LLM Chain-of-Thought（CoT）完全ガイド：原理からPrompt Engineeringのベストプラクティスまで

1. CoTの本質を一文で理解する

CoTとは、モデルへ一枚の計算用紙を渡すことです。 モデル内部の暗黙的な推論を、外部の明示的な推論へ変えます。

LLMはautoregressiveに、一つずつtokenを生成します。新しいtokenの確率は、それより前に生成されたすべてのtokenに依存します。CoTはこの仕組みを利用します。モデルに中間的な推論手順を先に「書き出させて」tokenに変え、それらのtokenをcontextへ残して後続生成の入力にします。これはモデルに「外部作業記憶」を与えることに相当します。

Autoregressive とは、モデルが一度に一つのtokenだけを生成し、新しいtokenの生成が、それより前に生成されたすべてのtokenに依存すること です。

「Auto」は「自分」、「regressive」は「回帰/依存」を意味します。合わせると、「自分自身の以前の出力に依存する」という意味になります。

最も直感的なたとえとして、文章を一文字ずつ書く場面を想像してください。最初の文字を書くとき、頭の中にあるのは題名だけです。2文字目を書くときは1文字目を見て、何を書くか決めます。3文字目を書くときは最初の2文字を見ます。このように続けていきます。文章全体を一度に書き上げることは決してありません。 各段階で「すでに何を書いたか」に基づいて「次に何を書くか」を決めます。

LLMもまったく同じことをしています。ただし、書く単位は「文字」ではなく「token」です。

数学的に正確に述べると、LLMが完全な系列を生成する過程は、本質的に 条件付き確率の連鎖 を計算しています。

P(出力全体) = P(token₁) × P(token₂|token₁) × P(token₃|token₁,token₂) × ...

各段階を展開すると：

第1段階：モデルが[prompt]を見る
         → P(token₁ | prompt)を計算する
         → token₁をsampleする

第2段階：モデルが[prompt, token₁]を見る
         → P(token₂ | prompt, token₁)を計算する
         → token₂をsampleする

第3段階：モデルが[prompt, token₁, token₂]を見る
         → P(token₃ | prompt, token₁, token₂)を計算する
         → token₃をsampleする

...終了token <EOS>が生成されるまで繰り返す

重要なのは、各段階が完全なTransformerのforward passを1回行うこと です。モデルは、その時点で既知のすべてのtoken、つまりpromptと生成済みtokenをN層のTransformerへ送り、次のtokenの確率分布を得て、その分布から一つのtokenをsampleします。

具体例を示します。

promptが「フランスの首都は」だとすると、モデルは次のように生成します。

入力：[フランス, の, 首都, は]
    → Transformer forward pass → 次のtokenの確率分布：
      「パ」(0.92), 「フ」(0.03), 「一」(0.01), ...
    → sample → 「パ」

入力：[フランス, の, 首都, は, パ]
    → Transformer forward pass → 次のtokenの確率分布：
      「リ」(0.97), 「レ」(0.01), ...
    → sample → 「リ」

入力：[フランス, の, 首都, は, パ, リ]
    → Transformer forward pass → 次のtokenの確率分布：
      「。」(0.85), 「、」(0.05), ...
    → sample → 「。」

「パ」が生成されると、「リ」の確率は不確かな値から0.97へ急上昇します。訓練データでは、「パ」の後に「リ」が続く場合が非常に多いからです。これがautoregressiveの中核です。前の出力が、後に続く可能性を大きく制約します。

この概念を理解することが、なぜそれほど重要なのでしょうか。

ここで扱うすべてのprompt engineering技術は、本質的に、この段階的な生成過程を操作しているからです。

2. CoTが有効な理由：低レベルの原理

2.1 Transformerの固定深度という制約

Transformerの層数Nは、アーキテクチャ上の固定定数です。問題がどれほど難しくても、モデルはN層だけを通過して結果を出力します。各層では「attentionによる情報収集 + FFNによる情報処理」を行うため、全体の計算深度はNに固定されます。

タスクに必要な推論手順が、モデルがN層内で完了できる上限を超えると、モデルの能力が不足します。LLMが簡単な計算には正確である一方、多桁の掛け算ではよく間違える理由の一つです。

2.2 CoTがこの制約を突破する方法

CoTを使わない場合、推論深度はN層、つまり1回のforward passに固定されます。CoTを使うと、各段階で生成した中間結果のtokenが次のforward passの入力contextになります。実効的な計算深度はK × N、つまりK段階の推論 × 各段階のN層になります。

CoTは本質的に、固定深度の計算回路 を、深度が動的に増える計算回路 へ変えます。2023年の論文『Chain-of-Thought Empowers Transformers to Solve Inherently Serial Problems』は、この点を数学的に厳密に証明しました。

2.3 Attentionの仕組みから理解する

CoTの各中間出力は、後続段階のKeyとValueになります。最後の段階で以前の計算結果を参照する必要があるとき、モデルのQueryは、前の段階で具体的な数値が置かれた位置へ直接attendできます。隠れ層内の曖昧で分散した表現から「思い出す」より正確です。

3. CoTが持つ三つの価値

4. CoTの実装方法

4.1 Zero-Shot CoT

例を与えず、引き出すための一文だけを使います。

"Let's think step by step."              ← 最も古典的で、論文上最も有効と検証された形
「この問題を一段階ずつ考えてください。」
"Think through this carefully."
"Before answering, reason through the problem."

実践上のコツ： promptの本文が中国語でも、CoTを引き出す表現には英語を使ったほうが有効な場合があります。LLMの訓練データでは、英語の論理推論テキストが中国語よりはるかに多く、モデルが「step by step」へ強く反応するためです。

適した場面： タスクの種類が大きく変わり、すべての状況を網羅する例を準備しにくい場合。

4.2 Few-Shot CoT

「推論過程を含む例」をpromptへ複数入れ、モデルに模倣させます。

問題：プールに二つの給水管がある。A管は毎時3トン、B管は毎時5トンを給水する。
二つを同時に開くと、40トンのプールが満杯になるまで何時間かかるか。

推論：
- A管の速度：3トン/時
- B管の速度：5トン/時
- 合計速度：3 + 5 = 8トン/時
- 必要時間：40 ÷ 8 = 5時間
回答：5時間

問題：{new_question}
推論：

Few-Shot CoTはZero-Shot CoTより信頼性が高くなります。モデルへ「推論せよ」と伝えるだけでなく、推論の書式と粒度 も示せるからです。

適した場面： モデルのデフォルト動作より明確に優れた、高品質な例を提供できる場合。

4.3 Structured CoT（エンジニアリング向けCoT）

XMLやJSONなどの構造化タグで推論過程を整理し、コードから解析しやすくします。

必ず次の構造で分析結果を出力してください。

<thinking>
<symptom_extraction>[重要な症状を抽出]</symptom_extraction>
<severity_assessment>[重症度を評価]</severity_assessment>
<possible_conditions>[考えられる症状を列挙]</possible_conditions>
</thinking>

<answer>[最終回答]</answer>

適した場面： AIアプリケーション開発で、推論過程と最終回答を別々に処理する必要がある場合。

4.4 Thinkingモデルに組み込まれたCoT

Claude Extended Thinking、OpenAI o1/o3、Gemini Thinking Modeなどのモデルは、訓練段階で強化学習（RL）を使い、推論能力に特化して最適化されています。thinking block内で自動的に深い推論を行うため、手動でCoTを引き出す必要はありません。

Prompt-based CoTとの重要な違い：

5. CoT Prompt Engineeringのベストプラクティス

実践1：推論と最終回答を分離する

本番環境では、推論過程をデバッグと監査のためにログへ保存し、最終回答をユーザーへ返す必要があります。構造化タグで両者を分けます。

この問題を分析してください。

<thinking>
[ここに推論過程を書く]
</thinking>

<answer>
[ここに最終回答を書く]
</answer>

実践2：推論の観点と方向を指定する

「推論してください」と言うだけでなく、推論過程に「道筋」を与えます。

このコードに問題がないか分析してください。

次の観点を順番に分析してください。
1. 最初に論理的な正しさを確認する——コードは期待される機能を実現しているか
2. 次にedge caseを確認する——空の入力、極端な値、並行処理など
3. 続いて性能を確認する——時間計算量と空間計算量は妥当か
4. 最後にセキュリティを確認する——injection、権限昇格などのriskがあるか

各観点について、先に判断（問題あり/問題なし）を示し、その後理由を説明してください。

原理： 観点を指定しないと、モデルは最初に見つけた問題へ多くのtokenを使い、後の観点をtoken予算切れによって無視する可能性があります。観点を指定すれば、重要な側面をすべて扱えます。

実践3：Self-Consistency（自己整合性による検証）

高リスクな推論タスクでは、モデルに複数回独立して推論させます。このときtemperature > 0に設定し、多数派の回答を採用します。

中心的な考えは、各推論が異なる経路をたどっても、正しい回答には複数の経路が共通して到達しやすいというものです。

# 伪代码
answers = [model.generate(question, temperature=0.7) for _ in range(5)]
final_answer = majority_vote(answers)
confidence = count(final_answer) / 5

適した場面： コストは倍増しますが、精度を5〜15%改善できるため、医療、金融、法律など高リスクな場面だけで使用します。

実践4：モデルへ「振り返る」機会を与える

推論後に自己点検させます。

第1段階：推論過程と暫定的な回答を書いてください。

第2段階：推論を振り返り、次の問題がないか確認してください。
- 計算間違いがないか。
- 条件を見落としていないか。
- 結論は妥当か。

問題を発見した場合は修正し、最終回答を示してください。

原理： 振り返り段階のcontextには、完全な推論chainがすでに含まれています。モデルは新しいforward passを使って以前の推論を「点検」できます。人が数学の問題を解いた後に検算することと似ています。

実践5：Thinkingモデル向けに戦略を調整する

Claude Extended Thinking、OpenAI o1/o3などのthinkingモデルでは、次のようにします。

してはいけないこと： 「Let’s think step by step」のようにCoTを手動で引き出すこと。最適化済みの推論戦略を妨げ、かえって性能を下げる可能性があります。

すべきこと： タスクと期待する出力形式を明確に説明します。

次のコードに含まれるすべてのセキュリティ脆弱性を分析してください。
各脆弱性について、種類、深刻度（高/中/低）、修正案を示してください。
結果をJSON配列で出力してください。

モデルはthinking block内で自動的に深い推論を行います。タスク記述の明確さだけに注意すれば十分です。

6. Few-Shot CoTの品質を管理する

6.1 悪い例は、例がない場合より悪い

Few-shotは諸刃の剣です。モデルはattentionの仕組みでパターンを照合し、複製します。「良いパターン」と「悪いパターン」を区別せず、どちらも忠実に模倣します。

悪い例は三つの害をもたらします。

推論粒度の上限： 例が粗い2段階の推論しか示していなければ、問題に5段階が必要でも、モデルは2段階しか行いません。

推論方向の誤誘導： 例の推論経路に手順の飛躍や論理的な穴があれば、モデルはその悪い習慣を学びます。

書式の過度な制約： すべての例が一つの特定書式なら、別の書式が現在の問題に適していても、モデルはその書式へ固定されます。

6.2 判断基準

Few-Shot CoTを使う 前提は、モデルのデフォルト動作より明確に優れた例を提供できることです。たとえば、特定領域の専門家レベルの推論例や、厳密に従う必要がある出力書式です。

Zero-Shot CoT がより適するのは、最適な推論経路が分からない場合や、タスクの種類が大きく変わる場合です。例を与えないことで、モデルに大きな自由度を与えられます。

中核原則：自分自身でも「模範回答の推論過程」がどのようなものか確信できないなら、例を与えず、モデルに任せます。

6.3 Few-Shotが必須の場合に品質を確保する方法

推奨する方法は、「モデルに例の生成と選別を手伝わせる」ことです。

1. 複数の問題に対してモデルへZero-Shot CoTを実行させます。
2. どの推論過程が正しく高品質か、人が検証します。
3. 検証を通過したものをFew-Shotの例として使用します。

モデルが生成した推論の書き方は、モデル自身の「思考習慣」と一致しているため、すべての例をゼロから人が書くより有効です。

7. CoTの制約とコスト

8. CoTを使うための判断tree

Thinkingモデル（o1/o3、Claude Extended Thinking、Gemini Thinking）を使っていますか？
│
├── はい → CoTを手動で引き出さない
│          明確なタスク記述と出力形式に集中する
│
└── いいえ → タスクに複数段階の推論が必要ですか？
    │
    ├── いいえ → CoTを使わず、直接回答する
    │            （事実検索、翻訳、創作など）
    │
    └── はい → 高品質な推論例がありますか？
        │
        ├── はい → Few-Shot CoTを使う
        │          + 推論の観点を指定
        │          + thinkingとanswerを分離
        │
        └── いいえ → Zero-Shot CoTを使う
                      ("Let's think step by step")
                      │
                      └── 高リスクな場面ですか？
                          │
                          ├── はい → Self-Consistencyを追加
                          │          + 振り返りによる確認
                          │
                          └── いいえ → 基本的なCoTで十分

9. Prompt Engineeringのほかの技術との関係

CoTは孤立した技術ではなく、Prompt Engineeringのほかの中核技術と連携します。

Clear Instructions + CoT： 推論の観点を指定することは、Clear InstructionsをCoTの場面へ適用することです。

Few-Shot + CoT： Few-Shot CoTは、Few-ShotとCoTを自然に組み合わせたものです。例の中で入出力だけでなく、推論過程も示します。

CoT + 区切り： XMLタグで推論と回答を分けることは、区切り技術をCoTの場面へ適用することです。

CoTとContext Engineeringの関係： CoTが生成する推論tokenはcontext windowの空間を占有します。Agentが長期間動く場面では、context windowのoverflowを防ぐため、過去の推論過程を圧縮または要約する必要があります。これはContext Engineeringの中核的な課題の一つです。

10. 主要論文

1. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models (Wei et al., 2022) — CoTの基礎となる論文
2. Large Language Models are Zero-Shot Reasoners (Kojima et al., 2022) — 「Let’s think step by step」の有効性を発見
3. Self-Consistency Improves Chain of Thought Reasoning (Wang et al., 2023) — 複数回sampleし、多数派を選ぶ方法
4. Chain-of-Thought Empowers Transformers to Solve Inherently Serial Problems (Feng et al., 2023) — CoTが固定深度の制約を突破することを理論的に証明