Agent 365を学んできた

はじめに

先日、Microsoft Agent 365を一通り学ぶ機会がありました。
普段はAzureで、エージェントを扱うにもFoundryばかりで、何ならCopilot Studioは確か今年に入って見ていなかったし、DefenderポータルやPurviewポータルをちゃんと操作したのも初めてでした。
そんな立場からAgent 365が何を担ってくれるのか、SIとしてどう導入を進めるのが良さそうかを整理してみます。

Agent 365にはプレビューの機能が多く含まれます。本記事の内容は2026年10月末時点で確認したものです。

エージェントが増えていく先

誰が作るかで統制のかけ方が変わる

Microsoftのガバナンスガイダンスでは、エージェントの作成を「誰が作るか」によって3つのゾーンに分けている。

ゾーン	作る人	主なツール
ゾーン1 市民開発	誰でも	Agent Builder、SharePointエージェント
ゾーン2 パートナー開発	IT承認済みの作成者	Copilot Studio
ゾーン3 プロフェッショナル開発	プロの開発者	Microsoft Foundry Agent Service、Copilot Studio

Agent BuilderはMicrosoft 365 Copilotの中で、作りたいエージェントを自然言語で説明して作れる機能で、Copilot StudioはPower Platform上でナレッジやコネクタを組み合わせてエージェントを作るローコードのツールである。どちらもコードを書かずにエージェントを作れる。
Microsoftの区分ではCopilot Studioはゾーン2(IT承認済みの作成者)に置かれているが、ここでは業務を知る現場の人がコードを書かずに作るものとしてAgent BuilderとCopilot Studioをまとめて「市民開発」と呼ぶ。

Foundryでプロコードのエージェントを作る場合は、設計レビュー～テスト～リリース判定と云った既存の開発プロセスに乗るので、誰が作りどのIDで何に接続するかはプロセスの中で決まっていく(ものだと思っている)。
一方でCopilot StudioやAgent Builderは、業務を知っている人がその場でエージェントを作れるので、活用の裾野を広げるという意味で良いのだが開発プロセスを通らないまま共有され、仮に作成者が異動/卒業してもエージェントはそこに残り続ける。

市民開発のエージェントを管理の流れに乗せる

Agent 365が必要になる大きな理由は、こうした市民開発で作られるエージェントをライフサイクルに乗せることだと個人的には考えている。
エージェントを組織のヒトつまり社員のアカウントと同じ管理の流れにするわけである。

社員であれば、アカウントの発行と同時に所属や上長が決まり、業務に必要な権限が付与され、異動や退職のたびに見直される。
エージェントもCopilot Studioで作成すると同時にEntraのエージェントIDが自動で付与されるので、存在そのものはIDとして見えている。
ただIDが振られただけでは、誰が責任を持つのか、何の業務に使うのか、どのデータを参照して良いのか、誰に使わせるのかは決まらない。

企業の基幹データに触れるエージェントは、機微な情報を扱うが故の接続先の権限、また性能面や品質面からプロコードで作る選択肢になると思う。そうであれば、前述のとおり必要な決めごとは開発プロセスの中で自然と固まって認知されていく。
一方で市民開発でMicrosoft 365のデータを使うエージェントは、作成者の権限の範囲で誰でも作れるので、極端なケースでは決めごとを経ないまま使われ始めることがある。いわゆるシャドーAIの問題はエージェントが見えない(管理対象になっていない)ことよりも、この決めごとを経ずに使われていることにある。
Copilot Studioで作ったエージェントは、作成者が個別のユーザーと共有する範囲であれば作成者の判断で使い始められるが、組織全体に公開する場合は、Microsoft 365管理センターに公開のリクエストが上がり、管理者が内容を確認して承認するまで公開されない。

ここで云う「公開」はエージェントを組織のカタログに掲載し、管理者が指定したユーザーやグループに利用可能にすることを指す。(パブリックに公開と云う意味ではない)

この公開の承認は、市民開発のエージェントが人(アカウント)と同じように責任者と用途と権限を決めるプロセスである。

ExcelマクロやAccessで作られた部門システム、個人のPower AutomateフローなどEUC(エンドユーザーコンピューティング)において、同じ構図をこれまでにも経験してきた。が、AIエージェントの場合は決めごとが曖昧なまま使われることで生じる問題がEUC以上に広い。

管理されないことによる想定ケース

部門ごとに似た目的のエージェントが乱立すれば利用者はどれを使えば良いのか判断できず、参照するナレッジや指示がエージェントごとに違えば回答もばらつく。作成者が異動したあとはナレッジの更新が止まり、古い情報のまま回答し続けるエージェントも出てくる。
データの面で想定されそうな問題は、エージェントは作成者や利用者の権限でデータを読みに行くためSharePointの共有設定が緩かったりすると本来見せたくない文書がそのまま回答のエビデンスになる。
外部のサービスに接続するエージェントであれば、情報が組織の外に出ていく経路にもなり得る。

そして、その上でエージェントは動くたびにモデルを呼び出しトークンを消費していく。
用途の重なるエージェントが同じナレッジを別々に読みに行けばその分コストが積み上がり、何らかのトリガーで自律的に動くエージェントは利用者がいなくても動き続ける。

コストは目に見えやすい問題だが、回答の品質・データの保護・責任の所在も含め、いずれもエージェントごとに責任者、用途、参照してよいデータを明確にしていく必要がある。

Agent 365の位置づけ

前置きが長くなったが、Agent 365はこうした組織内で増えるエージェントを観察し、統制し、保護するコントロールプレーンである。
とは云え、Agent 365と云う専用のポータルができたわけではなく、人やデータの管理に使ってきた既存に存在する下記のポータルにAgent 365としてエージェント向けの機能が加わったイメージである。

• Microsoft 365管理センター(https://admin.cloud.microsoft/): エージェントの一覧、公開承認
• Microsoft Entra管理センター(https://entra.microsoft.com/): エージェントID、条件付きアクセス
• Microsoft Purviewポータル(https://purview.microsoft.com/): データの分類・保護、監査
• Microsoft Defenderポータル(https://security.microsoft.com/): 脅威の検知、リアルタイム保護

エージェントレジストリ

エージェント管理の起点はMicrosoft 365管理センター(https://admin.cloud.microsoft/)のエージェントレジストリで、「Copilot StudioやFoundryで作られたエージェント」「Microsoft 365以外の環境で構築されたエージェント」「管理者が登録したエージェント」が1つの一覧に並ぶ。
レジストリの上部には、「エージェントの総数」「所有者のいないエージェント」「Agent 365の管理外で動いているエージェントの数」が表示される。
所有者のいないエージェントのカードを選ぶとその場で一覧が絞り込まれ、そこからブロックや削除に進める。
作成者を組織から削除すると、この数は自動で更新される。
Purview、Entra、Defenderから上がってきたリスクのシグナルもエージェントごとに集計されて表示されるので、棚卸しとリスクの把握は、まずこの画面で足りる。一覧はCSVへのエクスポートや、Microsoft Graph API(プレビュー)での取得もできる。

設定箇所：
Microsoft 365 管理センター → エージェント → すべてのエージェント → レジストリ

他のクラウドで作られたエージェントも、Amazon BedrockやGoogle CloudのGemini Enterprise Agent Platform（旧Vertex AI）など、対応するプラットフォームとの接続をMicrosoft 365管理センターで設定して同期すれば、レジストリに表示できるようだ。
同期は読み取り専用で、確認できるのはエージェントの一覧と、プラットフォームによっては利用状況までのようである。エージェント自身にEntra IDを持たせたり、コードレベルの監視を組み込んだりするには、後述のAgent 365 SDKが必要になる。

Microsoft Entra Agent ID

エージェントをIDとして扱う

エージェントをEntraのIDとして扱うことで、RBACでの権限付与と剥奪、サインインログの追跡、条件付きアクセスの適用が、組織の従業員と同じようにできるようになる。

Copilot Studioでは、2026年5月以降に作成したエージェントに自動でエージェントIDが付与される。
最初のエージェントを作成した時点でテナントに「Microsoft Copilot Studio エージェント ID ブループリント」が追加され、各エージェントIDはその子として作られる。
Copilot Studioでは、この機能が提供されるより前に作成されたエージェントがアプリ登録IDを使っているため、エージェントIDを持つものとアプリ登録IDを使うものが混在している場合がある。
今後のアップデートでMicrosoftによって移行される予定であるらしいが、Copilot Studio エージェントを Microsoft Entra エージェント ID に移行する (プレビュー)を参考に、移行しておく選択肢もある。
なおFoundryはエージェントの作成時にエージェントIDが設定される。

アクセスのパターンと条件付きアクセスの対象

エージェントにAzure AI SearchSharePointなどMicrosoft Entra IDで認証するリソースへアクセスさせる際、条件付きアクセスを設定するとトークンの発行時にアクセス要求を制御できる。
ただしエージェントが使う認証方式によって、条件付きアクセスが評価するIDは異なる。この節では代表的なアクセスパターン、それぞれのトークンの主体と条件付きアクセスの評価対象を整理する。

ユーザーの代理（OBO）

OBO（On-Behalf-Of）は、サインインしたユーザーの代理としてエージェントがリソースにアクセスする方式である。ユーザーの委任された権限を使うため、トークンの主体と条件付きアクセスの評価対象はユーザーとなる。

EntraエージェントID

ユーザーの代理ではなく、エージェント自身のEntraエージェントIDでアクセスする方式である。トークンの主体はエージェントIDとなり、条件付きアクセスはそのエージェントID、またはエージェントIDのブループリントを対象に評価される。

エージェントユーザーアカウント

Microsoft Entra エージェント IDのエージェントのユーザーアカウントは、エージェントIDに紐づけてEntra ID上に作成する専用のユーザーIDである。既存の従業員アカウントを流用するものではなく、メールボックスを持たせてチームの一員として動かすなど、ユーザーとしての機能が必要な場合に、エージェントIDの子として新規に作成する。
トークンの主体はこのエージェントユーザーアカウントとなり、条件付きアクセスでは「エージェントユーザー」を対象にする。

条件付きアクセスの対象はトークンの主体に対応する。
エージェントIDを対象にしたポリシーはエージェントユーザーアカウントには適用されず、その逆も同じである。設計時には、エージェントがどのIDでアクセスするかを確認する必要がある。

これらとは別に、APIキーでリソースへ直接アクセスする構成もあるが、この場合はEntra IDからトークンを取得しないため、条件付きアクセスは評価されない。

エージェントの公開と承認

カスタムセキュリティ属性はEntra IDの機能で、ユーザーやエージェントIDなどのオブジェクトに、組織独自のキーと値を追加で割り当てられる。
「承認ステータス」のような属性を定義し、新規、審議中、承認済みと云った値をエージェントIDに割り当てる。そのうえで、承認済みの値を持たないエージェントIDを条件付きアクセスでブロックしておく。

Copilot Studioのエージェントは、公開申請の審査を経て承認ステータスの属性が付与される。

Foundryのエージェントは、そもそもこの公開承認の対象ではない。

カスタムセキュリティ属性と条件付きアクセスの組み合わせは、公開承認の仕組みがあるかどうかに関わらず、Entra IDで認証するリソースへのアクセスをID層で止められる点に意味がある。個別共有のCopilot Studioのエージェントであっても、Foundryのエージェントであっても、承認済みの属性が付くまではSharePointやAzure AI Searchなどへのアクセスそのものをブロックできる。

なお属性の割り当てには「属性の割り当て管理者」という専用のロールがあり既定ではグローバル管理者にもこの権限がない。
Entra全体の管理者ではなくAI CoEのような専任チームにこのロールだけを割り当て、承認ステータスの付与を任せる設計にできる。
新しく作られたエージェントは、公開審査や設計レビューを経てこのロールの担当者が承認ステータスの属性を付与するまでリソースにアクセスできない。
これにより市民開発そのものは止めずに組織のリソースに触れる出口で統制をかける考え方で、ゾーンの考え方とも整合する。

未承認のエージェントをブロックするこの条件付きアクセスポリシーはレポート専用で作成し、What Ifで承認済みのエージェントが除外されることを確認してから有効にするのが良い。

エージェント公開時のポリシーテンプレート

Copilot Studioで作ったエージェントを組織に公開する際は、Microsoft 365管理センターに上がってくるリクエストを管理者(AI管理者)が審査し、利用者の範囲とポリシーテンプレートを選んで公開する流れにできる。

ポリシー テンプレートは、Entra、Purview、SharePoint Online、Defenderのポリシーを束ねてエージェントに一括で適用する仕組み。
既定のテンプレートには監査、DSPM(Data Security Posture Management：データセキュリティ態勢管理。データの共有状況から過剰共有などのリスクを評価する機能)、IDの保護、リアルタイム保護などが含まれ、カスタムテンプレートではEntraで作成した条件付きアクセス、アクセスパッケージ、カスタムセキュリティ属性を追加できる。前述の承認ステータスによる条件付きアクセスは、そのままテンプレートの部品になる。

テンプレートを適用できるのは新しくアクティブ化するエージェントだけで、承認済みのエージェントに後から適用することはできないため、テンプレートの設計はエージェントの公開が増える前に固めておく必要がある。
またEntraのポリシーはエージェントが Entra の認証でリソースにアクセスしていることが前提になる。そうでないエージェントに対しては、実行時には効かない可能性がある。

Microsoft Purview

秘密度ラベルとDLP

秘密度ラベルは、ファイルやメールに「社外秘」のような機密度の印を付けるPurviewの機能で、暗号化や共有の制限と連動させられる。
このラベルはCopilotやエージェントにも認識される。
機密データの持ち出しや不適切な利用を検知、ブロックするDLP(Data Loss Prevention：データ損失防止)のポリシーには、「Microsoft 365 Copilot と Copilot Chat」というロケーションがあり、次の条件とアクションを組み合わせられる。

条件	アクション	効果
秘密度ラベル	Copilotによる処理を禁止	ラベルの付いたファイルやメールを応答の生成に使わない(引用には表示される)
機密情報の種類	プロンプトの処理を禁止	プロンプトに機密情報が含まれる場合、応答しない
機密情報の種類	Web検索の実行を禁止	外部のWeb検索を応答の根拠に使わない
外部ユーザーから受信したメール(プレビュー)	Copilotによる処理を禁止	外部ドメインからのメールを根拠や要約に使わない

同じルールの中で秘密度ラベルの条件と機密情報の種類の条件は組み合わせられないため、条件ごとにルールを分ける。
ポリシーの変更が反映されるまでに最大4時間ほどかかる。またプロンプトにアップロードされたファイルの中身はDLPの評価対象にならない点を認識しておく必要がある。

ラベルの体系を持っていない組織向けには、Microsoftが既定のラベルとポリシーを用意している。
個人、公開、全般、社外秘、非常に機密性の高い社外秘の5つを軸に、サブラベルで共有範囲を分ける構成になっている。

実装の一例として、経理部門がクレジットカード番号や銀行口座情報を含む請求書・経費レポートを扱っているとする。
これらの文書に「社外秘」の子ラベルとして「社外秘/財務データ」を割り当てDLPポリシーの条件に秘密度ラベル「社外秘/財務データ」を指定、アクションに「Copilotによる処理を禁止」を選んでおく。
すると、経理部門のCopilot Studioエージェントが社内のナレッジをもとに回答を作る際、このラベルの付いた請求書や経費レポートは応答の生成には使われなくなる(ユーザーが文書自体を開けば中身は見えるし、引用としては表示される)。

エージェント開発を加速させるデータガバナンス

ランディングゾーンのような共通基盤では、Azure Policyなどのガードレールを先に用意しておくことで、Spokeシステムは全体の設計に悩まずにアプリケーションの開発へ集中できるが、エージェントの実行基盤も同じ構図になると想像する。
データの扱いは共通基盤でも重要だが、エージェントでは特に欠かせない。エージェントは作成者や利用者の権限でデータを読みに行き、その内容を回答の根拠にする。前述のとおり共有設定が緩ければ本来見せたくない文書も回答に使われ得るので、何を参照させて良いかの基準がデータの側になければ、エージェントごと、案件ごとに個別に判断することになる。

そこでまずデータの現状を把握し、そのうえでデータの側に判断の基準を作っていく。

DSPMで過剰共有を洗い出す

PurviewのDSPMでは、SharePointサイトを対象に過剰に共有されている機密データを洗い出すデータリスク評価ができる。
利用状況の上位100サイトは毎週自動で評価され、結果から「ラベルによるアクセス制限」「Restricted Content Discovery」「自動ラベル付けポリシーの作成」と云った修復に進める。初回は結果が出るまでに日数を要する。

Microsoftのブループリント

Copilotの展開に向けた過剰共有対策は、Microsoftが「ブループリント」としてもまとめている。
これはCopilotを使い始める前に何を整えるかを示した手順のようなもので、「過剰共有の修復」「ガードレールの設定」「規制への準拠」の3つで構成されている。DSPMで洗い出した結果への対処は、このうちの「過剰共有の修復」にあたる。リスクの高いサイトとファイルを識別し、必要に応じて暫定的にアクセスを制限して、アクセスの問題を修正していく。ここではPurviewに加えて、Microsoft Copilotのライセンスに含まれるSharePoint高度な管理(SAM=SharePoint Advanced Management)も使う。

データの側に作る判断の基準

ブループリントの「ガードレールの設定」にあたるのが、ラベルとDLPによる基準づくりである。ラベルが整っていれば、「社外秘までは部門のエージェントに参照させて良い」「非常に機密性の高い社外秘はDLPで除外する」と、判断の基準をデータの側に置ける。基準があれば、エージェントを作る側は案件ごとに「このデータを参照させて良いのか」を一から検討せずに済み、同じ基準に沿って開発を進められる。

監査

Purviewの監査(Audit)は、ユーザーや管理者の操作を記録して検索できる機能である。
CopilotやAIアプリの操作は、監査(Standard)の一部として自動的に記録され、Copilot StudioやFoundryで作ったアプリも対象に含まれる。Standardは監査の標準のレベルで、既定で有効になっており、記録の保持期間は180日である。上位の監査(Premium)では、保持ポリシーによる最大10年までの長期保持などが加わる。
レコードには、応答の生成で参照したファイル、秘密度ラベルのID、ポリシーでブロックされたかどうかと云った情報が入る。
ただし記録されるのはメタデータで、プロンプトや応答の全文ではない。会話の内容を確認するにはDSPMのアクティビティエクスプローラーなど別の画面を使うことになるので、インシデント対応の手順においてどの画面で何を確認するか把握しておく必要がある。

Microsoft Defender

リアルタイム保護

Defenderは、エージェントがツールを呼び出す前にその操作を評価し、危険な操作を実行前に止める。
評価の範囲はエージェントの種類によって異なり、Copilot Studioのエージェントはツールの呼び出し、Foundryのエージェントはユーザーの要求やエージェントの応答まで対象になる(いずれもプレビュー)。

検出できる脅威のシナリオとしては、悪意のあるコンテンツの伝播、シークレットの流出、回避手法、安全でないメールドメインへの送信が挙げられている。
既定のルールは監査のみでブロックはしないため、ブロックするには対象のエージェントと検出の種類を絞ったカスタムルールを作成する。
監査で影響を見極めてからブロックに進める、という段階を踏む。

設定箇所：
Microsoft Defender ポータル → 設定 → AI のセキュリティ → ポリシーとルール → リアルタイム保護

高度なハンティングでエージェントを調べる

Defenderには、集まったデータをKQLで検索できる高度なハンティングという機能があり、その中にエージェントの情報を持つAgentsInfoテーブルがある。レジストリの画面で絞り込めるのは状態、発行元の種類、チャネル、プラットフォーム、データソースと云った項目だが、このテーブルはシステムプロンプト、宣言されたツール、接続しているMCPサーバー、ガードレールまで列として持っている。
セキュリティの観点でエージェントの構成を横断的に調べたいときは、こちらを使う。たとえば、MCPサーバーに接続している稼働中のエージェントを一覧にするなら、次のようなクエリになる。

AgentsInfo
| summarize arg_max(Timestamp, *) by AgentId
| where LifecycleStatus == "Active"
| where array_length(McpServers) > 0
| project AgentName, Platform, Owners, SharedWith, McpServers, Guardrails

プロコードのエージェント

Microsoft Foundryで作ったエージェント

Foundryで発行したエージェントは、手動で登録しなくてもAgent 365のレジストリに表示される。
トレース、評価、ガードレールと云ったエージェントの中身に近い制御はFoundryが担い、レジストリ、ID、ポリシー、データ保護はAgent 365が担う、という役割分担になる。

SIの観点で気にしておきたいのはデータの保存場所である。Foundryのデータはリソースを作成したAzureリージョンに従うが、Agent 365のデータはEntraテナントの地域に従う。アクティビティデータがFoundryからAgent 365に流れた時点で保存場所が変わることになるため、データの所在地に要件があるシステムでは、Foundryのリソース単位でAgent 365へのデータ収集をオプトアウトできることを設計に織り込んでおきたい。

Agent 365 SDK

Foundry以外で作ったエージェント、たとえばMicrosoft Agent FrameworkやLangChainで書いてAzureやAWSでホストしているエージェントは、Agent 365 SDKを組み込むことでAgent 365の管理下に入れられる。
SDKはエージェントを作ったりホストしたりするものではなく、既存のエージェントに次のような機能を足すものである。

• Entraのエージェント IDによる認証と、メールボックスなどエージェント自身のリソースへのアクセス
• Teams、Outlook、Wordのコメントなどからの通知の受信と応答
• 管理されたMCPサーバー経由での、メール、予定表、SharePoint、TeamsなどMicrosoft 365のデータへのアクセス
• OpenTelemetryによる、推論やツール呼び出しの監視

合わせてAgent 365 CLIが用意されていて、ブループリントの作成、Azureへのデプロイ、Microsoft 365管理センターへの公開までをコマンドで進められる。

レジストリ同期とSDKの違いは、見えるようにするか、管理下に置くかの違いだと理解している。Entraのポリシーはエージェントが Entraで認証していることが前提なので、プロコードのエージェントを統制の対象にするなら、SDKでEntraのIDを持たせる必要がある。

導入をどう進めるか

Agent 365の構成要素を見ていくと、複数の既存ソリューションの延長上にあり、ラベル体系の雛形、DLPルールのセット、条件付きアクセスのポリシー群、公開の承認フローなどに分解できる。
実際の導入のシーンにおいては、こうした設計要素の推奨を設定した上でお客様の業務要件や扱うデータの性質に合わせていけば良い。
(Agent 365に特化した考え方ではないが)

段階ごとのインプットとアウトプット

ここまでの内容をもとに、導入の段取りを整理した(案)。

No.	段階	インプット	アウトプット	お客様と調整すること
1	現状把握	レジストリのエージェント一覧、SharePointサイトの一覧と共有設定、DSPMのデータリスク評価	所有者不在のエージェントの一覧、過剰共有サイトの一覧	各サイト、各エージェントの責任者
2	データ分類	情報セキュリティ規程、文書管理規程、情報資産台帳	ラベル体系、ラベルごとの取扱いマトリクス	ラベルの段階と名称、規程との対応付け、ラベルを付ける主体
3	エージェント統制	ゾーンの考え方、部門の体制	ゾーンごとの作成者と公開の承認フロー、承認ステータスの属性値、ポリシーテンプレート	承認者、市民開発を許容する範囲、作成者が異動したときの扱い
4	段階的な適用	No.2とNo.3の定義	条件付きアクセス、DLP、Defenderのルールの適用計画	レポート専用、シミュレーション、監査からブロックへ切り替える判断基準
5	運用	監査ログ、DSPM、Defenderのアラート	棚卸しの周期、インシデント対応の手順	SOCや情報システム部門との役割分担

No.4の適用計画は前タスクがインプットになるのでそれらを先に固めてから進める。No.2のデータ分類であれば、例えば下表のように整理してユーザーデータに反映していくのだろうと想像する。

ラベル	代表的なデータ	主な保存場所	閲覧できる人	Copilot・エージェントの参照	外部共有	ラベルの付け方
公開	公開済みの製品資料	広報サイト	誰でも	可	可	手動
全般	社内通達、組織図	全社ポータル	全社員	可	確認のうえ可	既定のラベル
社外秘	契約書、見積書	部門サイト	部門のメンバー	部門のエージェントのみ可	不可	自動ラベル付け(推奨)
非常に機密性の高い社外秘	人事評価、未発表の財務情報	限定サイト	指定したユーザー	不可(DLPで除外)	不可	自動ラベル付け(適用)

さいごに

エージェント実行環境に欠かせないAgent 365が、今後もアップデートが行われ統制する仕組みが整っていくことで、お客様ごとに最適化されたエージェントが安全に連携していく未来の業務が見えてきた気がします。
とは云え完全理解には全然至っていないのでもうちょっと触っていきたいと思います。

ここまでお読みくださりありがとうございました。