【検証スパイク】PoC中のドキュメント検索アプリでAWSのTPM制限を突破する：Gemini vs OpenAI

現在、社内でPoC（概念実証）を進めている「ドキュメント検索アプリ」において、利用拡大に伴うパフォーマンスの壁に直面しました。

本記事では、AWS Bedrock環境で発生したTPM（1分あたりのトークン数）制限による課題と、それを解決するために実施した検証スパイクの結果について共有します。

1. 背景と課題：3人の同時利用でPoCがストップ

現在開発中のアプリは、回答生成のモデルにAWS Bedrock（Claude 3 Haiku / 東京リージョン）を利用しています。単体テスト段階では問題ありませんでしたが、複数人での同時利用テストを開始したところ、以下の課題が浮き彫りになりました。

TPM制限によるエラー:現行環境のTPM上限は20万トークンです。1リクエストあたりのトークン消費量が多いため、わずか3人が同時利用しただけで上限に達し、エラーが発生してしまいました。
15人規模への対応が必要:PoCの次フェーズでは15人規模の同時利用を想定しており、試算では約133万TPM（入力約125万・出力約7.6万）が必要となります。
応答速度の許容範囲:現状の応答速度は40〜67秒かかっています。今回のアプリ要件として「60秒以内のレスポンス」をKPIとしていますが、現状はギリギリ、あるいはオーバーすることもあり、改善が望まれる状態でした。

2. 検証スパイクの概要

TPM制限の解消と、許容範囲内でのレスポンス維持を目的に、以下の2つのプラットフォームで検証スパイクを実施しました。

検証対象

Google Cloud: Gemini (File Search Tool)
OpenAI: Response API + Vector Store

検証環境

今回の検証は、素早い意思決定を行うためのスパイク（技術検証）として、以下の環境で行いました。

Gemini: 公式から提供されているデモ版を使用。
OpenAI: ローカル環境で簡易的な実装を行い検証。

3. 検証結果

両モデルとも、回答の精度（Accuracy）については現行のClaude 3 Haikuと比較しても遜色なく、良好な結果が得られました。

その上で、TPMと速度の観点での比較結果は以下の通りです。

① TPM（スケーラビリティ）

両サービスともに、契約Tierによっては200万TPMの上限を提供しており、課題となっていた「15人同時利用（必要数：約133万TPM）」を理論上クリアできることが確認できました。

② 応答速度パフォーマンス

KPIである「60秒以内」をクリアできるかどうかに注目しました。

Gemini (公式デモ版): 約10秒フルマネージドのFile Search Toolが最適化されており、非常に高速な結果が出ました。KPIを余裕でクリアしています。
OpenAI (ローカル簡易実装): 約90秒今回の簡易的な実装環境では、検索・回答生成に時間がかかり、KPIの60秒を超過する結果となりました。チューニング次第で改善の余地はありますが、素の構成ではGeminiに分がありました。

4. コスト面の比較

コスト効率においても、Geminiの優位性が確認されました。

Gemini 2.0 Flash等は入力単価が安価（$0.0001/1Kトークン）であることに加え、ストレージや検索時の埋め込み生成が無料（初回インデックス時のみ課金）という特徴があります。OpenAIも以前より価格競争力は増していますが、今回の構成においてはGeminiの方がコストパフォーマンスが高いと判断しました。