Latest / M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語） / Business Centralで独自のCopilot機能を登録：AL、メタプロンプト、Azure OpenAIキーの安全な管理（AI吹き替え）

Transcript

Business Centralで独自のCopilot機能を登録：AL、メタプロンプト、Azure OpenAIキーの安全な管理（AI吹き替え） · M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語）

0:00
ビジネスセントラルが支払いの称号や製品説明文の作成といった退屈な作業を代行してくれたらいいのにと思いませんか
0:05
クリック作業や深夜のエクセル作業に追われるのはもう終わりにしましょうそれがコパイロットの約束です先にお答えしておくとこれはビジネスセントラル
0:13
オンライン版に標準搭載されており追加費用はかかりませんただしオンプレミス環境では動作しませんのでご注意くださいここからが本題です
0:19
ほとんどの管理者は用意されたデモ以上のことは見ていません今日はその中身を解き明かしコパイロットを自社のビジネスに役立てる方法を教えします
0:25
この動画を見終わる頃にはサンドボックス環境で検証できる生存チェックリストが手に入りますすべてはマイクロソフトがあまり公言していない隠されたメニューから始まります
0:33
コパイロットの隠しメニューその真の力は顧客カードに表示される華やかなボタンの中にはありません真の仕掛けはマイクロソフトがその裏側に残した要素にあります
0:41
これらの拡張ポイントはシステム ai 名前空間の中にありますコパイロットケーパビリティコードユニットと関連する列挙型 enum を探してみてくださいそこに開発者向けの実際のフックが存在します
0:50
これらは単なる無意味なコードの断片ではありませんマイクロソフトが市販機ごとに新しいデモを発表するのを待つのではなく独自の ai 機能を定義登録できるように構築されているのです
0:59
多くのユーザーが触れているメニューは本の表面にすぎません請求データを入力して要約を作成したり製品説明文をドラフトしたりそれも悪くはありません
1:07
しかしそれらはほら動くでしょうと見せるためのデモ用シナリオにすぎません実際ビジネスセントラルの内部にはコパイロットケーパビリティやコパイロットアベーラビリティといったオブジェクトが存在します
1:15
平たく言えばケーパビリティとはコパイロットのために作成するスキルセットのことですアベーラビリティはそのスキルをいつどこでエンドユーザーに表示するかをシステムに指示するものです
1:24
これらを組み合わせることで単なる出来合いの ai ウィジェット集ではなくなりますコパイロットを自社専用にカスタマイズするためのフレームワークになるのです
1:30
ここが最大のポイントです多くの管理者はコパイロットは光り輝くブラックボックスのように完全にロックされていると思い込んでいます
1:36
用意されたものを使ってそれ以上は気にせず次に進んでしまいます追加の制御機能を探そうともしませんしかし開発者レベルでは調整用のレバーが露出しています
1:43
そしてもちろん開発者が登録した結果を管理者が実際に確認する方法もありますビジネスセントラル内のコパイロットおよびエージェントの機能ページを開いてください
1:50
登録したすべての機能がそこに表示されます何か不具合があれば管理者が個別に機能をオフにすることも可能です
1:56
開発者がある言語で定義し管理者がUIで管理するこの繋がりこそが単なる理論を実用的なものにする架け橋なのです
2:03
ロックされたアップルデバイスではなく隠しデバッグコマンドを備えたコンソールのようなものだと考えてくださいもしメインのコパイロットボタンをクリックするだけならあなたは本来のパワーを生かしきれていないことになります
2:12
まるでテスラを運転していて渋滞の中を少しずつ進んでいるようなものですラディカラスモードのスイッチはあってもそれを入れなければアイドリングしているのと同じです
2:19
ここでも同じことが言えます名前空間オブジェクトはすでにテナント内にありますが場所を知らなければ決して使うことはありません
2:25
ではどれほどの馬力があるのでしょうかビジネスセントラル内の ai モジュールはテキスト保管やワークフロー向けのチャット風保管
2:32
セマンティック検索用の埋め込みを提供しますつまりマイクロソフトの想定ではなく自社のパターンに基づいて発注書を起案する機能などが構築できるの
2:42
ですまた堅苦しい人事メモのような口調ではなく自社らしいトーンで話すアシスタントも作成できます
2:48
勘違いされる前に少し注意点をビジネスセントラルで見たかもしれないコパイロットとのプレビューチャット機能はこのモジュールで拡張することはできません
2:55
そのチャットは独自の道を歩んでいます皆さんが拡張するのはここで説明する機能モデルを通じて行います
3:00
マイクロソフトのマーケティングではこの点がうまく伝えられていませんドキュメントにはありますが管理者が滅多に読まない技術セクションの奥深くに埋もれています
3:06
しかしこれらのオブジェクトの存在を知れば状況は一変します経理の癖特殊なカスタムフィールド複雑な承認フローなどすべてを自前のコパイロット機能で解決できます
3:16
レドモンドマイクロソフト本社からのおこぼれを待つのではなく環境に合わせて直接アシスタントをカスタマイズできるのです
3:22
もちろん強力な機能には注意書きがつきものですこれらは諸刃の剣でもあります機能の登録を誤ると特にマイクロソフトのアップデート時に競合が発生する可能性があります
3:31
拙いやり方をすればサンドボックスが壊れたり最悪の場合本番環境のユーザーをブロックしたりしかねませんだからこそコパイロットとエージェント機能のページが重要なのです
3:38
管理者に可視性を提供するだけでなくカスタムAIが暴走した際の強制終了スイッチにもなりますつまりここでの収穫はシンプルです
3:46
そうコパイロットには隠しメニューがありますそうどのテナントにもすでに存在しています
3:50
そしてコパイロットをおもちゃから実用的なツールに変えることができますが存在を知ることはまだ第一歩に過ぎません
3:55
真のコツは環境を焼き払わずに火力を追加できるよう機能を安全に登録することです次はそこへ向かいます環境を壊さずに登録する方法です
4:05
コパイロット機能の登録は曖昧な魔法のトリックではありません平易なある言語で言えばコパイロット機能enumのenum拡張を作成し
4:13
インストールまたはアップグレードコードユニットからコパイロット機能を呼び出すということです機能の登録それがビジネスセントラルに
4:19
ここに新しいai機能があると伝える悪種のプロセスですシステムの一部として扱ってくれとねその呼び出しがないと拡張機能のコンパイルは通るかもしれませんが
4:26
コパイロットはその機能の存在すら認識できませんこれは人事関連の書類を提出するようなものだと考えてください
4:31
組織図に記録がなければデスクもメールアドレスもなくその社員は存在しないことになります基本的な定義ができたら次に考えるべき詳細はスコープと命名です
4:39
登録するすべての機能はマイクロソフトが絶えず更新している同じエコシステム内で動作します汎用的な名前を再利用したり適当な id を割り当てたりすると競合を招くのは目に見えています
4:48
例えばセールスヘルパーという名前にして一般的な列挙地 enum を割り当てたとしますその後マイクロソフトが同じ領域の組み込み機能を将来のアップデートでリリースしたらどうなるでしょう
4:55
システムはどちらを表示すべきか判断できなくなり実行時にあなたのコードとマイクロソフトのコードが衝突します
5:00
その対策は地味ですが不可欠ですユニークな名前を選び一般的な範囲と重ならない独自の列挙地を割り当て拡張機能全体を意図的にバージョン管理してください
5:08
バージョン番号を付ければサンドボックス環境が1.2で本番環境がまだ1.0であるといった状況を把握できます
5:13
プラットフォームに変更があった場合アップグレードコードユニットがその機能を安全に引き継ぐためのツールとなります
5:19
それがなければ古い配電盤に新しい配線をガムテープで無理やり固定して発火しないことを祈るようなものです
5:24
さてここからが多くの開発者が甘く見がちなところですただの機能だからといって拡張機能をいきなり本番環境に放り込んでしまうのです
5:30
そうなればヘルプデスクは問い合わせの嵐になるでしょう正しい手順はシンプルです
5:33
まずはサンドボックス環境だけで行います壊してリファクタリングして再テストする
5:36
正常に動作することが確認できて初めて本番環境へ移行しますその計画的なロールアウトがトラブルを減らします
5:41
これは単にコードをコンパイルするだけでなくガバナンスの問題でもありますビジネスセントラルのコパイロットとエージェントの機能ページは正当性を確認するためのチェックツールにもなります
5:48
登録後にそのページに機能が表示されなければ登録が正しく行われていませんそのページこそがシステムの真実を反映しています
5:55
そこで検証を終えてから始めて管理者のレビューに回すべきです管理者の話が出ましたがコパイロット機能のオンオフの切り替えやデータ移動の設定は
6:03
スーパー権限を持つ管理者やビジネスセントラルの管理者ロールを持つ人しか行えませんそのガバナンスの手順を事前に計画しておきましょう
6:11
ちょっとしたプロのアドバイスとして登録時にオプションの詳細リンクランモア url パラメータを使用してください
6:15
それがコパイロットとエージェントの機能管理ページにそのまま表示されますこれは単なる心遣いではなくドキュメントを組み込むということです
6:23
管理者がウィキリンクを探し回ったりチームであなたに質問したりする必要はなく機能の内容や使い方を直接クリックして確認できるようになります
6:30
照明のスイッチに説明書きをして次の人が間違ったスイッチを押さないようにするようなものだと考えてください
6:35
リスクを軽減するためのベストプラクティスチェックリストをご紹介します 1つ目は本番環境の前に必ずサンドボックスで実行すること
6:40
2つ目は1位な列挙地を選択し一般的な範囲を避けること 3つ目は常にインストールアップグレードユニットを使用してクリーンな移行パスを確保すること
6:47
4つ目は管理者が後で推測しなくて済むよう詳細はこちらの url を添付することです
6:51
これら4つを守ればテナントを安定した状態に保てます無視すれば深夜3時にデータベースの復旧作業に追われることになるでしょう
6:57
駐車スペースの例えはここでも当てはまります機能の登録とは新しい車のために正式に駐車場所を予約するようなものです
7:03
適切な書類に記入すれば場所は確保され誰もが幸せです手続きを飛ばしたり禁止区域に駐車したりすれば消防車道を塞いでしまい誰もが怒り出すでしょう
7:10
登録とはビジネスセントラルとマイクロソフトの更新プログラムが長期的に共存できるよう
7:14
機能のための安全な場所を確保することです結論として登録処理は本番コードとして扱ってください
7:19
なぜならまさにそれ自体が本番コードだからですサンドボックスでテストしスコープを1位に保ちバージョンを追跡しアップグレードコードユニットを完璧に仕上げましょう
7:26
もし何か異常が発生した際コパイロットとエージェント機能ページそして詳細はこちらの url があれば管理者は問題を特定し理解し必要に応じて機能を停止できます
7:34
正しく行えば登録作業は安定性をもたらします雑に行えば混沌を招くことになります
7:39
それが完了すると機能自体は動作するものの一般的すぎると感じるはずです回答はしますが個性がないのですそれは優秀な人材を雇ったのに会議でミュートのまま黙っているようなものです
7:48
次のステップはコパイロットに振る舞いを教えることですさもないと信頼できるアシスタントではなく質問に対して呆れた態度を取るティーンエイジャーのように見えてしまいます
8:05
マイクロソフトの開発者向けドキュメントではメタプロンプとはモデルのプロファイル出力形式ガードレールを定義する主要なシステムメッセージとされています
8:13
簡単に言えばAIの職務記述書です一度限りのユーザープロンプとが単発の依頼だとすればメタプロンプとは全ての回答に組み込まれる
8:20
高級的な指示書ですこれがないとコパイロットは母規担当として話すべきかコピーライターとして話すべきか判断できません
8:25
単に推測するだけになりますこのように考えてみてください職務内容を伝えず人を雇うことはないはずです
8:31
メタプロンプとはAIにとってまさにそれに当たりますいつフォーマルな言葉遣いをすべきか結果をどうフォーマットするかどんなトーンを使うべきか
8:38
そして絶対に避けるべきことは何かをコパイロットに伝えますそれによってワークフローに適合した回答と意見ばかり言う過去のクリッピーのような回答との間に差が生まれるの
8:45
です管理者はよくメタプロンプととプロンプとを混同しそれ故に不満を感じるのです
8:50
文脈を与えずに元帳エントリーを出してとだけコパイロットに投げれば独自のスタイルで勝手に作成してしまいます無駄に長い段落になったり存在しないフィールドが表示されたりするかもしれません
8:58
同じリクエストをあなたは財務アシスタントです元帳の入力項目は常にビジネスセントラルのフィールド名を使用した箇条書きで出力してくださいといったメタプロンプとで囲みます
9:06
あくまで例ですすると突然回答が整理され構造化され見やすい形式になりますダードレールはリクエストが実行される前に固定されます
9:13
マイクロソフトはこの区別を意図的に設けましたプロンプとは一時的なリクエストですがメタプロンプとはチャットの全コンテキストを通じて維持されます
9:20
開発者はセットプリマリシステメッセージを呼び出すことで AOAIチャットメッセージのコードユニットを通じてこれらを設定します
9:27
メタプロンプと自体をアイソレーテッドストレージに保存すればあるファイルにテキストをハードコーディングするのではなく拡張機能から安全に取得更新できます
9:34
ドキュメントに目を通せばアイソレーテッドストラギセットやアイソレーテッドストラジジェットを使用した例が見つかるはずです
9:40
それが本番環境に適したモデルですこれによりメタプロンプとを有効に保ちつつ拡張機能のセキュリティ境界内に隔離できます
9:46
では詳細な仕組みに入りましょうビジネスセントラルのAIモジュール経由でアジュールオープンAIサービスにユーザー入力を送信する場合
9:52
好むと好まざるとに関わらずトークン予算と温度設定を扱う必要がありますトークン予算は重要です
9:57
メタプロンプとユーザーのプロンプとの合計がモデルのトークン制限の対象となるためですですから小説のような長いシステムメッセージを詰め込まないでください
10:03
簡潔にまとめましょうそして温度テンペラタはランダム性を制御しますフィールドの正確性が求められる財務シナリオでは温度を0に近い低い値に設定してください
10:11
マーケティング機能を構築していてより色彩豊かなドラフトが必要な場合は温度を上げてアドリブを聞かせましょうこれは推測ではありませんビルドガイドに記載されています
10:18
コンプライアンスに関するもう一つの注意点です監査人はあなたの創造性など気にしません彼らが気にするのは数字が一致しているかどうかです
10:25
メタプロンプとには明示的な書式設定ルール応答構造無関係な解説の禁止事項を含めるべきですそうすればコパイロットの出力はユーザーにとって見栄えが良いだけではなくなります
10:33
下流システムや監査にも耐えうるものになりますメタプロンプとドキュメントの一部でありリスク管理の一部であると捉えてください
10:38
人格の使い分けこそがこの機能の面白いところですマーケティング向けコパイロットのメタプロンプとでは説得力のある言葉を使い製品のキャッチコピーを考えるよう指示するかもしれません
10:46
一方で財務向けコパイロットには形容詞を使わず構造化された仕分けデータを生成せよと指示します根底にある ai は同じでも事前に人格を定義しておくことで結果は全く異なるものになります
10:54
これこそが実用的な自動化と誰も使えない見せかけだけの出力との違いですこのセクションがマナーに関する内容だとしても基盤となるインフラを無視することはできません
11:02
メタプロンプとが機能するのはアジュールへの接続が正しく設定されている場合のみです ai はビジネスセントラル上でローカルに処理を行うわけではありません
11:08
すべてアジュールオープン ai のバックエンドを経由してやり取りされますそのパイプラインを誤ればどれほど優れたルールを記述しても意味がありません
11:14
失敗が続いたりさらに悪いことにはキーが誤作動したりする可能性があります結論としてプロンプとはリクエストに過ぎないということです
11:19
メタプロンプとはいわば提示命令です正しく作成し安全に保管しトークン計算を確認し作業内容に合わせて温度を設定してください
11:25
そうすることでコパイロットを単なるおしゃべりなツールから実際に信頼できる役割特化型のアシスタントへと変えることができます
11:30
適当にやれば夜通しレポートから無意味な内容を修正することになりますがたとえどれほど優れたメタプロンプとであっても認証情報が丸見えでは意味がありません
11:37
そして真の危険はそこにありますトーンや形式ではなくコパイロットとアジュールオープン ai を接続するためのキーをどのように保管し保護しているかという点です
11:45
キーの保護こそがアジュールセキュリティを正しく行うということですキーの保護は華やかではありませんがテナントを守れるかそれともインシデント報告書を書くハメになるかの分かれ道となります
11:53
コパイロットがアジュールオープン ai を呼び出す際には毎回必ず3つの情報が必要になりますリソースエンドポイントつまりアジュールオープン ai リソースの url デプロイメント名そして api キーです
12:03
これら3つが揃うことであなたのテナントがモデルとの対話を許可されていることを証明するハンドシェイクが成立しますどれか一つでも放置すればそれは ai の活用ではなく侵害シミュレーションを行っているようなものです
12:12
はっきり言いましょうどのような状況であってもこれらの値をあるにハードコードしてはいけません利便性を求めて api キーを高度に埋め込んだり github に放置したりすれば認証情報スキャナーに対してリポジトリを食べ放題だと宣伝しているようなものです
12:24
開発者はテスト用だからと軽視するかもしれませんがリポジトリは常に晒された秘密情報を求めて巡回されています実際の顧客データが公開サイトに流出するのはまさにそのせいです
12:32
パッチチューズデーで修正できるような問題ではありません安全な道筋はすでにマイクロソフトによって示されています開発やテストの作業にはあるの分離ストレージ
12:39
アイソレーテッドストレージが最適です拡張機能内にあるロッカーのようなものだと考えてくださいキーを中に入れれば他の拡張機能が覗き見ることはできません
12:47
分離されていて軽量でシンプルにもたれますサンドボックスや開発ビルドには最適ですが勘違いしないでください
12:53
分離ストレージは本番環境用ではありませんローカルスコープは反復開発には便利ですが実際のユーザーとデータが関わる現場の保管庫として設計されているわけではありません
13:01
しかし本番環境へ移行する際はアップキーハウルトあるいは広範囲に展開する場合はアジュールキーハウルトを使用するのが唯一の責任がある選択です
13:07
これは現金を机の引き出しに隠す代わりに銀行の貸金庫を借りるようなものだと考えてください
13:11
キーハウルトは適切なログ管理とローテーションポリシーを備えたアクセス制御された安全なコンテナ内にAPIキーを保持します
13:17
拡張機能をキーハウルトと統合し実行時に必要なものを呼び出せば生のキーをコード内にさらすことはありません
13:21
これが監査担当者に好まれるパターンです秘密情報がプレーンテキストとしてどこにも存在しなかったことを証明できるからです
13:27
退屈なガバナンスの話ですがコンプライアンスチームがやってくるときに求められるのはまさにその退屈さなのです
13:31
ドキュメントに記載されている重要な詳細を一つご紹介しましょうあるではAPIキーをシークレットテキストシークレットテキストとして保存できます
13:38
そうすればデバッグでステップ実行してもキーが平文で表示されることはなくスクリーンショットを取られる心配もありません
13:44
シークレットテキストはその名前の通りです実行時に機密値を隠してくれます
13:48
このセクションで一つだけ覚えておいてほしいのはこのオプションが存在するということです
13:52
これはデバッガー上での意図しない開発者による露出という最も初歩的な漏洩経路を塞いでくれます
13:58
ではプロの管理者の視点でやっていいことと悪いことを整理しましょう
14:02
APIキーをあるコードに埋め込んだりリポジトリに貼り付けたりしないでください
14:06
それは認証情報の採取を招く餌になります
14:08
開発やテストには分離ストレージを使用し平文で秘密情報を送ることなくチームの生産性を維持しましょう
14:14
その開発用パターンを本番環境に持ち込まないでください
14:16
それは金庫ではなくただの書類棚にすぎません
14:18
本番環境のビルドは必ずキーハウルトに接続してください
14:21
それが長期的にキーを安全に保管できる唯一の場所です
14:23
もう一つ注意点としてビジネスセントラル内のユーザー権限ではAPIキーを魔法のようにロックダウンすることはできません
14:28
コパイロットはビジネスデータへのアクセス制御を引き継ぎますがキーはサービス全体の認証に関わるものです
14:33
もし一つでも流出すれば外部から統合全体を乗っ取られる恐れがあります
14:36
ですから権限のスコープ設定だけで安全だと思い込むのはやめましょう
14:39
それでは不十分です
14:41
設定を検証したい場合の公式な手順はAzure OpenAIコードユニット内の認証設定シーケンスを実行することです
14:46
そこでリソースURLデプロイメント名APIキーを入力し全てが正しく連携していることを確認します
14:51
手順を間違えればコパイロットはロードすらされません
14:54
中途半端だとユーザーの方が先に気づくような沈黙のエラーが発生します
14:57
解決策は単純です
14:59
チェーンを順番に実行し開発環境でクリーンにテストしてからプレ本番そして本番へと進めるのです
15:03
3つの環境3つのキーセットそして負荷がかかっても機能する一つのパイプライン
15:07
それではトラブルを避けるためのチェックリストです
15:09
開発には分離ストレージ本番にはキーファウルトを使用しAPIキーはシークレットテキストで保護すること
15:15
値をコードに埋め込まず作業完了の前に必ず認証チェーンをエンドツーエンドで実行してください
15:20
そのパターンを守れば夜中の緊急対応に追われることなくコパイロットの統合を安全かつコンプライアンスに適合した状態で維持できます
15:27
セキュリティの課題が片付いたら次はキーの隠し場所よりもエラーを出さずに全てのパーツをいかに連携させるかという課題に移ります
15:34
機能やメタプロンプと安全なキーがあってもそれらが独立して互いに干渉しあっていては意味がないからです
15:40
そこで登場するのがワークフローの連携です
15:43
設計図から現実へワークフローの構築について
15:46
さてバラバラのパーツを実際に機能するコパイロットフローへと変える方法についてお話しします
15:51
機能ケーパビリティを登録し範囲を定めキーを確保しメタプロンプとを作成したとします
15:56
しかしそれらを適切な順序で配置しなければエラーになるかユーザーからチケットが発行されるまで何もしないただの綺麗なボタンが出来上がるだけです
16:04
ここではその手順を5つのステップに凝縮して解説します
16:07
ステップ1機能ケーパビリティステップ2有効性アベーラビリティステップ3認可オーソリゼーションステップ4メタプロンプとステップ5パイロットパイロット
16:15
この5つを覚えておけば頭の中にいつでも配線図を書くことができます
16:19
機能がスキルを与え有効性が対象を定め認可がNOを呼び起こしメタプロンプとがマナーを教えパイロットが実際に機能することを証明します
16:25
これが一連のループです
16:27
ステップ1機能ケーパビリティあるにおいてはコパイロットの機能ENUMをENUM拡張で拡張しインストールまたはアップグレードのコードユニットでコパイロット機能を呼び出して登録することを意味します
16:37
機能を登録しますそれは新しいアシスタントスキルがここにあると宣言する正式な求人票のようなものです
16:41
システムにその枠を与えてください
16:43
これがないとビジネスセントラルはあなたの機能の存在すら認識できません
16:47
ステップ2有効性アベーラビリティスキルが定義されたらそれがどこで表示されるかを範囲指定します
16:53
これはコパイロットおよびエージェント機能の管理ページで制御されます
16:56
プレビューとしてマークするか内部専用にするかあるいは一般公開するかを決定します
17:00
開発者にとってはメタデータですが管理者にとっては展開のための切り替えスイッチです
17:04
これを使用してください
17:05
このステップをスキップすると未完成の機能を安定する前に全てのユーザーに公開するリスクがあります
17:10
ステップ3認可オーソリゼーション
17:12
次にAzure OpenAIコードユニットを通じてAzure OpenAIバックエンドに接続します
17:16
おなじみのリソースエンドポイントつまりAzure OpenAIのURL、デプロイメント名、APIキーの3点が必要です
17:23
Azure OpenAIを呼び出します
17:25
それらの値を使って認可を設定します
17:28
機能が求人広告で有効性が契約なら認可はアシスタントを建物に入れるためのIDバッジです
17:34
これがないと機能はガラスのドアの前で立ち往生してしまいます
17:37
ステップ4メタプロンプト
17:38
ここで口調、構造、フォーマットを形作る基本的な指示を注入します
17:42
AOAIチャットメッセージを使用します
17:44
プライマリシステムメッセージを設定しアイソレーテッドストレージに安全に保管した
17:48
あるいは本番環境ではキーハウルトから参照したメタプロンプトを取得します
17:51
ここであなたは見積りアシスタントですと指定します
17:54
あるいはあなたは財務ヘルパーですといった具合です
17:56
そして出力がどのようなものであるべきかを固定します
17:58
これがないとアシスタントは困ったようにその場で適当な回答をしてしまいます
18:01
ステップ5パイロット
18:01
パイロット
18:02
まずは少人数のグループで展開してください
18:04
機能を提供しフィードバックを収集しテレメトリを監視します
18:07
AIモジュールは利用状況をログに記録するため適切な出力ができているか
18:09
不要な情報を大量生成していないかを確認できます
18:11
展開する前にロールバック計画が必要です
18:14
幸いなことにコパイロットおよびエージェント機能ページが緊急停止スイッチとして機能します
18:18
管理者は何らかの不具合が発生した場合個別の機能を即座に無効化できます
18:22
その同じページにはアジュールの設定が複数リージョンにまたがる場合の地理的データ移動の許可トグルも表示されます
18:28
それが表示されたら注意を払ってください
18:30
コンプライアンス担当者は必ずチェックします
18:32
この手順を現場の例で確認してみましょう
18:34
あるチームが販売オーダー提案用のコパイロットを構築しました
18:37
彼らはまずコパイロット機能用の列挙型拡張から始めインストール済みのコードユニットと連携させました
18:42
それをコパイロットおよびエージェント機能ページでプレビューとしてフラグ付けしテストユーザーのみに表示されるようにしました
18:47
次にアジュールオープンAIを呼び出しました
18:49
モデルが適切に応答するようにエンドポイントデプロイメントキーを設定して認証を行いました
18:54
続いてメタプロンプトを隔離ストレージに書き込みAOAIチャットメッセージで設定しました
18:58
プライマリシステムメッセージを設定します
19:01
あなたは見積りアシスタントです
19:02
バンドルを提案し金目行きとしてフォーマットしてください
19:05
余計な会話は不要です
19:06
パイロット運用では出力が予測可能になるまで少人数のグループでテストを行いました
19:10
その後に初めて可用性をGA一般公開としてマークし全ての営業担当者向けに有効化しました
19:14
その結果不要なやり取りを省きバンドルを推奨するコパイロットが完成しました
19:18
ここでのガバナンス層はオプションではありません
19:20
もし何かがうまくいかなくなっても管理者がトグルをオフにすればユーザーからの問い合わせを防げます
19:24
この遮断機のような考え方こそがカスタムコパイロットの生産性を維持し混乱を防ぐ鍵となります
19:29
他の拡張機能と同じように段階的な展開限定された範囲測定可能なテストを適用してください
19:34
AIだからといって例外ではありません
19:36
テストの際は各部分を分離して実行してください
19:38
全体をつなげてからうまくいくはずと願うのはやめましょう
19:40
機能登録を検証し可用性が正しく表示されるかを確認し認証設定で権限を確認してからメタプロンプトが応答に反映されるかを確認します
19:49
全てのピースが機能して初めてエンドユーザーに利用させます
19:52
それが設計図を現実に橋渡しする方法です
19:55
簡単に言えば機能がスキルを定義し可用性が対象を絞り認証が扉を開きメタプロンプトがルールを決めパイロット運用がシステムとしての信頼性を証明します
20:03
これらを正しく行えば公式の機能ロールアウトより一歩先んじることができます
20:07
そしてより重要な点に戻ります
20:09
これらのステップこそがマイクロソフトがステージで見せるデモのままに従うのではなくビジネスに合わせてコパイロットを形成する術なのです
20:16
ではまとめに入りましょう
20:18
覚えておくべき3つのポイントです
20:20
1つ目機能を登録することでシステムAIを通じてコパイロットを拡張すること
20:24
2つ目Azure接続を保護すること
20:26
テスト中は分離されたストレージを使い本番環境ではキーをキーファウルトへ移行してください
20:30
3つ目コパイロットとエージェントの機能ページから機能を試験管理し管理者が常に停止権限を保持できるようにすること
20:36
ガバナンス担当者への簡単な注意点ですがコパイロットはユーザーの権限を継承するためアクセスできないデータは読み取りません
20:43
またマイクロソフトがテナントのデータを使ってモデルを学習させることは明示的な許可がない限りありません
20:48
次のステップとして今週中にサンドボックスで1つの機能を試しチェックリスト通りに動作するか確認してください
20:53
その後M365章のニュースレターを公読してサバイバルガイドの最新情報を受け取り
20:58
M365章のリンクとインページをフォローしてトラブルを乗り越えてきたMVPによるライブ配信をチェックしましょう