技術要約：Queen-Bee エージェント

1. 問題提起

エンタープライズ・エージェント・システムは、生のタスク実行能力と運用上の安全性との間に決定的なギャップに直面しています。大規模言語モデル（LLM）エージェントは、オープンな領域においてツールの呼び出しやワークフローの実行を効果的に行うことができますが、エンタープライズ環境には厳格な制約が課されます：テナントの隔離、ポリシーの強制、監査可能性、およびスコープ化された実行境界です。

本論文は、広範な権限を持つモノリシックなエージェントは、プライベートなModel Context Protocol (MCP) 環境においては運用上受け入れられないと主張しています。タスクを正常に完了したとしても、部門間の境界を侵害したり、許可されていないテナントデータにアクセスしたり、不適切なツールを呼び出したりした場合は、出力の有用性に関わらず「失敗」とみなされます。現在のマルチエージェント・フレームワークの多くは、実行境界のコンパイル、テナントを意識した接続性、および統治された能力割り当てのための明示的なメカニズムを欠いています。

2. メソドロジー：Queen-Bee アーキテクチャ

著者らは、エンタープライズMCPオーケストレーションのために特別に設計された、統治されたマルチエージェント・アーキテクチャであるQueen-Beeを提案しています。このシステムは、BeeSpecと呼ばれる構造化された中間表現を通じて、プランニングと実行を分離します。

コア・コンポーネント

1. Queen コントロール・プレーン：

   • 一般的な実行エージェントではなく、中央のオーケストレーターとして機能します。
   • 責任： レジストリからケイパビリティ（能力）を取得し、タスク単位の実行計画を立て、BeeSpecを生成し、ポリシーチェックと監査ログを通じて実行時のガバナンスを強制します。
   • プロビジョニング・バックエンド： Queenは、軽量な構造化検索、ストレス検索（ノイズのあるレジストリ）、ハイブリッドな疎＋密検索、およびLLM誘導型プロビジョニングの4つの戦略を用いてエージェントをプロビジョニングできます。

2. BeeSpec（中間レイヤー）：

   • 特定のエージェント（Bee）の実行境界を定義する構造化されたレコードです。
   • スキーマ・フィールド： bee_id、role、domain、tenant_scope、memory_scope、attached_skills、allowed_tools、policy_profile、およびオプションの approval_gate。
   • 機能： Beeが「何をすることを許可されているか」（Queenによってプロビジョニングされるもの）と、「実際に何をするか」（実行されるもの）を明示的に分離します。

3. Bee 実行プレーン：

   • BeeSpecで定義された制約に厳格に従って動作する特化型エージェントです。
   • Beeはドメイン単位（例：人事、IT、化学）でスコープ化されており、付随するスキルを使用してローカルなツール計画を導き出します。
   • ツールの呼び出しは、実行前にポリシーレイヤーによって媒介されます。

4. テナント・スコープ型 MCP コネクタ・レイヤー：

   • アクティブなテナント・スコープ内でツールの呼び出しを解決します。
   • プロトタイプでは、これはローカルのFastMCPサーバーにバックエンドを持つ実際の stdio MCPアダプターを利用しており、システムがモックのレジストリではなく、実際のツールと相互作用することを保証しています。

実装の詳細

プロトタイプはPythonで実装されており、以下を含みます：

• 2つのレジストリ： MCPレジストリ（ツールの説明、リスクレベル、テナント・スコープ）とスキル・レジストリ（再利用可能な実行スキル）。
• ガバナンス・メカニズム： 監査に裏付けられた実行時ポリシーチェック、およびダウンストリーム実行のためのオプションの人間による承認ゲート。
• ドメイン拡張： 標準的な人事/ITタスクを超えて、本システムは、特性フィルタリングと文献エビデンス検索のために、実際のソフトウェア（RDKit）と外部データソース（ChEMBL、PubChem）を用いた化学ワークフローを統合しています。

3. 実験設計

システムは、2つのテナントにわたる59件のエンタープライズ型タスクで評価されました。これらは以下のように分類されています：

• 24件の定型的な人事/ITタスク。
• 16件のガバナンスに敏感なタスク（財務に敏感、またはクロステナント）。
• 16件のスコープ化された実行タスク（部分的なローカルワークフロー）。
• 3件の化学ワークフロータスク（スクリーニングおよび再配置）。

比較対象システム：
研究では7つの構成を比較しました：

1. Queen-Bee (Static)
2. Queen-Bee (Retrieval)
3. Queen-Bee (Stress Retrieval)
4. Queen-Bee (Hybrid Retrieval)
5. Queen-Bee (LLM Provisioning)
6. Queen-Bee w/o Policy
7. Single-Agent Baseline

4. 主要な結果

ガバナンスと隔離

• 完璧なブロッキング： すべての統治されたQueen-Beeバリアントは、財務ガードレールおよびクロステナントのリクエストのブロッキングにおいて1.0のレートを達成しました。
• ベースラインの失敗： 「Queen-Bee w/o Policy」および「Single-Agent Baseline」の両方は、ガバナンスに敏感なブロッキング指標において完全に失敗（0.0）しました。これは、ガバナンスが単なる専門化の関数ではなく、明示的なアーキテクチャ上の制約を必要とすることを裏付けています。
• ゼロ・ガバナンス失敗： 検索駆動型のQueen-Beeバリアントは、テストセット全体を通じてガバナンス失敗ゼロを達成しました。

タスク成功率と実行品質

• 成功率： 検索駆動型のQueen-Beeは、タスク成功率0.964を達成し、静的ベースライン（0.857）およびシングルエージェント・ベースライン（0.571）を上回りました。
• スコープ化された実行： 検索駆動型のプロビジョニングは、実行の完遂度を大幅に向上させました（静的ベースラインの0.80に対し0.95）。Queenが関連するケイパビリティを検索できることで、Beeは「過剰実行」（例：要約のみが求められているのに面接をスケジューリングするなど）を回避できました。
• ツールの精度： 検索駆動型のアプローチは、プロビジョニングされた8件のケースで誤ったツール呼び出しがわずか1件であったことから、高いツール選択精度（0.979）を維持しました（シングルエージェント・ベースラインでは16件の誤った呼び出しがありました）。

プロビジョニング・バックエンド

• 軽量 vs 複雑： より豊かな検索スタックが常に優れているという仮定に反して、軽量な構造化検索バックエンドが最も強力なデフォルトであり続けました。
• ハイブリッド/LLMの性能： ハイブリッド検索およびLLM誘導型プロビジョニングは実行可能でしたが、現在のレジストリ規模では軽量なベースラインを上回ることはありませんでした。LLM誘導型プロビジョニングは、品質の向上なしに顕著なレイテンシ（数百ミリ秒）を伴いました。
• ノイズへの堅牢性： システムは「ノイズの多い」ケイパビリティ・レジストリにさらされても安定しており、構造化リトリーバーがディストラクター（妨害要素）のノイズに対して堅牢であることを示唆しています。

化学ワークフローの統合

• システムは、Evidence Bee、Screening Bee、および Decision Bee を含むマルチBee薬物スクリーニング・ワークフローを正常に実行しました。
• このワークフローは、アーティファクトを意識したコラボレーションを実証しました。中間結果（例：ChEMBLのエビデンス、RDKitのスコア）が各ステージ間で受け渡され、手動の承認ゲートが要求に応じてダウンストリームの実行を正常に停止させました。
• システムは、プレースホルダーの出力ではなく、具体的なエビデンスに基づいたトップ3のリスト（Sunitinib, Pelitinib, Ruboxistaurin）を生成しました。

5. 意義と主張

本論文は、Queen-Beeをプロダクションレベルのセキュリティソリューションとしてではなく、新しいエンタープライズ・エージェント・アーキテクチャへのアプローチを示すプロトタイプレベルのシステム的証拠として位置づけています。

• 評価基準の転換： 著者らは、エンタープライズ・エージェント・プラットフォームは、単なるタスク実行能力だけでなく、統治されたプロビジョニング、隔離挙動、スコープ化された実行品質、およびアーティファクトを意識したワークフロー調整によって評価されるべきであると主張しています。
• ソフトウェアエンジニアリングの観点： 結果は、小規模で高度に構造化されたエンタープライズ・ケイパビリティ・レジストリに対しては、より重厚なセマンティック検索やモデル駆動のオーケストレーションよりも、統治された軽量なプロビジョニング・ポリシーが優れていることを示唆しています。主な利点は、検索スタックの複雑さを増すことではなく、明示的なケイパビリティ構造とBeeSpecによるスコープ化された実行から得られます。
• 限定的な制約： 著者らは、タスクセットが合成されたものであること、MCPスタックが（ライブなビジネスシステムではなく）ローカルのデモサーバーを使用していること、およびガバナンスモデルが主にルールベースであることを明示的に述べています。化学統合は、実際のツールを使用していますが、完全な科学的ワークフローのサブセットを表しています。

結論として、Queen-Beeは、制御プレーンのプランニングと実行プレーンのアクションを、構造化された中間レイヤー（BeeSpec）を介して分離することで、エンタープライズ環境において安全、隔離され、かつ高品質なエージェント実行が可能であることを実証しています。ただし、これはガバナンスとケイパビリティの割り当てが、第一級のアーキテクチャ・コンポーネントとして扱われる場合に限られます。