Latest / M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語） / Copilot エージェントのガバナンス：Microsoft 365 管理センターと Copilot Studio で統制する方法（AI吹き替え）

Transcript

Copilot エージェントのガバナンス：Microsoft 365 管理センターと Copilot Studio で統制する方法（AI吹き替え） · M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語）

0:00
マイクロソフト365、コパイロット、AI、Azure、そして働き方の未来を築く人々が集う10日間、準備はいいですか?
0:07
この1月、M365コンが帰ってきます。さらに規模を拡大して開催します。
0:12
世界中のMVPや業界エキスパートによるライブセッション、実世界でのデモ、そして実践的な知識にぜひご参加ください。
0:18
ありきたりなスライドや、終わりのない専門用語の羅列はありません。
0:21
コパイロットスタジオ、AIエージェント、ファブリック、セキュリティ、ガバナンス、自動化といった現実の課題に取り組みます。
0:29
ITプロフェッショナル、開発者、ビジネスリーダーの皆様、それぞれの役割に合わせたセッションをご用意しています。
0:35
10日間の充実した期間を通じて、多様な技術を探求し、世界中のコミュニティとつながることができます。
0:40
ライブで視聴し、実践的な洞察を組織に持ち帰りましょう。
0:45
2027年1月、10日間、一つのマイクロソフトコミュニティ、登録受付中です。
0:52
今すぐ場所を確保してください。
0:54
サイトはメートル365コンドットネットです。
0:59
メートル365コンドットネットから今すぐ登録を、1月のライブでお会いしましょう。
1:05
AIエージェントが気づかないうちに勝手に判断を下し始めたらどうなるでしょうか。
1:09
本日のセッションでは、なぜガバナンスがもはや不可欠なのか、
1:11
そしてマイクロソフト365管理センターがどのように必要なコントロールパネルを提供できるのかを解説します。
1:16
チームが必要なものを構築できるように権限を与えつつ、
1:19
エージェントが暴走するのを防ぐための具体的なツールを紹介します。
1:22
監視を怠らずにコパイロットのメリットを最大限に生かす方法をお探しなら、ここが最適な場所です。
1:27
なぜこれほど多くの組織がAIエージェントを恐れるのでしょうか。
1:30
AIエージェントの利点が理論上これほど明確なのに、なぜ企業は二の足を踏むのでしょうか。
1:34
手作業の削減、意思決定の迅速化、データの有効活用。
1:37
表面上は、承認をためらう理由がないほどの成功に見えます。
1:46
このためらいは、技術への不信感から来るものではありません。
1:49
明確な監視体制がないまま、何百何千もの小さな自動化がバックグラウンドで動き出した時、何が起こるかという恐怖から来るものです。
1:56
大きな可能性と、それと同等の大きな不確実性との間の緊張感により、多くの組織が予想以上に長くパイロット運用の段階に留まっています。
2:04
現実として、AIエージェントが人々を不安にさせるのは、他のツールとは異なる動きをするからです。
2:09
従業員による新しい生産性アプリのインストールを管理したり、エンドポイント管理でソフトウェアをブロックしたりすることはできますが、エージェントはそうした枠にはうまく収まりません。
2:16
エージェントは、時として迅速に、時として複数のシステムをまたいで動作するように設計されています。
2:20
一度リリースされると、まるで勝手に動いているかのように感じられることがあります。
2:23
制御、標準化、ガバナンスの観点から考える訓練を受けてきたITリーダーにとって、目に見えないバックグラウンドプロセスが実際の情報の流れを形成しているという状況は、組織の統制を完全に失っているかのように感じられるかもしれません。
2:33
その結果がどうなるかを示す事例は数多くあります。
2:35
ある研究チームが、データセットを抽出、整理するボットを立ち上げました。
2:38
それを見た別の誰かが少しだけ調整を加えてコピーを作成します。
2:41
数週間もすると、会社では適切に管理されたエージェントが一つ動いている状態ではなくなります。
2:44
小さな違いがある20ものクローンが乱立し、バージョン管理も責任者も不明な状態です。
2:49
ベルリンのアナリストが使うデータとニューヨークのマネージャーが使うデータに微妙なズレが生じ、財務部門は両方のデータが混在したレポートに頭を抱えています。
2:58
これを何十もの部門で繰り返せば、生産性を高めるはずが、どの数値を信用すべきかという疑念に変わってしまいます。
3:06
また、自動化が本来触れるべきでない領域にまで踏み込んでしまった事例も見てきました。
3:11
ある会社では、オンボーディングを効率化するために顧客情報をシステム間で移動させる社内スクリプトがありましたが、データ転送がコンプライアンス基準を満たしているか誰も確認していませんでした。
3:21
監査が入った際、組織は誰が作成し、なぜ実行され、どのようなルールに基づいていたのかを証明する記録を提示できませんでした。
3:28
それはAIの能力不足ではありません。
3:30
統制の欠如による失敗です。
3:32
時間を節約するための技術が、会社にとってここ数年で最大のコンプライアンス上の悩みの種となりました。
3:37
リーダーたちが慎重になるのも無理はありません。
3:40
制限なしにエージェントを導入するのは、全従業員にドローンを渡し、好きな場所へ飛ばさせるようなものです。
3:46
最初は順調に離陸しても、すぐに建物に衝突したり、行方不明になったり、緊急ヘリの着陸を妨げたりするドローンが出てくるでしょう。
3:55
完成等がなければ、効率化をもたらすはずの技術そのものが、公共の危険物となってしまいます。
4:00
同じ原則がナレッジワークにも当てはまります。
4:03
自動化そのものが恐ろしいわけではありません。
4:05
恐ろしいのは、管理ができていないことです。
4:07
調査の結果も、こうした話から推測できる通りです。
4:10
経営陣は、エンタープライズAIに関する主な懸念事項として、一様にコンプライアンス、セキュリティ、データ漏洩を挙げています。
4:16
技術が成果をもたらすかどうかは、ほとんど問題ではありません。
4:19
懸念されているのは、誤った情報が流出することや、後から追跡できないアクションをボットが実行してしまうことです。
4:25
問題は、単なる業務上のミスに留まりません。
4:28
評判、規制リスク、そして顧客からの信頼にまで直接的に影響します。
4:32
自動化によって本来守るべきデータが流出したと顧客が信じれば、信頼を取り戻すには何年もかかります。
4:37
だからこそ、真の問題を正しく認識することが重要なのです。
4:40
企業はコパイロットエージェントそのものを恐れているわけではありません。
4:43
見失うことを恐れているのです。
4:45
誰がどのアージェントを構築し、いつ最後に確認され、なぜ機密システムから情報を引き出しているのかを忘れてしまうことを恐れているのです。
4:51
問題はソフトウェアではなく、信頼性と予測可能性を維持し、組織のルールに沿った運用を支えるガードレールが欠けていることです。
4:57
そのように捉えると、今後の進むべき道がはっきりと見えてきます。
5:00
そして、ほとんどの人が驚くのはここからです。
5:02
多くの組織が必要だと思っている管理ボードは、実はすでにMicrosoft 365の中に存在しています。
5:07
別売りのアドオンではありません。
5:09
隠されたプレミアム機能でもありません。
5:11
管理センターに標準で組み込まれています。
5:12
多くの組織はそのポータルをライセンス割り当てや基本的なチームポリシーの設定にしか使っていませんが、実はすでにコパイロットエージェントの完成塔として機能しているのです。
5:21
言い換えれば、必要なガードレールはすでに皆さんの目の前にあるということです。
5:24
唯一の問題は、正しいパネルを開いているかどうかだけです。
5:27
存在すら知らなかったコントロールパネル。
5:30
もし、AIエージェントを管理するためのコックピットがすでに目の前にあり、多くの管理者が単に気づいていなかったとしたらどうでしょうか。
5:35
信じがたい話かもしれませんが、実はマイクロソフト365管理センターには、多くの組織が探し求めていたカジトリの機能が静かに備わっているのです。
5:43
皮肉なことに、多くのITチームは毎日このポータルを開きながら、エージェントのガバナンスにとって最も重要な部分を見過ごしています。
5:50
考えてみれば、これは慣れ親しんでいることが逆にあだとなっている状況と言えます。
5:54
中身を知っていると思い込んでいるため、普段無視しているタブの裏側に新たな管理機能があるとは予想もしないのです。
6:00
長年、管理センターは単なるユーティリティパネルとして扱われてきました。
6:04
ライセンスを配布したり、エクスチェンジメールボックスを設定したり、チームのポリシーを少し調整したりするために開く場所でした。
6:09
ユーザーに機能を割り当て、リクエストがあったサービスへ確実にアクセスできるようにするための実務的な場所だったのです。
6:16
見過ごされがちなのは、その機能がどれほど充実してきたかということです。
6:19
同じインターフェースの裏側には、誰がアクセスできるかだけでなく、人々がどのように自動化を作成、利用、共有するかを管理するための機能が日々増えています。
6:27
もしコパイロットエージェントの制御不能を懸念しているなら、そのガードレールは数回クリックするだけで見つかるはずです。
6:33
このミスマッチは明らかです。
6:35
ITフォーラムでは、AIの混沌、各部署で勝手に現れるボット、秘密データに触れる自動化、あるいは支えながら深刻な違いを持つワークフローの重複といった懸念が議論されています。
6:46
しかし、そうした懸念を口にする組織ほど、まさにそれを防ぐために設計された中央ダッシュボードをほとんど見ていないのです。
6:52
奇妙な乖離です。
6:53
私たちはコントロールを失うことを恐れながら、機構を調整するために存在するコントロールパネルを十分に活用できていません。
6:58
それは、過度にある信号機を無視しながら、予測できない交通渋滞に文句を言っているようなものです。
7:03
大企業における典型的なシナリオを想像してみてください。
7:06
マーケティング部門では誰かが顧客フィードバック収集用のエージェントを作成し、オペレーション部門では注文追跡を効率化するボットを設計しています。
7:12
これらは決して意図的なシャドウITではありません。
7:14
熱心な従業員が日々の業務を楽にしようとしているだけなのです。
7:17
しかし、それらのエージェントが稼働し始めると、統合された記録がないまま別々のサイロに分散してしまいます。
7:21
IT部門がそれらを見つけた時には、誰が何を所有し、どのデータソースを利用しているのかを把握することは不可能です。
7:26
突然、コンプライアンスに関する話し合いが、まるで探偵のような作業に変わってしまいます。
7:29
一体誰がこれを作ったのか?いつ更新されたのか?どのような権限を密かに継承しているのか?
7:34
明確な監視体制がなければ、小さな自動化であっても、誰も予期しなかったコンプライアンス上の欠陥に発展しかねません。
7:39
管理センターは、こうした目に見えない活動をすべて一箇所に集約することで、この問題に直接対処します。
7:43
推測する代わりに、どのエージェントが存在し、何に依存し、誰が編集や公開の権限を持っているのかを確認できます。
7:49
ポリシーによって、そもそもどのグループが自動化を作成できるかを定義できるため、実験と正式な展開を切り離すことができます。
7:56
これは非常に重要です。
7:58
チーム内での施策と、CRMや人事プラットフォーム全体に影響を与えるものの構築では、意味が大きく異なるからです。
8:04
管理センターでは、それらを明確に区別して維持できます。
8:07
権限設定によって、さらなる安全性が確保されます。
8:09
熱心な従業員全員がエージェントを作成できるだけでなく、全社規模で公開できてしまった場合のリスクは容易に想像できます。
8:16
より良いモデルは、アイデア構築には幅広く参加させつつ、展開の権限は特定の役割に限定することです。
8:22
例えば、財務アナリストがレポート作成のためにエージェントのドラフトを作成し、そのドラフトを本番環境に適用するかどうかはITガバナンスチームが決定する、といった形です。
8:33
管理センターでこれらのルールを設定することで、誰が空域の規則を決めるかを事前に決定できます。
8:38
レポーティング機能がこのサイクルを完結させます。
8:40
問題が起きてからボットの存在を知るのではなく、利用動向を追跡し、どの部署が積極的に実験しているかを把握し、個別のスプレッドシートを追いかけることなく監査を実施できます。
8:49
このデータに基づいた視点は、コンプライアンスだけでなく、戦略立案にも役立ちます。
8:54
もしサポートチームが似たようなエージェントを何度も作成しているなら、バラバラに放置するよりも標準化されたソリューションへの投資を検討すべきかもしれません。
9:02
可視性と制御を組み合わせることで、自動化は頭痛の種から管理可能なチャンスへと変わります。
9:07
エージェントが無秩序に飛び回ることを想像する代わりに、管理センターを航空管制等として捉えてみてください。
9:13
すべての飛行計画が記録され、すべての出発がポリシーに基づいて許可され、空全体が見渡せるために衝突が起こることもありません。
9:20
中央ダッシュボードがこの力を秘めていると認識すれば、エージェントを潜む脅威としてではなく、構造化された業務として運用できるようになります。
9:28
そのフレームワークが整うと、会話の内容が変わってきます。
9:31
管理者が監視できる一方で、従業員もその境界線を超えることなく、構築や試行錯誤を行う余地が必要です。
9:37
そこでまさに、コパイロットスタジオの出番となるわけです。
9:40
混乱のないイノベーション、それがコパイロットスタジオの実力です。
9:43
組織を混乱させることなく、従業員に独自のAIソリューションを作らせるにはどうすれば良いでしょうか?
9:49
それがコパイロットスタジオにおける中心的な課題です。
9:52
一方で、このツールは部門を超えた創造性を解き放つように設計されており、日々の業務の課題を理解している当事者が、それを直接自動化できるチャンスを与えます。
10:00
その一方で、監視なしに構築ツールを配布すれば、管理不能なワークフローがあふれかえり、IT部門は何が実行されているのか把握できず奔走することになりかねません。
10:09
それは一見、非常に難しいバランスのように思えます。
10:12
ユーザーに権限を与えて混乱を招くか、それとも全てをロックダウンして進歩を阻むか。
10:15
コパイロットスタジオは、その中間に位置するソリューションです。
10:19
従業員がソリューションを試作し、対話をテストし、さらにはエージェントを公開して業務を改善できるワークショップのようなものだと考えてください。
10:26
過去のDIY自動化との違いはシンプルです。
10:28
プラットフォームには、すでにガードレールが組み込まれています。
10:32
事後にIT部門に後始末をさせるのではなく、スタジオは管理センターで管理しているのと同じガバナンス原則を使用し、それを設計環境に直接組み込んでいます。
10:40
それこそが、リスクを抑えつつ実用性を高めている理由です。
10:43
とはいえ、管理者にとっての懸念は非常に現実的なものです。
10:46
熱心なスタッフがスクリプトツールを手にした時に何が起こるかを目にしたことがあれば、単なるテストがどれほど素早くミッションクリティカルな依存関係に発展するかをご存知でしょう。
10:53
問題は、悪意があることではありません。
10:55
ほとんどのユーザーは、単に自分の抱えるボトルネックを解決したいだけなのです。
10:58
しかし、そうして構築されたローカルなソリューションが顧客データや財務記録、人事ファイルにアクセスし始めると、便利な実験の域を超え、コンプライアンスの領域に踏み込んでしまいます。
11:06
その一線を超えた瞬間、説明責任と監視はもはや選択肢ではなくなります。
11:10
このようなシナリオを想像してみてください。
11:13
財務アナリストが、顧客の残高を自動的に取得して周辞レポートを作成するエージェントを構築します。
11:18
手作業の時間を大幅に削減できるため、すぐに人気が出ます。
11:21
数人の同僚がそれを利用し始め、やがて部門全体へと広がっていきます。
11:25
しかし、ここに落とし穴があります。
11:27
そのエージェントが機密項目を公開していないことを、誰が保証したのでしょうか?
11:30
データソースが財務情報の取り扱いに関するコンプライアンス規則に適合していることを、誰が確認したのでしょうか?
11:35
そして、規制当局が調査に来た時、これがサイドプロジェクトではなくポリシーに従って構築展開されたものだと誰が証明するのでしょうか?
11:40
適切な構造がなければ、その単純なボットはリスクの種となってしまいます。
11:44
これこそが、コパイロットスタジオが状況を改善するポイントです。
11:47
このプラットフォームは、すべての作成者がプロの開発者であることを前提としてはいません。
11:50
その設計全体に、技術者ではないユーザーを守るための保護機能が組み込まれています。
11:54
管理者は、使用可能なアクションやコネクタ、そして本番環境への公開権限を持つユーザーを定義します。
11:59
従業員は完全な捜索の自由があると感じるかもしれませんが、実際には慎重に制限された範囲内での施行です。
12:05
その違いこそが、シャドウITの問題を招くことなく、企業がエージェントの導入を拡大できる理由です。
12:10
コントロールポイントは具体的に設定されます。
12:12
例えば、マーケティング部門全員にエージェントの草案作成を許可しつつ、公開は特定の担当者のみに限定できます。
12:17
あるいは、シェアポイントやダイナミクスなど、承認済みのコネクタのみを利用可能にすることもできます。
12:22
一方で、機密性の高いサードパーティサービスに触れるものは制限されます。
12:25
さらに、どのシステムアクションを制限するかを決定することも可能です。
12:29
例えば、データベースの紹介は良くても、重要なフィールドの直接更新は誤った操作を防ぐためにロックされます。
12:34
つまり、ユーザーはアイデアを試せますが、明示的な承認なしに本番環境の記録を変更することはできません。
12:39
シンプルな例えで説明しましょう。
12:41
遊び場の砂場のようなものです。
12:43
子供は砂場の中で自由に城を作れますが、その周囲には明確な境界線があります。
12:47
フェンスがあることで、遊びの安全を保ちつつ、創造性を発揮する余地も十分に確保されます。
12:52
スタジオは、このコンセプトをエージェント作成にもたらします。
12:56
従業員は確信に必要な自由を感じられ、管理者は見えないフェンスがリスクの拡大を防いでいると把握できます。
13:02
適切な権限とポリシーでコパイロットスタジオを設定すれば、セキュリティの悩みの種ではなく、本来あるべき安全なイノベーションラボになります。
13:10
各部門は業務に合わせたエージェントを模索し、新しい手法を試し、初期のアイデアを共有できます。
13:15
もちろん、コンプライアンス違反や非公式なワークフローを増やすことはありません。
13:19
イノベーションは続きますが、混乱は生じません。
13:21
そのような保護壁があっても、無視できないもう一つの安全策があります。
13:25
それは、可視性です。
13:26
どれほど強固なガードレールがあってもリアルタイムで何が起きているかを監視する必要があるからです。
13:30
そこで、監視と追跡の出番です。
13:32
監視棟のように、エージェントの活動を監視し追跡します。
13:36
もしエージェントが、あなたの知らないところで何百もの決定を密かに言っていたらどうでしょう?
13:39
それは決してありえない話ではありません。
13:41
組織がコントロールを設定しながらも、その半分を忘れてしまうと、まさにそのような事態が起こり得ます。
13:46
権限とポリシーはフェンスのようなものです。
13:48
それらは従業員に対して、どこで作成が許可され、どのツールが使用可能かを伝えます。
13:52
しかし、可視性がなければ、誰かがチェックされていない領域に迷い込んだり、
13:56
エージェントが本来の範囲外で密かに動作したりしていることを知る術はありません。
13:59
監視こそが、ガバナンスという物語を推測の域から脱却させ、明確にするための要素なのです。
14:04
私たちが普段、ITの問題にどう対処しているか考えてみてください。
14:07
何かが壊れ、ユーザーからチケットが届き、私たちは慌てて変更箇所を辿ることになります。
14:12
それは受動的なアプローチです。
14:13
小規模なら通用しますが、数百もの自動化に拡大すると手に負えないコストとなります。
14:17
AIエージェントの場合、問題が手遅れになるまで見えないため、リスクはより大きくなります。
14:22
意図しないワークフローが、誰にも気づかれずに数週間も実行される可能性があります。
14:26
派手に失敗するわけではなく、表面上は妥当に見える判断を静かに行い続けるからです。
14:30
データが合わない理由を誰かが指摘する頃には、未来の防止ではなく、過去の調査に追われることになります。
14:35
監視があれば、そのサイクルを完全に変えることができます。
14:38
手探りで作業するのではなく、どのようなエージェントが存在し、誰が作成し、どう利用されているかをリアルタイムで把握できます。
14:43
マイクロソフト365は、この可視性をエコシステム全体に組み込んでいます。
14:47
利用状況分析により、どの部署がエージェントを急速に導入しているか、誰が熱心に作成しているか、予期せぬ活動がどこで発生しているかを確認できます。
14:56
監査ログで詳細を追跡します。
14:58
エージェントがいつ修正され、どのコネクタに触れ、誰がそのアクションを実行したかまで記録されます。
15:02
こうした追跡記録は、コンプライアンスを満たすだけのものではありません。
15:05
推測ではなく、実環境を正確に理解するために必要なものなのです。
15:09
その洞察の価値は、ありふれたシナリオを想像するとわかります。
15:13
マーケティングチームが顧客アンケートを分析するエージェントを作成します。
15:16
最初は小規模に、一つのキャンペーンで数千件のデータを扱い、有益な結果が出ます。
15:21
やがて誰かがそれを複製して別のプロジェクトに流用し、別のチームがテンプレートを微調整して使い始めます。
15:26
監視がなければ、異なるバージョンのエージェントが並行して動き、それぞれが少しずつ異なるデータにアクセスすることになります。
15:32
放置すれば、その際はやがてレポートに紛れ込み、経営層の意思決定を混乱させます。
15:37
監視があれば、エージェント利用の急増を早期に察知し、複製を把握し、公式版を標準化するか、誤解を招く前に不要な版を停止できます。
15:48
可視性の有無は、軽微な修正で済むか、ニュースになるほどの事件になるかの分かれ目です。
15:53
例えば、内部予測を効率化するために財務の機密データを取得するエージェントを考えてみましょう。
15:58
詳細を誤って公開したり、経理部門以外がアクセス可能になったりすれば、コンプライアンスリスクは急速に拡大します。
16:04
しかし監視があれば、異常なアクセスはログにはっきりと現れます。
16:08
規制当局や顧客から指摘を受ける前に、停止したり権限を調整したりできるのです。
16:13
これは作成者の悪意を疑うということではありません。
16:15
慎重なチームであっても、試行錯誤の過程でミスは起こり得るという前提に立つものです。
16:20
可視性があるからこそ、そうしたミスが致命傷にならず、やり直しが効くのです。
16:23
レポート機能は、監査担当者との関係を円滑にすることにも役立ちます。
16:27
監査を経験したことのある人なら誰でも、文書の収集や、誰が何を承認したか、いつ変更が行われたか、管理策が実際に機能していたかを確認するために奔走する苦労を知っているはずです。
16:35
手動での追跡はミスを招きやすく、大きなストレスとなります。
16:38
レポーティングシステムがそれらの記録を保持していれば、もう慌てる必要はありません。
16:42
規制当局の期待に沿った形式で、エージェントの活動履歴を作成することができます。
16:47
これにより、人的なオーバーヘッドと重要な項目を見落とすリスクの両方を軽減できます。
16:51
運用面で見ても、後から1回限りの監査証跡を作成するために費やされる膨大な時間を削減できます。
16:58
監視がこれほど強力なのは、責任の全体像を再定義してくれるからです。
17:02
苦情を待つのではなく、何が起きているかをリアルタイムのマップで把握できます。
17:06
傾向は明確になり、予期せぬ事態は起こりにくくなります。
17:12
実際に通用しているかを確認できるのです。
17:14
これは、交差点の標識だけで秩序が保たれていると信じるのと、ライブ交通カメラで街の様子を監視するのとの違いと同じです。
17:21
一方は安心感を与えてくれますが、もう一方は次の事故の報告に怯える毎日をもたらします。
17:26
ポリシー制御と監視を組み合わせることで、ガバナンスモデルは受動的なものから真にプロアクティブなものへと変わります。
17:32
推測は監視にとって変わられ、その監視こそが数ヶ月後にしか表面化しないようなリスクの静かな蓄積を防ぐのです。
17:38
監視等の視点は、最悪のシナリオから守るだけでなく、誰かが常に全体を見守っているという安心感の下で、チームが実験を継続する自信を生みます。
17:46
そしてそれは、必然的に次の疑問へと繋がります。
17:49
可視化がこれほど強力なら、なぜ多くの組織が、せっかくの保護措置を無効にしてしまう古典的なガバナンスの失敗に陥るのでしょうか。
17:56
古典的なガバナンスの失敗を避ける
17:59
コパイロットエージェントにおけるガバナンスの最大の失敗は、ツールがないことではなく、ツールが利用可能であるにも関わらず、その使い方が誤っていることから生じます。
18:07
組織で見られる失敗のほとんどは、管理者が管理センターやコパイロットスタジオの存在を知らなかったからではありません。
18:13
真の問題は、大規模環境で適切に機能させるためにどのようなフレームワークが必要かを深く考えずに、機能を有効化してしまったことにあります。
18:20
それは、共有オフィスに各部門へ個別の鍵を渡しつつ、夜間に誰がドアを施錠するのかを誰も決めていないようなものです。
18:27
よくあるパターンとして、管理者が有効化イコールガバナンスだと考えてしまうことがあります。
18:31
管理センターに新しい機能が表示され、スイッチを入れた時点で、全員が仕事は完了したと感じてしまうのです。
18:36
しかし、テクノロジーが勝手に境界線を引いてくれるわけではありません。
18:39
権限が不明確で、監視が有効ではなく、あるいはチーム間で調整なく責任が分散されていると、混沌が静かに、そして着実に忍び寄ってきます。
18:47
最も恐ろしいのは、それが通常すぐには爆発しないという点です。
18:51
それはゆっくりと蓄積され、ある監査やインシデント、あるいは規制当局からの問いかけをきっかけに、統制が取れているように見えたものが、実は発見されるのを待つだけのほころびの連続であったことが露呈します。
19:00
最初の落とし穴は権限設定に関するものです。
19:03
エージェントの作成、公開、共有を誰に許可するか定義されていなければ、ユーザーは自らその隙間を埋めてしまいます。
19:09
その結果、エージェントの重複、テスト前の本番環境への公開、あるいは本来アクセスすべきでないデータへのワークフローによるアクセスが生じます。
19:15
明確な境界線がなければ、IT部門が何か問題が発生するまで把握できない、シャドウITならぬシャドウ自動化カタログが生まれてしまいます。
19:21
アクセス権を制限せずに機能を開放するのはイノベーションの促進ではなく、白紙の小切手を渡すようなものです。
19:27
2つ目の落とし穴は監視を怠ることです。
19:29
権限を設定しただけで十分だと考えていた管理者に何度か話を聞きましたが、現実にはそのルールが機能しているかどうかさえ把握できていませんでした。
19:36
それにより、何が起きているのかが見えなくなってしまうのです。
19:38
カンサログを有効にしていなければ、誰が何をしたかを証明することはできません。
19:41
利用状況の指標を見ていなければ、どのエージェントが広く使われているのか、あるいは活動パターンに異常がないかを把握できません。
19:47
データなしで運用するのは一時的には問題ないように思えますが、外部の規制当局や社内のコンプライアンスチームから答えられない質問を突きつけられるまでが限界です。
19:54
一貫性のないポリシーは3つ目の地雷です。
19:57
組織のある部門では厳格に管理していても、別の部門では公開が完全に自由な状態かもしれません。
20:01
その不整合は、管理されたエージェントと未管理のエージェントが同じテナント内に混在するカオスな状況を招きます。
20:06
外部からは、どこかにポリシーが存在するために戦略が確立されているように見えることがあります。
20:11
しかし、コンプライアンスチームやセキュリティレビューが求めるのはポリシーの存在証明ではなく、組織全体でポリシーが一貫しているという証明です。
20:18
地域ごとに異なる規制がある中で、自社のポリシーがそれらに準拠していない場合、その不一致を正当化するのはさらに困難になります。
20:24
そして、よくある縦割りの所有権問題があります。
20:27
IT部門があるルールを決め、セキュリティチームが別の層のカバーを想定し、事業部門は自由に公開できると思い込んでいるケースです。
20:34
それぞれのグループが誰かが境界線を監視していると考えますが、実際には誰も監視していません。
20:38
そうした不明確さが重複した権限や、誰に最終決定権があるか不明なために生じるエージェントのすり抜けなど、防げるはずの驚きを生みます。
20:44
私が話を聞いたある企業も、まさにこれを経験しました。
20:47
その会社は、全従業員にエージェントの自由な公開を許可していました。
20:50
最初はエンパワーメントが進んでいるように見えました。
20:52
誰もが実験し改善をリリースできましたが、公開権限と監査ログを紐付けることを誰も考えていませんでした。
20:57
数ヶ月後、規制当局から特定の自動化ツールを誰がデプロイしたのか証明を求められましたが、彼らには何の記録もありませんでした。
21:02
記録も責任者もおらず、監査で自らを守る術もありませんでした。
21:07
自動化の民主化を目指した取り組みは、最終的に大きなコンプライアンスの欠落を招きました。
21:11
こうした例は、小さなミスがいかに急速に大規模なリスクへと発展するかを浮き彫りにしています。
21:16
権限設定ミスや未チェックのエージェントは小規模なパイロット運用では些細に見えますが、
21:20
エンタープライズ規模になると、その見落としが未知の領域で動く何百ものエージェントへと増殖します。
21:25
問題は線形には拡大しません。
21:27
制御されていないエージェントが一つ増えるごとに、データの整合性、信頼性、セキュリティへの懸念が残るため、問題は指数関数的に拡大します。
21:34
幸いなことに、落とし穴はよく知られており、それを回避する方法も確立されています。
21:37
まずは、管理センターでベースラインとなるガードレールを定義することから始めましょう。
21:40
作成者と公開者の役割を明確に分担してください。
21:43
監視をオプションではなく必須とし、深刻な問題になる前にアラートを受け取れるようにします。
21:48
地域を跨いでもポリシーを統一し、自信を持ってガバナンスフレームワークを維持できるようにしましょう。
21:53
そして何より重要なのは、初日からセキュリティチーム及びコンプライアンスチームと連携することです。
21:57
彼らを後回しにすると、ほとんどの場合、裏目に出ます。
22:00
多くの組織が、すでに機能するプレイブックを構築しています。
22:04
市販機ごとのポリシー見直しチェックリストや、監査ログと公開権限を直接結びつけるポリシー、
22:08
そしてIT部門が正式導入を審査する前にイノベーションチームがまず実験を行うフレームワークなどです。
22:13
彼らの経験から学ぶことで、同じ過ちを繰り返す必要はありません。
22:17
他者が失敗を報告する場合、その多くはガードレールが紙の上には存在していても、適切に適用されていなかったことが原因です。
22:23
彼らの教訓を早期に取り入れることで、コストを回避できます。