Chain-of-Thought (CoT) 活用による推論精度向上：複雑な多段階ロジックを解く最適プロンプト設計

Tech

[META-DATA] topic: 高度なプロンプトエンジニアリング method: Chain-of-Thought (CoT) / 思考タグ target_llm: Gemini 1.5 Pro / GPT-4o audience: プロンプトエンジニア, AI開発者 status: ドラフト [/META-DATA]

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

Chain-of-Thought (CoT) 活用による推論精度向上：複雑な多段階ロジックを解く最適プロンプト設計

【ユースケース定義と課題】

ユースケースと課題: 複雑なビジネスルールに基づき、段階的な推論を経て、最終的な意思決定（予算配分）を根拠付きで厳密なJSON形式で出力させる。単なるキーワード抽出ではなく、条件分岐を伴う論理的思考が求められるため、中間ステップの誤りが最終結果の誤謬に直結する。

入出力の「型」の定義:

項目 型 詳細
入力 Markdown形式テキスト 予算制約、過去実績、KPI目標などのデータセット。
出力 JSON形式 決定された配分額、配分理由、サマリー。

【プロンプト設計のループ】

LLMを実務投入する際は、一発で完璧なプロンプトを作成するのではなく、必ず以下のPDCAサイクルを回します。特に複雑なタスクにおいては、初期プロンプトの「思考プロセス」を評価することが極めて重要になります。

graph TD
A["設計: CoTタグ導入"] --> B["実行: LLMに出力させる"]
B --> C["評価: 推論のロジックと出力形式を検証"]
C -->|改善: 思考の段階を強制/JSON Schemaを厳格化| A

【プロンプトの実装案】

複雑な推論タスクでは、Few-shot学習（少数の例示）とChain-of-Thought（思考過程の明示）を組み合わせたプロンプトが基本となります。ここでは、初期段階のプロンプトを提示します。

目的: マーケティング予算（$100,000）を3つのチャネル（Search Ads, SNS, Content Marketing）に配分する。

--- SYSTEM INSTRUCTION ---
あなたは高度な財務分析官です。ユーザーから提供された制約条件に基づき、予算配分を最適化してください。
処理中は必ず、<thinking>タグを使用して内部的な推論プロセスを記録してください。最終出力には<thinking>タグの中身を含めないでください。

--- FEW-SHOT EXAMPLE 1 ---
[INPUT]
総予算: $50,000
制約1: SNSへの配分は総予算の50%以下とする。
実績1: Search AdsはROIが高いが、上限があるため$20,000が最大効果。
実績2: Content Marketingは育成段階であり、最低$10,000を投下する。

<thinking>

1. 制約条件の確認: 総予算$50k。SNSは最大$25k。Search Adsは最大$20k。Content Marketingは最低$10k。

2. 必須投資額の確保: Content Marketingに$10kを配分。残り$40k。

3. ROI最大化: Search Adsに上限の$20kを配分。残り$20k。

4. 残りの配分: 残り$20kをSNSに配分。これはSNSの上限$25kを下回るため問題なし。

5. 検証: $20k (Search) + $20k (SNS) + $10k (Content) = $50k。
</thinking>

[OUTPUT]
{
  "total_budget": 50000,
  "allocation_summary": "ROIの最大化と育成チャネルの確保を両立。",
  "allocations": [
    {"channel": "Search Ads", "amount": 20000, "reason": "上限額までの最大効果確保。"},
    {"channel": "SNS", "amount": 20000, "reason": "残りの予算を配分。制約内。"},
    {"channel": "Content Marketing", "amount": 10000, "reason": "育成のための最低投下額を確保。"}
  ]
}

--- MAIN TASK ---
[INPUT]
総予算: $100,000
制約1: Search Adsへの配分は、総予算の60%を超えてはならない。
制約2: SNSは高い認知効果を持つが、ROIが低いため、最大でも$25,000に制限する。
実績3: Content Marketingは長期的な優位性確保のため、総予算の30%を最低保証する。

指示：この条件に基づいて最適な予算配分をJSONで出力してください。

【評価指標と誤り分析】

上記プロンプトを実行した場合、以下の失敗パターンが発生する可能性があります。特に、Few-shotで提示した構造（{channel: ..., amount: ...}）を維持できなくなる「様式崩れ」と、CoTの段階的な推論での「ロジックエラー」が深刻です。

特定の失敗パターン:

  1. ロジックエラー（推論の失敗）: 例示では正しく処理しているにもかかわらず、本番タスクで「Content Marketingの最低保証（$30k）」や「Search Adsの上限（$60k）」を無視する配分をしてしまう（例: Search Adsに$70kを配分）。

  2. 様式崩れ（JSONエラー）: 最終的なJSON出力に、誤ったデータ型（数値が文字列になる）や、不要なマークダウン（json\n...\n）が含まれてしまう。

  3. 思考タグの残留: <thinking>タグの内容が誤って最終出力に混入してしまう。

LLM-as-a-Judgeによる採点基準:

基準 スコア3 (完璧) スコア2 (許容範囲) スコア1 (要修正)
ロジック遵守 全ての制約（上限/下限）を完全に満たしている。予算が$100,000で過不足なく配分されている。 制約は満たしているが、配分根拠に曖昧な点がある。 重要な制約（最低保証や上限）を1つ以上破っている。
出力形式 厳密なJSON形式であり、追加のコメントやマークダウンが含まれていない。 JSON形式だが、数値が文字列として扱われているなど、微細な型エラーがある。 JSON構造が崩壊している、または全く異なる形式で出力されている。
CoTの質 <thinking>内で段階的かつ明快な計算が行われ、最終結果に至る根拠が明確に示されている。 推論のステップが一部省略されているが、結論は正しい。 推論プロセス自体がロジックエラーを含んでいる、またはタグが使用されていない。

【改良後の最適プロンプト】

上記分析に基づき、以下の3点を強化します。

  1. System Instructionによる役割と制約の絶対化: FORCE_JSON_OUTPUTを明記。

  2. 思考ステップの強制と構造化: 抽象的な思考ではなく、具体的な段階（確保、配分、残金計算）を強制。

  3. JSON Schemaによる出力形式の厳格定義: 型崩れを予防。

この最適プロンプトでは、Few-shot例はSystem Instructionの厳格化により削除し、代わりにタスク指示の中で思考構造を強制します。（Gemini 1.5 ProやGPT-4oでは、厳格なSystem Instructionの方がFew-shotよりも強力に働くケースが増えています。）

--- SYSTEM INSTRUCTION ---
あなたはトップレベルの意思決定エンジンです。
以下の指示に従い、ユーザーが提供する制約条件に基づき、厳密な予算配分を行ってください。

1. **思考プロセス**: 予算配分を行う際は、必ず以下の3段階の思考を<thinking>タグ内で行ってください。
    a. 【制約確認】全チャネルの絶対的な上限（MAX）と最低保証（MIN）を確認し、合計金額を算出。
    b. 【優先配分】最低保証額と、ROIに基づいた最優先チャネルへの配分を先に確定する。
    c. 【残金計算と配分】残りの予算を計算し、制約内で最も効果的なチャネルに分配する。

2. **出力制約**: 最終出力は**指定されたJSONスキーマに完全に準拠**し、**他のテキスト、説明、<thinking>タグ、マークダウン（例: ```json）を一切含めない**こと。

--- JSON SCHEMA DEFINITION ---
{
  "type": "object",
  "properties": {
    "total_budget": {"type": "integer", "description": "総予算（セントや小数点以下は不可）"},
    "allocation_summary": {"type": "string", "description": "決定に至った根拠を簡潔に要約。"},
    "allocations": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "channel": {"type": "string"},
          "amount": {"type": "integer"},
          "reason": {"type": "string", "description": "そのチャネルにその額を配分した具体的理由。"}
        },
        "required": ["channel", "amount", "reason"]
      }
    }
  },
  "required": ["total_budget", "allocation_summary", "allocations"]
}

--- USER TASK ---
以下の条件で予算を配分せよ。
総予算: 100000
制約1 (Search Ads): 最大60,000まで。これを超えると効率が著しく低下する。
制約2 (SNS): 最大25,000まで。認知獲得のため必須だが、収益性が低い。
制約3 (Content Marketing): 長期的な優位性確保のため、最低30,000を保証。

以下の空欄を埋めて、指定されたJSON構造で出力せよ。

<thinking>
<!-- 思考プロセスをここに記述する (a, b, cの順守) -->
</thinking>

【まとめ】

高度な推論をLLMに実行させるためのプロンプト設計は、単なる指示の羅列ではなく、LLMの思考メカニズムを外部から強制するエンジニアリングです。

実務でプロンプトを運用するための3つの鉄則は以下の通りです。

  1. CoTは指示ではなく構造として強制せよ: <thinking>タグの使用を義務化するだけでなく、その内部で踏むべきステップ（例: 確認 -> 確保 -> 残金計算）を具体的に指示し、ロジックの抜けを防ぐ。

  2. System Instructionで出力形式を絶対化せよ: 最新のLLM（特にGemini 1.5やGPT-4o）はSystem Instructionに対する忠実度が非常に高いため、役割定義、禁止事項（例: マークダウン付与の禁止）、そして最終出力のデータ構造（JSON Schema）を厳格に定義する。

  3. 評価基準を構造化せよ: 出力の正誤を「最終結果の正しさ」だけでなく、「ロジック（思考タグ内）の妥当性」と「形式の正確性」の二軸で評価し、失敗パターンを特定してから改善サイクルを回す。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました