
自律型AIエージェントの開発は、長い間「累積誤差問題(compounding error problem)」という根強い課題によって妨げられてきました。大規模言語モデル(LLM)が複雑で多段階のワークフローを実行する際、たった一つのハルシネーション(幻覚)や論理的なミスがプロセス全体を脱線させてしまい、長時間実行されるエージェントを重要な企業タスクにおいて信頼できないものにしてしまいます。今週発表された大きな進展として、MIT計算機科学・人工知能研究所(CSAIL)とスタートアップ企業のAsari AIの研究者たちは、エージェントによるコード実行の方法を根本的に再考することで、この信頼性の危機を解決するために設計された新しいフレームワーク、EnCompassを公開しました。
NeurIPS 2025カンファレンスで発表され、現在広く議論されている論文で詳細が記されているEnCompassは、エージェントプログラミングに「推論時探索(inference-time search)」という概念を導入します。エージェントのコアロジックを、正しい結果を探索するために使用される戦略から切り離すことで、このフレームワークは、コードベース全体を書き換えることなく、バックトラッキング(後戻り)や並列探索といった洗練されたエラー回復メカニズムを開発者が実装することを可能にします。
EnCompassの重要性を理解するには、まず現代のAIエージェントのアーキテクチャを理解する必要があります。多くのエンタープライズ級のエージェントは「プログラム制御(program-in-control)」モデルで動作しており、開発者が特定のワークフロー(例:「このコードを翻訳する」「この財務報告書を分析する」「仮説を生成する」)を定義し、LLMが特定のサブタスクを実行するために呼び出されます。
これらのシステムは強力ですが、脆弱です。LLMは非決定論的であり、ある瞬間には素晴らしい回答を提供しても、次の瞬間にはハルシネーションを起こす可能性があります。数十のステップが含まれるワークフローでは、致命的なエラーが発生する確率は確実性に近づきます。従来、開発者は膨大な「グルーコード(glue code)」、つまりエラーをキャッチするための手動のループ、リトライロジック、条件チェックを記述することで、これを軽減しようとしてきました。しかし、このアプローチは、エラー処理ロジックが実際のタスクロジックを凌駕してしまうような、肥大化して管理不能なコードベースを招くことがよくあります。
EnCompassは、エージェントの実行を線形な経路としてではなく、探索問題(search problem)として扱うことでこれに対処します。 モデルがすべてのステップを正しく実行することを期待する代わりに、このフレームワークは「正しい」経路が可能性のツリーの中に隠されていることを認め、そのツリーを効率的にナビゲートするためのツールを提供します。
EnCompassの核心には、**確率的天使的非決定性(Probabilistic Angelic Nondeterminism / PAN)**と呼ばれる理論的な革新があります。このプログラミングモデルにより、開発者はエージェントが実行すべき「何(what)」、つまりステップのシーケンスを、それらのステップをナビゲートするために使用される戦略である「いかに(how)」から切り離して記述することができます。
実際には、これはPythonのデコレータ @encompass.compile を通じて実現されます。開発者がエージェントの関数をこのデコレータでラップすると、EnCompassはワークフローを探索空間へとコンパイルします。LLMがクエリされるコード内のポイントは「分岐点(branchpoints)」、つまり実行が分岐する可能性のある分かれ道として扱われます。
この分離には、次のような大きな利点があります。
EnCompassフレームワークは、人間の問題解決を模倣した機能をエージェントに与えます。人間の専門家が行き止まりに突き当たったとき、彼らは以前の仮定に立ち戻り(バックトラック)、別の方法を試します。EnCompassは、AIエージェントがプログラム的に同じことを行うことを可能にします。
このフレームワークは、複数の探索戦略を標準でサポートしており、開発者はユースケースに応じて速度、コスト、または精度を最適化できます。
表:EnCompassがサポートする探索戦略
| 戦略 | 説明 | 最適なユースケース |
|---|---|---|
| ビーム探索(Beam Search) | 各ステップで上位 k 個の候補のみを保持しながら、複数の有望な経路を並行して探索する。 | 広範さと速度のバランスが必要な、リスクの高いタスク。 |
| モンテカルロ木探索(MCTS) | シミュレーションを使用して現在の選択の長期的な価値を推定し、最も有望なブランチにリソースを集中させる。 | 初期の決定が後に影響を及ぼす、複雑で多段階の推論タスク。 |
| Best-of-Nサンプリング | 複数の独立した解決策を生成し、検証スコアに基づいて最適なものを選択する。 | コード生成や数学の問題など、出力の検証が容易なタスク。 |
| バックトラッキング(DFS) | 経路を深く探索し、失敗条件が満たされた場合に以前の状態に戻る。 | 1つの有効な解決策を見つければ十分な、リソースに制約のある環境。 |
これらの戦略を標準化することで、EnCompassは、JavaのコードベースをPythonに翻訳しようとするエージェントが、トリッキーな関数に対して複数の翻訳オプションを同時に探索することを可能にします。ある経路がコンパイルに失敗するコードにつながった場合、エージェントはそれを破棄して実行可能な代替案を進めることができ、これらはすべてランタイムエンジンによって自動的に処理されます。
研究者たちは、厳格なベンチマークを通じてEnCompassを検証しました。特に注目すべきは、JavaのリポジトリをPythonに自動翻訳するケーススタディです。これは、高い精度とコンテキストの認識が要求されることで知られるタスクです。
MIT CSAILの発表で詳述されている通り、その結果は驚くべきものでした。EnCompassで強化されたエージェントは、探索を使用しない標準的なエージェントと比較して、翻訳精度が15%から40%向上しました。開発者コミュニティにとってさらにおそらく印象的だったのは、コードの複雑さの軽減です。EnCompassを介して探索ロジックを実装する場合、同じ機能を手動で実装するよりもコード行数が約80%少なくて済みました。
この効率性の向上は、EnCompassが堅牢なAIエージェントの作成を民主化できる可能性を示唆しています。以前はカスタム探索アルゴリズムを構築するためのエンジニアリングのオーバーヘッドを賄えなかった小規模なチームでも、テクノロジー大手が構築したものに匹敵する信頼性を持つエージェントをデプロイできるようになります。
エンタープライズ部門にとって、EnCompassの登場はAIエンジニアリングの成熟を象徴しています。私たちは、モデルを動かすためにテキストを調整する「プロンプトエンジニアリング(prompt engineering)」の時代から、システムアーキテクチャが信頼性を保証する「フローエンジニアリング(flow engineering)」や「探索エンジニアリング(search engineering)」の時代へと移行しつつあります。
MIT CSAILおよびAsari AIの研究者であり、主著者であるZhening Li氏は、EnCompassはLangChainのようなフレームワークの代わりではなく、補完的なレイヤーであると強調しました。LangChainがツールやプロンプトをオーケストレートする一方で、EnCompassは意思決定の軌道を管理します。
エンタープライズAIへの主な影響:
EnCompassのリリースは、AI業界のより広範なトレンドである「推論時計算(inference-time compute)」へのシフトと一致しています。OpenAIの最近の推論モデルが回答前に「思考」するためにより多くの時間を割くのと同様に、EnCompassのようなフレームワークにより、開発者はアプリケーションレイヤーで計算リソースをより高い信頼性と引き換えにすることができます。
Asari AIとMITのチームは、EnCompassによってエージェントが発見における真の協力者として行動できる未来を構想しています。新しい化合物の設計を任されたエージェントを想像してみてください。EnCompassを介したMCTSを使用することで、エージェントは何千もの潜在的な分子構造を探索し、合成経路が不可能であると判明した場合にはバックトラックし、最も実行可能な候補のみを人間の科学者に提示することができます。
誤差蓄積問題を効果的に解決することで、EnCompassはAIエージェントを実験的な玩具から重要なプロダクションシステムへと進化させるために必要な、ミッシングリンク(欠けていたインフラ)となるかもしれません。