Microsoft Purview・Power Automate・Copilot StudioでAI GRCエージェントを構築：コンプライアンス報告を自動化

ガバナンス・リスク・コンプライアンス(GRC)のレポート作成は、多くの組織で今も手作業に頼っています。監査ログをExcelに貼り付け、フィルターをかけ、ピボットテーブルを増やしていくうちに、タブ同士の数字が食い違い始めます。コンプライアンスは本来、組織を守るための仕組みです。それが、監査人を安心させるためのデータとの格闘になってしまっているケースは少なくありません。

この記事では、Microsoft Purview、Power Automate、Copilot Studioを組み合わせたルール駆動型のGRCエージェントの作り方を整理します。ログの取得からレポートのスケジュール配信まで、すべてMicrosoftのエコシステム内で完結する構成です。

手作業のGRCレポートが抱える問題

手作業のレポートは、文書化を洞察と取り違えた結果になりがちです。Purviewからデータを抽出し、エクスポートしてスプレッドシートに広げても、翌週には新しい活動が発生してデータが変わります。先週まで完璧だったグラフは、すぐに古い情報になります。説明責任のための監査証跡が、担当者の燃え尽きを招くことさえあります。

多くの企業はPurviewを金庫のように扱い、監査の直前になって初めて開けます。監査ログには、誰がいつ、どこで、何をしたかというデータが大量に蓄積されています。有用であることは間違いありませんが、各エントリーは密度の高いJSONの塊で、人間が読むのは現実的ではありません。データは溢れているのに、読み取れないのです。

GRCエージェントの正体:3つのコンポーネントの役割分担

ここでいうGRCエージェントは、答えを推測する魔法のAIではありません。Microsoftのツール群の上に構築した、構造化された自動化です。3つのコンポーネントが、それぞれ異なる役割を担います。

• Microsoft Purview(記憶):監査ログ、分類データ、コンプライアンスイベントを提供する「信頼できる情報源」です。Microsoft 365上のユーザー操作、ドキュメント共有、ポリシー作成、保持ラベルの変更などが記録されます。
• Power Automate(神経系):シグナルを集め、ノイズを除き、決められた時刻に処理を実行します。たとえば毎日午前8時に、コネクタを呼び出してPurviewの最新アクティビティを取得できます。
• Copilot Studio(口・翻訳者):構造化データを、人間が読める文章に変換します。

コンプライアンス業務の大部分は、判断ではなくパターン認識です。活動の種類や結果ステータスの列を眺める作業は、自動化で瞬時に分類・要約できます。このアプローチが機能するのは、システムに人間のように考えさせるのではなく、人間より整理が得意になるように作られているからです。

この構成は決定論的でもあります。ロジック、頻度、対象範囲、文章のトーンまで、すべて設計者が定義します。自律性とは、ランダムなものではなく、言語能力を備えた規律ある自動化のことです。

Purview監査データのパイプラインを構築する

エージェントに考えさせる前に、まず見えるようにする必要があります。つまり、Purview監査ログの適切な部分だけにアクセスできるデータパイプラインを作ります。

ステップ1:抽出と範囲の絞り込み

抽出には、Purviewの組み込みコネクタを使う方法と、HTTPアクションで監査ログAPIを直接呼び出す方法があります。どちらでも、テナント内のファイル共有、権限変更、アクセス違反、管理者ログインなどのデータストリームが得られます。

ただし、全監査フィードを取得するのは得策ではありません。コンプライアンスに実際に影響するイベントを定義し、早い段階で範囲を絞りましょう。そうしないと、フロー自体が扱いきれなくなります。

ステップ2:アクセス制御

Power Automateは、与えられた権限の範囲内でしか動作しません。サービスアカウントにはPurviewの監査ログ閲覧者ロールを付与し、多要素認証(MFA)による中断なしで認証できるようにします。資格情報はAzure Key Vaultや接続参照に保存すると、自動化を維持しながらコンプライアンスも守れます。

ステップ3:フィルタリング

本当に必要なのは、リスクの識別に関わるイベントです。たとえば次のようなものです。

• 新しい場所からのログイン
• 役割割り当ての変更
• 外部共有の実行
• ラベルポリシーの修正

フィルタリングは、APIパラメータでクエリ段階で行っても、Power Automate内の条件ロジックで後処理しても構いません。重要なのは、ペイロードを管理しやすい大きさに保つことです。

ステップ4:JSONの解析と保存

次に、JSONをCopilotが解釈できる構造化された項目に変換します。サンプルイベントから作ったスキーマを使い、「JSONの解析」アクションを用います。ユーザーID、操作、ワークロード、結果ステータス、クライアントIPなどが、それぞれ独立した変数になります。

監査フィールドには、単一の値でも配列で表されるものや、結果が3層のネストの奥に隠れているものがあります。これらはPower Automateの式で処理します。ここでの小さなタイプミスは、後で意味のない結果を生みます。小さなサンプル実行で、抽出ごとにテストしておきましょう。

整形したデータは、規模に応じてSharePoint、Dataverse、SQLデータベースのいずれかに保存します。これは短期記憶として働き、Purviewに繰り返し負荷をかけずに過去との比較ができます。列機能やデータセット間の関連付けが必要ならDataverseが相性が良く、SharePointは手軽ですが数千行を超えると扱いにくくなります。

ステップ5:スケジュールとエラー対応

定期実行トリガーで頻度を決めます。変化の激しい環境なら日次、穏やかな環境なら週次でも足ります。タイムゾーンはUTCではなく自分の環境に合わせましょう。リトライポリシーとフォールバックも用意します。エラーはログに書き込み、しきい値を超えたらTeamsへ通知します。監査人が問題にするのはエラーそのものではなく、記録の欠落です。

Power Automateで判断ロジックを組む

Power Automate自体はAIではありません。推測もしなければ、手順を忘れも省略もしません。その予測可能な厳格さが、自律性の土台になります。

フローの基本構造

1. 定期実行トリガーで起動する(監査人のタイムゾーンに合わせる)
2. 初期化ブロックで、イベント総数、高リスク件数、レポート日などの変数を用意する
3. Purview監査ログのコネクタまたはHTTP APIを呼び出す
4. 配列のフィルターで不要なデータを除く(サービスプリンシパルのレコードを無視し、データガバナンスやポリシー変更に関する操作だけを残す、など)
5. 重複を排除する
6. ユーザープリンシパル名と操作でグループ化し、カテゴリごとに集計する

リスクレベルの判定

あらかじめ定義したしきい値に従って、システムがリスクレベルを判定します。たとえば特権昇格が3回なら「高」、外部共有が1回なら「中」、それ以外は「標準」です。このロジックは意味を作り出すものではなく、ルールを機械的に適用するものです。人間の直感が、数値による明確な基準に置き換わります。

入れ子の条件アクションでは、高リスクのユーザーを専用の配列に追加し、中リスクならレビュー用の通知を送る、といった分岐を組めます。異常がない場合は、何も返さずに終わらせず、「検出なし」というメッセージを記録します。データの欠落とデータなしの区別は、コンプライアンスでは不可欠です。

実行の証拠を残す

HTTP呼び出しは、再試行ポリシーを有効にしたスコープで囲みます。設定例は、3回の試行と指数バックオフです。失敗時のブランチでは、エラーメッセージ、タイムスタンプ、フロー実行IDを、SharePointリストやDataverseのテーブルに記録します。

各実行の最後には、処理した総イベント数、最大リスクユーザー、実行時間などのメトリクスを保存し、Teamsチャンネルや管理用のSharePointライブラリにも流します。実行IDとフローのバージョンも含めておくと、後でしきい値が変わっても、どのロジックがどの結果を導いたかを追跡できます。

Copilot Studioでレポートを文章化する

ここまでのエージェントは有能ですが、何も語りません。Copilot Studioがこれを、人間に分かる言葉へ翻訳します。

レポートの種類とプロンプト設計

まず、どんな伝え方が必要かを定義します。通常は、エグゼクティブサマリー、技術付録、推奨事項の3つです。経営層は一段落の要約を求め、監査人は証拠の追跡を必要とし、IT部門はすべてのフィールドを求めます。Copilot Studioでは1つのエクスペリエンスの中に複数のプロンプトを作り、トーン、フォーマット、詳細度を使い分けます。

接続は、フロー内のHTTPアクションで、構造化したJSONペイロードをCopilotのエンドポイントURLへ送る形で行います。呼び出しはAzure ADで認証されるため、アクセスできるのは自分のフローだけです。戻ってくるのは数値ではなくテキストで、それがそのままレポートになります。

出力の例としては、次のような内容が考えられます。高リスクの行動をしたユーザーと、その内容を示す。重大度別に整理し、所見ごとに推奨アクションを1つ添える。ベースラインと比較した全体傾向で締める。これは生成AIの自由な推測ではなく、決定論的なプロンプトに沿った整形済みの要約です。Copilotは統計をナレーションしているにすぎません。

ガードレールと検証

• 見出しを指定する:「概要」「重要な所見」「推奨事項」のように、使う見出しを明示します。
• トーンを固定する:専門的で中立的な表現、推測的な言い回しの回避、定量的な指標の記載を指示に含めます。
• コンテキスト変数を使う:レポートの日付や分析したイベント件数をプレースホルダーとして埋め込むと、フロー実行時に自動で解決されます。
• 応答を検証する:Copilotの応答が空でないかを条件でチェックし、空ならエラーを記録して1回だけ再処理します。

指示が厳密なほど、出力の再現性は高まります。コンプライアンスを支えるのは個性ではなく、再現性です。

配布とプロンプトのバージョン管理

同じフローから2つのブランチを作ります。1つはCopilotの要約をTeamsチャンネルに直接投稿し、もう1つは完全なHTML版をSharePointに保存します。管理職はTeamsで読み、監査人はアーカイブを確認できます。どちらにも自動でタイムスタンプが付き、同じ文面で届きます。

コンプライアンス基準が変わるたびに、CopilotのシステムプロンプトにV1、V2のようなバージョンを付け、どのバージョンがどのレポートを作ったかを記録します。将来の監査で、当時のナレーションがどんな指示のもとで作られたかを確認できます。

見落としやすいつまずきポイント

• 権限不足による「問題なし」:サービスアカウントに監査ログ閲覧者ロールがないと、エージェントは何も見えないまま「問題なし」と報告します。初期テストでこの状況に遭遇した例もあります。これは安心ではなく、成功を装った盲目状態です。
• MFAの壁:自動化は深夜に認証プロンプトへ対応できません。中断なしで認証できる設計が必要です。
• 範囲を絞らない取得:全フィードを取り込むと、フロー自体が処理しきれなくなります。
• JSON構造の読み違い:単一値の配列や深いネストを見落とすと、後工程で意味のない結果になります。
• タイムゾーンの設定漏れ:UTCのままだと、想定外の時刻にレポートが届きます。
• プロンプトの指定不足:見出しやトーンを指定しないと、体裁がばらつき、監査レポートに不向きな表現が混ざります。
• 「検出なし」を記録しない:データの欠落と、異常がなかったことの区別がつかなくなります。

実践のポイントとまとめ

• Purviewを情報源、Power Automateを実行基盤、Copilot Studioを文章化担当として役割を分ける。
• サービスアカウントには監査ログ閲覧者ロールを付与し、MFAで中断されない認証を用意する。資格情報はAzure Key Vaultなどに保管する。
• 取得するイベントは、リスクに関わるものに限定する。
• JSONはスキーマで解析し、小さなサンプルで各抽出をテストする。
• リスクレベルは、「特権昇格3回で高」のような明確なしきい値で判定する。
• 再試行ポリシー(3回、指数バックオフ)とエラーログ、Teams通知を組み込む。
• 実行ID、フローのバージョン、プロンプトのバージョンを記録し、後から追跡できるようにする。
• プロンプトには見出し、トーン、定量指標を明記し、応答の空チェックも入れる。

Purviewが収集し、Power Automateが解釈し、Copilot Studioが要約する。この流れができれば、GRCレポートは監査前の駆け込み作業ではなく、継続的に動く仕組みになります。最大の利点はスピードより標準化です。毎回同じトーン、同じしきい値、同じメタデータでレポートが届くので、監査担当者はフォーマットの確認ではなく内容の評価に時間を使えます。担当者の休暇で監査証跡が途切れる脆いプロセスから、時計仕掛けのように動くオーケストレーションへ。その転換こそが、このGRCエージェントの価値です。