9月8日、Vinod Chuganiが「Chain of Thought vs. Tree of Thoughts: Which is Best for AI Agents?」と題した記事を公開した。AIエージェントが「流暢だが静かに間違っている」回答を返す問題の根本には、推論フレームワークの選択がある——この記事はその設計判断に直接切り込む内容だ。

LLMは本来、入力から次のトークンを予測することを繰り返す仕組みであり、放置すると問いから答えへ一足飛びに跳ぶ傾向がある。単純なタスクでは問題ないが、複数ステップの推論や計画が必要な場面では「流暢だが静かに間違っている」回答を生成しやすい。この問題に対処するために生まれたのが、Chain of Thought（CoT）とTree of Thoughts（ToT）だ。

Chain of Thought：線形推論の強みと限界

CoTの核心は「途中の思考ステップを明示させる」ことにある。プロンプトに「Let's think step by step」と付け加えるだけで発動する最も単純な形から、明示的な手順指示やフューショット例示まで実装の幅は広い（関連論文：Wei et al., 2022、Kojima et al., 2022）。

推論の流れは一本道だ。問題→ステップ1→ステップ2→…→回答という構造で、数学の計算を紙に書き下ろす学生のように、各ステップが前のステップの上に積み上がる。透明性が高く、監査しやすい。

最大の弱点は、早期の誤りが伝播する点だ。 ステップ1で間違えると、その誤りはステップ2、3と引き継がれ、最終回答まで修正されない。モデルは一度動き出した推論チェーンを遡って見直さない。

とはいえ、標準的な数学問題、論理的演繹、要約タスク、日常的な推論の大半ではCoTは十分に機能する。「一本道」の制約が実質的な問題になるのは、問題が真に曖昧で複数のアプローチが考えられる場合、または早期の誤りのコストが高い場合に限られる。

Tree of Thoughts：チェスプレイヤー型の探索

ToTはCoTを非線形に拡張する。各ステップで複数の候補を生成し、それぞれを評価し、最も有望なパスを選んで進む。行き詰まればバックトラック（遡って別の枝を試す）する（関連論文：Yao et al., 2023）。

記事ではチェスプレイヤーのアナロジーが使われている。強いプレイヤーは最初に思いついた手をすぐ指さない。複数の候補手を検討し、それぞれの含意を読み、悪手を棄却し、最も有望な手をさらに深く読む。ToTはこの探索プロセスを言語モデルの推論に適用する。

アーキテクチャとしては、各ステップで複数の「続き」を生成→評価（スコアリングまたは推論による）→古典的なサーチアルゴリズムで探索順序を決定、という流れになる。

代償は大きい。 CoTが1回のプロンプト＋1回のモデル応答で完結するのに対し、ToTは難しい問題では数十〜数百回のモデル呼び出しが発生する。時間・コスト・トークン消費がいずれも大幅に増加する。

AIエージェントではどう使い分けるか

エージェントが判断を誤ったとき、その結果は「回答が間違っている」だけに留まらない。ツール呼び出しの順序、パラメータ設定、外部への操作——これらは取り消せない副作用を伴う。だからこそ推論フレームワークの選択が重要になる。

記事の結論は明快だ：

• CoTはデフォルト。データベースのクエリ決定、ユーザー意図の解釈、多ステップ計算など、ルーチン的な意思決定の大半を担う。速く、安く、ほとんどの場面で十分だ。
• ToTは専門家。「正しいアプローチが事前に不明確」「複数の実装戦略を比較したい」「早期の誤りのコストが高い」——こうした問題に使う。ソフトウェアエージェントが制約を満たす関数を実装する際に3つの戦略を生成・評価・フォールバックするシナリオや、戦略計画エージェントが複数のコースをシミュレートして最良案を選ぶシナリオが例として挙げられている。

実際のプロダクションシステムでは両者を併用するのが実態だ。CoTでルーチン判断を捌き、ToTは「複数アプローチの探索が必要かつ誤りのコストが高い」問題のサブセットに限定して使う。

選択の判断軸

記事は3つの実践的な問いを提示している。ここでのポイントは、これらが独立したチェックリストではなく、優先順位をもった判断の流れとして機能する点だ。

まず問うべきは「解法が明確かどうか」だ。解法が一意に定まるならCoTで十分であり、複数の戦略を比較・検討する必要があるときにはじめてToTが候補に上がる。

解法が不明確だと判断した場合、次に問うのが「早期ミスの影響」だ。要約タスクのように誤りが局所的なら致命傷にならない。だが計画タスクのように早期の決定が後続ステップ全体を制約する場合は高リスクであり、ToTのバックトラック能力が正当化される。

最後に問うのが「リソース制約」だ。ToTはCoTより桁違いに高コストになりうる。レイテンシ、費用、スループットへの影響は抽象論ではなく、実際の設計判断に直結する。どれほど精度が求められる問題でも、リアルタイム応答が必要なシステムでToTをフル適用することは現実的でない場合がある。

この3段階の問いを順に辿ることで、感覚的な選択ではなく根拠のある設計判断が可能になる。

設計パターンの参考文献としては、AnthropicのBuilding Effective Agentsが挙げられている。

※編集部の考察：実装面ではLangChainがCoT・ToTの両パターンをサポートしており、実際の統合先として参照されることが多い。ただし元記事がLangChainを明示的に推奨しているわけではないため、あくまで周辺情報として参照されたい。

詳細はChain of Thought vs. Tree of Thoughts: Which is Best for AI Agents?を参照していただきたい。