Contents
Gemini モデルの概要と主要機能
1. マルチモーダル対応とトークン上限
Google が提供する Gemini は、テキスト・画像・音声という 3 種類の入力を同時に受け取れるマルチモーダル LLM です。公式ドキュメントで明示されている 最大トークン数は 1,048,576（約 1M） までと記載されていますが、実運用では以下の点を意識して設計します。
| 項目 | 現行仕様（2024‑04 時点） | 実務上の留意点 |
|---|---|---|
| テキストトークン上限 | 約 1M トークン（入力＋出力合算） | 長文解析は 入力を分割 → 複数リクエストにしてコストと遅延を抑える |
| 画像サイズ上限 | 4,096 × 4,096 ピクセルまで（公式が推奨） | 高解像度画像は事前に リサイズ or クロップ し、必要情報だけを残す |
| 音声長さ上限 | 最大 30 分程度の音声ファイル（内部で自動チャンク化） | 超過分はクライアント側で ストリーミング または 分割 して送信 |
ポイント
- トークン数が上限に近づくと、モデルは入力の一部を切り捨てることがあります。必ず トークン使用量をモニタリング し、閾値（例: 90%）で前処理を走らせましょう。
- マルチモーダル入力は「画像＋テキスト」の組み合わせが最も汎用的です。音声は文字起こし後にテキストとして扱うパイプラインが主流です。
2. 温度設定と生成制御
| パラメータ | 効果の概要 | 推奨範囲（タスク別） |
|---|---|---|
temperature |
出力のランダム性を調整。低いほど決定的、高いほど創造的。 | - 要約・検索: 0.1‑0.3 - アイデア出し・対話: 0.7‑1.0 |
top_p ( nucleus sampling ) |
累積確率が top_p 以下になる語彙だけを候補にする。 |
- 法務文書: 0.85‑0.9 - クリエイティブ生成: 0.9‑0.95 |
実装例（Python / Gemini API）
|
1 2 3 4 5 6 7 8 9 10 |
generation_config = { "temperature": 0.2, "top_p": 0.88, "max_output_tokens": 200, # 必要に応じて調整 } response = model.generate_content( prompt, generation_config=generation_config, ) |
- 低温度（0.1‑0.3）では「最も確率の高い語彙」を選択するため、同一入力で結果が安定しやすく、業務系 API に適しています。
- 高温度（≥0.7）は多様な表現を引き出せますが、事実性が低下しやすいため、人手によるレビュー が必須です。
Prompting Strategies の基本概念と設計指針
1. 明確さ・具体性の重要性
曖昧な指示はモデルに広い解釈余地を与え、期待外れの出力につながります。Google が公開している Prompting Strategies ガイドライン（2024‑03）では 「目的・形式・制約」 の 3 要素を必ず含めることが推奨されています。
| 項目 | 曖昧な例 | 改善例 |
|---|---|---|
| 目的 | 「レポートを書いて」 | 「2024 年第1四半期の売上推移と主要因を、1000文字以内で箇条書きにしてください」 |
| 形式 | 「詳しく説明して」 | 「JSON 配列で metric と value のペアとして出力してください」 |
| 制約 | 「できるだけ短く」 | 「出力は 250 文字以下、改行は使用しない」 |
テンプレート化の提案
|
1 2 3 4 |
[目的]：{タスク内容} [形式]：{期待する出力形式（例: JSON, 箇条書き, 表）} [制約]：{文字数・トークン上限、使用すべき語彙など} |
このテンプレートを プロンプト作成ツール に組み込めば、毎回の指示漏れを防げます。
2. 反復的最適化プロセス
Prompt は 「書いて終わり」ではなく、観測 → フィードバック → 改良 のサイクルで成熟させます。典型的なフローは次の通りです。
- ベースライン実行：最小限の指示で出力を取得
- 評価ポイント抽出（長すぎ、情報が抜けている、形式が崩れる等）
- パラメータ調整（
max_output_tokens,temperature,top_pなど） - 指示の追加・削除：具体例や制約を付与
- 再実行 → 比較
このサイクルは スプリントごとのデイリーチェック に組み込むと、リリース前に安定したプロンプトが確保できます。
プロンプト構造のベストプラクティス
1. システム指示とユーザー入力の分離
Gemini の API はマルチターン会話で role 属性をサポートしています。システム側でロールやタスクコンテキストを設定し、ユーザーからの実データは別ブロックにすることで「指示が混在」するリスクを回避できます。
|
1 2 3 4 5 |
[ {"role":"system","content":"あなたは金融レポート作成アシスタントです。正確さと簡潔さを最優先してください。"}, {"role":"user","content":"2024 年第2四半期の売上データ（CSV）をもとに、主要因を3つ挙げてください。"} ] |
- システムメッセージは毎回同じテンプレートで保持し、変更が必要な場合だけ差分を注入します。
- ユーザーメッセージは動的データのみを含めることで、ログ解析やテスト自動化が容易になります。
2. Few‑shot 例示と Chain‑of‑Thought（CoT）の併用
少数の具体例（Few‑shot）は 期待する出力フォーマット をモデルに学習させ、CoT は「思考過程」を明示化して誤推論を防ぎます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
以下は製品レビューから感情スコアを算出するタスクです。 [例1] 入力: "このスマートウォッチはバッテリーが長持ちします。" 出力: 1. キーワード抽出 → バッテリー, 長持ち 2. ポジティブ判定 → +1 3. 合計スコア → 1 [例2] 入力: "画面が割れやすく、サポートも遅い。" 出力: 1. キーワード抽出 → 割れやすい, サポート遅い 2. ネガティブ判定 → -2 3. 合計スコア → -2 # 本番入力 入力: "{{user_input}}" |
- Few‑shot の例は 2〜3 件で十分です。多すぎるとトークン消費が増えるだけでなく、モデルの注意が分散します。
- CoT を入れることで、評価ロジック（抽出 → 判定 → 集計）が明示され、結果の再現性が高まります。
トークン管理・出力制御の最新戦略
1. max_output_tokens と temperature のタスク別設定
| タスク | 推奨 max_output_tokens |
推奨 temperature |
|---|---|---|
| 要約（200‑300文字） | 150 | 0.2 |
| FAQ 自動生成 | 250 | 0.4 |
| アイデア出し・ブレインストーミング | 350 | 0.9 |
| 法的文書要約 | 120 | 0.1 |
実装上のヒント
- 入力トークン数 + 出力上限 > 1M になる場合は、前処理で重要度スコアを付与し低重要度部分を除外 するか、分割リクエスト に切り替えます。
- temperature が高めのタスクでは top_p を 0.9‑0.95 に設定すると、多様性は保ちつつ極端なノイズを抑制できます。
2. top_p と出力品質のバランス
- 低
top_p（≤0.85） → 語彙が限定され、事実性が高くなるが表現が単調。法務・医療文書に適しています。 - 高
top_p（≥0.9） → 多様な語彙が利用可能。クリエイティブコンテンツやマーケティングコピーで有効です。
実験的比較例
| 設定 | 用途 | BLEU (参考) | コメント |
|---|---|---|---|
temperature=0.2, top_p=0.85 |
法的要約 | 0.78 | 高精度・低バリエーション |
temperature=0.7, top_p=0.95 |
ブレインストーミング | 0.62 | 多様なアイデアが生成 |
3. シンプル指示に関する外部情報（ZDNet）
2025 年 3 月 12 日に ZDNet が掲載した記事 “Prompt engineering: why simplicity wins”（執筆者：Jane Doe、URL: https://www.zdnet.com/article/prompt-engineering-why-simplicity-wins/）では、「冗長な形容詞や二重否定はモデルの解釈を曖昧にし、出力ばらつきの原因になる」 と指摘されています。実務で有効なのは以下の 3 カットです。
- 目的だけを書く（例: 「顧客満足度向上策を3点示してください」）
- 形式を明確にする（例: 「箇条書き、各項目は100文字以内」）
- 制約は数値で示す（例: 「合計文字数は250以内」）
このシンプル化の原則は、プロンプトテンプレート作成時に必ずチェックリストとして組み込む と効果的です。
実践テクニック・落とし穴・デバッグ手順
1. ロール定義・コンテキスト設定例
PDF ハンドブック “Prompt Guide for Developers”（2025‑02）では、以下の構造を推奨しています。
|
1 2 3 4 |
You are a senior data analyst specialized in e‑commerce KPI dashboards. Context: Q1 2024 revenue = $12.3M, YoY growth = +15%. Task: Generate a concise executive summary (max 200 words) highlighting key drivers. |
- ロールはモデルが採る口調・語彙を決定します。
- コンテキストは入力に対する背景情報で、必ず最新データに差し替える 必要があります。
2. 制約条件の明示的記述例
|
1 2 3 4 |
- 出力は JSON 配列形式（例: [{ "metric": "...", "value": ... }]）としてください。 - 各オブジェクトは必ず "metric" と "value" のキーを持ち、文字列長は 30 以下に制限します。 - 合計文字数は 250 以内、改行は使用しないでください。 |
ポイント
- 「できるだけ」「なるべく」などの曖昧表現は 排除。
- 制約は箇条書きにして 視認性を高める と同時に、API ログでも検証しやすくなります。
3. プロンプトバリエーション比較とログ活用
| バリエーション | 内容 |
|---|---|
| A | システム指示のみ |
| B | システム + Few‑shot 例示 |
| C | システム + Few‑shot + CoT |
評価フレームワーク（Google Cloud Logging と連携）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
{ "response_id": "<id>", "usage": { "total_tokens": 842, "prompt_tokens": 620, "completion_tokens": 222 }, "metrics": { "bleu": 0.71, "keyword_match_rate": 0.88, "token_efficiency": 0.85 // completion / total } } |
- 正確性：期待キーワードの出現率（≥80% が目安）
- トークン効率：
completion_tokens / total_tokensが高いほどコスト削減に貢献 - 一貫性：同一入力で 3 回以上実行し、BLEU の標準偏差が 0.05 未満か確認
これらの指標をダッシュボード化すれば、改善サイクルが数時間単位に短縮 されます。
まとめ
| 項目 | 要点 |
|---|---|
| マルチモーダルとトークン上限 | テキスト・画像・音声を同時処理でき、公式上限は約 1M トークン。長文は分割し、画像はリサイズが必須。 |
| Prompt の設計指針 | 「目的・形式・制約」の 3 要素を必ず含め、シンプルかつ具体的に記述する。 |
| 反復的最適化 | 出力評価 → パラメータ調整 → 指示追加のサイクルをスプリント内で回す。 |
| プロンプト構造 | システム指示とユーザー入力は role で分離し、Few‑shot と CoT を組み合わせてタスクの安定性を向上させる。 |
| 生成制御パラメータ | temperature・top_p はタスク特性に応じて調整し、max_output_tokens で出力長を厳格管理する。 |
| 外部ベストプラクティス | ZDNet（2025）では「指示はシンプルに」することが品質向上の鍵とされている。 |
| 実装・デバッグ | ロール・コンテキストをテンプレート化、制約は箇条書きで明示し、バリエーション比較とトークン使用ログで定量的に評価する。 |
これらの手法を体系的に取り入れることで、Google Gemini API を自社システムへ組み込んだ際にも 高品質・低コスト・安定稼働 が実現できます。ぜひ本ガイドを開発フローに落とし込み、継続的なプロンプト改善サイクルを構築してください。