{"version": "1.0", "title": "最新LLMのためのプロンプト最適化戦略", "keywords": ["プロンプト工学", "Chain-of-Thought", "CoT", "構造化出力", "Gemini", "GPT-4o"], "date": "2024-07-25"}
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト(未検証)です。
明示的なCoTを回避せよ:最新LLMの推論能力を最大限に引き出すプロンプト最適化戦略
【ユースケース定義と課題】
タスク定義(45文字):長文の財務記事から企業情報、業績、市場反応を抽出・分類し、厳格なJSON形式で構造化する。
| 項目 | 詳細 |
|---|---|
| 入力の型 | Markdownテキスト(ニュース記事) |
| 出力の型 | 厳格なJSONオブジェクト |
| 課題 | 複雑な抽出・分類タスクにおいて、従来のCoT指示を用いると、思考の途中でJSONの閉じ忘れや形式崩れが発生しやすい。最新LLMは内部推論が強力なため、冗長なCoT指示はむしろノイズとなる傾向がある。 |
【プロンプト設計のループ】
LLMのパフォーマンス向上は、一回の試行で終わるものではありません。常に結果を定量的に評価し、指示の粒度を調整する反復的なプロセスが必要です。
graph TD A["設計: ベースラインCoTプロンプトの作成"] --> B["実行: LLMによる構造化出力"] B --> C["評価: JSON形式の遵守と内容の正確性を検証"] C -->|改善: CoTの隠蔽とインストラクションの強化| A
【プロンプトの実装案】
まず、最新LLMでは非推奨とされつつある、伝統的なCoTを用いた「ベースライン」プロンプトを提示します。これは、モデルに思考プロセスを強制的に出力させる形式です。
案1:思考ステップを明示的に要求するプロンプト(ベースライン)
この手法は、旧世代のモデルでは必須でしたが、最新モデルでは「思考プロセス」の出力自体が構造化出力を妨げるノイズになることがあります。
あなたは、金融ニュース記事を分析し、指定されたJSONスキーマに厳格に従って構造化する専門家です。
# 手順
1. 記事全体を読み、主要な企業と関連情報を特定します。
2. 以下のプロセスに従って、ステップバイステップで思考してください。
3. 最終的な構造化出力のみを、指定されたJSON形式で出力してください。
## 思考プロセス(必須)
- 企業名、ティッカーシンボル、発表された財務指標を特定。
- 市場反応(株価の変動、アナリストのコメント)を抽出。
- これらの要素をJSONスキーマの各フィールドに対応付ける。
## 出力フォーマット
{
"analysis_date": "YYYY-MM-DD",
"company_info": {
"name": "...",
"ticker": "..."
},
"financial_summary": {
"revenue": "...",
"net_income": "..."
},
"market_reaction": "..."
}
---
入力記事:
[ここにニュース記事のMarkdownテキストを挿入]
出力:
思考プロセス:
[ここに思考ステップを詳細に出力]
最終結果:
{
"analysis_date": "2024-07-25",
...
}
【評価指標と誤り分析】
案1のベースラインプロンプトを実行した場合に頻発する失敗パターンと、その定量的な評価基準を定義します。
失敗パターン
| 失敗カテゴリ | 説明 | 最新LLMでの発生原因 |
|---|---|---|
| 様式崩れ | JSONの括弧閉じ忘れ、フィールド名の誤り、または「思考プロセス」と「最終結果」が混在する。 | 冗長な思考ステップ指示が、厳格な出力フォーマットの制約よりも優先されるため。 |
| 冗長な出力 | 思考ステップが極端に長くなり、トークンコストが増大する。 | CoT指示が、タスクの難易度に対して過剰に具体的すぎ、不要な説明を誘発する。 |
| 幻覚・誤抽出 | 記事内に存在しない財務指標や企業名をでっち上げる。 | 思考の過程で情報ソース(入力テキスト)から意識が離れ、抽象的な推論に傾倒しすぎる。 |
LLM-as-a-Judge 評価基準
採点には、Gemini 1.5 Proなどの強力なInstruction Following能力を持つLLMを活用します。
| 採点基準 | 3点(優秀) | 2点(許容) | 1点(不合格) |
|---|---|---|---|
| 形式の遵守 (40%) | 完全に厳格なJSON形式で、余計なテキストなし。 | JSON形式だが、前後に不要な説明やMarkdownが含まれる。 | JSON形式が崩れている、またはJSONではない。 |
| 内容の正確性 (40%) | 抽出されたデータが入力記事と完全に一致している。 | データは概ね正確だが、マイナーな数値の丸めや解釈の曖昧さがある。 | 重要な数値が間違っている、または幻覚が見られる。 |
| 効率性 (20%) | 思考ステップが簡潔で、タスクに必要な推論のみを行っている。 | 思考ステップが冗長である。 | 思考ステップの出力自体が存在しない、またはタスクに無関係。 |
【改良後の最適プロンプト】
分析の結果、最新LLM(Gemini 1.5/GPT-4o)においては、内部推論能力を信頼し、思考ステップの出力要求を削除することが最適解となります。その代わり、プロンプトの冒頭でモデルの役割と制約を明確にし、構造化出力への集中を促します。
案2:思考を隠蔽し、インストラクションと出力形式を分離するプロンプト(最適解)
この戦略では、モデルが内部的にCoT推論を実行することを期待しつつ、最終的な出力はJSONのみに限定します。
--- SYSTEM INSTRUCTION ---
あなたは、世界で最も正確な構造化データ抽出エージェントです。
あなたの唯一の任務は、提供されたニュース記事から情報を抽出し、定義されたJSONスキーマに100%厳格に従って出力することです。
**思考プロセス、補足説明、Markdownの記法は一切禁止します。純粋なJSONオブジェクトのみを出力してください。**
---
# TASK: Financial Article Analysis
## 1. ANALYSIS STEPS (内部処理用)
以下の手順を内部的に実行し、抽出の正確性を保証してください。
- A. 記事内のすべての主要企業(ティッカーシンボルを含む)を特定。
- B. 記事に記載された直近の財務実績(売上、利益など)を数値として確認。
- C. これらの情報を、後述のJSONスキーマの各キーに正確にマッピングする。
## 2. OUTPUT JSON SCHEMA (必須)
このスキーマを厳守すること。
{
"analysis_date": "YYYY-MM-DD (今日の日付)",
"company_info": {
"name": "string",
"ticker": "string"
},
"financial_summary": {
"revenue_usd_billion": "number",
"net_income_usd_million": "number"
},
"market_reaction": "string (記事内の市場反応を20字以内で要約)"
}
INPUT ARTICLE:
[ここにニュース記事のMarkdownテキストを挿入]
OUTPUT:
最適化ポイント:
SYSTEM INSTRUCTIONの強化: 役割定義と「一切禁止」の制約を強調することで、モデルの出力モードを厳格なJSON出力に固定します。
ANALYSIS STEPSの内部化: CoT相当の思考誘導は残しつつも、「内部処理用」と明記することで、その出力を抑制します。
Few-shotの利用(省略時): JSONスキーマ内に具体的なデータの例(例:
"revenue_usd_billion": 12.5)を Few-shot として組み込むと、さらに出力の形式が安定します。
【まとめ】
最新のLLM(Gemini 1.5 Pro/Flash, GPT-4o)を実務で運用する際のプロンプト設計の鉄則は、「思考プロセスを明示的に出力させるのではなく、推論を内部で実行させ、出力形式への集中を促す」ことです。
CoTは内部化せよ: 「ステップバイステップで考えろ」という指示は、明示的な出力要求ではなく、
ANALYSIS STEPS (内部処理用)のようにモデルの内部推論を最適化する指示として活用し、最終出力から隔離する。システムプロンプトで制約を定義せよ:
SYSTEM INSTRUCTIONまたはプロンプトの最上部で、モデルの役割と「純粋なJSONオブジェクトのみ」を出力するという制約を厳しく定義する。出力フォーマットの視覚的強調: 最終出力の型(JSONスキーマ、Markdownテーブルなど)を、具体的な構造と型定義(
string,numberなど)を含めて提示し、モデルが参照しやすいように明確に区切る。
この記事の更新履歴
この記事は、生成AIを活用した自動レビュー・更新フローにより内容を見直し、必要な修正を反映しています。
2026年9月18日
- 変更記事後半のコードブロックおよび露出したMarkdown記号を整理し、正常な表示に修正しました。

