本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
Chain-of-Thoughtを活用した複雑な論理推論タスクの精度向上プロンプト設計
【ユースケース定義と課題】
目的: 複数の変数（予算、期間、技術スタック）が絡むシステムリプレイスの意思決定支援と論理的なリスク分析。
難しさ: 条件が複雑になるとLLMが途中の計算や依存関係を見落とし、結論のみを提示して論理的整合性を欠く点。
入出力の型: 入力はMarkdown形式の要件定義、出力は「思考プロセス（JSON）」と「最終提言（Markdown）」のハイブリッド。
【プロンプト設計のループ】
graph TD A["要件定義の構造化"] --> B["思考ステップの明示化"] B --> C["Few-shotによる回答パターンの規定"] C --> D["論理的整合性の自己検証"] D -->|不一致があれば修正| B
設計: 入力情報を変数として分離し、推論の「足場」を作る。
実行: CoTを用いて中間プロセスを出力させる。
評価: 結論が前提条件と矛盾していないかを自動スコアリング。
【プロンプトの実装案】
# Role あなたは複雑なビジネスロジックを解読し、最適解を導き出すシニアITコンサルタントです。 # Task 提示されたシステムリプレイス要件に基づき、3つの提案オプションを比較検討し、最もリスクが低く費用対効果の高い案を選択してください。 # Constraints - 回答の前に、必ず「<thought>」タグ内で以下のステップに従って思考してください。 1. 現状の制約条件（予算、納期、技術）の抽出 2. 各オプションのメリット・デメリットの定量的比較 3. 潜在的なリスク（依存関係の競合など）の特定 - 結論は最後に「# 最終提言」として出力してください。 # Example (Few-shot) User: 予算1000万、納期3ヶ月。A案（フルスクラッチ）、B案（SaaS導入）。 Assistant: <thought> 1. 制約: 1000万, 3ヶ月。 2. 比較: A案は納期半年以上で予算超過リスク高。B案は1ヶ月で導入可能、予算内。 3. リスク: SaaSの機能制限が業務に与える影響。 結論: B案を推奨。 </thought> # Input Data [ここに複雑な要件を記述]
【評価指標と誤り分析】
| 評価項目 | 期待される挙動 | 失敗パターン（低精度時） | 配点 |
|---|---|---|---|
| 論理の一貫性 | 思考プロセスと結論が一致している | 思考ではA案が良いと言いつつ、結論でB案を出す | 40 |
| 制約遵守 | 予算や納期などの数値を全て考慮している | 一部の数値を無視して理想論を語る | 30 |
| 構造化レベル | 指定されたタグや形式を守っている | タグを閉じ忘れる、Markdownが崩れる | 30 |
【改良後の最適プロンプト】
# Instructions
以下の「入力データ」を分析し、最適な戦略を策定してください。
出力は必ず「思考プロセス」と「最終回答」の2部構成にすること。
# Process (Chain-of-Thought)
Step 1: 与えられたデータから「変更不可能な制約」をすべて箇条書きにする。
Step 2: 各選択肢がStep 1の制約を満たしているか、Boolean(True/False)で判定する。
Step 3: Falseが含まれる選択肢を排除し、残った選択肢から期待値を計算する。
Step 4: 最も高いスコアの選択肢を選出し、その根拠を述べる。
# Output Format
## 1. 思考ログ
[Step 1〜4のプロセスを記述]
## 2. 最終回答
- 推奨案:
- 理由:
- リスクと対策:
# Input Data
{ここに詳細なデータをペースト}
【まとめ】
思考の「外部化」:
thoughtタグやステップ指定を用いて、LLMが「次に書くべきこと」を迷わないように導線を引く。制約の「再認識」: 推論を開始する直前に、LLM自身に制約条件を書き出させることで、ハルシネーション（無視）を抑制する。
形式の「厳格化」: Markdown見出しやJSON構造を強制し、後続のシステムや人間が評価しやすい形で出力させる。
コメント