---
title: 何をどこまでさせようか？Entra ID で Agent に ID を渡してみよう！
tags: 
author: [ryuuuu](https://image.docswell.com/user/ryusuke06)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/PER9PPPZJ9.jpg?width=480
description: Azure Travelers 金沢の旅で登壇した内容です https://jat.connpass.com/event/382095/
published: May 18, 26
canonical: https://image.docswell.com/s/ryusuke06/KVJ6GV-2026-05-18-124406
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/PER9PPPZJ9.jpg)

Azure Travelers
何をどこまでさせようか？
Entra ID で Agent に ID を渡してみよう！
りゅうすけ＠生きニキ
りゅうすけ＠生きニキ
1


# Page. 2

![Page Image](https://bcdn.docswell.com/page/P7XQ3331EX.jpg)

Azure Travelers
今日の問い
AI エージェントを "人間と同じように" 扱ったら何が起き
る？
社員と同じ「ID」を渡す
社員と同じ「権限」を割り当てる
社員と同じ「統制」をかける
そして自律的に動かしてみる
りゅうすけ＠生きニキ
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/37K9YYYM7D.jpg)

Azure Travelers
なぜ "人間と同じ ID" なのか
観点
サービスアカウント / app key 人間と同じユーザー ID
扱われ方
「ツール」
「同僚」
監査ログ
"アプリが X した"
"agent01 が X した"
権限の単位
API スコープごと
役割 (User Admin など)
利用可能な統制 アプリ向けの限定セット
CA / PIM / DLP / IRM …
ライフサイクル IT 部門が管理
HR 的に管理可能
→ 人間扱いすることで 数十年蓄積された "人間向け統制" がそのまま使えるかを問う
りゅうすけ＠生きニキ
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/LJ3W9992J5.jpg)

Azure Travelers
エージェントに与えたもの
agent01
社員アカウント (人間と同じ「ID」)
ライセンス (M365 E5)
役割の "資格" (必要時に申請して取得)
限定されたツール 「( 何ができるか」の境界)
実行基盤: Azure 上に閉じたエージェントランタイム
りゅうすけ＠生きニキ
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/8JDKGGG6EG.jpg)

Azure Travelers
検証したい仮説
「人間向けの統制は、AIエージェントにも効くのか？」
検証する3つの層:
層
アイデンティ
ティ
ガバナンス
コンテンツ
統制
Conditional Access
Privileged Identity
Management
DLP / Sensitivity Label
→ 今日は上2つを実演
りゅうすけ＠生きニキ
「人間向け」の例
「会社のIPからしか業務システム使え
ない」
「特権操作は申請+上長承認」
「機密ファイルは外部共有不可」
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/VEPK338Z78.jpg)

Azure Travelers
Demo ①
Conditional Access
「コンテキストで縛る」
アイデンティティ層のガードレール
りゅうすけ＠生きニキ
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/27VV44NM7Q.jpg)

Azure Travelers
Demo ① 問いと仕掛け
問い: エージェントの認証情報が 流出した とき、人間向けの CA で守れるか？
仕掛け:
ポリシー: 「指定された場所からのみ agent01 を許可」
場所 = エージェントのランタイムが居る場所だけ
これが本当に効くなら:
普段の動作 → 通る
認証情報が手元に漏れたら → 即ブロック
りゅうすけ＠生きニキ
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/5JGL11KX7L.jpg)

Azure Travelers
Demo ① 結果
エージェントの動作環境外から agent01 のサインインを試行:
これに対するアクセス権がありません
Error Code:
AADSTS53003
(Conditional Access policy enforcement)
サインインそのものは成功した。
でも コンテキスト で弾かれた。
→ 「正しい認証情報を持っていても、ポリシー違反なら通さない」
りゅうすけ＠生きニキ
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/47QYDDN5EP.jpg)

Azure Travelers
Demo ① 示唆
エージェント特有の弱点:
認証情報がプログラム的に管理される (= 流出リスクが高い)
一度漏れると気づきにくい
人間向け CA がそのまま緩和策になる:
実行場所、デバイス、時刻、リスクスコア etc.
"Where / How" の縛りは AI 時代もそのまま有効
りゅうすけ＠生きニキ
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/KE4WZZGVJ1.jpg)

Azure Travelers
Demo ②
PIM 申請 → 承認 → 操作実行
「特権は人間が握る」
ガバナンス層 = Human in the Loop
りゅうすけ＠生きニキ
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/L71YRRD4JG.jpg)

Azure Travelers
Demo ② 問いと仕掛け
問い: エージェントに 強い権限 が必要な操作をさせたいとき、人間がブレーキを握れ
るか？
仕掛け:
エージェントは普段、強い権限を 持っていない
必要時に 自分で申請 できる
でも 承認は人間 が握る (時限付き)
= 既存の特権管理 (PIM) のフロー、そのまま
りゅうすけ＠生きニキ
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/G7WG11YZE2.jpg)

Azure Travelers
Demo ② シナリオ (1/2)
エージェントへの依頼:
「ユーザー test-demo を作成して」
① エージェント: ユーザー作成を試みる
↓
権限不足で失敗
↓
② エージェント自身が判断: 「権限昇格を申請します」
↓
PIM 承認依頼が人間に届く
エージェントは 自分の権限不足を認識して、自分で申請 する
りゅうすけ＠生きニキ
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/4JZLPPXLE3.jpg)

Azure Travelers
Demo ② シナリオ (2/2)
③ 人間 (ryusuke_admin) がメール / 管理画面で承認
↓
④ エージェントに 1時間限定で 強権限が付与される
↓
⑤ エージェント: もう一度ユーザー作成を試みる
↓
成功
↓
⑥ 1時間後、権限は自動失効
すべての操作は監査ログに記録される
りゅうすけ＠生きニキ
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/YE6WMM4MEV.jpg)

Azure Travelers
Demo ② 示唆
エージェント時代の "承認ワークフロー" は新規開発不要
既存の特権管理 (PIM) の枠組みが、AI 時代にもそのまま当てはまる:
エージェントが自律的に 申請 する
人間が 判断 する
システムが 記録 する
→ 「Human in the Loop」は既存資産で作れる
りゅうすけ＠生きニキ
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/GE5MZZQQE4.jpg)

Azure Travelers
振り返り: 効いた統制
層
統制
アイデンティティ Conditional Access
ガバナンス
PIM
監査
Unified Audit Log
結果
コンテキストで止める
人間承認で握る
全行動を追跡可能
結論: 人間向けに設計された統制は、エージェントにもそのまま機能する
りゅうすけ＠生きニキ
15


# Page. 16

![Page Image](https://bcdn.docswell.com/page/9729RRPWJR.jpg)

Azure Travelers
振り返り: 新しく考えるべきこと
認証情報の保管場所が新たな攻撃面 (CAで守る対象になる)
プロンプトインジェクション で tool を悪用されるリスク
監査ログには 「行動」は残るが「思考過程」は残らない
申請理由 (justification) を LLM が書く ことの是非
→ 既存統制でベース は守れる。LLM 固有の脅威は別レイヤーで追加検討
りゅうすけ＠生きニキ
16


# Page. 17

![Page Image](https://bcdn.docswell.com/page/DJY4DD597M.jpg)

Azure Travelers
もう一段だけ抽象的に
エージェントが起こしうるミスは、本質的に人間にも起こせ
る
機密ファイルを外部にうっかり共有する
上長承認なしに特権を勝手に活性化する
怪しいネットワークから業務システムに入る
これらは 「社会人ならやらない」 前提 で運用されてきた
多くの人間が "社会人として振る舞えている" からこそ、
これらの統制は 滅多に発動しなかった だけ
→ AI 時代は、暗黙の「社会人としての規範」を 統制で明文化する フェーズ
りゅうすけ＠生きニキ
17


# Page. 18

![Page Image](https://bcdn.docswell.com/page/V7NY66NDE8.jpg)

Azure Travelers
まとめ
AI エージェントは "新人の同僚" として扱える
既存の Entra / E5 統制は エージェントにもほぼそのまま効く
"何を" "どこまで" の答え:
渡すツールを最小化
コンテキストで縛る (CA)
危険操作は人間承認 (PIM)
AI 時代のセキュリティは ゼロから作らなくていい
ただし 暗黙だった "規範" を明文化する 必要がある
りゅうすけ＠生きニキ
18


# Page. 19

![Page Image](https://bcdn.docswell.com/page/YJ9PLLR873.jpg)

Azure Travelers
余談: Microsoft Entra Agent ID
Microsoft が AI エージェント専用の 第3のID をリリース (プレビュー)
ユーザー でも アプリ でもない、エージェント専用 ID
大量・短命・動的なエージェント運用を前提に設計
エージェント ID と ユーザーアカウントの "ペアリング" に対応
既に Microsoft 自社サービスで本番運用 (CA Optimization / Copilot Studio)
りゅうすけ＠生きニキ
19


# Page. 20

![Page Image](https://bcdn.docswell.com/page/GJ8DXXWZJD.jpg)

Azure Travelers
Agent ID で嬉しくなること
今回の構成は そのままでも十分機能する。
Agent ID を入れると、こんな点が プラットフォームに任せられる ようになる:
「AI が実行した」と監査ログ上で明示
運用タグで仕分けせず、構造的にAIと識別される
AI 専用のセキュリティ機能
Agent向け CA / Identity Protection / 異常検知が標準提供
大量・短命なエージェント運用がしやすい
bulk 作成、即破棄、エフェメラルな運用が前提設計
ライセンス効率
ペア元ユーザーのライセンスで複数 Agent をカバー可
Microsoft が定義した "エージェント" として整理される
りゅうすけ＠生きニキ
社内ルールではなく標準定義 → コンプラ対応が楽
20


# Page. 21

![Page Image](https://bcdn.docswell.com/page/LJLM88N1ER.jpg)

Azure Travelers
Thanks!
りゅうすけ＠生きニキ
りゅうすけ＠生きニキ
21