「Geminiが精度悪いと言われるのはなぜ？」— ベンチマーク最強なのに“使うと弱い”と感じる理由（仮説と検証レシピ）
先にまとめ
- 前提: Gemini（特に 2.5 Pro）は学術系ベンチマークやアリーナ系人力比較で上位常連。つまり「数字」は強い。
-
それでも“精度悪い”体験が出る仮説:
- ツール（関数）呼び出しの堅牢性が相対的に弱い／癖がある
- 出力の表記・形式が揺れる
- モデル更新やガードレール、長文脈など環境要因の影響が大きい
- 落差の正体: 「オフラインの正解率」と「プロダクションの信頼性（JSON遵守、関数引数の妥当性、拒否・暴走の少なさ、バージョンドリフト耐性）」は別物。
- 検証の仕方: ツール呼び出し精度、構造化出力の厳密評価（スキーマ完全一致）、安全設定の拒否率、長文脈での再現性を小さな自前ベンチで測る。
-
対策:
response_mime_type=application/jsonと responseSchema の強制、低温度運用、モデルバージョン固定、安全設定明示、長文脈の分割要約、復唱確認（self-check）。
前提：ベンチマークは本当に強い
Google/DeepMind の公表値では、Gemini 2.5 Pro は GPQA や AIME 2025 などで最先端を主張。人手投票型の LMSYS Chatbot Arena でも時期により上位に顔を出す。すなわち「学術・一問一答の強さ」自体は疑いにくい。
仮説①：Tool use（関数呼び出し）の信頼性が相対的に低い／癖が強い
何が起きている？
- 関数選択や引数形成の取りこぼし: ツールの有無・複数競合・並列呼び出し・マルチターン（状態保持）で崩れるケースが出る。関数呼び出しそのものを測る BFCL（Berkeley Function-Calling Leaderboard）のような公開ベンチは、単発だけでなくマルチターンも評価対象で、この差が体感に直結。
- JSONモード×ツールの相性: JSON を強制した状態でツールを渡すとエラーや挙動不整合が起きるという開発者報告が散見。
なぜ“精度悪い”と感じる？
アプリ側の“正しさ”は「正解を知っているか」よりも「正しいツールを正しい形で呼べるか」に大きく依存。たとえば関数未選択・スキーマ外引数・不要な自由記述はゼロ点扱いになりやすい。Gemini はマルチモーダル＆長文脈最適化の色が強く、関数呼び出しの“厳格さ”で他社の特化モデル（例: Claude 系、最新 GPT 系）と体感差が出る場面がある、という仮説。
すぐできる検証
-
BFCL系のミニ模倣: 単発／並列／マルチターンで、関数選択の正否、引数バリデーション合格率、不要自由文の混入率を記録。
abstain（該当関数なし時に呼ばない）も指標化。 -
プロンプト設計:
response_mime_type=application/jsonと responseSchema（OpenAPI/JSON Schema）で厳格生成＋エラー時は再試行を標準化。
仮説②：出力の不安定さ（表記揺れ・形式ブレ）が大きい
何が起きている？
- 表記・フォーマットの揺れ: 同じ指示でも、JSONモードや構造化出力の有無で挙動がガラッと変わる報告がある。同一指示でもモードで出力差が出るのは実装側から見ると“再現性が低い”。
- 長文脈時の不安定: 極端に長い入力で安定しないという声。研究でも「Lost in the Middle」（中盤の情報を見落としやすい）問題は周知で、長文脈の使い方が性能を大きく左右する。
すぐできる検証
- JSON厳格率テスト: 同一プロンプトを N 回回して、JSON スキーマ完全一致率／正規化後の差分（キー順／半角全角／改行）を計測。
- 長文脈ロバスト性: 情報位置（冒頭／中盤／末尾）をずらした抽出課題で F1 を比較（Lost-in-the-Middle テスト）。
実運用の対策
-
構造化出力を“強制”:
response_mime_type=application/json＋responseSchema 推奨。公式もスキーマ設定の方が堅牢と明記。 -
温度と停止条件の管理: 低温度（必要に応じ 0〜0.2）、
stop_sequencesや system で禁止語を明示。
仮説③：“環境要因”が大きい（モデル更新、ガードレール、長文脈、UI差など）
-
モデル更新のドリフト（回帰）
特定バージョンで品質後退や非互換が話題→後日デプリケーションや改善版の案内、という揺れが起きうる。プレビュー系モデルをそのまま本番に当てると挙動変化＝体感“精度低下”。 -
ガードレール（安全設定）による拒否・書き換え
safetySettingsの既定閾値で出力がブロック／弱体化されうる。設定不具合の報もあり、「出せるはずの答えが出ない」体験に直結。 -
長文脈の“使いこなし”問題
1M トークン級を掲げるが、実務では位置依存や段階的要約の設計が不可欠。長いほど良いではない。 -
人力比較のばらつき
Arena 系は信頼区間やランク差の誤差がある。僅差モデル同士では“好み”や小挙動差が誤認識を生む。
具体的な検証レシピ（小さな社内ベンチの作り方）
A. ツール呼び出し
- 指標: 関数選択正解率／引数スキーマ合格率／abstain 正解率／再試行回数／レイテンシ
- ケース: 単発／並列／マルチターン（前ターン出力の引き継ぎ）
- ヒント: BFCL の設計思想（並列・複数・マルチターン）を薄く踏襲
B. 構造化出力
- 指標: JSON パース成功率／スキーマ完全一致率／余計な自然文混入率
-
設定:
response_mime_type=application/json、responseSchema、低温度
C. 安全設定・拒否率
- 指標: カテゴリ別拒否率／書き換え率（弱体化・省略）
-
設定:
safetySettingsを明示し、既定値との差分を計測
D. 長文脈
- 指標: 位置依存 F1（冒頭／中盤／末尾）／情報欠落率
- 設計: 「Lost in the Middle」型の配置で抽出課題を作る
実運用の処方箋（最小セット）
-
構造化を“契約”にする:
response_mime_type=application/json＋responseSchema、バリデーション→再試行をテンプレ化 -
温度・停止条件を固定: 低温度＋
stop_sequences。デフォルト放置は揺れの元 - モデル版を固定: preview を本番に入れない。更新監視と回帰テストを CI に組み込み
-
安全設定を明示:
safetySettingsを API レベルで指定し、拒否率を監視 - 長文脈は段階戦略: 分割→要約→照合の段階化で“見落とし”を回避
反証可能性（この仮説が間違いならどう示される？）
BFCL/自前テストで Gemini の関数呼び出しが同条件で同等以上、JSON 厳格率も同等、拒否率も同等以下であることが再現性高く示されれば、本稿の仮説①②③は弱まる。
おわりに：**“強いのに弱く感じる”**のは、指標の違い
Gemini は学術系ベンチや人力比較で強い一方、プロダクションが要求する“機械的な厳格さ”（ツール呼び出しの堅牢性、構造化の完全遵守、拒否の少なさ、バージョン安定性）では、設計・設定・運用の工夫なしだと落差が出やすい。つまり「精度」を答えの正しさだけでなく、「形式・手順の正しさ」まで広げて測ることが、認識のズレを解消する第一歩だ。
参考（主に一次情報・公的ドキュメント）
- Gemini の構造化出力（JSON スキーマ）: Structured output — Gemini API（公式）
- 関数呼び出し: Function calling — Gemini API（公式）, Function calling — Vertex AI（公式）
- BFCL（Berkeley Function‑Calling Leaderboard）: （公式ページ／論文リンクは後日追記）
- 安全設定（safetySettings）: Safety settings — Gemini API（公式）
- 長文脈（研究）: Lost in the Middle: How Language Models Use Long Context（arXiv:2307.03172）
- ベンチマーク強さの一次情報: Gemini 2.5 関連の公式案内（総合）
- Chatbot Arena ランキング: LMSYS Chatbot Arena Leaderboard
- 挙動の不安定報告（事例集）: JSON モード差分／長入力不安定／特定版の挙動変化（適切な一次ソースを確認し後日追記）
Discussion