Microsoft Entra Agent ID とサービス プリンシパル: AI エージェントにはどちらを使うべきか？

By Mirko Peters · 2026-10-26

Microsoft Entra Agent ID とサービス プリンシパルを比較します。AI エージェントに専用の ID フレームワークとブループリントによるガバナンスが必要な理由を、Microsoft 365 の文脈で解説します。

Automatically translated with AI from the original post. Read the English original

Microsoft 365 で自律型の AI ワーカーをデプロイする際は、適切な ID モデルの選択が極めて重要です。従来のサービス プリンシパルは標準的なアプリケーション ワークロードの管理に長く使われてきましたが、短命で大量に生成される AI エージェントを扱うには力不足です。Microsoft Entra Agent ID は、資格情報の管理とエージェントのアクセス許可を分離する専用のアーキテクチャを導入し、セキュリティと監査性における大きな課題を解決します。

重要なポイント

• サービス プリンシパルは、資格情報とアクセス許可を個々のアプリケーションに直接紐付けます。そのため、短命で大量に生成される AI エージェントを追跡・保護するのが困難になります。
• Microsoft Entra Agent ID は、資格情報を中央のブループリントに保存し、個々のエージェントには一意のエージェント ID を割り当てることで、資格情報を切り離します。
• エージェント ID は、エージェント自体にローカルのシークレットを残さないため、コンポーネントが侵害された場合の影響範囲を大幅に抑えられます。
• ブループリントを使うと、管理者は一括でポリシーを適用し、ライフサイクルを管理できます。さらに、AI エージェントのファミリー全体を一括で停止できる、確実なキルスイッチとしても機能します。
• マネージド ID は Azure にホストされたコードに引き続き最適ですが、エージェント ID は実行時に自律的に判断を下す AI エージェント向けに専用設計されています。

AI ワーカーにおける ID のギャップを理解する

AI エージェントは、従来のエンタープライズ ID の枠組みにきれいに収まりません。パスワードや多要素認証コードでサインインする通常のユーザーとも、長期間安定して動く サービス アカウントに依存する従来のアプリケーションとも異なり、AI エージェントは動的に動作します。忙しい自動化ワークフローは、数千ものエージェント インスタンスを立ち上げ、1 営業日のうちにそのすべてを破棄することもあります。こうした一時的なエージェントが共有のサービス アカウントを使い回したり、人間の資格情報を借用したりすると、企業の監査ログはすぐに信頼できないフィクションになってしまいます。

さらに、午前 2 時にインシデントが発生したとき、IT 管理者は 2 つの基本的な問いに答える必要があります。どの特定のエージェントがこの操作を実行したのか、そして誰がその責任を負うのか。従来のアプリ登録や共有のサービス プリンシパルでは、無関係なワークロードを壊さずにこれらの問いに答えることはほぼ不可能です。この運用上の死角こそが、Microsoft が人間以外のワーカー向けに専用のフレームワークを開発した理由です。

サービス プリンシパルと エージェント ID: アーキテクチャの違い

Microsoft Entra Agent ID がなぜパラダイムシフトと言えるのかを理解するには、標準のサービス プリンシパルと構造的にどう違うのかを把握する必要があります。サービス プリンシパルは、テナント内のアプリケーション オブジェクトを 1 対 1 でインスタンス化したものです。長期間有効なシークレット、クライアント証明書、直接的なアクセス許可の割り当てを保持します。安定して予測可能な Web アプリやバックグラウンド デーモンにとっては、このモデルは長年うまく機能してきました。

しかし、AI エージェントに標準のサービス プリンシパルを使わせると、管理上の深刻な摩擦が生じます。

• 資格情報の乱立: 自動化ワークフローが新しいエージェント インスタンスを立ち上げるたびに、新しいサービス プリンシパルを作成することになり、環境中に クライアント シークレットが散在してしまいます。
• 粒度の問題: 問題のある 1 つのエージェントを無効にするには、何百ものサービス プリンシパルを精査する必要があり、重要な業務プロセスを誤って停止させるリスクがあります。
• 監査の曖昧さ: 共有のアプリケーション アカウントでは、どの特定のワークフロー インスタンスが機密性の高い企業データにアクセスしたのかが分かりにくくなります。

これに対してAgent IDモデルでは、管理用のブループリントを介した親子関係を導入します。ブループリントは認証資格情報を安全に保管し、許可されるスコープを定義します。個々のエージェントIDは一意の識別子を持ち、動的にインスタンス化されます。エージェントID自体にはパスワードやシークレットが保持されないため、攻撃者がランタイム環境から取り出せる資格情報は存在しません。

フリート管理におけるブループリントの強み

Microsoft Entra Agent IDの中核となる革新は、ブループリントオブジェクトにあります。ブループリントは、関連する複数のAIワーカーのフリートを管理するマスターテンプレートだと考えてください。たとえば組織が「営業アシスタントエージェント」のテンプレートをデプロイする場合、その1つの定義から北米、南米、ヨーロッパの地域別インスタンスを動的に起動できます。

これらのエージェントは共通のブループリントを共有するため、管理者は規模が拡大しても容易に扱える強力な管理機能を利用できます。

• 一元化されたポリシーの適用: ブループリントに条件付きアクセスポリシーやMicrosoft Graphのアクセス許可の制限を適用すると、そこから生成される将来のインスタンスを含むすべてのエージェントインスタンスに自動的に適用されます。
• 究極の緊急停止スイッチ: 特定のエージェントクラスに脆弱性が見つかった場合、親のブループリントを無効にすると、テナント全体で配下のすべてのエージェントIDの認証が即座に停止します。
• スポンサーによるガバナンス: すべてのエージェントIDには、名前が明記された人間のスポンサーが必要です。そのスポンサーが組織を離れた場合、Microsoft Entraは自動的にスポンサーの権限を上位のマネージャーに引き継ぎます。これにより、管理者の監視を失ったAIワークロードが放置されることを防ぎます。

アーキテクチャにおける各IDタイプの使い分け

最新のMicrosoft 365およびAzure環境では、人間以外のIDに対して多面的なアプローチが求められます。適切な仕組みを選択することで、セキュリティの抜け穴や管理上の負荷を防げます。

Azure上でホストされるコード向けのマネージドID

カスタムコード、関数、またはマイクロサービスがAzureインフラストラクチャ上で直接実行される場合は、必ずマネージドIDを既定の選択肢としてください。Azureがライフサイクルと資格情報のローテーションを自動的に処理するため、チームが管理すべきシークレットや、誤ってソースコードリポジトリに漏えいするシークレットは一切存在しなくなります。

従来型アプリケーション向けのサービスプリンシパル

安定稼働するエンタープライズアプリケーション、SaaS連携、そして永続的で専用のアプリケーションコンテキストと従来のクライアント資格情報フローを必要とする長時間稼働のデーモンサービスには、引き続き標準のサービスプリンシパルを利用してください。

自律型AIワーカー向けのAgent ID

Microsoft Entra Agent IDは、状況を動的に評価し、自律的に判断し、ユーザーやワークフローの代理としてMicrosoft 365のデータとやり取りするAIエージェント（Copilot Studioや独自のオーケストレーションフレームワークで構築されたものなど）をデプロイする場合に、特に利用してください。

クラウドの未来を守る

自律型の人工知能がデジタルトランスフォーメーションの中核となるにつれ、従来型のサービスアカウントでAIエージェントを管理することは、許容できないセキュリティ上の負債を生み出します。Microsoft Entra Agent IDを採用することで、IT管理者は最新のAIのスピードと規模を活かしつつ、厳格なガバナンス、明確な監査証跡、そして堅牢な最小権限のガードレールを維持できます。これらの仕組みの内部動作をさらに詳しく知りたい場合は、エピソード全編をお聴きいただき、Microsoftクラウドのセキュリティに関する継続的な議論にもぜひご参加ください。

よくある質問

Microsoft Entra Agent IDは、パスワードやシークレットをローカルに保存しますか？

いいえ。エージェントIDは、ローカルの資格情報、シークレット、証明書を持たないように設計されています。認証の仕組みは親のブループリントが安全に管理するため、攻撃者がエージェントのランタイム環境からキーを取り出すことはできません。

エージェントのブループリントはマルチテナント構成をどのように扱いますか？

ブループリントは、マルチテナントのテンプレートとして複数の組織にわたり公開できます。ただし、顧客がテナントにブループリントをデプロイすると、作成されるエージェントIDは厳密にシングルテナントかつローカルなものとなり、影響範囲を組織の境界内に完全に封じ込めます。

人間のスポンサーが会社を離れた場合、AIエージェントはどうなりますか？

管理者の監視を失ったAIワーカーが無期限に稼働し続けることを防ぐため、Microsoft Entraは、エージェントIDのスポンサー権限を離職するスポンサーの直属のマネージャーに自動的に移管します。

条件付きアクセスのポリシーをエージェントIDに直接適用できますか。

はい、適用できます。条件付きアクセスのエンジンは、エージェントIDに対してもユーザーと同様にサインインのシグナルを評価します。さらに、エージェントのブループリントを対象にポリシーを設定すると、そのテンプレートから作成される現在および将来のすべてのエージェントインスタンスに、そのルールが自動的に適用されます。