| name | gemini3-prompt-optimizer |
| description | 特殊改善: 汎用的なLLMプロンプトをGemini 3(3.0/3.1)で最高性能が出る形式に変換・最適化するスキル
|
Gemini 3 Prompt Optimizer
汎用プロンプトをGemini 3で最大性能を引き出す形式に変換するスキル。
なぜ変換が必要か
Gemini 3は「reasoning model」として設計されており、旧世代モデルや他社モデル向けのプロンプト手法が逆効果になることが多い。Google公式ドキュメントは「冗長で過度に複雑なプロンプトエンジニアリング技法を過剰分析する可能性がある」と明言している。つまり、Gemini 3には専用の設計思想でプロンプトを書く必要がある。
なお、Gemini 3の知識カットオフは2025年1月である。それより新しい事実が必要なプロンプトでは、Google Search groundingなどのツール利用を前提とした設計に切り替える必要がある。
変換の基本方針
Gemini 3のプロンプト設計は3つの柱に集約される:
- 短く、直接的に書く — 装飾・おだて・儀式的文言を削ぎ落とす
- 構造で意味を伝える — XMLかMarkdownを一貫して使い、役割・制約・文脈・タスクを明示分離する
- モデルの思考に任せる — thinking levelを信頼し、手動CoTを書かない
変換ワークフロー
入力プロンプトを受け取ったら、以下の手順で変換する。
Step 1: 入力プロンプトの分析
元のプロンプトを読み、以下を特定する:
- 目的: このプロンプトは何を達成しようとしているか
- 構造タイプ: system prompt / user prompt / マルチターン設計 / エージェント指示
- 出力形式: 自由文 / JSON / コード / 表 / その他
- アンチパターン: 後述の除去対象パターンに該当するものを列挙
Step 2: アンチパターンの除去
以下のパターンを検出したら除去または書き換える:
| アンチパターン | 対処 |
|---|
| 「あなたは世界最高の〇〇です」等のおだて | 削除。Gemini 3は説得より直接性を好む |
| 「深呼吸して」「ステップバイステップで考えて」等の儀式的CoT | 削除。thinking levelに委ねる |
temperature=0 や低temperature指定 | 削除。Gemini 3はデフォルト1.0が最適。下げるとループや性能低下が起きる |
| 長い背景説明や動機づけ | 目的を1-2文に圧縮 |
| XMLとMarkdownの混在 | どちらか一方に統一 |
| 「推論するな」「推測するな」の全面禁止 | 「提供された文脈だけを使って推論せよ」に書き換え |
| プロンプト前半の否定制約・文字数制限 | プロンプト末尾に移動 |
| 長文脈の先頭に質問を配置 | データ→質問の順に並べ替え |
| JSONを自然言語ルールだけで縛る | Structured Outputs推奨を注記 |
| ペルソナの過度な装飾 | 行動制約として再構成 |
| 「詳しく」「できるだけ」等の曖昧な出力指定 | 具体的な観点・項目数・文字数で指定 |
| 「この画像について教えて」等の曖昧なモダリティ参照 | 具体的なモダリティ要素 + 具体的な質問に書き換え |
| 「不確かでも答えて」「必ず回答して」等の回答強制 | 「不確かなら『不明』と答えよ」に書き換え。Gemini 3は幻覚を自信満々に生成する傾向がある |
| 「ユーザーに寄り添って」等の過度な追従促進 | 「根拠に基づき、反論すべき時は根拠を示して反論せよ」に書き換え |
| 「カニは架空の生き物」等の現実と矛盾する仮想前提 | Gemini 3は訓練データの世界知識に強く固執し、反事実的仮定を維持できない。ロールプレイ/世界構築では「以下の設定を絶対的ルールとして扱え」と強く宣言し、矛盾が出たら設定を優先するよう明示 |
| 要約で「簡潔にまとめて」だけの指示 | 「原文の主要事実をすべて含め、網羅性を優先」を追加。Gemini 3は物語性を優先し事実を落とす傾向がある |
| ツール利用プロンプトで検索の実行を暗黙に期待 | 「必ずツールを実行し、推測で検索結果を生成するな」と明示 |
| エージェント指示で議論と実装を区別しない | 「議論モード/実装モード」を明示分離 |
Step 3: Gemini 3最適化の適用
分析結果に基づき、以下のテクニックを適切に適用する。詳細は references/conversion-rules.md を参照。
3.1 構造化
- XMLタグ(
<role>, <context>, <task>, <constraints>, <output_format>)またはMarkdown見出し(混在禁止)でセクションを分離
- 選択基準: API/プログラム用途→XML、人間が読む/編集する→Markdown
3.2 配置の最適化
- コンテキスト優先: 長い入力データは先頭に、質問・指示は末尾に
- 制約は末尾: 否定制約、文字数制限、フォーマット指定はプロンプトの最後に配置
- アンカー句追加: 「Based on the entire document above...」「上記の全情報に基づき...」
3.3 Grounding(根拠付け)
- 外部知識の混入を防ぎたい場合: 「提供された文脈だけを唯一の情報源として使用」と明示
- 情報不足時の挙動: 「明示されていない情報は『情報なし』と回答」と指定
3.4 Split-Step Verification(分割検証)
- 情報の存在や正確性が不確実な場合: 検証フェーズと生成フェーズを分離
- テンプレート: 「Step 1: 検証可能か判定。Step 2: 検証できた場合のみ回答。不可なら『情報不足』で終了。」
3.5 出力制御
- Gemini 3はデフォルトで簡潔に回答する。会話的・詳細な応答が必要な場合のみ明示指定
- JSON出力は Structured Outputs (
response_mime_type, response_json_schema) を優先推奨
3.6 Thinking Level推奨
- Gemini 3は
thinking_level: highがデフォルト(指定なしで自動適用)。元プロンプトにCoTの指示があった場合は削除するだけでよい。明示的にhighを指定する必要はない
- 単純タスクには
thinking_level: low + think silently を提案し、レイテンシを削減
- CoTを削除してデフォルトに任せるのが公式推奨の移行パス
3.7 Explicit Planning(明示的計画)
- 複雑なタスクで「よく考えて」のような抽象的指示がある場合、具体的なチェック項目に置き換える
- Gemini 3は reasoning model なので、抽象的な「考えろ」は冗長なだけだが、「何を点検するか」を列挙すると精度が上がる
- テンプレート: 「最終回答の前に: 1. サブタスク分解 2. 情報不足判定 3. 制約違反チェック 4. 最終回答」
3.8 Function Calling時の注意
- 元プロンプトがFunction Calling / ツール利用を含む場合、thought signaturesの取り扱いに注意を促す
- Gemini 3のFunction Callingでは、thought signaturesを会話履歴にそのまま返送しないと4xxエラーになる。公式SDKは自動処理するが、REST APIや履歴の手動編集では注意が必要
- この注意事項を変更サマリーに含める
3.9 Few-shot例の整備
- 元プロンプトに例がある場合: フォーマットを統一し、2-4個に厳選
- 例がない場合: 分類・抽出・リライト系タスクでは追加を推奨
3.10 幻覚防止(Hallucination Defense)
- Gemini 3はRLHFの影響で「知らない」と答えるのを避け、もっともらしい偽情報を自信満々に生成する傾向がある
- 対策: 明示的な「不明時の脱出路」を設ける — 「不確かな場合は『確認できません』と答えること。嘘は失敗とみなす」
- 法務・医療・学術レビュー等、偽陽性コストが高いドメインでは特に重要
- Split-Step Verification(3.4)と組み合わせると効果的
3.11 追従性対策(Anti-Sycophancy)
- Gemini 3はユーザーの期待に合わせて意見を曲げる傾向が強い(「膨大な知能だが背骨がない」と評されている)
- 対策: 「根拠に基づく回答を優先し、ユーザーの前提が誤っている場合は根拠を示して指摘せよ」と明示
- 特にレビュー・分析・評価系タスクでは、「問題がなくても問題があると偽るな」「問題があるなら率直に指摘せよ」の両方を書く
- マルチターンでの注意: 追従性はターンを重ねると急激にエスカレートする。7ターン以内に立場を180度転換した報告がある。マルチターン設計では「前回の回答と矛盾する場合は矛盾を明示せよ」「ユーザーの圧力でなく根拠の変化でのみ意見を修正せよ」と明記する
3.12 エージェントモード分離
- コーディング/エージェント用途では、「質問=議論」と「指示=実装」を取り違える傾向がある
- 対策: system promptに「ユーザーが質問している場合は議論で返す。明示的な実装指示がある場合のみコード変更を行う」と書く
- ツール利用時: 「検索結果を推測で生成するな。必ず実際にツールを呼び出せ」と明記(Gemini 3は検索をシミュレートする傾向がある)
- カスケード崩壊の防止: Gemini 3は存在しないAPIをでっち上げた上にエラーを直そうとして更に壊していく「カスケード崩壊」を起こしやすい。コーディングエージェントでは「エラーが2回連続で解決しない場合は立ち止まってユーザーに報告する」「存在を確認できないAPIやメソッドは使わない」と明記する
Step 4: 出力の生成
変換後のプロンプトを以下の形式で提示する:
- 変換後プロンプト — そのまま使える完成形
- 変更サマリー — 何を変えたか、なぜ変えたかの簡潔な一覧
- パラメータ推奨 — temperature、thinking level等のAPI設定推奨値
- 追加提案(該当する場合のみ):
- Structured Outputs利用(JSON出力系)
- Google Search grounding(知識カットオフ2025年1月以降の情報が必要な場合)
- few-shot追加(分類・抽出・リライト系)
- Function Calling利用時のthought signatures注意
変換の判断基準
すべてのテクニックを常に適用するわけではない。入力プロンプトの性質に応じて判断する:
- 短い単発プロンプト: アンチパターン除去 + 構造化は軽めに。過度な構造化は逆効果
- System Prompt / エージェント指示: 構造化を積極適用。行動制約として再構成
- RAG / 文書QA: Grounding + 末尾制約配置 + アンカー句が特に重要
- データ抽出: Schema指定 + Structured Outputs推奨
- コード生成 / 分析: thinking level推奨 + explicit planning指示の追加
- マルチモーダル: モダリティの明示参照 + media_resolution設定の推奨(画像: high, PDF: medium, 動画: low/medium)
- Function Calling / エージェント: thought signatures注意 + system instructionsを「行動規約」として設計 + 議論/実装モード分離 + 検索シミュレーション防止 + カスケード崩壊防止(エラー時の停止条件明記)
- 法務・医療・学術等の高信頼性ドメイン: 幻覚防止を最優先。Split-Step Verification + 明示的な「不明」脱出路 + 追従性対策
- 要約・シンセシス: 網羅性指示を追加。物語性より事実の完全性を優先する指示
- ロールプレイ・世界構築・反事実的前提: Gemini 3は訓練データの世界知識に強く固執し、「カニは架空の生き物」のような現実と矛盾する仮定を維持できない。「以下の設定を絶対的ルールとして扱え」と強く宣言し、矛盾が出たら設定を優先するよう明示
リファレンスファイル
詳細な変換ルール、アンチパターン辞典、用途別テンプレートは以下を参照:
references/conversion-rules.md — 変換ルールの詳細解説と判断基準
references/anti-patterns.md — 検出すべきアンチパターンの網羅的リスト(with 変換前/後の例)。Gemini 3特有の幻覚・追従性・検索シミュレーション問題への対策パターンも含む
references/templates.md — 用途別の最適化済みテンプレート集。高信頼性ドメイン向け防御的テンプレートも含む
変換に迷った場合や、特定のユースケースでの最適な構成を確認したい場合にこれらを読む。