はじめに：なぜあなたのAIは「もっともらしい嘘」をつくのか
多くの開発現場で、次のような課題が報告されています。RAG（検索拡張生成）システムを構築し、社内ドキュメントを完璧に整備した。LLMも、広大なコンテキストウィンドウや高度なアーキテクチャを備えた最新のLlamaなどを採用している。それにもかかわらず、AIが顧客の契約条件について、平気で矛盾した回答を生成してしまうケースは珍しくありません。
この現象は、行動経済学者のダニエル・カーネマンの著書『ファスト＆スロー』の概念を用いると分かりやすく説明できます。つまり、AIは複雑な論理的推論を要する問題に対して、論理的に順序立てて考える「システム2（熟考）」ではなく、パターン認識に基づく「システム1（直感）」だけで解こうとしているような状態なのです。
生成AIの実装を担当するテックリードやシニアエンジニアの皆さんなら、このフラストレーションに共感していただけるはずです。プロンプトエンジニアリングの基礎を学び、コンテキストを注入してもなお、論理的な推論を要するタスクにおいてLLMは予期せぬ失敗（ハルシネーション）を犯します。
多くのエンジニアはここで、「プロンプトをもっと具体的にしよう」とか「よりパラメータ数の大きなモデルを使おう」と考えがちです。しかし、技術の本質を見抜けば、問題の根幹はそこにはありません。最大の課題は、LLMのデフォルトの動作モードが「思考」ではなく「直感」に基づいているという点にあります。
本記事では、プロンプトエンジニアリングの世界で最も革命的かつ本質的な手法である「Chain-of-Thought（CoT：思考の連鎖）」について紐解きます。現在、CoTは単なるプロンプトの工夫から、LLMの標準的な推論アーキテクチャへと進化を遂げています。最新のClaudeやGeminiといったモデルでは、問題の複雑度に応じて推論の深さを自動判断する「適応型思考（Adaptive Thinking）」や、外部ツールと統合された高度な推論モードが実装されるようになりました。しかし、巷に溢れる「魔法のプロンプト集」のような表面的なテクニック論だけでは、これらの進化を十分に引き出し、ビジネス価値に直結させることはできません。
なぜ「ステップ・バイ・ステップで考えて」と段階的な深掘りを指示するだけで正答率が跳ね上がるのか。その裏側で起きている認知科学的・計算機科学的なメカニズムを解剖します。さらに、Self-Consistency（自己整合性）やTree of Thoughts（思考の木）といった発展形から、最新モデルが内蔵する推論エンジンの挙動までを含めた、より堅牢な「推論アーキテクチャ」を設計するための指針を提示します。
これは、単にAIに正解を出させるためのハックではなく、AIというブラックボックスの中に「論理的な思考回路」を設計し、自律的な仮説検証や複雑な問題解決を可能にするための、実践的なエンジニアリングガイドです。
なぜLLMは「計算」や「論理」を間違えるのか
Chain-of-Thought（CoT）の有効性を深く理解するためには、まずLLMが失敗するメカニズムを、最新の認知科学的視点とアーキテクチャの制約から理解する必要があります。なぜ、あれほど流暢に言葉を操るAIが、小学生レベルの算数や論理パズルで躓くのでしょうか。
次トークン予測の限界点と「推論時コンピュート」
根本的な原因は、LLMのアーキテクチャそのものにあります。多くの人が認識しているように、LLMは本質的には「確率的な単語予測器」です。入力されたテキスト（コンテキスト）に基づいて、次に続く可能性が最も高いトークンを予測し、それを順次出力していくだけの存在です。
このプロセスにおいて、従来のモデルはO(1)の計算量で次の単語を決定します。つまり、入力がどれほど複雑な問いであっても、モデルは一定の計算ステップ（Transformerの層数分）を経て即座に次の単語を出力しようとします。
補足として、こうしたTransformerモデルを実装・運用する基盤技術も日々進化しています。例えば、標準的なライブラリであるHugging FaceのTransformersは、最新のv5.0.0（2025年1月公開）で内部設計を大きく刷新しました。モジュール型アーキテクチャへの移行により各コンポーネントの独立性が高まりましたが、実務において注意すべき重要な変更点もあります。このバージョンからPyTorch中心の最適化へと舵を切り、TensorFlowおよびFlaxのサポートが完全に終了（廃止）されました。現在これらのバックエンドを利用してモデルを運用している場合は、公式の移行ガイドを参照し、PyTorchベースの環境へ速やかに移行する必要があります。
このように基盤ライブラリの進化によって推論処理の効率化やデプロイの柔軟性は向上していますが、アーキテクチャの根本的な制約である「一定の計算ステップで答えを出力しようとする性質」自体は変わりません。これは、AI研究において「推論時コンピュート（Inference-time Compute）」の不足として議論されている問題です。
これを人間に置き換えてみましょう。例えば、「23 × 47 は？」と聞かれたとき、暗算が得意な人なら即座に答えられるかもしれません。しかし、「34,567 × 98,765 は？」と聞かれて、一瞬で答えを出せと言われたらどうでしょうか。
ほとんどの人は、適当な数字の羅列（もっともらしい嘘）を答えるはずです。なぜなら、その計算を行うために必要な「中間ステップ」を踏む時間、すなわち計算リソースを与えられていないからです。LLMが論理的なタスクで失敗するのは、まさにこれと同じ状況です。複雑な論理演算が必要な問いに対して、中間処理なしにいきなり「答え」のトークンを予測しようとするため、確率的に「それっぽい」数字や結論を出力してしまうのです。
システム1（直感）のみで答えるAIの脆弱性
認知心理学者ダニエル・カーネマンは、人間の思考モードを2つに分類しました。この二重過程理論は、現在のAIの振る舞いを理解する上でも極めて有効です。
- システム1（速い思考）: 直感的、自動的、無意識的。努力を要さない。「2 + 2 = ?」や「怒っている人の顔を認識する」など。
- システム2（遅い思考）: 論理的、意識的、努力を要する。「17 × 24 = ?」や「複雑な契約書の妥当性を検証する」など。
デフォルトの状態（標準的なプロンプティング）におけるLLMは、システム1のみで動作していると言えます。膨大な学習データから得られた統計的な相関関係に基づいて、パターンマッチング的に回答を生成しています。これは、一般的な会話や知識検索には極めて有効ですが、多段階の推論を必要とするタスクには不向きです。
「もっともらしい嘘（ハルシネーション）」が生まれる構造的理由はここにあります。LLMは論理を理解していないわけではありませんが、論理を展開するための「時間」と「作業スペース」を与えられていないのです。システム2を作動させるためには、意識的に思考プロセスを遅らせ、ステップを踏ませる必要があります。近年の研究では、この思考プロセスを明示的に出力させることが、AIの推論精度だけでなく「監視可能性（Monitorability）」の向上にも寄与することが示されています。
「もっともらしい嘘」が生まれる構造的理由
具体例を挙げて考えてみましょう。以下のような推論タスクを標準的なプロンプトでLLMに投げたとします。
Q: ロジャーはテニスボールを5個持っています。彼はさらにテニスボールの缶を2つ買いました。それぞれの缶にはテニスボールが3個入っています。彼は今、テニスボールを何個持っていますか？
A: 答えは11個です。
多くのモデルは正解（11個）を出せます。しかし、数字を少し複雑にしたり、条件をひねったりすると、途端に間違えます。
Q: （条件を複雑化）... 彼は缶を2つ買い、そのうちの1つを友人に譲りました。残りの缶からボールを1個取り出しました...
A: 答えは23個です。（誤答）
なぜ間違えるのでしょうか。モデルは入力文の「数字」と「単語（買う、譲る）」の表面的な関連性から、学習データ内でよく見られるパターン（足し算や引き算の結果としてありそうな数字）を予測してしまうからです。途中の計算式（状態遷移）を保持していないため、複雑な文脈の中で「現在のボールの数」という変数の値を追跡できなくなります。
ここでの教訓は明確です。「思考の過程」を出力させずに「結果」だけを求めると、LLMは統計的な推測（＝当てずっぽう）を行うということです。これを防ぎ、モデルにシステム2的な熟慮を強制する技術こそが、Chain-of-Thoughtなのです。
Chain-of-Thought（思考の連鎖）の本質的メカニズム
2022年、Google ResearchのWeiらが発表した論文 "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models" は、AIコミュニティに衝撃を与えました。彼らが示したのは、プロンプトに「思考過程の例」を含めるだけで、LLMの推論能力が劇的に向上するという事実でした。
では、CoTの本質とは何でしょうか。それは単なる「書き方の工夫」ではありません。計算機科学的な視点から見ると、CoTは計算リソースを動的に配分する技術と定義できます。
計算リソースを「時間軸」に展開する
先ほど、LLMはO(1)で次のトークンを予測すると述べました。しかし、出力されるトークン数が増えれば、トータルの計算量は増えます。
標準的なプロンプトで「答えはXです」と出力する場合、モデルはXを導き出すために1ステップ分の計算しか行えません。しかし、CoTを用いて「まずはAについて考えます。次にBを計算します。したがって答えはXです」と出力させる場合、モデルは「Aについて考える」「Bを計算する」というプロセスごとにTransformerの計算リソースを使うことができます。
つまり、CoTは問題を小さなサブタスクに分解し、それぞれのサブタスクに対してモデルの計算能力（層の深さ × パラメータ数）を割り当てることを可能にします。思考を言語化して出力するという行為そのものが、計算時間を稼ぎ、論理の深さを確保するための手段となっているのです。
中間生成トークンが果たす「ワーキングメモリ」の役割
人間が複雑な計算をするとき、紙に途中式を書きます。この「紙」の役割を果たすのが、CoTによって生成される中間生成トークンです。
LLMは自己回帰（Auto-regressive）モデルであり、自分が生成したテキストを入力の一部として再利用し、次のトークンを予測します。CoTによって「5 + (2 * 3)」という途中式が出力されると、このテキスト自体が次の推論ステップのためのコンテキスト（外部メモリ）として機能します。
- 思考なし: 入力 $x \rightarrow$ 予測 $y$ （$P(y|x)$）
- CoTあり: 入力 $x \rightarrow$ 思考 $z$ $\rightarrow$ 予測 $y$ （$P(z|x) \cdot P(y|x, z)$）
この数式的な違いは決定的です。中間思考 $z$ がコンテキストに含まれることで、最終的な答え $y$ を導き出すための条件付き確率が劇的に精緻化されます。モデルは自分の出力した思考を「足場」にして、より高い論理の梯子を登ることができるのです。
Wei et al. (2022) が示したパラダイムシフト
Weiらの研究で特に興味深いのは、スケーリング則（Scaling Laws）との関係です。彼らは、CoTの効果がモデルサイズに強く依存することを発見しました。
- 小規模モデル（< 10Bパラメータ）: CoTを行っても精度が変わらない、あるいは逆に低下する場合がある。論理的な思考を生成する能力自体が不足しているため、思考の連鎖が支離滅裂になりがち。
- 大規模モデル（> 100Bパラメータ）: モデルサイズが大きくなるにつれて、CoTによる精度向上の幅が指数関数的に大きくなる（創発的特性）。
これは、ある程度の規模を超えたLLMにおいてのみ、「論理的思考能力」が発現することを示唆しています。したがって、皆さんが開発現場でCoTを導入する場合、使用しているモデルの規模（あるいは能力）が、CoTを使いこなせるレベルにあるかを常に見極める必要があります。
例えば、Llamaシリーズの最新大規模モデル（70Bクラスや405Bクラス）であれば間違いなく効果を発揮しますが、エッジ向けの軽量モデル（8Bクラス）の場合は、タスクの難易度によって慎重な検証が必要です。最新の研究では小規模モデルでもCoTの恩恵を受けられるよう調整された派生モデルも登場していますが、基本的にはモデルの「推論の深さ」はパラメータ規模と相関する傾向にある点を理解しておくべきでしょう。
CoTのバリエーションと「思考設計」の戦略
CoTの原理を理解したところで、具体的な実装戦略について見ていきましょう。「思考の連鎖」を引き出す方法は一つではありません。状況やコストに応じて使い分ける必要があります。まずは動くプロトタイプを作り、仮説を即座に検証していくアプローチが有効です。
Zero-shot CoT：「順を追って考えて」の魔力
Weiらの論文の数ヶ月後、東京大学のKojimaらが発表した "Large Language Models are Zero-Shot Reasoners" は、さらに驚くべき発見をもたらしました。
それは、複雑な思考例（Few-shot）を与えなくても、単にプロンプトの末尾に "Let's think step by step"（ステップ・バイ・ステップで考えてみましょう） という魔法のフレーズを追加するだけで、LLMが自発的に思考プロセスを開始し、精度が向上するというものです。
この Zero-shot CoT の意義は計り知れません。これにより、タスクごとの詳細なデータセットを用意しなくても、汎用的に推論能力をブーストできることが証明されました。プロンプトエンジニアリングの初期段階や、特定のドメイン知識が必要ない一般的な論理タスクにおいては、まずこのアプローチを試すべきです。
実装のヒント:
日本語環境においては、「ステップ・バイ・ステップで考えてください」という直訳よりも、「段階的に論理立てて説明してください」や「結論を出す前に、思考プロセスを書き出してください」といった指示の方が、より高品質な日本語の思考を引き出せる場合があります。
Few-shot CoT：思考の型を例示する
しかし、実務レベルの複雑な業務システム設計などでは、Zero-shotだけでは不十分なケースが多々あります。モデルが勝手に考えた思考プロセスが、我々の期待するビジネスロジックやフォーマットと異なる場合があるからです。
ここで重要になるのが、本来の Few-shot CoT です。2026年現在、ChatGPTやClaude、Geminiなどでは、処理可能な情報量（コンテキストウィンドウ）が100万〜200万トークン規模へと飛躍的に拡大しています。しかし、どれほどモデルが進化しても、この手法の重要性は変わりません。むしろ、モデルの能力を最大限に引き出すための標準的な手法として定着しています。
これは、質問（Q）と回答（A）のペアを与える際に、回答の中に「思考過程（Thought）」を明示的に含める手法です。公式情報や検証結果によれば、3〜5個の良質な例示を与えることで、出力精度とフォーマットの制御性が大幅に向上することが確認されています。
例（金融ドメインの分類タスク）:
Q: 以下のニュースは、対象企業の株価にとってポジティブですか？
「対象企業は第3四半期の決算で、市場予想を上回る利益を計上したが、半導体不足による来期の生産遅延リスクを公表した。」A:
思考:
- まず、決算内容は「市場予想を上回る利益」であり、これはポジティブ要因である。
- 次に、将来の見通しとして「生産遅延リスク」が公表されており、これはネガティブ要因である。
- 短期的には好材料だが、将来の成長懸念という悪材料が含まれている。
- 株式市場は将来のリスクをより重視する傾向があるため、総合的には中立からややネガティブと判断される可能性があるが、ここでは混合要因として扱う。
結論: ニュートラル（混合要因）
このように「思考の型」を例示することで、モデルに「どのように考えるべきか」という推論のアルゴリズムを教え込むことができます。これは実質的に、自然言語を使ったプログラミングです。さらに最新のトレンドとして、このFew-shot CoTにJSON Modeなどの構造化出力機能を組み合わせることで、システム連携に耐えうる堅牢なAIエージェントを構築することが一般的になっています。
Manual vs Auto CoT：コストと精度のトレードオフ
Few-shot CoTの課題は、「思考例を作るのが面倒」という点です。これを解決するために、Auto-CoT（Zero-shot CoTを使って思考例を自動生成させ、それをFew-shotとして利用する手法）なども提案されています。
しかし、長年の開発現場で培った知見から言えば、「クリティカルなタスクにおいては、人間が手動（Manual）で作成した高品質な思考例を使うべき」です。自動生成された思考には誤りやノイズが含まれる可能性があり、それが推論の質を下げてしまうリスクがあるからです。
また、CoTには明確なコスト（トークン課金とレイテンシ）がかかります。思考プロセスを出力する分、出力トークン数は数倍に膨れ上がります。リアルタイム性が求められるチャットボットなどでは、このレイテンシが致命的になることもあります。その場合は、思考プロセスをユーザーに見せないように隠蔽するか、あるいは蒸留（Distillation）技術を用いて、CoTなしでも推論できるようにモデルをファインチューニングする戦略も検討すべきです。
推論精度の限界を突破する：CoTの発展系アプローチ
CoTは強力ですが、万能ではありません。一度間違った思考ステップを踏むと、その後の推論がすべて崩れる「エラーの連鎖」が起こりやすいという弱点があります。この問題を解決するために、より高度な推論アーキテクチャが開発されています。
Self-Consistency：多様な思考パスの多数決
人間も難しい問題を考えるとき、一度出した答えに自信が持てなければ、別の角度から考え直すことがあります。これをAIにやらせるのが Self-Consistency（自己整合性） です。
仕組みはシンプルですが強力です。
- 同じプロンプト（CoT付き）に対して、温度パラメータ（Temperature）を少し上げて、複数の異なる推論パス（回答案）を生成させる。
- 生成された複数の回答の中で、最も多く出現した答え（多数決）を最終的な回答として採用する。
Wang et al. (2022) の研究によれば、この手法は単一のCoTよりも圧倒的に高い精度を叩き出します。特に、推論ルートは違っても答えが一つに定まるような数学・論理問題において効果絶大です。APIコストは生成数に比例して増えますが、精度の安定性を最優先する業務アプリケーションでは必須の実装パターンと言えます。
Tree of Thoughts (ToT)：探索的推論の実装
さらに複雑な問題、例えば「小説のプロット作成」や「複雑なシステム設計」のような、答えが一つではない、あるいは探索が必要なタスクには、Tree of Thoughts (ToT) が有効です。
これは、CoTをさらに一般化し、思考を「木構造」として探索する手法です。
- 分解: 問題を複数のステップに分解する。
- 生成: 各ステップで複数の候補（思考の枝）を生成する。
- 評価: 各候補が有望かどうかをモデル自身（あるいは外部チェッカー）に評価させる。
- 探索: 有望な枝を選んで次のステップに進む（BFSやDFSなどの探索アルゴリズムを使用）。
ToTは、将棋や囲碁のAIが「数手先を読む」のと似たプロセスをLLMに行わせるものです。従来のプロンプトエンジニアリングが「一本道」の思考だったのに対し、ToTは「試行錯誤」と「バックトラック（やり直し）」を可能にします。実装コストは高いですが、AIエージェントや自律型システムの中核技術として注目されています。
ReAct：行動と思考のループ
最後に触れておきたいのが、ReAct (Reasoning + Acting) です。これはCoT（思考）と外部ツールへのアクセス（行動）を組み合わせたものです。
「思考 $\rightarrow$ 行動（検索APIを叩くなど） $\rightarrow$ 観測（検索結果を得る） $\rightarrow$ 再考 $\rightarrow$ 回答」というループを回すことで、LLMは自身の知識の限界を超え、最新情報や正確な計算に基づいた回答が可能になります。LangChainなどのフレームワークでエージェントを作る際、このReActパターンが標準的に使われています。
実践への示唆：CoTが「効く」タスクと「効かない」タスク
これまでの解説を踏まえ、実務においてCoTを導入すべきかどうかの判断基準（境界線）を整理しましょう。
タスクの複雑性とモデルサイズの境界線
すべてのタスクにCoTが必要なわけではありません。むしろ、単純なタスクでCoTを使うと、冗長な出力によってユーザー体験を損なうだけでなく、余計な情報を生成することでハルシネーションを誘発することさえあります。
CoTが推奨されるケース（システム2領域）:
- 数学的計算、多段階の論理推論
- コード生成、デバッグ
- 複雑な条件分岐を含むドキュメント読解
- 因果関係の分析、戦略立案
CoTが不要、または逆効果なケース（システム1領域）:
- 単純な事実検索（「日本の首都は？」）
- 挨拶、共感的な会話
- 翻訳、要約（タスクによっては思考がノイズになる）
- クリエイティブな文章生成（論理よりも感性が重視される場合）
ビジネス実装におけるROI判断基準
導入判断は、「精度の向上幅」と「コスト（料金・時間）の増加」のバランスで行うべきです。
Self-Consistencyを導入すれば精度は上がりますが、推論コストは5倍、10倍になります。エンドユーザー向けの無料チャットボットでこれをやるのは現実的ではありません。一方で、企業の意思決定支援や、医療・法務などのミスが許されない領域（High-Stakes Domain）では、コストをかけてでもCoTやSelf-Consistency、さらにはToTを実装する価値があります。
現場のエンジニアやプロジェクトを牽引するリーダーとして、単に「精度が出ない」と嘆くのではなく、「このタスクにはシステム2の思考が必要か？」「そのためのコストをビジネス側は許容できるか？」という経営と技術の双方の視点でアーキテクチャを選定してください。
結論：プロンプトエンジニアリングから「認知アーキテクチャ設計」へ
Chain-of-Thoughtは、単なるプロンプトのテクニックではありません。それは、確率的な単語予測器であるLLMに対して、擬似的な「認知プロセス」を実装するための設計思想です。
これからのAIエンジニアに求められるスキルは、もはや「上手なプロンプトを書くこと」だけではありません。LLMという演算装置を核として、メモリ（RAG）、思考回路（CoT/ToT）、行動（Tools）を組み合わせ、信頼性の高い「認知アーキテクチャ」を構築する能力です。
OpenAIの最新モデル（OpenAIの推論モデルなど）が示唆するように、AIモデル自体が内部でCoTを行う時代が到来しつつあります。しかし、その「思考の中身」を制御し、ビジネスの目的に合致させるためには、我々エンジニアがそのメカニズムを深く理解し、最短距離でビジネス価値を生み出す設計を描ける必要があります。
ブラックボックスからの脱却は、AIに「考えさせる」ことから始まります。まずは動くプロトタイプを作り、あなたのシステムにも「思考の連鎖」を組み込んで、その真のポテンシャルを引き出してください。
AI開発の旅はまだ始まったばかりです。共に、より賢く、実用的なシステムを築いていきましょう。
コメント