複雑な論理推論タスクの精度を最大化するChain-of-Thought（CoT）プロンプト設計ガイド

Tech

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

複雑な論理推論タスクの精度を最大化するChain-of-Thought（CoT）プロンプト設計ガイド

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

複雑なビジネス条件の判定やロジック検証を正確に行い、論理的破綻のない回答を出力させます。（61文字）

  • 入力形式: Markdown（業務要件・判定対象のシナリオ）

  • 出力形式: JSON（判定結果、判定理由、信頼度スコア）

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

graph TD
A["設計"] --> B["実行"]
B --> C["評価"]
C -->|改善| A

  • 設計: タスクの分解と、思考プロセス（CoT）を誘発する命令文および出力フォーマットの事前定義を行います。

  • 実行: 最新モデル（Gemini 1.5 Pro等）に対してプロンプトを入力し、推論ステップの生成を行わせます。

  • 評価: LLM-as-a-Judgeを用いて、思考プロセスの妥当性および出力フォーマットの厳密性を自動採点し、問題点を洗い出します。

【プロンプトの実装案】

あなたは高度な論理的思考を持つビジネスアナリストです。
以下の入力テキスト（業務ルールと判定対象）を読み、条件に適合するか判定してください。

# 思考プロセス（Chain-of-Thought）の指示

回答を出力する前に、必ず以下の手順でステップ・バイ・ステップで思考してください：

1. 適用されるべき業務ルールをすべて箇条書きで抽出する。

2. 判定対象のシナリオから、事実関係を整理する。

3. ルールと事実関係を1つずつ照合し、条件を満たしているか検証する。

4. 最終的な結論と根拠をまとめる。

# 入力データ

[業務ルール]

- 契約金額が100万円以上の場合、部長承認が必要。

- 納期の変更がある場合、法務の事前確認が必要。

[対象シナリオ]

- 契約金額150万円、納期変更ありの案件。

# 出力フォーマット（JSON）

```json
{
  "reasoning_steps": [
    "ステップ1: ...",
    "ステップ2: ..."
  ],
  "requires_department_manager_approval": true/false,
  "requires_legal_check": true/false,
  "final_judgment": "承認・確認の要否まとめ"
}

---

### 【評価指標と誤り分析】

#### 主な失敗パターン


1. **思考の飛躍（Hallucination / Skip）**: 中間ステップをスキップし、根拠のない結論を出す。

2. **フォーマット崩れ**: CoTを出力させた結果、最終出力のJSON構造が破損する。

3. **ルール見落とし**: 複数の複雑な条件が存在する場合に一部の評価を失念する。

#### 自動評価基準（LLM-as-a-Judge）

| 評価項目 | 配点 | 評価基準 |
| :--- | :--- | :--- |
| **論理的整合性** | 40点 | 思考プロセス（reasoning_steps）に矛盾や飛躍がないか |
| **条件網羅性** | 30点 | 指定されたすべてのルール・事実関係を判定対象に含めているか |
| **フォーマット準拠性** | 30点 | 指定されたJSON形式に完全に準拠し、余計なテキストが含まれていないか |

---

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

```text
あなたは厳格な論理検証を行うAI監査官です。
与えられた規約と案件内容を比較し、正確な判定を行ってください。

# 制約事項


- 事実に基づかない推測（ハルシネーション）は厳禁です。

- 思考プロセスは必ず `thinking_process` フィールド内で展開してください。

# 思考手順（Systematic CoT）


1. 事実抽出: 案件データから事実のみを抽出。

2. 適用規約の特定: 関連する規約をリスト化。

3. 個別検証: 各規約と事実を比較（PASS/FAIL/NOT_APPLICABLE）。

4. 総合判定: 全検証結果に基づく最終判定の導出。

# 入力データ

[規約]
{{RULES}}

[案件データ]
{{CASE_DATA}}

# 出力形式

```json
{
  "thinking_process": {
    "step1_facts": [],
    "step2_applied_rules": [],
    "step3_verification": [
      {"rule_id": "", "status": "PASS|FAIL", "reason": ""}
    ]
  },
  "final_result": {
    "approved": true,
    "summary": ""
  }
}

“`

【まとめ】

実務でプロンプトを運用するための3つの鉄則：

  1. 思考と出力の分離: 思考プロセス（CoT）を構造化フィールド内に限定させ、最終出力のフォーマット破壊を防ぐ。

  2. Step-by-Stepの明示的誘導: 単に「考えてください」ではなく、具体的にどのような手順で検証を進めるべきか（事実抽出→照合→判定）を指定する。

  3. 自動評価（LLM-as-a-Judge）の組み込み: プロンプト変更時には必ず評価基準テーブルに基づいた定量評価を行い、精度維持を図る。

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

コメント

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