ベクトル DB はもう不要？ Gemini 200万トークン超長コンテキストと Context Caching の性能・コスト徹底検証

Gemini 1.5 Pro は 200万トークンのコンテキストウィンドウを持ちます——小説『三体』三部作を一度に載せられる規模です。RAG を 2 年触ってきた開発者として、私はこう疑いました。ラボの数字はきれいでも、実運用ではダメなのでは？ ベクトル DB ＋ Embedding ＋ リランキングのパイプラインは、「丸ごと渡せばいい」に置き換わるのか。

実測で比べると、答えは思ったより複雑でした。

Gemini 長コンテキスト能力の全体像

1.5 Pro から 3.1 Pro への進化

まず Gemini の長コンテキストの歴史を短く振り返ります。

2024 年初頭、Gemini 1.5 Pro が登場し、コンテキストを一気に 100万トークンに広げ、業界を驚かせました。数ヶ月後には 200万トークンへ。当時 Claude 3 は 20万トークン前後、GPT-4 Turbo は 12.8万トークンでした。自転車レースに突然スポーツカーが入ってきたような格差です。

その後の Gemini 2.0・2.5 系は同じ方向を深掘りし、最新の Gemini 3.1 Pro はウィンドウを意図的に 100万トークンへ「縮め」つつ、推論品質とマルチモーダル理解を大きく上げています。Google の説明は、数字の競争より先に品質を固める、という方針です。

私も同感です。一冊分載せても読めないより、核心を正確に捉えられる容量の方が実用的です。

200万トークンはどれくらい入る？

数字のイメージが湧きにくい方向けに換算します。

• 英語約 150万語、漢字約 300万文字
• 『ハリー・ポッター』全 7 巻相当
• 技術ブログ約 10 年分の総量
• 中規模 Python プロジェクトのソース一式（コメント含む）

多くの企業の社内ナレッジベースは、一度に載せられる規模です。

自社の Wiki、技術文書、PRD、議事録を合わせても数十万文字程度でした。以前はチャンク化、ベクトル化、インデックス、検索品質の調整が必要でした。今はまとめて Gemini に渡すだけです。

マニュアルからオートマへ乗り換えた感覚に近いです。最初は不安ですが、慣れると戻れません。

マルチモーダル長コンテキスト：テキストだけではない

見落とされがちな点は、長コンテキストがマルチモーダルであることです。

1 時間の動画、数十ページの PDF、複数の図表を同時に渡し、「動画の数値と PDF 15 ページの統計は矛盾しているか？」と聞けます。モーダルをまたぐ関連分析は、従来の RAG では難しい。動画の分割や図のベクトル化は単純ではありません。

デモ動画、ユーザーフィードバック表、デザイン案を混ぜたテストでは、動画内容への質問に加え、デザイン判断とフィードバックの衝突まで指摘されました。俯瞰的な理解力には印象を受けました。

KiloClaw - 企業向けマネージド OpenClaw、AI エージェントのオーケストレーションとスマートルーティングを加速

今すぐ始める →広告

「大海撈針」実測：Gemini の再現率

Needle In A Haystack テストとは

容量が大きいのと、ちゃんと覚えているのは別問題です。200万文字を読ませて最後の数段落しか覚えていない、は避けたい。

業界では Needle In A Haystack（干し草の山から針を探す）テストがあります。超長文のどこかに特定の一文（例：「私の好きな色は紫です」）を埋め、無関係な文と混ぜ、AI にその文を問います。正答できれば長文の中から針を見つけたことになります。長さと位置を変えて繰り返し、再現率曲線を得ます。

Gemini 1.5 Pro の公式データ

Google 公表値は次のとおりです。

• 53万トークン：再現率 100%
• 100万トークン：99.7%
• 1000万トークンの極限テストでも 99.2%

初見は半信半疑でした。公式は最適条件のことが多いからです。

第三者の独立評価（Artificial Analysis など）では概ね一致。Gemini 1.5 Pro は長さを変えても再現が安定し、特に文書中盤の記憶が他モデルより優れていました。以前の長コンテキストでよくあった「中間忘却」——冒頭と末尾は覚えるが中盤がぼやける——をかなり抑えている印象です。

実務に近いシーンでの再現

ラボと業務は別です。約 50万文字の技術文書集（API、設計、障害対応など）を用意し、複数文書の異なる位置に設定パラメータを埋め、Gemini に質問しました。

多くは見つかりました。ただし次の傾向もありました。

• 構造化された明示情報（「API キーの有効期限は何日か」）はほぼ 100%
• 推論が要る質問（「この設計のセキュリティ上の懸念は」）はおおよそ 80%
• 複数文書をまたぐ質問では、ソースの一つを落とすことがある

強力だが万能ではない。単純検索ではなく複雑推論では、まだ最適化の余地があります。

Context Caching の深掘り

なぜコンテキストキャッシュが必要か

載せられる・覚えている、の次はコストです。毎回 200万トークンを送り直すと、請求で泣きたくなります。

Gemini 1.5 Pro の料金（2026 年 2 月時点）では、128K 超の入力は $2.50/100万トークン。200万トークンを 1 回送るだけで入力 $5。1日 100 回なら $500。多くのアプリでは現実的ではありません。

ここで Context Caching（コンテキストキャッシュ） が効きます。

仕組み

繰り返し使うコンテキストを事前にロードしてキャッシュし、以降はキャッシュ ID と新しい質問だけ送ります。

1. 初回リクエストでドキュメントを送り、キャッシュ作成を要求
2. Gemini がキャッシュ ID を返し、サーバー側でトークン状態を保持
3. 以降はキャッシュ ID ＋ 新しい質問のみ
4. 課金は新規質問のトークン ＋ 少量のキャッシュ維持費

キャッシュヒット分は通常入力の 10%。$5 相当の入力が $0.5 程度になります。コスト問題を想定した設計だと腑に落ちました。

Implicit と Explicit

Explicit Caching（明示的）：API でキャッシュを作成し、対象と TTL を指定。境界がはっきりしたナレッジベースやリポジトリ向き。

Implicit Caching（暗黙的）：2025 年 5 月以降、同一のトークンプレフィックスを自動検出してキャッシュ。操作不要で DX は良い。ただし同一プレフィックスが一定長に達するなど条件があり、毎回コンテキストが大きく違うと恩恵は薄いです。

ヒット率とコスト

ナレッジベース 100万トークン、1日 1000 クエリとします。

キャッシュなし：

• 入力：1,000,000 × 1000 ＝ 10億トークン/日
• 費用：10億 ÷ 100万 × $2.50 ＝ $2500/日

Context Caching あり：

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

• 初回ロード：$2.50（一度きり）
• 維持：$1.00/100万トークン/時 × 100万 × 24h ＝ $24/日
• 以降の入力（10% 想定）：$0.25/100万トークン
• クエリ分：1000 × 500 トークン × $0.25/100万 ≈ $0.125/日
• 合計：約 $25/日

$2500 から $25 へ、おおよそ 100倍 の差です。この試算のあと、一部プロジェクトの RAG からの移行を真剣に検討し始めました。

コスト対決：長コンテキスト vs RAG

Gemini API 料金（2026 年最新）

比較のため、2026 年 2 月時点の料金を整理します。

※ MTok ＝ 100万トークン

Context Caching：

• ストレージ：$1.00/100万トークン/時
• ヒット：通常入力の 10%
• ミス：通常料金

RAG の隠れコスト

表面上は Embedding とベクトル DB だけに見えますが、隠れコストがあります。

顕在コスト：

• Embedding API（例：text-embedding-3-large）$0.13/100万トークン
• ベクトル DB：Pinecone 標準で約 $70/月、または自前サーバー
• LLM 生成：モデル次第

隠れコスト：

• パイプラインの構築・保守の工数
• チャンクサイズ、オーバーラップ、リランキングの試行錯誤
• 検索→生成の 2 段でレイテンシ増
• どんな RAG でも取りこぼしはある

あるプロジェクトでは 2 週間チューニングし、再現率を 75% から 85% まで上げましたが完璧ではありませんでした。2 週間の人件費は、1 年分の API 料を上回ることもあります。

いつ切り替えるか

長コンテキスト向き：

• 総量 200万トークン以内（PDF 約 3000 ページ目安）
• 1日数百回以上のクエリ
• ドキュメント横断の関連分析
• 多少のレイテンシ許容（RAG より速いことも多い）
• 検索基盤を維持したくない

RAG 向き：

• 数千万トークン超のコーパス
• 1日数回〜数十回の低頻度
• 断片レベルの正確な引用・出典
• 更新が頻繁でコストに極端に敏感
• 成熟した RAG 基盤がある

例：50 万字の CS ナレッジ、1日 500 クエリなら長コンテキスト＋キャッシュで月 $50 前後もあり得ます。RAG だと DB と保守で逆に高くなることも。一方、数億字の法律文献プラットフォームなら RAG が妥当です。

実戦：Context Caching 導入

前提と制限

1. モデル：Gemini 1.5 Pro 以上
2. トークン数：キャッシュ対象は少なくとも 32,768 トークン（未満は割に合わない）
3. TTL：デフォルト最長 1 時間（延長可）
4. リージョン：未対応地域あり。公式を確認

Python SDK 例

import google.generativeai as genai
from google.generativeai import caching
import datetime

# 配置 API Key
genai.configure(api_key="YOUR_API_KEY")

# キャッシュする本文（少なくとも 32768 トークン）
document_content = """
[あなたの長文ドキュメント。少なくとも 32768 トークン]
"""

cache = caching.CachedContent.create(
    model='gemini-1.5-pro-002',
    display_name='knowledge_base_cache',
    system_instruction='提供された技術文書に基づき回答する専門アシスタントです。',
    contents=[document_content],
    ttl=datetime.timedelta(hours=1),
)

print(f"キャッシュ作成: {cache.name}")
print(f"トークン数: {cache.usage_metadata.total_token_count}")

model = genai.GenerativeModel.from_cached_content(cached_content=cache)

response = model.generate_content("文書に書かれた API レート制限の方針は？")
print(response.text)

cache.update(ttl=datetime.timedelta(hours=2))

# cache.delete()

ライフサイクル

作成：起動時に常用文書をプリロード、またはアップロード時にオンデマンド作成。

延長：期限前でアクティブならバックグラウンドで update。

削除：不要キャッシュは削除してストレージ料を抑える。

caches = caching.CachedContent.list()
for c in caches:
    print(f"{c.display_name}: {c.name} (残り {int(c.expire_time.timestamp() - datetime.datetime.now().timestamp())} 秒)")

now = datetime.datetime.now()
for c in caches:
    if c.expire_time < now + datetime.timedelta(minutes=5):
        c.delete()
        print(f"削除: {c.display_name}")

よくある落とし穴

落とし穴1：キャッシュ未ヒットでも課金

キャッシュ ID の誤りや期限切れで通常料金のまま。ログでヒットを確認してください。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

落とし穴2：トークン数の不一致

32,768 以上が条件ですが、自前計算と Google 側がずれることがあります。SDK の usage_metadata で確認。

落とし穴3：並行

同一キャッシュ ID への同時リクエストは問題ありませんが、延長の原子性には注意。

落とし穴4：内容更新

原文が変わってもキャッシュは自動更新されません。古いキャッシュを削除し、作り直してください。

アーキテクチャの選択：RAG は死んだか、共生か

長コンテキストの限界

万能ではありません。

• コスト上限：キャッシュでも数千万トークン超では維持費が重い
• 更新頻度：頻繁な更新ではキャッシュ再構築が多く、優位が薄れる
• 精密な引用：RAG は「何ページ何段落」と出せる。長コンテキスト単体では出典が弱い
• マルチテナント：ユーザーごとにコンテキストが分かれると、キャッシュ管理が複雑

RAG が替えられない場面

• 膨大なコーパス検索：TB 級はベクトル DB が現実的
• 分単位の更新：ニュース、株価など
• 複合検索：キーワード、タグ、時間などの多次元フィルタ
• 成熟した基盤：安定運用中なら、新しさだけで全面移行は不要

ハイブリッド

排他的ではありません。

第1層：ベクトル検索で関連数百件を粗く絞る
第2層：そのバッチを Gemini 長コンテキストで精読

RAG が粗引き、Gemini が精読——最近この分担を試していますが、想定以上にうまくいきました。

判断の簡易ツリー

ドキュメント総量は？
├── 200万トークン未満 → 長コンテキスト + Context Caching
└── 200万トークン以上 →
    ├── 断片の正確な引用が必要 → RAG
    ├── 更新が非常に頻繁 → RAG
    └── それ以外 → ハイブリッド（RAG 粗引き + 長コンテキスト精読）

展望とまとめ

トレンド

2026 年初頭の時点では、長コンテキストの進化は速い。ウィンドウ拡大とコスト低下は続くでしょう。かつて「載せられるが覚えない」だったのが、「載せて覚えている」に近づいています。数年後、「ドキュメントが大きすぎる」はメモリ不足のように遠い話になるかもしれません。

RAG 開発者へ

1. 慌てない：RAG は消えず、役割がはっきりする。RDB と NoSQL のように共存します。
2. 触ってみる：小さな案件を長コンテキストに移し、差を体感する。
3. ハイブリッドを見る：当面の有力解のひとつ。
4. 数字で決める：新しさも古さも捨て、コストと品質で選ぶ。

書き終えて、Gemini への態度は懐疑から慎重な楽観へ移りました。銀の弾丸ではないが、条件が合えば RAG よりシンプルで安い場面はあります。技術の価値は新旧ではなく、問題を解けるかです。

実践の話や質問があれば、コメントで共有してください。この分野はまだみんな学び続けている最中です。