Google のモデルファミリーである Gemini は、Gemini アプリ、Google AI Studio、Google Cloud の Gemini API から利用されています。プロンプティングの基本はそのまま当てはまります。このガイドでは、Google が公開しているプロンプト設計のガイダンスに沿って、Gemini に固有の点を扱います。
モデル名や制限は変わるので、ここでのアドバイスは安定した挙動に関するものです。現在のモデルについては Google のドキュメントを確認してください。
システム指示
Gemini API は、会話とは別にシステム指示を受け付けます。役割、常設のルール、出力の規約にそれを使い、タスクとそのデータはユーザーコンテンツに置きます。システムプロンプトとロールプロンプティングを参照してください。
Gemini アプリでは、保存した指示とカスタム Gem が同じ目的を果たします。Gem は、独自の常設指示を持つ再利用可能なアシスタントです。
few-shot の例を含める
この点について Google のガイダンスは明確です。可能な限りプロンプトに few-shot の例を含めることを勧め、例のないプロンプトは効果が低くなりやすいと述べています。実際には次のとおりです。
- 例は 2〜5 個で通常は足ります。多すぎると、モデルがそれらに過剰適合することがあります。
- 区切りや間隔を含め、すべての例で書式を同一に保つ。
- 避けるべきパターンではなく、従うべきパターンを示す。
- 意図したパターンだけが共通するよう、内容にバリエーションを持たせる。
Classify the request as question, complaint, or praise.
Text: "How do I export my data?"
Category: question
Text: "The app crashed twice during checkout."
Category: complaint
Text: "{{text}}"
Category:
上のように、プロンプトを期待する答えの書き出しで終えるのは、Gemini がうまく従う補完スタイルの手がかりです。詳しくは few-shot プロンプティングを参照してください。
一貫した構造を使う
Gemini は、指示、文脈、入力を分けるのに、XML 風のタグや Markdown の見出しで機能します。1 つのスタイルを選び、プロンプト全体で一貫して使います。スタイルを混ぜると境界が分かりにくくなります。
プレフィックスも軽量な構造のひとつです。Text:、Category:、JSON: のようなラベルが、各部分が何であるか、次に何が来るべきかを示します。
長い文脈：質問は最後
Gemini のモデルは、長いドキュメント、コードベース、数時間の音声や動画を含む、非常に大きな入力を受け付けます。その能力を使うときは次のようにします。
- 質問や指示を資料の後に置く。 長い文脈に関する Google のガイダンスは、クエリを末尾に置くことです。
- 収まるからというだけで資料を含めない。 無関係な文脈はお金がかかり、注意を薄めることがあります。トークン最適化を参照してください。
- 複数のリクエストで再利用する大きなコンテンツには、コンテキストキャッシュを使う。
マルチモーダルのプロンプティング
Gemini は、テキスト、画像、音声、動画、PDF などのドキュメントを 1 つのプロンプトで受け付けます。いくつかの実践で結果が良くなります。
- 何を見るかを伝える。 「2 つ目のグラフで」「動画の 01:20 から 02:00 の間で」。
- 画像が 1 枚なら、その画像について尋ねるテキストの前に置く。
- 画像を丁寧に読み取る必要があるタスクでは、まず説明を求め、それから質問する。これは 2 段階のチェーンです。
- 読めないものへのルールを与える。 「値が判読できない場合は null を使うこと。」
- テキストの場合と同じく、出力形式を述べる。
The image is a photo of a utility bill. Extract the account number,
billing period, and amount due as JSON. Use null for any field you
cannot read with confidence.
構造化出力
コードがパースする出力には、レスポンスタイプを JSON に設定し、API でレスポンススキーマを渡します。応答はそのスキーマに制約されます。
- 値が固定されたフィールドには enum を使う。純粋な分類には、enum のレスポンスタイプも使えます。
- モデルがスキーマを読むので、スキーマ内でフィールドを説明する。
- スキーマは適度にシンプルに保つ。非常に大きい、または深くネストしたスキーマは、拒否されたり品質が落ちたりすることがあります。
- コード側で結果を検証する。
構造化出力のプロンプトを参照してください。
思考
現行の Gemini モデルは、応答の前に推論でき、その量を制御する設定があります。これらのモデルでは、目標と制約を述べ、モデルに計画させます。単純で大量のタスクでは設定を下げて遅延とコストを減らし、複数ステップの分析では上げます。思考が有効なときは、「ステップごとに考えて」という明示的な指示はほとんど効果を加えません。思考の連鎖プロンプティングを参照してください。
Google 検索によるグラウンディング
Gemini API は、応答を Google 検索の結果に根拠づけ、引用を返せます。最近の出来事や、変化する事実についての質問に使います。自分のデータから答える必要がある場合は、ドキュメントを自分で渡し、モデルにそれに基づいて答えさせます。RAG のプロンプティングを参照してください。
情報源が何であれ、与えた文脈に答えが含まれていないときの対応をモデルに伝えます。
関数呼び出し
ツールは、名前、説明、パラメーターのスキーマで宣言します。どのモデルでも同じで、モデルがいつ呼び出すかを決めるのに使うのは説明です。目的、パラメーター、戻り値を具体的に書きましょう。AI エージェント向けのプロンプトを参照してください。
サンプリング設定
抽出や分類のように一貫性が必要なタスクでは、温度を低くするのが通常のアドバイスです。最近の一部の Gemini モデルに関する Google のガイダンスは、温度を既定のままにすることです。下げるとループや推論の弱まりが起こりうるためです。変更する前に、使用するモデルのドキュメントを確認してください。
トークン数
Gemini にはトークン数を数える API メソッドがあり、マルチモーダル入力もトークンで数えられ、画像、音声、動画にはそれぞれ独自のレートがあります。オフラインのトークナイザーはないため、PromptFlowEngine は Gemini の数値を「近似」と表示します。予算には API の数値を使ってください。
Gemini アプリでのプロンプティング
- 繰り返すタスクのために Gem を作り、その指示を一度だけ書く。
- 貼り付ける代わりに、ファイルを添付するか、関連する Google Workspace のソースを接続する。
- 形式を頼む：表、リスト、語数制限。
- 話題が変わったら新しいチャットを始める。
- 認証情報や顧客データをチャットに入れない。
PromptFlowEngine の Chrome 拡張機能は Gemini の中で動作します。プロンプト欄の下書きを分析して再構成し、シークレットが含まれていると警告します。
Gemini でよくある間違い
| 間違い | 起こること | 対策 |
|---|---|---|
| 例がない | 形式とスタイルがぶれる | 一貫した例を 2〜5 個加える |
| 長いドキュメントの前に質問を置く | 資料の活用が弱まる | 質問は最後に置く |
| タグと見出しのスタイルを混ぜる | 境界がぼやける | 1 つを選んで守る |
| 曖昧なマルチモーダルの依頼 | 一般的な説明になる | 何を見るか、何を返すかを伝える |
| 文章だけで JSON を頼む | ときどき無効な出力が出る | レスポンススキーマを使う |
| 入れられるからとウィンドウを埋める | コスト増、焦点の希薄化 | タスクに必要なものを送る |
Gemini のプロンプトを最適化する
- 常設のルールをシステム指示に移す。
- タスクを述べ、一貫した例を加える。
- 長い資料を先に、質問を最後に置く。
- コードが読む出力は、スキーマで定義する。
- つなぎの言葉と繰り返しを取り除き、再テストする。
PromptFlowEngine のプロンプトオプティマイザーは最後のステップを検証付きで行い、プロンプトアナライザーは、何かを実行する前に出力形式の欠落を指摘します。
ChatGPT と OpenAI のプロンプティングガイドと Claude のプロンプティングガイドとも比較してみてください。