WEBVTT

00:00:00.000 --> 00:00:06.340
経営陣はこれが単なる導入の問題だと考えています そうではありませんこれは極めて短期間で決断すべきガバナンスの問題です

00:00:06.340 --> 00:00:10.760
コパイロットはポリシーの整理や社内調整が終わるのを待ってはくれないため 早急な対応が迫られています

00:00:10.760 --> 00:00:16.500
コパイロットが環境全体で稼働し始めると現状のシステムをそのまま利用します そこに問題が生じるのです

00:00:16.500 --> 00:00:24.960
複数のマイクロソフト365テナントを持つ多くの組織はベンダーが一つで id 基盤も一元管理されているという理由から ai 制御も一貫していると思い込んでいます

00:00:24.960 --> 00:00:31.620
マイクロソフトが提示する戦略的ストーリーを鵜呑みにし現実もその通りだと想定している のですしかし実際の運用状況は大きく異なります

00:00:31.620 --> 00:00:37.760
ai はテナントの境界で機能しますがリスクは境界を超えて拡散します ですから問いはコパイロットをどこでも有効にできるかではありません

00:00:37.760 --> 00:00:42.500
真の問いは個別に動作するテナント間で安全に拡張できるガバナンスモデルとは何か ということです

00:00:42.500 --> 00:00:49.220
そのモデルにたどり着く前にまず罠を定義する必要があります その罠とは一つの企業の中に存在する独立した ai の島々です

00:00:49.220 --> 00:00:56.640
多くの組織においてこの錯覚は親しみやすさから始まります マイクロソフト365を開きパービューを開きエントラーを開きパワープラットフォームを開きます

00:00:56.640 --> 00:01:02.880
ブランド名は統一されています管理画面の言語もつながっているように感じられます そして営業的なメッセージは非常に明快です

00:01:02.880 --> 00:01:09.920
一つのエコシステム一つの戦略一つの方向性 しかしその背後にある制御モデルは一つではなくそれこそがブランディング以上に重要な点です

00:01:09.920 --> 00:01:17.300
調査の結果すべてのテナントでコパイロットを一元的に管理できるような 全機能が揃った単一のグローバル ai 管理センターは存在しません

00:01:17.300 --> 00:01:25.920
実際にあるのは断片化された制御スタックです ガバナンスの一部はパービューに別の一部は各管理センターに残りはエントラやパワープラットフォームに散らばっています

00:01:25.920 --> 00:01:33.240
新しいマイクロソフトの制御レイヤーでいくつかの機能が登場しつつありますが すべてのテナント協会を超えた完全で成熟したグローバルな基盤はまだ形成されていません

00:01:33.240 --> 00:01:41.340
そのギャップが根拠のない自信を生んでいます リーダーはエコシステムを見て一元化を想定しチームは共有 id を見て一貫性を想定します

00:01:41.340 --> 00:01:49.420
調達部門は一つの契約を見て単一の運用モデルを想定しますが各テナントには個別の ポリシー協会とデータ協会が依然として存在しており実際には各テナントが独自の

00:01:49.420 --> 00:01:55.140
真実を抱えているのです つまり実際に起きていることはシンプルです企業内に ai 環境が一つ存在するわけではありません

00:01:55.140 --> 00:02:03.240
たまたま同じ企業に属しているだけの複数の ai 環境が存在しているのです それは全く異なるリスクの構図ですあるテナントはパービューの適用範囲が広くても別のテナントはラベルの

00:02:03.240 --> 00:02:08.220
導入が不十分だったり 監査ログの取り込みが未完だったりします役員レベルでは一つのプログラムに見えるかもしれませんが

00:02:08.220 --> 00:02:14.040
監査やインシデントの観点からは決して一つのプログラムではありません それは個別の運用状況の集合体に過ぎないのです

00:02:14.040 --> 00:02:21.660
そして条件が揺らぐとレポートは実態と乖離し始めます 意図的ではなく構造的な問題としてです中核チームは問いかけます私たちはガバナンス下にありますか

00:02:21.660 --> 00:02:29.180
あるテナントは監査が有効だからイエスと答え別のテナントはラベルが存在するから たとえ適用範囲が弱くてもイエスと答えます3番目のテナントは id が接続されているからイエスと言います

00:02:29.180 --> 00:02:35.660
4番目は技術的にコパイロットが展開されているからイエスと答えます それぞれの回答は単独で見れば妥当に聞こえますが意味するところはバラバラです

00:02:35.660 --> 00:02:42.740
それが罠なのですグローバルな管理プレーンを見ているつもりでも実際に見ているのは 社内に点在する ai のことを似すぎません

00:02:42.740 --> 00:02:50.820
ブランドや一部の id では繋がっていますが一つのシステムとしてガバナンスは機能していません このセクションで他は忘れてもこの言葉だけは覚えておいてください

00:02:50.820 --> 00:02:57.960
グローバルな ai 管理センターなど存在せずあるのは幻影だけです その幻影が消えた時次の問題がすぐに浮上します

00:02:57.960 --> 00:03:02.760
多くの組織はテナントごとに手作業でガバナンスを行いそれをコントロールと呼び ます

00:03:02.760 --> 00:03:09.200
なぜテナントごとの手動ガバナンスが規模拡大に伴い崩壊するのか リーダーたちは教会の問題に気づくと決まって通りにかなった対応をしようとします

00:03:09.200 --> 00:03:14.960
わかった各テナントを適切に管理すればいいというのです ある管理チームが設定を確認し別のチームが別の場所でそれを繰り返します

00:03:14.960 --> 00:03:21.500
誰かがスプレッドシートで管理しまた誰かがチェックリストを作ります ステアリンググループが月に一度集まり展開が順調かどうかを確認します

00:03:21.500 --> 00:03:26.880
書面上は規律が取れているように見えます 実際にはガバナンスを装った手作業の繰り返しにすぎません

00:03:26.880 --> 00:03:33.060
それが失敗する理由は単純です 繰り返しはコントロールを生むのではなく時間の経過とともにばらつきを生むからです

00:03:33.060 --> 00:03:40.020
各テナントのスピードは異なり管理者の解釈も少しずつ違い ビジネスは中央の再レビューよりも今すぐの進歩を求めるため

00:03:40.020 --> 00:03:46.140
現場独自の例外処理が正当化されてしまうのです この古いモデルが生き残っているのは目に見える安心感があるからです

00:03:46.140 --> 00:03:54.020
チケットが閉じられポリシーが作成され設定が変更されたことを指摘できます 活動量は示せますが目に見える努力が安定した運用モデルと同じとは限りません

00:03:54.020 --> 00:04:01.460
コパイロットの導入によりそのギャップは急速にコストを押し上げます ユーザーがプロンプトを開始した瞬間システムは既存の権限コンテンツの露出

00:04:01.460 --> 00:04:05.540
ラベル付けの不備をそのまま利用します これこそ多くの人が見落としている点です

00:04:05.540 --> 00:04:11.700
コパイロットはガバナンスの成熟を待ってはくれません コパイロットはすでに存在する権限許容してしまっているコンテンツの衛生状態

00:04:11.700 --> 00:04:17.940
標準化に失敗した監査体制の上で動くからです あるテナントはアクセス権を整理しあるテナントはデータを削除しまたあるテナントは有用な

00:04:17.940 --> 00:04:23.680
監査ログを流しているのに別のテナントは調査に必要なデータすら十分に取れていない コパイロットはそうした際を即座に露呈させます

00:04:23.680 --> 00:04:29.880
それは理論上の話ではなく実際の利用を通じて起こることなのです あるテナントが広範なシェアポイントアクセスを見直し別のテナントがそれで十分だと

00:04:29.880 --> 00:04:35.120
判断した場合 ai はそのギャップを見つけ出します さらに一歩踏み込むとテナントが増えるたびに問題は倍増します

00:04:35.120 --> 00:04:43.200
テナントが悪いのではなく管理されていない際が蓄積されるからです 新しいパイロットチームが独自の例外を追加し合併によって異なるラベルを持つテナントが

00:04:43.200 --> 00:04:50.520
加わり地域の管理者が古いベースラインをコピーします 事業部門がより迅速なアクセスを求めますが個別の選択肢を見ればどれも劇的なものには見えません

00:04:50.520 --> 00:04:57.080
それらが数ヶ月かけて積み重なるとポリシーの乖離アクセスの乖離 ロールアウトの乖離が生じますその結果ガバナンスチームはリスクの防止よりも

00:04:57.080 --> 00:05:03.460
際の調整に多くの時間を費やすことになります そこで手動による管理は限界を迎えます人が設定に触れるため安全に感じられますが

00:05:03.460 --> 00:05:11.700
実際にはあらゆる接点がテナント間の乖離を招くため不整合が拡大するだけです 結果としてスピードが必要な場面でロールアウトが遅れ証拠が必要な場面で監査の負荷が増し

00:05:11.700 --> 00:05:17.440
標準化が必要な場面で手戻りが増えます 何よりも最悪なのは経営層が保障を期待している一方で隠れたリスクが生じることです

00:05:17.440 --> 00:05:23.720
ガバナンスを単なるセットアップ作業として扱うのをやめた時このことに気づきました ガバナンスはそうではありませんそれはむしろ劣化に近いものです

00:05:23.720 --> 00:05:32.460
一度権限を整理しても再発を防ぐ管理がなければリスクは再び露呈します 一度ラベルの分類を定義してもテナント間で適用にばらつきがあればベースラインは侵食されます

00:05:32.460 --> 00:05:40.800
基盤となるコントロールが維持されているか確認せずにコパイロットを段階的に導入しても 安全なスケーリングにはなりませんそれは単にガバナンスが追いつかないスピードで拡大しているだけです

00:05:40.800 --> 00:05:48.080
ここで重要な指標はアクセスの乖離です 単に問題を修正したかどうかではなく修正後にどれほど早く権限が再び拡散するかが重要です

00:05:48.080 --> 00:05:55.560
それによってモデルが維持されているかあるいは低下しているかがわかります なぜならガバナンスとは完了させるプロジェクトではないからですそれは継続的に管理すべき劣化の問題なのです

00:05:55.560 --> 00:06:00.300
規模拡大によって従来のモデルが破綻した時多くのリーダーは最も馴染みのある解決策である id 管理に頼ろうとします

00:06:00.300 --> 00:06:08.200
ユーザーがテナント間を円滑に移動できればガバナンスも自然とついてくると想定するのです しかしそうはなりませんなぜ id 管理だけではガバナンスの問題を解決できないのでしょうか

00:06:08.200 --> 00:06:17.360
id 管理は綺麗な解決策のように思えるため多くのプログラムがここで間違った方向に進んでしまいます ユーザーがテナント間で認証できエントラが接続されテナント間の設定が整っていれば

00:06:17.360 --> 00:06:28.140
リーダーは難しい部分は解決したと思い込みます アクセスやサインインが統合されアーキテクチャ図は整って見えますが id が移動できるようになったからといってコパイロットのガバナンスが統合されるわけではありません

00:06:28.140 --> 00:06:31.320
その思い込みは ai が実際に機能するポイントで破綻します

00:06:31.320 --> 00:06:37.580
コパイロットはリクエストが実行されるテナントのコンテキスト内で応答を生成します マイクロソフト自身のガイダンスでもこの点は明確に示されています

00:06:37.580 --> 00:06:44.920
マイクロソフト365コパイロットはテナントのセキュリティ及びコンプライアンスの境界内で動作し その特定のテナントコンテキストにおけるユーザーの権限を尊重します

00:06:44.920 --> 00:06:53.100
ユーザーはゲストとしてコンテキストを切り替えることはできますがコパイロットは一度に一つのテナントに限定されます 複数のテナントを統合して一つのインテリジェントなワークスペースにし単一の回答を導き出すことはしません

00:06:53.100 --> 00:07:00.680
つまり id は横断できてもガバナンスは横断できないということです この2つを切り離して考えると経営層が使う言葉の多くが危ういほど曖昧に聞こえてきます

00:07:00.680 --> 00:07:08.440
接続されたテナント共有された id 統合されたエクスペリエンスこれらのフレーズはコラボレーションの方向性としては正しいかもしれませんが

00:07:14.920 --> 00:07:29.780
パイロットスタジオのマルチテナントモードを見るとそのギャップはより明白になります プレビュー版が示す現実は非常に限定的だからです確かにマルチテナント利用は存在しあるテナントでホストされたエージェントを別のテナントから使用することは可能ですがマルチテナントモードでのエンドユーザー認証はプレビュー版ではまだサポートされていません

00:07:29.780 --> 00:07:37.060
ゲストユーザーはサポートされていません カスタムコネクタはサポートされていませんグラフおよびマイクロソフト365標準コネクタはサポートされていません

00:07:37.060 --> 00:07:46.240
マルチジオはサポートされていませんいくつかの分析機能も利用できません またそのモードでは会話のトランスクリプトもオフになっていますそれは成熟したクロステナントのガバナンス基盤とは言えません

00:07:46.240 --> 00:07:52.600
それは明確な制限を伴う限定的なプレビューです そしてこうした制限が重要なのは多くのリーダーシップチームが自分たちに言い聞かせているストーリーを崩してしまうからです

00:07:52.600 --> 00:07:58.580
彼らはマルチテナントと聞くと運用が成熟していると想定します アーキテクトはクロステナントと聞くとポリシーが対照的であると想定します

00:07:58.580 --> 00:08:08.240
管理チームは同じベンダーと聞くと監査の一貫性が保たれていると想定します しかし展開が始まると挙動の違い信号の欠落認証や分析における厄介なギャップが露呈します

00:08:08.240 --> 00:08:16.320
第2のケースを想像してください グローバル企業がクロステナントの組織間関係を構築しユーザーエクスペリエンスがコパイロット利用にも自然に拡張されると想定します

00:08:16.320 --> 00:08:25.340
共有されたディレクトリ信頼よりスムーズなアクセス共通の id パターンといった機体は妥当に思えます しかしチームが実際にコパイロットやエージェントのシナリオをテストするとその挙動は一貫性を

00:08:25.340 --> 00:08:30.340
書きます 一部のデータは切り替えたコンテキストでしか表示されません一部の期待していたコネクタは利用できません

00:08:30.340 --> 00:08:37.540
監査における一部の期待はプレビュー機能が実際に提供するものと合致しません リーダーシップ層が依然として接続されていると信じている一方で管理チームは例外を見つけ

00:08:37.540 --> 00:08:43.320
始めますこれは技術的なエッジケースではありません ガバナンスの誤読なのですなぜなら監査人はあなたのアーキテクチャのストーリーではなく

00:08:43.320 --> 00:08:50.060
証拠をチェックするからです彼らはプロンプトがどこで実行されたか どのテナントがポリシーを適用したかどのようなログが存在するかそして連携していると説明した環境

00:08:50.060 --> 00:08:56.080
間で制御が本当に同等であったかを問うのです もしあなたの運用モデルが id をガバナンスとして扱っていたなら明確な回答は得られないでしょう

00:08:56.080 --> 00:09:05.340
ですから一つだけ覚えておいてほしいことがあります クロステナントの id はクロステナントのインテリジェンスとは異なります id はユーザーのログインを助けるものですしかしコパイロットの動作が一貫して

00:09:05.340 --> 00:09:13.500
ガバナンスされ適切に監視され企業が単一環境と呼ぶあらゆる場所で安全に拡張できるかどうかを教えて くれるわけではありませんそれが明らかになった今解決策はテナント接続を増やすことではありません

00:09:13.500 --> 00:09:24.540
アーキテクチャこそが必要です実際に機能するガバナンスモデルそれはハブ&スポークです ではプラットフォームが断片化し id が部分的でテナントの境界が依然として重要な場合真のガバナンスモデルとはどのような

00:09:24.540 --> 00:09:30.100
ものでしょうか それはハブ&スポークシステムですスライド上の図が綺麗だから提案しているのではありません

00:09:30.100 --> 00:09:40.520
皆さんが現在直面している複雑な運用環境に実際に適合するからです ガバナンスの意思決定を単一のシステムとして設計測定執行する中央拠点を構築しその決定を実行する

00:09:40.520 --> 00:09:48.580
ローカルのテナントチームが必要ですこれらのローカルチームはプレッシャーを感じる たびに独自のルールを作り出すことなく自身の境界内で作業しなければなりません

00:09:48.580 --> 00:09:58.220
まずはハブから始める必要がありますハブは単なる管理ポータルや華やかなダッシュボードではなく すべてのテナントに飛び込んで手作業でファイルを整理するような英雄的な中央チームでもありません

00:09:58.220 --> 00:10:07.080
そうではなくハブは究極のガバナンス権限を持つものとして機能します このグループがポリシー設計監査基準ラベル標準ロールアウト基準を統括します

00:10:07.080 --> 00:10:14.220
コパイロット利用の準備が整ったことの定義 証拠となるものの基準セキュリティ上の欠陥を埋める速度を決定するのは彼らです

00:10:14.220 --> 00:10:23.760
その転換が議論の全体像を変えます この構造によりグローバルは魔法の画面を指す言葉ではなく統一されたガバナンスシステムを意味するようになります

00:10:23.760 --> 00:10:29.720
パービューコントロール監査ログの取り込み 秘密ドラベルのすべてにおいて単一の基準が適用されます

00:10:29.720 --> 00:10:36.840
特定のテナントがコパイロットへのアクセスを拡大する前に満たすべき明確な基準が一つ存在します 次に必要なのがスポークです

00:10:36.840 --> 00:10:46.700
スポークはその基準を受け取り自身の環境に適用するローカルのテナント実行チームです 彼らは修正作業を実行しログを検証し広範囲にわたるアクセス権限をレビューする役割を担います

00:10:46.700 --> 00:10:56.140
しかし彼らは自由法人ではなく非常に限定された設計空間の中でそのすべての作業を行います ローカルチームが計画から逸脱する必要がある場合は例外のための正式な手順が用意されています

00:10:56.140 --> 00:11:05.720
より迅速に進めたい場合でもまずは共有された管理基準を満たす必要があります 地域的または法的な差異が生じた場合それらは誰にも知られないローカルの回避策に埋没することなく

00:11:05.720 --> 00:11:09.800
文書化され承認されるようになります この構造は極めて重要です

00:11:09.800 --> 00:11:15.880
完全に中央集権型のモデルは現場の詳細に対応できず 完全にローカルなモデルはすぐに全体的な不整合を招くからです

00:11:15.880 --> 00:11:24.240
ハブ&スポーク型はその両方の失敗パターンを回避します ハブが必要な一貫性を確保しスポークが実際の作業現場で実行スピードを提供します

00:11:24.240 --> 00:11:31.620
具体的に見ていきましょう ハブではコパイロットの展開を許可する前にすべてのテナントが実行すべき最低限のパービュー制御セットを定義します

00:11:31.620 --> 00:11:36.560
どの監査イベントを確認すべきかまたどれくらいの頻度でレビューを行うかを正確に定義します

00:11:36.560 --> 00:11:43.980
また機密コンテンツの共通ラベル体系を作成し機密 タグの意味がテナントごとにバラバラにならないようにします

00:11:43.980 --> 00:11:51.720
レビューのサイクルを設定します 全体的なセキュリティ状況は月次展開が進行中の領域ではより高い頻度で行うのが良いでしょう

00:11:51.720 --> 00:12:01.460
スポークではチームがその高レベルな基準を特定のテナントの現実に当てはめます どのサイトに広範なアクセス権が残っているかどの事業部門のラベル付けが遅れているかを特定します

00:12:01.460 --> 00:12:09.660
監査が実際に有効になっているかセキュリティチームが適切な記録を確認できる状態にあるかを確認します 公式にレビューされていない例外を作成したローカル管理者がいないか調査し

00:12:09.660 --> 00:12:16.580
パイロットグループが安全に拡大できるかそれとも一度停止して修正が必要かを判断します そしてここに厳格なルールを設けます

00:12:16.580 --> 00:12:23.120
ルールがなければこのモデルは単なる提案に過ぎず実質的なガバナンスとは言えないからです 監査ログの検証過剰な共有のスキャン完了

00:12:23.120 --> 00:12:30.760
ラベル適用の最低限の基準を満たさない限りどのテナントでもコパイロットを展開しません これらが計画段階であるとか部分的に議論されているといった話ではありません

00:12:30.760 --> 00:12:36.340
必ず検証済みでなければなりません テナントがこれら3つの条件を満たしていることを証明できなければ展開は一時停止されます

00:12:36.340 --> 00:12:43.220
厳しく聞こえるかもしれませんが ai を通じて意図しない機密情報が露出しその事後処理に膨大なコストがかかることを考えれば当然です

00:12:43.220 --> 00:12:49.740
そのように考えればこれらのルールは基本的な常識にすぎません このモデルが非常に有効なもう一つの理由はタイミングです

00:12:49.740 --> 00:12:59.240
構築を先延ばしにするほど後で自分自身が背負うことになるクリーンアップの負債が増大します 基準を満たさずに展開したテナントはすべて後にチームが解消しなければならない膨大な

00:12:59.240 --> 00:13:04.600
例外と証拠不足の山となります リーダーはガバナンスを導入後に成熟させるものと考えがちですが

00:13:04.600 --> 00:13:13.360
マルチテナントのコパイロット環境ではその順序は完全に逆です ガバナンスが展開を先導しなければ展開によってチームが吸収しきれないほどの負債が生まれることになります

00:13:13.360 --> 00:13:20.140
あなたがエンタープライズレベルでこれを主導しているなら次の取るべき行動は明確です 今すぐハブを立ち上げ今日中にベースラインを定義してください

00:13:20.140 --> 00:13:28.920
スポークを割り当て例外処理プロセスを直ちに文書化してください グローバルとはテナント自体が連携していなくても意思決定と展開ゲートが単一の

00:13:28.920 --> 00:13:35.040
システムとして機能することを意味しなければなりません モデルとは翌朝の適用ルールを実際に変える場合にのみ意味をなします

00:13:35.040 --> 00:13:41.680
リーダーが規模を拡大する前に測定すべきこと ガバナンスモデルは全員が共有できる測定基準を生み出して初めて成立します

00:13:41.680 --> 00:13:48.520
そうでなければ各テナントは独自の言葉で進捗を主張しリーダーシップは実質的なコントロールを 書いたまま状況報告を受けることになります

00:13:48.520 --> 00:13:54.860
コパイロットをさらに展開する前にアーキテクチャが想定通りに機能しているかを確認するための少数の指標が必要です

00:13:54.860 --> 00:14:01.580
アクティビティレベルでは真実は見えず導入数ではリスクを把握できません まずは過剰な共有の削減から始めるべきです

00:14:01.580 --> 00:14:12.940
これは環境がaiにとって安全になりつつあることを示す最も明白な兆候の一つです 広範なアクセスグループ公開されたシェアポイントサイトビジネスに必要な範囲を超えた古い権限設定を確認する必要があります

00:14:12.940 --> 00:14:18.900
目標は完璧な数字を出すことではなくコパイロットの普及拡大よりも先にリスクへの露出が減少していることを証明することです

00:14:18.900 --> 00:14:24.460
これら2つの線が逆方向に動いているなら根本的な問題の解決よりも早いペースで拡大していることになります

00:14:24.460 --> 00:14:32.200
2つ目の指標は過観測性のカバレッジです コパイロットがすべてのテナントで何をしているかを本格的な調査に頼る方法で把握できていますか

00:14:32.200 --> 00:14:37.360
多くの調査によればコパイロットの対話記録などの主要なデータはマイクロソフトパービューに保存されますが

00:14:37.360 --> 00:14:42.800
それは監査が全テナントで有効であることが前提です カバレッジが機能していると決めつけてはいけません

00:14:42.800 --> 00:14:48.820
どのテナントで監査ログの取り込みが有効でどのテナントの可視性が不完全なのかを正確に把握する必要があります

00:14:48.820 --> 00:14:54.720
ログがなければガバナンスもアカウンタビリティも存在しません 断定的な言い方ですがそうあるべきだからです

00:14:54.720 --> 00:14:59.500
テナントで何が起きているかを示す有効な証拠を提供できない場合そのテナントは安全に拡張する準備ができていません

00:14:59.500 --> 00:15:04.660
検査が許されないものをガバナンスすることはできず万が一の際に自分の行動を弁護することもできなくなるでしょう

00:15:04.660 --> 00:15:12.500
3つ目の指標は全テナントにおけるポリシー適用までの時間です これこそリーダーシップがハブ&スポークモデルの進化を問う場所です

00:15:12.500 --> 00:15:18.580
あるテナントが今週適用し別のテナントが検討に1ヶ月かけるようでは中央の決定は全く無意味です

00:15:18.580 --> 00:15:23.820
ポリシーが承認されてから全テナントで効果的に適用されるまでにかかる時間を測定してください

00:15:23.820 --> 00:15:28.440
発表や文書化にかかる時間のことではなく実際に稼働するまでの時間を指しています

00:15:28.440 --> 00:15:32.560
これほど変化の早いAIプログラムにおいてそうした遅延はリスクと同義です

00:15:32.560 --> 00:15:36.880
多くの組織にとって標準的な変更には72時間以内という目標が現実的です

00:15:36.880 --> 00:15:40.620
サイクルタイムがこれより大幅に長い場合まだスケーラブルなモデルとは言えません

00:15:40.620 --> 00:15:43.240
解決すべき調整の問題を抱えているだけです

00:15:43.240 --> 00:15:46.000
次にラベルのカバー率を確認する必要があります

00:15:46.000 --> 00:15:50.480
一部のテナントだけが高い数値を出し他が遅れを取るような見せかけの指標にしないでください

00:15:50.480 --> 00:15:56.780
本当に重要なのは機密コンテンツがコパイロットの判断を左右するほど一貫してラベル付けされているかどうかです

00:15:56.780 --> 00:16:02.260
完璧さを求めているのではなく組織内のすべてのテナントで同レベルの制御を求めているのです

00:16:02.260 --> 00:16:05.320
最後にアクセス権のドリフト率を追跡する必要があります

00:16:05.320 --> 00:16:09.020
この指標はクリーンアップの取り組みが長期間維持されているかどうかを教えてくれます

00:16:09.020 --> 00:16:13.060
是正プロジェクト完了後どれくらいの速さで権限が再び拡散し始めるでしょうか

00:16:13.060 --> 00:16:16.060
広範なグループがどれほどの頻度でシステムに再侵入してくるでしょうか

00:16:16.060 --> 00:16:20.020
多くのチームは修正を一度測定して問題が永遠に消えたと思い込み手遅れになってから気づきます

00:16:20.020 --> 00:16:21.320
実際には消えていません

00:16:21.320 --> 00:16:25.400
唯一重要な指標は目を離した瞬間にシステムがどれだけ早くほころび始めるかです

00:16:25.400 --> 00:16:27.440
それがあなたの運用ダッシュボードとなります

00:16:27.440 --> 00:16:33.260
過剰共有の削減、過間促成のカバー範囲、ポリシー適用までの時間、ラベル率、アクセスドリフトを追跡すべきです

00:16:33.260 --> 00:16:36.600
レポートの頻度は数値そのものと同じくらい重要です

00:16:36.600 --> 00:16:41.780
経営陣は全体像を把握する必要があるためハブ組織がエグゼクティブダッシュボードを管理すべきです

00:16:41.780 --> 00:16:47.080
一方で実際の作業はテナントの協会で行われる必要があるためスポーク組織が是正を担当します

00:16:47.080 --> 00:16:50.220
一方のチームがシステムを監視しもう一方のチームがそれを修正します

00:16:50.220 --> 00:16:53.360
これらの数値は拡大後ではなく拡大前に追跡しなければなりません

00:16:53.360 --> 00:16:56.420
リスクは次の会議やガバナンスワークショップまで待ってくれません

00:16:56.420 --> 00:17:01.580
現在の管理策が見逃している箇所をコパイロットが特定できる場所ではリスクはすでに存在しています

00:17:01.580 --> 00:17:03.860
リーダーが見落としがちな2つのパターン

00:17:03.860 --> 00:17:05.940
現場で特定の2つのパターンをよく見かけますが

00:17:05.940 --> 00:17:11.160
どちらもリーダーがコパイロットを単なるソフトウェアのローンチと捉え重要な管理イベントとして扱っていないために発生します

00:17:11.160 --> 00:17:17.800
最初のパターンは組織がパービューの基準を明確にしたりシェアポイントのアクセス権を見直したりする前にコパイロットを展開することで始まります

00:17:17.800 --> 00:17:19.900
初日展開は完璧に見えます

00:17:19.900 --> 00:17:24.820
ライセンスは割り当てられユーザーは興奮し社内メッセージは生産性の向上一色になります

00:17:24.820 --> 00:17:28.420
しかし通常のプロンプトで技術的には以前からアクセス可能だったものの

00:17:28.420 --> 00:17:31.880
実質的には一般的な従業員から見えていなかった資料が検索されるようになります

00:17:31.880 --> 00:17:34.700
AIが登場する前は古いサイトや使われていないフォルダー

00:17:34.700 --> 00:17:38.420
継承されたアクセス権などをわざわざクリックして見てはいけないものを見つけようとする人はいませんでした

00:17:38.420 --> 00:17:40.520
しかし今ではその必要もありません

00:17:40.520 --> 00:17:44.440
ユーザーが基本的な質問をすると要約が返されファイルが表示されます

00:17:44.440 --> 00:17:47.000
それは人事関連の機密コンテンツや財務資料

00:17:47.000 --> 00:17:50.040
あるいはごく限られた範囲に留めるべき取引情報かもしれません

00:17:50.040 --> 00:17:52.040
侵害があったわけでもマルウェアがあったわけでも

00:17:52.040 --> 00:17:54.280
従来の意味でのセキュリティ協会が破られたわけでもありません

00:17:54.280 --> 00:17:58.380
システムは単にそのテナントがすでに許可していたアクセス権とコンテンツの状態を利用しただけなのです

00:17:58.380 --> 00:18:01.160
その瞬間に多くのチームがようやくこの問題を理解します

00:18:01.160 --> 00:18:03.120
AIが露出を作り出したわけではありません

00:18:03.120 --> 00:18:05.780
AIはこれまで露出を隠していた摩擦を取り除いただけなのです

00:18:05.780 --> 00:18:09.720
一つのテナントでそれが起きると組織全体の経営人の信頼は通常低下します

00:18:09.720 --> 00:18:13.320
次にどこで同じパターンが現れるか誰にも確信が持てないからです

00:18:13.320 --> 00:18:15.380
インシデントは局所的なものに見えるかもしれませんが

00:18:15.380 --> 00:18:17.220
信頼へのダメージは全社規模に及びます

00:18:17.220 --> 00:18:20.100
二つ目のパターンはより静かですが同じくらい危険です

00:18:20.100 --> 00:18:24.160
ある企業がテナント間のID関係を設定しマルチテナントシナリオが可能だと聞くと

00:18:24.160 --> 00:18:27.760
自分たちの運用モデルは広範な展開に十分対応できると想定してしまいます

00:18:27.760 --> 00:18:30.500
スライド上ではそれは堅実な計画のように聞こえます

00:18:30.500 --> 00:18:32.900
しかし現実には運用は混乱を招きます

00:18:32.900 --> 00:18:36.080
あるチームは全ての接続環境でスムーズなコパイロット体験を期待し

00:18:36.080 --> 00:18:38.100
別のチームは同等の可視性を期待し

00:18:38.100 --> 00:18:41.460
3番目のチームは同じコントロールがどこでもユーザーに推奨すると想定します

00:18:41.460 --> 00:18:44.660
そして実際の利用が始まると一貫性のない挙動認証のギャップ

00:18:44.660 --> 00:18:47.100
そして実際に測定可能な範囲の弱点が露呈し始めます

00:18:47.100 --> 00:18:49.700
問題はこれらのチームが不注意だったということではありません

00:18:49.700 --> 00:18:53.100
真の問題は彼らが接続性を保証アシュアランスと取り違えてしまったことです

00:18:53.100 --> 00:18:55.980
その思い込みがコンプライアンスに関する誤った物語を作り上げてしまいます

00:18:55.980 --> 00:18:59.860
リーダーシップは接続済みという言葉を聞いて組織は準備ができていると想定してしまいます

00:18:59.860 --> 00:19:06.080
数ヶ月後コントロールのレビューを行うと挙動エビデンスそして強制力が開始時に誰かが認めたがっていたよりもはるかにバラバラだったことが判明します

00:19:06.080 --> 00:19:08.320
ではそれより優れたパターンと比較してみましょう

00:19:08.320 --> 00:19:11.440
別の組織は規模を拡大する前に歩みを緩めることを選択します

00:19:11.440 --> 00:19:16.960
彼らはまずラベルのベースラインを設定し後半なアクセスを先にレビューし他のことを行う前に監査の可視性を検証します

00:19:16.960 --> 00:19:19.280
彼らはコパイロットを段階的に拡大していきます

00:19:19.280 --> 00:19:24.880
それは導入を恐れているからではなく次の波が始まる前に各波から利用可能なエビデンスを得たいと考えているからです

00:19:24.880 --> 00:19:33.840
その組織は驚きへの説明や露出したコンテンツの修正あるいはガバナンスが本来何を意味していたのかという議論のために絶えず立ち止まる必要がないため長期的にはより早く進むことができます

00:19:33.840 --> 00:19:36.240
それが多くのリーダーが見落としている利点です

00:19:36.240 --> 00:19:38.780
適切なガバナンスは展開を妨げるものではありません

00:19:38.780 --> 00:19:42.140
これにより第一波が完了した後の展開における停滞が解消されます

00:19:42.140 --> 00:19:50.160
落とし穴は導入そのものではありません落とし穴は遠くからは繋がって見えても近くで見ると全く異なる動きをするテナント間での管理されていない導入です

00:19:50.160 --> 00:19:53.240
あなたが下すべき決断は実は非常にシンプルです

00:19:53.240 --> 00:20:00.160
今すぐ連合型のハブ&スポークAIガバナンスモデルへ移行しテナントごとの切り替えを真の制御だと勘違いするのをやめるべきです

00:20:00.160 --> 00:20:07.020
ログ記録過剰共有のレビューラベルのベースライン網羅性を証明できないテナントではコパイロットの拡大を一時停止すべきです

00:20:07.020 --> 00:20:11.180
AIはあなたが報告する組織図ではなくあなたが実際に構築したシステムに従うのです

00:20:11.180 --> 00:20:16.200
今回の話でマルチテナントコパイロットガバナンスへの考え方が変わったならリンクトインでミルコピータースをフォローしてください

00:20:16.200 --> 00:20:19.580
もし現在これらの問題に直面しているならチームと共有してください