9月25日、Shannon Williamsが「AGNTCon + MCPCon Europe: What Enterprise AI Teams Are Actually Building」と題した記事を公開した。会場で最も衝撃的だったのは、銀行・通信・エネルギー・自動車・医療と業界はバラバラなのに、参加者が持ち寄ったアーキテクチャ図が驚くほど似通っていたことだ。エンタープライズのAIチームは今、各自がサイロの中で「同じ制御プレーン」を作り続けているという現実が、このイベントで浮き彫りになった。

ObotのCEOでKubernetesエコシステムの初期を支えた共同創業者でもあるShannon Williamsは、上海・東京でのMCP Dev Summitをはさんだ強行スケジュールでアムステルダム入りし、AGNTCon + MCPCon Europeに登壇した。500人以上がブースを訪れ、セッションには200人超が参加。エンジニア、アーキテクト、SRE、プラットフォームエンジニアが顔を揃えた。Williamsは「早期のDockerConやKubeConと同じ手触りがある」と述べ、黎明期のKubernetesエコシステムと重ねて見ている。

全員が同じものを作っている

イベントを通じて最も強く印象に残ったのが、「みんな同じものを作っている」という事実だ。呼び名はまちまちで「コントロールプレーン」「AIプラットフォーム」「オーケストレーション層」などさまざまだが、やろうとしていることは共通している。社内に散在するエージェント、MCPサーバー（Model Context Protocol準拠のツール統合レイヤー。Anthropicが策定しLLMとツール群を標準化された方法で接続するオープン仕様）、スキル、CLI、APIやモデルに対して、何らかの構造を与えようとしているのだ。

Obotのキーノートでは、「エージェントが何にアクセスできるかを制御する問題が、分散コンピューティングの問題になった」という指摘があった（キーノート動画はこちら）。多数のエージェントが複数のプロトコルとデータソースをまたいで動作し、多くの場合はユーザーのIDを借用して動く。これはKubernetesがワークロードに対して取り組んだ問題と構造的に似ている。

ブースを訪れた人々が描くスタックは、「LLMプロキシ＋MCPゲートウェイ＋それをつなぐスクリプト」という組み合わせが多く、ほとんどがOSSで構成されていた。そして、Williamsが想定外だったのは、見知らぬ来場者の多くがすでにObotを本番運用していたことだ。彼らは自力でプロジェクトを見つけ、デプロイし、現場での知見を共有しに来ていた。「Rancher初期に感じたのと同じ感覚だった」とWilliamsは振り返る。Rancherとは、Kubernetesが普及し始めた2016〜2017年頃に企業のコンテナ管理を担うOSSとして登場したプラットフォームであり、「誰もが同じ運用課題を抱えながら各自で解決策を作っていた時代」の象徴的な存在だ。Williamsはそのときと同じ熱量と混乱をAIエージェント管理の現場に見ているわけである。

ガバナンスが急務になった理由

こうした「同じものを各自で作っている」状況がなぜ生まれているのか。その背景には、エージェントの使われ方の急速な変化がある。

「バイブコーディング（Vibe Coding）」——LLMに雰囲気で指示を出して開発する手法——は会話に頻繁に登場したが、現場の実態はやや異なる。エンジニアリングチーム自体の生産性向上というより、エンジニアリング外の部門がClaude Codeなどのツールを使って業務をこなすケースが増えているというのが実情だという。

問題は、そうしたエージェントが重要なデータへのアクセス権を持ったままユーザーの端末上で動くことだ。セキュリティチームが懸念するのは当然で、「隔離されたサンドボックスに移して、エージェントのアクセス先と行動履歴を記録したい」という相談が相次いだ。

ガバナンスが急務になったきっかけとしてWilliamsが聞いたのは、インシデントの発生か、あるいは監査だ。「誰が何を使っているか」「エージェントが何に触ったか」を後から説明できないと分かった時点で、チームが動き出す。

ある大規模組織のチームは、API・MCP・統合・AI SDKを一手に担い、社内他部門の開発を支援する立場にある。地方拠点のチームが以前は数年かかっていたアプリを数週間でリリースするようになった一方、そのスピードを落とさずに「承認済み一覧」「本番移行の明確なパス」「利用状況の可視化」を実現したいと考えている。この例は、ガバナンスを「スピードの敵」ではなく「スピードを維持するための仕組み」と捉え直す視点として、Williamsが最も興味深いと感じた事例だ。

旧来のモデルはもう合わない

こうした議論の根底にある構造的な変化はシンプルだ。旧来のアーキテクチャは「開発者はAPIを使い、それ以外はアプリを使う」という前提で設計されていた。今や人とシステムの接点は、MCPサーバー・API・デスクトップクライアント・自律エージェント・ユーザー駆動のエージェントと多岐にわたる。エージェントに人間のIDを借用させるのではなく、エージェント固有のIDと権限を付与する仕組みが必要になっているが、既存スタックのほとんどはそれを想定して作られていない。

この「エージェントIDと認可」の問題は現在、OAuth 2.0の拡張やSPIFFE/SPIREといった既存の認証基盤をどうエージェントに適用するかという形で活発に議論されており、標準化はまだ途上にある。

旧来の前提が崩れた先に何が必要かを整理する軸として、キーノートで提示された「Curate（整備する）・Monitor（監視する）・Isolate（隔離する）」というフレームワークが、現場の実態とよく合致していた。承認済みの統合・エージェント・スキル・モデルを用意する「Curate」に着手しているチームは多い。「Monitor」は夜も眠れない問題で、見えていない動きがまだ大量にあると全員が認識している。「Isolate」は最も着手が遅れており、「必要なのはわかっているが、何を・どこで隔離するかが決まっていない」というチームがほとんどだ。

Williamsはこのイベントを、コンテナ黎明期と同じ「早期参入が後のキャリアを決める」局面と見ている。DockerやKubernetesに早期から関わったエンジニアが今や意思決定者になっているように、エージェント基盤を今から手を動かして理解している人間が、組織のやり方を形作ることになる——というのが彼女の見立てだ。

詳細はAGNTCon + MCPCon Europe: What Enterprise AI Teams Are Actually Buildingを参照していただきたい。