39体のエージェント・システムをライブ監査してみた。成熟度スコアカードが明らかにしたこと

昨夜、AI Tinkerers で誰かが、私のマルチエージェントシステムを部屋の前で監査しました。デモでもありません。プレゼンでもありません。知識グラフ分析を用いた、実際のアーキテクチャ評価で、確立された成熟度フレームワークに照らして採点されたものです。

このシステムには、5つのカテゴリにまたがる39の専門エージェントがあり、ガバナンスのプロトコルを定義しています。さらに、8〜17ステップからなる6種類のワークフロータイプがあり、継続的改善のための専用の進化ループも備えています。私はこれを数か月かけて作り込んできました。

監査

Marcus Waldman が、iConsult ツールでアーキテクチャ全体に対する分析を実行しました。このツールは、エージェント定義、ワークフロー構造、協調パターンを知識グラフにマッピングし、そのうえで Arsanjani と Bustos の「エージェント型アーキテクチャ・パターン」に関する研究で示されたパターンに照らしてスコアリングします。

返ってきた結果は以下のとおりです：

失敗連鎖（フェイルチェーン）のカバレッジ：20%。自動回復チェーンの5ステップのうち、存在していたのは1つだけでした。残りは完全に欠落していました。

39のエージェント、3層のスーパーバイザ階層、そして監査役・センチネルの専用エージェントを備えたシステムで、堅牢性の項目は「未開始」でした。これは、ほとんどのチームが口にしていないギャップです。

Arsanjani の「エージェント成熟度 6レベル」

Ali Arsanjani（Google Cloud）は、成熟度モデルを公開しており、エージェントシステムが実際に能力スペクトラムのどこに位置するのかをマッピングします。私たちの多くは、自分たちは実際よりも高い段階にいると思いがちです。

レベル0：エージェントなし。 従来型のソフトウェア。自律的な構成要素はありません。

レベル1：ツール付き単一エージェント。 関数呼び出しを備えた1つのLLM。ここが、ほとんどの「エージェント的」プロダクトが実際にいる場所です。エージェントはツールを使えますが、計画はできず、会話の外に記憶はなく、他のエージェントとの協調もありません。

レベル2：マルチエージェント協調。 定義された役割と引き渡しパターンを持つ複数のエージェント。スーパーバイザ／ルータが作業をディスパッチします。ここからオーケストレーション問題が「本格的に刺さる」領域に入ります。

レベル3：自律的な計画。 エージェントはタスクを分解し、計画を作り、それを人間の監督を最小限にして実行できます。システムは、多段階のワークフローを、絶え間ないプロンプトなしで扱います。

レベル4：適応型システム。 エージェントは結果から学び、戦略を調整し、時間とともに改善します。自己評価ループ。パフォーマンス指標が、振る舞いへとフィードバックされます。

レベル5：エージェントの官僚制。 専用の監督エージェント。監査役。検査官。ほかのエージェントを監視・評価するために存在する統治構造。規模の拡大において信頼性を維持する唯一の方法だと気づくまでは、オーバーキルのように聞こえるレベルです。

私のシステムにはガバナンスエージェントがあります。監査役、センチネル、評価者、コヒーレンス（整合性）チェッカーがいます。紙の上ではレベル5に触れています。しかし実際には、監査でわかったのは、ガバナンス層は部分的に作られている一方で、その下にあるインフラ（自動回復、動的レジストリ、イベントバス）がまだ存在しないということでした。

組織図は作れても、配管（プランビング）は作れません。この成熟度モデルが測るのは配管です。

なぜ多数決が失敗するのか

AgentAuditor 論文（USC、2026年2月）には、この成熟度の問題に直接つながる関連する指摘があります。

マルチエージェントの信頼性に対する標準的なアプローチは多数決です。同じタスクを複数のエージェントで実行し、合意された回答を採用します。もっともに聞こえます。ですが、それは壊れています。

問題は相関バイアスです。エージェントが同じ学習データを共有し、似た推論パターンを持つ場合、独立した投票を生みません。間違った答えへ収束します。多数決が失敗するのは、組織で集団浅慮（グループシンク）が失敗するのと同じ理由です。声の数が増えても、皆が同じ盲点を共有していれば役に立ちません。

AgentAuditor のアプローチは、推論ツリーをマッピングし、票を数えるのではなく経路の分岐を探すことでした。その結果：多数決に比べて精度が5%改善。個々のエージェントがより優れていたからではなく、監査構造がより良かったからです。

これが、今回の監査で私のシステムに露呈したまさにそのギャップです。私はセンチネルと監査役を持っていますが、そこが見ているのは推論の分岐ではなく、規則違反です。ガバナンス層はプロセスをチェックします。しかし、エージェントが同じ盲点へ収束していないかを検査しません。それは、まったく別種の監査です。

教訓はこうです。エージェントを増やしても信頼性は直りません。推論経路がどこで分岐しているのかを特定できる構造的な監査を追加することで直ります。これはスケーリング問題ではなく、協調（コーディネーション）アーキテクチャの問題です。

ヒップ（誇大宣伝）の裏側にある数字

Gartner は、マルチエージェントに関する問い合わせが 1,445% 増加したと報告しました。同時に、2027年までにエージェント型AIプロジェクトの40%がキャンセルされるとも予測しています。この分野の何千ものベンダーのうち、実際に本物のマルチエージェント能力を構築しているのは、およそ130社程度に過ぎません。

Deloitte は市場規模を 2026年に 85億ドルと見積もり、2030年には 350〜450億ドルまで成長するとしています。しかしそれらの数字は、適切なオーケストレーションを前提としています。そうでなければ、40%のキャンセル率になります。

需要と現実のギャップは、モデル能力の問題ではありません。GPT-4、Claude、Gemini はいずれも複雑な推論を扱えます。ボトルネックはオーケストレーションの成熟度です。エージェントをどう調整しますか？ 障害をどう検出しますか？ どう回復しますか？ そして、システムが本当に設計どおりに動いているとどうやって分かりますか？

多くのチームが、これらの質問をスキップします。別のエージェントを追加することほど面白くないからです。

自己評価

もしあなたがマルチエージェントシステムを構築しているなら、次のような質問をする価値があります：

1. あなたは実際にどのレベルですか？ アーキテクチャ図が示唆している段階ではありません。実行中のシステムが何を示しているかです。

2. システムは自分自身の失敗を検出できますか？ ログに記録するのではありません。リアルタイムに検出し、それを回復ロジックへルーティングします。

3. エージェントの振る舞いをどう監査しますか？ 答えが「ログを読んでいる」ですべてなら、エージェントの数がいくつであっても、観測可能性（オブザーバビリティ）の成熟度はレベル1です。

4. エージェントが誤った出力を生成したらどうなりますか？ システムはそれを捕捉しますか？ それともパイプラインを通じて伝播しますか？

5. ガバナンス層は構造的ですか、それとも飾りですか？ 設定に「監査役エージェント」があることと、品質が落ちたときに実際にワークフローを中断できる監査役エージェントがいることは別物です。

私は昨夜、これらの質問に対して公開の場で答えなければなりませんでした。外部による評価の価値がそこにあります。自分自身の評価は常に寛容になってしまいます。

私がそれに対してやっていること

監査の結果は、具体的な実装計画として提示されました。フェーズ1 は堅牢性のギャップです。サーキットブレーカー、リトライポリシー、ヘルスチェック、そして5つすべてのステップを実際にカバーする失敗連鎖（フェイルチェーン）です。協調スコアは妥当でした。というのも、スーパーバイザのアーキテクチャとワークフロー定義がしっかりしていたからです。しかし、堅牢性のない協調は「動くときは動く」システムであり、失敗したときには捕捉する手段が何もありません。

成熟度モデルは、完成させるためのチェックリストではありません。今どこにいて、次に何を作るべきかを知るための地図です。フレームワークは存在します。評価ツールも良くなっています。問題は、その監査を実行する覚悟があるかどうかです。

私はオープンソースのシンボリック計算フレームワークである Sigil を構築しており、Substack ではシステムアーキテクチャについて書いています。