Latest / M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語） / Power PlatformとAzure OpenAIで作るエンタープライズAI：チャットボットのデモを超えるアーキテクチャ・セキュリティ・ガバナンス（AI吹き替え）

Transcript

Power PlatformとAzure OpenAIで作るエンタープライズAI：チャットボットのデモを超えるアーキテクチャ・セキュリティ・ガバナンス（AI吹き替え） · M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語）

0:00
マイクロソフト365、コパイロット、AI、Azure、そして未来の働き方を形作る人々が集う10日間、準備はいいですか?
0:07
この1月、M365コンが帰ってきます。
0:10
規模をさらに拡大してお届けします。
0:12
世界中のMVPや業界の専門家によるライブセッション、実践的なデモ、役立つ知識をぜひ体験してください。
0:18
ありきたりなスライドはありません。
0:20
無意味な専門用語の羅列もありません。
0:22
コパイロットスタジオ、AIエージェント、ファブリック、セキュリティ、ガバナンス、自動化といった現実の課題に取り組みます。
0:29
ITプロフェッショナル、開発者、ビジネスリーダーの皆様、それぞれのニーズに合わせたセッションをご用意しています。
0:35
10日間の充実した期間で、多様なテクノロジーを探求し、グローバルなコミュニティとつながりましょう。
0:40
ライブ視聴して、組織で活用できる実践的なインサイトを持ち帰ってください。
0:45
2027年1月、10日間、一つのマイクロソフトコミュニティ。
0:49
現在、登録受付中です。
0:53
今すぐお申し込みを。
0:54
サイトはメートル365コンドットネットです。
0:59
メートル365コンドットネットから参加登録を、1月のライブでお会いしましょう。
1:05
AIを活用したパワープラットフォームのデモの多くが、なぜチャットボット止まりで、実際のビジネスワークフローで生き残れないのか、不思議に思ったことはありませんか?
1:13
この動画では、デモでは語られない、プロフェッショナルな展開に不可欠なセキュリティパフォーマンス、ガバナンスを備えたAzure OpenAIとPower Apps Dynamics 365の接続方法を解説します。
1:24
魔法のような話よりも、具体的なやり方を知りたいなら、ここはまさにうってつけの場所です。
1:29
コネクタの先にある、パワープラットフォームにおけるAIの真の仕組みは、いつも同じところから始まります。
1:35
ビジネスユーザーは、数秒で応答する営業チャットボットや、チケットを魔法のように分類するカスタマーサービスアプリといった、華麗なデモを目にします。
1:44
そして彼らは、素晴らしい、これをすぐにPower Appsに入れようと考えます。
1:47
コネクタが配置され、画面が立ち上がると、人々はAIが自分の雑務をこなしてくれる姿を想像し始めます。
1:52
しかし、現実はすぐに突きつけられます。
1:54
デモでは2人のユーザーで動いていたコネクタも、次の大きなプロジェクトを構築しようとするとパフォーマンスの問題が発生したり、チャットボットが尻滅裂な回答をしたり、あるいは機密データが漏えいしたりするのです。
2:06
AI統合の多くがここで頓挫します。
2:08
AIをPower Platformに追加するのは、プラスボタンを押してコネクタを追加し、Azure OpenAIとリンクするだけという神話を信じているのが原因です。
2:15
この考え方が定着してしまうのは、これらのツールが理論上は簡単すぎるほどに見えるからです。
2:19
それが一番の難関であればどれほど良いでしょう。
2:21
では、遊び半分ではない本格的なプロジェクトを目指す場合、裏側では何が起きているのでしょうか。
2:25
AIの魔法がどこで起きているのかを理解することが、単なるデモで終わらせるか、真のビジネスプロセスを駆動させるかの分かれ道となります。
2:31
さて、実用的なPower Platform AI構成には、ほぼ必ず4つの要素が存在します。
2:36
まず、エンドユーザーが操作し、AIリクエストのトリガーとなるPower AppsやDynamics 365そのものです。
2:43
それらはデータを収集します。
2:44
顧客からのメッセージや調査結果、製品レビューなど、インテリジェンスを得たいあらゆる入力が対象です。
2:50
しかし、Power AppsはAzure OpenAIと直接通信しません。
2:53
そこで登場するのがPower Automateで、全体を統括する役割を担います。
2:56
ユーザーがボタンを押すかフォームを送信するたびに、Power Automateのフローがデータを取得し、適切な形式に整えて、必要な送信先へと送り届けます。
3:04
3番目に来るのがAzure OpenAIエンドポイントです。
3:07
これが真の頭脳であり、感情分析やテキストの要約、あるいは顧客への返信生成といった機能を提供します。
3:14
そして、スタックの中にひっそりと組み込まれているのがAzure API Managementですが、何かが起こるまで不当なほど軽視されがちです。
3:20
これはセキュリティとスロットリング、帯域制御を担う部分で、安定したフローを維持するか、システムをパンクさせるかの違いを生みます。
3:25
これらのパズルのピースがどのように互いに依存しているかを見ていきましょう。
3:28
例えば、Dynamics 365のユーザーが営業活動の記録を入力した瞬間をトリガーとして考えてみましょう。
3:34
それがPower Automateのフローを起動させます。
3:36
このフローは単にデータをAからBへ運ぶだけではありません。
3:39
Azure OpenAIへリクエストを送信する前に、テキストを整理したり、他のソースからのコンテキストを統合したり、プライバシーのためにフィールドをマスクしたりします。
3:47
その過程が重要です。
3:49
他の自動化処理でリソースが消費されフローの実行が遅延すれば、アプリの動作も重くなります。
3:55
もしPower Automateがペイロードを適切に準備できず、製品レビューのコンテキストが欠けていたり、フォーマットが不適切だったりすると、オープンAIエンドポイントは奇妙な結果を返したり、最悪の場合はハルシネーションを起こしたりします。
4:08
つまり、上流の配線が乱れていれば、インテリジェンスは機能しません。
4:12
Azure App Managementが加わると、事態はさらに興味深くなります。
4:15
誰もがインテリジェンスに胸を躍らせる一方で、誰にどの程度のアクセス権を与えるべきかについて考える人はまだ多くありません。
4:21
App Managementは入口のバランサーのように機能します。すべてのリクエストをチェックし、認証を適用し、利用状況が暴走しないよう監視します。
4:29
スロットリングポリシーを設定していなければ、壊れたアプリが1時間に数千回ものリクエストを送信し、オープンAIインスタンスがパンクしたり、あるいは恐ろしい高額のAzure請求が発生したりしかねません。
4:40
また、誰が何をしたかを記録するため、何かが壊れたり不正があったりした際に、追跡可能な監査証跡が残ります。
4:47
デモでこうした問題が示されることはまずありません。
4:49
短いチュートリアルでは、すべてが少人数のユーザーと理想的なネットワーク環境を前提に最適化されているからです。
4:56
しかし、実際のビジネス環境では、SLAやデータプライバシーへの懸念パフォーマンスの敷地があり、それらを無視することはできません。
5:02
例えば、感情分析機能を備えた営業フィードバック用のパワーアップを導入したとします。
5:07
わずか10人であればフローは順調に動き、1秒以内で有益な結果が得られるでしょう。
5:11
しかし、その数が1万件に跳ね上がった日、例えばメールキャンペーンや合併の後などに、エンドポイントがリクエストを処理しきれず、30秒の待ち時間やエラーが発生し始めることがあります。
5:21
さらに悪いことに、フィードバックデータの半分が突然処理できなくなるかもしれません。
5:26
ペイロードサイズがAzureの制限を超えたり、API管理のセキュリティポリシーが適切に強化されていなかったりするからです。
5:32
今やあなたのAIパイプラインは営業を助けるどころか妨害しており、ヘルプデスクはヘキヘキしています。
5:38
それが警告の合図です。
5:39
コネクタを接続するだけでは、アーキテクチャというパーティーへの招待状を受け取ったにすぎません。
5:44
真の課題は、各層がどのように相互作用し、スケールアップしようとした時にどれほど脆くなるかを理解することです。
5:51
パワーアップスがどのようにオーケストレーションを開始し、フローがどのようにデータを処理・保護し、AIエンドポイントがどう解釈し、API管理がどうガードレールとして機能するか。
6:00
それこそが、サンドボックスに留まるボットとエンタープライズ対応ソリューションを分かつ境界線です。
6:05
コネクタの仕組みしか理解していなければ、常に安定性とセキュリティを掛け事にしているようなものです。
6:10
パワーアップスで新しいAIデモをドラッグ&ドロップするのは誰にでもできます。
6:14
実際のユーザーやデータと向き合っても壊れないものを作るには、コネクタだけに頼るのではなく、詳細を掘り下げることが不可欠です。
6:21
つまり、単なるテキストの反復からビジネス上の課題を解決するという要求に変わるとき、AIにはさらなる賢さが求められます。
6:28
ビジネスにインパクトをもたらすAIの構築方法を説明しましょう。
6:32
AIのビジネスへの適応、感情分析、要約などについてです。
6:36
パワープラットフォームでAzure OpenAIを試したことがあれば、奇妙なことに気づいたかもしれません。
6:41
一つのエンドポイントで、文章内のネガティブな感情を見抜き、メールのやり取り全体を要約し、新しい製品説明文の草案を作成することも可能です。
6:49
これらすべてが同じAI環境で、時には1日で行えます。
6:53
しかし、これは魔法ではありません。
6:55
実際に役に立つことをしようとした途端に、多くのプロジェクトが行き詰まるのには理由があります。
6:59
人々はよく、プロンプトを差し替えるだけで済むと考えがちです。
7:02
現実はどうでしょうか?
7:03
ビジネスのユースケースごとに異なるアプローチが必要であり、そこでプラグ&プレイという幻想は崩れ去ります。
7:09
感情分析とテキスト生成の違いについて話をしましょう。
7:13
例えば、ダイナミクス365アプリで顧客の苦情にフラグを立てたいとします。
7:17
感情分析は最も明白な最初のユースケースで、入力は短く、応答は早く、コストも低く、追跡すべきコンテキストもほとんどありません。
7:25
これが機能するのは、パワーオートメートがオープンAIエンドポイントに渡すデータが最小限で済むからです。
7:30
モデルに何を探すべきかを伝える適切なプロンプトと、1から2分を送るだけで良いのです。
7:35
数十件のレコードなら、モデルが暴走したり予算を食いつぶしたりするリスクを気にせず、一気に処理できます。
7:41
そうしたフローは管理が容易で、スロットリングも簡単。ほとんど書き直す必要もありません。
7:45
では、要約生成に移りましょう。
7:47
ここからすでに負担がかかり始めます。
7:49
パワーアップでマネージャーが詳細な会議メモを貼り付け、数秒で論理的な要約を期待する場合、
7:55
オープンAIに送るプロンプトは言葉を厳選し、適切なトーンに合わせる必要があります。
8:01
それでも、要約の質は一様ではありません。
8:04
入力が大きすぎたり、元のテキストの構成が乱れていたりすると、
8:08
モデルが想定外の挙動をして要約ではなく言い換えを始めたり、存在しない詳細を捏造したりすることさえあります。
8:15
ここで重要になるのが設定です。
8:17
パワーオートメイトで入力を整形し、署名を削り、書式を解除し、文書が長すぎる場合は分割する必要があります。
8:23
これらはすべて、AIが処理を行う前の段階の話です。
8:26
しかし、本格的なテキスト生成や大規模な分類を行うとなると、話は一気に複雑になります。
8:30
例えば、営業チームがカスタムメールの返信を即座に作成したい場合や、
8:35
サポートスタッフがチケットを問題の種類ごとに分類したい場合などです。
8:38
AI搭載のフローを何千もの入力に対して実行することが、
8:41
デモのような順調なものとは全く別物だと、多くの人は気づいていません。
8:44
パワーオートメイトのフローは、膨大なデータセットをループ処理しなければなりません。
8:48
オープンAIのエンドポイントがリクエストでパンクし、
8:51
スループットが急落する一方でアジュールの請求額は上昇し、
8:55
時には経理部門が動くほど急激に跳ね上がります。
8:59
ここで最大の落とし穴は、これらのAIプロセスをすべて同じものとして扱うことです。
9:04
センチメント分析なら1リクエストあたりわずかなコストで済みますが、
9:08
長文生成はモデルの複雑さを増し、何百ものトークンを消費し、応答時間も長くなります。
9:15
さらに、顧客ごとに異なるトーンや言い回しといったカスタム指示が必要になると、
9:19
調整の度に精密なプロンプトエンジニアリングが求められます。
9:22
プロンプトエンジニアリングと聞くと、単に指示を工夫することだと思われがちですが、
9:26
実際には検索アルゴリズムのチューニングに近い作業です。
9:29
テストをして、奇妙な結果が出れば書き直す。
9:32
リリースするすべてのバリエーションが出力だけでなく、
9:37
影響を与えます。これは単なる理論ではありません。
9:40
無視できないほど多くの現実の例が存在します。
9:43
ある企業がパワープラットフォームのフローを構築し、
9:45
オープンAIを使ってカスタマーサービスのチケットをトリアージし、
9:48
感情分析に基づいて分類し、提携文を提案するようにしました。
9:52
ステージング環境では完璧に見えました。
9:54
問題が起きたのは、そのフローを全サポートスタッフに解放した時です。
9:57
突然、毎分すべてのチケットに対してエンドポイントにリクエストが殺到したのです。
10:02
モデルは単純な分類ではなく、
10:03
汎用的なテキスト生成を行う設定になっていました。
10:06
その結果、チケットの全履歴を分析し、
10:08
毎回何段落もの草案を作成するようになってしまいました。
10:11
コストは一晩で急増し、ワークフローは極端に遅くなり、
10:14
AIは提案の中に存在しない情報を捏造し始めました。
10:18
単純なトリアージ業務に、
10:19
単文分類用ではなくテキスト生成用に調整されたエンドポイントが必要な理由を、
10:24
誰も立ち止まって問いませんでした。
10:25
何時間も調査を重ねた結果、
10:27
パワーオートメイトの設定とエンドポイントの設定がこの混乱を招いていたことがようやく判明しました。
10:33
制御を維持したいなら、
10:34
まずはパワーオートメイトフローに使用制限を設定し、
10:37
Azureポータルでリクエスト数とトークン使用量を常に監視することから始めてください。
10:42
分類や感情分析のような迅速なタスクには、
10:45
並列フローを設定し、
10:47
目的を達成できる最小限のモデルを使用しましょう。
10:50
長文生成を行う場合は、
10:52
最大トークン数を制限し、
10:54
ユーザーがその機能にアクセスする頻度を抑制してください。
10:57
ログを定期的に確認しましょう。
10:59
急激なスパイクや暴走をできるだけ早く見つけ出してください。
11:02
これらの手順を怠れば、
11:03
後日届く高額な請求書によってプラットフォームから警告を受けるか、
11:06
最悪の場合、
11:07
ユーザーはアプリの動作の重さに不満を抱くことになるでしょう。
11:09
つまり、
11:10
適切なAI構成とは単にソリューションを動かすだけのものではありません。
11:13
ビジネスを停滞させず、
11:14
コストを予測可能にし、
11:16
結果を妥当なものに保つためのものです。
11:18
設定を誤れば、
11:19
AIは瞬く間に強力な味方から大きな不採へと変わってしまいます。
11:22
アプリにAIの知能を組み込んだ今、
11:25
誰がそれを使えるのかを明確にし、
11:27
エンドポイントとデータをどのように大規模に保護するかを検討しなければなりません。
11:31
フローの保護。
11:32
なぜAzure App Managementが盾となるのか。
11:35
お気づきかもしれませんが、
11:37
多くのパワープラットフォームAIデモでは、
11:39
セキュリティは最後にチェックする項目の一つとして軽視されがちです。
11:42
しかし、パイロットプロジェクトが社内のテスト環境から本番環境へ移行すると、
11:46
新たなリスクが急速に顕在化します。
11:48
そのオープンAIエンドポイントは、
11:50
もはや無害なテストプロンプトに応えるだけのものではありません。
11:53
アプリが公開しているあらゆる情報への窓口になり得るのです。
11:56
顧客サービスのワークフローが、
11:58
保護されていないAPIを通じてクライアントデータを密かに送信していたり、
12:01
チャットボットのキーが誰の目にも触れる状態で放置されていたりする状況を想像してみてください。
12:05
わずかなミスが、不正アクセス、データ漏洩、
12:08
あるいは悪意ある第三者からの大量のAPI呼び出しに対して、
12:11
ビジネスを無防備な状態にしてしまいます。
12:13
これは過程の話ではありません。
12:15
Azure OpenAIのエンドポイントをパワーアップスやダイナミクス365に接続すると、
12:19
強力な機能を外部にさらすことになります。
12:21
もし悪意ある人物にAPIキーが漏洩すれば、
12:23
それがスクリプト内やテストフローに埋もれていたとしても彼らはプロンプトを送信し、
12:27
回答を取得し、使用量を積み上げることができます。
12:29
DDOS攻撃が現実的な脅威となります。
12:32
悪意ある者がいなくても、アプリの設定ミスによって間違ったレコードでループが発生すれば、
12:36
エンドポイントに絶え間なく負荷がかかり続ける可能性があります。
12:38
いずれの場合も、ガバナンス上の問題だけでなく、
12:40
コストの暴走という事態に直面することになるのです。
12:43
そして、どのようなデータがネットワーク上を流れるかによっては、
12:45
現実的なコンプライアンスリスクが生じます。
12:47
ここで、知られざる功労者として登場するのがAzure App Managementです。
12:51
多くの人はこれを単なる設定が必要なAzureリソースの一つと見ていますが、
12:54
実際には秩序と混沌を分ける境界線となります。
12:57
App Managementは、パワーオートメートやコネクタ単体ではできないことを実現します。
13:01
リクエストの度に認証と認可を強制するため、
13:04
コードへの記述を忘れる心配はありません。
13:07
エンドポイントへのリクエスト数を制限できるため、
13:10
開発者のミスや暴走したスクリプトが予算や信頼を損なう事態を防げます。
13:15
また、詳細なログを記録するため、
13:17
いつ誰が何にアクセスしたかという問いに対する追跡が可能になります。
13:20
実際に起きたインシデントについてお話ししましょう。
13:23
ある組織がDynamics 365の顧客メール向けAI分類フローを展開し、
13:28
APIキーをパワーオートメートに組み込みました。
13:30
そのキーが共有ドキュメントフォルダに紛れ込み、
13:33
熱心だが未熟なチームメンバーがテストアプリ内で誤って再起ループを作成してしまいました。
13:38
数時間のうちに数千件ものAPI呼び出しがオープンAIエンドポイントに殺到し、
13:42
同じレコードが何度も繰り返されました。
13:44
Azureの請求額が予期せず急増し、
13:47
チームはログを精査した末にようやく何が起きたのかを理解しました。
13:49
最悪だったのは請求額だけでなく、
13:52
機密情報が誤った場所に流出したのではないかという不確実性でした。
13:56
もしアピマネジメントが導入されていれば、
13:58
事態が深刻化する前にループはレート制限エラーで停止し、
14:02
詳細なログが異常なアクセスを即座に検知できていたはずです。
14:06
アピマネジメントのポリシーは真のセーフティネットとなります。
14:09
レート制限を設定して、
14:10
例えばユーザーごとの1分間のリクエスト最大数を決めることができます。
14:14
IP範囲で呼び出しを制限し、
14:16
基地のパワープラットフォームゲートウェイからのリクエストのみを許可することも可能です。
14:20
厳しいコンプライアンスポリシーを持つ組織では、
14:23
独自のビジネスプロセス固有のヘッダーやトークンを要求することで、
14:27
外部からの無作為なアクセスを容易にブロックできます。
14:31
これらの管理機能はエンドユーザーを煩わせるためではなく、
14:35
急速に拡大するAIアプリが業務を停止させたり、
14:38
顧客データを侵害したりしないように設計されています。
14:41
ここでのバランス調整が重要です。
14:44
セキュリティポリシーは悪用を防ぐには十分強力であるべきですが、
14:46
通常の業務を遅らせるものであってはいけません。
14:48
スロットリングを厳しく設定しすぎると正当なリクエストが失敗し始め、
14:53
ユーザーは成功するまで何度も同じデータを送信するといった回避策を取るようになります。
14:58
そこで重要になるのが、アピマネジメント内のモニタリングと分析機能です。
15:03
時間の経過に伴う利用パターンを把握し、失敗した呼び出しを特定し、
15:07
ユーザーが気づく前にポリシーを微調整できるのです。
15:10
ビジネス全体でパワーアップスやダイナミクス365のAI機能を使いたいけれど、
15:16
データ保護とコスト管理の両面で歯止めが必要だと考えていますね。
15:20
アピマネジメントでゲートキーピングを行えば、単なる保護以上のメリットが得られます。
15:24
導入状況を追跡し、どのワークフローが真の価値を生み出し、
15:28
どれが不必要に容量を消費しているかを確認できます。
15:30
リーダーシップ層から、誰が、何を、いつ、どのようにと問われても、すべて記録に残っています。
15:34
ポックの5人から数千人が利用する未稼働の営業、サポートアプリへと規模が拡大しても、
15:40
アピマネジメントがあれば、ただ門戸を開いて運任せにする必要はありません。
15:44
トラフィックを予測可能な形で制御できます。
15:46
こうに言えない事実として、AIエンドポイントを適切に管理していないと、
15:50
ほとんどの本番環境向け統合は、予期せぬ事態が一度起きただけで崩壊してしまいます。
15:55
アピマネジメントを使えば、潜在的なリスクを抱え込むことなく、
15:58
アイデアの段階からエンタープライズ規模へと移行できます。
16:01
つまり、単なるパイプラインではなく、組織の正面玄関と考えてください。
16:04
もちろん、どんなに優れた門番でも、与えられた権限の範囲内でしか機能しません。
16:08
エンドポイントの保護は、コインの片面に過ぎません。
16:11
その先には、利用状況の追跡、予算の維持、アプリの進化やポリシー変更に伴うコンプライアンスルールの徹底といった、
16:18
より大きな全体像があり、ガバナンスが単なるオプションではなく、
16:21
システム全体を駆動する重要な要素となります。
16:23
ガバナンスという、ノリ、コストコンプライアンス、そしてAIを適切に制御することです。
16:28
パワーアップのサイドプロジェクトが、
16:30
一晩で誰もが使うお気に入りのツールになった際、
16:33
コストが急増し、誰が管理責任者なのか誰もわからず、
16:37
動揺した経験はありませんか?
16:39
AIの導入成功を祝うのは簡単です。
16:42
裏でセンチメンタナリシスが静かに動き、
16:44
テキスト要約がレポート作成時間を短縮している間は良いのですが、
16:48
誰かがAzureの請求書を見るか、
16:51
情報セキュリティ部門から警告を受けると、
16:53
現場は静まり返ります。
16:55
それがガバナンスの欠如を示す最初の兆候であり、
16:58
アプリが実用レベルで広く使われるようになると、
17:00
ほぼ必ずと言っていいほど発生します。
17:02
このパターンは、ほとんど全てのケースで共通しています。
17:05
AI機能を連携させ、エンドポイントを保護し、
17:08
リーダー層がビジネスケースを承認する。
17:10
しかし、実際のユーザーが増えるにつれ、
17:12
環境は複雑さを増していきます。
17:18
パワーアップから何件のリクエストが送信されており、
17:21
それらのうち本当に必要なものはどれでしょうか。
17:23
実験と予算を食いつぶす自動化の境界線はどこにあるのでしょうか。
17:27
スタッフが独自に自動化を構築調整する数が増えるほど、
17:30
舞台裏で何が起きているかを把握することは週ごとに難しくなっていきます。
17:34
制御不能なコスト増大は、多くの場合、
17:36
ガバナンスにおける最初の緊急事態となります。
17:38
Azureは、オープンAIエンドポイントを通過する全てのトークン、
17:41
API呼び出し、データ量を完全にカウントしていますが、
17:44
誰かがそれらの数字を追跡していないと、
17:46
裏で請求額が膨れ上がる可能性があります。
17:48
利用料を支払う仕組みですが、
17:50
市民開発者が純粋にイノベーションを目指していても、
17:53
パワーオートメートフローが1日1000回も
17:55
AIエンドポイントを呼び出していることに気づかない場合、
17:59
利用状況の把握は困難になります。
18:00
ほとんどの人は、予算アラートが作動するか、
18:03
財務部門の誰かが請求ミスを疑うことで、
18:06
初めてこの事態に気づきます。
18:08
これを放置することは、単に支払いが増えるだけでなく、
18:10
プロジェクトが強制終了されたり、
18:12
最悪の場合、経営人がAIの取り組み全体への信頼を失うリスクを伴います。
18:16
しかし、問題はコストだけではありません。
18:18
次に待ち受けているのはコンプライアンスの課題です。
18:20
API管理で入り口を厳重に監視していても、
18:23
どのようなデータが送信され、
18:24
どのくらいの期間保存され、
18:25
コピーがどこに残るのかといった疑問が残ります。
18:28
開発者は、サポートチケットのテキストをAzure OpenAIに送信する前に、
18:33
個人情報を適切にマスクしたでしょうか?
18:36
どのユーザーが何にアクセスしたかの記録はあり、
18:38
それは組織のポリシーに準拠していますか?
18:41
監査人は、
18:42
多分大丈夫という回答には納得しません。
18:44
規制の厳しい業界では、
18:46
適切なフィルタリングを行わずに機密データをテキスト要約のために送信するなど、
18:50
一度のコンプライアンス違反がプロジェクトを数週間停止させたり、
18:54
会社を窮地に追い込む可能性があります。
18:55
規制がそれほど厳しくない環境であっても、
18:58
ガバナンスの効いていないデータがクラウド内を飛び交っているように見えれば、
19:01
IT部門は懸念を抱きます。
19:02
マイクロソフトは、こうした面での負担を軽減するよう努めています。
19:05
Azureコストマネジメントでは、
19:07
ダッシュボード、アラート、利用制限の設定が可能です。
19:09
それでも、指揮位置を設定し、
19:11
週単位の利用急増を監視し、
19:12
エスカレーションする前に停止させるのは、
19:14
あくまで担当者の役割です。
19:15
すべてのリソース、AIエンドポイント、フロー、
19:18
さらには個々のパワーアップスにタグ付けすることは、
19:20
チームや事業部門ごとに支出を追跡するためのシンプルで強力な方法です。
19:24
また、これはクリーンアップやレポート作成にも役立ちます。
19:27
パイロット終了後も自動化が実行されたままになっている場合、
19:30
タグ付けされたリソースは際立って見えるため、
19:33
ヘルスチェックで必ず発生する、
19:35
謎のワークロード問題を回避できます。
19:37
パワープラットフォーム側では、
19:38
センテロフエクセレンス、COE、スターターキットが、
19:45
リソース、AIエンドポイント内のすべてのフロー、カスタムコネクタ、アプリ、ボットをスキャンし、
19:49
アクション可能なインベントリを構築できます。
19:52
IT部門は利用状況の分析を設定し、
19:54
不審なパターンが発生した際にアラートを送信したり、
19:57
社内のベストプラクティスを思い出させる通知で市民開発者を導くことができます。
20:01
一部の組織では、APIの利用状況、高負荷なフロー、
20:04
誰が何を作成しているかといった定期的なレポートの生成にこれを利用しています。
20:07
COEツールキットは、単に可視化のためだけに存在するわけではありません。
20:11
さらに、段階的デプロイのテンプレートを提供し、
20:13
リスクの高いアプリのレビューをトリガーします。
20:15
また、コンプライアンスの枠組みから外れたフローを停止、
20:18
中断することで、ビジネスポリシーを強制することも可能です。
20:21
急速に成長し、多数のパワーユーザーを抱える組織にとって、
20:24
こうしたガードレールは自体の制御不能を防ぐために不可欠です。
20:27
ガバナンスの問題は、通常、成功した後に表面化するという点に注目しておく必要があります。
20:32
予想を遥かに超えて普及した、ある顧客フィードバックアプリの事例を見てみましょう。
20:36
利用者は1週間で倍増し、その後3倍になりました。
20:39
1ヶ月も経たないうちにコストが急増しました。
20:41
Azureの請求額から再予測が必要になり、
20:44
そのアプリが承認なしに機密データをAIエンドポイントへ送信していたことが判明しました。
20:48
バータリ的なスクリプトや応急処置が導入されましたが、
20:50
その時点ではすでに大混乱に陥っていました。
20:57
リソースには必ずタグ付けを行ってください。
20:59
概念実証の段階であっても、予算やソフトキャップを設定しましょう。
21:02
エンドポイントへのアクセス権を定期的にレビューし、監査してください。
21:05
誰が何に接続できるかというリストは、チームの移動や役割の変化に伴い常に変わります。
21:09
どのフローがどのようなデータを、なぜ送信するのかを文書化してください。
21:13
これは単なる形式的な事務作業ではありません。
21:15
数週間や数ヶ月後に誰かがシステムの内容や境界を尋ねられた際、すぐに答えられるようにしておくためです。
21:20
重要なのは、ガバナンスは一度設定して終わりではないという認識です。
21:24
モデルは変化し、ビジネスロジックは変容し、プライバシー規制も絶えず進化しています。
21:28
レビューと更新は定期的に行う必要があります。
21:31
強固なガバナンスがあれば、AI機能は負荷に耐えきれず消えることなく、ビジネスの信頼と共に持続的に成長できるのです。
21:38
管理体制が整えば、IT部門やビジネスリーダーは自信を持って拡大や実験、革新に取り組めるようになります。