WEBVTT

00:00:00.000 --> 00:00:06.260
マイクロソフト365コパイロットの導入は伝説のアイテムを手に入れたような気分にさせてくれますが実際はスターターキットに過ぎないことに気づくはずです

00:00:06.260 --> 00:00:10.580
標準の状態ではモデルが持つ基本知識とテナント内のコンテンツを利用するだけです

00:00:10.580 --> 00:00:16.260
便利ではありますが誇りをかぶったソップ標準作業手順書や人事のガイドラインあるいは隅に潜む巨大なERPシステムはどうでしょうか

00:00:16.260 --> 00:00:19.820
コネクタやグラウンディングカスタムエージェントがなければコパイロットはそれらにアクセスできません

00:00:19.820 --> 00:00:22.100
良いニュースはあなたが教え込めるということです

00:00:22.100 --> 00:00:27.960
肝心なのはいつコパイロットスタジオを使いいつチームツールキットに切り替えガバナンスや監視ライセンスをどう運用に組み込むかを知ることです

00:00:27.960 --> 00:00:29.980
なぜならここからが本当の展開だからです

00:00:29.980 --> 00:00:32.420
最初のエージェントを作成することがラスボス戦ではありません

00:00:32.420 --> 00:00:34.380
それは単なるチュートリアルの終了に過ぎません

00:00:34.380 --> 00:00:35.960
ビルドはボス戦ではないのです

00:00:35.960 --> 00:00:40.960
最初のエージェントをテストしプロンプトが機能しデモデータが完璧に見えると一瞬ゲームをクリアしたような気分になります

00:00:40.960 --> 00:00:41.960
それが罠です

00:00:41.960 --> 00:00:44.560
本当の仕事はそのビルドを本番環境に向けた時に始まります

00:00:44.560 --> 00:00:46.860
そこでは環境が全く異なるルールで動いているからです

00:00:46.860 --> 00:00:50.100
多くの開発者がテストで良い回答が得られたらミッション完了だと勘違いしています

00:00:50.100 --> 00:00:52.820
実際にはそれはイージーモードのストーリーに過ぎません

00:00:52.820 --> 00:00:57.600
本番環境は開発用ノートPCで概念実証ポックがうまくいったかどうかなど気にしません

00:00:57.600 --> 00:01:04.320
本番環境が求めるのはストレス下での安定性でありコンプライアンスチェックIDガードレールそして厳格な稼働率基準です

00:01:04.320 --> 00:01:07.020
そしてここで最初のボスモンスターが登場します

00:01:07.020 --> 00:01:08.120
スケーラビリティ

00:01:08.120 --> 00:01:10.920
エージェントはエンタープライズレベルの負荷に耐えられるでしょうか

00:01:10.920 --> 00:01:14.800
そこでコパイロット制御システムからの監視ログと診断ログが重要になります

00:01:14.800 --> 00:01:16.220
グラウンディングの陳腐化

00:01:16.220 --> 00:01:20.580
シェアポイントやデータバースのデータが変更されたときエージェントは正しく最新データに接続し続けられるでしょうか

00:01:20.580 --> 00:01:23.080
コネクタとグラフグラウンディングがその防波堤となります

00:01:23.080 --> 00:01:25.020
コンプライアンスと監査可能性

00:01:25.020 --> 00:01:27.840
規制当局や内部監査人から指摘を受けた際

00:01:27.840 --> 00:01:31.980
エージェントの履歴は完璧なログと秘密ドラベルによってレビュー可能でしょうか

00:01:31.980 --> 00:01:35.440
これらが一つでも欠ければ勝利の画面はすぐに消え去ります

00:01:35.440 --> 00:01:40.840
コパイロットスタジオでのテストは無制限の回復ポーションがあるトレーニング上でのスパーリングのようなものです

00:01:40.840 --> 00:01:44.400
呪文を唱えプロンプトを試せば全てが輝いて見えますが

00:01:44.400 --> 00:01:47.520
実運用ではファイアウォールによる遮断は不発となり

00:01:47.520 --> 00:01:50.340
過不可な外部データソースは応答を極端に遅くします

00:01:50.340 --> 00:01:54.620
その瞬間ユーザーはそれを賢いとは呼ばずサポートチケットを発行し始めるのです

00:01:54.620 --> 00:01:58.040
ガバナンスを後回しにするチームで最もよくある停滞失敗が起こります

00:01:58.040 --> 00:02:00.200
彼らは後で追加すればいいと言い聞かせますが

00:02:00.200 --> 00:02:03.400
ガバナンスを先延ばしにするとほぼ確実に悪い驚きが待っています

00:02:03.400 --> 00:02:05.040
スケーリングの問題やデータの不一致

00:02:05.040 --> 00:02:08.120
コンプライアンスの欠如がまさに最悪のタイミングで露呈するのです

00:02:08.120 --> 00:02:10.960
セキュリティとコンプライアンスはオプションのサイドクエストではありません

00:02:10.960 --> 00:02:12.820
それらはキャンペーンマップの一部なのです

00:02:12.820 --> 00:02:14.580
ではアーキテクチャについて話しましょう

00:02:14.580 --> 00:02:16.760
コパイロットの脳は単一のブロックではないからです

00:02:16.760 --> 00:02:18.580
基盤モデルという正の言語エンジンがあり

00:02:18.580 --> 00:02:20.160
その上にオーケストレーターがいて

00:02:20.160 --> 00:02:22.160
どの機能をいつ呼び出すかを調整します

00:02:22.160 --> 00:02:24.320
マイクロソフト365個パイロットはデフォルトで

00:02:24.320 --> 00:02:25.620
そのオーケストレーションを提供するため

00:02:25.620 --> 00:02:27.380
すべてのリクエストに構造が与えられます

00:02:27.380 --> 00:02:28.680
次にグラウンディングです

00:02:28.680 --> 00:02:30.580
これはエンタープライズコンテンツへのつなぎ止めであり

00:02:30.580 --> 00:02:32.020
答えが捏造されないようにします

00:02:32.020 --> 00:02:33.200
最後はスキルです

00:02:33.200 --> 00:02:36.400
実際のタスクを実行するためのカスタムプラグインやコネクタのことです

00:02:36.400 --> 00:02:38.720
これら4つの要素を切り離されたサイロとして扱うと

00:02:46.760 --> 00:02:48.220
一つのスタックとして扱うとき始めて

00:02:48.220 --> 00:02:49.620
エージェントは頑丈さを保てます

00:02:49.620 --> 00:02:52.200
では実際の現場における成功とはどのようなものでしょうか

00:02:52.200 --> 00:02:54.040
デモのプロンプトにうまく答えることではありません

00:02:54.040 --> 00:02:55.580
それは練習モードにすぎません

00:02:55.580 --> 00:02:58.540
成功の証は給与計算の繁忙期やデータ移行の真っ只中

00:02:58.540 --> 00:03:00.020
コンプライアンス担当者の監視家

00:03:00.020 --> 00:03:02.900
そして高負荷なリクエスト環境といった現実世界で持ちこたえることです

00:03:02.900 --> 00:03:05.580
そこでこそエージェントは実行に値することを証明します

00:03:05.580 --> 00:03:07.760
多くの構築が失敗する理由は他にもあります

00:03:07.760 --> 00:03:09.320
組織がそれを運用システムではなく

00:03:09.320 --> 00:03:11.160
使い捨てのプロジェクトと考えていることです

00:03:11.160 --> 00:03:13.580
誰かがプロトタイプを立ち上げ派手なデモを見せた後

00:03:13.580 --> 00:03:15.100
監視もせずに放置してしまいます

00:03:15.100 --> 00:03:17.180
すぐに各部署が独自のエージェントを作り始め

00:03:17.180 --> 00:03:19.820
ドキュメントもなくチェックされないままトークンを消費し続けます

00:03:19.820 --> 00:03:21.200
単純な運用マニュアルがなければ

00:03:21.200 --> 00:03:22.360
誰がコネクタを管理し

00:03:22.360 --> 00:03:23.700
誰がグラウンディングを監査し

00:03:23.700 --> 00:03:25.420
誰がクレジット消費を確認するのか

00:03:25.420 --> 00:03:28.220
現場は同期されないミニボスだらけの混沌とかします

00:03:28.220 --> 00:03:30.460
視点を変えればずっと簡単になります

00:03:30.460 --> 00:03:33.080
運用マインドセットから始めれば設計は変わります

00:03:33.080 --> 00:03:35.880
最初のテストがうまくいったかどうかだけを気にするのではありません

00:03:35.880 --> 00:03:37.840
日々の業務に向けて堅牢化するのです

00:03:37.840 --> 00:03:40.520
監査ログ、管理者によるゲート、バックアップ、ヘルスチェック

00:03:40.520 --> 00:03:41.560
これらが信頼を築き

00:03:41.560 --> 00:03:43.460
プレッシャーのかかる状況下でシステムを維持します

00:03:43.460 --> 00:03:47.020
管理者にはマイクロソフト365管理センター内に利用可能なコントロールがすでにあり

00:03:47.020 --> 00:03:48.320
そこではシナリオを管理し

00:03:48.320 --> 00:03:50.060
診断フィードバックを早期に得ることができます

00:03:50.060 --> 00:03:51.560
それらのツールを活用することこそが

00:03:51.560 --> 00:03:54.400
珍しいだけのエージェントと信頼できる運用ツールを分かつ境界線です

00:03:54.400 --> 00:03:56.600
だからこそ作るだけでは勝者にはなれません

00:03:56.600 --> 00:03:58.880
テスト環境は最初のステップに過ぎません

00:03:58.880 --> 00:04:01.680
ガバナンスと監視体制を整えた実際のデプロイこそが

00:04:01.680 --> 00:04:03.520
本当の生存競争の始まりです

00:04:03.520 --> 00:04:05.000
そして深く踏み込む前に

00:04:05.000 --> 00:04:07.400
戦いのための適切な武器が必要になります

00:04:07.400 --> 00:04:09.720
マイクロソフトは2つの異なるキットを用意しており

00:04:09.720 --> 00:04:10.820
それぞれルールが異なります

00:04:10.820 --> 00:04:14.080
選択を誤ればプラスチックの剣でレードに挑むようなことになります

00:04:14.080 --> 00:04:16.480
コパイロットスタジオかチームツールキットか

00:04:16.480 --> 00:04:17.640
武器を選ぶのです

00:04:17.640 --> 00:04:19.660
そこにこそ真の問いが生まれます

00:04:19.660 --> 00:04:21.460
あなたはどちらのツールを手に取りますか

00:04:21.460 --> 00:04:22.580
コパイロットスタジオでしょうか

00:04:22.580 --> 00:04:25.980
それともマイクロソフト365エージェントツールキットとも呼ばれるチームツールキットでしょうか

00:04:25.980 --> 00:04:27.740
どちらもコパイロットを拡張すると歌っており

00:04:27.740 --> 00:04:28.680
似たものに聞こえますが

00:04:28.680 --> 00:04:30.560
対象とする構築者やニーズは大きく異なります

00:04:30.560 --> 00:04:32.200
選択を誤れば時間と予算を浪費し

00:04:32.200 --> 00:04:34.960
本番環境で華やかなデモが機能しなければ信頼を失うことにもなりかねません

00:04:34.960 --> 00:04:37.280
コパイロットスタジオは作り手のための舞台です

00:04:37.280 --> 00:04:40.360
これはスピードと明快さを追求したローコードのビジュアルビルダーです

00:04:40.360 --> 00:04:41.800
ドラッグ&ドロップによるフロー作成

00:04:41.800 --> 00:04:43.060
テンプレートガイド付き対話

00:04:43.060 --> 00:04:44.620
そして組み込みの分析機能が利用できます

00:04:44.620 --> 00:04:48.720
スタジオにはマイクロソフト365データソースへの接続が豊富に用意されており

00:04:48.720 --> 00:04:50.660
パワーユーザーならコードを一切書かずに

00:04:50.660 --> 00:04:53.060
シェアポイントコンテンツの抽出やチームメッセージの監視

00:04:53.060 --> 00:04:55.240
人事規定ドキュメントの参照などが可能です

00:04:55.240 --> 00:04:59.620
テスト調整を経てマイクロソフト365個パイロットへ直接公開できるほか

00:04:59.620 --> 00:05:03.020
最小限の手間でスタンドアロンのエージェントとしてリリースすることもできます

00:05:03.020 --> 00:05:07.340
来期ではなく今市販機中に機能するワークフローが必要な部署にとって

00:05:07.340 --> 00:05:08.820
スタジオは最短ルートです

00:05:08.820 --> 00:05:11.680
すでに16万社以上の顧客が財務データの称号

00:05:11.680 --> 00:05:13.040
従業員のオンボーディング

00:05:13.040 --> 00:05:15.320
小売店での製品に関する問い合わせ対応など

00:05:15.320 --> 00:05:17.320
まさにこの用途でスタジオを活用しています

00:05:17.320 --> 00:05:20.240
その理由は明白で単に導入のハードルが低いからです

00:05:20.240 --> 00:05:21.800
チームがすでにパワーアップスを触ったり

00:05:21.800 --> 00:05:23.940
パワーオートメートで提携レポートを自動化したりしているなら

00:05:23.940 --> 00:05:26.040
スタジオは慣れ親しんだ環境のように感じられるでしょう

00:05:26.040 --> 00:05:28.200
ソフトウェアエンジニアである必要はありません

00:05:28.200 --> 00:05:30.480
明確な目標と基本的なローコードのスキルさえあれば

00:05:30.480 --> 00:05:32.280
クリック設定デプロイが可能です

00:05:32.280 --> 00:05:34.380
次にチームツールキットに目を向けましょう

00:05:34.380 --> 00:05:36.800
ここはフルスタック開発者が活躍する領域です

00:05:36.800 --> 00:05:38.460
ツールキットはブスコードに組み込まれるもので

00:05:38.460 --> 00:05:40.120
ドラッグ&ドロップのキャンバスではありません

00:05:40.120 --> 00:05:43.320
ここでは構造化されたルールを持つ宣言型エージェントを設計したり

00:05:43.320 --> 00:05:45.780
さらに踏み込んでオーケストレーションモデルの呼び出しや

00:05:45.780 --> 00:05:48.740
API処理をゼロから定義するカスタムエンジンエージェントを作成したりできます

00:05:48.740 --> 00:05:52.160
コパイロット内だけでなくチームやマイクロソフト365アプリ

00:05:52.160 --> 00:05:53.980
ウェブ外部チャンネル全体にわたって

00:05:53.980 --> 00:05:57.460
スキャホールディングデバッグ構成公開のルートが手に入ります

00:05:57.460 --> 00:05:59.680
コパイロットスタジオがカタログから選ぶ組み立て家具なら

00:05:59.680 --> 00:06:02.960
ツールキットは木材を削り出し家を自ら配線するようなものです

00:06:02.960 --> 00:06:04.300
その自由度は素晴らしいものですが

00:06:10.120 --> 00:06:13.000
実際にはスタジオでの拡張はマイクロソフトが定めたガードレール

00:06:13.000 --> 00:06:17.360
安全なコネクタ管理制御そして軽量なガバナンスの範囲内で行うことを意味します

00:06:17.360 --> 00:06:19.700
一方でツールキットはガードレールの書き換え

00:06:19.700 --> 00:06:22.540
独自のオーケストレーションの構築外部LLMの呼び出し

00:06:22.540 --> 00:06:25.440
マイクロソフトが標準提供していないエージェント動作の実装を意味します

00:06:25.440 --> 00:06:27.080
一方はテンプレートで安全を確保し

00:06:27.080 --> 00:06:30.500
もう一方は性のパワーを提供してそれを責任を持って使いこなすことを期待します

00:06:30.500 --> 00:06:33.260
多くの人はツールを選択すればUIも変わると思っています

00:06:33.260 --> 00:06:34.360
いいえ違います

00:06:34.360 --> 00:06:36.660
スタジオで構築したかツールキットで構築したかに関わらず

00:06:36.660 --> 00:06:38.760
エンドユーザーが見るプロンプトボックスや回答カードは同じです

00:06:38.760 --> 00:06:41.220
それは設計によるものでUX層は統一されています

00:06:41.220 --> 00:06:43.540
実際に変わるのは舞台裏の部分です

00:06:43.540 --> 00:06:46.560
グラウンディングの選択肢スケーラビリティそして管理制御です

00:06:46.560 --> 00:06:49.400
だからこそこの決定は単なる見かけではなく運用の問題なのです

00:06:49.400 --> 00:06:51.020
ここに実践的なルールがあります

00:06:51.020 --> 00:06:53.460
シェアポイントのコンテンツチームのチャットや会議

00:06:53.460 --> 00:06:55.380
埋め込まれたファイルデータバースのデータ

00:06:55.380 --> 00:06:58.420
あるいはメールや人検索へのコネクタといったグラウンディング機能の一部は

00:06:58.420 --> 00:07:00.940
テナントでマイクロソフト365コパイロットのライセンス

00:07:00.940 --> 00:07:04.140
またはコパイロットスタジオの重量課金が有効になっている場合にのみ利用可能です

00:07:04.140 --> 00:07:07.980
その権利がない場合スタジオを選択してもそれらの機能は開放されません

00:07:07.980 --> 00:07:11.460
そのライセンスの確認一つがどちらの道を選ぶべきかの決定だとなり得ます

00:07:11.460 --> 00:07:13.680
ではどのように選択を簡略化すれば良いのでしょうか

00:07:13.680 --> 00:07:15.260
簡単なチェックリストを作成しましょう

00:07:15.260 --> 00:07:18.060
1つ目IT部門を煩わせることなくパワーユーザーが構築できる

00:07:18.060 --> 00:07:20.340
迅速で監査可能かつ管理者が制御可能なエージェントが必要ですか

00:07:20.340 --> 00:07:22.160
それならコパイロットスタジオを選びましょう

00:07:22.160 --> 00:07:24.140
2つ目カスタムオーケストレーションや外部AIモデル

00:07:24.140 --> 00:07:26.660
あるいは企業の機関システムに直接組み込むような深い統合が必要ですか

00:07:26.660 --> 00:07:28.500
それならエージェントツールキットを選びましょう

00:07:28.500 --> 00:07:31.820
3つ目ラベルを信じるのではなくチームの実際のスキルセットと目標を信じてください

00:07:31.820 --> 00:07:33.680
私がよく使う例えは住宅です

00:07:33.680 --> 00:07:35.140
スタジオはプレハブ住宅です

00:07:35.140 --> 00:07:38.100
色やキャビネットは選べますが配管や配線はすでに安全な状態です

00:07:38.100 --> 00:07:39.420
ツールキットはさらちです

00:07:39.420 --> 00:07:43.000
すべてを設計できますが設計が崩れた場合のリスクもすべて背負うことになります

00:07:43.000 --> 00:07:44.960
どちらでも素晴らしい家を建てることができます

00:07:44.960 --> 00:07:47.620
一方はより迅速で複雑さが少なくもう一方は制限がありませんが

00:07:47.620 --> 00:07:48.980
うまく管理しなければ壊れやすいのです

00:07:48.980 --> 00:07:50.740
どちらもグラウンディングなしでは崩壊します

00:07:50.740 --> 00:07:53.320
選んだツールが構築を担うとはいえ正しいデータが与えられなければ

00:07:53.320 --> 00:07:55.080
自信に満ちたデタラメを高速で生成するだけです

00:07:55.080 --> 00:07:57.300
コネクタのないスタジオエージェントはただのオウムです

00:07:57.300 --> 00:07:58.860
グラウンディングのないツールキットエージェントは

00:07:58.860 --> 00:08:00.340
カスタムコードで書かれたオウムにすぎません

00:08:00.340 --> 00:08:03.680
どちらにしてもユーザーに向かって推測をさえずる鳥を飼っているようなものです

00:08:03.680 --> 00:08:07.200
そしてそれがあらゆるエージェントの生命線であるデータ接続につながります

00:08:07.200 --> 00:08:10.820
これはエージェントの頭脳が不完全な情報で占い師のような振る舞いをすることを防ぐものです

00:08:10.820 --> 00:08:12.340
エージェントをグラウンディングさせること

00:08:12.340 --> 00:08:14.600
それは虚無ではなく脳に栄養を与えることです

00:08:14.600 --> 00:08:16.820
グラウンディングによってエージェントは知ったかぶりをやめ

00:08:16.820 --> 00:08:18.460
真の知識に基づいて動き始めます

00:08:18.460 --> 00:08:22.660
適切なソースを与えればハッタリから根拠のある回答を提供できるようへと変わります

00:08:22.660 --> 00:08:26.060
これを怠れば表面上は洗練されて見えてもその回答の根拠は

00:08:26.060 --> 00:08:28.340
と誰かに聞かれた瞬間に崩れ去ってしまいます

00:08:28.340 --> 00:08:32.840
マイクロソフト365個パイロットはすでにマイクロソフトグラフを通じて見えるデータに依存しています

00:08:32.840 --> 00:08:35.780
ファイル、チャット、会議、そして予定表のイベントまで

00:08:35.780 --> 00:08:39.860
それは良いスタートですが最も価値のあるコンテンツはその中心の外側にあります

00:08:39.860 --> 00:08:43.460
ERPには在庫がありCRMは顧客ライフサイクルを管理し

00:08:43.460 --> 00:08:46.040
人事部はシェアポイントの奥深くにプレイブックを保管し

00:08:46.040 --> 00:08:48.220
ポリシー文書はホームの厳重なホルダーにあります

00:08:48.220 --> 00:08:50.680
エージェントをそれらのソースにグラウンディングさせなければ

00:08:50.680 --> 00:08:52.400
検証可能なものを指し示す代わりに

00:08:52.400 --> 00:08:55.340
一般的なモデルの知識を使って自信たっぷりに推測するでしょう

00:08:55.340 --> 00:08:57.860
それらを接続することは単なるドラッグ&ドロップではなく

00:08:57.860 --> 00:08:59.380
繊細な配管作業なのです

00:08:59.380 --> 00:09:01.860
コパイロットスタジオとマイクロソフトグラフコネクタを使えば

00:09:01.860 --> 00:09:03.600
シェアポイントの保存済みドキュメント

00:09:03.600 --> 00:09:05.220
データバースの構造化テーブル

00:09:05.220 --> 00:09:06.480
エクスチェンジのメール記録

00:09:06.480 --> 00:09:08.260
チームのチャット内容にアクセスできます

00:09:08.260 --> 00:09:10.020
マイクロソフトの中核機能だけでなく

00:09:10.020 --> 00:09:12.600
パワープラットフォームを介した1200以上のコネクタで

00:09:12.600 --> 00:09:14.040
外部システムとの連携も可能です

00:09:14.040 --> 00:09:17.000
財務、人事、チケット管理などあらゆる分野が対象です

00:09:17.000 --> 00:09:18.440
既存のコネクタが使えない場合でも

00:09:18.440 --> 00:09:19.580
APIを利用すれば

00:09:19.580 --> 00:09:22.060
標準コネクタでカバーされていない業務アプリを組み込むことができます

00:09:22.060 --> 00:09:23.420
正しく構築されたエージェントは

00:09:23.420 --> 00:09:25.300
これらの保存先から最新の事実を取得し

00:09:25.300 --> 00:09:26.380
文脈に沿って提示します

00:09:26.380 --> 00:09:27.620
魔法のように見えるかもしれませんが

00:09:27.620 --> 00:09:29.360
実は適切に整備されたパイプラインのおかげです

00:09:29.360 --> 00:09:30.600
ただし注意点があります

00:09:30.600 --> 00:09:32.440
これらのグラウンディング、根拠付け、オプションは

00:09:32.440 --> 00:09:33.780
全て無料で使えるわけではありません

00:09:33.780 --> 00:09:37.420
シェアポイントのコンテンツ、チームの会議録、メール、データバースなどのソースへのアクセスには

00:09:37.420 --> 00:09:40.700
多くの場合、テナントでコパイロットのライセンスや課金設定が有効である必要があります

00:09:40.700 --> 00:09:42.780
その権限がなければコネクタは機能せず

00:09:42.780 --> 00:09:46.240
AIアシスタントは最も重要なデータの一部を参照できなくなります

00:09:46.240 --> 00:09:48.860
単にスイッチをオンにするだけで全てが解決するとは思わないでください

00:09:48.860 --> 00:09:50.740
まずはライセンスの構成を確認しましょう

00:09:50.740 --> 00:09:52.620
人事ヘルプデスクの例を考えてみましょう

00:09:52.620 --> 00:09:54.700
誰かが育児休暇のポリシーは何ですか?

00:09:54.820 --> 00:09:55.520
と尋ねます

00:09:55.520 --> 00:09:58.320
グラウンディングがない場合、エージェントはモデルが持つ一般的な知識から

00:09:58.320 --> 00:09:59.700
最もらしい回答を組み立てます

00:10:07.420 --> 00:10:13.320
このわずかな違いが、未検証の発言を監査担当者や人事が承認できる信頼性の高い回答に変えます

00:10:13.320 --> 00:10:15.820
その監査証跡こそが真の強化ポイントです

00:10:15.820 --> 00:10:19.960
根拠付けされた回答にはユーザーや規制当局を元のソースへ導く引用を添えることができます

00:10:19.960 --> 00:10:23.620
コンプライアンス部門からボットの回答理由を問われても長々と説明する必要はありません

00:10:23.620 --> 00:10:25.180
ログを見れば一目瞭然です

00:10:25.180 --> 00:10:26.300
これがプロンプトです

00:10:26.300 --> 00:10:27.780
これが参照したドキュメントです

00:10:27.780 --> 00:10:29.500
そしてこれが生成された回答です

00:10:29.500 --> 00:10:32.720
幸運を祈る必要はありませんが、すべての接続は同時にリスクポイントでもあります

00:10:32.720 --> 00:10:37.800
人事データとの連携がずさんだと、公開FAQと一緒に従業員の個人記録が表示されてしまうかもしれません

00:10:37.800 --> 00:10:41.820
ERPのアクセス権限の設定を誤れば、営業担当者が給与データを見てしまうといった事態になりかねません

00:10:41.820 --> 00:10:44.780
そうした見落としは、本番環境において致命的なミスとなります

00:10:44.780 --> 00:10:49.420
より安全な方法は、グラウンディング計画に秘密ドラベルやパービューによる分類を組み込むことです

00:10:49.420 --> 00:10:55.500
そうすれば、エージェントは権限ルールに一致するコンテンツのみを取得し、データ分類を尊重して制御できるようになります

00:10:55.500 --> 00:10:56.900
警告は単純です

00:10:56.900 --> 00:11:01.960
根拠のないエージェントはもっともらしく嘘をつき、根拠付けが不十分なエージェントは漏えいすべきでない情報をさらけ出します

00:11:01.960 --> 00:11:06.420
どちらにせよ、自社のブランド名の下で誤った情報を広めたり、機密情報を漏えいさせたりすることになります

00:11:06.420 --> 00:11:09.100
パービューのようなガバナンスツールが存在するのには理由があるのです

00:11:09.100 --> 00:11:11.960
データコネクタを利用する際は初日から分類機能を組み合わせましょう

00:11:11.960 --> 00:11:15.480
さもなければ、後で評判の低下やコンプライアンス問題の対処に追われることになります

00:11:15.480 --> 00:11:16.820
教訓は明らかです

00:11:16.820 --> 00:11:19.060
グラウンディングは高度な付加機能ではありません

00:11:19.060 --> 00:11:22.740
これは、役立つコパイロットと信頼できないおしゃべりボットを分ける基準となるものです

00:11:22.740 --> 00:11:27.220
適切に行えば、裏付けとなるログに基づいた実際のコンテンツに紐づいた事実をユーザーに提供できます

00:11:27.220 --> 00:11:31.940
適切に行わなければ、サポートチケットを開くよりも早いスピードで、ハルシネーションと情報漏洩が組織全体に広がります

00:11:31.940 --> 00:11:34.260
だからこそ、次の課題も同様に重要なのです

00:11:34.260 --> 00:11:36.720
なぜなら、グラウンディングされたエージェントが一つなら管理可能だからです

00:11:36.720 --> 00:11:39.920
監視なしで何重ものエージェントが放たれると、そこに真のトラブルが始まります

00:11:39.920 --> 00:11:43.020
ガバナンス、それはエージェントが増殖して変異するのを防ぐことです

00:11:43.020 --> 00:11:48.360
この文脈におけるガバナンスとは、コパイロットエージェントが統制不能なカオスに陥るのを防ぐルールセットのことです

00:11:48.360 --> 00:11:53.420
誰が作成できるか、どこで実行されるか、どのデータに触れられるかを、運任せにせず決定するための仕組みです

00:11:53.420 --> 00:11:56.660
マイクロソフトは、それを強制するためのツールをすでに提供しています

00:11:56.660 --> 00:12:02.800
マイクロソフト365管理センターのコパイロット制御システムパワープラットフォーム管理センターのライフサイクル管理

00:12:02.800 --> 00:12:08.160
カンドラベルとDLPのためのマイクロソフトパービュー、そして監査のためのコパイロット診断ログです

00:12:08.160 --> 00:12:12.040
これらを、カードの城が崩壊するのを防ぐ4つの柱と考えてください

00:12:12.040 --> 00:12:17.360
最初に知っておくべきこととして、コパイロットのシナリオ管理は管理者アクセス権を持つ誰でもできるわけではありません

00:12:17.360 --> 00:12:20.940
グローバル管理者やAI管理者といった特定の役割が必要です

00:12:20.940 --> 00:12:25.380
最小権限の原則を守り、本人が気づかないうちに深く切り込むような権を渡さないようにしましょう

00:12:25.380 --> 00:12:28.800
誰がスイッチを切り替えられるかを制限することも、一つのガバナンスの形です

00:12:28.800 --> 00:12:32.260
そこから先は、事後ではなく設計段階からライフサイクルルールを組み込んでください

00:12:32.260 --> 00:12:37.700
ルール1、エージェントを作成できるユーザーを定義し、それをパワープラットフォーム管理センターの環境に紐付けます

00:12:37.700 --> 00:12:44.620
ルール2、365管理センターのコパイロット設定を使用して、エージェントを公開できるユーザーを定義し、リリースの承認またはブロックを行います

00:12:44.620 --> 00:12:50.780
ルール3、エージェントを実行できる場所を定義し、分離された環境に割り当てることで、本番環境を無法地帯にしないようにします

00:12:50.780 --> 00:12:53.380
ルール4、クレジットの割り当て方法を定義します

00:12:53.380 --> 00:12:55.980
ここでコパイロットエージェント消費メーターが役立ちます

00:12:55.980 --> 00:13:00.800
そのカウンターはいつ、マナバ、消費量が急速に減っているか、誰がそれを消費しているかを明確な数値で示します

00:13:00.800 --> 00:13:06.060
パービューは、ドキュメントやメールですでに信頼されているコンプライアンスネットであり、ここでも同様に機能します

00:13:06.060 --> 00:13:11.640
データに感度ラベルを適用すれば、エージェントがソースに接続しても、そのラベルは回答まで引き継がれます

00:13:11.640 --> 00:13:16.680
DLPポリシーを使用して、エージェントが回答を通じて機密フィールドを公開しないようにブロックします

00:13:16.680 --> 00:13:22.940
保持ポリシーにより古いコンテンツが残らないようにし、数週間前に期限切れになるべきデータでエージェントがグラウンディングするのを防ぎます

00:13:22.940 --> 00:13:27.180
一度これらのガードレールを設定すれば、すべてのエージェントが自動的にその監視を引き継ぎます

00:13:27.180 --> 00:13:30.720
多くのチームが見落としがちなもう一つの動き、それは診断ログの有効化です

00:13:30.720 --> 00:13:34.360
そのスイッチを切り替えれば、すべてのやり取りを明確に可視化できるようになります

00:13:34.360 --> 00:13:39.640
プロンプと、応答、コンテンツ参照、システムログ、これらすべてが後で活用できる記録となります

00:13:39.640 --> 00:13:44.440
マネージャーから、なぜエージェントが誤った指示を出したのかと問われても、肩をすくめる代わりに履歴を再生できます

00:13:44.440 --> 00:13:49.160
さらに、エンドユーザー自身がフィードバックを送らない場合でも、管理者がユーザーに代わってログを送信できます

00:13:49.160 --> 00:13:52.060
これにより、トラブルシューティングは事後対応型ではなく、予防型になります

00:13:52.060 --> 00:13:55.220
これはイノベーションを遅らせることではなく、それを正しい方向に導くためのものです

00:13:55.220 --> 00:14:01.520
スタジオを使えばパワーユーザーは午後までにフローを簡単に作成でき、ツールキットを使えば開発者は大規模なビルドを素早く本番環境に展開できます

00:14:01.520 --> 00:14:04.980
管理体制がなければ、そのスピードは重複や矛盾を生むことになります

00:14:04.980 --> 00:14:10.040
ガバナンスがあれば、同じスピードで、コンプライアンスが守られ監視された再利用可能な資産を生み出せます

00:14:10.040 --> 00:14:14.560
違いはスタッフの創造性ではなく、それを取り巻くフレームワークの規律にあります

00:14:14.560 --> 00:14:17.260
A、コスト追跡さえもガバナンスの一部です

00:14:17.260 --> 00:14:21.360
管理センターの消費メーターは単なる会計ビューではなく、バランスを調整するためのダイヤルです

00:14:21.360 --> 00:14:26.360
クレジットパックの割り当て、重量課金モデルでの超過監視を行い、予算の枠内で利用を維持できます

00:14:26.360 --> 00:14:31.540
これを無視すると、クレジットが枯渇してエージェントがワークフローの途中で突然停止した時に初めて制限を知ることになります

00:14:31.540 --> 00:14:34.380
空っぽのタンクで本番環境のデバッグなどしたくないはずです

00:14:34.380 --> 00:14:37.060
デメ20のガバナンスは、鎧のように機能します

00:14:37.060 --> 00:14:42.220
開発者が迅速に動ける柔軟性を保ちつつ、一度の失敗でパーティ全体が全滅しないだけの保護力があります

00:14:42.220 --> 00:14:49.340
デメ1の状況では、ガバナンスを無視して承認なしにエージェントを生成させ、監査人が頭上で目を光らせる中、各部署の不具合修正に追われることになります

00:14:49.340 --> 00:14:52.760
ガバナンスはゲームを退屈にするものではなく、生き残るためのものです

00:14:52.760 --> 00:14:56.060
そして生き残ることは、ダンジョンで待ち受ける次の罠へと直結します

00:14:56.060 --> 00:15:00.400
ガバナンスを制御下においても、次の驚きは技術的なものではなく、経済的なものだからです

00:15:00.400 --> 00:15:03.800
財務チームがメーターを確認するたびに管理者が冷や汗をかくのには理由があります

00:15:03.800 --> 00:15:07.680
うまく動いているビルドも、それが生み出す請求書を見るほど台無しになるものはありません

00:15:07.680 --> 00:15:10.600
ライセンスとコスト、それは見えていないトラップカードです

00:15:10.600 --> 00:15:14.820
ライセンスとコストは、ほとんどのチームがボードに置かれるまで気づかないトラップカードです

00:15:14.820 --> 00:15:22.780
マイクロソフトは迅速な構築と華やかなデモという夢を売りますが、月半ばでクレジットが消えたり、コネクタがひっそりとライセンス要件を追加したりすれば、それも台無しです

00:15:22.780 --> 00:15:29.340
これは付随的な問題ではなく、管理すべき中心的な仕組みであり、これを怠れば人々が依存し始めた瞬間にエージェントは停止してしまいます

00:15:29.340 --> 00:15:32.020
コパイロットスタジオはコパイロットクレジットで動作します

00:15:32.020 --> 00:15:41.620
クレジットはパックで購入し、テナント全体で月額約200ドルで25,000クレジットを利用するか、組織の消費量に応じて期間終了後に請求される重量課金メーターを使用します

00:15:41.620 --> 00:15:45.680
寒大に聞こえますが、ドキュメントを読めば消費が一定ではないことは明らかです

00:15:45.680 --> 00:15:51.900
段階的な料金体系を採用しており、標準的な非生成アクションは安価ですが、生成型回答はより多くのコストを消費します

00:15:51.900 --> 00:15:57.700
正確な数値はマイクロソフトのライセンスガイドによって変動するため、課金に関するドキュメントはビルドキットの一部として扱ってください

00:15:57.700 --> 00:16:02.140
重要な点は、テスト用のプロンプトも本番環境の応答も同じリソースプールから消費されるということです

00:16:02.140 --> 00:16:04.800
システム内のどこにも無料のサンドボックスは隠されていません

00:16:04.800 --> 00:16:06.400
どれほど望んだとしてもです

00:16:06.400 --> 00:16:14.280
クレジットはテナント全体で共有されるため、人事のオンボーディングボットであれ、営業の案件支援ボットであれ、財務の報告アシスタントであれ、すべてのエージェントが同じプールを利用します

00:16:14.280 --> 00:16:20.600
この設計は柔軟性をもたらしますが、ある部門の集中的なテストによって、別のチームの本番稼働用リソースが枯渇する可能性もあります

00:16:20.600 --> 00:16:24.720
プールが空になると、コパイロットスタジオはスロットル、制限、おかけたり、優しく警告したりはしません

00:16:24.720 --> 00:16:28.100
クレジットが補充されるまで、ただ単純にそれらのエージェントを停止させます

00:16:28.100 --> 00:16:35.180
他のグループがテストループを一晩中動かしていたせいで、稼働中のサポートボットが取引の途中で沈黙した理由を説明するような事態は避けたいはずです

00:16:35.180 --> 00:16:40.980
重量課金制は、その月に実際に消費した分だけを支払えば良いため、前払いのコミットメントを避けたい場合には役立ちます

00:16:40.980 --> 00:16:43.280
しかし、そのメーターは極めて無慈悲です

00:16:43.280 --> 00:16:50.100
プロトタイプの簡単なテストでも本番ワークフローと同じようにクレジットを消費するため、予算アラートを設定していないと、簡単に予算を超過してしまいます

00:16:50.100 --> 00:16:55.440
安全なアプローチは、テストビルドであってもクレジット計画の一部として扱い、早い段階で制限を割り当てることです

00:16:55.440 --> 00:16:59.440
チームツールキットやブスコードのエージェントツールキットは、異なる視点を提供します

00:16:59.440 --> 00:17:06.020
スイートに公開した場合、作業はユーザーのマイクロソフト365個パイロットライセンスの下で実行されるため、プロンプトごとのクレジット消費は発生しません

00:17:06.020 --> 00:17:09.760
スタジオに比べれば自由に見えますが、それは基本的な機能のみをカバーするものです

00:17:09.760 --> 00:17:14.480
カスタムエンジンエージェントを構築したり、外部サービスと連携したりした瞬間から、コストが積み重なり始めます

00:17:14.480 --> 00:17:21.460
APIには独自の測定基準があり、エンタープライズコネクタにはベッドライセンスが必要なことが多く、管理者の同意によって予算外のティアへ移行することもあります

00:17:21.460 --> 00:17:25.140
スタジオはアクションごとに課金しますが、ツールキットはクレジットモデルを回避させてくれます

00:17:25.140 --> 00:17:27.360
しかし、どちらも何らかの形で支出が発生します

00:17:27.360 --> 00:17:29.660
これは無料の抜け道ではなく、トレードオフと呼ぶべきものです

00:17:29.660 --> 00:17:35.160
実用上のルールとして、チームズツールキットはコストを統合やサービスレイヤーに隠しますが、スタジオはクレジットという形で前払いさせるという違いがあります

00:17:35.160 --> 00:17:37.000
どちらが常に安いとは限りません

00:17:37.000 --> 00:17:41.640
道を選ぶ前に、想定されるワークフローを文書化された価格体系に照らし合わせて検討する必要があります

00:17:41.640 --> 00:17:46.720
シェアポイントに基づいた軽量な承認ボットであれば、スタジオでクレジットを低コストで消費しながら運用するのが適しているでしょう

00:17:46.720 --> 00:17:54.200
外部CRMとの大規模な統合であれば、コパイロットのクレジットを消費する代わりにCRMのAPI料金を支払うことにはなりますが、ツールキットの方が理にかなっている可能性があります

00:17:54.200 --> 00:17:57.920
重要なのは、完全にコストを回避することではなく、どこにコストが発生するかを把握することです

00:17:57.920 --> 00:18:00.980
では、こうした落とし穴によって計画が台無しになるのをどう防げば良いのでしょうか

00:18:00.980 --> 00:18:05.820
まずは、コパイロットエージェントの消費メーターや重量課金レポートを使用して、テナントレベルの利用監視を有効にしてください

00:18:05.820 --> 00:18:11.100
次に、予算がゼロになる前に財務部門やIT部門へ通知が届くよう、アラートの指揮位置を設定します

00:18:11.100 --> 00:18:18.060
3つ目は、特定のチームが予算を使い切らないよう、指定のクレジットパックや明確な社内規定を用いて、部署ごとに予算を割り当ててください

00:18:18.060 --> 00:18:21.160
これら3つの管理策が、予期せぬ事態のほとんどを防いでくれます

00:18:21.160 --> 00:18:23.620
開発規模が広がると、さらなる複雑さが加わります

00:18:23.620 --> 00:18:28.940
統合には明示的な管理者の承認が必要なことが多く、承認の度にデフォルトで新たなコストが発生する可能性があります

00:18:28.940 --> 00:18:33.360
テスト中に利用した外部APIは、マイクロソフトではなく記者に請求されます

00:18:33.360 --> 00:18:38.880
設計段階でライセンスとコネクタをリスト化し、展開前に誰が何に対して支払うかを確認するのが賢明です

00:18:38.880 --> 00:18:42.000
機能だけでなく、コストの変更管理として扱う必要があります

00:18:42.000 --> 00:18:44.860
ライセンスは細かい規定ではなく、アーキテクチャの一部なのです

00:18:44.860 --> 00:18:48.780
クレジットは無計画にではなく、0度攻略のトークンのように慎重に消費してください

00:18:48.780 --> 00:18:55.000
最初に適切なライセンスを装備し、消費量を監視し、新しいコネクタを追加するたびに統合コストが発生することを予期しておきましょう

00:18:55.000 --> 00:19:00.900
ユーザーがエージェントを頼りにする状況を作るなら、どれも不可欠な手順であり、いよいよ最終段階へと進みます

00:19:00.900 --> 00:19:07.900
エージェントの構築、グラウンディング、ガバナンス、資金確保は重要な通過点ですが、真の成果は本番導入ではなく、長期的な運用にあります

00:19:07.900 --> 00:19:10.540
最後に、この視点が何よりも重要になります

00:19:10.540 --> 00:19:12.320
それでは、結論を述べましょう

00:19:12.320 --> 00:19:16.540
成功とは華やかなデモではなく、エージェントが暴走せず有用であり続けるためのルールを守ることです

00:19:16.540 --> 00:19:18.800
まずは、構築パスを慎重に選択してください

00:19:18.800 --> 00:19:22.880
ローコードで素早く開発するならコパイロットスタジオ、フルカスタムのエンジンとより詳細な制御ならチームツールキットです

00:19:22.880 --> 00:19:25.360
次に、開始時点からガバナンスを確実に適用してください

00:19:25.360 --> 00:19:29.820
パービューラベル、管理者ロール、診断ログ、利用状況の監視をすべて公開前に有効にします

00:19:29.820 --> 00:19:31.900
3つ目は、支出計画の策定です

00:19:31.900 --> 00:19:37.160
スタジオはテナント全体のクレジットパックや重量課金を消費し、ツールキットはコストを外部APIやサービスへと移行させます

00:19:37.160 --> 00:19:37.900
以上です

00:19:37.900 --> 00:19:40.640
チャンネル登録と通知設定、そしてコメントをお待ちしています

00:19:40.640 --> 00:19:43.380
次のクエストに向けて、スタジオとツールキットのどちらを選択しますか?