MENU
知識がなくても始められる、AIと共にある豊かな毎日。
noteを見に行く
AIコーディング

Gemini プロンプトの設計術 — 1M トークンと Deep Think を引き出す

ゲンキ

Gemini プロンプトの設計術 — 1M トークンと Deep Think を引き出す

「Claude で使えていたプロンプトをそのまま Gemini に貼ったら、なぜか出力が浅い」「ChatGPT で精度が出ていた連鎖思考プロンプトが、Gemini 3.1 Pro では逆に冗長な分析を返す」。本連載の Gemini プロンプト特集第 1 弾を読み始めたあなたは、おそらくこの種のミスマッチに気づいて来たはずだ。

Gemini 3.1 Pro 完全ガイドで確認した通り、Gemini 3.1 Pro は ARC-AGI-2 や GPQA Diamond で他陣営を上回る抽象推論能力を持つ。しかしその力を引き出すプロンプト作法は、Claude や ChatGPT とは別物だ。本記事は 2026 年 5 月時点の Google 公式ガイドと Phil Schmid 氏ら実務家の検証を統合し、Gemini プロンプトの「効く構造」と「逆効果のアンチパターン」を整理する。Gemini CLI 入門と Claude vs ChatGPT vs Gemini 比較にも橋渡しする基礎篇だ。

目次
  1. なぜ Claude / ChatGPT のプロンプトが Gemini で空振りするのか
  2. 効く構造 — Role + Goal + Constraints + Examples + Output format
  3. 1M token コンテキストの設計 — Lost-in-the-middle への対策
  4. Deep Think Mini を引き出す指示文
  5. システム指示（system_instruction）の設計
  6. マルチモーダル — 画像・PDF・動画の渡し方
  7. Few-shot examples の使い方と限界
  8. 失敗テンプレート — 旧時代の遺物
  9. まとめ — メイカーが今夜から書き換えるべき 5 行
  10. 参照
忍者AdMax

なぜ Claude / ChatGPT のプロンプトが Gemini で空振りするのか

Anthropic Claude は「丁寧な前置きと安全性配慮」を好み、OpenAI GPT は「対話的な役割遊びと連鎖思考」を歓迎する。一方で Google DeepMind は Gemini 3.1 Pro のプロンプト指針を 2026 年に大きく刷新し、「直接性 > 説得」「論理 > 冗長性」を明示した。Vertex AI（現 Gemini Enterprise Agent Platform）のドキュメントは「Gemini 3 はチャット相手ではなく実行エンジンとして扱え」と書く。

具体的に、Claude 向けに練ったこんなプロンプトを想像してほしい。「あなたは経験豊富な機械工学エンジニアです。これから提示する 3D モデルの問題について、慎重に段階的に思考し、可能な限り多角的な観点から分析してください。まず観察を述べ、次に仮説を立て、最後に推奨を出してください」。Claude Opus 4.7 はこの種の指示で出力品質が上がる。しかし Gemini 3.1 Pro は同じプロンプトを「過剰な制約」と解釈し、無駄に長い分析や、形式に縛られすぎて本筋を外した出力を返すケースが報告されている。

公式ガイドが繰り返し警告するのは、「旧モデル時代の冗長プロンプト技法は、Gemini 3 では over-analyze（過剰分析）の原因になる」という点だ。Chain-of-Thought（連鎖思考）を明示的に書かせる、複雑な役割演技を組み込む、安全性配慮を何重にも入れる、といった「Claude / GPT 経由で培われたプロンプト工学」は、Gemini ではむしろ逆効果になる。これは劣化ではなく、Gemini 3.1 Pro が標準で深い思考（Deep Think Mini）を内蔵しているための仕様だ。明示的に「考えて」と言わなくても、HIGH モードでは自動的に考える。

たとえば「Let’s think step by step」という呪文は GPT-3.5 時代に発見された強力なテクニックで、Claude や ChatGPT では今でも有効な場面がある。しかし Gemini 3.1 Pro でこれを書くと、モデルは「考えるべき問題なのか、それとも step-by-step 形式での出力が求められているのか」と混乱し、本来不要な手順分解を出力に含めてしまう。結果として「3D モデルの応力ポイントを 3 つ挙げて」という単純な質問に対し、3 つの応力ポイントを答える前に「私はまず問題を理解する必要があります。次に応力解析の基礎を確認します…」と前置きが入る、という出力になる。これは可読性を下げるだけで、推論の質を上げない。

効く構造 — Role + Goal + Constraints + Examples + Output format

Google 公式と Phil Schmid 氏の Gemini 3 Prompting Guide が共通して推す型は、5 要素の組み合わせだ。

要素役割書き方の例（3D プリント業務）
Role立場と専門領域「あなたは Klipper firmware に精通した 3D プリンタエンジニアだ」
Goal達成すべき結果「この printer.cfg の論理矛盾を抽出し、優先度付きで提示する」
Constraints制約条件「日本語で回答」「コードブロックは使わず Markdown 表で」「推測は明示」
Examples1〜2 の最小例「例: pressure_advance と pressure_advance_smooth_time の同時設定 → 注意」
Output format出力スキーマ「優先度 / 該当箇所 / 提案 / 根拠 の 4 列表」

この型の核心は「長さよりも構造」だ。プロンプト全体が 200 トークン以内でも、5 要素が揃っていれば 1,000 トークンの曖昧なプロンプトより精度が高い。逆に、200 トークンに膨らんだ「丁寧な依頼文」は、5 要素が崩れていれば品質を下げる。

Goal を書くときの失敗例は「3D モデルを分析せよ」のような曖昧形だ。Gemini プロンプトを効かせるには「青線の傾向は？」「サポート構造の最適化点を 3 件挙げよ」のような具体的問いに落とし込む必要がある。Phil Schmid 氏は「Gemini 3 はチャット仲間ではなく実行エンジン」と表現し、ゴールと出力形式と制約を明示的に渡すことが鍵だと書く。

Output format をスキーマで固定するのも強力だ。「JSON で {severity, category, summary} を返せ」「Markdown 表で 4 列固定」のように指示すると、後段のパース処理が安定する。逆にスキーマを書かず「適切な形式で」と曖昧にすると、同じプロンプトでも応答ごとに形式が揺れる。

スキーマの記述粒度にもコツがある。「JSON で返せ」だけでは不足で、各フィールドの型と取りうる値の範囲まで書く方が安定する。「severity は low / medium / high / critical の 4 値から、summary は 100 字以内の日本語、references は配列で各要素は URL 形式」のように、enum や桁数を明示する。Gemini Developer API には structured output（構造化出力）機能があり、Pydantic 風のスキーマを渡せば応答がそれに準拠する形で返ってくる。これを使えばパースエラーをほぼ撲滅できる。

Role の書き方でも違いが出る。Claude は「あなたは慎重で丁寧な助手です」のような性格付けに反応するが、Gemini は性格付けより専門領域の明示に強く反応する。「あなたは Klipper firmware と Voron 自作機に詳しい 3D プリンタエンジニアだ」のような具体的領域定義の方が、「経験豊富で慎重なエンジニア」のような性格描写より精度が出る。

1M token コンテキストの設計 — Lost-in-the-middle への対策

Gemini プロンプトの真価は 1M token のコンテキスト窓にある。Google 公式の表現を借りれば、1M token は 約 1,500 ページの文書、または約 30,000 行のコードに相当する。Klipper のリポジトリ全体、過去 100 件分の Etsy 商品リスト、自社設計の機械図面 PDF を全部投入する、という運用が現実的に可能だ。

しかし、コンテキストが長くなるほど「Lost-in-the-middle」と呼ばれる劣化が現れる。Gemini Lab の検証によれば、LLM は文書の前後に置かれた情報には強い注意を向ける一方、中央に埋もれた情報は見落としやすい。Gemini 1.5 Pro 時代の NIAH（Needle In A Haystack）テストでは 1M token でも 99% の精度を出したが、これは「埋め込まれた針を探す」単純タスクの結果で、複雑な推論を要求する実務では中央情報の見落としが起きる。

対策は配置にある。公式と実務両方の推奨は次の 3 パターンだ。

パターン順序適性
質問先置きQuestion → Document短い質問、文書から答えを抜き取る検索的タスク
サンドイッチQuestion → Document → Question中央埋没を抑える複雑推論タスク
文書先置きDocument → Question短い文書、Claude / GPT で慣れた形式

Claude や ChatGPT で慣れた「文書を先に出して最後に質問」というスタイルは、Gemini の長文脈では弱い。質問を先頭に置いて、モデルが「何を探しているか」を知った状態で文書を処理する方が、中央情報の取りこぼしを減らせる。

もうひとつ重要なのが Context Caching だ。1M token を毎回再送するとコストが嵩むが、Gemini Developer API は同一文脈を再利用する Context Caching を提供している。たとえば「自社の設計マニュアル 200 ページを毎回コンテキストに入れる」というワークフローなら、マニュアル部分をキャッシュ化することで再送料金を削減できる。長文脈と低コストを両立させる事実上の前提だ。

Context Caching の課金体系は通常の入力単価より割安に設定されており、キャッシュ保持時間も指定できる。1 時間保持と 24 時間保持では料金が異なるため、ワークフローに応じた設計が必要になる。たとえば日中の業務時間内のみ使うアシスタントなら 8 時間保持、24/7 で参照する設計マニュアルなら 24 時間保持＋自動更新といった具合だ。

Lost-in-the-middle 対策として「重要な指示は冒頭と末尾に置く」というシンプルなルールも効く。長大な文書を渡した後に「ところで、上記の文書から X を抽出して」と末尾に質問を置くだけで、中央埋没を回避できる場合がある。Question→Document→Question のサンドイッチ配置は、この経験則を構造化したものだ。

Deep Think Mini を引き出す指示文

Gemini 3.1 Pro 完全ガイドで扱った通り、Gemini 3.1 Pro の HIGH モードでは Deep Think Mini が活性化し、出力前に内部で複数の推論経路を展開する。問題は「いつ HIGH を使い、いつ MEDIUM / LOW で十分か」の見極めだ。

公式は「明示的に Chain-of-Thought を書かせるな」と注意するが、これは「考えさせない」という意味ではない。Gemini 3 系列はそもそも内部で考えるので、追加の指示は冗長化につながる。代わりに、問題の性質を率直に伝えれば、適切な思考深度を自分で選ぶ設計になっている。

実務でのコツは次のとおりだ。

  • 「この問題には複数の前提条件があり、それぞれの影響が他に波及する。すべての制約を考慮した提案を出してほしい」と書くと、HIGH モードを呼び出す価値が出る
  • 「短く 3 件挙げて」と書けば、LOW モードで十分応答する
  • temperature は 1.0（デフォルト）のまま使う。Gemini 3 系列は temperature 1.0 で推論性能が最大化されるよう調整されており、Claude や旧 GPT で良かった「temperature 0 で決定的に」というアプローチは Gemini では逆効果になる場合がある

HIGH モードに頼りすぎる失敗もある。Thinking token は出力単価と同じく 1M あたり 12 USD（約 1,890 円）課金されるため、長い熟考を連発するとコストが急速に上がる。「思考の質が必要な要所だけ HIGH、それ以外は MEDIUM / LOW」という切り替えを徹底すること。これは Gemini 3.1 Pro 完全ガイド で書いた「Pro / Flash の使い分け」と相似形だ。

たとえば 100 件の Etsy 商品説明文を生成する一連のリクエストを HIGH モードで回すと、Thinking token だけで数千円規模になりうる。同じタスクを LOW モードに切り替えれば、品質を実質的に落とさずにコストを 5 分の 1 以下に圧縮できる。ループ処理では特に、モデルとモードの組み合わせがコスト構造を決定づける要因になる。

逆に、たった 1 件の重要設計判断（たとえば 50 万円の業務用 3D プリンタの選定）については、HIGH モードで Deep Think Mini を回す価値は十分にある。1 リクエストの thinking cost が数十円増えても、判断ミスのコストに比べれば桁違いに安い。「1 件の重要判断には豪勢に思考時間を投じ、100 件の量産タスクには思考を絞る」という濃淡が、Gemini プロンプト運用の経済合理性を生む。

システム指示（system_instruction）の設計

API レベルで強力なのが system_instruction フィールドだ。これは API リクエスト毎に送信される「前置き」で、対話ターン数にカウントされず、ユーザーメッセージとは別に処理される。

公式の典型例は「You are a cat. Your name is Neko.」だが、業務利用ではもっと具体的に書く。たとえば 3D プリント業務向けに次のようなシステム指示を組むと、毎回のプロンプトを短く保てる。

あなたは 3D プリンティング業務の専門アシスタントだ。回答は日本語、技術的根拠を必ず明示し、推測には『推測』のラベルを付ける。コードを返すときは 4 スペースインデントで囲み、JSON を返すときは厳密にスキーマを守る。Klipper / OrcaSlicer / Bambu Studio の文脈を前提として良い。

このような system_instruction を一度設定すれば、ユーザープロンプトは「printer.cfg のレビュー」程度に短くできる。Antigravity や Gemini CLI のような OSS ツールでは、リポジトリ直下に置く GEMINI.md が同じ役割を果たす（第三者解説中心の規約だが、Gemini CLI 公式 docs でも参照されている）。Claude Code の CLAUDE.md、ChatGPT の Custom Instructions と並ぶ「ツール固有のシステム指示ファイル」として扱うとよい。

実用上の注意点として、システム指示に「絶対にXをするな」のような強い否定指示を入れると、Gemini はその指示を過剰に解釈して基本的な論理を放棄することがある。公式ドキュメントは「do not infer のような open-ended な否定指示は逆効果になりうる」と明記している。否定よりも「提供された情報に基づいて答えよ」「不明な場合は不明と書け」のような肯定指示の方が安定する。

マルチモーダル — 画像・PDF・動画の渡し方

Gemini プロンプトで見落とされがちな強みがマルチモーダルだ。Gemini 3.1 Pro は画像・PDF・音声・動画を直接受け取り、最大 2 時間の動画を 1 リクエストで処理できる。3D プリント業務での実用シナリオは次のように整理できる。

入力用途
設計図 PDF寸法抽出、変更履歴コメント生成
3D スキャン後の点群スクリーンショット欠損部位の判定、補正方針の提案
プリント中のタイムラプス動画失敗箇所の特定、ノズル詰まり時刻の抽出
製品撮影写真Etsy 商品説明文の自動生成、被写体識別

動画プロンプトでは時間範囲を指定できるのが強い。「5:30 から 8:00 の間に何が起きたか要約して」と書けば、Gemini はその区間だけを精緻に分析する。プリント失敗のタイムラプス映像を AI に解析させて、何時何分に何が起きたかをログ化するワークフローが現実的になる。

画像プロンプトでは「分析せよ」のような曖昧形は禁物だ。「この画像のサポート構造のうち、剥離リスクが高い箇所を 3 つ指摘せよ」のように、観察対象と出力点数を明示する。これも本記事冒頭の Role + Goal + Constraints + Examples + Output format の構造に沿う。

PDF を渡すときには、構造化された設計図面と単純テキストの PDF で扱いが変わる。図面 PDF は画像として処理されるため、寸法線や注記を読み取らせるには「左下の組立図において、寸法線が示す値をすべて抽出し、表で返せ」のような具体的な観察対象指定が必要だ。一方、テキスト中心の PDF（仕様書、研究論文）は OCR を経たテキストとして扱われ、純粋に長文脈の問題として処理される。

音声入力もマルチモーダルの一部だが、メイカー業務では使いどころが限られる。プリンタの異音録音から機械的不具合を推定する、といったニッチな用途はあるが、現実的には Whisper でテキスト化してから Gemini に渡す方が安定する。Gemini の音声処理能力は Claude や ChatGPT の最新モデルと比べて特別な優位性はない。

Few-shot examples の使い方と限界

Examples（例示）はプロンプトを強化する古典的技法だが、Gemini 3 系列では使い方が変わる。旧モデルなら 5〜10 件の例を入れて学習させる手法（few-shot）が有効だったが、Gemini 3.1 Pro は内蔵の推論能力が高いため、例示は 1〜2 件で十分、それ以上はノイズになりがちだ。

効く例示の書き方は次のとおりだ。

  1. 例は「入力 → 出力」のペアで明確に区切る
  2. 例の出力形式は実際のタスクで期待する形式と完全に一致させる
  3. 例の数は 1 件か 2 件にとどめる
  4. 例の品質はゴールド標準にする（曖昧な例はモデルを混乱させる）

例を入れる代わりに、Output format で厳密にスキーマを定義する方が効くケースも多い。「JSON Schema を渡して additionalProperties: false で固定」「Markdown 表のヘッダーを明示的に書いて埋めさせる」といったアプローチが、例示より強力に出力を制御する。

失敗テンプレート — 旧時代の遺物

最後に、Gemini プロンプトで頻発する失敗テンプレートを挙げる。これらは Claude や ChatGPT で機能していたが、Gemini 3.1 Pro では逆効果になる。

  1. 「ステップバイステップで考えて」と書く: Gemini 3 系列は標準で考える。明示すると over-analyze になる
  2. 「あなたは X 業界で 20 年のキャリアを持つ専門家です」と過剰な役割設定: 短く「あなたは X の専門家だ」で十分
  3. 「絶対にハルシネーションを起こさないでください」: 否定指示は逆効果。「不明な場合は不明と書け」が正解
  4. 「以下の文書を読んで質問に答えてください」と Document → Question 配置: Question → Document か サンドイッチ配置を推奨
  5. 「temperature 0 で精緻に」: Gemini 3 は temperature 1.0 が公式推奨
  6. 「3 回考え直してから答えてください」: モデルは自分で考える。冗長な指示は不要

これらの失敗を取り除いて、Role + Goal + Constraints + Examples + Output format の 5 要素を簡潔に渡すだけで、出力品質は劇的に変わる。Gemini プロンプトは短く、構造的に、実行エンジンへの指令として書くのが正解だ。

逆に Claude プロンプトを Gemini に流用するときは、丁寧な前置きと安全配慮の修飾語を削るだけでも顕著に改善する。「申し訳ありませんが」「念のためお伺いしますが」「以下の点について慎重にご検討の上」といった日本語の婉曲表現は、Gemini にとってはノイズに近い。直接「青線の傾向は？」と聞く方が応答が速く、深い。これは礼儀を欠くという話ではなく、ツールごとに最適化された語法を使い分ける、というプロフェッショナルな運用態度の問題だ。

プロンプト最適化は習慣で身につく技能だ。書いたプロンプトのうち、どの一行が応答品質に効いたかを観察し、効かない一行を削っていく。この削減プロセスを繰り返すことで、自分の業務に最適化された短い指令の型ができあがる。長く書くほど偉い、と感じる古い感覚を、Gemini 時代に持ち込まないようにしたい。

まとめ — メイカーが今夜から書き換えるべき 5 行

本記事の要点を、明日からプロンプトを書き換えるための 5 行に圧縮する。

  1. Role / Goal / Constraints / Examples / Output format の 5 要素を 200 トークン以内に詰める
  2. Question → Document → Question のサンドイッチ配置で Lost-in-the-middle を回避する
  3. HIGH モードは要所だけ、定常タスクは MEDIUM / LOW を選ぶ
  4. system_instruction（または GEMINI.md）で前提情報を固定し、毎回のプロンプトを短く保つ
  5. 「ステップバイステップで考えて」「絶対に X するな」「temperature 0」は今夜消す

翌日公開のNotebooks in Gemini × NotebookLMは NotebookLM × Gemini Notebooks 統合の実践に入る。1M token のコンテキストを「毎回再送するか、ノートブックに常駐させるか」の選び方が、ワークフロー設計の次の論点になる。

参照

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】
ABOUT ME
swiftwand
swiftwand
AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.
Recommend
こちらの記事もどうぞ
記事URLをコピーしました