AIエージェントのID管理はなぜ必要か？Microsoftが自社環境で検証した安全運用

AIエージェントのID管理は、企業がエージェントを業務へ導入するときの前提になりつつあります。AIエージェントは質問へ回答するだけでなく、社内データを参照し、ツールを呼び出して処理を実行します。誰の権限で動いたのかが分からなければ、アクセス制御も監査も正確に行えません。

Microsoftは2026年8月27日、自社の本番テナント内でAIエージェントを安全に運用するために実施した「Securing AI Agents initiative」を公開しました。約100人の社内利用者が参加し、Windows 365、Microsoft Entra、Intune、Defender、Purviewなどを組み合わせて、実際の利用条件に近い環境で検証しています。

本記事では、Microsoftの取り組みから、なぜAIエージェントにも社員やサービスアカウントと同じ水準のID・権限管理が必要なのかを整理します。あわせて、企業が導入前に決めるべき実行環境、データ保護、監視、段階的な展開方法を解説します。

1. MicrosoftがAIエージェントの安全運用事例を公開

管理製品の説明ではなく、自社IT部門による実証

Microsoft Inside Trackによると、同社のIT部門であるMicrosoft Digitalは、Windows、Entra、Intune、Defender、Purview、Microsoft Securityの各チームと連携し、自社の企業環境でAIエージェントを安全に動かせるかを検証しました。目的は、統制されたデモ環境で機能を見せることではなく、実在する利用者と業務負荷の下で安全策が機能するかを確認することでした。

取り組みは当初、Microsoft Build 2026に向けた2週間の短期検証として始まりました。その後、製品部門と事業部門をまたぐ70人超の関係者が参加する活動へ拡大しています。AIエージェントの安全運用は、ID担当やセキュリティ担当だけでは完結せず、端末、ネットワーク、データ、業務運用の担当者が同じ設計を共有する必要があることを示す事例です。

約100人を対象に本番テナント内で検証

Microsoft Digitalは、約100人の社内利用者に専用のWindows 365 Cloud PCを提供しました。利用者はCopilot CLIやOpenClawが事前設定されたWindows環境で、開発者向けのユースケースを試しています。検証場所は完全に切り離された実験室ではなく、Microsoftの本番テナント内でした。

ただし、利用者が日常業務に使う主端末へ直接導入したわけではありません。Cloud PCを分離・初期化しやすい非主要環境として用意し、企業のIDやポリシーが適用される現実的な条件と、問題発生時に影響を止めやすい構成を両立しました。さらに、対象者を限定した段階的な展開と、リスクおよび利用者への影響の継続監視を行っています。

2. 約100人の実環境パイロットで検証した仕組み

端末・ID・データ・通信を一つの設計にする

Microsoftが検証したのは単独のセキュリティ機能ではありません。AIエージェントが動く端末から、認証、アクセス先、実行中の挙動、取り扱うデータまでをつなげて確認しました。Microsoft Inside Trackが挙げた主な構成は次のとおりです。

• Windows 365 Cloud PC：エージェント専用の実行環境を払い出し、必要に応じて分離・初期化する
• Microsoft Entra Agent ID：人とエージェントのIDを区別し、認証とアクセス判断の基点にする
• Microsoft Intune：端末とエージェントに適用する構成ポリシーを管理する
• Microsoft Defender：エージェントの実行時の挙動を監視し、脅威を検知・調査する
• Microsoft Purview：機密情報の取り扱いとDLP（情報漏えい防止）を適用する
• Microsoft Entra Global Secure Access：エージェントの通信をネットワーク層で制御する

Microsoftが公開した「Agent AI」のイメージ画像。

Microsoftは、これらにMicrosoft Agent 365を加えた構成を、エンドポイント、ID、データ、ネットワークの統制を組み合わせる設計として説明しています。重要なのは製品名ではなく、一つの許可だけで安全と判断しないことです。正規のIDで認証したエージェントでも、端末が未管理だったり、外部通信が無制限だったりすれば、企業が意図しない処理を実行する余地が残ります。

機能の有無ではなく実際の挙動を確かめる

AIエージェントは、入力へ一度回答して終わるとは限りません。目標に応じてデータを読み、複数のツールを順番に呼び出し、結果を次の判断へ使います。そのため、管理画面でポリシーが有効になっていることだけでは、統制が実際に働くか判断できません。

Microsoftは、実際のエージェントの動作に対してDefenderの実行時保護とPurviewのDLPを検証し、Global Secure Accessにも現実のエージェント通信を流しました。確認すべき対象は、プロンプトや最終回答だけではありません。参照したデータ、呼び出したツール、外部との通信、実行結果、拒否された操作まで記録し、想定外の動作を検知して止められるかを試す必要があります。

3. AIエージェントのID管理が必要な理由

人のIDを借りると責任と操作の区別が曖昧になる

Microsoftが特に重視したのが、人とAIエージェントのIDを分けることです。Entra Agent IDを使うと、エージェントは利用者のIDをそのまま借り続けるのではなく、エージェントとして識別できる固有のIDを持てます。これにより、誰が利用を開始したのか、どのエージェントが何へアクセスしたのかを分けて記録できます。

人のIDを共用すると、監査ログ上で社員の操作とエージェントの自動処理が混在します。担当者の異動や退職時には、エージェントまで停止するのか、別の社員へ権限が引き継がれるのかも不明確になります。固有IDに業務責任者、技術管理者、利用目的、有効期限を関連付ければ、アクセス審査や廃止の判断を行いやすくなります。

Microsoft Learnは、利用者の指示で動く対話型エージェントと、独立して処理する自律型エージェントを区別しています。前者では本人に許された範囲を越えない委任設計が必要です。後者ではエージェント自身のIDを用い、目的に必要な権限だけを付与します。人の代理権限とエージェント固有の権限を混同しないことが、AIエージェントのID管理の基本です。

社員やサービスアカウントと同じ統制を適用する

Microsoft Security Blogは、AIエージェントを社員やサービスアカウントと同じセキュリティ基準で扱うべきだと説明しています。具体的には、最小権限、明示的な検証、侵害を前提とするゼロトラストの考え方です。AIだから広い権限が必要なのではなく、実行する業務ごとに必要な範囲を定義します。

たとえば請求書処理エージェントなら、添付ファイルの読取り、取引先情報との照合、会計システムへの下書き登録は必要でも、取引先口座の変更や支払確定までは不要かもしれません。参照、作成、承認、実行を分け、影響が大きく取り消しにくい操作には人の承認を残します。アクセス権には期限を設け、使われていない権限や所有者不在のIDを定期的に見直すことも必要です。

4. IDだけでなく端末・通信・データも保護する

専用環境で影響範囲を限定する

AIエージェントのID管理は重要ですが、IDだけで安全運用が完成するわけではありません。認証後の処理が行われる端末、接続できるネットワーク、読み書きできるデータにも制御が必要です。Microsoftの検証では、専用Cloud PCを使い、日常業務の主端末から実行環境を分けました。

企業が同じ製品構成を採用しない場合でも、考え方は応用できます。初期導入では、対象システムとデータを限定した仮想環境や専用端末を用意し、問題があればセッション停止、ネットワーク分離、資格情報の失効、環境の初期化を行えるようにします。異常時にどこまで止めれば影響を封じ込められるかを、運用開始前に決めておくことが重要です。

ポリシーを重ね、ログを関連付ける

端末管理では、許可するアプリ、更新状態、保存先、コピー操作などを制御します。ネットワークでは、エージェントが接続できる社内システムや外部サービスを限定します。データ保護では、秘密度ラベルやDLPを使い、機密情報の外部送信や許可されていない保存を防ぎます。実行時監視では、通常と異なる大量参照、深夜の連続実行、禁止されたツールの呼び出しなどを検知対象にします。

さらに、IDの認証ログ、端末の状態、ネットワーク接続、データ操作、エージェントの実行履歴を関連付けて確認できる必要があります。アラートだけが残り、どの業務処理から発生したか追えない状態では、停止や復旧の判断が遅れます。Microsoftの事例が示すのは、個別製品の導入ではなく、複数の統制が実際の処理全体でつながる設計の重要性です。

5. 企業への学び：安全運用を始める手順

最初にID台帳と責任者を整える

企業が最初に行うべきことは、AIエージェントの棚卸しです。開発部門が把握する試作だけでなく、SaaSに組み込まれた機能、個人が導入したデスクトップアプリ、API経由で定期実行される処理も対象にします。少なくとも次の項目を台帳へ記録します。

• 識別情報：エージェント名、固有ID、開発・提供元、実行場所
• 業務情報：目的、利用部門、業務責任者、技術管理者、承認者
• アクセス情報：参照データ、接続先、権限、資格情報、有効期限
• 運用情報：利用者、実行頻度、監視方法、停止条件、廃止予定日
• 証跡情報：取得するログ、保存期間、確認担当者、事故時の調査手順

次に、業務を構成する操作を分解し、閲覧のみ、自動で下書き、人の承認後に実行、AIには許可しない、の段階に分類します。個人情報、金銭、契約、外部公開に関わる処理は優先して確認します。台帳上の所有者とID基盤上の所有者を一致させ、異動・退職・用途終了時の失効手順も決めます。

小規模な本番相当環境で拒否と復旧を試す

Microsoftの取り組みから得られる実務上のポイントは、管理された範囲で現実の条件を再現することです。対象者とユースケースを限定し、リセット可能な環境で、許可した操作だけでなく禁止した操作も試します。機密データの外部送信、権限外のファイル参照、未承認ツールの利用、資格情報の期限切れなどを発生させ、ポリシーが拒否し、担当者へ通知し、調査に必要なログが残るかを確認します。

導入後は段階的に対象を広げます。その際は、処理時間や手戻りの減少だけでなく、拒否件数、誤検知、アラート対応時間、権限見直し件数も測定します。Microsoftが示した「大きく考え、制御されたテストと現実のシナリオを両立し、人とエージェントを区別し、運用実態を試す」という考え方を、自社の導入判定基準へ置き換えることが重要です。

6. まとめ

Microsoftが2026年8月27日に公開した事例では、約100人の社内利用者が専用のWindows 365 Cloud PCを使い、本番テナント内でAIエージェントの安全運用を検証しました。中心となる考え方は、エージェントに固有IDを付与して人の操作と区別し、最小権限、端末管理、通信制御、データ保護、実行時監視を組み合わせることです。

企業がAIエージェントを導入するときは、機能比較より先に、ID台帳、責任者、権限、有効期限、人の承認を残す処理、停止・復旧手順を決める必要があります。そのうえで、小規模な本番相当環境において許可・拒否・監視・復旧を一連でテストし、段階的に展開します。AIエージェントのID管理を社員と同じ運用プロセスへ組み込むことが、安全な全社活用の出発点になります。

▶ [AIガバナンス支援サービスの詳細・お問い合わせはこちら] 

参考文献

• Microsoft Inside Track, “Securing AI agents in the enterprise: Learnings from our journey at Microsoft,” 2026年8月27日, https://www.microsoft.com/insidetrack/blog/securing-ai-agents-in-the-enterprise-learnings-from-our-journey-at-microsoft/
• Microsoft Security Blog, “80% of Fortune 500 use active AI Agents: Observability, governance, and security shape the new frontier,” 2026年2月10日, https://www.microsoft.com/en-us/security/blog/2026/02/10/80-of-fortune-500-use-active-ai-agents-observability-governance-and-security-shape-the-new-frontier/
• Microsoft Learn, “Microsoft Entra security for AI overview,” 2026年5月8日更新, https://learn.microsoft.com/en-us/entra/agent-id/security-for-ai-overview