Gemini API のロングコンテキストでよくある問題と解決策

Gemini API の100万トークンコンテキストウィンドウに魅力を感じて使い始めたものの、「思ったように動かない」という経験をされた方は多いのではないでしょうか。

私自身、大量のドキュメントを一度に渡して分析させようとしたとき、最初は期待通りに動かず原因究明に時間を取られました。コンテキストウィンドウが大きければ大きいほど便利なはずなのに、なぜか精度が下がる、遅くなる、お金がかかる——この三重苦に悩んだ経験から、よくある問題とその対処法をまとめました。

「中間の情報が回答に反映されない」— Lost in the Middle 問題

長い文書を渡したとき、文書の最初と最後に書いた内容は答えてくれるのに、中間部分の情報が回答に出てこないという現象があります。これは「Lost in the Middle」と呼ばれる現象で、大規模言語モデルに共通して起きる特性です。

原因: トランスフォーマーモデルは、コンテキストの先頭（primary position）と末尾（recency effect）に注意を向けやすい傾向があります。中間部分は相対的にアテンションスコアが低くなり、特に無関係な情報が大量に挟まっている場合、モデルは中間の内容を「背景情報」として処理してしまいます。

対処法:

# ❌ 問題が起きやすいパターン：関連情報が中間に埋もれる
prompt = f"""
{大量の前置き情報...}
 
{実際に必要な情報}  ← ここが埋もれる
 
{大量の後置き情報...}
"""
 
# ✅ 対策1: 最も重要な情報を冒頭に置く
prompt = f"""
## 主要情報（必ず参照してください）
{最も重要な情報}
 
## 補足情報
{その他の情報...}
"""
 
# ✅ 対策2: System Instructionsで強調する
response = client.models.generate_content(
    model="gemini-2.5-pro",
    contents=prompt,
    config=types.GenerateContentConfig(
        system_instruction="文書の全ての部分を均等に参照し、特に「主要情報」のセクションを最優先にしてください。"
    )
)

対策3: 文書を複数のチャンクに分割して個別に処理し、最後に結果を統合するアプローチも有効です。Gemini の長文処理能力に頼るより、構造を設計する方が精度が安定します。

レスポンスが遅い・タイムアウトが発生する

入力トークンが増えると比例してレスポンスが遅くなるのは自然ですが、それ以上に遅い場合や、途中で接続が切れる場合は別の原因を疑う必要があります。

よくある原因と対処:

原因1: 大量のトークンを同期処理している

# ❌ 同期処理：長い応答で詰まりやすい
response = client.models.generate_content(model="gemini-2.5-pro", contents=long_prompt)
 
# ✅ ストリーミング処理：チャンクが届き次第処理できる
for chunk in client.models.generate_content_stream(
    model="gemini-2.5-pro",
    contents=long_prompt
):
    if chunk.text:
        print(chunk.text, end="", flush=True)

原因2: HTTPクライアントのタイムアウト設定が短い

100万トークン処理では応答に数十秒かかることがあります。デフォルトのタイムアウト（多くのHTTPクライアントで30秒〜60秒）では足りない場合があります。

import google.generativeai as genai
 
# クライアントレベルでタイムアウトを延長
client = genai.Client(
    api_key="YOUR_GEMINI_API_KEY",
    http_options={"timeout": 300}  # 5分に延長
)

原因3: モデルが過負荷状態（503エラー）

503 UNAVAILABLE が返ってきた場合はモデルが高負荷状態です。指数バックオフでリトライするのが定石です。

import time
import google.generativeai as genai
 
def generate_with_retry(client, model, prompt, max_retries=5):
    for attempt in range(max_retries):
        try:
            return client.models.generate_content(model=model, contents=prompt)
        except Exception as e:
            if "503" in str(e) or "overloaded" in str(e).lower():
                wait_time = (2 ** attempt) + 1  # 3s, 5s, 9s, 17s, 33s
                print(f"リトライ {attempt + 1}/{max_retries}、{wait_time}秒後...")
                time.sleep(wait_time)
            else:
                raise
    raise RuntimeError(f"{max_retries}回リトライしても失敗しました")

長文入力でトークン料金が想定外に膨らむ

「ちょっと試してみただけなのに請求額が高かった」——コンテキストウィンドウが大きいと、うっかりすると大量のトークンを消費します。

対策: 送信前にトークン数を確認する

from google import genai
 
client = genai.Client(api_key="YOUR_GEMINI_API_KEY")
 
# 実際に送信する前にトークン数を計測
count_result = client.models.count_tokens(
    model="gemini-2.5-pro",
    contents=long_prompt
)
print(f"予定トークン数: {count_result.total_tokens:,}")
 
# Gemini 2.5 Pro の料金（参考）
# 200K以下: 入力 $1.25/1M tokens
# 200K超:   入力 $2.50/1M tokens
estimated_cost = (count_result.total_tokens / 1_000_000) * 2.50
print(f"推定コスト（入力のみ）: ${estimated_cost:.4f}")
 
# 閾値を設定してコスト制御
MAX_INPUT_TOKENS = 300_000
if count_result.total_tokens > MAX_INPUT_TOKENS:
    raise ValueError(f"トークン数が多すぎます: {count_result.total_tokens:,}")

コスト削減の実践:

同じ文書を繰り返し参照する場合は、コンテキストキャッシングを使えば最大75%のコスト削減が可能です。ただしキャッシングにも注意点があるので、後述します。

応答品質が不安定になる

同じ文書、同じ質問でも、日によって（あるいはリクエストのたびに）回答の質が変わるという問題です。

原因1: 温度（temperature）パラメータの設定

長文分析・情報抽出タスクには低い温度値が適切です。

response = client.models.generate_content(
    model="gemini-2.5-pro",
    contents=prompt,
    config=types.GenerateContentConfig(
        temperature=0.0,   # 情報抽出・分析: 0.0〜0.2
        # temperature=0.7, # 創作・ブレスト: 0.7〜1.0
    )
)

原因2: thinking_budget の影響

Gemini 2.5 Pro / Flash は推論予算（thinking_budget）を持っています。長いコンテキストでは内部推論がブレやすいため、適切に制御します。

response = client.models.generate_content(
    model="gemini-2.5-pro",
    contents=prompt,
    config=types.GenerateContentConfig(
        thinking_config=types.ThinkingConfig(
            thinking_budget=1024  # 推論に使うトークンを制限して安定化
        )
    )
)

コンテキストキャッシングを使ったのに効果がない

「キャッシングを有効にしたのにコストが変わらない」というのはよくある悩みです。

詳しいトラブルシューティングはコンテキストキャッシングが動かない問題の解決策にまとめましたが、最も多い原因はこの2つです。

原因1: キャッシュの最小トークン数を満たしていない

Gemini API のコンテキストキャッシングは、キャッシュするコンテンツが一定のトークン数（Gemini 2.5 Pro では 32,768トークン以上）必要です。これ以下のサイズだとキャッシングの対象外になります。

原因2: キャッシュ期間内に再利用していない

作成したキャッシュはデフォルトで1時間有効ですが、期間内に再利用しないと毎回課金されます。TTL（Time To Live）を適切に設定し、ウォームアップ処理で事前にキャッシュを準備する設計が効果的です。

from google import genai
from google.genai import types
from datetime import timedelta
 
client = genai.Client(api_key="YOUR_GEMINI_API_KEY")
 
# キャッシュを作成（有効期間を24時間に設定）
cache = client.caches.create(
    model="gemini-2.5-pro",
    contents=[large_document_content],
    config=types.CreateCachedContentConfig(
        system_instruction="あなたは文書分析の専門家です。",
        ttl=timedelta(hours=24)  # デフォルトの1時間から延長
    )
)
 
print(f"キャッシュID: {cache.name}")
print(f"有効期限: {cache.expire_time}")

レスポンスが途中で切れる

長い文書を渡すと、出力も長くなりがちです。デフォルトの max_output_tokens に引っかかって応答が切れることがあります。

response = client.models.generate_content(
    model="gemini-2.5-pro",
    contents=prompt,
    config=types.GenerateContentConfig(
        max_output_tokens=8192,  # デフォルト値を増やす（最大 65,536）
    )
)
 
# finish_reason を確認して切れていないかチェック
if response.candidates[0].finish_reason.name != "STOP":
    print(f"⚠️ 応答が不完全です。理由: {response.candidates[0].finish_reason.name}")
    # MAX_TOKENS の場合は続きをリクエストするロジックを実装

全体を振り返って：長文処理を安定させる設計の考え方

Gemini のロングコンテキストは強力ですが、「全部突っ込めばいい」という発想だと必ず問題にぶつかります。私が実際に使って安定しているのは、次のシンプルな原則です。

まず、重要な情報を文書の冒頭に置きます。次に、送信前に count_tokens でコストを確認します。そして、繰り返し使う文書はコンテキストキャッシングで最適化します。

より詳細なパフォーマンス最適化については、Gemini API のレイテンシ最適化ガイドもあわせてご覧ください。長文処理特有のチューニングポイントも解説しています。

実装で詰まった箇所があれば、まずはこの記事のチェックポイントを一つずつ確認してみてください。ほとんどのケースはいずれかの項目に当てはまるはずです。