MCP接続と権限を一元管理WSO2 Agent Managerの実力
要約
WSO2が一般提供を始めたAgent Managerは、AIエージェント固有IDやMCP接続、権限、ライフサイクルをどう管理するのでしょうか。Kubernetes上のサンドボックスや監査ログを含め、複数部門へ展開する前の確認項目を整理します。
海外では、AIエージェントを個別に作る段階から、複数のモデルやフレームワーク、実行環境を横断して管理する段階へ進む議論が広がっています。WSO2 Agent Managerは、その変化を示すオープンソース基盤の事例です。
私たちが見てきた範囲では、導入初期は接続設定が動けば成功と捉えられがちです。エージェントやMCP接続先が増えると、個別設定だけでは実行主体や停止判断を追いにくくなります。
この記事の対象読者
次の課題を抱える企業や組織に向けた内容です。製品の比較だけでなく、AIエージェントを本番へ進める前の管理単位を確認できます。
- AIエージェントを複数部門で使いたい企業
- 社内のAI接続先を把握できていない組織
- AIの権限と監査ログを整えたい企業
- MCPを業務システムに接続したい企業
- PoCから本番展開へ進みたい企業
WSO2が発表したAgent Manager
WSO2は2026年9月18日、複数のモデル、フレームワーク、実行環境にまたがるAIエージェントを一元管理するオープンソース基盤「Agent Manager」の一般提供を発表しました。発表内容はInfoQが報じています。
Agent Managerには、検証可能なエージェントID、MCP接続の管理、ライフサイクル管理、セキュリティ制御が含まれます。実行環境として、Kubernetes上のサンドボックスへの対応も特徴のひとつでしょう。
- エージェントID、実行主体を識別する管理単位
- MCP接続、外部ツールや業務システムとの接続先
- ライフサイクル、登録や更新、停止を含む状態管理
- サンドボックス、Kubernetes上で実行環境を分離する仕組み
ここでいうMCPは、AIモデルと外部ツールやデータを接続するためのプロトコルです。接続先を増やしやすい一方、接続したエージェントがどの操作まで許されるかを別に定義する必要があります。
固有IDとMCP権限の管理単位
AIエージェント固有IDは、利用者のログインIDだけで代用しない設計が考えられます。利用者、エージェント、実行タスク、MCP接続先を分けて記録すると、誰の依頼でどのエージェントが何を呼び出したかを追いやすくなるでしょう。
権限は、MCPサーバーへ接続できるかと、接続後に何を実行できるかを分けて設定します。たとえば参照だけを許可するエージェントに、更新や削除の操作まで渡さない考え方です。
- エージェントごとに固有IDを発行し、担当業務と所有者を記録する
- MCP接続先ごとに、参照、作成、更新、削除の操作を分ける
- 利用者の依頼とエージェントの実行を同じ記録軸で追えるようにする
- 権限変更時に、変更者、変更理由、適用範囲を残す
- 停止対象をIDで指定し、接続先を個別に探さなくても止められるようにする
Agent Managerの検証可能なエージェントIDは、この管理単位を共通化する方向に合います。BinxAIでは、エージェント数が少ない段階でも、後から部門をまたぐ前提でIDと接続先の台帳を作る進め方を取ります。
サンドボックスと監査ログの役割
サンドボックスは、AIエージェントの処理を隔離された実行環境で動かすための仕組みです。Kubernetesはコンテナなどを管理する基盤で、Agent Managerはその上でサンドボックス実行を扱います。
ただし、実行環境を分離しても、接続先の権限が広すぎればリスクは残ります。サンドボックスは実行場所の制御、権限は操作範囲の制御、監査ログは事後確認の制御として、それぞれ別に設計したいところです。
- サンドボックスで、処理が触れられる実行環境を限定する
- 権限設定で、MCP経由の操作範囲を限定する
- 監査ログで、利用者、エージェント、接続先、操作結果を確認する
- 異常時は、エージェントIDや接続先を指定して停止する
- 停止後に、未完了処理と再開条件を確認する
複数部門へ広げる前の確認項目
海外でAIガバナンスを横断管理する議論が進む一方、企業の現場では部門ごとに接続先や承認ルールが異なることが多いでしょう。共通基盤を置く前に、部門固有の差分と全社共通のルールを切り分けます。
- どの業務をエージェント化し、誰が所有者になるか
- 利用するMCP接続先と、扱うデータの種類は何か
- 参照、更新、削除のうち、どこまで自動実行を許すか
- 監査ログを誰が確認し、異常時に誰が停止するか
- 部門追加時に、既存のIDと権限を再利用できるか
この確認を済ませると、PoCから本番へ移す際の判断材料が揃います。特に、部門ごとに別のエージェントIDを発行するのか、共通のエージェントに利用者単位の権限を付けるのかは、早い段階で決めたい項目です。
WSO2 Agent Managerは、個別のAI機能を増やす製品というより、複数のAIエージェントを共通の管理対象として扱うための選択肢です。自社の運用単位と合うかを、ID、MCP接続、権限、監査、停止の順に確かめるとよいでしょう。
自社で詰まりやすい設計箇所
自社だけで進める場合、製品の設定より先に、既存の接続先と権限の棚卸しで止まることがあります。エージェントの所有者が曖昧なまま、部門ごとに別の命名や承認方法が増えるケースも考えられるでしょう。
- 社内にどのMCP接続先があるかを一覧化できていない
- エージェントIDと利用者IDの関係が決まっていない
- 監査ログの確認者と停止判断の責任者が決まっていない
外部の支援を使うと、現場の業務と接続先を確認してから、要件や権限の範囲を固めやすくなります。一式の機能を導入するのではなく、どの業務をどの管理単位で始めるかを整理できるのも、その利点のひとつでしょう。
BinxAI株式会社 | みっちゃくん
BinxAI株式会社のみっちゃくんは、提案の前に現場へ入り、課題の整理と現状の診断を済ませてから要件を固める進め方が特徴です。企画や課題整理、要件整理から開発までを同じ担当が一気通貫で受け持ちます。
見積は一式ではなく、要件を整理したうえで詳細を示します。契約後に要件が動いた場合も、決めた範囲の中で優先順位を入れ替えて進めます。料金は公式ページと無料相談で案内します。
- 課題の整理と現状の診断
- 要件定義と設計
- 開発と本番環境への展開
- 運用の引き継ぎと内製化の支援
- 担当者向けの研修
よくある質問
WSO2 Agent Managerは何を一元管理しますか？
検証可能なエージェントID、MCP接続、ライフサイクル、セキュリティ制御を一元管理します。複数のモデルやフレームワーク、実行環境をまたぐ点が特徴です。
MCP接続と権限は同じ設定ですか？
同じものとして扱わない設計が向いています。MCP接続はどのシステムへつなぐか、権限は接続後に何を実行できるかを表すためです。
Kubernetes上のサンドボックスは何に使いますか？
AIエージェントの実行環境を分離するために使います。実行環境を隔離しても、MCP接続先の権限設定や監査ログの設計は別に必要です。
監査ログには何を残すべきですか？
利用者、エージェント固有ID、MCP接続先、実行した操作、実行結果、時刻を確認できる形にします。異常時に停止判断へつなげられる記録かどうかも、あわせて見ておきたいところです。
複数部門へ展開する前に何を決めますか？
エージェントの所有者、接続先、操作範囲、監査ログの確認者、停止責任者が主な決定事項です。部門ごとの差分と共通ルールを分けると、後から追加しやすくなります。
WSO2 Agent Managerの発表は、AIエージェントを個別に動かすだけでなく、ID、MCP接続、権限、実行環境、停止を共通の管理対象にする流れを示しています。導入を検討する企業は、まず自社の接続先とエージェントの管理単位を一覧化するところから始めてください。
この記事の分類
同じ分類の記事をまとめて読めます。
次に読む記事
AIエージェントが増えた会社に必要な司令塔 接続と権限を一元管理する方法
AIエージェントやMCP接続先が増えると、個別のPoCだけでは権限や監査ログを管理しきれません。Salesforce Japanの発表を手がかりに、Agent FabricとOmni Gatewayの役割、棚卸しから本番移行までの確認項目を整理します。
AIエージェントの接続・予算・監視をまとめて管理する設計と評価の進め方
Nutanix Enterprise AI 2.8とAgent Gatewayの更新を起点に、MCPサーバーの接続許可、AIエージェントの権限、トークン予算、稼働ログを一体で管理する設計と、ハイブリッド環境での評価項目を整理します。
誰がどのAIを使うのかSAS AI Navigatorが示す統制の形
SAS AI Navigatorが示すAIガバナンスの新しい形を、モデルやAIエージェントの棚卸しから実験・承認・廃止までの管理として整理します。自社で先に決める台帳項目と責任者、運用へ落とす際の注意点も紹介します。
