AIエージェントが増えた会社に必要な司令塔 接続と権限を一元管理する方法
要約
AIエージェントやMCP接続先が増えると、個別のPoCだけでは権限や監査ログを管理しきれません。Salesforce Japanの発表を手がかりに、Agent FabricとOmni Gatewayの役割、棚卸しから本番移行までの確認項目を整理します。
AIエージェントを部門ごとに試す段階では、個別の成果が注目されます。数が増えて本番業務へ入ると、どのエージェントが何へ接続し、誰の権限で動くのかが問われます。
Salesforce Japanの発表は、海外で進むエージェント管理基盤の議論を、日本企業が抱えやすい運用課題へ引き寄せる材料になりそうです。製品の採用可否より先に、会社全体の管理単位を決める必要があります。
この記事の対象読者
- 複数のAIエージェントを業務で使いたい企業や組織
- MCPやAPIの接続先が増えている企業や組織
- AIの利用状況と権限を一元管理したい企業や組織
- PoCから本番運用へ移行できずにいる企業や組織
- Salesforceを業務基盤として利用している企業や組織
Salesforce Japanが発表した管理基盤
Salesforce Japanは2026年8月17日、MuleSoft Agent FabricとMuleSoft Omni Gatewayの国内提供開始を発表しました。発表概要では、AIエージェント、MCPサーバー、APIを一元的に扱う構成が示されています。
Agent Fabricは、社内外に存在するエージェントを見つけ、接続し、権限や利用状況を管理する役割です。複数の業務システムをまたぐエージェント運用で、管理対象を把握する層にあたります。
Omni Gatewayは、エージェントとMCPサーバーやAPIの間に置く制御プレーンとして説明されています。接続を個別に許可するのではなく、共通の窓口から制御する考え方です。
- Agent Scanners、稼働するエージェントを発見する機能
- MCP Bridge、エージェントとMCP接続を仲介する機能
- Agent Broker、エージェントの接続や利用を調整する機能
- Omni Gateway、接続と制御を集約する窓口
増える接続先と権限の論点
AIエージェントの管理で最初に詰まりやすいのは、エージェントそのものの台帳です。名称、所有者、利用目的、接続先、扱うデータ、停止方法が揃っていなければ、障害時に影響範囲を特定できません。
次に確認したいのが、MCPサーバーやAPIへの接続権限です。同じエージェントでも、参照だけでよい業務と更新まで許す業務では、認証と認可の設計を分ける必要があります。
- エージェント名、所有者、目的、稼働環境
- MCPサーバー、API、データベースなどの接続先
- 参照、作成、更新、削除に分けた操作権限
- 実行者、実行時刻、入力、出力、外部処理の監査ログ
- 異常時に止める担当者、停止方法、復旧条件
AIエージェントの数を増やす前に、接続と権限を横断して見られる台帳を作ることが先です。台帳があれば、同じデータへ複数のエージェントがアクセスしていないか確認できます。
PoCを本番へ移す評価手順
PoC(概念実証)では、想定した質問に答えられるかを試しがちです。本番移行では、正答率だけでなく、誤った入力や接続障害が起きたときに安全側へ倒れるかを確認します。
- 1. 業務範囲と禁止操作を決め、台帳へ登録する
- 2. 接続先ごとに必要な権限だけを割り当てる
- 3. 正常系、権限外の依頼、障害時の3場面を試す
- 4. 実行ログから原因と利用者を追跡できるか確認する
- 5. 停止、復旧、権限変更の手順を担当者と実演する
| 確認段階 | 見る項目 | 本番移行の判断 |
|---|---|---|
| 接続前 | 接続先と操作権限 | 目的外の接続がない |
| 試験中 | 異常時の応答と停止 | 人の確認へ戻せる |
| 運用前 | 実行者と処理内容のログ | 後から追跡できる |
| 運用後 | 権限と接続先の見直し | 変更履歴を残せる |
評価の結果は、導入するか見送るかの2択にしなくても構いません。接続先を限定する、更新操作を人の承認後にする、対象業務を狭めるといった条件付きの移行も選べます。
自社で詰まりやすい管理項目
自社だけで進める場合、最初に台帳の項目を決めても、既存のAPIやMCPサーバーを洗い出す段階で漏れが出ることがあります。部門ごとに異なる名称や権限ルールを、同じ表へそろえる作業も必要です。
- 稼働中のエージェントと試験中のエージェントが混在する
- APIやMCPサーバーの所有者が接続ごとに異なる
- 監査ログは残っていても、誰の操作か追跡できない
- 停止手順が決まっておらず、緊急時の判断が個人に集中する
外部の支援を使うと、製品を先に決めるのではなく、現状の接続、権限、ログ、運用担当を整理してから要件を固めやすくなります。導入後に社内で見直せる状態まで引き継げるかも、依頼前に確認したい点です。
BinxAI株式会社 | みっちゃくん
BinxAI株式会社のみっちゃくんは、提案の前に現場へ入り、課題の整理と現状の診断を済ませてから要件を固めます。要件を整理したうえで詳細な見積を出し、契約後に要件が動いても決めた範囲で優先順位を入れ替えて進むスタイルです。企画、課題整理、要件整理から開発までを、同じ担当が一気通貫で受け持ちます。
本番環境への展開後は、運用の引き継ぎ、内製化、担当者向け研修まで支援します。
- 課題の整理と現状の診断
- 要件定義と設計
- 開発と本番環境への展開
- 運用の引き継ぎと内製化の支援
- 担当者向けの研修
よくある質問
Agent FabricとOmni Gatewayの違いは？
Agent Fabricはエージェントの発見、接続、権限、監視を扱う管理基盤です。Omni Gatewayは、エージェントと外部のMCPサーバーやAPIの接続を制御する窓口として捉えると整理しやすいでしょう。
MCP接続先は何から棚卸ししますか？
まず接続先の名称、所有者、利用目的、扱うデータ、許可している操作を並べるところから始まります。次に、現在も使われているか、停止時にどの業務へ影響するかを確認しましょう。
監査ログには何を残しますか？
少なくとも実行者、実行時刻、利用したエージェント、接続先、実行内容、結果を追跡できる形が必要です。入力や出力に機密情報が含まれる場合は、保存範囲と閲覧権限も別途定めておくとよいでしょう。
PoCから本番へ移せないときの最初の確認は？
回答の精度だけでなく、権限外の依頼、外部接続の失敗、誤操作、停止の4場面を試すことが出発点。結果を台帳とログへ結び付け、誰がいつ判断するかを決めると次の課題が見えます。
Salesforceを使っていなくても考え方は使えますか？
使えます。Agent FabricやOmni Gatewayの採用判断とは別に、エージェント台帳、接続先、権限、監査ログ、停止手順を一体で管理する考え方は、他の業務基盤にも応用できます。
あわせて読みたい
AIエージェントが増えた会社では、個々の性能比較だけでなく、接続、権限、ログ、停止を横断して管理する視点が欠かせません。まずは台帳を作り、PoCを本番へ移せる条件を1つずつ確認してください。
本記事に挙げた他社の料金や制度は、執筆時点で公開されていた情報です。お申し込みの前に、各社の最新の内容をご確認ください。
この記事の分類
同じ分類の記事をまとめて読めます。
次に読む記事
MCP接続と権限を一元管理WSO2 Agent Managerの実力
WSO2が一般提供を始めたAgent Managerは、AIエージェント固有IDやMCP接続、権限、ライフサイクルをどう管理するのでしょうか。Kubernetes上のサンドボックスや監査ログを含め、複数部門へ展開する前の確認項目を整理します。
AIエージェントの接続・予算・監視をまとめて管理する設計と評価の進め方
Nutanix Enterprise AI 2.8とAgent Gatewayの更新を起点に、MCPサーバーの接続許可、AIエージェントの権限、トークン予算、稼働ログを一体で管理する設計と、ハイブリッド環境での評価項目を整理します。
誰がどのAIを使うのかSAS AI Navigatorが示す統制の形
SAS AI Navigatorが示すAIガバナンスの新しい形を、モデルやAIエージェントの棚卸しから実験・承認・廃止までの管理として整理します。自社で先に決める台帳項目と責任者、運用へ落とす際の注意点も紹介します。
