AIエージェントに「上司」はいるか
- 山崎行政書士事務所
- 7月14日
- 読了時間: 25分
Microsoft Entra Agent IDで決める所有者・スポンサー・停止権限
※本記事は2026年7月14日時点のMicrosoft公式情報を基に作成しています。
「そのAIエージェントの上司は誰ですか」
こう聞かれて、すぐに氏名を答えられる企業は、まだ多くないのではないでしょうか。
生成AIの利用が、単なる文章作成や検索補助にとどまっている間は、問題が起きても、人が出力を確認して修正できました。
しかし、AIエージェントが次のような操作を始めると、管理の論点は大きく変わります。
販売管理システムに注文を登録する
顧客管理システムの情報を更新する
経費精算や支払処理を進める
契約管理システムの情報を書き換える
他のAIエージェントや外部APIを呼び出す
経営層や担当者の代理として業務を実行する
そこで、情シス担当者と経営層に考えていただきたい問いがあります。
AIエージェントが誤った発注、顧客情報の更新、契約情報の変更を行ったとき、誰が止め、誰が説明するのでしょうか。
Microsoft Entra Agent IDが示す重要な考え方は、AIエージェントの「上司」を一人に決めることではありません。
事業上の説明責任、技術管理、緊急停止、再開承認を分離し、それぞれの責任者をあらかじめ記録することです。
結論：AIエージェントの「上司」は一人ではない
AIエージェントを安全に運用するためには、少なくとも次の四つの役割が必要です。
┌──────────────────────────┐
│ ① なぜ使うのかを説明する人 │
│ スポンサー │
│ ・利用目的 │
│ ・業務上の必要性 │
│ ・継続、延長、停止の判断 │
└──────────────────────────┘
↓
┌──────────────────────────┐
│ ② どのように動かすかを管理する人 │
│ 所有者 │
│ ・認証設定 │
│ ・構成、資格情報 │
│ ・技術的な停止、復旧 │
└──────────────────────────┘
↓
┌──────────────────────────┐
│ ③ 緊急時に遮断する人 │
│ SOC、Entra管理者、セキュリティ管理者 │
│ ・個別IDの無効化 │
│ ・条件付きアクセスによる広域遮断 │
└──────────────────────────┘
↓
┌──────────────────────────┐
│ ④ 再開を承認する人 │
│ スポンサー、業務責任者、経営層 │
│ ・影響確認 │
│ ・是正確認 │
│ ・残存リスクの受容 │
└──────────────────────────┘Microsoft Entra Agent IDでは、技術的な管理を行う「所有者」と、事業上の説明責任を担う「スポンサー」が明確に区別されています。
スポンサーはAgent IDおよびAgent IDブループリントに必要とされる一方、所有者とマネージャーは任意です。また、これらの管理関係はMicrosoft EntraのRBAC、つまりAgent ID AdministratorやConditional Access Administratorなどの管理者ロールとは別に扱われます。
ここで重要なのは、Microsoft Entra上の「スポンサー」という登録だけで、法令上・契約上の責任主体が自動的に決まるわけではないという点です。
Microsoft Entraの管理関係と、社内規程、職務権限、稟議規程、委託契約、インシデント対応規程を整合させて、初めて組織として説明可能な統制になります。
1．Microsoft Entra Agent IDとは何か
Microsoft Entra Agent IDは、AIエージェントに専用のIDを与え、認証、承認、管理、保護、ガバナンスを行うためのID・セキュリティ基盤です。
エージェントごとに識別可能なIDを持たせ、誰の指示で、何にアクセスし、どの権限で、どのような処理を行ったのかを管理しやすくします。
2026年時点では、Microsoft Entra Agent ID製品自体は一般提供されています。一方で、管理センターからAgent IDやブループリントを作成する新しいウィザードなど、一部の操作画面や関連機能にはプレビュー表記が残っています。
図1 ブループリントとAgent IDの関係
【Agent IDブループリント】
受注処理エージェントの共通設計
├─認証方式
├─共通ポリシー
├─管理関係
└─基本となるアクセス設計
│
├──────────────┐
↓ ↓
【Agent ID：本番】 【Agent ID：検証】
受注エージェント-prod 受注エージェント-test
・本番ERPへ接続 ・検証ERPへ接続
・書込み権限あり ・テストデータのみ
・重要資産候補 ・本番書込み禁止この構造が有効なのは、AIエージェントを「アプリケーション名」だけで管理するのではなく、設計系列、環境、用途、責任者、権限、ライフサイクルを関連付けて管理できるからです。
ただし、ブループリントを作っただけで統制が完成するわけではありません。
実際の業務で必要になるのは、次の問いに答えられる状態です。
確認項目 | 組織として答えるべき内容 |
なぜ存在するのか | 業務目的、期待効果、承認された利用範囲 |
誰のために動くのか | 利用部門、業務責任者、スポンサー |
誰が技術管理するのか | 所有者、保守担当者、委託先 |
何ができるのか | 読取り、作成、変更、削除、実行、外部送信 |
何をしてはいけないのか | 禁止処理、禁止データ、禁止接続先 |
誰が止められるのか | 緊急停止実行者、停止承認者 |
誰が再開を決めるのか | 再開承認者、必要な確認事項 |
何を証拠として残すのか | サインインログ、監査ログ、業務処理ログ |
2．「所有者」と「スポンサー」は何が違うのか
Microsoft Entra Agent IDの管理モデルを理解するうえで、最も重要なのが所有者とスポンサーの分離です。
表1 Agent IDの管理関係
管理関係 | 主な役割 | 技術設定 | 停止・削除 | 必須性 |
所有者 | セットアップ、認証設定、構成、資格情報などの技術管理 | 可能 | 無効化、削除、再有効化、復元、ハード削除などが可能 | 任意 |
スポンサー | 利用目的、継続、アクセス延長、停止などの事業上の判断 | アプリケーション設定の変更は不可 | 有効化・無効化、スポンサー変更、論理削除などの限定操作 | 必須 |
マネージャー | 組織階層上の管理、アクセスパッケージの要求 | 不可 | 変更・削除権限なし | 任意 |
Microsoftの説明では、所有者は技術管理者として認証プロパティや資格情報、構成を管理できます。不要になったAgent IDの無効化や削除に加え、無効化されたIDの再有効化、論理削除されたIDの復元、ハード削除も行えます。
一方、スポンサーはAIエージェントの業務目的を理解し、そのエージェントが引き続き必要か、アクセス権を維持すべきかを判断します。セキュリティインシデント時には、その挙動が期待されたものかを判断し、中断や権限調整を承認することも想定されています。技術設定を自由に変更する権限はありませんが、有効化・無効化や論理削除など、限定的なライフサイクル操作は可能です。
「Manager」という名前に注意する
Microsoft Entra Agent IDには「マネージャー」という管理関係もあります。
しかし、マネージャーは名前から想像されるような「何でも決められる直属上司」ではありません。
マネージャーはアクセスパッケージを要求できますが、Agent IDを変更したり削除したりする権限は持ちません。変更や削除には、所有者、スポンサーまたは管理者が必要です。
つまり、AIエージェントの管理においては、
マネージャーという名称よりも、実際に付与されている決定権と技術権限を確認する必要があります。
図2 責任と権限を分けて考える
【事業上の判断】
スポンサー
なぜ必要なのか
継続すべきか
停止すべきか
│
│ 承認・判断
↓
【検知・封じ込め】 → 【技術的実行】 → 【対象システム】
SOC・セキュリティ 所有者・管理者 ERP
監視担当 Entra管理者 CRM
運用担当 契約管理
│
│ 状況・証跡
↓
【再開判断】
スポンサー・業務責任者・経営層この分離が必要なのは、技術担当者だけでは、次の判断ができないことがあるためです。
その注文は業務上正当だったのか
顧客情報の更新は想定された処理だったのか
契約情報の変更は承認済みだったのか
業務停止による影響と、稼働継続によるリスクのどちらが大きいか
反対に、事業部門のスポンサーだけでは、次の技術判断が難しい場合があります。
どのAgent IDを無効化すべきか
同じブループリントから作られた他のAgent IDに影響があるか
条件付きアクセスでどの範囲を遮断するか
発行済みトークン、外部API、対象システム側のセッションをどう扱うか
どのログを保全すべきか
したがって、スポンサーと所有者は上下関係ではなく、異なる責任を持つ対等な統制関係として設計する必要があります。
3．AIエージェントの「停止権限」は一つではない
「AIエージェントを止める」と言っても、その方法は一つではありません。
Microsoft Entra Agent IDでは、特定のAgent IDを無効化する方法と、条件付きアクセスによって広い範囲の認証やトークン発行を止める方法があります。
表2 主な停止手段
停止手段 | 対象範囲 | 主な効果 | 主な利用場面 |
個別Agent IDの無効化 | 特定のAgent ID | トークン取得・認証を停止し、IDとメタデータは残す | 特定エージェントの誤動作、侵害疑い |
ブループリントの無効化 | 特定の設計系列 | ブループリント単位で対象を制御 | 同じ設計に共通する問題がある場合 |
CAポリシー1 | Agent ID全体 | Agent IDの認証、トークン発行を広域ブロック | テナント全体の緊急封じ込め |
CAポリシー2 | エージェントのユーザーアカウント | ユーザー代理型エージェントの認証をブロック | 委任動作の停止 |
CAポリシー3 | 人からエージェントへのサインイン | 人がエージェントを起動する経路をブロック | 人による起動のみ止めたい場合 |
論理削除 | 対象ID | 復元可能な状態で廃止 | 利用終了、保留中の廃止 |
ハード削除 | 対象ID | 恒久的な削除 | 証跡・依存関係確認後の最終廃止 |
Microsoft Entra管理センターで個別のAgent IDを無効化すると、そのIDがトークンを受け取り、認証されることを止めながら、IDとメタデータをテナント内に保持できます。
条件付きアクセスでは、個々のオブジェクトを変更せずに、幅広いカテゴリのAgent IDに対するトークン発行をテナント全体でブロックできます。ただし、条件付きアクセスによるブロックはAgent IDの「作成」までは禁止しません。また、適用にはMicrosoft Entra ID P1が必要であり、Microsoftは本番適用前にレポート専用モードで影響を確認することを推奨しています。
停止ボタンより重要なこと
緊急停止機能を準備していても、次の事項が決まっていなければ実際には使えません。
決めるべき事項 | 具体的な問い |
停止判断者 | 誰が「止めるべき状態」と判断するか |
停止実行者 | 誰がEntra管理センターや対象システムを操作するか |
夜間・休日対応 | スポンサーが不在でも一時停止できるか |
証跡保全 | 無効化や削除の前に何を保存するか |
業務側の対応 | 注文、顧客情報、契約データをどう凍結するか |
再開承認 | 誰が、何を確認して再開を承認するか |
再発防止 | 権限、プロンプト、ツール、承認条件をどう修正するか |
図3 推奨するインシデント対応フロー
① 異常検知
・不審なサインイン
・想定外の書込み
・大量処理
・権限外アクセス
↓
② 一時的な緊急停止
・個別Agent ID無効化
・書込み権限の遮断
・必要に応じてCA適用
↓
③ 証跡保全
・Entraサインインログ
・Entra監査ログ
・AIエージェント実行ログ
・対象業務システムの取引ログ
↓
④ 業務影響の確認
・スポンサー
・業務責任者
・経営層
↓
⑤ 技術調査
・所有者
・SOC
・開発、運用担当
↓
⑥ 是正
・権限縮小
・資格情報更新
・処理条件修正
・承認ステップ追加
↓
⑦ 再開承認
・スポンサーが業務面を確認
・所有者が技術面を確認
・必要に応じて経営承認
↓
⑧ 段階的な再開・監視強化ここで重要なのは、緊急停止の実行を、スポンサーの連絡が取れるまで待つ設計にしないことです。
重大な誤更新や情報流出が進行している場合、事前に定めた条件に基づき、SOCやEntra管理者が一時停止できるようにしておく必要があります。
そのうえで、スポンサーが業務影響と継続可否を判断し、所有者が技術的な復旧を実施する「二段階統制」が現実的です。
4．2026年6月、AIエージェントは「重要資産」になった
Microsoft Security Exposure Managementの2026年6月リリースでは、AIエージェントに関する二つの定義済み分類ルールが、重要資産リストに追加されました。
表3 追加されたAIエージェント分類
分類 | 対象となるAIエージェント | 想定される影響 |
経営層主導のAIエージェント | 上級役員が作成または所有し、役員の代理として行動したり、機密データへアクセスしたりするエージェント | 役員本人のIDが直接侵害されなくても、役員権限による未承認操作や機密情報の露出につながる |
特権ビジネスシステム書込みアクセス権を持つAIエージェント | 基幹業務システムで、作成・変更・削除などの高リスクな書込み処理を実行できるエージェント | 販売注文、顧客データ、金融取引、法的契約などの改変により、重大な事業影響が生じる |
Microsoftが例示している書込み対象には、販売注文、顧客データ、金融取引、法的契約が含まれています。
これは単なる製品機能の追加ではありません。
私は、この変更を次のように捉えています。
AIエージェント管理が「IT資産管理」から「重要業務と経営リスクの管理」へ移り始めた。
もちろん、Microsoft Security Exposure Management上で重要資産に分類されたからといって、それだけで法的責任が確定するわけではありません。
しかし、少なくとも組織としては、次の対応が求められます。
従来
AIエージェント一覧
↓
「どの部署が使っていますか」
現在
AIエージェント一覧
↓
権限・データ・業務影響を評価
↓
重要資産として分類
↓
攻撃経路・露出リスクを優先確認
↓
経営層へ説明Microsoft Security Exposure Managementの表示内容や効果は、導入しているライセンス、接続済みのMicrosoft Security製品、取得できている資産・関係性データ、権限設定などに左右されます。したがって、管理画面に表示されないことをもって「重要なAIエージェントが存在しない」と判断してはいけません。
5．誤発注、顧客更新、契約変更が起きたらどうするか
表4 代表的な三つの事故シナリオ
シナリオ | 最初に行うこと | スポンサーが判断すること | 所有者・技術担当が確認すること |
AIが誤った注文を登録 | Agent IDの停止、対象注文の保留 | 注文が業務上有効か、取消・再処理が必要か | 実行経路、入力値、API呼出し、権限 |
顧客情報を誤更新 | 書込み停止、更新対象の凍結 | 顧客対応、業務影響、社内報告の要否 | 更新件数、変更前後、取得元データ |
契約情報を変更 | Agent ID停止、対象文書・レコードを保全 | 変更が承認済みか、正式情報として扱えるか | 変更者ID、時刻、変更内容、承認処理 |
事故対応で起こりやすい失敗
失敗1 スポンサーはいるが、連絡先が分からない
Entra ID上にスポンサー名が登録されていても、休日・夜間の連絡先や代理者が決まっていなければ、緊急時には機能しません。
失敗2 所有者が退職している
所有者が個人一人だけで、異動・休職・退職により連絡不能になると、技術管理が停滞します。
Microsoftは、スポンサーが異動または退職する際に、共同スポンサーへの通知やマネージャーへのスポンサーシップ移管を行うライフサイクルワークフローも案内しています。
失敗3 停止はできるが、再開条件がない
安全のために止めた後、誰も再開を承認できず、業務停止が長期化するケースです。
失敗4 Entraだけを止めて安心する
Entra側でAgent IDを無効化しても、すでに基幹システムへ登録された注文や更新結果が自動的に元へ戻るわけではありません。
対象業務システム側で、次の確認が必要です。
処理済みデータ
保留中のジョブ
キュー
外部APIの処理状態
対象システム側のセッション
キャッシュや一時保存
下流システムへの連携結果
6．停止基準は事前に決める
「問題が起きたら適切に判断する」という規程では、実際のインシデントでは動けません。
停止基準は、具体的な事象と対応を結び付けておく必要があります。
表5 AIエージェント停止基準の例
重要度 | 事象例 | 初動 | 事業側判断 |
S1：重大 | 未承認の外部送信、機密情報流出、金銭・契約・顧客データの不正変更、権限昇格 | 直ちにAgent ID無効化。必要に応じて広域遮断。証跡保全 | スポンサー・経営層へ即時報告。再開には明示承認 |
S2：高 | 想定外の大量処理、異常なアクセス先、可逆的な誤更新 | 書込みを停止し、読取り専用化または処理保留 | 当日中に継続・停止を判断 |
S3：中 | 回答品質低下、処理遅延、軽微な誤分類 | 監視強化。人の承認を必須化 | 通常の変更管理で是正 |
S4：低 | 表記揺れ、非重要な出力不備 | ログ記録、次回改善 | 定例レビュー |
この基準はあくまでひな型です。
実際には、次の要素に応じて調整します。
評価軸 | 確認内容 |
データ | 個人情報、営業秘密、契約情報、認証情報を扱うか |
権限 | 読取りだけか、作成・変更・削除が可能か |
金額 | 金銭的影響に上限があるか |
可逆性 | 元に戻せる処理か |
外部影響 | 顧客、取引先、行政機関へ影響するか |
自律性 | 人の承認なしで処理を完了できるか |
速度 | 短時間に大量処理できるか |
連鎖性 | 他のエージェントやシステムを起動するか |
7．最低限整備したい「七つの文書」
AIエージェントの統制では、管理画面の設定だけでも、規程の作成だけでも不十分です。
必要なのは、設定と文書を対応付けた管理です。
AIエージェント台帳
│
├─所有者・スポンサー表
├─利用目的整理表
├─権限マトリクス
├─停止基準
├─インシデント連絡・承認フロー
└─監査ログ確認手順7-1．AIエージェント台帳
表6 台帳に記録する項目
分類 | 必須項目 |
識別情報 | 管理番号、Agent ID名、Object ID、App ID、Blueprint ID |
利用情報 | 業務目的、利用部門、利用者、利用環境 |
システム | 接続先、利用API、MCPサーバー、外部サービス |
データ | 参照データ、更新データ、機密区分、個人情報の有無 |
権限 | 読取り、作成、変更、削除、実行、外部送信 |
責任者 | スポンサー、共同スポンサー、所有者、代替所有者 |
停止 | 停止実行者、停止承認者、緊急連絡先 |
再開 | 再開承認者、再開条件 |
ログ | サインインログ、監査ログ、業務ログの保存先 |
ライフサイクル | 作成日、稼働開始日、次回レビュー日、終了予定日 |
提供状態 | 正式提供、プレビュー、ベータAPI利用の有無 |
台帳記載例
項目 | 記載例 |
Agent ID名 | sales-order-agent-prod |
利用目的 | 承認済み見積書から販売注文案を作成する |
禁止事項 | 10万円を超える注文の自動確定、顧客マスター削除 |
スポンサー | 営業本部長 |
所有者 | 情報システム部・クラウド基盤担当 |
接続先 | CRM、販売管理、承認ワークフロー |
書込み権限 | 注文案の作成のみ |
緊急停止者 | SOC当番、Entra管理者 |
再開承認者 | 営業本部長＋情報システム部長 |
ログ保存先 | Entraログ、SIEM、販売管理監査ログ |
次回レビュー | 2026年9月30日 |
7-2．所有者・スポンサー表
表7 役割分担例
判断・作業 | スポンサー | 所有者 | SOC・Entra管理者 | 経営層 |
利用目的の承認 | A／R | C | I | I |
技術構成の決定 | C | A／R | C | I |
権限追加の業務承認 | A／R | C | C | I |
権限設定の実施 | I | A／R | R | I |
緊急一時停止 | IまたはA | C | A／R | I |
業務影響の評価 | A／R | C | C | I |
技術調査 | C | A／R | R | I |
再開承認 | A／R | C | C | 必要に応じA |
最終廃止 | A／R | R | C | I |
凡例
R：実行責任
A：最終説明・承認責任
C：協議
I：報告
これは一例です。
重要なのは、RACIを作った後に、Microsoft Entraの所有者・スポンサー・管理者ロールと一致しているかを確認することです。
7-3．利用目的整理表
表8 利用目的を明確にする質問
項目 | 記載する内容 |
解決する業務課題 | 何を効率化・自動化するのか |
利用者 | 誰が利用・起動するのか |
起動条件 | 人の指示、スケジュール、イベント、他エージェント |
許可する処理 | 読取り、案の作成、確定処理など |
禁止する処理 | 削除、外部送信、承認なしの確定 |
人の承認条件 | 金額、件数、データ区分、対象顧客 |
利用データ | 入力元、参照先、出力先 |
成功条件 | 何をもって正常処理とするか |
失敗条件 | どの状態を異常とみなすか |
終了条件 | いつ廃止・再審査するか |
利用目的は、「営業支援のため」のような抽象的な記載では不十分です。
例えば、次のように動詞まで明確にします。
承認済みの見積情報を読み取り、販売注文の下書きを作成する。注文確定は人が行い、顧客マスターの変更および削除は行わない。
7-4．権限マトリクス
表9 権限マトリクス例
対象システム | 読取り | 作成 | 変更 | 削除 | 実行 | 外部送信 | 人の承認 |
CRM | ○ | − | △ | × | − | × | 顧客更新時 |
販売管理 | ○ | ○ | △ | × | △ | × | 注文確定時 |
契約管理 | ○ | 下書きのみ | × | × | − | × | 正式文書化時 |
メール | ○ | ○ | − | × | 送信可 | ○ | 外部送信時 |
ファイル保管 | ○ | ○ | △ | × | − | △ | 機密情報を含む場合 |
記号例
○：許可
△：条件付き許可
×：禁止
−：該当なし
「書込み権限あり」という一行ではなく、作成、変更、削除、実行、送信を分けることが重要です。
注文の下書きを作る権限と、注文を確定する権限では、事業リスクがまったく異なります。
7-5．停止・再開基準
停止基準と再開基準は対になっている必要があります。
表10 再開判定表の例
確認項目 | 確認結果 | 確認者 |
原因が特定されている | 済／未 | 所有者 |
不要な権限を削除した | 済／未 | Entra管理者 |
資格情報を更新した | 済／未 | 所有者 |
誤処理データを特定した | 済／未 | 業務担当 |
対象データを修復した | 済／未 | 業務責任者 |
再発防止策を反映した | 済／未 | 所有者 |
テスト環境で再現確認した | 済／未 | 開発・運用担当 |
ログ監視を強化した | 済／未 | SOC |
残存リスクを説明した | 済／未 | スポンサー |
再開を承認した | 承認／否認 | 再開承認者 |
7-6．インシデント連絡・承認フロー
表11 連絡先台帳
役割 | 主担当 | 代替担当 | 夜間・休日連絡 | 主な判断 |
スポンサー | 営業本部長 | 営業副本部長 | 緊急連絡網 | 業務継続・停止 |
所有者 | クラウド基盤担当 | アプリ基盤担当 | 運用当番 | 技術調査・復旧 |
緊急停止者 | SOC当番 | Entra管理者 | 24時間窓口 | 一時遮断 |
対象システム担当 | ERP担当 | 保守委託先 | 保守窓口 | 取引・データ保全 |
経営報告先 | 情報システム部長 | 管掌役員 | 秘書室経由 | 重大影響判断 |
法務・個人情報担当 | 法務責任者 | 個人情報管理者 | 社内連絡網 | 対外対応要否 |
7-7．監査ログ確認手順
Microsoft Entra管理センターでは、Agent IDに関するサインインをフィルターして確認できます。
一方、Microsoft GraphからAgent IDのサインインイベントを取得する例では、2026年7月時点で/betaエンドポイントが使用されています。監査ログでは、agentTypeやblueprintIdなどを利用して、AIエージェントが関与したイベントを追跡できます。
表12 ログ確認チェックリスト
ログ | 主な確認内容 | 関連付けに使う情報 |
Entraサインインログ | 認証時刻、結果、アクセス先、IP、リスク | Agent ID、Object ID、App ID |
Entra監査ログ | ID作成、変更、無効化、所有者・スポンサー変更 | agentType、blueprintId |
エージェント実行ログ | プロンプト、ツール呼出し、応答、処理結果 | 実行ID、相関ID |
API・MCPログ | 呼出し先、パラメーター、応答コード | 相関ID、トランザクションID |
業務システム監査ログ | 作成・変更・削除されたレコード | 注文番号、顧客番号、契約番号 |
承認ワークフローログ | 承認者、承認時刻、差戻し | 申請番号、承認ID |
SIEM・SOCログ | 異常検知、アラート、遮断操作 | インシデント番号 |
変更管理記録 | 設定変更、権限追加、リリース | 変更要求番号 |
ログを保存するだけでは不十分です。
次の関連付けができる必要があります。
誰が起動したか
↓
どのAgent IDが動いたか
↓
どのツール・APIを呼び出したか
↓
どの業務データを変更したか
↓
誰が承認したか
↓
結果はどうなったか8．正式提供とプレビューを混同しない
Microsoft Entra Agent IDについては、「正式提供か、プレビューか」を一言で表すことはできません。
製品、管理画面、個別機能、Microsoft Graph APIごとに提供状態を確認する必要があります。
表13 2026年7月時点の整理
対象 | 状態・注意点 |
Microsoft Entra Agent ID製品 | 一般提供 |
所有者・スポンサー・マネージャーの管理モデル | Microsoft公式文書で提供。スポンサーは原則必須 |
管理センターのAgent ID作成ウィザード | プレビュー表記 |
管理センターのブループリント作成ウィザード | プレビュー表記 |
GraphによるagentIdentityBlueprint作成 | v1.0エンドポイントあり |
GraphによるagentIdentity作成 | v1.0エンドポイントあり |
GraphによるAgent IDサインインログ取得例 | /betaを使用 |
Agent Identity Protection | プレビュー。プレビュー期間中はEntra ID P2が必要 |
Agent向け条件付きアクセス | Entra ID P1が必要。事前にレポート専用での評価を推奨 |
Security Exposure ManagementのAI分類 | 2026年6月に定義済み分類として追加 |
Microsoft Graphでは、v1.0に一般提供され、運用環境で利用できる機能が含まれます。一方、betaエンドポイントは重大な変更が生じる可能性があり、運用アプリケーションでの利用はサポートされていません。
Agent IDブループリントとAgent IDの作成APIにはv1.0エンドポイントがあり、作成要求にはスポンサーの指定が必要です。
したがって、次の理解は誤りです。
「Microsoft Entra Agent IDが一般提供されたので、関連する画面・API・保護機能はすべて正式提供である」
正しくは、次のように評価します。
製品全体の提供状態
＋
利用する管理画面の提供状態
＋
利用するAPIのバージョン
＋
利用する保護機能の提供状態
＋
必要なライセンス
＋
変更時の代替手順プレビュー機能を本番業務で利用する場合は、少なくとも次の事項を台帳に記録すべきです。
管理項目 | 記録内容 |
プレビュー機能名 | 具体的な画面・機能・API |
利用目的 | なぜプレビューを使う必要があるか |
影響範囲 | 対象Agent ID、業務、データ |
変更リスク | UI、API、仕様変更時の影響 |
代替手順 | 利用不能時の手動運用 |
承認者 | 技術・業務双方の承認 |
確認日 | 公式文書を再確認する日 |
終了条件 | 正式提供移行または利用停止条件 |
9．NIST、ISO/IEC 42001、ISMSとの関係
Agent IDの所有者・スポンサー・停止設計は、Microsoft固有の設定項目だけではありません。
AIガバナンスや情報セキュリティ管理の考え方とも整合します。
NIST AI RMFは、AIリスク管理を「Govern、Map、Measure、Manage」の四機能で整理しています。ISO/IEC 42001は、組織がAIマネジメントシステムを確立し、実施、維持、継続的に改善するための国際規格です。
表14 管理文書とフレームワークの対応
実務文書・統制 | NIST AI RMF | ISO/IEC 42001・ISMSの観点 |
スポンサー・所有者表 | Govern | 役割、責任、権限 |
利用目的整理表 | Map | 組織の状況、利用目的、影響 |
AIエージェント台帳 | Govern／Map | 資産・AIシステムの把握 |
権限マトリクス | Govern／Manage | アクセス制御、最小権限 |
テスト・ログ確認 | Measure | 監視、測定、評価 |
停止基準 | Manage | リスク対応、是正処置 |
インシデントフロー | Manage | インシデント管理、継続性 |
定期レビュー | Govern／Measure | パフォーマンス評価、継続的改善 |
個人データを取り扱う場合は、GDPR第25条のデータ保護・バイ・デザインおよびデフォルトの考え方も意識する必要があります。
後から制限を追加するのではなく、設計段階で、利用目的、データ最小化、アクセス範囲、保存期間、人の関与、削除方法を組み込むという考え方です。
なお、各法令・規格への適合性は、適用関係、業種、契約、データ、利用地域などを踏まえた個別評価が必要です。
10．30日で始めるAIエージェント統制
最初から完璧なAIガバナンス体系を作ろうとすると、計画だけで止まってしまいます。
まずは30日で、最低限の説明可能性と停止可能性を作ります。
表15 30日ロードマップ
期間 | 実施内容 | 成果物 |
第1週 | Agent ID、アプリ、サービスプリンシパル、エージェント、MCP、接続先を棚卸し | AIエージェント暫定台帳 |
第2週 | 利用目的、データ、読取り・書込み・削除権限を分類 | 利用目的整理表、権限マトリクス |
第3週 | スポンサー、所有者、代理者、緊急停止者、再開承認者を決定 | 所有者・スポンサー表、RACI |
第4週 | 停止テスト、ログ確認、机上訓練、経営報告 | 停止手順、ログ確認手順、訓練記録 |
最初に優先すべきAIエージェント
次に該当するものから着手します。
優先度 | 条件 |
最優先 | 金銭、注文、契約、顧客データを書き換える |
最優先 | 経営層や役員の代理として動く |
高 | 個人情報や機密情報を外部へ送信できる |
高 | 人の承認なしで処理を完了できる |
高 | 他のAIエージェントや外部ツールを起動できる |
中 | 社内データの読取りのみ |
低 | 公開情報のみを使い、出力を人が確認する |
11．経営層・情シス向け10項目チェック
表16 AIエージェント統制セルフチェック
質問 | はい／いいえ |
本番稼働するすべてのAIエージェントを把握している | |
各AIエージェントにスポンサーが登録されている | |
所有者と代替所有者が決まっている | |
読取り・作成・変更・削除権限を分けて把握している | |
人の承認なしで実行できる範囲を把握している | |
緊急時に誰が無効化するか決まっている | |
夜間・休日でも一時停止できる | |
再開承認者と再開条件が決まっている | |
Agent IDから業務処理までログを追跡できる | |
プレビュー機能とbeta APIの利用箇所を把握している |
判定の目安
「はい」の数 | 状態 |
0～3 | 重大な管理空白があります。書込み権限を持つエージェントから早急に確認が必要です |
4～7 | 基礎はありますが、停止・再開・証跡の統合が必要です |
8～9 | 運用可能な水準です。定期レビューと訓練を強化します |
10 | 基礎統制が整っています。実設定と文書の継続的な一致確認が必要です |
12．山崎行政書士事務所が支援できること
AIエージェント管理では、次の二つを分断しないことが重要です。
Microsoft Entraの実際の設定
×
社内規程・台帳・手順・責任分界規程には「最小権限で管理する」と書かれていても、実際のAgent IDに広い書込み権限が残っていれば、説明はできません。
反対に、技術的な設定が適切でも、スポンサー、停止判断者、再開承認者が文書化されていなければ、経営層、監査人、取引先に一貫した説明ができません。
山崎行政書士事務所では、Azure、Microsoft 365、Microsoft Entra IDの技術的な実態を確認しながら、行政書士としての文書整理力を生かし、次の整備を支援します。
支援項目 | 内容 |
AIエージェント棚卸し | Agent ID、アプリ、権限、接続先、利用部門の整理 |
AIエージェント台帳 | ID、目的、データ、権限、ログ、ライフサイクルの文書化 |
所有者・スポンサー表 | 事業責任と技術責任、代理者、緊急停止者の明確化 |
利用目的整理表 | 許可処理、禁止処理、人の承認条件の整理 |
権限マトリクス | 読取り、作成、変更、削除、実行、送信の可視化 |
停止・再開基準 | インシデント重要度、停止判断、再開条件の文書化 |
連絡・承認フロー | 情シス、事業部門、SOC、経営層のRACI整理 |
ログ確認手順 | Entraログ、AI実行ログ、業務ログの関連付け |
証跡提出パック | 監査、取引先審査、経営報告で提示する資料の整理 |
責任分界整理 | 自社、Microsoft、開発会社、運用会社、利用部門の役割整理 |
当事務所は、Azure／Microsoft 365／Entra IDの設定、ログ、契約、運用ルール、責任分界を一体として整理し、情シス、法務、経営層が同じ説明をできる資料づくりを支援しています。
単に規程のひな型を作るのではなく、
実際のEntra ID設定
管理者ロール
条件付きアクセス
Agent IDの所有者・スポンサー
対象システムの権限
監査ログとサインインログ
委託先との役割分担
インシデント時の運用
を照合し、技術的に実行でき、組織として説明できる文書へ落とし込むことを重視しています。
AIエージェントに必要なのは「肩書としての上司」ではない
AIエージェントには、人間のような直属上司はいません。
しかし、組織として安全に利用するためには、次の四者が必要です。
なぜ使うのかを説明するスポンサーどのように動かすかを管理する所有者異常時に止める緊急停止者安全を確認して再開を承認する責任者
AIエージェントが便利になるほど、権限は強くなり、処理速度は速くなり、人の目を通らない業務が増えていきます。
だからこそ、「問題が起きたら考える」のではなく、稼働前に決めておかなければなりません。
最後に、もう一度問いかけます。
貴社のAIエージェントについて、スポンサー、所有者、緊急停止者、再開承認者の氏名をすぐに答えられますか。
答えられない場合、必要なのはAIの追加開発より先に、AIエージェント台帳と責任分界の整備かもしれません。
本記事に関する注意事項
本記事は、2026年7月14日時点のMicrosoft公式情報等に基づく一般的な情報提供を目的としています。
Microsoft Entra Agent IDおよび関連サービスには、正式提供機能とプレビュー機能、v1.0 APIとbeta APIが混在しています。実際の導入時には、利用テナントのライセンス、提供地域、管理画面の表示、公式ドキュメント、メッセージセンター、リリースノートを改めて確認してください。
本記事は、特定の事案に対する法的判断、訴訟対応、紛争当事者間の交渉または代理を行うものではありません。個別具体的な法的判断や紛争対応については、弁護士等の適切な専門家への相談が必要です。
山崎行政書士事務所はMicrosoftとは独立した事業者であり、本記事はMicrosoftによる公式見解または保証を示すものではありません。
コメント