Chain-of-Thought プロンプトの仕組みと業務での実装

「Chain-of-Thought（CoT）プロンプト」は、AI に「段階的に推論させる」ことで複雑タスクの精度を上げる手法です。「ステップで考えてください」と書くだけでも効果はありますが、業務での実装は もう一歩踏み込む と精度がさらに上がります。

CoT が効くタスクの特徴

CoT は次のような 多段階推論を要するタスク で特に効果が出ます。

• 計算を含む推論（料金計算、稼働日計算、見積もり）
• 複数情報の照合（契約書 × 社内ガイドライン）
• 因果関係の特定（障害原因の切り分け、解約理由の連鎖）
• 段階的な判断（リスクスコアリング、優先順位付け）

逆に、形式変換・分類・短文要約 など 1 ステップで完結するタスクには CoT は不要で、トークンを無駄に消費するだけです。

「ステップで考えてください」だけでは不十分な理由

最も素朴な CoT は次のような書き方です。

以下の問題を、ステップごとに考えて答えてください。

これでも改善はしますが、業務では次の 3 つの問題があります。

1. ステップの分け方が AI 任せ → 再現性が低い
2. 検証が入らない → 推論ミスがそのまま結論に
3. 出力が長くなる → コスト増、可読性低下

業務での実装は 構造化 と 検証 が肝です。

業務での 3 つのバリエーション

バリエーション 1: 手順誘導型

タスクの分解手順を AI に教える タイプです。

以下の契約書を、次の手順で分析してください。

# 手順
1. 契約類型を特定する
2. 必須条項のチェックリストを作成する
3. 契約書の各条項を順に読み、チェックリストと照合する
4. 不足条項とリスクをまとめる

# 出力
- 各ステップの結論
- 最終リスクスコア（high/medium/low）

# 契約書
{{contract}}

手順を AI に丸投げせず、こちらが分解する。再現性が高く、検証もしやすい。

バリエーション 2: 制約付き思考型

各ステップで 守るべき制約 を明示します。

以下の問題を解いてください。

# 制約
- 各ステップは 50 字以内で記述する
- 数値計算は必ず途中式を示す
- 不確定な情報は「不明」と明示する

# 問題
{{problem}}

制約があると AI が手抜きせず、検証可能な推論を出します。

バリエーション 3: 自己検証型

最後に AI に 自分の推論を検証 させます。

{{task}}

# 出力ルール
1. まず段階的に推論する
2. 結論を出す
3. 結論の検証として、次の 3 点を自己チェック:
   - 矛盾する前提を使っていないか
   - 数値計算は正しいか
   - 別の解釈はないか
4. 自己チェックで問題があれば結論を修正
5. 最終回答を提示

自己検証は 計算ミスや論理矛盾 を半分くらいは拾ってくれます。完璧ではないですが、ノーチェックよりは確実に良くなります。

Claude / GPT との相性

観点	Claude	GPT
構造化された手順への追従	高い	高い
自己検証の素直さ	比較的素直に修正する	自分の答えに固執しやすい
長い CoT の安定性	高い	高い
省略傾向	少ない	「省略します」と言って中略しがち

Claude は CoT の途中過程を比較的丁寧に出してくれる傾向があります。GPT は「省略します」と言って中略する場合があるので、「中略禁止」を明示すると良いです。

いつ CoT を使うべきか

• 1 ステップで終わるタスク → CoT 不要
• 論理ミスが許されないタスク → CoT + 自己検証
• 業務手順が決まっているタスク → 手順誘導型
• 出力が短い分類・抽出 → CoT より Few-shot

PrompTune で運用する

CoT プロンプトは構造化が肝心です。PrompTune の 無料診断ツール では、プロンプトの「構造」を評価項目に含めており、CoT の組み立てが妥当かを 5 軸でスコアリングできます。