Tree of Thoughts（ToT）：探索的推論で複雑な問題を解くプロンプティング
LLMに複数の思考パスを探索・評価・バックトラックさせることで、従来のCoTでは解けなかった問題を解決するTree of Thoughtsを実践的に解説します。
Tree of Thoughts（ToT）とは
Tree of Thoughts（ToT）は、Yao et al.（2023）がNeurIPS 2023で発表した、LLMの問題解決能力を飛躍的に向上させるプロンプティングフレームワークです。Chain-of-Thought（CoT）が「一本道の推論」であるのに対し、ToTは複数の推論パスを木構造で探索し、各パスを自己評価してバックトラック（後戻り）も行うという、より人間の熟考プロセスに近いアプローチを取ります。
従来のCoTでは、一度誤った推論ステップに進むと修正が困難でした。ToTは「思考（Thought）」を中間ステップの単位とし、幅優先探索（BFS）や深さ優先探索（DFS）といったアルゴリズムで複数の候補を並行的に探索します。これにより、局所最適に陥らずに正解へ到達できる可能性が大幅に高まります。
核心的なアイデア：4つの構成要素
ToTフレームワークは以下の4つの要素で構成されます。
1. 思考の分解（Thought Decomposition）
問題を中間ステップ（思考）に分解します。各思考は、モデルが生成・評価できる程度のまとまりを持ちます。
2. 思考の生成（Thought Generation）
各ステップで複数の候補思考を生成します。方法は2つあります。
- サンプリング（Sample）：同じプロンプトから独立して複数の思考を生成
- 提案（Propose）：「次に可能なステップを全て列挙せよ」と指示して候補を一括生成
3. 状態の評価（State Evaluation）
各思考パスの有望さをLLM自身に評価させます。
- 値による評価（Value）：各状態に「確実/おそらく/不可能」のようなラベルを付与
- 投票による評価（Vote）：複数の候補から最も有望なものに投票
4. 探索アルゴリズム（Search Algorithm）
- BFS（幅優先探索）：各レベルで上位b個の状態を維持。浅い問題に適する
- DFS（深さ優先探索）：有望な状態を深く探索し、行き詰まればバックトラック。深い問題に適する
驚異的な成果：Game of 24
ToTの威力を最も端的に示すのが「Game of 24」（4つの数字と四則演算で24を作る）タスクです。
| 手法 | 成功率 |
|---|---|
| 標準プロンプト（IO） | 7.3% |
| Chain-of-Thought | 4.0% |
| CoT + Self-Consistency（SC） | 9.0% |
| ToT（b=1） | 45% |
| ToT（b=5） | 74% |
CoTの4.0%からToTの74%へ、実に18.5倍の改善です。
実践：プロンプト例
例1：簡易ToTプロンプト（シングルプロンプト版）
複数のAPI呼び出しなしで、ToTの考え方をシングルプロンプトに組み込む方法です。
あなたは3人の異なる専門家です。それぞれが独立して問題を解きます。
問題：4, 9, 10, 13 の4つの数字を、四則演算（+, -, *, /）を使って
ちょうど24にしてください。各数字は1回ずつ使います。
手順：
1. 各専門家は独立してステップバイステップで解法を考えます
2. 各ステップで「残りの数字」を明示します
3. 行き詰まった場合は別のアプローチを試します
4. 全専門家の解法を比較し、正しいものを選びます
専門家1の思考：
専門家2の思考：
専門家3の思考：
最終回答：例2：段階的な思考生成と評価（マルチステッププロンプト）
実際のToTに近い形で、生成と評価を分離するアプローチです。
ステップ1：候補生成プロンプト
以下のビジネス課題に対して、3つの異なるアプローチを提案してください。
各アプローチは1-2文で簡潔に述べてください。
課題：従業員200名の製造業がDXを推進したいが、
IT部門は2名しかおらず、現場のITリテラシーも低い。
アプローチ1：
アプローチ2：
アプローチ3：ステップ2：評価プロンプト
以下の3つのアプローチを、「実現可能性」「コスト効率」「社員の受容性」の
3つの観点で評価してください。各観点を1-10で採点し、
最も有望なアプローチを選んでください。
アプローチ1：{ステップ1の出力1}
アプローチ2：{ステップ1の出力2}
アプローチ3：{ステップ1の出力3}
評価後、最も有望なアプローチをさらに詳細化してください。例3：コード設計におけるToT的アプローチ
あなたはソフトウェアアーキテクトです。以下のシステム設計について、
3つの異なるアーキテクチャ案を提示し、それぞれを自己評価してください。
要件：
- リアルタイムチャット機能を持つWebアプリ
- 同時接続数：最大10,000
- メッセージの永続化が必要
- 将来的にモバイルアプリも対応
各案について以下を記述：
1. アーキテクチャの概要（2-3文）
2. 技術スタック
3. メリット（箇条書き）
4. デメリット・リスク（箇条書き）
5. 自己評価スコア（スケーラビリティ、開発速度、保守性を各10点満点）
最後に、最も推奨する案とその理由を述べてください。いつ使うべきか
ToTが特に効果を発揮するのは以下の場面です。
- 正解への道筋が複数ある問題：数学パズル、コード設計、戦略立案
- 試行錯誤が必要な問題：一度の推論で正解に辿り着けない、探索が必要なタスク
- 判断基準が明確な問題：各ステップの良し悪しを評価できる場合
- 重要な意思決定：複数の選択肢を比較検討する必要がある場面
逆に、以下の場合はCoTやシンプルなプロンプトで十分です。
- 単純な分類・翻訳タスク
- 正解が一意に決まる事実確認
- リアルタイム応答が求められる場面
注意点・限界
コストとレイテンシ
ToTは探索の幅（b）に比例してAPI呼び出し回数が増加します。CoTと比較して5〜100倍のトークンを消費する場合があります。本番環境での利用にはコスト試算が必須です。
評価精度の限界
LLM自身が思考パスを評価するため、モデルの能力を超える問題では評価自体が不正確になります。「自分が間違っていることに気づけない」場面では効果が限定的です。
実装の複雑さ
本格的なToTの実装には、状態管理・探索アルゴリズム・評価ロジックなどのオーケストレーションコードが必要です。シングルプロンプト版は手軽ですが、本来のToTの探索能力には及びません。
推論モデルとの関係
2025年以降の推論モデル（o1、DeepSeek-R1等）は内部的にToT的な探索を行う場合があります。これらのモデルに対してToTを外部から適用すると冗長になり、逆効果になることがあります。