企業AIエージェント管理基盤の選び方｜Agent 365・Gemini Enterprise Agent Platformから考える統制設計

目次

---

1. AIエージェント導入は「作る」から「管理する」段階へ移った

2026年の企業AIエージェント導入では、論点が大きく変わり始めています。これまでは、どのモデルを使うか、どのフレームワークで作るか、どの業務を自動化するかが主な関心でした。LangGraph、CrewAI、OpenAI Agents SDK、Google ADKのような開発フレームワークを比較し、まず動くPoCを作ることが多かったはずです。

しかし、AIエージェントが本番業務に入ると、問題は「作れるか」だけでは済みません。どのエージェントが社内に存在するのか。誰が責任者なのか。どのデータへアクセスできるのか。どの操作は自動実行してよく、どの操作は人間承認が必要なのか。失敗したときに、どのログを見れば原因を追えるのか。こうした管理面を設計しないままエージェントだけを増やすと、便利さよりもリスクが先に大きくなります。

Microsoft Agent 365やGoogleのGemini Enterprise Agent Platformが注目される理由は、まさにここにあります。どちらも、単にAIエージェントを作るための部品ではありません。企業内に増えていくAIエージェントを可視化し、IDを与え、権限を管理し、実行状況を観測し、ポリシーに沿って運用するための基盤として位置づけられています。

これは、企業ITにとって自然な流れです。SaaSが増えたときには、ID管理、SSO、アクセス制御、ログ監査、CASBのような仕組みが必要になりました。クラウド利用が広がったときには、クラウド設定監査、権限管理、ネットワーク制御、コスト管理が重要になりました。同じように、AIエージェントが増えるほど、エージェントそのものを管理する仕組みが必要になります。

この記事では、Microsoft Agent 365とGemini Enterprise Agent Platformの動向を手がかりに、企業がAIエージェント管理基盤を選ぶときの考え方を整理します。特定製品の優劣を決めるのではなく、社内AIエージェントを本番展開する前に必要なID、レジストリ、ゲートウェイ、監査ログ、評価、責任分界の設計を見ていきます。

2. Agent 365とGemini Enterprise Agent Platformが示す方向性

Microsoft Agent 365は、企業内で増えていくAIエージェントを観測し、統制し、保護するための管理基盤として打ち出されています。Microsoft 365、Copilot Studio、Azure Foundry、サードパーティランタイムなどで作られたエージェントを、管理者が把握し、セキュリティやコンプライアンスの観点から扱えるようにする考え方です。

Microsoftの強みは、既存の企業IT管理に近い場所からAIエージェントを扱える点にあります。Microsoft 365管理センター、Entra、Defender、Purview、条件付きアクセス、データ損失防止、監査といった企業利用でなじみのある仕組みに、エージェントの可視化や制御を重ねていく方向です。すでにMicrosoft 365やTeams、SharePoint、Entra IDを中核にしている企業にとっては、AIエージェントを既存の管理体系へ組み込みやすい発想です。

一方、Gemini Enterprise Agent Platformは、Google Cloud上でAIエージェントを構築、配備、統制、最適化する基盤として整理されています。GoogleはAgent Identity、Agent Registry、Agent Gateway、Agent Runtime、Memory Bank、Observability、Evaluationといった要素を並べ、エージェントを本番システムとして扱うための構成を示しています。

Googleの方向性で特徴的なのは、エージェントごとの強いID、承認済みエージェントやツールを登録するレジストリ、エージェントと内部ツールの通信を制御するゲートウェイを組み合わせている点です。MCPサーバーや社内APIのような外部ツールへ接続する場面でも、どのエージェントが、どのユーザーの文脈で、どのリソースへアクセスしたのかを追いやすくする設計です。

両者に共通しているのは、AIエージェントを「便利な自動化スクリプト」ではなく、「企業内で管理すべき実行主体」と見ていることです。人間ユーザーにはIDがあり、部署があり、権限があり、退職時にはアクセスが止まります。アプリケーションにも登録、認可、ログ、責任者があります。AIエージェントも同じように、存在を把握し、責任者を持ち、権限を絞り、実行結果を追える状態にする必要があります。

3. 管理基盤に必要な5つのレイヤー

AIエージェント管理基盤を選ぶときは、製品名よりも先に、何を管理したいのかを分解した方が判断しやすくなります。重要なレイヤーは、大きく5つあります。

最初のレイヤーはIDです。AIエージェントが人間ユーザーの権限をそのまま借りて動くと、ログ上は「社員が実行した」ように見えます。しかし実際には、社員が直接操作したのか、AIが下書きを作ったのか、AIがツールを呼んだのか、AIが自動で送信したのかで意味はまったく違います。エージェントに固有のIDを与え、必要に応じてユーザーの代理として動いたことも記録できる設計が必要です。

次にレジストリです。企業内でAIエージェントが増えると、「誰かが作った便利なエージェント」が部署ごとに散らばります。営業向け、情シス向け、経理向け、開発向け、問い合わせ対応向けなど、用途は広がります。レジストリがないと、どのエージェントが本番利用中なのか、どのツールへ接続しているのか、責任者は誰なのかが分からなくなります。これはシャドーAIの温床になります。

ゲートウェイは、AIエージェント時代の重要な制御点です。AIエージェントは単体では大きな価値を出しにくく、社内API、ファイル、データベース、SaaS、MCPサーバー、ブラウザ操作などとつながって初めて業務を進めます。だからこそ、接続点でアクセス制御、ポリシー適用、監査ログ、危険操作のブロックを行う必要があります。すべてのツール連携をエージェント開発者の実装任せにすると、業務ごとに安全性がばらつきます。

観測性も欠かせません。AIエージェントの最終回答だけを保存しても、運用には不十分です。どの入力を受け、どのプロンプトで判断し、どのツールを呼び、どのデータを取得し、どの段階で失敗したのか。こうした実行履歴が見えなければ、誤回答の原因調査も、監査対応も、改善もできません。エージェント運用では、ログは付録ではなく、品質を支える中核機能です。

最後に評価です。エージェントは、リリースした瞬間に完成するものではありません。モデルの更新、プロンプト変更、業務ルール変更、接続先APIの仕様変更、社内文書の更新によって挙動が変わります。代表的な業務シナリオ、失敗してはいけないケース、拒否すべき依頼、承認が必要な操作を評価データとして持ち、変更のたびに再テストできる体制が必要です。

4. Microsoft 365中心の企業とGoogle Cloud中心の企業で選び方は変わる

AIエージェント管理基盤の選定では、単純に機能一覧を比べるだけでは不十分です。どちらが高機能かよりも、自社のID基盤、クラウド基盤、業務アプリ、開発体制、監査体制にどれだけ自然に入るかが重要です。

Microsoft 365を業務の中心にしている企業では、Agent 365を軸に検討する意味があります。Teams、SharePoint、Outlook、Microsoft 365 Copilot、Copilot Studio、Entra ID、Defender、Purviewがすでに社内標準になっている場合、エージェント管理も同じ管理体系に寄せた方が運用負荷を抑えやすくなります。管理者が見慣れたポータルで、エージェントの利用状況、アクセス、セキュリティシグナル、ライフサイクルを扱えることは大きな利点です。

たとえば、Teams上で動く営業支援エージェント、SharePoint文書を参照する社内FAQエージェント、Microsoft 365内のデータを使う業務支援エージェントが中心なら、Microsoftの管理基盤と相性が良くなります。既存の条件付きアクセス、DLP、監査、データ保持ポリシーと合わせて考えやすいからです。

Google CloudをAI開発基盤にしている企業では、Gemini Enterprise Agent Platformを検討しやすくなります。Vertex AI由来の開発・モデル選択・配備の流れ、Agent Runtime、Agent Identity、Agent Registry、Agent Gateway、Cloud Observabilityを組み合わせ、Google Cloud上でエージェントを本番システムとして運用する発想です。MCPサーバー、社内API、クラウドリソースを統制しながらつなぐ構成を作りたい場合に向いています。

特に、AIエンジニアがコードでエージェントを開発し、クラウド上に配備し、複数のモデルやツールを使い分け、評価と観測性を継続的に回したい企業では、Google Cloud側の統合基盤が合う可能性があります。Agent GatewayやAgent Registryの考え方は、エージェントとツールが増えるほど効いてきます。

ただし、現実の企業ではMicrosoft 365とGoogle Cloud、AWS、オンプレミス、各種SaaSが混在します。その場合は、どちらか一つで全社を完全に統一するより、管理境界を決めることが重要です。Microsoft 365内の業務エージェントはAgent 365で管理し、Google Cloud上で開発・配備するエージェントはGemini Enterprise Agent Platformで管理する。さらに、全社の監査ログやSIEMへ必要な情報を集約する。こうした分担設計が現実的です。

選定時には、次の観点で見比べると判断しやすくなります。

どちらを選ぶ場合でも、避けたいのは「導入製品があるから安全」と考えることです。管理基盤は、社内ルール、業務設計、データ分類、責任者、評価データ、ログ運用と組み合わせて初めて機能します。

5. 本番展開前に決めるべき運用ルール

AIエージェント管理基盤を導入する前に、社内で決めておくべきことがあります。ここを曖昧にしたまま製品を入れると、管理画面はできても運用判断ができません。

まず、エージェントの登録ルールです。誰でも自由に本番エージェントを作れる状態は危険です。一方で、すべてを情シス承認にすると現場の改善が止まります。現実的には、試作、部門内利用、本番利用、全社利用のように段階を分け、段階ごとに必要なレビューを変える設計がよいでしょう。試作では軽く、社外送信や基幹システム更新を含む場合は厳しくする、という考え方です。

次に、責任者の設定です。AIエージェントには、業務責任者と技術責任者の両方が必要です。業務責任者は、そのエージェントが何をしてよいか、成果物を誰が確認するか、業務ルールが変わったときにどう更新するかを判断します。技術責任者は、モデル、プロンプト、ツール、ログ、権限、障害対応を管理します。責任者がいないエージェントは、本番利用すべきではありません。

三つ目は、操作権限の分類です。AIエージェントが行う操作を、読み取り、下書き作成、更新、送信、削除、外部公開、支払い、権限変更のように分けます。多くの業務では、読み取りや下書き作成までは自動化しやすい一方、送信、削除、支払い、権限変更は人間承認を必須にすべきです。この境界を決めずに「AIに任せる」と、事故時に止める場所が分からなくなります。

四つ目は、ログの保存と利用です。エージェント管理基盤を入れても、ログを誰が見るのか、どの期間保存するのか、どのログを監査対象にするのか、改善にどう使うのかを決めていなければ活用されません。実行ログは、監査のためだけでなく、評価データセットを更新する材料でもあります。失敗例、差し戻し理由、承認者の修正内容を次の改善に使う仕組みが必要です。

五つ目は、停止条件です。AIエージェントは便利だからこそ、止める基準を先に決めておく必要があります。誤送信が起きた、機密情報に触れた、ツール呼び出しエラーが連続した、評価スコアが閾値を下回った、業務ルール変更後に再検証が終わっていない。こうした場合に、自動停止するのか、責任者へ通知するのか、一時的に読み取り専用へ落とすのかを決めておきます。

導入前チェックリストとしては、次の項目を確認するとよいでしょう。

• 本番利用するエージェントを登録する台帳がある
• 各エージェントに業務責任者と技術責任者がいる
• 読み取り、作成、更新、送信、削除、外部公開の権限を分けている
• 人間承認が必要な操作を明文化している
• 接続するMCPサーバー、社内API、SaaSを一覧化している
• 実行ログ、ツール呼び出し、承認履歴、失敗理由を追える
• 評価データセットと再テスト手順がある
• 停止条件と再開条件を決めている
• 退職、異動、業務終了時にエージェント権限を見直す流れがある

このチェックリストは、エージェント管理基盤を選ぶ前にも使えます。自社に必要な運用ルールが分かると、製品比較で見るべき機能も自然に絞られます。

6. 注意点：統制基盤だけではAIエージェントは安全にならない

Agent 365やGemini Enterprise Agent Platformのような管理基盤は、AIエージェントを本番展開するうえで重要な土台です。ただし、これらを入れれば自動的に安全になるわけではありません。AIエージェントのリスクは、管理基盤の外側にも広がるからです。

たとえば、エージェントが接続する社内API側に過剰な権限があれば、ゲートウェイで入口を管理しても、取得できるデータが広すぎる問題は残ります。MCPサーバーがファイルシステム全体へアクセスできる設計なら、エージェントIDを付けても影響範囲は大きくなります。RAG対象の文書に古い規程や誤った情報が混ざっていれば、エージェントは管理された状態で誤回答を返します。

また、AIエージェントの品質は、モデルだけで決まりません。プロンプト、ツール説明、業務ルール、データ整理、評価データ、例外処理、人間承認の設計が品質を左右します。管理基盤は、これらを見えるようにし、制御しやすくするための仕組みです。中身の設計まで自動で代わってくれるわけではありません。

もう一つの注意点は、現場の利便性です。管理を厳しくしすぎると、現場は未承認のAIツールへ流れます。反対に、何でも自由にすると、情シスやセキュリティ部門が追えません。AIエージェント運用では、禁止と解禁の二択ではなく、承認済みの安全な利用経路を作ることが重要です。低リスクな業務では素早く試せるようにし、高リスクな業務では承認やログを強める。リスクに応じた段階設計が現実的です。

さらに、ベンダーロックインにも注意が必要です。Microsoft 365中心、Google Cloud中心、AWS中心、オンプレミス中心、ローカルLLM中心など、企業ごとに基盤は違います。特定の管理基盤にすべてを寄せると、将来のモデル変更やクラウド方針変更が難しくなる場合があります。重要な業務では、エージェントの定義、評価データ、ログ、業務ルール、ツール仕様をできるだけ移行可能な形で持っておくことも検討すべきです。

管理基盤は、AIエージェントを安全にする万能薬ではありません。社内のデータ分類、権限設計、業務フロー、人間承認、評価、ログ活用と組み合わせることで、初めて本番運用に耐える仕組みになります。

7. まとめ

企業のAIエージェント導入は、PoCを作る段階から、増えていくエージェントをどう管理するかという段階へ進んでいます。Microsoft Agent 365やGemini Enterprise Agent Platformが示しているのは、AIエージェントを単なるツールではなく、企業内で管理すべき実行主体として扱う考え方です。

本番運用では、エージェントごとのID、承認済みエージェントとツールのレジストリ、社内リソースへの接続を制御するゲートウェイ、実行状況を追う観測性、品質とリスクを測る評価が必要になります。Microsoft 365中心の企業ならAgent 365が自然に入りやすく、Google Cloud中心でエージェント開発と配備を進める企業ならGemini Enterprise Agent Platformが候補になります。ただし、どちらを選んでも、業務責任者、権限分類、人間承認、停止条件、評価データを決めなければ、安全な本番運用にはなりません。

OpenBridgeでは、AIエージェント開発、MCP連携、RAG、ローカルLLM、業務システム連携、監査ログ設計まで含めて、企業向けAIシステムの導入を支援しています。AIエージェントをPoCで終わらせず、本番で使える業務基盤に育てるには、開発フレームワークの選定だけでなく、管理基盤と運用設計を最初からセットで考えることが重要です。