Copilot Studio監査ログ更新を解説｜Microsoft Purview Auditの影響と管理者対応

Microsoft Copilot Studioを運用していても、「誰がエージェントを公開・共有したのか」「認証設定やプラグインが変更されたか」「利用者の会話をどこまで確認できるか」が曖昧では、インシデント発生時に十分な証跡を確保できません。

2026年7月8日付の更新情報で重要なのは、新しい監査機能を一律に有効化することではなく、Copilot Studioの管理・作成・利用アクティビティをMicrosoft Purview Auditでどこまで追跡できるのかを再確認することです。

Copilot Studio側の管理アクティビティ収集は既定で有効ですが、テナント全体のMicrosoft Purview監査が無効になっていると、監査検索やAPI、Microsoft Sentinelではログを利用できません。また、Purview Auditで確認できるのは主に操作のメタデータであり、会話本文が常に含まれるわけではありません。(Microsoft Learn)

この記事では、監査対象、管理者が確認すべき設定、検知ルールへの影響、優先して実施すべき対応を具体的に整理します。

Microsoft Copilot Studio / Microsoft Purview Auditの監査ログ更新とは

Microsoftの公式ガイダンスでは、Copilot Studioに関する監査対象が、次の3つの視点で整理されています。

• 管理者によるエージェントや環境の管理
• 作成者によるエージェント、コンポーネント、AIプラグインなどの変更
• 利用者によるエージェントとの対話

今回のポイントは、単に「監査ログが記録される」と理解するのではなく、どの操作が、どのサービスに、どの粒度で記録されるかを切り分けることです。

特に注意したいのは、次の違いです。

• Copilot Studioの操作ログはMicrosoft Purview Auditで確認する
• 会話本文はPurview Auditの監査レコードとは別に扱われる
• Microsoft Entra Agent IDの認証アクティビティはMicrosoft Entra ID側で確認する
• Microsoft Sentinelで検知するには、Purview監査ログの取り込みと分析ルールが必要になる

監査ログは、エージェントの公開や共有を直接防ぐ機能ではありません。誰が、いつ、何を変更したかを後から検知・調査するための証跡です。公開範囲やデータ利用を制限する予防的な統制とは分けて設計する必要があります。

対応が必要かを最初に判断する

次のいずれかに該当する組織は、今回のガイダンスを受けて設定と運用を確認すべきです。

現在の状況	対応要否	最初に確認すること
Copilot Studioを本番利用している	必要	Purview Auditで実際にログを検索できるか
監査ログを一度も確認していない	最優先	テナント監査の有効状態とテストイベント
Microsoft 365 Business系ライセンスを中心に利用している	最優先	統合監査ログが有効になっているか
Microsoft SentinelでCopilotを監視している	必要	ログ取り込み、パーサー、分析ルール
プロンプトや回答本文を調査したい	必要	DSPM for AIと保持ポリシー
Copilot Studioを検証環境でしか利用していない	推奨	本番展開前のログ確認手順
FedRAMP環境を利用している	個別確認	本ガイダンスの前提外となるため、環境固有の対応

Microsoft 365 Business Basic、Business Standard、Business Premiumなどの一部環境や、管理されていない試用テナントでは、監査が既定で有効になっていない場合があります。「Microsoft 365では監査が既定で有効」と思い込まず、実際の状態を確認することが重要です。(Microsoft Learn)

Microsoft Purview Auditで監査できるCopilot Studioの範囲

エージェントの作成・削除・設定変更

Copilot Studioでは、エージェントのライフサイクルや主要な設定変更が監査対象になります。

分類	主なアクティビティ	実務上確認できること
作成・削除	BotCreate、BotDelete、BotDeleteCleanup	エージェントを作成・削除した利用者と時刻
名前変更	BotUpdateOperation-BotNameUpdate	エージェント名の変更
認証設定	BotUpdateOperation-BotAuthUpdate	認証方式に関する変更
公開	BotUpdateOperation-BotPublish	エージェントの公開操作
共有	BotUpdateOperation-BotShare	共有設定の変更
アイコン	BotUpdateOperation-BotIconUpdate	表示アイコンの変更
Application Insights	BotAppInsightsUpdate	テレメトリ設定の変更

セキュリティ上は、名前やアイコンの変更よりも、認証設定、公開、共有、Application Insights設定の変更を優先して監視すべきです。これらはエージェントの利用範囲や認証経路、調査可能性に影響するためです。

コンポーネント、AIプラグイン、環境変数

エージェント本体だけでなく、動作を構成する要素も監査対象です。

対象	主なアクティビティ
エージェントコンポーネント	BotComponentCreate、BotComponentUpdate、BotComponentDelete
コンポーネントコレクション	BotComponentCollectionCreate、BotComponentCollectionUpdate、BotComponentCollectionDelete
AIプラグイン	AIPluginOperationCreate、AIPluginOperationUpdate、AIPluginOperationDelete
環境変数	EnvironmentVariableCreate、EnvironmentVariableUpdate、EnvironmentVariableDelete

特にAIプラグインと環境変数は、外部サービスとの連携やエージェントの挙動に影響し得ます。変更申請のない更新や、通常とは異なる作成者による変更を検知対象にすると効果的です。

公式ガイダンスでは、エージェント、コンポーネント、AIプラグイン、環境変数に関する具体的な操作名が公開されています。(Microsoft Learn)

利用者とエージェントの対話

利用者がエージェントに質問し、回答を表示した操作は、主にCopilotInteractionとして記録されます。

監査レコードには、次のような情報が含まれます。

• 操作日時
• 組織ID
• 利用者またはリソースの識別情報
• 操作名
• 会話を関連付けるスレッドID
• 利用されたチャネルを示すAppHost

ただし、Purview Auditの監査検索結果には、通常、質問文や回答文の全文は含まれません。監査ログから分かるのは、誰が、いつ、どのエージェントと対話したかを示すメタデータが中心です。

また、一部のチャネルは監査対象外となる場合があります。チャネルごとの対応状況を検証し、記録されるイベントではAppHostを確認してください。(Microsoft Learn)

管理者が理解すべき「2つの有効化」

Copilot Studioの監査で最も誤解しやすいのが、Copilot Studio側の収集と、Microsoft 365テナント側の監査を混同することです。

Copilot Studio側のアクティビティ収集

Copilot Studioの管理アクティビティ収集は、テナントで既定により有効です。この収集自体は無効化できないと案内されています。

ただし、これだけで管理者がログを検索できるとは限りません。

Microsoft Purviewのテナント監査

Microsoft Purview側では、テナント全体の監査を無効化できます。無効になっている場合、次の機能から監査データを利用できません。

• Microsoft Purviewの監査検索
• Search-UnifiedAuditLog
• Office 365 Management Activity API
• Microsoft Sentinelによる監査ログの取り込み

つまり、Copilot Studioがイベントを発生させていても、テナント監査が無効なら、運用担当者やSOCが利用できる監査証跡にはなりません。(Microsoft Learn)

PowerShellで監査状態を確認する

Exchange Online PowerShellで、次のコマンドを実行します。

Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled

結果の見方は次のとおりです。

• True：統合監査ログが有効
• False：統合監査ログが無効

無効だった場合は、組織の変更管理手順に従って次のコマンドで有効化します。

Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true

この確認コマンドはExchange Online PowerShellで実行してください。Microsoftの案内では、Security & Compliance PowerShellで同じ確認を行うと、正しい有効状態を取得できない場合があります。

監査を有効化してから反映されるまでに時間がかかることがあります。また、発生したイベントが監査検索で確認できるようになるまで数時間かかる場合があるため、テスト直後に「記録されていない」と判断しないようにしてください。(Microsoft Learn)

監査ログに会話本文は含まれるのか

Purview AuditでCopilotInteractionを検索しても、質問文と回答文の全文がそのまま表示されるわけではありません。

各サービスの役割は次のように整理できます。

サービス	主に確認できる情報	主な用途
Microsoft Purview Audit	操作日時、利用者、操作名、エージェントID、スレッドIDなど	操作の追跡、インシデント調査
DSPM for AI	会話テキストやアクセスされたリソースへの関連情報を取得できる場合がある	AI利用内容の可視化、データリスク調査
Microsoft Entra ID	Agent IDなどの認証アクティビティ	不正認証、サインイン調査
Microsoft Sentinel	取り込んだログの相関分析とアラート	SOC監視、継続的な検知

Copilot Studioの公式ガイダンスでは、Purview Auditには会話本文ではなくスレッドIDが記録され、DSPM for AIが関連するチャットテキストやアクセスリソースの取得を試みると説明されています。したがって、「Purview Auditを有効にしたから、すべてのプロンプトと回答を確認できる」と考えるのは誤りです。(Microsoft Learn)

監査ログの保持と会話本文の保持は別に考える

Purview Audit Standardの監査レコードは、現行のMicrosoft公式情報では原則として180日間保持されます。より長期間保存する場合は、利用しているライセンスと監査保持ポリシーを確認する必要があります。(Microsoft Learn)

一方、利用者とエージェントのメッセージ本文を保持したくない場合は、Purview Data Lifecycle Managementで「Microsoft Copilot Experiences」を対象とした0日保持ポリシーを設定する方法が案内されています。(Microsoft Learn)

ここで重要なのは、次の違いです。

• テナント監査を無効化すると、Copilot Studio以外を含む監査・API・Sentinel連携にも影響する
• 0日保持ポリシーは、利用者やエージェントのメッセージ本文を保持しないための選択肢
• 監査レコードと会話本文では、保存目的と保持設定が異なる

プライバシー対策を理由にテナント全体の監査を無効化するのではなく、必要な証跡と会話本文の保持要件を分けて判断してください。

Microsoft Entra Agent IDの認証ログも確認する

Microsoft Entra Agent IDを持つエージェントでは、認証アクティビティがMicrosoft Entra ID側にも記録されます。

Microsoftは2026年7月以降、新しく作成するCopilot StudioエージェントにMicrosoft Entra Agent IDを使用する方針を案内しています。既存エージェントでは従来のアプリ登録が使われている場合もあるため、エージェントごとに認証方式を確認してください。(Microsoft Learn)

インシデント調査では、次のようにログを相関します。

1. Purview Auditでエージェントの認証設定変更を確認する
2. BotUpdateOperation-BotAuthUpdateの実行者と時刻を特定する
3. 同じ時間帯のEntra ID認証ログを確認する
4. Agent ID、利用者、IPアドレス、認証結果を突き合わせる
5. 直後の公開・共有操作や利用者との対話を確認する

Purviewだけを見ると「設定が変更されたこと」までしか分からないケースでも、Entra IDのログと組み合わせることで、変更前後の認証アクティビティを調査しやすくなります。

監査・検知ルールに与える影響

1回の操作が複数イベントとして記録されることがある

Copilot Studioの監査ログはSDKレイヤーで記録されるため、利用者による1回の操作から複数の監査イベントが発生する場合があります。(Microsoft Learn)

そのため、監査イベントの行数をそのまま次の指標として使用するのは適切ではありません。

• 実際の操作回数
• エージェントの利用回数
• ユニークな質問数
• 作成者の作業量

検知ルールでは、単純な件数だけでなく、次の項目を組み合わせて相関してください。

• UserKey
• BotId
• Operation
• CreationTime
• ThreadId
• 短い時間帯に発生した関連イベント

たとえば、「同じ利用者が10分以内に認証設定を変更し、その後エージェントを公開した」という一連の操作として評価する方が、イベント件数だけを見るよりも実用的です。

優先して検知したい操作

以下は、公式に必須とされている検知ルールではありませんが、実務上の優先度が高い組み合わせです。

優先度	検知対象	検知例
高	認証設定の変更	承認されていない作成者によるBotAuthUpdate
高	共有と公開	BotShareの直後にBotPublishが実行された
高	AIプラグイン	リリース時間外の作成・更新
高	環境変数	通常と異なる利用者による更新
高	削除	本番エージェントのBotDeleteまたはBotDeleteCleanup
中	Application Insights	監視設定が変更された
中	コンポーネント	短時間に大量の更新・削除が発生した
中	利用者との対話	特定利用者による急激な対話増加

検知条件には、単なるしきい値だけでなく、エージェントの重要度、作成者の役割、変更申請の有無、通常のリリース時間帯を組み込むと誤検知を減らせます。

Microsoft Sentinelでは取り込みとルール作成が必要

Microsoft Sentinelを利用していても、Copilot Studioの危険な操作が自動的に適切なアラートになるとは限りません。

運用では、次の確認が必要です。

• Purview監査ログがSentinelに取り込まれているか
• Copilot Studioの操作名がパーサーで保持されているか
• BotIdやUserKeyなどのフィールドを検索できるか
• 認証変更、公開、共有、削除を対象とした分析ルールがあるか
• テストイベントでアラートが発火するか

Microsoftの監視ガイダンスでも、SentinelでCopilot Studioを監視するには、Purview監査ログの取り込みとカスタム検知ルールの構成が必要とされています。(Microsoft Learn)

優先して実施すべき対応

最優先：テナント監査の有効状態を確認する

まず、PowerShellまたはPurviewポータルで監査が有効か確認します。

Purviewポータルでは、必要な監査権限を持つ管理者が「ソリューション」から「監査」を開き、Copilot Studio関連のアクティビティを検索します。(Microsoft Learn)

監査が無効だった場合は、Copilot Studioだけでなく他のMicrosoft 365監査にも影響するため、変更管理とセキュリティ担当者の承認を得て有効化してください。

次に実施：非本番環境でログを発生させる

設定画面を見ただけで確認を終えず、実際のイベントを使ってエンドツーエンドで検証します。

安全なテスト例は次のとおりです。

1. 非本番環境にテスト用エージェントを作成する
2. エージェント名を変更する
3. テスト利用者に共有する
4. エージェントを公開する
5. テスト利用者が1回対話する
6. 数時間後にPurview Auditでイベントを検索する
7. Sentinelを利用している場合は取り込みとアラートを確認する

確認すべき結果は次のとおりです。

• BotCreateが記録されている
• 名前変更、共有、公開の各イベントが確認できる
• 実行者と時刻が一致している
• BotIdで同じエージェントを追跡できる
• 利用者の対話がCopilotInteractionとして確認できる
• ThreadIdとAppHostが取得できる
• Sentinel側でも必要なフィールドが欠落していない

会話本文の保持方針を決める

セキュリティ部門だけで判断せず、法務、コンプライアンス、個人情報保護、業務部門を含めて次の要件を整理します。

• インシデント調査で会話本文が必要か
• 機密情報を含む会話を保存してよいか
• 保存する場合の保持期間
• 誰に閲覧権限を与えるか
• eDiscoveryや訴訟対応の対象になるか
• 0日保持ポリシーを適用すべきエージェントや利用者範囲

会話本文を残さないことは情報漏えい時の影響を抑えますが、調査時に内容を確認できなくなるというトレードオフがあります。一律に0日保持を適用するのではなく、用途とリスクに応じて決定してください。

監査対象外となる経路を記録する

一部チャネルが監査対象外になる可能性があるため、エージェントごとに次の情報を台帳化します。

• 利用しているチャネル
• Purview Auditへの記録可否
• AppHostの値
• 会話本文の取得可否
• 認証方式
• Microsoft Entra Agent IDの有無
• Sentinelでの監視可否
• 代替ログの保存場所

監査できない経路がある場合は、利用を禁止する、対象者を限定する、別のログで補完するなどの対応が必要です。

よくある失敗と注意点

「既定で有効」を確認済みとみなす

Copilot Studio側の収集が既定で有効でも、Purviewのテナント監査やSentinel連携まで正常とは限りません。設定値とテストイベントの両方で確認してください。

Purview Auditで会話全文を検索しようとする

Purview Auditの中心は操作メタデータです。会話本文が必要な場合は、DSPM for AI、保持ポリシー、対象チャネルを含めて設計する必要があります。

イベント行数を利用回数として集計する

1回の操作から複数イベントが発生する可能性があります。利用状況を集計する場合は、利用者、スレッドID、時刻などで重複を整理してください。

プライバシー対策としてテナント監査を無効化する

テナント監査を無効化すると、Copilot Studio以外のMicrosoft 365監査、API、Sentinel連携にも影響します。会話本文を保持しない目的であれば、Data Lifecycle Managementの保持ポリシーを検討します。

Sentinelへの取り込みだけで完了と考える

ログを取り込んでも、操作名やエージェントIDを使った分析ルールがなければ、有害な変更を見逃します。公開、共有、認証、プラグイン、環境変数、削除を中心にテストしてください。

まず実施すべきこと

今回の監査ログガイダンスを受けて、管理者が最初に行うべきことは次の3点です。

1. UnifiedAuditLogIngestionEnabledを確認し、Purview Auditで検索できる状態にする
2. 非本番エージェントで作成、共有、公開、対話のテストイベントを発生させる
3. 会話本文の保持要件と、Sentinelで優先検知する操作を決定する

特に重要なのは、「設定上は有効」ではなく、実際の操作がPurviewからSentinelまで届き、必要な担当者が調査できることを確認することです。

まずは非本番環境で、エージェントの公開または共有と1回の利用者対話を実行し、Purview Auditに必要なイベントと識別情報が記録されるか確認してください。