Skip to Content
Docs03. 実装Gemini 特化プロンプティングガイド
中級prompt-designmodel-selection更新: 2026-10-08この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

Gemini 特化プロンプティングガイド

この記事の目的

Google の Gemini ファミリーに対して、公式ガイドが推奨する具体的なプロンプトの書き方を根拠を持って選べるようになります。汎用の基礎技法と上級パターンがモデル中立の原理を扱うのに対し、本記事は「few-shot の常時推奨・thinking_level・サンプリングパラメータの扱い・マルチモーダルテキスト以外の入力(画像・音声など)を理解できるモデルの能力。コンピュータ操作型 Agent の前提となる。」といった、このモデル固有の作法に踏み込みます。

本記事は鮮度管理型です。 モデル世代・機能名(効果や API 仕様)は変化が速いため、本文冒頭の最終確認日と各公式ページを必ず確認してください。API のフィールド名は実装時に公式リファレンスで綴りを再確認してください。

対象読者

  • Gemini を使ったアプリ・エージェントを実装し、そのモデルに合わせてプロンプト品質を上げたいエンジニア
  • マルチモーダル・長コンテキストを活かしたい、または Gemini の世代交代に追従したいエンジニア

前提知識

本文

最終確認日: 2026-09-10 — Gemini 3.8 Flash のモデル仕様と、数値思考予算のモデル / API 別の扱いを更新しました。共通指針は各参考資料の確認日を参照してください。

部分再確認: 2026-10-08 — Gemini 2.5 系の利用対象と、3.8 Flash のモデル仕様・思考レベルを再確認しました。API 別の実呼出しや共通プロンプト指針の全項目は未再検証です。

概要: 汎用記事との分担

層正本本記事
汎用技法(名前・使いどころ)基礎技法—
中立な原理と検証(なぜ効くか)上級パターン—
Gemini 固有の作法本記事few-shot 重視・thinking_level・サンプリング・マルチモーダル・世代差
モデルの選び方モデル選定ガイド / モデルカタログ—
世代交代への追従運用バージョニングとモデル更新追従—

Claude・OpenAI との横並び比較と移行は モデル間の違いと移行 が扱います。

モデルファミリーの前提(プロンプトに効く差分だけ)

顔ぶれ・価格・選び方は モデルカタログ が正本です。プロンプト設計に効く差分だけを押さえます。Gemini 3.8 Flash は 2026-09-10 に確認し、従来モデルの共通指針は各参考資料の確認日を基にしています。

  • 現行は Gemini 3 系: 安定版は Gemini 3.8 Flash(2026-09-02 GA、入力 1,048,576 / 出力 65,536 トークン)・3.7 Flash・3.6 Flash(2026-07-21 登場)・3.5 Flash-Lite / 3.1 Flash-Lite(軽量)で、プレビューの 3.1 Pro などがあります。3.5 Flash はレガシー扱いに移りました。旧世代の 2.5 Pro / Flash / Flash-Lite は 2026-09-18 から過去の利用者のみ利用可能で、終了日は未定です(2026-10-16 提供終了の告知は撤回されました)。新規プロジェクトは 3.5 Flash-Lite / 3.8 Flash などを検討します(提供条件は 2026-10-08 確認)
  • 3 系は thinking_level を基本にする: 数値予算の有無はモデル / API 別に確認します。2.5 系の Live API と一括化しません(後述)
  • マルチモーダルが最大の差別化点: text / image / audio / video を同格の入力として扱えます。プロンプトはこれを前提に書きます
  • サンプリングパラメータは既定のままが公式推奨で、これは他社の慣行と逆向きです(後述)

メッセージ構造とシステム指示

  • 重要な指示は system instruction かプロンプト冒頭に置く: 役割(ペルソナ)・振る舞いの制約・出力フォーマットを system instruction に寄せます
  • 簡潔・直接に書く: Gemini 3 は「ゴールを明確かつ簡潔に述べる」ことを推奨し、過度に丁寧・説得的な言い回しは不要とします(「あなたは超優秀なので、どうか…」的な誘導は効きません)
  • 曖昧語を定義する: 解釈の割れる語は明示的に説明します

構造化の推奨記法

  • XML タグまたは Markdown 見出しのどちらでもよい: 一貫した区切りで各部を分離します。Gemini は両方を同格に例示します(Claude が XML を強調するのと対照的)
    • XML 例: <role> / <constraints> / <context> / <task>
    • Markdown 例: # Identity / # Constraints(箇条書き)
  • 制約を明示する: すべきこと・すべきでないことと、出力フォーマット(表・箇条書き・段落など)を指定します

例示(few-shot)

few-shot の常時推奨が Gemini 最大の特徴です。公式は「プロンプトには常に few-shot 例を入れることを推奨」「例のないプロンプトは効果が落ちやすい」と明言します。

  • 例がフォーマット・言い回し・スコープ・パターンを規定する: 言葉で説明しにくい出力の型を例で伝えます
  • 全例で構造・フォーマットを統一する: ばらつくと、望まない出力形式を招きます
  • 数は実験で最適化する: 少数でパターンを掴めることが多く、多すぎると例へ過学習します

汎用の例示設計(上級パターン)に加え、この「常時 few-shot + フォーマット統一」が Gemini 固有の勘所です。

思考の制御: thinking_level

Gemini 3 系の思考制御は thinking_level(相対的な思考量の許容)で行います(2026-08 時点)。

  • 既定は動的思考(dynamic thinking): 複雑さに応じて思考量を自動調整します。thinking_level は minimal / low / medium / high で、モデルごとに既定と対応レベルが異なります(2026-08 時点の既定の例: 3.7 Flash は medium で minimal 非対応、3.6 Flash は medium、3.5 Flash-Lite は minimal、3.1 Pro プレビューは high)
  • thinking_budget は一律に廃止されたわけではありません: 2026-09-10 の公式 Python SDK の ThinkingConfig に数値の thinking_budget があり、Live API 公式も 2.5 Flash の thinkingBudget を説明しています。3.8 Flash は low / medium / high(既定 medium、minimal 非対応)を使います。SDK に型があることだけでは、すべてのモデルが同じフィールドを受理するとは判断できません
  • 複雑な CoT の作り込みをやめる: 「ステップごとに考えて」を長々と書くより、thinking_level: high に任せるのが公式の推奨です(上級パターンの思考制御の Gemini 版)
  • 思考署名(thought signatures)は SDK 任せ: マルチターンで推論を継続するために必要な暗号化状態で、SDK が自動処理します。手動設定は不要です

出力の制御: JSON スキーマ強制

  • 機械処理する出力は JSON スキーマで強制する: JSON MIME タイプ + スキーマを指定します(パラメータ名は世代・API 面で異なるため実装時に公式リファレンスで確認)。基本設計は 構造化出力 が正本です
  • スキーマの description でモデルを誘導し、具体的な型(integer・enum)を使う。ただし非常に大きい・深くネストしたスキーマは拒否されうるため、アプリ側でも必ず検証します
  • 構造化出力LLM の出力を JSON Schema などの機械可読なスキーマに従わせる技術。後続の処理がコードである出力(分類・抽出・スコア)に使う。は組み込みツールと併用できる(検索・コード実行・function calling など)
  • サンプリングパラメータは既定のまま: Gemini 3.x では temperature を既定(1.0)から下げると looping や性能劣化を招きうると公式が警告します。決定性のために温度を下げる他社の慣行は Gemini では逆効果です
  • 既定は簡潔: 詳細・会話的な回答が欲しければ system instruction で明示的に要求します

長文・長コンテキストとマルチモーダル

  • 資料を先・質問を最後に置く: これは Google が最も一貫して繰り返す長文作法です。大きなデータブロックの後には転換句(「以上の情報に基づいて…」)を挟みます
  • コンテキストキャッシュを使う: 繰り返し使う前置き資料をキャッシュしてコストを削ります
  • 複数箇所の同時検索は精度が落ちうる: 単一箇所の抽出は高精度でも、多数の情報を同時に探させると精度が変動します。タスクを分けることを検討します
  • マルチモーダルは各モダリティを本文で明示参照する: text / image / audio / video を同格に扱い、指示側で「この画像の…」のように各入力を明確に指し示します。高解像度設定は PDF などでトークン消費が増える点に注意します

ツール使用・エージェント文脈

  • 関数宣言は明確・簡潔に、強い型付けで: 目的・各パラメータの型と説明を書き、integer・enum などの具体型を使います
  • 呼び出しモードを使い分ける: auto(既定)/ any(必ず呼ぶ)/ none(呼ばない)/ validated(スキーマ遵守を保証)。並列呼び出しと合成(依存関数の逐次連鎖)に対応します
  • アクティブなツール数は 10〜20 個までに絞る: 多すぎると選択が乱れます
  • エージェントの system instruction に設計軸を書く: 自律度・リスク許容(低リスクな読み取りと高リスクな状態変更の区別)・明確化を求めるか仮定して進むか・エラー回復の粘り強さ、を明示します

世代交代で見直すこと

2.5 系から 3 系への移行で見直す点です(2026-08 時点)。

  • 複雑な CoT スキャフォールドを thinking_level: high に置き換える
  • 決定性のための明示的な temperature 設定を外す(既定に戻す)
  • 移行先の API とモデルに合わせて思考制御を選ぶ: 3 系は thinking_level を基本とします。2.5 Live の数値予算まで機械的に書き換えません
  • 既定が簡潔になった: 2.5 で得ていた冗長さが要るなら明示的に要求します
  • API 面の移行: 従来の generateContent から新しい Interactions API(ステートフル)への移行が進んでいます。一部機能は片方にのみあります

移行作業の運用(回帰評価・段階リリース)は バージョニングとモデル更新追従 が正本です。

効かない・不要になった俗説

以下は Google 公式が非推奨・不要とするものです(2026-08 時点)。

  • 過度に丁寧・説得的な前置き: 直接的で構造化されたプロンプトが最良
  • 手作りの CoT スキャフォールド: thinking_level に任せる
  • 決定性のための低 temperature の常用: Gemini 3.x では looping・劣化を招きうる。サンプリングパラメータは既定維持
  • few-shot なしで済ませる: 効果が落ちやすいと明言。常時例を入れる
  • 例を大量に盛る: 多すぎると例へ過学習

実務での注意点

アンチパターン

  • 他モデルの慣行で temperature を下げる → Gemini 3.x では looping・性能劣化を招きうる → サンプリングパラメータは既定のまま、挙動はプロンプトで誘導する
  • few-shot 例なしで書く → Gemini では効果が落ちやすい → 常に例を入れ、全例でフォーマットを統一する
  • 複雑な CoT スキャフォールドを書き込む → thinking と二重になり冗長 → thinking_level: high に任せる
  • 質問を資料より前に置く → 長コンテキストで品質が落ちる → 資料を先・質問を末尾に置き、転換句を挟む
  • マルチモーダル入力を本文で参照しない → どの画像・音声を指すか曖昧になる → 指示側で各モダリティを明示参照する

チェックリスト

  • 役割・制約・出力形式を system instruction かプロンプト冒頭に置いた
  • few-shot 例を入れ、全例で構造・フォーマットを統一した(多すぎない)
  • 対象モデル・API の thinking_level / thinking_budget 対応と既定を確認し、実際のリクエストで検証した
  • temperature などサンプリングパラメータを既定のまま使っている
  • 機械処理する出力を JSON スキーマで強制し、アプリ側でも検証している
  • 長文は資料を先・質問を末尾に置き、転換句を挟んでいる
  • マルチモーダル入力を指示側で明示参照している
  • アクティブなツール数を 10〜20 個に絞っている

関連トピック

参考資料

TODO・未確認事項

変わりやすい項目(定点観測)

OpenAI(GPT 系)特化プロンプティングガイドモデル間の違いと移行(横断比較)