WEBVTT

00:00:00.000 --> 00:00:07.200
マイクロソフト365、コパイロット、AI、Azure、そして働き方の未来を築く人々が集う10日間、準備はいいですか?

00:00:07.360 --> 00:00:12.360
この1月、M365コンが帰ってきます。さらに規模を拡大して開催します。

00:00:12.600 --> 00:00:18.520
世界中のMVPや業界エキスパートによるライブセッション、実世界でのデモ、そして実践的な知識にぜひご参加ください。

00:00:18.680 --> 00:00:21.940
ありきたりなスライドや、終わりのない専門用語の羅列はありません。

00:00:21.940 --> 00:00:29.280
コパイロットスタジオ、AIエージェント、ファブリック、セキュリティ、ガバナンス、自動化といった現実の課題に取り組みます。

00:00:29.280 --> 00:00:35.040
ITプロフェッショナル、開発者、ビジネスリーダーの皆様、それぞれの役割に合わせたセッションをご用意しています。

00:00:35.220 --> 00:00:40.660
10日間の充実した期間を通じて、多様な技術を探求し、世界中のコミュニティとつながることができます。

00:00:40.880 --> 00:00:44.660
ライブで視聴し、実践的な洞察を組織に持ち帰りましょう。

00:00:45.120 --> 00:00:51.040
2027年1月、10日間、一つのマイクロソフトコミュニティ、登録受付中です。

00:00:52.700 --> 00:00:54.780
今すぐ場所を確保してください。

00:00:54.780 --> 00:00:59.300
サイトはメートル365コンドットネットです。

00:00:59.500 --> 00:01:04.800
メートル365コンドットネットから今すぐ登録を、1月のライブでお会いしましょう。

00:01:05.000 --> 00:01:09.120
AIエージェントが気づかないうちに勝手に判断を下し始めたらどうなるでしょうか。

00:01:09.260 --> 00:01:11.700
本日のセッションでは、なぜガバナンスがもはや不可欠なのか、

00:01:11.940 --> 00:01:16.140
そしてマイクロソフト365管理センターがどのように必要なコントロールパネルを提供できるのかを解説します。

00:01:16.140 --> 00:01:18.880
チームが必要なものを構築できるように権限を与えつつ、

00:01:19.180 --> 00:01:21.920
エージェントが暴走するのを防ぐための具体的なツールを紹介します。

00:01:22.060 --> 00:01:27.120
監視を怠らずにコパイロットのメリットを最大限に生かす方法をお探しなら、ここが最適な場所です。

00:01:27.320 --> 00:01:30.300
なぜこれほど多くの組織がAIエージェントを恐れるのでしょうか。

00:01:30.440 --> 00:01:34.500
AIエージェントの利点が理論上これほど明確なのに、なぜ企業は二の足を踏むのでしょうか。

00:01:34.580 --> 00:01:37.780
手作業の削減、意思決定の迅速化、データの有効活用。

00:01:37.940 --> 00:01:40.900
表面上は、承認をためらう理由がないほどの成功に見えます。

00:01:46.140 --> 00:01:49.080
このためらいは、技術への不信感から来るものではありません。

00:01:49.240 --> 00:01:56.640
明確な監視体制がないまま、何百何千もの小さな自動化がバックグラウンドで動き出した時、何が起こるかという恐怖から来るものです。

00:01:56.800 --> 00:02:04.300
大きな可能性と、それと同等の大きな不確実性との間の緊張感により、多くの組織が予想以上に長くパイロット運用の段階に留まっています。

00:02:04.480 --> 00:02:09.060
現実として、AIエージェントが人々を不安にさせるのは、他のツールとは異なる動きをするからです。

00:02:09.060 --> 00:02:16.020
従業員による新しい生産性アプリのインストールを管理したり、エンドポイント管理でソフトウェアをブロックしたりすることはできますが、エージェントはそうした枠にはうまく収まりません。

00:02:16.140 --> 00:02:19.820
エージェントは、時として迅速に、時として複数のシステムをまたいで動作するように設計されています。

00:02:20.000 --> 00:02:23.040
一度リリースされると、まるで勝手に動いているかのように感じられることがあります。

00:02:23.040 --> 00:02:32.900
制御、標準化、ガバナンスの観点から考える訓練を受けてきたITリーダーにとって、目に見えないバックグラウンドプロセスが実際の情報の流れを形成しているという状況は、組織の統制を完全に失っているかのように感じられるかもしれません。

00:02:33.080 --> 00:02:35.360
その結果がどうなるかを示す事例は数多くあります。

00:02:35.580 --> 00:02:38.720
ある研究チームが、データセットを抽出、整理するボットを立ち上げました。

00:02:38.920 --> 00:02:41.480
それを見た別の誰かが少しだけ調整を加えてコピーを作成します。

00:02:41.680 --> 00:02:44.940
数週間もすると、会社では適切に管理されたエージェントが一つ動いている状態ではなくなります。

00:02:44.940 --> 00:02:49.340
小さな違いがある20ものクローンが乱立し、バージョン管理も責任者も不明な状態です。

00:02:49.480 --> 00:02:58.160
ベルリンのアナリストが使うデータとニューヨークのマネージャーが使うデータに微妙なズレが生じ、財務部門は両方のデータが混在したレポートに頭を抱えています。

00:02:58.700 --> 00:03:06.720
これを何十もの部門で繰り返せば、生産性を高めるはずが、どの数値を信用すべきかという疑念に変わってしまいます。

00:03:06.940 --> 00:03:11.800
また、自動化が本来触れるべきでない領域にまで踏み込んでしまった事例も見てきました。

00:03:11.800 --> 00:03:21.400
ある会社では、オンボーディングを効率化するために顧客情報をシステム間で移動させる社内スクリプトがありましたが、データ転送がコンプライアンス基準を満たしているか誰も確認していませんでした。

00:03:21.580 --> 00:03:28.320
監査が入った際、組織は誰が作成し、なぜ実行され、どのようなルールに基づいていたのかを証明する記録を提示できませんでした。

00:03:28.540 --> 00:03:30.680
それはAIの能力不足ではありません。

00:03:30.860 --> 00:03:32.620
統制の欠如による失敗です。

00:03:32.860 --> 00:03:37.900
時間を節約するための技術が、会社にとってここ数年で最大のコンプライアンス上の悩みの種となりました。

00:03:37.900 --> 00:03:40.360
リーダーたちが慎重になるのも無理はありません。

00:03:40.560 --> 00:03:46.400
制限なしにエージェントを導入するのは、全従業員にドローンを渡し、好きな場所へ飛ばさせるようなものです。

00:03:46.600 --> 00:03:54.940
最初は順調に離陸しても、すぐに建物に衝突したり、行方不明になったり、緊急ヘリの着陸を妨げたりするドローンが出てくるでしょう。

00:03:55.160 --> 00:04:00.440
完成等がなければ、効率化をもたらすはずの技術そのものが、公共の危険物となってしまいます。

00:04:00.640 --> 00:04:02.900
同じ原則がナレッジワークにも当てはまります。

00:04:03.140 --> 00:04:05.340
自動化そのものが恐ろしいわけではありません。

00:04:05.340 --> 00:04:07.760
恐ろしいのは、管理ができていないことです。

00:04:07.880 --> 00:04:10.780
調査の結果も、こうした話から推測できる通りです。

00:04:10.920 --> 00:04:16.560
経営陣は、エンタープライズAIに関する主な懸念事項として、一様にコンプライアンス、セキュリティ、データ漏洩を挙げています。

00:04:16.740 --> 00:04:19.660
技術が成果をもたらすかどうかは、ほとんど問題ではありません。

00:04:19.820 --> 00:04:25.520
懸念されているのは、誤った情報が流出することや、後から追跡できないアクションをボットが実行してしまうことです。

00:04:25.700 --> 00:04:28.280
問題は、単なる業務上のミスに留まりません。

00:04:28.280 --> 00:04:32.740
評判、規制リスク、そして顧客からの信頼にまで直接的に影響します。

00:04:32.940 --> 00:04:37.680
自動化によって本来守るべきデータが流出したと顧客が信じれば、信頼を取り戻すには何年もかかります。

00:04:37.880 --> 00:04:40.580
だからこそ、真の問題を正しく認識することが重要なのです。

00:04:40.720 --> 00:04:43.360
企業はコパイロットエージェントそのものを恐れているわけではありません。

00:04:43.540 --> 00:04:45.160
見失うことを恐れているのです。

00:04:45.360 --> 00:04:51.400
誰がどのアージェントを構築し、いつ最後に確認され、なぜ機密システムから情報を引き出しているのかを忘れてしまうことを恐れているのです。

00:04:51.400 --> 00:04:56.920
問題はソフトウェアではなく、信頼性と予測可能性を維持し、組織のルールに沿った運用を支えるガードレールが欠けていることです。

00:04:57.100 --> 00:04:59.840
そのように捉えると、今後の進むべき道がはっきりと見えてきます。

00:05:00.080 --> 00:05:02.360
そして、ほとんどの人が驚くのはここからです。

00:05:02.540 --> 00:05:07.400
多くの組織が必要だと思っている管理ボードは、実はすでにMicrosoft 365の中に存在しています。

00:05:07.600 --> 00:05:09.000
別売りのアドオンではありません。

00:05:09.160 --> 00:05:10.840
隠されたプレミアム機能でもありません。

00:05:11.000 --> 00:05:12.900
管理センターに標準で組み込まれています。

00:05:12.900 --> 00:05:20.960
多くの組織はそのポータルをライセンス割り当てや基本的なチームポリシーの設定にしか使っていませんが、実はすでにコパイロットエージェントの完成塔として機能しているのです。

00:05:21.100 --> 00:05:24.540
言い換えれば、必要なガードレールはすでに皆さんの目の前にあるということです。

00:05:24.720 --> 00:05:27.780
唯一の問題は、正しいパネルを開いているかどうかだけです。

00:05:27.980 --> 00:05:29.920
存在すら知らなかったコントロールパネル。

00:05:30.120 --> 00:05:35.720
もし、AIエージェントを管理するためのコックピットがすでに目の前にあり、多くの管理者が単に気づいていなかったとしたらどうでしょうか。

00:05:35.720 --> 00:05:43.120
信じがたい話かもしれませんが、実はマイクロソフト365管理センターには、多くの組織が探し求めていたカジトリの機能が静かに備わっているのです。

00:05:43.240 --> 00:05:50.140
皮肉なことに、多くのITチームは毎日このポータルを開きながら、エージェントのガバナンスにとって最も重要な部分を見過ごしています。

00:05:50.360 --> 00:05:54.620
考えてみれば、これは慣れ親しんでいることが逆にあだとなっている状況と言えます。

00:05:54.840 --> 00:06:00.520
中身を知っていると思い込んでいるため、普段無視しているタブの裏側に新たな管理機能があるとは予想もしないのです。

00:06:00.520 --> 00:06:03.960
長年、管理センターは単なるユーティリティパネルとして扱われてきました。

00:06:04.100 --> 00:06:09.480
ライセンスを配布したり、エクスチェンジメールボックスを設定したり、チームのポリシーを少し調整したりするために開く場所でした。

00:06:09.620 --> 00:06:16.000
ユーザーに機能を割り当て、リクエストがあったサービスへ確実にアクセスできるようにするための実務的な場所だったのです。

00:06:16.180 --> 00:06:19.720
見過ごされがちなのは、その機能がどれほど充実してきたかということです。

00:06:19.720 --> 00:06:27.380
同じインターフェースの裏側には、誰がアクセスできるかだけでなく、人々がどのように自動化を作成、利用、共有するかを管理するための機能が日々増えています。

00:06:27.540 --> 00:06:33.080
もしコパイロットエージェントの制御不能を懸念しているなら、そのガードレールは数回クリックするだけで見つかるはずです。

00:06:33.220 --> 00:06:34.880
このミスマッチは明らかです。

00:06:35.060 --> 00:06:46.220
ITフォーラムでは、AIの混沌、各部署で勝手に現れるボット、秘密データに触れる自動化、あるいは支えながら深刻な違いを持つワークフローの重複といった懸念が議論されています。

00:06:46.220 --> 00:06:52.460
しかし、そうした懸念を口にする組織ほど、まさにそれを防ぐために設計された中央ダッシュボードをほとんど見ていないのです。

00:06:52.580 --> 00:06:53.660
奇妙な乖離です。

00:06:53.840 --> 00:06:58.500
私たちはコントロールを失うことを恐れながら、機構を調整するために存在するコントロールパネルを十分に活用できていません。

00:06:58.700 --> 00:07:03.300
それは、過度にある信号機を無視しながら、予測できない交通渋滞に文句を言っているようなものです。

00:07:03.440 --> 00:07:06.180
大企業における典型的なシナリオを想像してみてください。

00:07:06.180 --> 00:07:12.040
マーケティング部門では誰かが顧客フィードバック収集用のエージェントを作成し、オペレーション部門では注文追跡を効率化するボットを設計しています。

00:07:12.200 --> 00:07:14.260
これらは決して意図的なシャドウITではありません。

00:07:14.440 --> 00:07:17.100
熱心な従業員が日々の業務を楽にしようとしているだけなのです。

00:07:17.240 --> 00:07:21.160
しかし、それらのエージェントが稼働し始めると、統合された記録がないまま別々のサイロに分散してしまいます。

00:07:21.340 --> 00:07:26.200
IT部門がそれらを見つけた時には、誰が何を所有し、どのデータソースを利用しているのかを把握することは不可能です。

00:07:26.200 --> 00:07:29.400
突然、コンプライアンスに関する話し合いが、まるで探偵のような作業に変わってしまいます。

00:07:29.540 --> 00:07:34.300
一体誰がこれを作ったのか?いつ更新されたのか?どのような権限を密かに継承しているのか?

00:07:34.420 --> 00:07:38.860
明確な監視体制がなければ、小さな自動化であっても、誰も予期しなかったコンプライアンス上の欠陥に発展しかねません。

00:07:39.000 --> 00:07:43.440
管理センターは、こうした目に見えない活動をすべて一箇所に集約することで、この問題に直接対処します。

00:07:43.440 --> 00:07:49.580
推測する代わりに、どのエージェントが存在し、何に依存し、誰が編集や公開の権限を持っているのかを確認できます。

00:07:49.760 --> 00:07:56.600
ポリシーによって、そもそもどのグループが自動化を作成できるかを定義できるため、実験と正式な展開を切り離すことができます。

00:07:56.820 --> 00:07:58.300
これは非常に重要です。

00:07:58.480 --> 00:08:04.520
チーム内での施策と、CRMや人事プラットフォーム全体に影響を与えるものの構築では、意味が大きく異なるからです。

00:08:04.660 --> 00:08:07.200
管理センターでは、それらを明確に区別して維持できます。

00:08:07.400 --> 00:08:09.980
権限設定によって、さらなる安全性が確保されます。

00:08:09.980 --> 00:08:16.220
熱心な従業員全員がエージェントを作成できるだけでなく、全社規模で公開できてしまった場合のリスクは容易に想像できます。

00:08:16.420 --> 00:08:22.760
より良いモデルは、アイデア構築には幅広く参加させつつ、展開の権限は特定の役割に限定することです。

00:08:22.940 --> 00:08:32.880
例えば、財務アナリストがレポート作成のためにエージェントのドラフトを作成し、そのドラフトを本番環境に適用するかどうかはITガバナンスチームが決定する、といった形です。

00:08:33.040 --> 00:08:38.160
管理センターでこれらのルールを設定することで、誰が空域の規則を決めるかを事前に決定できます。

00:08:38.160 --> 00:08:40.760
レポーティング機能がこのサイクルを完結させます。

00:08:40.880 --> 00:08:49.720
問題が起きてからボットの存在を知るのではなく、利用動向を追跡し、どの部署が積極的に実験しているかを把握し、個別のスプレッドシートを追いかけることなく監査を実施できます。

00:08:49.920 --> 00:08:54.180
このデータに基づいた視点は、コンプライアンスだけでなく、戦略立案にも役立ちます。

00:08:54.340 --> 00:09:02.260
もしサポートチームが似たようなエージェントを何度も作成しているなら、バラバラに放置するよりも標準化されたソリューションへの投資を検討すべきかもしれません。

00:09:02.260 --> 00:09:07.800
可視性と制御を組み合わせることで、自動化は頭痛の種から管理可能なチャンスへと変わります。

00:09:07.980 --> 00:09:13.740
エージェントが無秩序に飛び回ることを想像する代わりに、管理センターを航空管制等として捉えてみてください。

00:09:13.960 --> 00:09:20.740
すべての飛行計画が記録され、すべての出発がポリシーに基づいて許可され、空全体が見渡せるために衝突が起こることもありません。

00:09:20.920 --> 00:09:28.160
中央ダッシュボードがこの力を秘めていると認識すれば、エージェントを潜む脅威としてではなく、構造化された業務として運用できるようになります。

00:09:28.380 --> 00:09:31.560
そのフレームワークが整うと、会話の内容が変わってきます。

00:09:31.780 --> 00:09:37.540
管理者が監視できる一方で、従業員もその境界線を超えることなく、構築や試行錯誤を行う余地が必要です。

00:09:37.720 --> 00:09:40.440
そこでまさに、コパイロットスタジオの出番となるわけです。

00:09:40.620 --> 00:09:43.760
混乱のないイノベーション、それがコパイロットスタジオの実力です。

00:09:43.760 --> 00:09:49.080
組織を混乱させることなく、従業員に独自のAIソリューションを作らせるにはどうすれば良いでしょうか?

00:09:49.200 --> 00:09:52.040
それがコパイロットスタジオにおける中心的な課題です。

00:09:52.040 --> 00:10:00.240
一方で、このツールは部門を超えた創造性を解き放つように設計されており、日々の業務の課題を理解している当事者が、それを直接自動化できるチャンスを与えます。

00:10:00.420 --> 00:10:09.080
その一方で、監視なしに構築ツールを配布すれば、管理不能なワークフローがあふれかえり、IT部門は何が実行されているのか把握できず奔走することになりかねません。

00:10:09.260 --> 00:10:11.920
それは一見、非常に難しいバランスのように思えます。

00:10:12.100 --> 00:10:15.920
ユーザーに権限を与えて混乱を招くか、それとも全てをロックダウンして進歩を阻むか。

00:10:15.920 --> 00:10:18.980
コパイロットスタジオは、その中間に位置するソリューションです。

00:10:19.160 --> 00:10:25.840
従業員がソリューションを試作し、対話をテストし、さらにはエージェントを公開して業務を改善できるワークショップのようなものだと考えてください。

00:10:26.020 --> 00:10:28.800
過去のDIY自動化との違いはシンプルです。

00:10:28.980 --> 00:10:31.920
プラットフォームには、すでにガードレールが組み込まれています。

00:10:32.140 --> 00:10:40.580
事後にIT部門に後始末をさせるのではなく、スタジオは管理センターで管理しているのと同じガバナンス原則を使用し、それを設計環境に直接組み込んでいます。

00:10:40.800 --> 00:10:43.500
それこそが、リスクを抑えつつ実用性を高めている理由です。

00:10:43.620 --> 00:10:46.220
とはいえ、管理者にとっての懸念は非常に現実的なものです。

00:10:46.380 --> 00:10:53.400
熱心なスタッフがスクリプトツールを手にした時に何が起こるかを目にしたことがあれば、単なるテストがどれほど素早くミッションクリティカルな依存関係に発展するかをご存知でしょう。

00:10:53.640 --> 00:10:55.560
問題は、悪意があることではありません。

00:10:55.700 --> 00:10:58.740
ほとんどのユーザーは、単に自分の抱えるボトルネックを解決したいだけなのです。

00:10:58.740 --> 00:11:06.580
しかし、そうして構築されたローカルなソリューションが顧客データや財務記録、人事ファイルにアクセスし始めると、便利な実験の域を超え、コンプライアンスの領域に踏み込んでしまいます。

00:11:06.780 --> 00:11:10.820
その一線を超えた瞬間、説明責任と監視はもはや選択肢ではなくなります。

00:11:10.980 --> 00:11:12.860
このようなシナリオを想像してみてください。

00:11:13.060 --> 00:11:17.900
財務アナリストが、顧客の残高を自動的に取得して周辞レポートを作成するエージェントを構築します。

00:11:18.060 --> 00:11:21.300
手作業の時間を大幅に削減できるため、すぐに人気が出ます。

00:11:21.520 --> 00:11:24.940
数人の同僚がそれを利用し始め、やがて部門全体へと広がっていきます。

00:11:25.220 --> 00:11:26.800
しかし、ここに落とし穴があります。

00:11:27.060 --> 00:11:30.180
そのエージェントが機密項目を公開していないことを、誰が保証したのでしょうか?

00:11:30.280 --> 00:11:34.860
データソースが財務情報の取り扱いに関するコンプライアンス規則に適合していることを、誰が確認したのでしょうか?

00:11:35.020 --> 00:11:40.560
そして、規制当局が調査に来た時、これがサイドプロジェクトではなくポリシーに従って構築展開されたものだと誰が証明するのでしょうか?

00:11:40.560 --> 00:11:44.260
適切な構造がなければ、その単純なボットはリスクの種となってしまいます。

00:11:44.380 --> 00:11:47.200
これこそが、コパイロットスタジオが状況を改善するポイントです。

00:11:47.340 --> 00:11:50.540
このプラットフォームは、すべての作成者がプロの開発者であることを前提としてはいません。

00:11:50.740 --> 00:11:54.080
その設計全体に、技術者ではないユーザーを守るための保護機能が組み込まれています。

00:11:54.240 --> 00:11:59.700
管理者は、使用可能なアクションやコネクタ、そして本番環境への公開権限を持つユーザーを定義します。

00:11:59.920 --> 00:12:05.320
従業員は完全な捜索の自由があると感じるかもしれませんが、実際には慎重に制限された範囲内での施行です。

00:12:05.520 --> 00:12:10.280
その違いこそが、シャドウITの問題を招くことなく、企業がエージェントの導入を拡大できる理由です。

00:12:10.420 --> 00:12:12.500
コントロールポイントは具体的に設定されます。

00:12:12.660 --> 00:12:17.820
例えば、マーケティング部門全員にエージェントの草案作成を許可しつつ、公開は特定の担当者のみに限定できます。

00:12:17.880 --> 00:12:21.840
あるいは、シェアポイントやダイナミクスなど、承認済みのコネクタのみを利用可能にすることもできます。

00:12:22.020 --> 00:12:25.400
一方で、機密性の高いサードパーティサービスに触れるものは制限されます。

00:12:25.600 --> 00:12:28.840
さらに、どのシステムアクションを制限するかを決定することも可能です。

00:12:29.020 --> 00:12:34.320
例えば、データベースの紹介は良くても、重要なフィールドの直接更新は誤った操作を防ぐためにロックされます。

00:12:34.460 --> 00:12:39.620
つまり、ユーザーはアイデアを試せますが、明示的な承認なしに本番環境の記録を変更することはできません。

00:12:39.620 --> 00:12:41.560
シンプルな例えで説明しましょう。

00:12:41.720 --> 00:12:43.380
遊び場の砂場のようなものです。

00:12:43.520 --> 00:12:47.760
子供は砂場の中で自由に城を作れますが、その周囲には明確な境界線があります。

00:12:47.960 --> 00:12:52.700
フェンスがあることで、遊びの安全を保ちつつ、創造性を発揮する余地も十分に確保されます。

00:12:52.880 --> 00:12:55.820
スタジオは、このコンセプトをエージェント作成にもたらします。

00:12:56.060 --> 00:13:02.480
従業員は確信に必要な自由を感じられ、管理者は見えないフェンスがリスクの拡大を防いでいると把握できます。

00:13:02.600 --> 00:13:10.120
適切な権限とポリシーでコパイロットスタジオを設定すれば、セキュリティの悩みの種ではなく、本来あるべき安全なイノベーションラボになります。

00:13:10.120 --> 00:13:15.020
各部門は業務に合わせたエージェントを模索し、新しい手法を試し、初期のアイデアを共有できます。

00:13:15.180 --> 00:13:18.900
もちろん、コンプライアンス違反や非公式なワークフローを増やすことはありません。

00:13:19.060 --> 00:13:21.380
イノベーションは続きますが、混乱は生じません。

00:13:21.620 --> 00:13:24.840
そのような保護壁があっても、無視できないもう一つの安全策があります。

00:13:25.120 --> 00:13:26.540
それは、可視性です。

00:13:26.740 --> 00:13:30.460
どれほど強固なガードレールがあってもリアルタイムで何が起きているかを監視する必要があるからです。

00:13:30.620 --> 00:13:32.620
そこで、監視と追跡の出番です。

00:13:32.800 --> 00:13:35.820
監視棟のように、エージェントの活動を監視し追跡します。

00:13:36.040 --> 00:13:39.440
もしエージェントが、あなたの知らないところで何百もの決定を密かに言っていたらどうでしょう?

00:13:39.660 --> 00:13:41.500
それは決してありえない話ではありません。

00:13:41.700 --> 00:13:46.400
組織がコントロールを設定しながらも、その半分を忘れてしまうと、まさにそのような事態が起こり得ます。

00:13:46.580 --> 00:13:48.620
権限とポリシーはフェンスのようなものです。

00:13:48.820 --> 00:13:52.480
それらは従業員に対して、どこで作成が許可され、どのツールが使用可能かを伝えます。

00:13:52.580 --> 00:13:56.200
しかし、可視性がなければ、誰かがチェックされていない領域に迷い込んだり、

00:13:56.440 --> 00:13:59.620
エージェントが本来の範囲外で密かに動作したりしていることを知る術はありません。

00:13:59.780 --> 00:14:04.320
監視こそが、ガバナンスという物語を推測の域から脱却させ、明確にするための要素なのです。

00:14:04.500 --> 00:14:07.380
私たちが普段、ITの問題にどう対処しているか考えてみてください。

00:14:07.600 --> 00:14:11.780
何かが壊れ、ユーザーからチケットが届き、私たちは慌てて変更箇所を辿ることになります。

00:14:12.020 --> 00:14:13.500
それは受動的なアプローチです。

00:14:13.700 --> 00:14:17.720
小規模なら通用しますが、数百もの自動化に拡大すると手に負えないコストとなります。

00:14:17.920 --> 00:14:22.280
AIエージェントの場合、問題が手遅れになるまで見えないため、リスクはより大きくなります。

00:14:22.460 --> 00:14:25.980
意図しないワークフローが、誰にも気づかれずに数週間も実行される可能性があります。

00:14:26.200 --> 00:14:30.640
派手に失敗するわけではなく、表面上は妥当に見える判断を静かに行い続けるからです。

00:14:30.640 --> 00:14:35.620
データが合わない理由を誰かが指摘する頃には、未来の防止ではなく、過去の調査に追われることになります。

00:14:35.760 --> 00:14:38.200
監視があれば、そのサイクルを完全に変えることができます。

00:14:38.360 --> 00:14:43.280
手探りで作業するのではなく、どのようなエージェントが存在し、誰が作成し、どう利用されているかをリアルタイムで把握できます。

00:14:43.460 --> 00:14:47.140
マイクロソフト365は、この可視性をエコシステム全体に組み込んでいます。

00:14:47.180 --> 00:14:56.220
利用状況分析により、どの部署がエージェントを急速に導入しているか、誰が熱心に作成しているか、予期せぬ活動がどこで発生しているかを確認できます。

00:14:56.400 --> 00:14:58.280
監査ログで詳細を追跡します。

00:14:58.480 --> 00:15:02.660
エージェントがいつ修正され、どのコネクタに触れ、誰がそのアクションを実行したかまで記録されます。

00:15:02.820 --> 00:15:05.540
こうした追跡記録は、コンプライアンスを満たすだけのものではありません。

00:15:05.740 --> 00:15:09.240
推測ではなく、実環境を正確に理解するために必要なものなのです。

00:15:09.380 --> 00:15:12.820
その洞察の価値は、ありふれたシナリオを想像するとわかります。

00:15:13.000 --> 00:15:16.500
マーケティングチームが顧客アンケートを分析するエージェントを作成します。

00:15:16.740 --> 00:15:21.160
最初は小規模に、一つのキャンペーンで数千件のデータを扱い、有益な結果が出ます。

00:15:21.340 --> 00:15:26.460
やがて誰かがそれを複製して別のプロジェクトに流用し、別のチームがテンプレートを微調整して使い始めます。

00:15:26.460 --> 00:15:32.340
監視がなければ、異なるバージョンのエージェントが並行して動き、それぞれが少しずつ異なるデータにアクセスすることになります。

00:15:32.520 --> 00:15:37.660
放置すれば、その際はやがてレポートに紛れ込み、経営層の意思決定を混乱させます。

00:15:37.820 --> 00:15:47.800
監視があれば、エージェント利用の急増を早期に察知し、複製を把握し、公式版を標準化するか、誤解を招く前に不要な版を停止できます。

00:15:48.040 --> 00:15:53.080
可視性の有無は、軽微な修正で済むか、ニュースになるほどの事件になるかの分かれ目です。

00:15:53.080 --> 00:15:57.960
例えば、内部予測を効率化するために財務の機密データを取得するエージェントを考えてみましょう。

00:15:58.200 --> 00:16:04.760
詳細を誤って公開したり、経理部門以外がアクセス可能になったりすれば、コンプライアンスリスクは急速に拡大します。

00:16:04.940 --> 00:16:08.380
しかし監視があれば、異常なアクセスはログにはっきりと現れます。

00:16:08.560 --> 00:16:12.960
規制当局や顧客から指摘を受ける前に、停止したり権限を調整したりできるのです。

00:16:13.120 --> 00:16:15.760
これは作成者の悪意を疑うということではありません。

00:16:15.980 --> 00:16:20.020
慎重なチームであっても、試行錯誤の過程でミスは起こり得るという前提に立つものです。

00:16:20.020 --> 00:16:23.800
可視性があるからこそ、そうしたミスが致命傷にならず、やり直しが効くのです。

00:16:23.920 --> 00:16:27.120
レポート機能は、監査担当者との関係を円滑にすることにも役立ちます。

00:16:27.280 --> 00:16:34.900
監査を経験したことのある人なら誰でも、文書の収集や、誰が何を承認したか、いつ変更が行われたか、管理策が実際に機能していたかを確認するために奔走する苦労を知っているはずです。

00:16:35.060 --> 00:16:38.160
手動での追跡はミスを招きやすく、大きなストレスとなります。

00:16:38.360 --> 00:16:42.380
レポーティングシステムがそれらの記録を保持していれば、もう慌てる必要はありません。

00:16:42.380 --> 00:16:46.940
規制当局の期待に沿った形式で、エージェントの活動履歴を作成することができます。

00:16:47.120 --> 00:16:51.540
これにより、人的なオーバーヘッドと重要な項目を見落とすリスクの両方を軽減できます。

00:16:51.740 --> 00:16:57.840
運用面で見ても、後から1回限りの監査証跡を作成するために費やされる膨大な時間を削減できます。

00:16:58.040 --> 00:17:02.140
監視がこれほど強力なのは、責任の全体像を再定義してくれるからです。

00:17:02.300 --> 00:17:06.260
苦情を待つのではなく、何が起きているかをリアルタイムのマップで把握できます。

00:17:06.500 --> 00:17:09.440
傾向は明確になり、予期せぬ事態は起こりにくくなります。

00:17:12.380 --> 00:17:14.500
実際に通用しているかを確認できるのです。

00:17:14.640 --> 00:17:21.460
これは、交差点の標識だけで秩序が保たれていると信じるのと、ライブ交通カメラで街の様子を監視するのとの違いと同じです。

00:17:21.620 --> 00:17:26.500
一方は安心感を与えてくれますが、もう一方は次の事故の報告に怯える毎日をもたらします。

00:17:26.660 --> 00:17:32.280
ポリシー制御と監視を組み合わせることで、ガバナンスモデルは受動的なものから真にプロアクティブなものへと変わります。

00:17:32.280 --> 00:17:38.300
推測は監視にとって変わられ、その監視こそが数ヶ月後にしか表面化しないようなリスクの静かな蓄積を防ぐのです。

00:17:38.420 --> 00:17:45.980
監視等の視点は、最悪のシナリオから守るだけでなく、誰かが常に全体を見守っているという安心感の下で、チームが実験を継続する自信を生みます。

00:17:46.140 --> 00:17:48.940
そしてそれは、必然的に次の疑問へと繋がります。

00:17:49.120 --> 00:17:56.680
可視化がこれほど強力なら、なぜ多くの組織が、せっかくの保護措置を無効にしてしまう古典的なガバナンスの失敗に陥るのでしょうか。

00:17:56.680 --> 00:17:59.780
古典的なガバナンスの失敗を避ける

00:17:59.780 --> 00:18:07.380
コパイロットエージェントにおけるガバナンスの最大の失敗は、ツールがないことではなく、ツールが利用可能であるにも関わらず、その使い方が誤っていることから生じます。

00:18:07.560 --> 00:18:13.820
組織で見られる失敗のほとんどは、管理者が管理センターやコパイロットスタジオの存在を知らなかったからではありません。

00:18:13.900 --> 00:18:20.940
真の問題は、大規模環境で適切に機能させるためにどのようなフレームワークが必要かを深く考えずに、機能を有効化してしまったことにあります。

00:18:20.940 --> 00:18:27.260
それは、共有オフィスに各部門へ個別の鍵を渡しつつ、夜間に誰がドアを施錠するのかを誰も決めていないようなものです。

00:18:27.260 --> 00:18:31.440
よくあるパターンとして、管理者が有効化イコールガバナンスだと考えてしまうことがあります。

00:18:31.620 --> 00:18:36.340
管理センターに新しい機能が表示され、スイッチを入れた時点で、全員が仕事は完了したと感じてしまうのです。

00:18:36.480 --> 00:18:39.560
しかし、テクノロジーが勝手に境界線を引いてくれるわけではありません。

00:18:39.560 --> 00:18:47.260
権限が不明確で、監視が有効ではなく、あるいはチーム間で調整なく責任が分散されていると、混沌が静かに、そして着実に忍び寄ってきます。

00:18:47.460 --> 00:18:50.820
最も恐ろしいのは、それが通常すぐには爆発しないという点です。

00:18:51.000 --> 00:19:00.460
それはゆっくりと蓄積され、ある監査やインシデント、あるいは規制当局からの問いかけをきっかけに、統制が取れているように見えたものが、実は発見されるのを待つだけのほころびの連続であったことが露呈します。

00:19:00.660 --> 00:19:03.320
最初の落とし穴は権限設定に関するものです。

00:19:03.320 --> 00:19:09.020
エージェントの作成、公開、共有を誰に許可するか定義されていなければ、ユーザーは自らその隙間を埋めてしまいます。

00:19:09.200 --> 00:19:15.440
その結果、エージェントの重複、テスト前の本番環境への公開、あるいは本来アクセスすべきでないデータへのワークフローによるアクセスが生じます。

00:19:15.600 --> 00:19:21.780
明確な境界線がなければ、IT部門が何か問題が発生するまで把握できない、シャドウITならぬシャドウ自動化カタログが生まれてしまいます。

00:19:21.780 --> 00:19:26.960
アクセス権を制限せずに機能を開放するのはイノベーションの促進ではなく、白紙の小切手を渡すようなものです。

00:19:27.080 --> 00:19:29.540
2つ目の落とし穴は監視を怠ることです。

00:19:29.680 --> 00:19:35.860
権限を設定しただけで十分だと考えていた管理者に何度か話を聞きましたが、現実にはそのルールが機能しているかどうかさえ把握できていませんでした。

00:19:36.060 --> 00:19:38.420
それにより、何が起きているのかが見えなくなってしまうのです。

00:19:38.580 --> 00:19:41.620
カンサログを有効にしていなければ、誰が何をしたかを証明することはできません。

00:19:41.620 --> 00:19:47.380
利用状況の指標を見ていなければ、どのエージェントが広く使われているのか、あるいは活動パターンに異常がないかを把握できません。

00:19:47.520 --> 00:19:54.480
データなしで運用するのは一時的には問題ないように思えますが、外部の規制当局や社内のコンプライアンスチームから答えられない質問を突きつけられるまでが限界です。

00:19:54.640 --> 00:19:56.920
一貫性のないポリシーは3つ目の地雷です。

00:19:57.100 --> 00:20:01.400
組織のある部門では厳格に管理していても、別の部門では公開が完全に自由な状態かもしれません。

00:20:01.620 --> 00:20:06.460
その不整合は、管理されたエージェントと未管理のエージェントが同じテナント内に混在するカオスな状況を招きます。

00:20:06.680 --> 00:20:11.100
外部からは、どこかにポリシーが存在するために戦略が確立されているように見えることがあります。

00:20:11.340 --> 00:20:18.060
しかし、コンプライアンスチームやセキュリティレビューが求めるのはポリシーの存在証明ではなく、組織全体でポリシーが一貫しているという証明です。

00:20:18.060 --> 00:20:24.440
地域ごとに異なる規制がある中で、自社のポリシーがそれらに準拠していない場合、その不一致を正当化するのはさらに困難になります。

00:20:24.580 --> 00:20:27.540
そして、よくある縦割りの所有権問題があります。

00:20:27.760 --> 00:20:34.080
IT部門があるルールを決め、セキュリティチームが別の層のカバーを想定し、事業部門は自由に公開できると思い込んでいるケースです。

00:20:34.280 --> 00:20:38.060
それぞれのグループが誰かが境界線を監視していると考えますが、実際には誰も監視していません。

00:20:38.140 --> 00:20:44.820
そうした不明確さが重複した権限や、誰に最終決定権があるか不明なために生じるエージェントのすり抜けなど、防げるはずの驚きを生みます。

00:20:44.940 --> 00:20:47.620
私が話を聞いたある企業も、まさにこれを経験しました。

00:20:47.800 --> 00:20:50.580
その会社は、全従業員にエージェントの自由な公開を許可していました。

00:20:50.780 --> 00:20:52.700
最初はエンパワーメントが進んでいるように見えました。

00:20:52.900 --> 00:20:57.080
誰もが実験し改善をリリースできましたが、公開権限と監査ログを紐付けることを誰も考えていませんでした。

00:20:57.260 --> 00:21:02.740
数ヶ月後、規制当局から特定の自動化ツールを誰がデプロイしたのか証明を求められましたが、彼らには何の記録もありませんでした。

00:21:02.740 --> 00:21:06.860
記録も責任者もおらず、監査で自らを守る術もありませんでした。

00:21:07.040 --> 00:21:11.540
自動化の民主化を目指した取り組みは、最終的に大きなコンプライアンスの欠落を招きました。

00:21:11.680 --> 00:21:15.980
こうした例は、小さなミスがいかに急速に大規模なリスクへと発展するかを浮き彫りにしています。

00:21:16.180 --> 00:21:20.320
権限設定ミスや未チェックのエージェントは小規模なパイロット運用では些細に見えますが、

00:21:20.480 --> 00:21:25.420
エンタープライズ規模になると、その見落としが未知の領域で動く何百ものエージェントへと増殖します。

00:21:25.660 --> 00:21:27.420
問題は線形には拡大しません。

00:21:27.420 --> 00:21:33.860
制御されていないエージェントが一つ増えるごとに、データの整合性、信頼性、セキュリティへの懸念が残るため、問題は指数関数的に拡大します。

00:21:34.020 --> 00:21:37.400
幸いなことに、落とし穴はよく知られており、それを回避する方法も確立されています。

00:21:37.580 --> 00:21:40.640
まずは、管理センターでベースラインとなるガードレールを定義することから始めましょう。

00:21:40.860 --> 00:21:43.560
作成者と公開者の役割を明確に分担してください。

00:21:43.740 --> 00:21:48.080
監視をオプションではなく必須とし、深刻な問題になる前にアラートを受け取れるようにします。

00:21:48.080 --> 00:21:53.400
地域を跨いでもポリシーを統一し、自信を持ってガバナンスフレームワークを維持できるようにしましょう。

00:21:53.580 --> 00:21:57.780
そして何より重要なのは、初日からセキュリティチーム及びコンプライアンスチームと連携することです。

00:21:57.940 --> 00:22:00.800
彼らを後回しにすると、ほとんどの場合、裏目に出ます。

00:22:00.980 --> 00:22:03.900
多くの組織が、すでに機能するプレイブックを構築しています。

00:22:04.120 --> 00:22:08.440
市販機ごとのポリシー見直しチェックリストや、監査ログと公開権限を直接結びつけるポリシー、

00:22:08.440 --> 00:22:13.200
そしてIT部門が正式導入を審査する前にイノベーションチームがまず実験を行うフレームワークなどです。

00:22:13.360 --> 00:22:17.020
彼らの経験から学ぶことで、同じ過ちを繰り返す必要はありません。

00:22:17.180 --> 00:22:23.320
他者が失敗を報告する場合、その多くはガードレールが紙の上には存在していても、適切に適用されていなかったことが原因です。

00:22:23.320 --> 00:22:26.440
彼らの教訓を早期に取り入れることで、コストを回避できます。