本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
複雑な論理構造を解き明かす「Chain-of-Thought」実装ガイド：推論精度の極大化
【ユースケース定義と課題】
複数の制約条件（時間、予算、リソース）が絡み合う複雑なビジネスロジックの判定と、その根拠を構造化して出力するタスク。
入力の型：Markdown（条件リストと制約事項）
出力の型：JSON（判定結果、および各ステップの思考ログ）
【プロンプト設計のループ】
graph TD A["設計: 思考ステップの明文化"] --> B["実行: Zero-shot/Few-shot試行"] B --> C["評価: 推論の飛躍・矛盾チェック"] C -->|改善: 中間推論の強制誘導| A
設計：LLMがいきなり結論を出さないよう、「思考プロセス」の枠組みを定義します。
実行：Gemini 1.5 Pro等の長文コンテキスト耐性を活かし、具体的な思考例を提示します。
評価：結論が合っていても過程が間違っている「ラッキー正解」を排除する評価基準を設けます。
【プロンプトの実装案】
# Role
あなたは高度な経営コンサルタント兼ロジカルシンキングの専門家です。
# Task
提示された複数のビジネス制約条件を分析し、最適な意思決定案を提示してください。
# Constraints
- 回答の前に、必ず「<thought>」タグ内で思考プロセスを書き出してください。
- 思考プロセスでは、条件を一つずつ検証し、矛盾がないか確認してください。
- 最終回答は、指定されたJSONフォーマットのみで出力してください。
# Example (Chain-of-Thought)
<thought>
1. 条件A（予算500万）と条件B（納期3ヶ月）を確認。
2. 案1は予算内だが納期が4ヶ月。不適合。
3. 案2は予算450万、納期2.5ヶ月。適合。
4. 結論として案2を採択。
</thought>
{
"decision": "案2",
"reasoning_summary": "納期と予算の全制約を満たす唯一の選択肢であるため"
}
# Input
[ここに具体的な課題データを入力]
【評価指標と誤り分析】
| 評価項目 | 期待される挙動 | 失敗パターン（分析） |
|---|---|---|
| 論理的一貫性 | 思考プロセスの手順と結論が一致している | 思考プロセスでは「不可」としているのに結論が「可」になる（様式崩れ） |
| 制約充足率 | 与えられた全ての条件（変数）を考慮している | 特定の条件を無視して一般的な回答を出力する（情報の欠落） |
| 構造化精度 | 指定したJSONフォーマットを完全に遵守している | JSONの外側に説明テキストが漏れ出す（パースエラー） |
【改良後の最適プロンプト】
# System
あなたは、論理的推論をステップバイステップで行うエキスパート・システムです。
複雑な入力を、まず最小単位の論理要素に分解し、それらを組み合わせて結論を導出します。
# Reasoning Protocol
1. **分解**: 入力文から全ての制約条件を箇条書きで抽出せよ。
2. **検証**: 各解決案が制約条件をクリアしているか、[Pass/Fail]で判定せよ。
3. **統合**: 全ての判定結果を統合し、最も合理的な結論を導け。
# Instructions
- ユーザーからの入力に対し、以下の形式で思考を言語化してください。
<reasoning_process>
[ステップごとの推論内容]
</reasoning_process>
- 最終結果は、必ず以下のJSONスキーマに従ってください。
```json
{
"analysis_id": "string",
"satisfied_constraints": ["string"],
"final_decision": "string",
"confidence_score": 0.0-1.0
}
User Input
[対象となる複雑なタスク内容] “`
【まとめ】
「思考の隔離」を徹底する：
<thought>タグなどを用いて、推論プロセスと最終出力を構造的に分離させること。中間変数を明示させる：計算や判定の途中で発生する中間結果を言語化させることで、論理の飛躍を防ぐ。
失敗をLLMに自己採点させる：出力の最後に「自身の推論に矛盾がないか」を再チェックする命令を加えることで精度が向上する。
