Microsoft AzureでAIエージェントを全社展開する場合、最初にやるべきことは「AIエージェントを管理対象の資産として棚卸しし、ID・権限・データアクセス・利用ツール・ログ・コストを一元的に追跡する」ことです。今回のCloud Adoption Frameworkの公式情報は、AIエージェントを単なるチャット機能ではなく、データへアクセスし、業務アクションを実行し、委任された権限で動く存在として扱うよう求めています。(Microsoft Learn)
特に管理者は、Microsoft Agent 365、Microsoft Entra Agent ID、Microsoft Purview、Microsoft Defender for Cloud、Azure Monitor、Microsoft Sentinel、Microsoft Foundry、Copilot Studioの役割を整理し、開発者任せの個別運用から脱却する必要があります。開発者側も、PoCの延長で本番展開するのではなく、Managed Identity、RBAC、DLP、監視、レッドチームテスト、MCPサーバー管理を展開前の必須チェックに組み込むべきです。(Microsoft Learn)
今回の公式情報で押さえるべきポイント
Cloud Adoption Frameworkの「Governance and security for AI agents across the organization」は、AIエージェント導入プロセスのうち「Govern agents」にあたる内容です。公式リポジトリでは2026年6月2日に該当ファイルへの更新履歴があり、日本時間で6月3日前後に確認する管理者にとっては、AIエージェント統制の見直し対象として扱うべき内容です。(GitHub)
今回の要点は、次の4層でAIエージェントを管理することです。
| 層 | 主な目的 | 関連するMicrosoftサービス・機能 | 管理者が確認すべきこと |
|---|---|---|---|
| データガバナンスとコンプライアンス | データの利用範囲、保存場所、保持期間を制御する | Microsoft Purview、Copilot Studioのガバナンス機能、データ所在地制御 | RAG、ログ、メモリ、学習データに個人情報や機密情報が含まれていないか |
| エージェント可観測性 | どのエージェントが、誰の責任で、何をしているかを把握する | Microsoft Agent 365、Defender for Cloud、Azure Log Analytics、Application Insights、Cost Management | 所有者不明、未管理、コスト不明のエージェントがないか |
| エージェントセキュリティ | プロンプト操作、データ漏えい、権限乱用を防ぐ | Defender for Cloud AI threat protection、Content Safety、AI Red Teaming Agent、Azure RBAC、Microsoft Sentinel | 本番前テスト、最小権限、SOC連携、インシデント対応手順があるか |
| エージェント開発標準 | 開発方法、外部ツール連携、エージェント間通信を標準化する | Microsoft Agent Framework、Foundry SDK、MCP、A2A | 承認済みSDK・プロトコル・MCPサーバーだけを使っているか |
この整理で重要なのは、AIエージェントの管理範囲がMicrosoft Foundryだけに閉じない点です。Copilot Studioで作られたローコードエージェント、Microsoft 365上のエージェント、外部パートナー製エージェント、独自MCPサーバーを使うカスタムエージェントも、同じ統制対象として見る必要があります。(Microsoft Learn)
変更点は「AIエージェントをどこで動かすか」より「どう統制するか」へ寄ったこと
今回の更新で目立つのは、従来のPaaS、IaaS、SaaSという分類から、「Azure AIプラットフォーム」「Azureインフラストラクチャ」「SaaS上のAI」という整理へ表現が寄せられている点です。公式リポジトリの差分では、環境統制の説明が「PaaS、IaaS、SaaS」から「Azure AI platforms、Azure infrastructure、SaaS」へ変更されています。これは機能の廃止や破壊的変更というより、AIエージェントの展開先に応じてガバナンス責任を明確にするための整理と見るのが実務的です。(GitHub)
もう一つの変更点は、規制コンプライアンスの説明から特定の法令名の例示が削られ、データ保護法、業界認証、社内要件といった一般化された表現に変わっていることです。これは「特定の規制に対応すれば十分」という読み方を避け、業界・地域・データ種別ごとに自社で適用要件を判断する必要がある、というメッセージとして受け止めるべきです。(GitHub)
管理者が見直すべき社内文書は、次のようなものです。
| 見直す文書・設定 | 確認すべき観点 | 放置した場合のリスク |
|---|---|---|
| Azure Landing Zone設計書 | AIエージェント用に別アーキテクチャを作るのではなく、既存のID、ネットワーク、セキュリティ統制へ組み込めているか | PoC環境だけ統制が緩くなり、本番化時に手戻りが発生する |
| AI利用ポリシー | エージェントの所有者、利用目的、アクセス可能データ、許可ツールを定義しているか | 所有者不明のエージェントやシャドーAIが増える |
| RBAC設計 | Foundryリソース、Foundryプロジェクト、管理対象IDのスコープを分けているか | 開発者やエージェントに過剰権限を与える |
| DLP・データ分類ルール | プロンプト、応答、ログ、RAG用データソースに感度ラベルやDLPを適用できているか | 内部情報や個人情報が回答・ログ・外部ツール経由で漏れる |
| 監視・SOC連携 | AI関連アラートをDefender、Log Analytics、Sentinelへ集約しているか | 攻撃や異常動作に気付けない |
影響範囲はAzure管理者、Microsoft 365管理者、開発チームにまたがる
この公式情報の影響範囲は、Azureの一部サービスだけではありません。AIエージェントはID、データ、アプリ、SaaS、外部APIをまたぐため、Azure管理者だけで完結しない点が重要です。
| 役割 | 主な影響 | 最初に確認する場所 |
|---|---|---|
| Azure管理者 | Foundry、Azure Monitor、Log Analytics、Defender for Cloud、RBAC、ネットワーク制御の設計 | Azure Portal、Defender for Cloud、Azure Policy、Cost Management |
| Microsoft 365管理者 | Agent Registry、Agent settings、Agent Tools、MCPサーバー、ユーザーアクセス制御 | Microsoft 365 admin center |
| セキュリティ担当 | AI脅威検知、DLP、感度ラベル、SOC連携、インシデント対応 | Microsoft Defender、Microsoft Sentinel、Microsoft Purview |
| 開発者 | Managed Identity、最小権限、入力・出力フィルタ、レッドチームテスト、監視組み込み | Microsoft Foundry、SDK、CI/CD、Application Insights |
| コンプライアンス担当 | データ所在地、保持期間、削除要求、監査証跡 | Purview、ログ保持設定、社内規程 |
Microsoft Learnでは、Agent 365を採用していない場合でも、Microsoft Entra、Microsoft Purview、Microsoft Defender、Azure Monitorからガバナンスシグナルを集める構成が示されています。つまり、Agent 365がない環境でも「何もしない」のではなく、既存のAzureとMicrosoft 365の統制機能を組み合わせて暫定的な管理面を作ることが求められます。(Microsoft Learn)
管理者が確認すべき設定
エージェント台帳と所有者を整備する
最初に確認すべきなのは、組織内に存在するAIエージェントの一覧です。Microsoft 365 admin centerのAgent Registryは、組織内で利用可能なエージェントを一元的に確認する機能で、Microsoft製、外部パートナー製、自社公開、作成者共有のようにタイプ別に整理できます。また、所有者不明のエージェントや、Agent 365外で作成・管理される未管理エージェントも確認対象になります。(Microsoft Learn)
台帳には最低限、次の項目を入れてください。
| 項目 | 記録する内容 |
|---|---|
| エージェント名 | 利用者が識別できる名称 |
| 所有者 | 業務責任者と技術責任者を分けて記録 |
| 利用目的 | 例：社内FAQ、営業支援、問い合わせ分類、コードレビュー支援 |
| 実行環境 | Foundry、Copilot Studio、Microsoft 365、独自実装など |
| アクセスするデータ | SharePoint、Dataverse、Blob Storage、SQL、外部APIなど |
| 利用するツール | MCPサーバー、コネクタ、社内API、外部SaaSなど |
| 権限 | Managed Identity、Entra Agent ID、RBACロール、委任権限 |
| コスト管理 | コストセンター、タグ、予算アラート |
| リスク区分 | 社内限定、顧客対応、個人情報処理、外部連携ありなど |
失敗しやすいのは、エージェントの「作成者」だけを所有者として扱うことです。作成者が退職・異動すると所有者不明になります。業務責任者、技術責任者、セキュリティ承認者を分けて記録する方が、監査や障害対応で困りません。
Agent settingsで許可タイプ、共有、ユーザーアクセスを確認する
Agent settingsでは、許可するAIエージェントの種類、セキュリティテンプレート、共有方法、ユーザーやグループのアクセスを管理できます。組織全体でエージェントの利用を広げる前に、全ユーザーが自由に共有できる状態になっていないか、部署やロールに応じたアクセス制御ができているかを確認してください。(Microsoft Learn)
特に確認すべき設定は次の通りです。
| 設定 | 推奨される確認 |
|---|---|
| Allowed agent types | Microsoft製、外部パートナー製、自社製、個人共有のどれを許可するか |
| Sharing | 組織全体共有を許可する条件、承認フローの有無 |
| User access | 部署、職務、機密情報へのアクセス権に応じたグループ制御 |
| Security templates | 新規エージェントに適用する既定のポリシー、許可リスト、ルール |
| Ownerless agents | 所有者不明エージェントを検出し、管理者または上長へ再割り当てする運用 |
AIエージェントの展開初期は、全面禁止よりも「監視から開始し、リスクが高い領域から段階的に制限する」方が現実的です。ただし、顧客データ、個人情報、決済情報、法務・人事情報を扱うエージェントは、最初から厳しい承認制にするべきです。
Microsoft Entra Agent IDとManaged Identityで認証を標準化する
AIエージェントの行動は、誰が、どの権限で、どのリソースにアクセスしたかを追跡できなければなりません。Microsoftの公式情報では、エージェントごとに固有のIDを持たせ、Microsoft Entra Agent IDやManaged Identityを使って認証・認可・ライフサイクル管理を行う考え方が示されています。EntraのエージェントID機能では、条件付きアクセス、リスク検出、ポリシー適用なども管理対象になります。(Microsoft Learn)
開発チームがやりがちな危険な実装は、複数のエージェントで同じアプリ登録や同じシークレットを使い回すことです。これでは、問題発生時にどのエージェントが操作したのか分からず、権限停止の範囲も広がります。
実務では、次の基準で見直してください。
| 確認項目 | 推奨される状態 |
|---|---|
| 認証方式 | 可能な限りManaged IdentityまたはEntraベースの認証を使用 |
| シークレット | コード、環境変数、プロンプト、ログに平文で残さない |
| RBAC | Foundryリソース、Foundryプロジェクト、データソースごとに最小権限 |
| スコープ | サブスクリプション全体ではなく、必要なリソースまたはプロジェクト単位 |
| 監査 | どのIDが、いつ、何へアクセスしたかをログで追跡可能にする |
FoundryのRBACでは、FoundryリソースとFoundryプロジェクトというスコープを意識する必要があります。公式ドキュメントでは、Foundry User、Foundry Ownerなどのロール名変更にも触れられており、旧名称が一部に残る可能性がある点にも注意が必要です。(Microsoft Learn)
Agent ToolsとMCPサーバーを許可制にする
AIエージェントのリスクは、モデルそのものだけでなく、接続するツールから生まれます。Agent Toolsでは、AI-powered toolsやMCPサーバーを一覧化し、利用可否を管理できます。ツールはエージェントがユーザーデータ、業務フロー、外部システムへアクセスする経路になるため、登録されているだけで安心せず、どのデータや操作を公開するのかを確認してください。(Microsoft Learn)
特にMCPサーバーは、社内APIや業務ロジックをAIエージェントに公開する強力な仕組みです。便利な一方で、管理者の可視性がないまま導入されると、機密データの取得、外部送信、誤操作の経路になります。Bring Your Own MCP serverは公式情報上プレビュー機能として扱われており、本番利用の判断では利用条件とサポート範囲を必ず確認する必要があります。(Microsoft Learn)
運用ルールとしては、次の3段階に分けると管理しやすくなります。
| 区分 | 例 | 扱い |
|---|---|---|
| 許可 | Microsoft提供、社内審査済み、ログ取得済みのMCPサーバー | 本番利用可 |
| 条件付き許可 | 部署限定、検証環境のみ、読み取り専用API | 期限付きで許可 |
| ブロック | 出所不明、外部送信あり、ログなし、所有者不明 | 利用不可 |
Defender for Cloud、Azure Monitor、SentinelでAI固有の異常を監視する
AIエージェントの監視では、CPUやメモリだけでは不十分です。プロンプト操作、不審なデータアクセス、想定外のツール呼び出し、応答の急増、トークン消費の異常、失敗率の上昇などを追跡する必要があります。
Defender for CloudのAI threat protectionは、AIワークロードのアラートをDefender XDRに統合し、セキュリティチームが生成AIアプリケーションに関わる攻撃範囲を把握できるようにする機能です。公式情報上、AI threat protectionはGAとして整理され、サポート対象には制限があるため、対象モデルやトークン種別を確認してから監視設計に組み込む必要があります。(Microsoft Learn)
監視設計では、最低限次のログを残してください。
| ログ | 目的 |
|---|---|
| エージェント呼び出しログ | 誰がどのエージェントを使ったかを追跡 |
| データアクセスログ | どのデータソースへアクセスしたかを確認 |
| ツール実行ログ | MCPサーバー、API、コネクタの呼び出しを追跡 |
| 応答・失敗ログ | 異常な回答、拒否、タイムアウト、失敗率を分析 |
| コストログ | トークン、API、コンピュート利用量を部署・用途別に把握 |
| セキュリティアラート | SOCやインシデント対応へ連携 |
注意したいのは、ログにプロンプトや応答をそのまま保存すると、機密情報をログ基盤に複製してしまう点です。監査に必要な情報と、保存してはいけない個人情報・認証情報を分け、マスキングや保持期間の設定を必ず行ってください。
開発者が本番展開前に確認すべきポイント
入力と出力を「信用しない」設計にする
AIエージェントは自然言語、ファイル、画像、外部データ、APIレスポンスなどを扱います。公式情報でも、入力・出力フィルタリング、敵対的入力、データ漏えい、プロンプトインジェクション、ジェイルブレイクへの対策が重視されています。(Microsoft Learn)
開発時は、次のような前提で設計してください。
| 対象 | 確認ポイント |
|---|---|
| ユーザー入力 | 命令上書き、スクリプト、過剰なファイルサイズを拒否する |
| RAGデータ | 権限のない文書を検索結果に出さない |
| 外部APIレスポンス | APIから返るテキストも悪意ある入力として扱う |
| 出力 | 個人情報、カード番号、秘密情報、内部URLを返さない |
| ツール呼び出し | 実行前に権限と操作内容を検証する |
| ログ | 機密値を記録しない |
特にRAGを使う社内検索エージェントでは、「検索対象に入っているから回答してよい」と考えるのは危険です。ユーザーの権限を引き継いで検索し、回答生成後にもDLPや感度ラベルに基づくチェックを入れる必要があります。
レッドチームテストを本番前と大きな更新後に実施する
AI Red Teaming Agentは、AIアプリケーションに対して攻撃プロンプトを生成し、リスクカテゴリごとにテストするための仕組みです。公式情報では、既定のリスクカテゴリや攻撃プロンプト数を使った例が示されていますが、同時に「単一ターン」「テキストのみ」といった制限や、利用可能リージョンの制限も明記されています。(Microsoft Learn)
そのため、本番前チェックでは「AI Red Teaming Agentを実行したか」だけでなく、次の点まで確認してください。
| 確認項目 | 判断基準 |
|---|---|
| 対象範囲 | モデル単体ではなく、RAG、ツール、認証、ログまで含めて確認したか |
| テストケース | 業務固有の禁止事項や機密情報を含む攻撃シナリオを追加したか |
| 実施タイミング | 初回本番化前、大きなプロンプト変更後、データソース追加後に実施したか |
| 例外処理 | ブロック時のユーザー表示、管理者通知、ログ記録があるか |
| 残リスク | 既知の制限をリリース判定資料に残しているか |
AIエージェントは、モデルを変えていなくても、接続先データ、プロンプト、ツール、権限が変われば挙動が変わります。アプリケーションのコード更新だけをテスト対象にする運用では不十分です。
ネットワークとデータ面の保護を後回しにしない
Microsoft Foundryのセキュリティベースラインでは、NSG、Private Link、パブリックネットワークアクセス無効化、Entra IDによるデータプレーンアクセスなど、通常のAzureワークロードと同様のセキュリティ管理が整理されています。Foundryを使う場合でも、AIだから特別に緩めるのではなく、既存のAzureセキュリティ基準に組み込むことが重要です。(Microsoft Learn)
PoC段階でありがちな失敗は、検証を急ぐあまり、パブリックアクセス、広すぎるRBAC、共有キー、未設定の診断ログをそのまま本番へ持ち込むことです。PoC環境であっても、本番化の可能性があるなら最初からタグ、RBAC、ネットワーク境界、ログ設定をIaCに含めておくべきです。
移行・展開時の実務チェックリスト
AIエージェントのガバナンスは、一度に全機能を厳格化しようとすると現場が止まります。現実的には、棚卸し、監視、制御、本番ゲートの順に進めると失敗しにくくなります。
| フェーズ | 実施内容 | 完了の目安 |
|---|---|---|
| 棚卸し | 既存エージェント、所有者、データソース、利用ツール、コストを一覧化 | 所有者不明・未管理エージェントが見える状態 |
| 監視 | Azure Monitor、Application Insights、Log Analytics、Defender、Cost Managementを接続 | 利用量、異常、コストを部署・用途別に追える状態 |
| 制御 | Entra Agent ID、Managed Identity、RBAC、DLP、許可ツール、Agent settingsを適用 | 新規エージェントが標準ポリシーなしで作られない状態 |
| 本番ゲート | レッドチームテスト、DLP確認、ログ保持、インシデント対応、停止手順を確認 | リリース判定でAI固有リスクを説明できる状態 |
移行時に特に注意したいのは、既存のPoCエージェントです。PoCで作ったエージェントは、作成者の個人権限、共有シークレット、広いデータアクセス、未整備のログ設定を持っていることがあります。本番移行時は、アプリケーション移行ではなく「IDとデータアクセスの再設計」として扱ってください。
管理者と開発者が避けるべき失敗
AIエージェントのガバナンスでよくある失敗は、技術不足よりも「責任範囲が曖昧なまま展開すること」です。
| 失敗例 | なぜ危険か | 対策 |
|---|---|---|
| エージェントを作成者個人の管理に任せる | 異動・退職で所有者不明になる | 業務責任者と技術責任者を台帳に登録 |
| すべてのエージェントに同じ権限を与える | 侵害時の影響範囲が広がる | エージェント単位でIDとRBACを分ける |
| RAGデータの権限継承を確認しない | 本来見えない文書を要約してしまう | ユーザー権限を引き継いだ検索とDLPを適用 |
| MCPサーバーを自由登録にする | 外部送信や業務操作の抜け道になる | 許可制、ログ取得、所有者登録を必須化 |
| ログを残さない | 事故時に原因と影響範囲を追えない | 操作、データアクセス、ツール呼び出しを記録 |
| ログに機密情報を残しすぎる | 監査ログ自体が情報漏えい源になる | マスキング、保持期間、アクセス制御を設計 |
| レッドチームテストを初回だけにする | データやツール変更後のリスクを見逃す | 本番前と重要変更後に再実施 |
| コストタグを付けない | トークンやAPIコストが部署別に見えない | エージェント単位または用途単位でタグ付け |
まず実施すべき次のアクション
Microsoft AzureでAIエージェントを安全に展開するなら、最初のアクションは新機能の有効化ではなく、既存エージェントの棚卸しです。Agent Registryや既存のAzureリソース、Copilot Studio、Foundryプロジェクト、Microsoft 365上の共有エージェントを確認し、所有者、データソース、権限、ツール、コストを一覧化してください。
次に、リスクの高いエージェントから順に、Entra Agent IDまたはManaged Identity、最小権限RBAC、Purview DLP、Defender for Cloud、Azure Monitor、Sentinel連携を適用します。新規開発では、MCPサーバーや外部ツールの利用を許可制にし、本番前のレッドチームテストとインシデント停止手順をリリース条件に入れるべきです。
今回のCloud Adoption Frameworkのメッセージは明確です。AIエージェントは、便利な自動化部品ではなく、組織のデータへアクセスし、業務を実行する新しい管理対象です。今後の展開では、「誰が作ったか」ではなく「誰が責任を持ち、どの権限で、どのデータにアクセスし、何を実行できるか」を説明できる状態にすることが、Azure管理者と開発者の共通の出発点になります。
コメント