Chain of ThoughtとTree of Thoughtsの違い：探索が役立つ条件

Chain of Thoughtと比べ、Tree of Thoughtsによるプロンプティングでモデル呼び出しを増やす意味があるのは、解を完成させる前に途中の候補を評価できる場合です。小さな探索でも、以下の計算例では、基準となる1回の呼び出しが21回に増えます。まずは推論モデルを使った構成を基準にし、探索で改善できる失敗に絞って分岐を加えましょう。

出典の確認日：2026年10月24日。 以下のベンチマーク結果はすべて、Shunyu Yaoらによる2023年の原論文に基づいています。分岐の具体例とモデル呼び出し回数は、仕組みを説明するための計算であり、本番運用で報告された実績ではありません。

Tree of Thoughtsとは？ 分岐・評価・枝刈りの仕組み

Tree of Thoughts（ToT、思考の木）は、未完成の解をアプリケーション側で比較し、どの候補を先に進めるか選べるようにする枠組みです。大規模言語モデル（LLM）が次の一手を提案し、評価器がその結果の状態を判定し、探索手続きが残す候補、展開する候補、捨てる候補を決めます。Yaoらがこの枠組みを発表したのは2023年5月です。原論文の手法解説。

建物の中で経路を探す場面を考えてみてください。分かれ道に来たら、進路を決める前にいくつかの通路を確かめられます。行き止まりなら、それ以上調べる必要はありません。通れそうな通路は候補として残し、別の通路を調べることもできます。まだ引き返すコストが小さいうちに進路を変えられる点に価値があります。

**思考（thought）**とは、途中の作業を扱いやすく区切った単位です。数式、クロスワードの解答候補、文章の構成案などが該当します。**状態（state）**には、元の問題と、そこまでにできた部分的な解を記録します。思考の単位は、評価できるだけのまとまりを持ちつつ、別案を試す意味がある程度には小さくする必要があります。

このループは、次の三つの操作で構成されます。

• 分岐： 現在の状態から、互いに異なる次の一手を提案します。
• 評価： 各候補の状態が制約を満たすか、有効な答えに到達する見込みがあるかを確認します。
• 枝刈り： 不採用の状態はそれ以上展開せず、残りの予算を有望な候補に使います。

論文では、これらの操作を幅優先探索と深さ優先探索に組み合わせています。幅優先探索は同じ深さにある有望な候補を残し、深さ優先探索は一つの枝をたどって、行き詰まれば前の分岐に戻ります。どちらを使うかはタスクに応じて選びます。いずれも、新しいモデルの学習は必要ありません。枠組みと探索アルゴリズム。

開発者にとって本質的な変化は、解の途中にある選択肢を制御できることです。深く考えているような文章をモデルに求めるだけでは、アプリケーションにその制御権は生まれません。

Chain of ThoughtとTree of Thoughtsは何が違う？

違いは、選択肢を比較するタイミングです。解がまだ途中の段階で比べるのか、それとも答えが最後までできてから比べるのか、という点にあります。

この区別は、Yaoらの論文の背景と手法で説明されています。標準的なSelf-consistencyは、推論経路を最後まで複数サンプリングし、最も多く現れた答えを選びます。そのため、どの答えを同じものとみなすかを適切に判定できる必要があります。自由な文章の多数決は、数値の答えを数えるほど単純ではありません。

Chain-of-thoughtプロンプティング（思考の連鎖）は、途中の作業を言葉にするのに役立ちます。Self-consistencyは、完成した試行全体に多様性を持たせます。ToTが加えるのは、見込みの薄い経路を最後まで進めるコストを払う前に止められるコントローラーです。ただし、その制御によって、続ければ成功した経路を切り捨てるという新たな失敗も生じます。

関連する二つの手法は、それぞれ別の問題を解きます。Few-shotプロンプティングは、求める振る舞いや出力形式の例を示すもので、生成器や評価器に仕様を守らせる助けになります。プロンプトチェーンは、事実を抽出してから返信を作る、といった処理段階をつなぎます。決まった順序の処理が探索になるのは、複数の候補を保持し、どれを調べるか判断する仕組みが加わったときです。

失敗の原因に合う、最もシンプルな構成を選びましょう。形式が安定しないなら、より明確な例や検証が必要です。根拠が足りないなら、情報検索が必要です。どちらも、それだけで木構造の探索が必要になるわけではありません。

具体例で見る分岐・評価・枝刈り

途中の計算式が正しくても、その先が行き止まりになることはあります。評価器が見分けるべきなのは、この違いです。

論文のGame of 24の例を使います。4、9、10、13をそれぞれちょうど一度ずつ使い、四則演算で24を作る問題です。以下は仕組みを説明するために組み立てた手順であり、モデルが実際に出力した記録ではありません。各状態から解に到達できるかどうかは、残りの演算の組み合わせを列挙して確認しています。論文で使われた入力例。

1. 1

   初期状態から候補を分岐させる

   候補Aでは4 + 9 = 13を計算し、10, 13, 13が残ります。

   候補Bでは13 - 9 = 4を計算し、4, 4, 10が残ります。

   どちらの計算もルールに沿っています。同じ数字が並んでいても、それぞれ別の残りの値です。状態を記録するときは、同じ値がいくつあるかも保持しなければなりません。

2. 2

   分岐後の状態を評価する

   候補Aは、残りの値をそれぞれ一度ずつ使い、足し算・引き算・掛け算・割り算をしても24にはなりません。この枝は切り捨てます。

   候補Bには、解へ進む方法があります。10から残っている4の一つを引き、その結果にもう一つの4を掛けます。この枝は残します。

   この例では、判定の妥当性を確かめられるよう、厳密な算術チェックを使っています。一方、論文の探索では、モデルによる価値の推定を使っており、その評価は間違うことがあります。

3. 3

   残した枝をさらに展開する

   4, 4, 10から、4 + 4 = 8を計算して8, 10を残すか、10 - 4 = 6を計算して4, 6を残すかを考えます。

   前者は、残りの演算で24を作れません。後者なら4 × 6 = 24になります。後者を残し、完成した式を検証します。

4. 4

   最終的な答えを確認する

   (13 - 9) × (10 - 4) = 24は、元の数字をすべて一度ずつ使い、計算結果も目標の値になります。タスクのチェックに合格したので、探索を終了します。

この小さなパズルなら、全探索のソルバーだけで解けるため、LLMを加えるのは余計な実装です。この例の目的は、ループの仕組みを示すことです。実際のアプリケーションでは、もっともらしい計画をモデルが提案し、モデルに推測させるべきでない制約をコードで確認する、という役割分担がよく役立ちます。

Tree of Thoughtsの論文では何が報告された？

原論文の結果は、著者らが選んだタスクで、探索を明示的に組み込むことが有効だったと示しています。現在の本番ワークロードで、どの程度の改善を期待できるかまで示すものではありません。

Game of 24では、比較的難しい100問を使ってGPT-4を評価しています。実験が行われたのは2023年5月です。表2に報告されている成功率は次のとおりです。

出典：Yaoら、表2とGame of 24の実験設定。

探索幅は保持する状態の数であり、モデル呼び出し回数ではありません。 候補の生成と評価には、それぞれ処理が発生します。Game of 24の設定では、各候補の価値を三回ずつサンプリングしていました。実験設定。

論文では、Creative WritingとMini Crosswordsも扱っています。ただし、タスクも評価方法も異なります。実務上の結論は、「ToTでモデルが賢くなる」というほど広いものではありません。有望な途中の方向性を選ぶことが重要で、かつその方向性を評価できる場合に、探索が役立つ可能性があるということです。コントローラーを導入する前には、対象のワークロードで確かめる必要があります。

分岐を増やすとモデル呼び出しは何回になる？

生成・評価・最終出力を分けて数えましょう。候補の生成器より、評価器のほうが多くの呼び出しを消費する場合があります。

ここでは、論文の設定とは別に、上限を設けた探索の計算例を考えます。呼び出しとは、アプリケーションがモデルに送る一回のリクエストです。一つの親状態に対する提案リクエスト一回で、すべての子候補を生成し、各子候補の評価にはそれぞれ別のリクエストを使うとします。再試行も早期終了も行わず、決めた深さで探索を止め、最後に一回の呼び出しで回答を作ります。

展開する親ごとに子候補を三つ作り、各階層で二つの状態を残し、三階層にわたって展開します。展開する親の数は、順に1、2、2です。したがって、回数は次のようになります。

• 生成： 1 + 2 + 2 = 5回。
• 評価： 3 × (1 + 2 + 2) = 15回。
• 最終回答： 1回。
• 合計： 5 + 15 + 1 = 21回。つまり、1回で済む基準構成の21倍です。

各候補の評価を三回繰り返すと、同じ木でも5 + 45 + 1 = 51回になります。各階層の候補を一つのリクエストでまとめて評価すれば、5 + 3 + 1 = 9回になります。ただし、まとめることで評価器に渡るコンテキストや判断条件は変わります。これは実装上の選択肢であり、同じ品質を保てるという約束ではありません。

比較として、Self-consistencyで五つのサンプルを個別にリクエストし、最後の多数決を決定的なコードで行うなら、モデル呼び出しは五回です。別のモデルを判定役に加えれば呼び出しが増え、比較条件も変わります。

一般的な計算式はC = Σ nₜ(g + kv) + fです。nₜは階層tで展開する親の数、gは親ごとの生成リクエスト数、kは親ごとの子候補数、vは子候補ごとの評価リクエスト数、fは最終出力のリクエスト数を表します。この式は、子候補を個別に評価する前提です。まとめて評価する場合は、その実際のリクエスト数を直接数えてください。

LLMでTree of Thoughtsを実装するための設計

探索状態と停止条件は、アプリケーションのコードで管理します。モデルには、範囲が明確で中身を確認できる候補の提案と評価を任せます。

この構成で壁になるのは、評価器の品質です。解につながる部分解と、もっともらしいだけの行き止まりを区別できないなら、枝を増やしても、誤った選択をする機会が増えるだけです。

1. 1

   検査できる状態を定義する

   制約付きのスケジューリング機能なら、割り当て済みの仕事、未割り当ての仕事、埋まっている時間枠、まだ満たしていない制約などを状態に含められます。次の思考の単位は、割り当て案と定義します。状態、候補ID、親ID、判断の根拠は分けて保存します。

   その段階で検査できるものを選びましょう。「よい戦略を考えています」といった曖昧な段落では、確かな根拠を持って枝刈りすることが難しくなります。

2. 2

   生成と評価に別々の役割を与える

   生成器への指示は、たとえば次のようにします。「この状態から、互いに異なる次の割り当てを提案してください。候補ごとに、割り当て内容と更新後の状態を返してください。列挙された制約を守ってください。」

   評価器への指示は、たとえば次のようにします。「各候補を制約に照らして確認してください。候補ID、違反している制約、そしてその候補から先に進める見込みを、実行可能・不確実・不可能のいずれかで返してください。判断の根拠となる状態のフィールドを示してください。」

   時間枠の重複や必須フィールドの欠落といったルールには、まず決定的なチェックを使います。モデルの判断が必要なら、LLM-as-a-judgeの評価手順を使い、正解がわかっているケースに照らして検証してください。

3. 3

   枝刈りの条件と探索予算を明示する

   必須の制約に違反する状態は除外します。残りの候補に順位を付け、次に展開する候補の数に上限を設け、重複する状態を取り除きます。予算が許すなら、不確実な候補も残しておきましょう。評価器の確信度が低いことは、その枝が不可能である証拠ではありません。

   リクエスト数、深さ、トークン数、経過時間の上限は、コントローラーで強制します。評価と再試行も上限に含めます。何を、なぜ捨てたかを記録し、成功する経路を枝刈りで失ったケースを検証できるようにしましょう。

4. 4

   採用や実行の前に最終確認する

   スケジューリングの制約をすべて満たしているか、関連するソフトウェアテストが通るか、といった最終チェックを設けます。予算を使い切るまでに合格する候補が見つからなければ、未解決として返すか、レビューに回します。

   枝の探索は、サンドボックス内か、実行前の提案として扱います。検討中のスケジューリングの枝から招待を送ってはいけません。コントローラーがまだ候補を比較している間に、コード変更の枝がデプロイを実行してもいけません。

最終的な答えだけでなく、評価器も測定の対象にします。誤って不採用にすれば、有望な枝を完全に失う可能性があります。誤って採用すれば、残りの予算を行き止まりの展開に費やす可能性があります。この二つの失敗には、それぞれ別の対策が必要です。

推論モデルだけで十分なのはどんなとき？

推論モデルがすでに品質とレイテンシーの要件を満たし、アプリケーション側で途中の選択肢を制御する必要もなければ、外部にToTを実装する必要はありません。

推論モデルは、回答の前に内部で処理を行います。Anthropicの現行プロンプティングガイドは、思考機能を持つモデルに対し、推論の各ステップを細かく指定するより、全体の目標を与えることを勧めています。この方針からも、まずタスク、制約、受け入れ条件を明確に伝える構成を試すのが妥当です。ただし、特定のモデルが内部でYaoらのToTアルゴリズムを実装していると示しているわけではありません。Anthropicのプロンプティングガイド。

小さなコード変換機能を追加するなら、まず適切な推論モデルを使い、その結果に関連するテストを実行してみてください。基準となる構成がリリース条件を満たすなら、外部の探索木を加えても、利点が確かでないまま状態管理、評価、失敗時の処理が増えます。

一方、アプリケーション側から何かを加えられるなら、外部探索は引き続き選択肢になります。シミュレーター、制約チェッカー、隔離したテスト環境がある場合や、異なる計画候補を保持する必要がある場合などです。より高性能なモデルを、その探索の生成器として使うこともできます。モデルによる推論と、アプリケーションが制御する探索は、別々の設計上の選択です。

判断は実測に基づいて行います。測定したリソース消費に見合うだけ、検証済みの成果が改善する場合にだけ探索木を残しましょう。回答が長くなったことや、処理の記録が凝ったものになったことは、成功の基準ではありません。

Tree of Thoughtsで過大評価されがちなこと

架空の専門家同士で議論するように頼むプロンプトだけでは、制御された木探索にはなりません。複数案は出せるかもしれませんが、本番向けのToTには、明示的な状態、評価、分岐の選択、停止方針が必要です。それらが一回の生成の中にしか存在しないなら、指定した探索が意図どおり実行されたと考えることはできません。

もう一つの過大評価は、枝を増やせば必ず答えがよくなるという考えです。別の枝でも同じ発想を繰り返すことがあります。判定役が生成器と同じ誤った前提を共有している場合もあります。早い段階の枝刈りで、唯一有効な続き方を捨ててしまうこともあります。自信のある言い回しは、タスクのチェックの代わりにはなりません。

また、論文のGame of 24で得られた最良の結果は、あらゆる業務ワークフローにToTが必要だという証拠ではありません。スキーマに合わない出力を返す文書抽出器に必要なのは、よりよい例と検証かもしれません。社内規定を把握していないサポートアシスタントには、適切な情報源が必要かもしれません。同じ情報不足のまま経路をいくら増やしても、欠けている事実は手に入りません。

評価できる代替案を選ぶために探索を使いましょう。足りないコンテキストや、守られていない入出力の仕様は、直接直すべき問題です。

今週の開発で、何から変えるべき？

失敗したケースに、初期の選択を変えれば立て直せるものがあり、途中の状態を信頼できる方法で採点できるなら、着手する意味があります。たとえば、隔離した環境でコード変更の候補を検査する場合や、明示的なスケジューリング制約に照らして計画を検証する場合です。まずは対象を絞り、探索予算を固定して始めましょう。

ある部分解が別の部分解よりよい理由をまだ説明できないなら、導入を待つべきです。採用できる状態とできない状態の事例を集め、評価器の判断を確認し、その精度を改善してから木を広げましょう。

単純な抽出や分類、または固定された処理順序のワークフローがすでに受け入れ条件を満たしているなら、大きな変更は必要ありません。そのシンプルな構成を維持してください。

週明けに行うことは具体的です。現在のChain-of-thoughtワークフローから失敗事例を集め、調整に使っていない同じ評価用タスクで、推論モデルを使った基準構成と、探索範囲を制限したToT構成を比較します。最終的な検証器は変えません。受け入れられた結果、モデル呼び出し回数、トークン数、レイテンシー、そして成功する経路を枝刈りで失ったケースを記録します。その結果から有効だと判断できるタスクの範囲にだけ、探索を導入しましょう。

Tree of Thoughtsについてよくある質問

推論とChain-of-Thoughtは同じものですか？

推論は、問題を考えて解いていく能力全般を指します。Chain-of-thoughtは、中間ステップを使うプロンプティング手法です。モデルは、そのステップを回答に表示しなくても、内部で推論を行えます。

AIでいう木構造とは何ですか？

木構造は、状態と、その先に取り得る行動を表します。ノードが一つの状態に対応し、その子ノードは次の一手で到達する別々の候補です。ToTでは、それぞれの状態が部分的な解を表します。

推論を木構造にするとは、どういう意味ですか？

ここでは、複数の部分解を枝として整理し、評価して、どれを先に進めるか選ぶことを指します。Yaoらが提案した具体的な枠組みがTree of Thoughtsです。

Tree of Thoughtsプロンプティングとは何ですか？

言語モデルに途中の選択肢を提案・評価させ、どの状態を展開するか選ぶ探索手続きと組み合わせる手法です。実務上の利点は、答えを最後まで作る前に、途中の判断を見直せることです。

プロンプティングの「三つのC」とは何ですか？

YaoらのToTアルゴリズムは、三つのCというルールを定義していません。この覚え方はToTの仕様ではありません。論文で説明されているのは、思考の分解、生成、状態の評価、探索です。

Chain of ThoughtとTree of Thoughtsの主な違いは何ですか？

標準的なCoTは、一つの連続した推論経路を生成します。ToTは、途中までの別の経路を明示的に検討し、探索中に評価します。Self-consistencyはさらに異なり、完成した経路をサンプリングして、最終的な答えを集約します。

Chain of Thoughtプロンプティングの具体例はありますか？

計算の解き方の例として、13 - 9 = 4、次に10 - 4 = 6、最後に4 × 6 = 24という手順を示せます。このような中間ステップを例として与えるのがCoTの一例です。別の手順と比較して、どの枝を残すか決める仕組みを加えると、ToTの探索になります。

Chain-of-Thoughtを簡単にいうと、どんな手法ですか？

計算や推論といった中間ステップを介して、問いと答えをつなぐ手法です。途中のステップがあると内容を追いやすくなりますが、そのステップ自体に間違いが含まれることはあります。

Chain-of-Thoughtは、実際にはどう動くのですか？

標準的なプロンプティングでは、モデルが問題と、それまでに生成したテキストに基づいて中間ステップを順に生成し、その後に答えを出します。その一連の生成だけでは、正しさを独立して確認する仕組みも、アプリケーションが管理する探索候補群も得られません。

信頼できるAIワークフローを構築するための実践ガイドは、ニュースレターに登録してお受け取りください。