WEBVTT 00:00:00.000 --> 00:00:07.700 マイクロソフト365、コパイロット、AI、Azure、そして働き方の未来を切り開く人々に捧げる10日間、準備はいいですか? 00:00:07.860 --> 00:00:12.280 この1月、M365コンがさらに規模を拡大して帰ってきます。 00:00:12.540 --> 00:00:18.580 世界中のMVPや業界エキスパートによるライブセッション、実践的なデモ、専門知識の共有にご期待ください。 00:00:18.760 --> 00:00:21.900 ありきたりなスライドや空虚な流行語は一切ありません。 00:00:22.060 --> 00:00:29.340 コパイロットスタジオ、AIエージェント、ファブリック、セキュリティ、ガバナンス、自動化といった現実の課題に切り込みます。 00:00:29.340 --> 00:00:35.040 ITプロフェッショナル、開発者、ビジネスリーダー、どなたにも最適なセッションをご用意しています。 00:00:35.220 --> 00:00:40.600 10日間という期間で複数の技術を探求し、グローバルなコミュニティとつながることができます。 00:00:40.840 --> 00:00:44.620 ライブで視聴し、実践的な知見を組織に持ち帰りましょう。 00:00:45.000 --> 00:00:51.160 2027年1月、10日間、一つのマイクロソフトコミュニティ、登録受付を開始しました。 00:00:51.380 --> 00:00:55.940 m365コン.NETにアクセスして、今すぐ参加枠を確保してください。 00:00:55.940 --> 00:00:59.600 繰り返しになりますが、m365コン.NETです。 00:00:59.760 --> 00:01:04.760 m365コン.NETから今すぐ登録を、1月のライブでお会いしましょう。 00:01:04.940 --> 00:01:09.180 コパイロットが自分の権限内にある情報しか表示しないと思っているなら、考え直すべきです。 00:01:09.320 --> 00:01:14.180 グラフ権限を一つ間違えるだけで、コンプライアンスチームが承認していないデータが突然AIに露出してしまいます。 00:01:14.340 --> 00:01:17.600 怖いのは、それが起きていることに一生気づかないかもしれないという点です。 00:01:17.600 --> 00:01:25.200 この動画では、管理されていないコパイロットアクセスの真のリスクを解説し、機密ファイルや財務データ、顧客情報がどのように漏えいし得るのかを見ていきます。 00:01:25.440 --> 00:01:34.140 その後、必要なアクセス権を維持しつつ、生産性を損なうことなく、グラフ権限、DLPポリシー、パービューで保護する方法を解説します。 00:01:34.140 --> 00:01:51.660 コパイロットが過剰な情報を持つと、若手スタッフが先市販機のプロジェクトレビューのメモを求めた際に、自分たちの会議のまとめではなく、非公開の取締役会の議事録や戦略的決定、予算削減の詳細、本来見るべきではなかった人物名までが表示されてしまうのです。 00:01:51.880 --> 00:01:57.920 侵害アラートもDLP警告もならず、AIが本来触れるべきではないドキュメントを静かに提供してしまうのです。 00:01:57.920 --> 00:02:03.120 なぜなら、コパイロットはユーザーのメールボックスやワンドライブの境界で自動的に停止するわけではないからです。 00:02:03.120 --> 00:02:07.760 その到達範囲は、マイクロソフトグラフを通じて付与された権限によって決定されます。 00:02:07.960 --> 00:02:19.540 グラフは単なるデータベースではなく、マイクロソフト365のほぼ全てのコンテンツ、シェアポイント、チームズメッセージ予定表、ワンノート、テナントに紐付くCRMデータなどへのアクセス拠点です。 00:02:19.680 --> 00:02:22.960 適切なドアさえ開いていれば、全てはグラフを経由して流れ出します。 00:02:23.140 --> 00:02:25.380 これこそ、多くの管理者が軽視しているポイントです。 00:02:25.380 --> 00:02:29.800 自分自身でサインインしているのだから、コパイロットも自分が見えるものしか見ないはずだという一般的な思い込みがあります。 00:02:29.980 --> 00:02:31.420 一見もっともらしく聞こえます。 00:02:31.620 --> 00:02:36.240 問題は、コパイロット自体が独自のアプリケーション権限セットで動作することが多いという点です。 00:02:36.400 --> 00:02:44.880 もしその権限がサインインしているユーザーの権利よりも広範囲であれば、キーボードの前に座る人間が到達できる範囲を遥かに超えるアクセス権を持つAIアシスタントが誕生することになります。 00:02:45.100 --> 00:02:50.380 そして一部の導入環境では、それらの昇格された権限が理由を問われることもなく付与されています。 00:02:50.620 --> 00:02:53.920 市販機予測に取り組んでいる財務アナリストを想像してみてください。 00:02:54.100 --> 00:02:58.440 彼らはコパイロットに、上位20社のアカウントの現在のパイプラインデータを尋ねます。 00:02:58.660 --> 00:03:02.840 通常の役割において彼らが見るべきなのは一部のクライアントの数字だけのはずです。 00:03:02.840 --> 00:03:07.040 しかし、コパイロットのアプリ登録でグラフがどのようにスコープ設定されているかによっては、 00:03:07.040 --> 00:03:12.840 AIがそのアナリストが直接アクセスしたことのない共有チームサイトから、営業パイプラインの全レポートを引き出してしまいます。 00:03:13.000 --> 00:03:16.040 エンドユーザーの視点からは、何も疑わしい点はありません。 00:03:16.220 --> 00:03:20.200 しかし、セキュリティとコンプライアンスの観点から見れば、それは機密情報の露呈です。 00:03:20.360 --> 00:03:24.520 グラフAPIの権限は、実質的に組織のデータへの正面玄関となります。 00:03:24.600 --> 00:03:27.820 マイクロソフトはこれらを、サインインしたユーザーに代わって動作する、 00:03:28.140 --> 00:03:33.220 移任された権限と、アプリが独立して動作することを許可する、アプリケーション権限に分けています。 00:03:33.380 --> 00:03:37.640 コパイロットのシナリオではコンテンツ取得のために移任された権限が必要なことが多いですが、 00:03:38.040 --> 00:03:40.420 ユーザーが参加していなかったチーム会議の要約など、 00:03:40.780 --> 00:03:45.140 特定の機能では管理者がアプリケーションレベルの権限を承認するよう求められる場合があります。 00:03:45.620 --> 00:03:47.500 そして、そこに危険が忍び寄ります。 00:03:47.700 --> 00:03:52.780 アプリケーション権限は、意図的にスコープを制限しない限り、個々のユーザーの制限を無視します。 00:03:52.780 --> 00:04:01.220 これらの承認は導入の初期段階で行われることが多く、開発テナントでコパイロットをテストしているIT管理者がセットアップを完了させるためだけに権限プロンプトで、 00:04:01.580 --> 00:04:06.740 同意をクリックし、その構成を影響を検討せずに本番環境で複製してしまう可能性があります。 00:04:06.980 --> 00:04:11.720 一度設定されると、それらの広範な権限は誰かが積極的に監査しない限り残存します。 00:04:11.920 --> 00:04:18.940 時間の経過とともに新しいデータソースがM365に接続されると、意識的な決定なしにコパイロットの到達範囲は拡大していきます。 00:04:18.940 --> 00:04:25.900 これが静かな権限の肥大化です。騒ぎもユーザーからの苦情もなく、ただAIの範囲が徐々に広がっていくだけなのです。 00:04:26.040 --> 00:04:32.260 課題は、ほとんどのセキュリティチームが、どのコパイロットの機能がどのレベルのグラフアクセスを必要とするかを熟知していないことです。 00:04:32.420 --> 00:04:37.900 彼らはシェアポイントの全てのファイルの読み取りを見て、ユーザーコンテキストによって制限されていると思い込むかもしれませんが、 00:04:38.060 --> 00:04:41.420 その権限がアプリケーションレベルでテナント全体に及ぶものであるとは認識していません。 00:04:41.420 --> 00:04:49.700 特定のAIシナリオを最小限必要な権限にマッピングしなければ、結局は初期設定で承認された権限がデフォルトとなってしまいます。 00:04:49.920 --> 00:04:56.620 そして、それらの権利が広ければ広いほど、期待される動作と実際の動作との間のギャップは大きくなります。 00:04:56.880 --> 00:05:03.860 また、コパイロットの出力にはユーザーが確認できる組み込みの権限追跡機能がないことも覚えておくべきです。 00:05:03.860 --> 00:05:12.520 もしAIが通常ならユーザーが閲覧をブロックされる場所からコンテンツを取得した場合でも、これはあなたの権限外です、という警告バナーは表示されません。 00:05:12.740 --> 00:05:17.680 その透明性の欠如により、リスクを伴う露呈が日常のワークフローに紛れ込みやすくなります。 00:05:17.860 --> 00:05:23.900 ここでの重要な教訓は、AI導入におけるグラフ権限は、オンボーディングプロセスにおける単なるチェックボックスの一つではないということです。 00:05:24.060 --> 00:05:28.780 それらは、コパイロットがネットワーク上で行う全ての対話を形作る設計上の選択なのです。 00:05:28.780 --> 00:05:35.660 ファイアウォール規則やVPNのアクセス範囲と同様に、意図的かつ定期的に見直し、再検証を行う必要があります。 00:05:35.860 --> 00:05:42.780 デフォルト設定はすぐに利用を開始できますが、人間よりも遥かに広い範囲をAIが扱うことを容認していることになります。 00:05:42.980 --> 00:05:49.860 範囲が容易に拡大してしまうことが分かった今、本格的なインシデントに発展する前にその隙間をどう見つけるかが次の課題です。 00:05:50.040 --> 00:05:51.800 流出する前に漏洩を見つける。 00:05:51.960 --> 00:05:55.680 もしコパイロットが本来表示すべきでないデータを表示していたら、あなたはそれに気づけるでしょうか? 00:05:55.680 --> 00:05:58.700 ほとんどの組織にとって正直な答えは、いいえ、です。 00:05:58.880 --> 00:06:03.900 情報が公開サイトに投稿されたり、メーリングリストに一斉送信されたりするわけではありません。 00:06:04.100 --> 00:06:10.080 漏洩は、ドキュメントの草案や要約、AIが生成した回答の中にひっそりと現れるかもしれません。 00:06:10.280 --> 00:06:14.780 そして、誰かが異変に気づかない限り、警告を発することなく見過ごされてしまいます。 00:06:14.960 --> 00:06:18.880 可視性の問題は、多くの監視システムの構築方法に起因しています。 00:06:18.880 --> 00:06:28.600 それらは従来の活動やファイルのダウンロード、異常なログイン場所、大量のメール送信向けに調整されており、AIによる情報収集やコンパイルの仕組みには対応していません。 00:06:28.780 --> 00:06:31.960 コパイロットは、一般的な意味でファイルを開くわけではありません。 00:06:32.140 --> 00:06:37.780 マイクロソフトグラフを通じてデータソースをクエリし、結果をまとめて自然言語テキストとして提示します。 00:06:37.780 --> 00:06:45.800 つまり、AIがバックグラウンドで機密性の高い場所からデータを取得していても、標準のファイルアクセスレポートには問題がないように見える可能性があるのです。 00:06:45.940 --> 00:06:53.700 ある企業では、従業員が自分の部門の管轄外であるクライアント名を何気なく口にしたことで、初めて問題に気づいたケースもありました。 00:06:53.880 --> 00:06:58.580 マネージャーがどうしてそれを知っているのかと尋ねると、その答えは、コパイロットが草案に含めていたから、でした。 00:06:58.760 --> 00:07:01.100 インシデントチケットも自動警告もありませんでした。 00:07:01.300 --> 00:07:04.820 ただの何気ない発言がきっかけで、IT部門が調査に乗り出したのです。 00:07:04.820 --> 00:07:10.380 全容を把握した頃には、AIが生成した同じ回答がすでに複数のチーム間で共有されてしまっていました。 00:07:10.560 --> 00:07:16.060 マイクロソフト365にはこうしたシナリオを調査するためのツールがありますが、どこを見るべきかを知っておく必要があります。 00:07:16.240 --> 00:07:20.340 パービューの監査機能を使えば、コパイロットによるデータアクセスを詳細に記録できます。 00:07:20.560 --> 00:07:24.420 ただ、そこにAIという大きな警告バッジが表示されるわけではありません。 00:07:24.420 --> 00:07:35.340 監査ログ検索に入ったら、検索クエリの実行やファイルアクセスなど、コパイロットが使用する特定の操作でフィルタリングし、コパイロットのデプロイに関連付けられたアプリケーションIDで絞り込むことができます。 00:07:35.540 --> 00:07:37.580 これには事前の準備が少し必要です。 00:07:37.740 --> 00:07:42.060 エントラIDでアプリ登録の詳細を確認し、通信を識別できるようにしておく必要があります。 00:07:42.300 --> 00:07:44.680 そこから先は、パターンを見つけることが重要です。 00:07:44.880 --> 00:07:48.000 通常はデータ利用が少ないアカウントから大量のクエリが発生している場合、 00:07:48.000 --> 00:07:52.820 例えばインターンのアカウントが1時間に10回もの複雑な検索を行っているなら、確認する価値があります。 00:07:53.000 --> 00:07:58.340 機密とラベル付けされたコンテンツが、通常は触れるはずのない部門で急増している場合も同様です。 00:07:58.500 --> 00:08:01.440 パービューはラベル付けされたアクティビティをフラグ立てできるため、 00:08:01.860 --> 00:08:04.780 コパイロットのクエリがラベル付きドキュメントを参照した場合、 00:08:05.180 --> 00:08:07.860 AIが全文を出力しなくてもログで確認できます。 00:08:07.980 --> 00:08:11.900 役割ベースのアクセス権レビューも、点と点をつなぐ有効な手段です。 00:08:11.900 --> 00:08:19.540 誰が実際にコパイロットを使用しているかをマッピングし、やり取りするデータの種類と照らし合わせることで、不整合の可能性を早期に発見できます。 00:08:19.740 --> 00:08:22.340 財務部門がレポート作成にコパイロットを多用するのは自然ですが、 00:08:22.620 --> 00:08:27.380 なぜマーケティング部門の複数のアカウントが、AIクエリを通じて給与計算スプレッドシートにアクセスしているのでしょうか。 00:08:27.460 --> 00:08:32.080 こうしたレビューを行えば、監査小石の単一イベントを超えた全体像を把握できます。 00:08:32.280 --> 00:08:36.280 ただし、一般的な監視ダッシュボードではあまり役に立たないという難点があります。 00:08:36.280 --> 00:08:44.960 これらはあらゆるM365アクティビティを広範なカテゴリに集約するため、AI特有の挙動が通常の操作に紛れてしまう可能性があるからです。 00:08:45.100 --> 00:08:54.640 コパイロットのアプリIDや使用パターンに焦点を当てたカスタムフィルターやレポートを作成しなければ、砂浜から特定の砂粒を探すような作業になってしまいます。 00:08:54.840 --> 00:08:58.120 必要なのは単なる可視化ではなく、ターゲットを絞った可視化です。 00:08:58.260 --> 00:09:03.100 これは監視文化を築くためではなく、AIが実際に何を取り込んでいるかを確実に把握するためのものです。 00:09:03.100 --> 00:09:06.080 適切なログ記録手法は3つの重要な疑問に答えてくれます。 00:09:06.200 --> 00:09:12.980 コパイロットは何を取得したのか?誰がそれを実行したのか?そして、そのアクションは既存のセキュリティ及びコンプライアンスポリシーに準拠しているか? 00:09:13.120 --> 00:09:21.300 これらの答えがあれば、権限の調整、DLPルールの整地化、役割の割り当ての厳格化など、課題に対して的確に対処できます。 00:09:21.520 --> 00:09:26.320 明確な答えがなければ推測するしかなく、推測はセキュリティ戦略とは言えません。 00:09:26.320 --> 00:09:36.320 そのため、誰かの何気ない一言を待つよりも、時間を投資して監視体制を構築し、コパイロットの足跡を可視化、追跡できるようにする価値があります。 00:09:36.580 --> 00:09:41.720 そうすれば、データ過剰露出の兆候は不意の出来事ではなく管理可能なイベントとなります。 00:09:41.960 --> 00:09:45.360 どこで情報漏洩が起きているかを知ることは、ほんの第一歩に過ぎません。 00:09:45.360 --> 00:09:50.020 真のゴールは再発防止であり、そこで適切なガードレールが重要になります。 00:09:50.240 --> 00:09:52.080 実際に機能するガードレールです。 00:09:52.260 --> 00:09:56.380 DLPは、クレジットカード番号が含まれるメールを検知するためだけのツールではありません。 00:09:56.520 --> 00:10:08.260 コパイロットの文脈においてDLPは、AIが生成した回答に機密データが含まれ、それがチームチャットに貼り付けられたり、テナント外へエクスポートされたりするのを防ぐトリップワイヤーとなります。 00:10:08.260 --> 00:10:16.980 Microsoft 365の基盤ツールとしては同じですが、AIシナリオに合わせて設定するには、これまでとは異なる考え方が必要です。 00:10:17.140 --> 00:10:28.500 多くの組織のDLPポリシーが、電子メールの添付ファイル、USBドライブへのファイルダウンロード、非承認アプリへのデータコピーといった旧来のトリガーを前提としていることが問題です。 00:10:28.680 --> 00:10:33.200 コパイロットはファイルを送信するわけではないため、デフォルトではこれらのルールはトリガーされません。 00:10:33.200 --> 00:10:36.040 コパイロットはその場でコンテンツを生成しているからです。 00:10:36.040 --> 00:10:47.080 コパイロットに制限付きとマークされた顧客リストをすべて尋ね、それがラベル付けされたドキュメントから抽出された場合、従来のDLP条件を一度もトリガーすることなく出力が流出する可能性があります。 00:10:47.340 --> 00:10:52.780 そのため、AIのプロンプトと応答をDLPのスコープに明示的に組み込む必要があります。 00:10:53.340 --> 00:10:59.920 実践的な例として、特定の契約書をセキュアな環境外へ持ち出すことをポリシーで禁止しているとします。 00:10:59.960 --> 00:11:04.940 ユーザーがコパイロットに重要な情報を抽出してパワーポイントに貼り付けるよう指示するかもしれません。 00:11:04.940 --> 00:11:12.080 DLPルールでAIが生成したコンテンツを監視していなければ、その機密情報は保護されていないファイルの中に存在することになります。 00:11:12.320 --> 00:11:22.180 DLP検査の対象をコパイロットの出力まで拡張することで、そのパワーポイントが管理外の場所に保存されたり、チームで外部ゲストと共有されたりするのをブロックできます。 00:11:22.400 --> 00:11:27.500 Microsoft 365での設定は複雑ではありませんが、慎重なプロセスが必要です。 00:11:27.500 --> 00:11:33.700 まず、Microsoft Purviewコンプライアンスポータルでデータ損失防止のセクションに移動し、新しいポリシーを作成します。 00:11:33.880 --> 00:11:39.560 適用する場所を選択する際、Exchange、SharePoint、OneDrive、そして何よりもチームを含めてください。 00:11:39.720 --> 00:11:42.900 コパイロットはこれらのいずれにもデータを表示できるからです。 00:11:42.900 --> 00:11:45.060 次に、条件を定義します。 00:11:45.240 --> 00:11:52.820 金融口座番号のような組み込みの機密情報の種類や、社内のプロジェクトコードを検出するカスタムの種類を対象にできます。 00:11:53.080 --> 00:12:02.860 また、秘密ドラベルを一貫して使用している場合は、保存または共有されるファイルの最終出力にラベル付けされたコンテンツが含まれたときにトリガーされるよう条件を設定することも可能です。 00:12:03.080 --> 00:12:04.940 最後に、アクションを構成します。 00:12:05.140 --> 00:12:10.520 共有のブロック、ユーザーへのポリシーヒントの表示、あるいは続行するための正当な理由の入力を要求します。 00:12:10.520 --> 00:12:14.200 秘密ドラベルそのものが、この仕組みを実現するための鍵となります。 00:12:14.380 --> 00:12:21.200 AIのコンテキストにおいて、ラベルは他のM365サービスと同様にコパイロットが読み取れるメタデータです。 00:12:21.360 --> 00:12:33.900 機密性の高いドキュメントにアクセスや使用を制限するラベルが付いている場合、ラベルの保護設定が関連アプリ全体で一貫して適用されていれば、コパイロットは回答生成時にその制限を尊重します。 00:12:33.900 --> 00:12:43.360 AIが許可された範囲外のラベルが付いたコンテンツを使用しようとすると、そのラベルにリンクされたDLPポリシーによってアクションを阻止するか、レビュー対象としてフラグを立てることができます。 00:12:43.580 --> 00:12:48.120 その連携がなければ、コンプライアンスの観点からラベルは単なる飾りになってしまいます。 00:12:48.340 --> 00:12:54.220 私がよく目にする設定ミスの一つは、DLPポリシーがAIシナリオを全く認識していない状態のままにすることです。 00:12:54.220 --> 00:13:00.260 ルールは存在しても、管理者がコパイロットの出力を別個のチャンネルとみなしていないために、リンクが設定されていないのです。 00:13:00.400 --> 00:13:07.980 これにより、メール内であればブロックされるはずの機密情報が、生成された回答の中では検査されず、視覚が生じてしまいます。 00:13:08.180 --> 00:13:16.360 これを修正するには、AIを活用したワークフローもDLPの監視場所の一つと考え、他のすべてと同様に監視しなければなりません。 00:13:16.360 --> 00:13:25.060 DLPと秘密ドラベルが適切に構成され連携していれば、コパイロットはコンプライアンスの悩みの種になることなく、有用なツールであり続けられます。 00:13:25.240 --> 00:13:34.040 レポートのドラフト作成やドキュメントの要約、データセットの精査を任せつつ、メールやチームメッセージと同様の境界線を静かに矯正できます。 00:13:34.280 --> 00:13:39.500 ユーザーはAI支援の恩恵を受けられ、ガードレールによって機密情報の流出が防がれます。 00:13:39.660 --> 00:13:43.160 この利点は、単に意図しない情報共有を防ぐことだけではありません。 00:13:43.160 --> 00:13:46.840 明確なルールの下でテクノロジーを運用できるようにすることが重要です。 00:13:47.020 --> 00:13:52.400 そうすれば、チームの不満を招き、導入を阻害するような一律の制限に頼る必要もなくなります。 00:13:52.580 --> 00:14:02.960 コントロールを調整することで、マーケティングはコパイロットでブレインストーミングを行い、財務は分析を実行し、人事はオンボーディングガイドを生成するなど、各部門が許可された範囲内で活動できます。 00:14:03.160 --> 00:14:06.260 しかし、出力の制御はパズルの断片に過ぎません。 00:14:06.260 --> 00:14:12.540 リスクを完全に低減するには、そもそも誰にどのAI機能へのアクセス権を与えるかを決定する必要があります。 00:14:12.780 --> 00:14:15.540 一律のアクセス権で全てに対応することはできません。 00:14:15.700 --> 00:14:20.740 マーケティングのインターンとCFOが、本当に同じコパイロットの権限を持つべきでしょうか。 00:14:20.860 --> 00:14:25.800 口に出すと馬鹿げた話に聞こえますが、多くのテナントではまさにそのように設定されています。 00:14:26.040 --> 00:14:32.180 役割ごとの構成を設定するよりも手軽で迅速なため、全員に同じ権限でコパイロットが有効化されているのです。 00:14:32.180 --> 00:14:38.500 その欠点は、AIのアクセス権が各役割のニーズではなく、最もオープンな環境に合わせられてしまうことです。 00:14:38.500 --> 00:14:41.940 そこで登場するのが、役割ベースのコパイロットアクセスグループです。 00:14:42.120 --> 00:14:49.180 全てのユーザーを同等に扱うのではなく、特定の役割が実際に必要とする情報やワークフローにAI機能を合わせます。 00:14:49.380 --> 00:14:56.140 マーケティングはキャンペーン資産やブランドガイドラインへのアクセスが必要でも、生の財務モデルは必要ないかもしれません。 00:14:56.380 --> 00:15:00.860 財務はそれらのモデルを必要としますが、初期段階の製品ロードマップは不要です。 00:15:01.060 --> 00:15:03.780 目的は、コパイロットの利便性を下げることではありません。 00:15:03.980 --> 00:15:07.020 その範囲を、各人の業務に関連するものに限定することです。 00:15:07.020 --> 00:15:11.060 全社一律で有効化するリスクは、多くのチームが予想しているよりもはるかに大きいものです。 00:15:11.160 --> 00:15:16.140 コパイロットは、マイクロソフト365関係台に既に存在するデータを利用して動作します。 00:15:16.140 --> 00:15:22.600 全てのスタッフが平等なAIアクセス権を持つと、テクノロジーは意図的に維持してきた情報のサイロを壊してしまいます。 00:15:22.820 --> 00:15:34.040 その結果、人事アシスタントが収益の内訳に触れてしまったり、運用責任者がコパイロットに翌年の製品リリース計画を尋ねて、まだ確定していない設計の詳細を得てしまったりする事態になりかねません。 00:15:34.240 --> 00:15:38.380 その時点では情報漏洩とは感じられませんが、リスクは確実に存在します。 00:15:38.560 --> 00:15:43.460 適切なアクセスモデルを構築するには、業務内容とデータニーズのマッピングから始める必要があります。 00:15:43.460 --> 00:15:48.440 使用するアプリケーションだけでなく、日常的に触れるデータの深度や機密性も考慮すべきです。 00:15:48.560 --> 00:15:57.460 例えば、営業チームのコパイロットへのリクエストの70%は顧客のアカウント履歴に関連しており、機密性の高い契約ファイルへのアクセスは5%未満であるといったことが判明するかもしれません。 00:15:57.620 --> 00:16:03.780 つまり、AIの利用範囲の大部分を特定のシェアポイントライブラリ内に限定し、残りをロックダウンすれば安全だということです。 00:16:03.920 --> 00:16:06.800 各部門で同じ作業を行えばパターンが見えてきます。 00:16:06.800 --> 00:16:14.260 各グループに必要な権限を把握できれば、マイクロソフトエントラーID、旧Azure ADが強力な管理ツールとなります。 00:16:14.460 --> 00:16:20.320 役割に応じたセキュリティグループを作成し、グループ単位でコパイロットの権限を割り当てます。 00:16:20.540 --> 00:16:28.900 例えば、財務グループには特定のグラフAPIスコープのみを有効にし、マーケティンググループには別のセットを割り当てることが可能です。 00:16:29.080 --> 00:16:34.420 機密サイトやチームチャンネル、特定のワンドライブフォルダーへのアクセス権も同じモデルで管理できます。 00:16:34.420 --> 00:16:39.560 このアプローチの強みは、これまで説明した制御機能と組み合わせることで発揮されます。 00:16:39.740 --> 00:16:44.060 グラフの権限は、コパイロットが技術的にアクセスできる範囲を決定します。 00:16:44.280 --> 00:16:49.100 DLPポリシーは、AIの出力に機密情報が含まれていないかを監視します。 00:16:50.320 --> 00:17:00.560 役割ベースのグループは、権限の過度な拡大を防ぎ、入力ソースを制限することで、不要なDLP検知を回避する役割も果たします。 00:17:00.560 --> 00:17:04.640 しかし、どんなシステムもやりすぎは禁物です。 00:17:04.820 --> 00:17:08.020 あらゆるシナリオに細分化されたグループを作りたくなるものです。 00:17:08.220 --> 00:17:15.380 レポート権限付きの財務アナリスト用コパイロットや、チームアクセスなしのマーケティングインターン用など、数十ものバリエーションができてしまいます。 00:17:15.560 --> 00:17:20.520 紙の上では細かく見えても、実際の運用環境ではメンテナンスが非常に困難になります。 00:17:20.520 --> 00:17:24.820 ユーザーの役割は変わり、プロジェクトは変化し、契約社員も出入りします。 00:17:25.000 --> 00:17:31.240 グループモデルが複雑すぎると、IT部門はセキュリティ向上よりもアクセス権の修正に時間を取られることになります。 00:17:31.480 --> 00:17:32.960 真の目的はバランスです。 00:17:33.160 --> 00:17:38.740 明確で整理された少数の役割グループであれば、管理を停滞させることなく、ほとんどのユースケースに対応できます。 00:17:39.000 --> 00:17:44.380 CFOグループには広範な分析能力が必要ですが、出力共有には厳格な制御が求められます。 00:17:44.380 --> 00:17:50.180 インターングループにはデータ範囲を限定しつつも、実務に貢献できるだけの能力を与えます。 00:17:50.400 --> 00:17:57.260 部門リーダーには中間的な権限を与え、特別なプロジェクトで例外が必要な場合はIT部門が調整できるようにします。 00:17:57.520 --> 00:18:00.700 すべてをロックダウンしてユーザーを不便にさせる必要はありません。 00:18:00.880 --> 00:18:05.300 各AI利用環境を適切かつ安全に保ち、ポリシーに従わせることが重要です。 00:18:05.480 --> 00:18:08.320 正しく設定できれば、そのメリットはすぐに現れます。 00:18:08.480 --> 00:18:11.360 ユーザーはコパイロットが提示するデータに驚かなくなります。 00:18:11.360 --> 00:18:14.280 それは常に彼らの責任範囲内のものだからです。 00:18:14.440 --> 00:18:19.660 誤って情報が公開されることがなくなるため、コンプライアンスチームが調査すべきインシデントも減ります。 00:18:19.860 --> 00:18:25.640 IT部門は、全社展開によって築き上げたデータ境界が侵害される心配をすることなく、 00:18:26.160 --> 00:18:28.800 コパイロットの新機能を安心して導入できます。 00:18:29.060 --> 00:18:34.240 アクセス制御とガードレールを連携させることで、リスクプロファイルを大幅に低減できるのです。 00:18:34.320 --> 00:18:38.060 しかし、どれほど優れたモデルであっても、それが機能していることを自分自身、 00:18:38.060 --> 00:18:41.320 そして監査を求めてくる相手に対して証明できなければ意味がありません。 00:18:41.520 --> 00:18:44.000 速度を落とさずにコンプライアンスを証明すること。 00:18:44.120 --> 00:18:48.740 コンプライアンスは単なる見せかけのセキュリティではなく、監査人を納得させるための証拠です。 00:18:48.900 --> 00:18:54.180 ポリシーやガードレールは重要ですが、AIが支援したデータに何が起きたのかを正確に示せなければ、 00:18:54.520 --> 00:18:56.460 証明ではなく主張に終始してしまいます。 00:18:56.660 --> 00:18:58.860 監査に対応できるコパイロット環境とは、 00:18:58.920 --> 00:19:03.120 ユーザーのクエリからAIによるデータ取得までの全てのやり取りが説明可能であり、 00:19:03.500 --> 00:19:06.120 検証可能な証跡に裏打ちされている状態を指します。 00:19:06.300 --> 00:19:11.220 難しいのは、多くの企業が社内レビューを通過したことで万全だと考えてしまう点です。 00:19:11.420 --> 00:19:16.620 そうしたレビューでは管理策の存在やいくつかのサンプルシナリオを確認するだけに留まり、 00:19:17.100 --> 00:19:20.580 外部監査人が求める流度を常に満たしているとは限りません。 00:19:21.060 --> 00:19:26.620 外部の審査員が、全市販機にコパイロットがアクセスした全ての機密コンテンツのログと、 00:19:27.020 --> 00:19:32.300 誰がなぜそれを要求したかの提示を求めたとき、驚くほど頻繁に不備が見つかります。 00:19:32.300 --> 00:19:37.300 ログが不完全であるか、あるいはAI関連のイベントが最初からそのようにタグ付けされておらず、 00:19:37.620 --> 00:19:39.400 完全に欠落しているかのいずれかです。 00:19:39.540 --> 00:19:42.420 ここでマイクロソフトパービューが大きな違いを生み出します。 00:19:42.660 --> 00:19:47.260 そのコンプライアンス機能は、単にラベルやDLPポリシーを適用するだけではありません。 00:19:47.460 --> 00:19:50.260 必要なホレンジック証拠を収集することもできます。 00:19:50.480 --> 00:19:54.060 コパイロットのコンテキストにおいて、パービューは関連する全てのデータアクセス要求、 00:19:54.380 --> 00:19:56.920 その背後にあるID、およびソースの場所を記録可能です。 00:19:56.920 --> 00:20:00.680 また、AIの自己報告に頼ることなく、機密ファイルがドラフト、 00:20:01.020 --> 00:20:04.300 ようやくエクスポートで参照されたといったデータ移動のパターンと、 00:20:04.680 --> 00:20:06.600 それらのイベントを関連づけることもできます。 00:20:06.780 --> 00:20:10.260 パービューのコンプライアンススコアは、単なる見栄えの良い指標ではありません。 00:20:10.440 --> 00:20:12.720 これは、マイクロソフトが推奨する管理策に対し、 00:20:12.980 --> 00:20:15.040 AI関連のリスクを直接制限するものを含め、 00:20:15.300 --> 00:20:17.920 お客様の環境がどの程度適合しているかを示すスナップショットです。 00:20:17.920 --> 00:20:20.980 グラフ権限の整理、より厳格なDLP設定、 00:20:21.300 --> 00:20:23.460 適切に管理されたロールベースのグループなどが、 00:20:23.720 --> 00:20:25.160 すべてそのスコアに反映されます。 00:20:25.300 --> 00:20:27.760 スコアは変更を加えるたびに更新されるため、 00:20:28.140 --> 00:20:30.880 AIガバナンスの改善によってコンプライアンスの状況が 00:20:30.880 --> 00:20:33.580 どのように向上しているかをほぼリアルタイムで確認できます。 00:20:33.800 --> 00:20:37.960 特定の顧客データがコパイロットによって生成されたレポートになぜ含まれていたのかを、 00:20:38.300 --> 00:20:41.540 規制当局の調査で説明しなければならない場面を想像してください。 00:20:41.540 --> 00:20:45.100 構造化されたログがなければ、その説明は推測の域を出ません。 00:20:45.260 --> 00:20:48.760 パービューを適切に構成すれば、アクセス要求を監査ログで示し、 00:20:49.100 --> 00:20:50.920 それを許可したロールと権限を特定し、 00:20:51.200 --> 00:20:53.920 出力が承認されたチャンネル内に留まっていたことを証明できます。 00:20:54.120 --> 00:20:56.440 記録のないイベントを慌てて説明するよりも、 00:20:56.700 --> 00:20:58.160 はるかに楽な話し合いになります。 00:20:58.400 --> 00:21:02.200 重要なのは、コンプライアンス報告を監査前の特別なプロジェクトとしてではなく、 00:21:02.620 --> 00:21:05.040 通常のITガバナンスサイクルの一部に組み込むことです。 00:21:05.040 --> 00:21:07.920 自動化されたレポーティングは、この点で大きく役立ちます。 00:21:08.040 --> 00:21:11.300 パービューは、情報保護ポリシーの合致、DLPインシデント、 00:21:11.580 --> 00:21:14.860 および秘密ドラベルの使用状況に関する定期的なレポートを生成できます。 00:21:15.060 --> 00:21:19.660 これらのレポートが毎月ガバナンスチームのワークスペースに届けられるようスケジュール設定すれば、 00:21:19.940 --> 00:21:22.840 レビューが容易なAIアクティビティの基準線が構築されます。 00:21:23.020 --> 00:21:26.160 どんな異常も、履歴パターンと照らし合わせればすぐに浮き彫りになります。 00:21:26.160 --> 00:21:28.720 こうした時間短縮機能の積み重ねが重要です。 00:21:28.880 --> 00:21:36.080 例えば、パービューには、ラベル付けされたコンテンツに関わる全インシデントを場所やアクティビティの種類でグループ化したレポートが標準で備わっています。 00:21:36.240 --> 00:21:41.160 コパイロットのセッションで機密ドキュメントが出力に取り込まれ、DLPが機能した場合、 00:21:41.600 --> 00:21:45.660 そのインシデントはカスタムクエリをゼロから作成しなくてもレポートに表示されます。 00:21:45.880 --> 00:21:52.180 そこから詳細をドリルダウンして確認できますが、収集や分類といった面倒な作業はすでに完了しています。 00:21:52.180 --> 00:21:59.340 もう一つの効率化として、パービューの監査とマイクロソフト365の役割ベースのアクセスデータとの統合があります。 00:21:59.540 --> 00:22:05.080 パービューはエントラーIDグループを認識できるため、役割の種類ごとにアクセスログを抽出できます。 00:22:05.320 --> 00:22:11.540 つまり、過去90日間にマーケティング担当者がコパイロット経由で財務ラベル付きデータにアクセスしたすべての事例を表示する、 00:22:11.820 --> 00:22:14.060 といった具体的な問いにも迅速に答えられます。 00:22:14.060 --> 00:22:21.060 役割とデータ分類の両方で絞り込めるこの機能こそ、外部監査人が求めているものです。 00:22:21.240 --> 00:22:24.520 考えてみれば、このレベルのコンプライアンスは負担ではありません。 00:22:24.720 --> 00:22:28.380 それは、ガバナンス設計が実際に機能していることを確認するためのガードレールなのです。 00:22:28.560 --> 00:22:31.840 また、手作業でデータをかき集める必要がないため、監査に伴うストレスも解消されます。 00:22:31.840 --> 00:23:01.820 ご視聴ありがとうございました。