MENU

Microsoft 365 CopilotのGraph APIでアプリ/エージェント管理はどう変わる？管理者向け確認ポイント

Copilot

Microsoft 365 Copilotの「Microsoft Graph APIs for App & Agent Inventory and Details」は、Copilot、Teams、Outlookなどで使われるアプリやエージェントを、管理画面だけでなくMicrosoft Graph APIから棚卸し・詳細確認できるようにする更新です。結論から言うと、利用者の操作画面が大きく変わる更新ではなく、IT管理者や開発者が「どのエージェントが、誰に、どのホストで、どの状態で使えるのか」を自動的に把握し、監査・運用・ガバナンスに組み込めるようになる点が重要です。

特に確認すべきなのは、対象テナントでMicrosoft Agent 365ライセンス、管理者ロール、Graph APIのアクセス許可、/beta APIの扱いをどう整理するかです。Microsoft 365 Roadmapの項目ID 502875では、対象製品はMicrosoft Copilot (Microsoft 365)、クラウドはWorldwide (Standard Multi-Tenant)、プラットフォームはWeb、プレビューは2026年3月、一般提供は2026年4月、ステータスはLaunchedとされています。変更日時はUTCで2026年5月8日22:15で、日本時間では2026年5月9日朝の更新に相当します。(Microsoft)

目次

Microsoft 365 CopilotのGraph API更新で何が変わるのか

今回の更新で変わるのは、Microsoft 365 Copilotまわりのアプリ・エージェント管理を「人が管理画面で確認する運用」から、「APIで取得してレポート化・監査・自動化する運用」へ広げられる点です。

Microsoftの説明では、新しいGraph APIエンドポイントにより、IT管理者と開発者がCopilot、Teams、Outlook、その他のMetaOSホストにまたがるアプリとエージェント管理へプログラムからアクセスできるようになるとされています。主な機能は、テナント内のアプリ/エージェントを一覧化するInventory APIと、個別のアプリ/エージェントの詳細メタデータを取得するDetails APIです。(Microsoft)

管理者目線では、次のような確認がしやすくなります。

確認したいことAPIで見えるようになる情報の例実務での使い道
テナント内にどのエージェントがあるか表示名、種類、発行元、対応ホスト、最終更新日時定期棚卸し、未承認エージェントの発見
誰に利用可能かavailableTo、許可ユーザー/グループ利用範囲の監査、部門別展開の確認
実際に展開されているかdeployedTo、取得済みユーザー/グループ展開状況レポート、ライセンス・導入状況の整理
ブロックされているかisBlocked利用禁止アプリの管理、セキュリティ対応
どのホストで使えるかCopilot、Teams、Outlook、M365など影響範囲の把握、展開前テスト
リスク判断に必要な情報感度、カテゴリ、機能、要素タイプガバナンス、監査、例外承認

これまでアプリやエージェントの管理は、管理センターでの目視確認や個別の運用ルールに依存しがちでした。今回のAPIにより、たとえば「外部発行元のエージェントだけを抽出する」「全ユーザーに展開されているCopilotエージェントを一覧化する」「最終更新日が新しいものだけを監査対象にする」といった運用が組みやすくなります。

Inventory APIとDetails APIの役割

Microsoft 365 Roadmapでは、Inventory APIはテナント内のすべてのアプリとエージェントの包括的なインベントリ取得に使えると説明されています。フィルター条件として、1P、3P、LOB、Sharedなどの種類、Copilot、Outlook、Teams、Officeなどのホスト、最終更新日などが挙げられています。(Microsoft)

一方、Details APIは、特定のアプリまたはエージェントについて、可用性、展開状態、対応ホスト、作成者情報、バージョン、感度、カテゴリ、Graph connectors、ナレッジソース、プラグインアクションなどの機能情報を確認するためのAPIです。監査、ライフサイクル管理、既存ITワークフローへの統合に使うことが想定されています。(Microsoft)

実務では、まずInventory APIで全体像を取得し、気になる対象だけDetails APIで深掘りする流れが現実的です。

API主な目的使う場面
Inventory APIアプリ/エージェントの一覧取得月次棚卸し、展開状況のレポート、リスク候補の抽出
Details API個別アプリ/エージェントの詳細確認監査、例外承認、展開前レビュー、インシデント調査

たとえば、全社展開されている外部アプリを洗い出したい場合は、一覧取得で候補を抽出し、詳細取得で発行元、対応ホスト、感度、許可ユーザー、展開先を確認します。人事・財務・法務など機密性の高い領域に関連するエージェントであれば、利用範囲や所有者をより厳しく確認する必要があります。

対象範囲はCopilotだけでなくTeamsやOutlookにも及ぶ

この更新は「Microsoft 365 Copilot」のロードマップ項目ですが、対象をCopilotチャットだけに限定して考えると見落としが出ます。Roadmapの説明では、Copilot、Teams、Outlook、その他のMetaOSホストにまたがるアプリとエージェント管理が対象とされています。(Microsoft)

管理者が特に注意すべきなのは、エージェントの利用場所が分散していることです。ユーザーはCopilotだけでなく、Teams上のアプリ、Outlookのアドイン、Officeアプリ内の拡張、M365ホスト経由の機能としてエージェントやアプリを使う可能性があります。

そのため、棚卸しの観点は次のように分けると整理しやすくなります。

観点確認ポイント
ホストCopilot、Teams、Outlook、M365、Office系アプリのどこで使えるか
種類Microsoft製、外部パートナー製、組織内共有、LOB/カスタムか
展開範囲全員、一部ユーザー/グループ、未展開のどれか
所有者作成者や管理責任者が明確か
データ接続Graph connectors、ナレッジソース、プラグインアクションが含まれるか
リスク機密情報に触れる可能性、外部サービス連携、退職者所有の有無

「Copilotのエージェントだけを見れば十分」と考えると、TeamsやOutlook側で利用されるアプリを見逃す可能性があります。Copilot導入後のガバナンスでは、利用者の入口ではなく、アプリ/エージェントが組織データにどう接続し、どのホストで使われるかを軸に管理することが重要です。

公式ドキュメント上のAPI名とエンドポイント

Microsoft Learnでは、今回の機能に近い管理APIとして「Agent and app Package Management API overview (preview)」が案内されています。このAPIでは、組織カタログ内のエージェントまたはMicrosoft 365アプリを「package」として扱い、すべてのアプリ/エージェントの一覧取得、個別の詳細情報取得、メタデータや詳細要素の確認ができると説明されています。(Microsoft Learn)

主なAPIは次のとおりです。

操作HTTPメソッドエンドポイント用途
List packagesGET/copilot/admin/catalog/packages組織内のすべてのアプリ/エージェントを取得
Get package detailsGET/copilot/admin/catalog/packages/{id}特定のアプリ/エージェントの詳細メタデータを取得
Update packagePATCH/copilot/admin/catalog/packages/{id}許可ユーザー/グループ、展開対象などを更新
BlockPOST/copilot/admin/catalog/packages/{id}/blockパッケージの使用をブロック
UnblockPOST/copilot/admin/catalog/packages/{id}/unblockブロックを解除
ReassignPOST/copilot/admin/catalog/packages/{id}/reassign所有者を別ユーザーへ再割り当て

Microsoft Learnの概要ページでは、一覧取得、詳細取得に加えて、ブロック、ブロック解除、所有者再割り当てもAPI一覧に含まれています。(Microsoft Learn) ただし、Roadmapの項目名は「Inventory and Details」であり、まず注目すべきは棚卸しと詳細確認です。更新・ブロック系の操作は、十分にテストしてから限定的に使うべきです。

管理者が最初に確認すべき設定

このAPIを使う前に、管理者は「APIが使えるか」だけでなく、「誰が、どの権限で、何を取得・変更できるか」を確認する必要があります。

ライセンス要件を確認する

Microsoft LearnのPackage Management API概要では、このAPIへのアクセスにはMicrosoft Agent 365ライセンスが必要とされています。(Microsoft Learn) Microsoft 365 Copilotの導入済みテナントであっても、実際にAPIを利用する前にAgent 365のライセンス状態を確認してください。

運用上は、次の順で確認すると手戻りが少なくなります。

確認項目確認する理由
Microsoft 365 Copilotの利用状況エージェント管理の対象範囲を把握するため
Microsoft Agent 365ライセンスPackage Management APIの利用条件に関わるため
対象クラウドLearnではグローバルサービスで利用可能、米国政府機関クラウドや21Vianet中国では非対応とされています
テナントの展開状態Roadmap上はLaunchedでも、テナント反映に差が出る可能性があるため

Microsoft 365 Roadmapは商用機能の予定日や説明を掲載するものですが、情報は変更される可能性があると明記されています。展開時期や利用条件は、ロードマップだけでなく、Microsoft 365管理センターのメッセージセンターとMicrosoft Learnの最新ページで併せて確認するのが安全です。(Microsoft)

管理者ロールを確認する

Microsoft LearnのAgent 365管理ページでは、エージェントレジストリデータへGraph APIでアクセスでき、一覧取得と詳細取得によってコンプライアンス、レポート、監査、管理に役立てられると説明されています。また、これらのAPIにはAI adminまたはGlobal adminロールが必要とされています。(Microsoft Learn)

本番運用では、Global adminで日常的にAPIを実行するのは避けるべきです。可能な限り、必要な作業に応じてAI adminなどの適切なロールを割り当て、定期棚卸し用、監査用、変更操作用の責任者を分けてください。

Graph APIのアクセス許可を確認する

一覧取得APIでは、最小特権の委任アクセス許可としてCopilotPackages.Read.All、より高い権限としてCopilotPackages.ReadWrite.Allが示されています。個人用Microsoftアカウントとアプリケーションアクセス許可はサポートされていません。(Microsoft Learn)

読み取りだけの棚卸しであれば、最初からReadWrite権限を与える必要はありません。まずCopilotPackages.Read.Allで取得できる範囲を確認し、ブロックや所有者変更などの操作が必要になった段階で、別途ReadWrite権限を検討するのが現実的です。

目的推奨する考え方
棚卸し・監査レポート読み取り権限から始める
展開対象の変更変更対象、承認者、ロールバック手順を決めてからReadWriteを使う
ブロック/解除影響ユーザーを確認し、業務停止リスクを評価してから実行する
自動化権限、実行者、ログ保管、変更承認をセットで設計する

/beta APIである点を軽視しない

Microsoft LearnのList packagesページでは、/betaバージョンのAPIは変更される可能性があり、実稼働アプリケーションでの使用はサポートされないと明記されています。HTTP要求はGET https://graph.microsoft.com/beta/copilot/admin/catalog/packagesです。 (Microsoft Learn)

これは非常に重要です。たとえば、監査レポートの自動生成には使えても、業務停止につながる制御を完全自動化するには慎重な設計が必要です。

具体的には、次のような対策を入れてください。

リスク対策
プロパティ名や応答形式が変わる取得項目を固定しすぎず、未知の値を許容する
API仕様変更で自動処理が失敗する監視、エラー通知、手動確認フローを用意する
ブロック操作を誤実行する本番変更は承認制にし、最初は読み取り専用で運用する
管理センター表示とAPI結果に差が出る初期展開時はUIとAPIの結果を突き合わせる
権限が強すぎる読み取り用と変更用を分離し、ReadWrite権限を常用しない

特に日本企業の情シス運用では、「APIで取れるようになったからすぐ自動制御する」よりも、「まず棚卸しを自動化し、例外やリスクを見える化する」段階から始める方が失敗しにくいです。

APIで取得できる情報の具体例

List packages APIでは、テナントで利用可能なすべてのパッケージを取得できます。フィルター条件として、supportedHosts、elementTypes、lastModifiedDateTimeがサポートされており、Copilot、Outlook、Teams、M365などのホストや、Bots、DeclarativeAgent、CustomEngineAgentなどの要素タイプで絞り込めます。(Microsoft Learn)

たとえば、Copilotで使えるエージェントを一覧化する場合は、次のようなリクエストが例示されています。

GET https://graph.microsoft.com/beta/copilot/admin/catalog/packages?$filter=supportedHosts/any(h:h eq 'Copilot')

一覧取得の応答には、id、displayName、type、shortDescription、isBlocked、supportedHosts、lastModifiedDateTime、availableTo、deployedToなどが含まれます。(Microsoft Learn)

Get package details APIでは、特定のIDを指定して詳細情報を取得します。HTTP要求はGET https://graph.microsoft.com/beta/copilot/admin/catalog/packages/{id}で、成功時にはcopilotPackageDetailオブジェクトが返ります。 (Microsoft Learn)

詳細情報には、一覧取得で得られる基本情報に加えて、longDescription、categories、sensitivity、allowedUsersAndGroups、acquireUsersAndGroups、elementDetailsなどが含まれます。(Microsoft Learn)

管理レポートに落とし込むなら、まずは次の項目を標準列として持つと使いやすくなります。

レポート列見るべき理由
IDAPIで個別詳細を取得するキーになる
表示名管理者・部門担当者が識別しやすい
種類Microsoft製、外部製、共有、カスタムの区別に使う
発行元外部サービス連携やベンダー確認に使う
対応ホストCopilot、Teams、Outlookなど影響範囲を把握する
ブロック状態利用禁止対象の確認に使う
利用可能範囲全社公開か、一部ユーザーかを判断する
展開範囲実際の配布状態を確認する
最終更新日時新規・変更された対象の抽出に使う
感度/カテゴリ監査やリスク分類に使う
所有者/許可グループ退職者所有や責任者不明の検出に使う

管理者・開発者への影響範囲

今回の更新による影響は、主に管理者、セキュリティ担当、開発者、IT運用担当に及びます。

Microsoft 365管理者への影響

Microsoft 365管理者にとっては、CopilotエージェントやMicrosoft 365アプリの棚卸しを定期運用に組み込めるようになる点が大きなメリットです。

これまでは、導入時に承認したアプリやエージェントであっても、更新、所有者変更、展開範囲変更が積み重なると、実態把握が難しくなりがちでした。APIで一覧化できれば、月次で差分を取り、次のような異常を検知できます。

  • 外部発行元のアプリが全ユーザーに利用可能になっている
  • 退職者が作成・所有していたエージェントが残っている
  • CopilotだけでなくOutlookやTeamsでも使えるようになっている
  • 機密性の高いカテゴリのエージェントが広範囲に展開されている
  • ブロック済みのはずのパッケージが解除されている

特にCopilot導入が進む組織では、「ユーザーが便利に使える状態」と「組織として管理できる状態」を両立させる必要があります。APIによる棚卸しは、その土台になります。

セキュリティ・コンプライアンス担当への影響

セキュリティ担当者にとっては、エージェントがどのデータや機能に接続し得るかを確認しやすくなることが重要です。Roadmapでは、Details APIによりGraph connectors、ナレッジソース、プラグインアクションなどの機能情報を確認できると説明されています。(Microsoft)

この情報は、次のような判断に使えます。

判断したいこと確認する情報
外部サービス連携のリスク発行元、機能、プラグインアクション
機密情報への接触可能性感度、カテゴリ、ナレッジソース
監査対象にすべきか全社展開、外部製、最終更新日
例外承認が必要か利用部門、所有者、展開範囲
インシデント時の影響範囲対応ホスト、許可ユーザー/グループ

Copilotやエージェントは、単体のツールではなく、組織データ、ユーザー操作、外部アプリをつなぐ接点になります。セキュリティレビューでは、アプリ名だけで判断せず、「どこで使えるか」「誰が使えるか」「何に接続するか」をセットで見る必要があります。

開発者・IT運用担当への影響

開発者やIT運用担当にとっては、既存の運用システムやレポート基盤にCopilotエージェント管理を組み込めるようになる点が実務的なメリットです。

たとえば、次のような活用が考えられます。

活用シーン実装イメージ
月次棚卸しList APIで全件取得し、前月との差分をCSVやPower BIに出力
展開前レビュー新規エージェントの詳細を取得し、承認フローに回す
退職者対応所有者情報を確認し、必要に応じて再割り当てを検討
セキュリティ監査外部製、全社展開、感度ありの条件で抽出
インシデント調査特定アプリの対応ホスト、利用可能範囲、詳細要素を確認

ただし、読み取りと変更を同じ自動処理に混ぜるのは避けるべきです。最初は読み取り専用の棚卸しから始め、変更操作は人の承認を挟む運用にすると、誤操作による影響を抑えられます。

展開・移行時に注意すべきポイント

この更新は「新しいAPIが使えるようになる」だけでなく、Copilotエージェント管理の運用設計を見直すきっかけになります。特に次の点は、展開前に整理しておくべきです。

管理対象の定義をそろえる

まず、「アプリ」「エージェント」「パッケージ」という言葉の使い分けをチーム内でそろえてください。Microsoft LearnのPackage Management APIでは、組織カタログ内のエージェントまたはMicrosoft 365アプリをpackageとして扱うと説明されています。(Microsoft Learn)

現場では、Teamsアプリ、Outlookアドイン、Copilotエージェント、LOBアプリを別々に管理していることがあります。しかしAPI上は同じ管理対象として見える範囲が広がるため、棚卸し台帳も統合した方が運用しやすくなります。

いきなりブロック運用に使わない

API一覧にはブロック、ブロック解除、所有者再割り当てが含まれます。Block APIはCopilot packageの使用を防ぐためのAPIで、成功時には204 No Contentを返すと説明されています。(Microsoft Learn)

ただし、最初から自動ブロックに使うのは危険です。TeamsやOutlookで業務に使われているアプリを誤って止めると、問い合わせや業務停止につながります。

安全な展開順は次のとおりです。

フェーズやること
読み取り検証APIで一覧と詳細を取得し、管理センターの表示と突き合わせる
台帳化重要項目をレポート化し、所有者・利用部門を確認する
リスク分類外部製、全社展開、機密関連、所有者不明を抽出する
承認フロー整備ブロック、解除、再割り当ての判断者を決める
変更操作の試行検証環境または限定対象で実行し、影響を確認する
本番運用ログ、通知、ロールバック手順を整えて運用する

所有者不明・退職者所有のエージェントを洗い出す

Copilotエージェントやカスタムアプリの数が増えると、作成者や所有者が退職・異動したまま残るケースが出ます。Reassign APIでは、Copilot packageの所有権を別ユーザーへ再割り当てできると説明されています。(Microsoft Learn)

所有者が不明なエージェントは、更新停止、問い合わせ先不明、セキュリティレビュー漏れの原因になります。APIで棚卸しを行う際は、表示名や対応ホストだけでなく、所有者・発行元・最終更新日時も確認し、責任者不明のものを早めに整理してください。

部門展開と全社展開を分けて管理する

Details APIの応答例には、availableTo、deployedTo、allowedUsersAndGroups、acquireUsersAndGroupsが含まれています。(Microsoft Learn) これらは、誰に利用可能か、誰に展開されているかを確認するうえで重要です。

全社展開されているエージェントは便利ですが、機密データや業務プロセスに関わる場合はリスクも大きくなります。次のような基準を設けると判断しやすくなります。

展開範囲推奨する管理レベル
個人または少人数所有者と用途を確認
部門限定部門責任者の承認、利用目的の明文化
全社展開セキュリティレビュー、データ接続確認、変更履歴管理
外部製かつ全社展開ベンダー確認、契約・データ保護条件の確認
機密カテゴリ法務・セキュリティ・情報システム部門の共同確認

よくある失敗と回避策

Microsoft 365 CopilotのGraph API対応は便利ですが、運用設計を誤ると、かえって管理が複雑になります。特に次の失敗に注意してください。

失敗しやすいポイント起きる問題回避策
Copilotだけを棚卸し対象にするTeamsやOutlookで使われるアプリを見逃す対応ホストを軸に横断的に見る
ReadWrite権限を最初から広く付与する誤変更や過剰権限のリスクが高まる読み取り権限から始める
/beta APIを前提に本番制御を作り込む仕様変更時に処理が止まる監査・棚卸し用途から始める
所有者情報を見ない退職者所有や責任者不明のエージェントが残る所有者・発行元・最終更新日を台帳化する
全社展開を一律に許可する機密情報や外部連携のリスクが増える部門展開、例外承認、定期レビューを導入する
管理センターとAPI結果を突き合わせない想定外の差異に気づけない初期運用ではUI確認も併用する

独自の観点として重要なのは、「エージェントを禁止するか許可するか」だけで判断しないことです。実務では、エージェントの種類、使う部門、接続するデータ、対応ホスト、所有者、展開範囲を組み合わせてリスクを判断する必要があります。APIはその判断材料を集めるための仕組みです。

まず実施すべき確認チェックリスト

今回の更新に対応するために、管理者は次の順で確認するとスムーズです。

優先度確認項目目的
高Roadmap ID 502875とメッセージセンターの内容を確認自社テナントへの反映状況を把握する
高Microsoft Agent 365ライセンスの有無を確認API利用条件を満たすか確認する
高AI adminまたはGlobal adminロールを確認API実行に必要な管理権限を整理する
高CopilotPackages.Read.Allで読み取り検証棚卸しに必要な最小権限を確認する
中Copilot、Teams、Outlook、M365のホスト別に一覧化影響範囲を横断的に把握する
中外部製、全社展開、所有者不明を抽出優先的にレビューすべき対象を決める
中Details APIで詳細メタデータを取得感度、カテゴリ、許可範囲、要素詳細を確認する
低ブロック、解除、再割り当ての運用ルールを整備変更操作を安全に行う準備をする

最初のゴールは、すべてを自動制御することではありません。まずは「何が存在し、誰に使われ、どのホストで動き、誰が責任を持つのか」を見える化することです。そのうえで、部門展開、全社展開、外部製アプリ、機密データに関わるエージェントを優先してレビューしてください。

まとめ：Copilotエージェント管理はAPI前提の運用へ進む

Microsoft 365 Copilotの「Microsoft Graph APIs for App & Agent Inventory and Details」は、Copilot時代のアプリ/エージェント管理をAPIで支えるための重要な更新です。Inventory APIで全体を棚卸しし、Details APIで個別のリスクや展開状態を確認できるようになることで、管理者は手作業に頼らず、監査・レポート・ガバナンスを継続的に回しやすくなります。

一方で、公式ドキュメント上ではPackage Management APIがプレビュー扱いであり、/beta APIの変更可能性、Microsoft Agent 365ライセンス、AI adminまたはGlobal adminロール、Graphのアクセス許可を事前に確認する必要があります。(Microsoft Learn)

次に取るべき行動は明確です。まず読み取り専用でアプリ/エージェントの棚卸しを行い、Copilot、Teams、Outlook、M365にまたがる利用実態を台帳化してください。その後、所有者不明、外部製、全社展開、機密カテゴリの対象を優先的にレビューし、必要に応じてブロック、解除、所有者再割り当ての運用ルールを整備するのが安全な進め方です。

Copilot
Teams Microsoft Graph Microsoft 365 Copilot Agent 365 Copilot管理

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次