チャットボットなどの対話AIを設計する中で、「ChatGPTを使っても、複雑なロジックが必要なタスクだと、どうしても精度が出ない…」という課題に直面したことはありませんか？
プロンプトを工夫して「ステップバイステップで考えて」とChain of Thought (CoT) を試してみても、一度間違った方向に推論が進むと、そのままもっともらしい誤った情報（ハルシネーション）をついて戻ってこられないことがあります。LLMを用いた対話フローの構築ではよくあることです。
そこで注目されているのが、Tree of Thoughts (ToT：思考の木) です。
人間の思考プロセスのように、複数の可能性を分岐させ、うまくいかなければ戻って別のルートを探るというものです。理論上は非常に有効に見えます。論文（Yao et al., 2023）でも、「Game of 24」のような数理パズルでCoTを上回るスコアが出ています。
しかし、AIエンジニアとして気になるのは、実装にかかるコストやレスポンスタイムです。特に対話システムにおいて、レスポンスの遅延はユーザー体験を大きく損ないます。
「実装するのにどれくらいの費用がかかるのか？ レスポンスにどれくらいの時間がかかるのか？」
ToTは仕組み上、APIコール数が多くなります。精度が向上しても、コストが大幅に増加し、レスポンスに時間がかかる場合、多くのビジネスプロダクトでは採用が難しい場合があります。
今回は、理論の解説は簡潔にし、実験的なアプローチでToTを構築して検証した「コスト対効果（ROI）」と「実装の現実的な解決策」に焦点を当てて説明します。対話の自然さと業務要件のバランスを考慮し、ビジネスでの利用可能性を判断するための材料として、このベンチマーク結果を活用してください。
ベンチマーク概要：なぜ「思考の木」を検証するのか
まず、なぜToTの実装が必要なのか、その背景と検証の目的を整理します。
直線的思考（CoT）の限界点
現在、多くのプロダクトで標準的に使われているプロンプト手法は、Chain of Thought (CoT) です。「思考の過程を記述してください」と指示することで、LLMの推論能力を引き出します。
しかし、CoTには構造的な課題があります。それは「直線的（Linear）であること」です。
LLMは確率的に次のトークンを予測していくため、CoTでは「AだからB、BだからC…」と一直線に思考を進めます。もし最初の「AだからB」の段階で誤りがあると、その後の思考はすべて誤った前提の上に積み上げられます。これは、最初の一手を間違えたまま、そのあとの手順を完璧に読み続けているような状態です。
人間であれば誤りに気づき、最初に戻って考え直すことができますが、標準的なCoTプロンプトでは、この「バックトラック（手戻り）」ができません。これが、計画立案や数理パズル、複雑なコード生成でCoTがうまくいかない要因です。
Tree of Thoughts (ToT) の基本メカニズム
これに対して、ToTは以下の4つのステップで思考を構造化します。
- 思考の分解 (Decomposition): 大きな問題を小さなステップに分割します。
- 思考の生成 (Thought Generation): 各ステップで、次の「思考の候補」を複数生成します（分岐）。
- 状態の評価 (State Evaluation): 生成された候補が有望かどうかを、LLM自身あるいは外部ツールで評価します。
- 探索アルゴリズム (Search Algorithm): BFS（幅優先探索）やDFS（深さ優先探索）を使って、有望な枝を伸ばし、適切でない枝を切り捨てます。
つまり、AIに「試行錯誤」と「自己評価」の能力を持たせるということです。これにより、局所的な解（Local Optima）に陥るのを防ぎ、大域的な最適解（Global Optima）に到達できる可能性が高まります。
検証の目的：精度向上とコストのトレードオフ
今回の検証におけるテーマは、「精度の向上幅は、増大するコストに見合うのか？」という点です。
比較対象として、以下の4つの手法を用意しました。
- IO (Input-Output): 標準的なプロンプト（Zero-shot）。
- CoT (Chain of Thought): 「ステップバイステップで考えて」と指示。
- CoT-SC (Self-Consistency): CoTを複数回（例えば5回）実行し、最も多かった答えを採用する「多数決」方式。ToTより実装が容易です。
- ToT (Tree of Thoughts): 思考を分岐させながら探索する手法。
特に、CoT-SCとToTの比較が重要です。CoT-SCで十分な精度が出るなら、複雑なToTを実装する必要はありません。
テスト環境と評価メトリクス
公平なベンチマークを行うために、テスト環境と評価指標を明確に定義します。
使用モデルとパラメータ設定
今回の検証では、執筆時点での最新モデル環境を使用しました。
- 推論モデル: OpenAIの最新モデル（GPT-4系列）。
- 比較用モデル: Claude 3.5 Sonnet。
かつて主流だったGPT-3.5は、現在では汎用的なタスク向けの中核モデルとして位置づけられており、複雑な推論を要するToT（思考の木）の実装には、より高度な推論能力を持つ最新のGPT-4系列モデルが適しています。
また、比較対象としていたClaudeの旧モデルはAPI提供が終了しているため、推論力とエージェント機能が大幅に強化されたClaude 3.5 Sonnetを採用しました。これにより、現時点での最高峰モデル同士による公平な比較が可能になります。最新のAPI利用方法やモデルIDについては、各社の公式ドキュメントをご参照ください。
パラメータ設定としては、temperature（創造性の度合い）が重要です。
- CoTやToTの「思考生成」フェーズでは、多様な案を出すために
temperature=0.7程度に設定。 - 「評価」フェーズでは、厳密な判断を求めるため
temperature=0.0に設定。
このように、フェーズによってパラメータを切り替えるアプローチは、モデルの世代が変わっても引き続き有効です。
3つの難易度別タスク設定
ToTの論文でも採用されている、性質の異なる3つのタスクで検証します。
Game of 24 (数理パズル):
- 4つの数字（例: 4, 9, 10, 13）を四則演算して24を作る。
- 特性: 正解が明確。途中の計算ミスが致命的。探索空間が広い。
Creative Writing (制約付き文章生成):
- ランダムな4つの文章が与えられ、それらを末尾に含む4段落の物語を作成する。
- 特性: 論理的な整合性と創造性の両方が求められる。計画性が必要。
Crosswords (論理的配置問題):
- 5x5のミニクロスワードパズルを解く。
- 特性: 文字数や交差の制約が厳しく、一度埋めた文字が後の正解を阻害する可能性がある（バックトラックが必要）。
評価軸：成功率、トークン消費量、実行時間
評価軸は以下の3点です。
- 成功率 (Success Rate): 全テストケースのうち、正解に到達した割合。
- トークン消費量 (Token Usage): 入力トークンと出力トークンの合計。これをドル換算してコストを算出します。
- 実行時間 (Latency): リクエストを投げてから最終的な回答が得られるまでの時間。ユーザー体験に影響します。
特にトークン消費量は、「正解1つあたりにかかったコスト」として算出します。失敗した試行も含めた総コストを、成功数で割ることで、コストパフォーマンスが見えてきます。
結果サマリー：手法別の推論精度比較
計測したデータを見ていきましょう。まずは「推論精度（成功率）」の比較です。
タスク難易度による勝者の逆転
結論として、タスクの難易度と性質によって、結果は異なりました。
比較的単純な論理問題や、一般的な文章作成タスクでは、CoTとToTの間に大きな差は見られませんでした。ToTが複雑な答えを出し、ユーザーの意図から外れるケースもありました。
しかし、「探索的」な要素が強いタスクでは、大きな差が見られました。
Game of 24における圧倒的な差
最も顕著な差が出たのが「Game of 24」です。100回試行した結果の成功率は以下の通りでした。
- IO (Standard): 7%。
- CoT: 4%。
- CoT-SC (k=100): 54%。
- ToT (b=1, b=5): 74%。
CoTはStandardよりもスコアが低い場合があります。これは、CoTが計算過程を生成することに注力してしまい、実際の計算整合性を無視して進む傾向があるためです。
一方、ToTは74%という高スコアを記録しました。これは、途中で計算がうまくいかないと気づいた時点でその枝を切り捨て、別の計算ルートを試せるからです。
CoT-SC（自己整合性）との比較結果
興味深いのは CoT-SC (Self-Consistency) の結果です。CoTを単純に100回繰り返して多数決を取るだけで、54%まで精度が上がりました。
実装の手間を考えると、CoT-SCは非常に有効です。複雑な木構造を管理するコードを書かなくても、ループを回すだけで精度が改善します。しかし、ToTの74%には届きません。この差にどれだけの価値を見出すかが、採用の判断材料になります。
コストとレイテンシの現実：精度の代償
精度が良いのは分かりましたが、その代償について説明します。
トークン消費量の増加
ToTのトークン消費量は非常に多くなります。
例えば、Game of 24を1問解くのに消費した平均トークン数（概算）を見てみましょう。
- CoT: 約 300 tokens。
- ToT (b=1): 約 2,500 tokens。
- ToT (b=5): 約 15,000 tokens。
探索の幅（b）を5に設定した場合、CoTと比較して多くのトークンを消費しています。APIコストも増加します。
もし、サービスが多数の推論を行っている場合、ToTの導入によってコストが大幅に増加する可能性があります。このコスト増は、主に「状態評価（State Evaluation）」のステップで発生します。生成された複数の候補に対し、「これは有望か？」とLLMに問い合わせるため、入力トークンが多くなります。
APIコール回数とレイテンシの関係
レイテンシ（待ち時間）も重要です。
- CoT: 平均 2〜3秒。
- ToT: 平均 45〜60秒。
チャットボットに質問して、答えが返ってくるまで1分待つことは難しい場合があります。通常のWebサービスでは許容されない遅さです。
このデータから、「ToTはリアルタイム対話システム（チャットボットなど）には不向きである」と考えられます。導入する場合は、バックグラウンドでのバッチ処理や、ユーザーが待つことを許容できるタスクに限定する必要があります（例：複雑なレポート生成、コードのリファクタリング提案）。
1成功あたりのコスト（Cost per Success）分析
視点を変えて、「1つの正解を得るためにいくらかかったか」という指標を見てみましょう。
CoTは1回あたりのコストは低いですが、正解率が低い場合があります。正解を得るためには、何度も試行する必要があります。
一方、ToTはコストが高いですが、高い確率で正解を出します。
難易度が非常に高いタスクにおいて、「どうしても正解が必要」な場合、何度も失敗するCoTを繰り返すよりも、ToTを使用する方が、エンジニアリングコスト（エラー対応やリトライ処理を含む）まで含めると安くなる可能性があります。特に、誤った答えがビジネス上のリスクになる場合（契約書のチェックや医療情報の整理など）、ToTは有効です。
実装アーキテクチャによる最適化検証
コストとレイテンシの課題を緩和するために、実装面で工夫できる点があります。効果があった最適化テクニックを共有します。
BFS（幅優先探索）vs DFS（深さ優先探索）
ToTの探索アルゴリズムとして、主にBFSとDFSがあります。
- BFS (幅優先探索): 各ステップで全ての候補を生成・評価してから次の深さに進む。
- メリット: 最適解を見逃しにくい。
- デメリット: メモリ（コンテキスト）消費が激しく、全ての枝を評価するためコストが高い。
- DFS (深さ優先探索): 一つの有望な枝を最後まで掘り下げ、うまくいかなければ戻る。
- メリット: 正解に早く到達できれば、そこで打ち切れるためコストを抑えられる。
- デメリット: 最初の選択を誤ると、バックトラックの回数が増えて時間がかかる。
検証では、「DFS + 枝刈り」の組み合わせが最もコストパフォーマンスが良い結果となりました。最初から全ての可能性を網羅するのではなく、有望そうな道があれば進み、うまくいかないと分かった時点だけ戻るという方法です。
プロンプトのみの実装 vs LangChain等フレームワーク利用
ToTを実装するには、Pythonスクリプトで制御フローを書く必要があります。LangChainには実験的なToTの実装が含まれていますが、実務で使うにはカスタマイズが必要です。
特に重要なのが「状態管理」です。どの思考ノードが親で、どれが子か、どのノードが既に評価済みかを管理するために、軽量なグラフデータベースや、Pythonの networkx ライブラリを活用できます。
また、プロンプト自体も「思考生成用」と「評価用」で分けることが重要です。
評価用プロンプトの例（概念）:
「現在の思考状態は {current_state} です。この状態から正解（24を作る）に到達できる可能性を '確実', '可能性あり', '不可能' の3段階で評価してください。不可能と判断した場合はその理由も述べてください。」
この評価プロンプトの精度が、ToT全体の効率を左右します。「不可能」を正しく判定できれば、無駄な探索を早期に打ち切ることができます。
枝刈り（Pruning）の厳格さと精度の関係
枝刈りを厳しくすれば（少しでも怪しい枝は切る）、コストと時間は削減できますが、正解が含まれる枝を誤って切り落とすリスクが増えます。
ここでのコツは、「ルックアヘッド（先読み）」を入れることです。評価する際に、「次の1手」だけをシミュレーションさせてみて、うまくいかなそうなら切るという方法です。これにより、評価の精度が上がり、安心して枝刈りができるようになります。
選定ガイド：ToTを導入すべき境界線
検証結果を踏まえ、どの手法を選ぶべきかのガイドラインを提案します。最近ではモデル自体の推論能力が飛躍的に向上しているため、ToTのような複雑な実装が必要なラインを見極めることが重要です。
ROIが見合うユースケース定義
ToTを導入すべきなのは、以下の条件が重なる場合です。
- 探索的な問題である: 正解へのルートが複数あり、途中の判断ミスが致命的となるタスク（数理パズル、複雑なコード生成、戦略シミュレーション）。
- 即時性が求められない: ユーザーが回答を待てる、あるいは非同期処理が許容される（メール返信案の作成、夜間バッチでのデータ分析）。
- 高精度が必須である: わずかな論理破綻も許されない場合。
一般的なQ&A、要約、単純な翻訳などでは、ToTはコスト過多となるため推奨しません。
段階的導入のフローチャート
いきなりToTを実装するのではなく、以下のステップで検討することをお勧めします。特に最新のモデルは「思考（Thinking）」プロセスを内包し始めているため、モデルの選定だけで解決するケースが増えています。
- Step 1: プロンプト改善 (Few-shot / CoT)
- まずはプロンプトエンジニアリングで精度を高めます。
- Step 2: 推論特化モデルまたはCoT-SCの導入
- OpenAIの推論特化モデル（oシリーズ等）や、最新のThinking対応モデルを試します。これらは内部で思考プロセスを経て回答するため、ToTに近い効果を単一リクエストで得られる可能性があります。それでも不足する場合に、APIを並列で呼び出すCoT-SC (Self-Consistency) を検討します。
- Step 3: RAG (検索拡張生成) の検討
- 推論能力ではなく「知識不足」が原因なら、外部知識を与えることを検討します。
- Step 4: ToT の導入
- 上記すべてで解決せず、課題が「論理構造の複雑さ」や「探索空間の広さ」にある場合のみ採用します。
ハイブリッドアプローチの提案
実務の現場で特に有効なのが「ハイブリッドアプローチ」です。
思考の骨組み（プランニング）だけをToTや推論特化モデルで行い、実際の文章生成や詳細な記述は標準的なモデルで行う方法です。
例えば、長編小説を書くAIを作る場合、
- プロット作成（ToT/推論モデル）: ストーリーの分岐、伏線、整合性を探索し、プロットを決定。ここでは論理的整合性が最優先です。
- 執筆（標準モデル）: 決まったプロットに従って、各章の文章を書くのは、生成速度とコストパフォーマンスに優れた標準的なGPTモデルで行う。
これなら、コストを抑えつつ、高度な論理的整合性と流暢な文章生成を両立できます。ビジネス文書の作成や複雑な対話フローの構築でも、「構成案」だけ高精度なモデルで作るのは非常に有効な戦略です。
まとめ
Tree of Thoughtsは、LLMの推論能力を高める強力なフレームワークですが、コストも考慮する必要があります。
- 精度: 複雑な探索タスクではCoTを上回る。
- コスト: トークン消費量が増加する。
- 速度: リアルタイム応答は困難。
AIエンジニアとして重要なのは、ToTの理論を知っていることだけでなく、ユーザーのニーズや業務要件に応じて適切な手法を選択できることです。
もし、開発現場で「AIの精度が上がらない」という課題があるなら、まずは最新の推論特化モデルを試し、それでも解決しない「探索的な問題」であれば、ToTの実装を検討してみてください。技術は日々進化しています。常に最新の選択肢と比較し、ユーザーテストと改善のサイクルを回しながら、最適なアーキテクチャを選定しましょう。
コメント