WEBVTT 00:00:00.040 --> 00:00:03.820 ガバナンス、リスク、コンプライアンスのレポート、いわゆるGRCについて話しましょう。 00:00:03.940 --> 00:00:08.100 この3文字は、あらゆるSARSの監査を合わせたものよりも多くのカフェイン摂取を引き起こしています。 00:00:08.260 --> 00:00:13.120 今この瞬間も、どこかの哀れなアナリストが、2003年当時にマクロが魔法だと思われていたかのように、 00:00:13.480 --> 00:00:15.320 Excelのセルに監査ログをコピーし続けています。 00:00:15.520 --> 00:00:18.600 最初は良い意図で、整理されたブックといくつかのフィルターから始めますが、 00:00:18.900 --> 00:00:21.700 最後には互いに矛盾する40ものピボットテーブルのタブであふれ返ります。 00:00:21.880 --> 00:00:25.520 本来は保護手段であるはずのコンプライアンスが、もはやパフォーマンスアートと化しています。 00:00:25.600 --> 00:00:29.560 すべてが管理下にあると監査人に安心してもらうため、何時間もデータを格闘するのです。 00:00:29.680 --> 00:00:31.980 ネタバレすると、ほとんどの場合、管理下になんてありません。 00:00:32.100 --> 00:00:36.600 手作業のGRCレポートとは、組織が、文書化、を、洞察と勘違いした結果に他なりません。 00:00:36.760 --> 00:00:41.900 マイクロソフトパービューからデータを抽出し、エクスポートしてスプレッドシートに引き伸ばし、それをガバナンスと呼ぶのです。 00:00:42.080 --> 00:00:47.840 翌週には新たな活動があり、データが変化し、先週まで完璧だったグラフが、グラデーションで彩られた嘘に早変わりします。 00:00:48.020 --> 00:00:51.580 説明責任を果たすはずの監査証跡が、結局は担当者の燃え尽きを招くことになります。 00:00:51.580 --> 00:00:56.240 さらに悪いことに、多くの企業はパービューを金庫のように扱い、監査の直前になって初めてこじ開けるのです。 00:00:56.380 --> 00:01:00.500 その監査ログは、誰がいつどこで何をしたかというテラバイト級のデータを静かに蓄積し続けています。 00:01:00.700 --> 00:01:01.400 有用かって? 00:01:01.580 --> 00:01:02.660 間違いなく有用です。 00:01:02.820 --> 00:01:03.640 読みやすいかって? 00:01:03.820 --> 00:01:04.600 ほとんど読めません。 00:01:04.780 --> 00:01:07.600 各エントリーは、光さえ歪めそうなほど高密度なJSONの塊です。 00:01:07.780 --> 00:01:12.080 週末が不要で、正気を失っても構わないのなら、手動で解析することも可能でしょう。 00:01:12.080 --> 00:01:15.820 さて、この不条理をAIエージェントのアイデアと対比させてみてください。 00:01:16.000 --> 00:01:22.840 それは単に答えを推測する魔法のコパイロットではなく、マイクロソフトのツール群で構築されたルール駆動型の自動化エージェントです。 00:01:22.840 --> 00:01:31.600 自然言語インテリジェンスのためのコパイロットスタジオ、タスクオーケストレーションのためのパワーオートメート、そして監査の信頼できる情報源としてのパービュー。 00:01:31.600 --> 00:01:40.660 言い換えれば、コンプライアンスチームがずっと望んでいたこと、つまりデータの取得、分析、説明を、ため息をつくことも、マスターのスプレッドシートにコーヒーをこぼすリスクもなしに実行するソフトウェアです。 00:01:40.800 --> 00:01:47.080 不満を言わず、眠らず、JSONを英語のように読むインターンにGRCレポートを該注するようなものだと考えてください。 00:01:47.080 --> 00:01:55.280 この説明が終わる頃には、パービューログの接続からレポートスケジュールの自動化まで、すべてマイクロソフトのエコシステム内で構築する方法を完全に理解できるはずです。 00:01:55.420 --> 00:01:59.780 そして、この単なる自動化を真に自律的な監査担当へと変えるロジックのステップについても解説します。 00:01:59.960 --> 00:02:01.460 まずは、ここに注目してください。 00:02:01.620 --> 00:02:04.000 コンプライアンスは、パフェインの摂取量に依存すべきではありません。 00:02:04.160 --> 00:02:06.940 機械は疲れませんし、別のラベルを間違えることも決してありません。 00:02:06.940 --> 00:02:12.000 このエージェントを監視なしでレポートを送れるほど信頼性の高いものにする、一つの論理レイヤーと宣伝された設計選択があります。 00:02:12.200 --> 00:02:15.540 そこに到達する前に、まずこのエージェントが実際には何であるかを理解しましょう。 00:02:15.680 --> 00:02:21.460 コパイロットスタジオとパワーオートメイトのこの組み合わせが、単なるかっこいい名前のフロー以上の存在たる理由は何でしょうか? 00:02:21.620 --> 00:02:23.880 GRCエージェントの正体についてです。 00:02:24.040 --> 00:02:28.040 AIの花々しさを取り除き、この技術の真の姿を定義しましょう。 00:02:28.260 --> 00:02:32.360 それは、インテリジェンスを装ったマイクロソフトスタック上の構造化された自動化です。 00:02:32.520 --> 00:02:35.720 このGRCエージェントは、3つの頭を持つ生き物のようなものです。 00:02:35.920 --> 00:02:38.600 それぞれの頭が認知プロセスの役割を担っています。 00:02:38.780 --> 00:02:40.880 パービューが生の記憶を提供します。 00:02:41.040 --> 00:02:44.100 監査ログ、分類データ、そしてコンプライアンスイベントです。 00:02:44.100 --> 00:02:46.820 パワーオートメイトは神経系として機能します。 00:02:46.960 --> 00:02:51.020 シグナルを収集し、ノイズを除去し、プロセスを予定通りに実行します。 00:02:51.220 --> 00:02:54.200 そしてコパイロットスタジオが、口であり翻訳者となります。 00:02:54.380 --> 00:02:58.060 ログの技術的な専門用語を、人間が読める要約へと変換します。 00:02:58.260 --> 00:03:02.220 ユーザーが24時間以内に5回権限を昇格し、ポリシーの敷地を超過しました。 00:03:02.380 --> 00:03:04.560 これはJSONではなく、人間が理解できる言葉です。 00:03:04.740 --> 00:03:05.960 真実をお話ししましょう。 00:03:06.160 --> 00:03:09.780 コンプライアンス業務の90%は判断を伴うものではなく、パターン認識です。 00:03:09.860 --> 00:03:14.680 それなのに、分析担当者は何時間もかけて活動の種類や結果ステータスの列を眺めています。 00:03:14.880 --> 00:03:18.700 自動化なら、そうしたパターンを瞬時に分類、要約できるというのに。 00:03:18.700 --> 00:03:24.440 このアプローチが有効なのは、システムが人間のように考えようとするのではなく、人間よりも優れた整理能力を持つように構築されているからです。 00:03:24.620 --> 00:03:26.640 それぞれのコンポーネントを詳しく見ていきましょう。 00:03:26.820 --> 00:03:31.340 マイクロソフトパービューは単なるファイルラベル付けツールではなく、コンプライアンスのブラックボックスです。 00:03:31.520 --> 00:03:37.820 マイクロソフト365条でのあらゆるユーザーアクション、ドキュメントの共有、ポリシー作成、保持ラベルの変更などが記録されます。 00:03:38.000 --> 00:03:41.960 しかし、入れ子状のJSON構造を読み解くスキルがなければ、有益なインサイトは得られません。 00:03:42.120 --> 00:03:43.500 これが根本的な問題です。 00:03:43.660 --> 00:03:45.500 データは溢れているのに、読み取れないのです。 00:03:45.640 --> 00:03:46.800 次にパワーオートメート。 00:03:46.980 --> 00:03:48.740 華やかさはありませんが、規律があります。 00:03:49.000 --> 00:03:52.300 時間通りに実行し、決して忘れず、すべてのステップを厳格に守ります。 00:03:52.500 --> 00:03:57.260 例えば毎日午前8時にスケジュールを設定すれば、コネクタを呼び出してパービューの最新のアクティビティを取得します。 00:03:57.460 --> 00:03:59.820 設定を間違えた時、人間ならパニックになります。 00:03:59.820 --> 00:04:03.860 しかし、ここではフローが静かに停止し、失敗のいきさつを詳細にログへ記録するだけです。 00:04:03.960 --> 00:04:05.620 コンプライアンス部門はログを愛しています。 00:04:05.780 --> 00:04:08.400 パワーオートメートは、それを宗教的なまでの正確さで提供します。 00:04:08.620 --> 00:04:10.020 最後にコパイロットスタジオ。 00:04:10.200 --> 00:04:12.380 構造化されたデータを物語へと変えます。 00:04:12.580 --> 00:04:18.960 ユーザーごとのリスクアクションを集計したJSONテーブルのような構造化データを渡すと、自然言語のリスク要約を出力します。 00:04:19.160 --> 00:04:21.600 ここで、知性という幻想が生まれるのです。 00:04:21.820 --> 00:04:23.260 推測しているわけではありません。 00:04:23.260 --> 00:04:25.860 あなたが設計したプロンプトのルールに従っているだけです。 00:04:26.020 --> 00:04:31.900 例えば重要度別に注目すべきリスク活動を要約し、カテゴリーごとに推奨事項を一つ含める、といった指示です。 00:04:32.060 --> 00:04:36.140 出力結果は分析担当者のメモのように見えますが、実際には文法で着飾ったアルゴリズムの正直な表現です。 00:04:36.280 --> 00:04:38.360 ここで、語られることのない皮肉に触れておきましょう。 00:04:38.520 --> 00:04:43.580 企業は可視性を約束するダッシュボード、見栄えのするレポート、色分けされた指標を購入しますが、それらは説明、押してはくれません。 00:04:43.720 --> 00:04:45.100 ただ、表示、するだけです。 00:04:45.100 --> 00:04:47.460 しかし、このGRCエージェントは記述します。 00:04:47.600 --> 00:04:53.380 パターンを文章へと翻訳し、コンプライアンス審査における無数のニアミスを引き起こしてきた解釈の溝を埋めるのです。 00:04:53.540 --> 00:05:03.200 役員から先月のリスクパターンの報告を求められたとき、信頼しきれないパワーBIのリンクを送るのではなく、コーヒーを入れている朝8時5分にワークフローが自動生成した、明快なレポートを送りましょう。 00:05:03.400 --> 00:05:05.800 なぜ多くのチームはまだこれを行っていないのでしょうか。 00:05:05.940 --> 00:05:08.640 自動化がどれほど読みやすいものになるかを、過小評価しているからです。 00:05:08.780 --> 00:05:11.860 AIは予測不可能だと思われがちですが、このスタックは決定論的です。 00:05:12.040 --> 00:05:13.340 すべてはあなたが定義します。 00:05:13.540 --> 00:05:18.780 ロジック、頻度、範囲、さらには言葉のトーンまでも、自律性とはランダムなものではありません。 00:05:18.980 --> 00:05:21.360 それは、言語スキルを備えた規律ある自動化です。 00:05:21.540 --> 00:05:24.460 しかし、エージェントが考える前に、まずは見せる必要があります。 00:05:24.680 --> 00:05:29.440 つまり、パービュー監査データのうち適切な部分だけにアクセスできるデータパイプラインを構築するということです。 00:05:29.540 --> 00:05:32.400 その可視性がなければ、見えないまま自動化することになります。 00:05:32.400 --> 00:05:37.220 そこで次に、パワーオートメートをパービューに接続し、重要なイベントを定義して、エージェントにどこを見るべきか教えます。 00:05:37.360 --> 00:05:40.060 そうして初めて、何を考えるべきかを教えることができるのです。 00:05:40.200 --> 00:05:45.400 パービューデータパイプラインの構築、GRCエージェントに考えさせる前に、まずは目を与えなければなりません。 00:05:45.600 --> 00:05:47.760 真実の源泉に直接接続するのです。 00:05:47.900 --> 00:05:49.720 マイクロソフトパービューの監査ログです。 00:05:49.900 --> 00:05:53.200 これらのログは、誰がいつ、何を、どのように操作したかを追跡します。 00:05:53.400 --> 00:05:57.260 残念なことに、これらはJSONという、構造的に見て悪夢のような形式で保存されています。 00:05:57.420 --> 00:06:00.420 JSONは、エンジニアにとっての法律用語のようなものだと考えてください。 00:06:00.620 --> 00:06:03.260 技術的には正確ですが、実用上は読めたものではありません。 00:06:03.400 --> 00:06:07.900 パワーオートメートの素晴らしい点は、正しく接続さえすれば、この難解なデータを流暢に読み取れることです。 00:06:08.060 --> 00:06:09.500 ステップ1は抽出です。 00:06:09.500 --> 00:06:16.240 パービューの組み込みコネクタを使うか、苦労を厭わないなら、HTTPアクションでパービュー監査ログAPIを直接呼び出します。 00:06:16.420 --> 00:06:18.560 どちらの方法でも、結果は同じです。 00:06:18.700 --> 00:06:21.840 テナント内で発生したすべてを表すデータストリームが得られます。 00:06:22.000 --> 00:06:26.040 ファイル共有、権限の変更、アクセス違反、管理者のログインなどです。 00:06:26.220 --> 00:06:29.300 より規律あるアプローチは、早い段階で範囲を制限することです。 00:06:29.460 --> 00:06:34.140 確かに全監査フィードを取得することも可能ですが、それはPDFを一つ紛失したためにインターネット全体をバックアップするようなものです。 00:06:34.140 --> 00:06:36.780 コンプライアンスに実際に影響を与えるイベントを定義しましょう。 00:06:36.960 --> 00:06:40.740 さもないと、フローが自らの忍耐力を奪う、意図せぬサービス拒否攻撃のようになってしまいます。 00:06:40.900 --> 00:06:42.300 次に、アクセス制御です。 00:06:42.440 --> 00:06:45.280 パワーオートメイトは、与えられた権限の範囲内でしか動作しません。 00:06:45.440 --> 00:06:51.900 フローのサービスアカウントがパービューの監査ログを読み取れなければ、エージェントは虚空を見つめ、何の問題も見つからなかったと忠実に報告するだけです。 00:06:52.060 --> 00:06:55.560 それは安心材料ではなく、成功を装った盲目状態にすぎません。 00:06:55.560 --> 00:07:02.120 サービスアカウントにパービュー内の監査ログ閲覧者ロールを付与し、MFA、多要素認証による中断なしで認証できるようにしておきましょう。 00:07:02.300 --> 00:07:04.760 AIは従順ですが、創造的ではありません。 00:07:04.960 --> 00:07:08.200 深夜2時にクリックして認証したり、プロンプトに対応したりはできません。 00:07:08.380 --> 00:07:13.880 視覚情報を慎重に割り当て、Azure Key Vaultや接続参照に保存することで、自動化を維持しながらコンプライアンスを遵守できます。 00:07:14.060 --> 00:07:16.760 データ抽出が安定したら、次はフィルタリングです。 00:07:16.760 --> 00:07:21.080 カフェテリアのランチメニューホルダへのアクセスイベントなど、誰が必要とするでしょうか。 00:07:21.180 --> 00:07:24.080 代わりに、真のリスク識別しに焦点を絞りましょう。 00:07:24.320 --> 00:07:29.500 新規場所からのログイン、役割割当ての変更、外部共有の実行、ラベルポリシーの修正などです。 00:07:29.640 --> 00:07:32.580 これらは監査担当者が本当に気にかける内容を物語っています。 00:07:32.780 --> 00:07:38.040 APIパラメータを使用したクエリ段階でフィルタリングするか、パワーオートメート内の条件ロジックで後処理することも可能です。 00:07:38.040 --> 00:07:40.740 いずれにせよ、ペイロードを管理しやすい状態に保つことが重要です。 00:07:40.860 --> 00:07:43.300 溜め込むのではなく、厳選するのだと忘れないでください。 00:07:43.500 --> 00:07:47.840 次に、コピー&ペーストを自動化だと思っている層とプロフェッショナルを分かつ工程に進みます。 00:07:47.980 --> 00:07:48.600 フィードです。 00:07:48.820 --> 00:07:53.740 JSONの塊を、5のコパイロットモジュールが解釈できる構造化された列へと変換します。 00:07:53.940 --> 00:07:59.700 簡単な方法は、パービューイベントのサンプルから抽出した定義済みスキーマを用いて、JSONの解析、アクションを使うことです。 00:07:59.700 --> 00:08:03.900 ネストされた配列という言葉に胸が痛むなら、コンプライアンスコーディングの世界へようこそ。 00:08:04.040 --> 00:08:09.960 ユーザーID、操作、ワークロード、結果ステータス、クライアントIPといった各プロパティが個別の変数になります。 00:08:10.140 --> 00:08:14.420 これは本質的に、対話が始まる前にAIエージェントへ語彙を教えているようなものです。 00:08:14.560 --> 00:08:18.460 この段階で、あなたはマイクロソフトのデータ形式が持つ存在論的なユーモアに気づくでしょう。 00:08:18.640 --> 00:08:22.280 一部の監査フィールドは、単一値しか持たない場合でも配列として提示されます。 00:08:22.460 --> 00:08:27.280 また、曖昧なマトリオーシカのように、結果が3層ものネストの奥深くに隠されているものもあります。 00:08:27.480 --> 00:08:30.400 パワーオートメートは式を使ってこのカオスを処理します。 00:08:30.620 --> 00:08:37.440 各ユーザーIDに適用、といった構文は難解に見えるかもしれませんが、これこそが自動化ツールにJSONを掘り下げて意味を抽出させる方法なのです。 00:08:37.580 --> 00:08:40.620 ここでの些細なタイプミスが、後でとんでもない無意味な結果を生みます。 00:08:40.780 --> 00:08:43.440 ですから、小さなサンプル実行で各抽出をテストしてください。 00:08:43.600 --> 00:08:45.700 A、フローのデバッグは華やかな仕事です。 00:08:45.700 --> 00:08:48.280 クリーンアップしたデータはどこかに保存しておきたいでしょう。 00:08:48.420 --> 00:08:52.660 レポートの規模に応じて、シェアポイント、データバース、あるいはSQLデータベースを使用します。 00:08:52.800 --> 00:08:58.120 このストレージは短期記憶として機能し、パービューに何度も負荷をかけることなく、エージェントに過去との比較データを提供します。 00:08:58.280 --> 00:09:00.180 知能をキャッシュしていると考えてください。 00:09:00.380 --> 00:09:03.460 昨日のイベントが、今日の分析に説得力を与えます。 00:09:03.640 --> 00:09:08.960 列機能やデータセット間の関連付けが必要なら、データバースの型がパワーオートメートと親和性が高いです。 00:09:09.140 --> 00:09:12.660 シェアポイントは手軽ですが、数千行を超えると扱いづらくなります。 00:09:12.840 --> 00:09:14.320 次はスケジュール設定です。 00:09:14.520 --> 00:09:15.960 実行頻度を定義しましょう。 00:09:16.180 --> 00:09:19.200 動的な環境なら日時サマリーを、穏やかなエコシステムなら終時で十分です。 00:09:19.340 --> 00:09:21.460 パワーオートメートの定期実行トリガーを使用します。 00:09:21.640 --> 00:09:24.160 UTCではなく、自分のタイムゾーンを設定してください。 00:09:24.340 --> 00:09:27.300 午前3時にレポートが届く理由を不思議に思うのが趣味でない限り、 00:09:27.300 --> 00:09:31.240 フローは自動的に開始され、フィルタリングされたデータを抽出し、変換し、保存して、 00:09:31.240 --> 00:09:34.040 次のフェーズである、論理の、のためにペイロードを準備します。 00:09:34.180 --> 00:09:36.960 コンプライアンスの整合性はもはや人間の意欲に依存せず、 00:09:37.220 --> 00:09:38.700 時計仕掛けのように遂行されます。 00:09:38.860 --> 00:09:42.820 エラー許容範囲を設定する際、他のあらゆるアナリストが同じ瞬間にログをクエリしようとして、 00:09:43.100 --> 00:09:47.300 驚くべきことにパービューのAPIが、リクエスト型、エラーを返した場合の対応も考えておきましょう。 00:09:47.480 --> 00:09:50.040 リトライポリシーとフォールバックメッセージを構築しましょう。 00:09:50.040 --> 00:09:53.020 自動化であっても、障害は適切に処理されるべきです。 00:09:53.140 --> 00:09:57.140 エラーをログファイルに書き込み、敷地を超えたらTeamsへ通知を送ります。 00:09:57.360 --> 00:10:00.220 そうすれば、障害をドラマではなくデータとして管理できます。 00:10:00.420 --> 00:10:01.160 覚えておいてください。 00:10:01.460 --> 00:10:03.320 監査人はエラー自体を罰するわけではありません。 00:10:03.480 --> 00:10:05.800 彼らが罰するのは、その記録が欠けていることです。 00:10:05.940 --> 00:10:08.000 これで、生きているパイプラインが完成しました。 00:10:08.180 --> 00:10:12.380 パービューのデータがパワーオートメイトの動脈を通じ、選択したストレージへ流れます。 00:10:12.380 --> 00:10:16.220 手動のデータ収集プロセスを、より厳格な手法へと置き換えるのです。 00:10:16.380 --> 00:10:19.580 正しく行えば、組織の文化にも微妙な変化をもたらします。 00:10:19.760 --> 00:10:23.900 コンプライアンス報告は、監査前の特勘作業ではなく、絶え間ない鼓動となります。 00:10:24.100 --> 00:10:28.680 念のため言っておくと、毎週金曜に手動でパービューを検索し、Excelにコピーしても同じことはできます。 00:10:28.900 --> 00:10:30.980 自分でバターを攪拌して作ることもできるのと同じです。 00:10:31.100 --> 00:10:33.520 このパイプラインは、他の方法がないから存在するわけではありません。 00:10:33.700 --> 00:10:35.700 週末を大切にするために存在するのです。 00:10:35.700 --> 00:10:39.600 自動化を危険視してログを手作業でスクロールしている人たちが滑稽なだけです。 00:10:39.760 --> 00:10:44.520 唯一の真のリスクは、担当者が休むだけで監査証跡が途切れるような脆いプロセスに固執することです。 00:10:44.680 --> 00:10:49.660 エージェントが資格を得て、構造化されたスケジュールでデータを受け取れるようになったら、次は認知能力を与えます。 00:10:49.820 --> 00:10:55.180 次のレイヤーでは、生の情報を解釈し、判断の指揮位置や条件ロジック、要約へと変換します。 00:10:55.380 --> 00:10:57.780 本質的には、目から脳へと進化させるのです。 00:10:57.940 --> 00:10:58.960 基盤は整いました。 00:10:58.960 --> 00:11:00.720 思考回路を構築しましょう。 00:11:00.900 --> 00:11:02.220 エージェントに脳を与える。 00:11:02.360 --> 00:11:03.720 パワーオートメートのロジック。 00:11:03.860 --> 00:11:05.520 パワーオートメートはAIではありません。 00:11:05.700 --> 00:11:08.560 夢を見たり、推測したり、コンプライアンスリスクを原始したりはしません。 00:11:08.740 --> 00:11:12.000 それが提供するのは、人間には維持が難しい、服従、です。 00:11:12.160 --> 00:11:15.380 手順を忘れず、即興で動かず、言い訳もしません。 00:11:15.600 --> 00:11:18.780 その予測可能な厳格さこそが、自立性には不可欠なのです。 00:11:18.980 --> 00:11:21.840 GRCエージェントのロジック層は、構造から始まります。 00:11:21.840 --> 00:11:28.180 フローが自ら起動し、確実にパービューを紹介し、発見内容を解釈して、定義した指揮位置を超えたか判断する必要があります。 00:11:28.340 --> 00:11:30.020 連鎖反応をイメージしてください。 00:11:30.200 --> 00:11:31.860 定期的なトリガーが作動します。 00:11:32.040 --> 00:11:33.740 パービューへの呼び出しが行われます。 00:11:33.940 --> 00:11:37.380 データが整理され、パターンが集計され、リスクカテゴリーが割り当てられます。 00:11:37.560 --> 00:11:39.420 ドラマはなく、ただ実行があるのみです。 00:11:39.560 --> 00:11:41.060 定期的なトリガーから始めましょう。 00:11:41.260 --> 00:11:44.400 適切なタイミングの定期実行は、人間の忘却に対する文明の回答です。 00:11:44.560 --> 00:11:46.940 監査人がいるタイムゾーンに合わせて設定してください。 00:11:46.940 --> 00:11:53.280 日時でも週時でも、そのスケジュールによりフローは促されることなく自動で開始され、自立システムとして維持されます。 00:11:53.480 --> 00:11:55.660 その直後に初期化ブロックを配置します。 00:11:55.840 --> 00:11:58.300 環境変数、カウンター、配列などです。 00:11:58.460 --> 00:12:01.220 これらがエージェントが後に使う認知的な骨組みとなります。 00:12:01.420 --> 00:12:06.100 イベント総数、高リスク件数、レポート日などの変数がエージェントの作業記憶になります。 00:12:06.280 --> 00:12:11.520 起動すると、フローはパービュー監査ログコネクタまたはHTTP APIを呼び出します。 00:12:11.740 --> 00:12:13.160 そして現実がやってきます。 00:12:13.420 --> 00:12:18.040 性能応答には、性的なノイズやシステムのハートビート、全く無関係なイベントが含まれます。 00:12:18.180 --> 00:12:21.060 フィルター配列ステップを挿入して、不要なデータを取り除きましょう。 00:12:21.260 --> 00:12:27.360 一般的なパターンとして、ユーザータイプがサービスプリンシパルのレコードは無視し、データガバナンスやポリシー変更に関連する操作タイプのみを保持します。 00:12:27.420 --> 00:12:31.200 この整理作業こそが、エージェントを不安にさせず、分析的な状態に保つ秘訣です。 00:12:31.340 --> 00:12:35.300 マイクロソフトは冗長性を好むため、多くのログストリームで同じイベントが繰り返されます。 00:12:35.500 --> 00:12:38.820 式での単純なユニオン操作やループ比較を使用して、重複を排除します。 00:12:39.020 --> 00:12:42.220 後に残るのはシグナル、つまり分類する価値のある正確なサブセットです。 00:12:42.360 --> 00:12:45.100 ここでようやく、スクリプトが頭脳としての役割を果たします。 00:12:45.180 --> 00:12:49.860 作成、または選択、アクションを追加し、残りのレコードをユーザープリンシパル名と操作でグループ化します。 00:12:50.020 --> 00:12:53.400 次に、その集計結果を各地に適用、ループに渡し、カテゴリごとに合計します。 00:12:53.600 --> 00:12:56.040 最終的に、エージェントはスナップショットを保持することになります。 00:12:56.220 --> 00:13:00.040 誰が何を、どれくらいの頻度で行い、定義されたリスク境界に達したかどうかです。 00:13:00.220 --> 00:13:04.620 自立化の秘訣は、定義した式位置からシステムがリスクレベルを推論できるようにすることです。 00:13:05.020 --> 00:13:09.420 例えば、特権昇格が3回なら、リスクレベルを高に設定します。 00:13:09.620 --> 00:13:13.060 外部共有が1回なら、リスクレベルを中に設定します。 00:13:13.280 --> 00:13:15.040 それ以外は標準とします。 00:13:15.040 --> 00:13:18.380 このロジックは意味を捏造するのではなく、強制的に適用するものです。 00:13:18.500 --> 00:13:23.360 多すぎる、という状態を数値化することで、人間の直感を数値による明確さえ置き換えたのです。 00:13:23.520 --> 00:13:25.440 入れ子上の条件アクションを使用します。 00:13:25.640 --> 00:13:29.140 リスクレベルが高の場合、そのユーザー情報を高リスクの配列に追加します。 00:13:29.320 --> 00:13:31.640 中の場合は、レビュー用にQAを送るかもしれません。 00:13:31.820 --> 00:13:35.920 異常がない場合は、何も返さないのではなく、検出なし、というメッセージを記録します。 00:13:35.920 --> 00:13:39.520 データ欠落とデータなしを区別することは、コンプライアンスにおいて不可欠です。 00:13:39.660 --> 00:13:44.260 指揮位置を超えたら、オプションでコパイロットスタジオのエンドポイントを呼び出し、物語形式の要約を作成します。 00:13:44.420 --> 00:13:46.740 2名のユーザーがリスク指揮位置を超えました、のように。 00:13:46.920 --> 00:13:49.500 しかし、その言語化ステップは次のセクションで扱います。 00:13:49.660 --> 00:13:52.340 ここでは、構成ではなく評価が目的だからです。 00:13:52.500 --> 00:13:53.640 エラーは起こるものです。 00:13:53.820 --> 00:13:57.900 APIは、マーケティング上の謳い文句よりも頻繁にスロットル制限や一時的な不具合が発生します。 00:13:57.900 --> 00:14:02.140 すべてのHTTP呼び出しを、再試行ポリシーを有効にしたスコープコンテナで囲みます。 00:14:02.320 --> 00:14:04.940 3回の試行、指数バックオフを設定しましょう。 00:14:05.120 --> 00:14:11.260 失敗ブランチでは、エラーメッセージ、タイムスタンプ、フロー実行IDを、自動化状態を管理するシェアポイントリストかデータバーステーブルに記録します。 00:14:11.440 --> 00:14:13.840 最初のデプロイ時には、滑稽な事態を覚悟してください。 00:14:14.000 --> 00:14:17.340 私がこのビルドを最初にテストした時、エージェントは誇らしげに問題なしと報告しました。 00:14:17.460 --> 00:14:19.420 完璧なコンプライアンスだと私は思いました。 00:14:19.420 --> 00:14:23.200 しかしその後、サービスアカウントに監査ログ閲覧者のロールが不足していることに気づいたのです。 00:14:23.300 --> 00:14:26.320 ロボットは怠けていたのではなく、忠実ゆえに盲目だったのです。 00:14:26.480 --> 00:14:30.460 自動化とは、与えられた指示を忠実に実行するだけであり、それ以上は行わないという教訓です。 00:14:30.620 --> 00:14:33.220 すべてのフロー実行は、実行の証拠を書き出します。 00:14:33.440 --> 00:14:40.920 最後に、ファイルに追加、または項目の作成、アクションを挿入し、ようやくメトリクス、処理された合計イベント数、最大リスクユーザー、実行時間を保存します。 00:14:41.080 --> 00:14:44.920 そして、それらの結果をチームチャンネルや管理用のシェアポイントライブラリにストリーム配信しましょう。 00:14:45.100 --> 00:14:47.960 監査の季節がやってきたとき、記憶を頼りに説明することはできません。 00:14:48.160 --> 00:14:50.020 証拠となる記録を提示する必要があります。 00:14:50.260 --> 00:14:53.540 追加の安全策として、実行IDとフローのバージョンを含めておきましょう。 00:14:53.720 --> 00:14:58.160 後に指揮位置が変更されても、監査人はどのロジックがどの結果を導いたかを追跡できます。 00:14:58.380 --> 00:15:01.420 マシンによるガバナンスとは、マシン自身による統制を意味します。 00:15:01.620 --> 00:15:05.260 この時点で、自動化システムは分類、集計、そして判断が可能になっています。 00:15:05.440 --> 00:15:08.560 リスクレベルがポリシーに抵触しても、システムは何も語りません。 00:15:08.760 --> 00:15:12.500 人間にとってその沈黙は不気味なものですが、次の層が言葉を与えてくれます。 00:15:12.700 --> 00:15:13.860 あるいはこう言えるでしょう。 00:15:14.080 --> 00:15:17.720 思考できるようになった今、システムには言葉が必要であり、できれば人間にも分かる言語で話すべきだと。 00:15:17.720 --> 00:15:21.080 システムに文章作成を教える、コパイロットスタジオとの統合です。 00:15:21.220 --> 00:15:24.800 これまでのエージェントは科目で、有能ですが無言の存在でした。 00:15:24.980 --> 00:15:30.100 コパイロットスタジオはそれに言葉を与え、データを外交的な表現へと変換する通訳者となります。 00:15:30.280 --> 00:15:34.780 コードと会議の間に挟まれた、他言語を操る交渉人だと考えてください。 00:15:35.000 --> 00:15:36.820 作り話をしないシステムです。 00:15:37.060 --> 00:15:40.000 現実を人間が解釈できる文章へと書き換えます。 00:15:40.100 --> 00:15:51.460 その進化は、パワーオートメートが生成するジェイソンの山を、ユーザーの行動やリスクの集計、イベント記録を整理した経営層には丁寧で、監査人には正確なレポートへと変える力にあります。 00:15:51.460 --> 00:15:58.580 公文と政治の橋渡しをし、かつての生のマシンデータを解読不能な表ではなく、最新の判断として読めるようにします。 00:15:58.760 --> 00:16:01.920 まずは、どのようなコミュニケーションを望むかを定義することから始めます。 00:16:02.080 --> 00:16:05.560 通常は、エグゼクティブサマリー、技術付録、推奨事項の3つです。 00:16:05.760 --> 00:16:07.700 それぞれが異なる情報の受け手に対応しています。 00:16:07.880 --> 00:16:09.600 経営層は一段落の要約を求めます。 00:16:09.740 --> 00:16:11.520 監査人は証拠の追跡を必要とします。 00:16:11.700 --> 00:16:14.680 IT部門は、データで万全を期すために全てのフィールドを求めます。 00:16:14.680 --> 00:16:19.160 スタジオで単一のコパイロットエクスペリエンスを作成し、その中に複数のプロンプトを構築します。 00:16:19.280 --> 00:16:22.720 各プロンプトが、トーン、フォーマット、詳細度を調整します。 00:16:22.920 --> 00:16:29.040 例上位のリスクを平易な言葉で5つの箇条書きに要約し、それぞれに改善策を提案する。 00:16:29.200 --> 00:16:34.020 次の例すべての高リスクイベントを表形式でリスト化した技術付録を作成する。 00:16:34.140 --> 00:16:36.500 パワーオートメートとコパイロットスタジオを接続するには、 00:16:36.500 --> 00:16:42.560 フロー内のhttpアクションを使用して、構造化されたJSONペイロードをコパイロットのエンドポイントURLに投稿します。 00:16:42.680 --> 00:16:46.440 コパイロットは、定義したシステムプロンプトを使用してそのペイロードを解釈します。 00:16:46.640 --> 00:16:49.400 マイクロソフトの認証機能により、これを安全に行えます。 00:16:49.560 --> 00:16:53.220 Azure ADを通じて呼び出しを認証するため、あなたのフローのみがアクセス可能です。 00:16:53.360 --> 00:16:54.200 おめでとうございます。 00:16:54.440 --> 00:16:57.900 これで、ボットに構造化された思考をライティングエンジンへ送信させる方法を習得しました。 00:16:58.080 --> 00:17:00.020 返される結果は数字ではなくテキストです。 00:17:00.020 --> 00:17:02.060 そのテキストが、あなたのレポートとなります。 00:17:02.260 --> 00:17:04.860 それをコパイロットに入力し、次のように指示します。 00:17:05.040 --> 00:17:15.920 これらの結果を短いコンプライアンスレポートにまとめ、重大度別に分類し、発見事項ごとに一つのアクションを推奨し、全体的な傾向で締めくくれ、コパイロットはアナリストのメモのようなものを返します。 00:17:16.080 --> 00:17:19.280 昨日、2人のユーザーにリスクの高い行動が見られました。 00:17:19.440 --> 00:17:23.160 アデレバンスが許容式位置を超える権限昇格を3回実行しました。 00:17:23.340 --> 00:17:25.660 管理者ロールの即時レビューを推奨します。 00:17:25.660 --> 00:17:28.360 メガンBが一度、外部共有を試みました。 00:17:28.500 --> 00:17:30.800 ユーザーに外部データポリシーを再確認させてください。 00:17:31.020 --> 00:17:32.680 その他の異常は検出されませんでした。 00:17:32.860 --> 00:17:35.260 ベースラインと比較した全体的な傾向は安定しています。 00:17:35.460 --> 00:17:36.100 わかりますか? 00:17:36.240 --> 00:17:38.060 これは生成的な推測ではありません。 00:17:38.240 --> 00:17:40.980 決定論的なプロンプトに従ったフォーマット済みの統合です。 00:17:41.160 --> 00:17:43.840 人間はそれを執筆と呼び、マシンはそれを出力と呼びます。 00:17:44.020 --> 00:17:47.220 その秘訣は、データ構造と言語構造の両方を制御することにあります。 00:17:47.220 --> 00:17:51.100 コパイロットは自由に動き回っているのではなく、統計をナレーションしているのです。 00:17:51.220 --> 00:17:52.840 次に配布方法を決めます。 00:17:53.020 --> 00:17:56.320 普通の人間がレポートを見つけるためにデータバースにログインすべきではありません。 00:17:56.520 --> 00:17:59.120 そこで、パワーオートメイトのコネクタを再び活用します。 00:17:59.320 --> 00:18:01.480 同じフローから2つのブランチを作成します。 00:18:01.680 --> 00:18:04.440 1つはコパイロットの要約をチームチャンネルに直接投稿し、 00:18:04.740 --> 00:18:07.620 もう1つは完全なHTML版をシェアポイントに記録します。 00:18:07.780 --> 00:18:11.960 管理職はチームの投稿を読み、監査人はアーカイブを開いてドキュメントを確認します。 00:18:11.960 --> 00:18:15.440 どちらも自動的にタイムスタンプが押され、同じ言い回しで届きます。 00:18:15.580 --> 00:18:18.920 これが一貫性であり、多くの人間には馴染みのない美徳です。 00:18:19.060 --> 00:18:21.440 プロンプとエンジニアリングの規律について話しましょう。 00:18:21.620 --> 00:18:22.960 ガードレールが必要です。 00:18:23.100 --> 00:18:25.740 コパイロットが使用すべき正確な見出しを指定してください。 00:18:25.960 --> 00:18:28.280 概要、重要な所見、推奨事項。 00:18:28.500 --> 00:18:32.720 指定しないと、コパイロットは物語的なフレアや絵文字であなたを感心させようとします。 00:18:32.900 --> 00:18:36.020 絵文字入りの監査レポートなんて、混沌を招くだけです。 00:18:36.020 --> 00:18:42.960 専門的で中立的なトーンを使用する、推測的な表現を避ける、定量的な指標を含める、といった指示を組み込みます。 00:18:43.120 --> 00:18:46.240 指示が厳密であるほど、出力の再現性が高まります。 00:18:46.420 --> 00:18:49.640 コンプライアンスは個性ではなく、再現性によって成り立つものです。 00:18:49.800 --> 00:18:52.100 平凡なメカニズムの中にこそ美しさがあります。 00:18:52.320 --> 00:18:54.980 コパイロットスタジオではコンテキスト変数を使用できます。 00:18:55.220 --> 00:18:59.980 レポートの日付や実行時間などの動的データを、出力内に直接埋め込むことができます。 00:19:00.180 --> 00:19:03.000 日付やレコード数のプレースホルダーを使用してください。 00:19:03.000 --> 00:19:06.960 フローがコパイロットを呼び出すと、それらの変数は自動的に解決されます。 00:19:07.080 --> 00:19:11.780 結果は、3月15日に生成、563件の監査イベントを分析、と表示されます。 00:19:11.960 --> 00:19:15.360 そのメタコンテキストは、どんなジフよりも早く監査人を納得させます。 00:19:15.560 --> 00:19:18.680 正確さを追求するには、最後に検証という工程が必要です。 00:19:18.820 --> 00:19:22.340 コパイロットの応答が空ではないことをチェックするパワーオートメートの条件を挿入します。 00:19:22.520 --> 00:19:25.340 もし空であれば、エラーをログに保存し、一度再起的に処理します。 00:19:25.560 --> 00:19:28.040 すでにエージェントに自己認識と論理を学習させているはずです。 00:19:28.040 --> 00:19:30.600 次はそれを言語的な健全性チェックと組み合わせます。 00:19:30.740 --> 00:19:32.840 完成したフローはこのような形になります。 00:19:33.040 --> 00:19:39.360 抽出、分析、要約、ナレーション、公開、すべての矢印が説明責任を表しています。 00:19:39.600 --> 00:19:41.000 最終的な改良です。 00:19:41.160 --> 00:19:45.140 コンプライアンス基準が変更されるたびに、コパイロットのシステムプロンプトをバージョン管理してください。 00:19:45.320 --> 00:19:50.500 更新にV1、V1、1などのタグを付け、どのプロンプトバージョンがどのレポートを作成したかを記録します。 00:19:50.500 --> 00:19:55.140 将来の監査では、何が起きたかだけでなく、当時のナレーションモデルがどのような指示を受けていたかを参照できます。 00:19:55.300 --> 00:19:58.380 これはメタコンプライアンスであり、ガバナンスが自らを記述するガバナンスです。 00:19:58.520 --> 00:20:00.720 官僚主義がついに再規制を実現しました。 00:20:00.880 --> 00:20:05.280 コパイロットスタジオがレポートを作成すれば、人間の役割は幸いにも不要となります。 00:20:05.460 --> 00:20:12.140 エージェントが物語を紡ぎ、証拠を添付し、ファイルを投稿し、旧バージョンをアーカイブして、次の起動サイクルまでシャットダウンします。 00:20:12.140 --> 00:20:17.340 承認を必要としないよう意図的に設計されているため、確認を求めるメールがあなたに届くことはありません。 00:20:17.520 --> 00:20:22.540 擬人化を許していただけるなら、エージェントは自らの言語の正確さを密かに誇りに思っています。 00:20:22.740 --> 00:20:26.460 ここで自立性はメタファーから抜け出し、ワークフローの現実となります。 00:20:26.660 --> 00:20:34.020 マシンはコンプライアンスデータを処理するだけでなく、遅延による感情的な動揺を招くことなく、スケジュール通りに人間にコンプライアンスを説明します。 00:20:34.020 --> 00:20:40.880 そう、もし遊び心が欲しければ、コパイロットGRCエージェントが自律的に作成したレポートといった署名を加えることもできます。 00:20:41.080 --> 00:20:45.500 ロボットが自らの仕事に署名することほど、上司のマイクロマネジメントを抑制するものはありません。 00:20:45.500 --> 00:20:52.900 エージェントが調査結果を明確に表現できるようになった今、あなたはGRCレポートの作成を永久に、あるいは少なくとも誰かがコネクタを無効にするまでやめることができます。 00:20:53.060 --> 00:20:55.140 この段階でサイクルは完結します。 00:20:55.140 --> 00:21:02.200 パービューが収集し、パワーオートメートが解釈し、コパイロットが要約し、驚くべきことに、あなたは終末を取り戻すのです。 00:21:02.340 --> 00:21:06.960 日々の退屈なルーチンが、コンプライアンスを流暢に語る一つのワークフローへと変貌します。 00:21:07.160 --> 00:21:11.000 結果は、間隔を空けず常に正確な時刻にチームに表示されます。 00:21:11.180 --> 00:21:17.540 明快なテキスト、一貫した用語、監査可能な来歴、その繊細な利点はスピードではなく、標準化にあります。 00:21:17.780 --> 00:21:22.160 各レポートは同じトーンで、同じ式位置を使用し、同一のメタデータを記録します。 00:21:22.160 --> 00:21:25.420 監査担当者がフォーマットの確認に何時間も費やす必要はもうありません。 00:21:25.540 --> 00:21:27.100 彼らは本質を評価するのです。 00:21:27.240 --> 00:21:31.060 リスクパターンは、スプレッドシートの混乱ではなく、時間軸に沿って追跡される物語となります。 00:21:31.240 --> 00:21:34.160 あなたはコンプライアンスを、記録からオーケストレーションへと変えました。 00:21:34.320 --> 00:21:38.200 法定レベルの精度で監視、解釈、報告を行う、常時稼働のシステムです。 00:21:38.400 --> 00:21:40.860 手動のGRCレポートはタイプライターのようなものです。 00:21:41.000 --> 00:21:43.800 このエージェントはワープロであり、自動構成機能まで備えています。 00:21:43.800 --> 00:21:49.540 次の監査シーズン前に導入すれば手動のコンプライアンスレポート、という言葉は、ログをファックスして、と同じくらい時代遅れに聞こえるでしょう。 00:21:49.700 --> 00:21:52.540 次は、このインテリジェンスをデータプライバシーの執行へと拡張します。 00:21:52.720 --> 00:21:54.020 あなたはすでにNOを構築しました。 00:21:54.180 --> 00:21:55.540 今度は、それに監視を任せましょう。