このエージェントは誰が作ったのか

ユーザー数3.000人のあるお客様のテナントで最初の棚卸しを行ったところ、280個のエージェントが見つかりました。そのうち170個には、社内に在籍している責任者がもういませんでした。作ったのは悪意のある誰かではなく、何かを素早く解決したかった現場の部門です。10年前に生まれ、いまだに誰も片付けていないサービスプリンシパルも、まさにこうして生まれました。エージェントは同じパターンを繰り返しています。ただ、より速く、より大きな数で。

ライセンスにできないこと

E7はE5、Copilot、Entra Suite、Agent 365をひとつにまとめたものです。パッケージの中身については、すでに十分に説明されています。しかし、ライセンスがテナントを片付けてくれるわけではありません。ライセンスが与えてくれるのは、エージェントを可視化し、識別し、制御するためのツールです。あるエージェントが存在すべきかどうか、誰がその責任を負うのか、何にアクセスしてよいのかを、ライセンスが決めることはありません。

さらにスピードの問題があります。エージェントは今、かつてExcelマクロが生まれていた場所、つまり現場の部門で、素早く、チケットなしに生まれています。それは意図されたことであり、私たちも良いことだと考えています。ただしそれは、ディレクトリ内の人間以外のアカウントが、他のどのグループよりも速く増えていくことを意味します。

レジストリが示すもの、示さないもの

Agent 365は、Microsoft 365、Copilot Studio、Power Platform、Foundryのエージェントを1か所に集約します。Defender for Endpointはさらに、クライアントにローカルインストールされたAIエージェントを、構成済みのMCPサーバーも含めて検出します。どちらもAdvanced Huntingに取り込まれ、KQLでまとめて分析できます。文字どおりのシャドーAIです。

次のクエリで、実際に呼び出されているエージェントと、その際に使われているツールを確認します。

CloudAppEvents
| where ActionType in ("InvokeAgent", "InferenceCall", "ExecuteToolBySDK", "ExecuteToolByGateway")
| extend RawEventData_parsed = parse_json(RawEventData)
| extend
    Workload          = coalesce(tostring(RawEventData_parsed["Workload"]), "Unknown"),
    TargetAgentName   = coalesce(tostring(RawEventData_parsed["TargetAgentName"]), "Unknown"),
    AgentName         = coalesce(tostring(RawEventData_parsed["AgentName"]), "Unknown"),
    AgentBlueprintId  = coalesce(tostring(RawEventData_parsed["AgentBlueprintId"]), "Unknown"),
    PlatformAgentType = coalesce(
        tostring(RawEventData_parsed["PlatformAgentType"]),
        tostring(RawEventData_parsed["CopilotEventData"]["PlatformAgentType"]),
        "Unknown"
    )
| project-away RawEventData_parsed
| summarize count() by ActionType, Workload, TargetAgentName, PlatformAgentType, AgentName, AgentBlueprintId

ただし制約があります。このクエリが示すのは全体像の一部、主にMicrosoft自身のエージェントと、Microsoftのプラットフォーム上で構築されたエージェントだけです。それ以外で動いているものは、ここには表示されません。

クライアント上のローカルエージェントについては、Defender for Endpoint Plan 2で十分です。

AgentsInfo
| where Platform == "LocalAgents"
| summarize arg_max(Timestamp, Name, Version, LifecycleStatus, RawAgentInfo) by AgentId
| where LifecycleStatus !in~ ("Deleted", "Uninstalled")
| extend AgentMetadata = RawAgentInfo.localAgentMetadata
| extend Vendor = tostring(AgentMetadata.vendor),
         Device = tostring(AgentMetadata.deviceName)
| summarize DeviceCount = dcount(Device) by Agent = Name, Vendor
| sort by DeviceCount desc

ユーザーの代理として動作するエージェントは、そのユーザーの権限を引き継ぎます。そのユーザーが過剰に共有されたSharePointライブラリにアクセスできるなら、エージェントもアクセスできます。しかも、どの人間よりも速く、徹底的にです。

独自のIDを持つ自律型エージェントは、独自の権限で動作します。会社のデータにアクセスする他のすべてのアカウントと同じく、責任者、整理された権限プロファイル、そして有効期限が必要です。

レジストリは、何が存在するかを示します。それが存在すべきかどうかは誰かが評価しなければならず、その評価に終わりはありません。

エージェントに必要なのはIDであり、例外ではありません

Entra Agent IDで構築されたエージェントには、独自の管理されたIDが割り当てられます。Agent Blueprintsを使えば、エージェントが存在する前の段階で、その構成と付与する権限を定義できます。さらにEntra ID Governanceにより、アクセスレビューとライフサイクル管理がエージェントにも適用されます。作成、承認、責任者の割り当て、定期的なレビュー、そして失効です。

Conditional Accessはエージェントのアイデンティティとブループリントに適用できますが、人間の場合とまったく同じようにはいきません。「すべてのユーザー」を対象とするポリシーはエージェントアカウントを捕捉せず、APIキーでアクセスするものはEntraを完全に迂回します。ポリシーに頼る前に、こうした抜け穴を把握しておく必要があります。

当たり前に聞こえます。しかし実際には、残念ながらそうではありません。従来のアプリ登録やサービスプリンシパルでさえ、それがいかに難しいかを、私たちはすでに多くのテナントで目にしています。放置されたシークレット、どこかのテスト段階で付与されたままの権限、とうに別の仕事に移った責任者。エージェントはより多くの数で、はるかに多くの人によって作られるため、状況が良くなることはありません。

今日サービスプリンシパルを管理できていない組織は、明日エージェントも管理できません。

ガバナンスは終わりのない仕事です

毎週、新しいエージェントが加わります。責任者は役割を変え、会社を去ります。権限は膨らみ、Conditional Accessのルールには例外が増え、秘密度ラベルは誰も手入れしません。どれもGo-liveのあるプロジェクトではなく、運用です。

私たちはまさにそのように取り組んでいます。Managed Entraでは、お客様のEntra IDを完全にコードとして運用しています。技術的な細部に聞こえるかもしれませんが、これこそが運用を確実に回せる本当の理由です。

多くの企業はITILに沿った整った変更プロセスを持っています。チケットに何を変更するかが書かれ、そのあとポータルでクリックされます。では、まさにその変更だけが行われ、それ以外は何も変わっていないことを誰が確認しているのでしょうか。

私たちが確認するのは説明ではなく、変更そのものです。ルールはコードとして存在します。何が変わるかは事前に明文化されています。もう1人がまさにその内容を承認し、承認されたものだけが、名前と日付とともにロールアウトされます。それでも何かがうまくいかなければ、最後に正常だった状態が、徹夜作業ではなく数分で復元されます。

例外も同じ経路を通ります。お客様が標準からの逸脱を必要とする場合、それはExcelのリストや管理者の頭の中ではなく、リポジトリに記録されます。可視化され、バージョン管理され、他の変更と同じようにレビューされます。これによりベースラインが数か月かけて少しずつ形骸化することはなく、次の監査では、テナントがどう構成されているか、誰がいつ何を変更したかの証跡がすでに揃っています。

そして私たちは、エージェントに求めることを自分たちにも課しています。私たち自身の自動化も、人間以外のIDだからです。それはフェデレーションIDを使ってお客様のテナントにサインインし、保存されたシークレットは一切使いません。権限は分離されています。あるIDは読み取りと計画だけが許され、別のIDが書き込みを許されます。漏洩しうるパスワードも、いつの間にか期限切れになる証明書もありません。

エージェントそのものについては、まさに取り組みの最中です。Conditional Access、アクセスレビュー、Entitlement Managementは、すでにコードとして運用しています。いま構築しているのは、ID、権限、Conditional Access、責任者、有効期限を備えたリポジトリ内のエージェントテンプレートと、コミュニティのMaesterチェックなどを使った、孤立したエージェントIDの自動チェックです。エージェントが数百個になれば、これが全体を把握できるか、祈るしかないかの分かれ目になります。

エージェントが読み取り、受け渡すデータをPurviewがどのように保護し、私たちのCSOCがその活動をどのように監視するかについては、AIガバナンスに関する別の記事で説明します。

では、Azureのエージェントは？

Agent 365は、Microsoft Foundryで動作するエージェントも把握します。しかし、その下にあるプラットフォーム、つまりモデル、ネットワーク、データ連携、評価は、誰かが構築して運用しなければなりません。そのために私たちはAI Foundationを完全にコードとして構築しました。新しいAIプロジェクトはどれも、前のプロジェクトと同じガードレールのもとで始まります。詳しくは、3つのFoundationに関する記事The Holy Trinityをご覧ください。

最も重要なのは、下のレイヤーとのつながりです。AI Foundationから生まれるすべてのエージェントは、ほかの環境と同じEntraの中に独自のIDを持ち、必要な権限だけを与えられます。ユーザーの代理として動作する場合、そのユーザーが見てよいものしか見えません。そして、検証可能な痕跡を残します。エージェントがMicrosoft 365ではなくAzureで動いているからといって、独自のアカウントや独自の例外を持つ特別扱いはありません。

明日の朝に確かめたい3つの質問

自分たちの現状を知りたいなら、次の3つの質問から始められます。

1. アクティブなオーナーやスポンサーがいなくなったエージェントはどれか。
2. 12か月より古いシークレットを持つサービスプリンシパルはどれか。
3. EntraではなくAPIキーでアクセスしているエージェントはどれか。

3つすべてにすぐ答えられるなら、ほとんどの組織より先を行っています。

私たちはどこから始めるか

現状からです。エージェントはすでにそこにいるのですから。2日間のAgent 365ワークショップでは、皆さんのテナントでどのエージェントが動いていて、それがどこから来たのかを可視化します。終了時には、インベントリ、リスクの全体像、そして責任の所在を明確にしたガバナンス計画が手元に揃います。

まとめ

E7は現実の問題に取り組んでいます。しかし、何が動いているかが見えることは、それを掌握していることと同じではありません。そのためには、誰かが毎日目を配り、IDを管理し、権限を削り、エージェントが昨日と突然違う振る舞いを始めたときに気づく必要があります。

ライセンスは始まりにすぎません。決め手は運用です。

すでにE7を導入している、あるいはエージェントが増え続けていると感じていませんか。そして、それを誰が把握しているのか気になっていませんか。ご連絡ください。皆さんの環境で何が動いていて、そのうち何を残してよいのかを一緒に確認します。導入にあたってはMicrosoftの支援プログラムを利用できます。皆さんに合うかどうかは、一緒に確認しましょう。