本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Chain-of-Thought (CoT) による多段階論理推論の精度向上プロトコル
【ユースケース定義と課題】
複雑な条件が絡む論理パズルやビジネス上の意思決定ロジックを正確に解く。推論の飛躍や計算ミスを防ぐことが困難。
入力型: Markdown（前提条件と問い）
出力型: JSON（
thought_process,final_answerを含む構造体）
【プロンプト設計のループ】
graph TD A["設計: 思考ステップの定義"] --> B["実行: Few-shot/Zero-shot CoT"] B --> C["評価: 推論経路の妥当性確認"] C -->|改善: 誤答箇所の分解| A
設計: 課題を最小単位の論理ステップに分解するよう指示を設計。
実行: 思考過程を言語化させるトリガー（「ステップバイステップで考えて」等）を組み込む。
評価: 最終回答だけでなく、中間推論に誤りがないかを LLM-as-a-Judge で判定。
【プロンプトの実装案】
# Role
あなたは、高度な論理的思考能力を持つ専門家です。
# Task
以下の前提条件に基づき、問いに対して論理的な回答を導き出してください。
# Constraints
- 結論を出す前に、必ず「思考プロセス」をステップバイステップで記述してください。
- 各ステップでは、前のステップからの論理的帰結を確認してください。
- 回答は必ず以下のJSON形式で出力してください。
# Input
[前提条件]
1. AはBより背が高い。
2. CはDより背が低い。
3. BはCより背が高い。
[問い]
最も背が高いのは誰か？
# Response Format
{
"thought_process": [
"Step 1: ...",
"Step 2: ..."
],
"final_answer": "結論"
}
【評価指標と誤り分析】
失敗パターン:
計算・論理の飛躍: 途中のステップを省略し、誤った結論に到達する。
様式崩れ: 思考プロセスを記述せず、結論のみを出力する。
LLM-as-a-Judge 採点基準:
| 評価項目 | 判定基準 | 配点 |
|---|---|---|
| 推論の整合性 | 前提条件と各ステップの論理が矛盾していないか | 5 |
| 構造化 | thought_process が適切な粒度で分割されているか |
3 |
| フォーマット遵守 | 指定されたJSON型を維持しているか | 2 |
【改良後の最適プロンプト】
# System
You are a logical reasoning engine. Use Chain-of-Thought to ensure zero-shot accuracy.
# Instructions
1. Analyze the provided premises carefully.
2. Formulate a step-by-step reasoning path. Each step must explicitly reference the premise used.
3. Check for any contradictions before concluding.
4. Output the result in the strict JSON schema provided below.
# Output Schema
{
"analysis": "Briefly state the goal",
"reasoning_steps": [
{
"step": 1,
"description": "Observation from premise X",
"inference": "Deduction from the observation"
}
],
"final_answer": "Strictly the conclusion"
}
# Execution
Let's think step by step.
【まとめ】
思考の強制: 「ステップバイステップで考えて」というフレーズは、モデルに計算リソース（トークン）を割り当てるための必須命令である。
構造化出力: 推論過程をリスト形式（JSONの配列等）で出力させることで、検証の自動化とデバッグを容易にする。
参照の明示: 各推論ステップで「どの前提に基づいているか」を明示させることで、幻覚（ハルシネーション）を抑制する。
