ミドルマーケット（中堅市場）向けファンドの、ある月曜日を想像してほしい。アソシエイトが社内のAIエージェントに「Falconのステータスを『IOI（関心表明書）提出済み』に変更し、バンカーに当社のタイムラインを送信して」と1行入力する。このファンドには「プロジェクトFalcon」と呼ばれる案件が2件ある。ソフトウェア企業の現在進行中のオークション案件と、2023年に見送った製造業案件だ。CRMエージェントは古い記録を先に照合し、すでに終了した案件を再オープンしてそこにIOIを記録する。メール送信エージェントは独自の検索を行い、現在進行中の案件のバンカーのメールアドレスを正しく設定するものの、そのファイルに「Falcon IOI」というタグが付いているため、2023年のモデルから算出された評価額レンジを添付してしまう。どのエージェントも自らの仕事を実行した。しかし、作成された下書きは、ある企業の入札価格帯を別の企業のバンカーに提示するものになっており、送信ボタンを押す前にアソシエイトが読み直したことで、かろうじて送信を防ぐことができたのだ。
その一連の流れの中で、誤読をしたモデルは1つもない。各エージェントが、ユーザーがどのFalconを指しているのかを独自に判断しただけなのだ。AIの導入が広がるにつれ、こうした食い違いはより重大な問題となる。デロイトが2025年に実施した調査によると、米国の企業およびPEのリーダー1000人のうち86%が、自社が生成AIをM&Aワークフローに統合済みであると回答した。
筆者はPE企業向けのAIエージェントを構築する会社を共同創業したため、ベンダーの立場からこの問題を目にしてきた。初期のエージェントは単一のドキュメントに関する質問には上手く答えていたが、タスクが複数のドキュメント、CRM、電子メールにまたがると正しく機能しなくなった。我々はこれをモデルの外側で解決した。現在では、すべてのエージェントの実行およびツール呼び出しにおいて、モデルが処理を行う前に通常のコードによって設定された固定の社内・チーム・案件のスコープが割り当てられる。委任された作業を受け取るエージェントにはそのスコープのより狭い範囲が与えられ、それを広げるにはポリシーの変更か人間の承認が必要となる。たとえば、市場調査エージェントがCRMへの書き込み権限を取得することは決してない。
案件の同定は1度だけ行い、それを共有する
研究結果も同じ方向を示している。EnterpriseBenchの研究者たちが、ソフトウェアエンジニアリング、人事、財務、事務作業に及ぶ500のタスクをAIエージェントに与えたところ、最も優秀なモデルであっても完遂率はわずか41.8%にとどまった。タスクを難しくしていたのは、複数のシステムに分散したデータ、ロールベースのアクセス制御、複数の部門にまたがるワークフローといったエンタープライズ環境特有の条件だった。
Falcon問題に対する現実的な解決策は、単一のオーケストレーターが案件を1度だけ同定し、2つの記録が合致した場合にはどちらを指しているのかをユーザーに確認した上で、すべてのエージェントに同じ案件IDを渡すことだ。そのうえで、各エージェントには自らのタスクに必要な文脈（コンテキスト）のみが与えられる。
安全に分割できる場合のみ作業を分割する
効果的なシステムでは、他のタスクが依存するデータを変更することなく実行・再試行ができる場合に限り、タスクに専用のエージェントが割り当てられる。市場マッピングや関係性の調査は並行して実行できるが、CRMの更新は、その背景にある分析結果の出力と人間の承認を待つ必要がある。
260種類のエージェント構成を検証したGoogle Researchのプレプリント（査読前論文）も、この分離アプローチを支持している。並列的な財務推論タスクにおいて、中央コーディネーターを配置することで単一エージェントよりも結果が80.8%向上した。一方で、順序的な計画（シーケンシャル・プランニング）のベンチマークでは、検証されたすべてのマルチエージェント構成でパフォーマンスが39%から70%悪化した。また、エラーの広がり方にも違いが見られた。独立したエージェント群はエラーを17.2倍に増幅させたのに対し、中央調整を行った場合は4.4倍にとどまった。
引き継ぎ（ハンドオフ）自体が失敗を引き起こすこともある。MASTの研究者たちが7つのマルチエージェント・フレームワークから1600以上のトレース（実行記録）を調査したところ、エージェントがステップを繰り返す、割り当てられた役割を無視する、結果の検証が行われる前に終了するなど、14の明確な失敗モード（エラーパターン）が特定された。そのため、効果的なワークフローにおけるすべてのステップには、担当者（オーナー）、必須の成果物、停止ルール、そして検証のプロセスが存在しなければならない。
どのデータソースを優先するかを事前に決定する
PEにおいて、情報源の間でデータが食い違うことは日常茶飯事だ。インフォメーション・メモランダム（CIM）には過去12カ月の売上高が記録され、CRMには初回接触時の見積もり数値が残り、最近の経営陣のメモには改定された見通しが記載されているかもしれない。これらを単一の数値に統合するのではなく、それぞれの値を出典、観測時期、そして該当フィールドに対する社内の信頼度とともに保持することが重要だ。あるデータソースが特定のフィールドでは決定的な情報であっても、別のフィールドでは古くなっている場合がある。署名済みの文書で法的法人名が決定される一方で、最新の経営陣とのミーティングで最新の予測値が決定されるといった具合だ。重要な主張に出典がない場合や、より優先度の高い情報源と衝突する場合は、その成果物を送信・発行してはならない。
別のシステムを変更するアクションに対しては、より厳格な処理が必要となる。人間の承認は、正確なレコード、フィールド、および数値に対して行われるべきだ。すべての書き込み処理にはユニークキーが付与されるため、再試行によって重複適用されることはない。また、変更が確実に反映されたかを確認するために記録を読み戻す（リードバック）。追跡すべき指標は2つだ。出所に遡ることができる重要主張の割合と、リードバックによって実際に反映が確認された書き込み試行の割合である。
エージェントを信頼する前に質問すべきこと
より優れたモデルが登場すれば状況は改善するだろうが、我々が直面した失敗を根本的に解決してくれるわけではない。失敗の要因がCIMの読み取り精度にあったケースは滅多になかった。「これはどの案件か？」「どの地域のルールが適用されるか？」「どの受信トレイから返信すべきか？」といった問いこそが失敗の原因だったのだ。より賢いモデルであっても、こうした問いに自ら答えることはできない。それを解決するのがオーケストレーターだ。作業の分割方法、各エージェントがアクセス可能な領域、データ競合時の優先ソース、そしてデータがCRMに反映される前に誰が結果をチェックするかを決定するのはオーケストレーターなのである。
もし筆者がエージェントを評価するPE企業の立場であれば、デモ用のメモは飛ばして、ベンダーに2つの質問をするだろう。「この出力に含まれる主張のうち、情報源まで遡ることができる割合はどれくらいか？」そして「先月、貴社のエージェントが行ったCRM更新のうち、実際に正しく反映されたと確認できたものはいくつあるか？」だ。この両方に答えられるベンダーは、一見地味だが最も重要な部分──すなわち、案件チームが依拠することになる基盤──を構築できていると言える。
