AIエージェントが業務システムに組み込まれつつある今、「エージェントそのものをどう守るか」という問いが現実的な課題として浮上している。Microsoftはこの問いに対し、既存のセキュリティ製品群——Entra、Purview、Defender——を組み合わせた4層の統合アーキテクチャで答えようとしている。日本語メディアでほとんど取り上げられていない技術詳細を、今回は実務の文脈で読み解く。

AIエージェントは「新しいID」を持つ存在である

まず押さえておきたいのは、AIエージェントはユーザーでも従来のサービスアカウントでもない、第三のID種別だという点だ。Microsoftはこれを「Workload Identity（ワークロードID）」としてMicrosoft Entra上で管理する設計を取っている。

具体的には以下のメカニズムが働く：

  • マネージドID / サービスプリンシパルによるエージェントのID発行
  • 条件付きアクセス（Conditional Access）でエージェントのアクセス元・スコープを制限
  • Just-In-Time（JIT）アクセスにより、必要なときだけ必要な権限を付与

特にJITは重要だ。「常時アクセス権の付与は特権アカウント管理における最大のリスク」——これはAIエージェントにもそのまま当てはまる。エージェントに広い権限を常時持たせる設計は、侵害時の爆発半径（blast radius）を最大化する最悪のパターンだ。

データ保護層：PurviewがエージェントのI/Oを監視する

エージェントが触れる情報の機密性を制御するのがMicrosoft Purviewの役割だ。

  • 情報保護ラベル（Sensitivity Labels）がエージェントの入出力にも適用される
  • エージェントが「機密」ラベルの付いたデータにアクセスしようとした場合、ポリシーに基づいてブロックまたは監査
  • データ損失防止（DLP）ポリシーはエージェントの応答にも適用可能

ここで注目すべきは、Purviewがエージェントの「振る舞い」をログとして残す点だ。「何を入力し、何を出力したか」の監査証跡は、インシデント発生時の調査はもちろん、コンプライアンス対応においても不可欠になる。

脅威検出層：Defenderがプロンプトインジェクションを検知

Microsoft DefenderはAIエージェント特有の脅威に対応するための拡張が進んでいる。注目すべきはプロンプトインジェクション攻撃への対応だ。

悪意ある外部コンテンツ（メール本文、Webページ等）にエージェントを操作する命令を埋め込む攻撃は、従来のマルウェアとは異なるベクトルであり、既存のエンドポイント保護では検知できない。Defenderはこのような間接プロンプトインジェクションを検知するシグネチャを持ち始めている。

さらに：

  • エージェントの異常な動作パターン（通常より大量のデータアクセス等）をアラート
  • Microsoft Sentinel連携によるSIEM/SOARへの統合

コンプライアンス層：エージェントの「行動記録」を残す

4層目はコンプライアンスだ。規制対応の観点から、エージェントの判断根拠と実行ログをどこまで記録・保全できるかが問われる。Purviewの監査ログとDefenderのインシデントログを組み合わせることで、エージェントの行動を事後検証できる体制を構築できる。

実務への影響——日本のIT管理者が今すぐ動くべきこと

このアーキテクチャを踏まえ、実務で取るべき行動を整理する。

1. AIエージェントを「人間のアカウント」で動かすのを今すぐやめる Copilot StudioやAzure AI Foundryで作成したエージェントに、個人アカウントや共有サービスアカウントを使い回している構成は即刻見直しだ。マネージドIDを使ったEntra統合が正解。

2. 最小権限の原則を徹底する エージェントに付与する権限は「実際に必要な最小限」に絞る。SharePoint全サイトの読み取り権限を付与したエージェントが侵害されたときのリスクを想像してほしい。

3. Purviewの情報保護ラベルをAIワークロードにも適用する ラベルが整備されていないと、Purviewによるエージェント制御は機能しない。ラベル整備が先決。

4. プロンプトインジェクションを「新しい攻撃ベクトル」として認識する セキュリティ研修やインシデント対応プレイブックに、AIエージェント固有の攻撃シナリオを追加する時期に来ている。

筆者の見解

MicrosoftがAIエージェントセキュリティに対してEntra・Purview・Defenderの既存資産を統合して使う設計を選んだことは、技術的に理にかなっていると思う。ゼロから作るのではなく、実績のある製品群を組み合わせて対応する——これはMicrosoftらしい、そして正しいアプローチだ。

とりわけNon-Human Identity（NHI）の管理をEntraの枠組みで統一しようとしている点は評価したい。AIエージェントの普及で、NHIの数は今後人間のIDを大幅に上回るようになる。NHI管理の基盤ができていない組織は、自動化を進めようとするたびにボトルネックに直面することになる。

一方で、率直に言えば、これらの機能が「使える状態」になるまでの道のりはまだ長い。条件付きアクセスのエージェント対応、Defenderのプロンプトインジェクション検知精度、Purviewのエージェントログ保全——どれも完成形には程遠く、プレビュー段階の機能が多い。

それでも、統合プラットフォームとして全体最適を目指す方向性は変わっていない。M365・Azure・Defenderのエコシステム内でこれらが統合されれば、バラバラのポイントソリューションを寄せ集めるよりも確実に運用しやすくなる。これがMicrosoftの強みであり、AI時代においてもその強みは有効だ。

日本企業の多くはまだAIエージェントのセキュリティを「先の話」と捉えているかもしれない。だが、Copilot Studioで作ったエージェントが社内SharePointに接続された瞬間から、この話は「今の話」になる。アーキテクチャの理解は、導入の前に必要だ。

出典: この記事は How Microsoft Is Securing AI Agents Across Identity, Data, Threats, and Compliance の内容をもとに、筆者の見解を加えて独自に執筆したものです。