Latest / M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語） / Copilot Studio と Teams Toolkit、Copilot エージェントにはどちらを選ぶべき？（AI吹き替え）

Transcript

Copilot Studio と Teams Toolkit、Copilot エージェントにはどちらを選ぶべき？（AI吹き替え） · M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語）

0:00
マイクロソフト365コパイロットの導入は伝説のアイテムを手に入れたような気分にさせてくれますが実際はスターターキットに過ぎないことに気づくはずです
0:06
標準の状態ではモデルが持つ基本知識とテナント内のコンテンツを利用するだけです
0:10
便利ではありますが誇りをかぶったソップ標準作業手順書や人事のガイドラインあるいは隅に潜む巨大なERPシステムはどうでしょうか
0:16
コネクタやグラウンディングカスタムエージェントがなければコパイロットはそれらにアクセスできません
0:19
良いニュースはあなたが教え込めるということです
0:22
肝心なのはいつコパイロットスタジオを使いいつチームツールキットに切り替えガバナンスや監視ライセンスをどう運用に組み込むかを知ることです
0:27
なぜならここからが本当の展開だからです
0:29
最初のエージェントを作成することがラスボス戦ではありません
0:32
それは単なるチュートリアルの終了に過ぎません
0:34
ビルドはボス戦ではないのです
0:35
最初のエージェントをテストしプロンプトが機能しデモデータが完璧に見えると一瞬ゲームをクリアしたような気分になります
0:40
それが罠です
0:41
本当の仕事はそのビルドを本番環境に向けた時に始まります
0:44
そこでは環境が全く異なるルールで動いているからです
0:46
多くの開発者がテストで良い回答が得られたらミッション完了だと勘違いしています
0:50
実際にはそれはイージーモードのストーリーに過ぎません
0:52
本番環境は開発用ノートPCで概念実証ポックがうまくいったかどうかなど気にしません
0:57
本番環境が求めるのはストレス下での安定性でありコンプライアンスチェックIDガードレールそして厳格な稼働率基準です
1:04
そしてここで最初のボスモンスターが登場します
1:07
スケーラビリティ
1:08
エージェントはエンタープライズレベルの負荷に耐えられるでしょうか
1:10
そこでコパイロット制御システムからの監視ログと診断ログが重要になります
1:14
グラウンディングの陳腐化
1:16
シェアポイントやデータバースのデータが変更されたときエージェントは正しく最新データに接続し続けられるでしょうか
1:20
コネクタとグラフグラウンディングがその防波堤となります
1:23
コンプライアンスと監査可能性
1:25
規制当局や内部監査人から指摘を受けた際
1:27
エージェントの履歴は完璧なログと秘密ドラベルによってレビュー可能でしょうか
1:31
これらが一つでも欠ければ勝利の画面はすぐに消え去ります
1:35
コパイロットスタジオでのテストは無制限の回復ポーションがあるトレーニング上でのスパーリングのようなものです
1:40
呪文を唱えプロンプトを試せば全てが輝いて見えますが
1:44
実運用ではファイアウォールによる遮断は不発となり
1:47
過不可な外部データソースは応答を極端に遅くします
1:50
その瞬間ユーザーはそれを賢いとは呼ばずサポートチケットを発行し始めるのです
1:54
ガバナンスを後回しにするチームで最もよくある停滞失敗が起こります
1:58
彼らは後で追加すればいいと言い聞かせますが
2:00
ガバナンスを先延ばしにするとほぼ確実に悪い驚きが待っています
2:03
スケーリングの問題やデータの不一致
2:05
コンプライアンスの欠如がまさに最悪のタイミングで露呈するのです
2:08
セキュリティとコンプライアンスはオプションのサイドクエストではありません
2:10
それらはキャンペーンマップの一部なのです
2:12
ではアーキテクチャについて話しましょう
2:14
コパイロットの脳は単一のブロックではないからです
2:16
基盤モデルという正の言語エンジンがあり
2:18
その上にオーケストレーターがいて
2:20
どの機能をいつ呼び出すかを調整します
2:22
マイクロソフト365個パイロットはデフォルトで
2:24
そのオーケストレーションを提供するため
2:25
すべてのリクエストに構造が与えられます
2:27
次にグラウンディングです
2:28
これはエンタープライズコンテンツへのつなぎ止めであり
2:30
答えが捏造されないようにします
2:32
最後はスキルです
2:33
実際のタスクを実行するためのカスタムプラグインやコネクタのことです
2:36
これら4つの要素を切り離されたサイロとして扱うと
2:46
一つのスタックとして扱うとき始めて
2:48
エージェントは頑丈さを保てます
2:49
では実際の現場における成功とはどのようなものでしょうか
2:52
デモのプロンプトにうまく答えることではありません
2:54
それは練習モードにすぎません
2:55
成功の証は給与計算の繁忙期やデータ移行の真っ只中
2:58
コンプライアンス担当者の監視家
3:00
そして高負荷なリクエスト環境といった現実世界で持ちこたえることです
3:02
そこでこそエージェントは実行に値することを証明します
3:05
多くの構築が失敗する理由は他にもあります
3:07
組織がそれを運用システムではなく
3:09
使い捨てのプロジェクトと考えていることです
3:11
誰かがプロトタイプを立ち上げ派手なデモを見せた後
3:13
監視もせずに放置してしまいます
3:15
すぐに各部署が独自のエージェントを作り始め
3:17
ドキュメントもなくチェックされないままトークンを消費し続けます
3:19
単純な運用マニュアルがなければ
3:21
誰がコネクタを管理し
3:22
誰がグラウンディングを監査し
3:23
誰がクレジット消費を確認するのか
3:25
現場は同期されないミニボスだらけの混沌とかします
3:28
視点を変えればずっと簡単になります
3:30
運用マインドセットから始めれば設計は変わります
3:33
最初のテストがうまくいったかどうかだけを気にするのではありません
3:35
日々の業務に向けて堅牢化するのです
3:37
監査ログ、管理者によるゲート、バックアップ、ヘルスチェック
3:40
これらが信頼を築き
3:41
プレッシャーのかかる状況下でシステムを維持します
3:43
管理者にはマイクロソフト365管理センター内に利用可能なコントロールがすでにあり
3:47
そこではシナリオを管理し
3:48
診断フィードバックを早期に得ることができます
3:50
それらのツールを活用することこそが
3:51
珍しいだけのエージェントと信頼できる運用ツールを分かつ境界線です
3:54
だからこそ作るだけでは勝者にはなれません
3:56
テスト環境は最初のステップに過ぎません
3:58
ガバナンスと監視体制を整えた実際のデプロイこそが
4:01
本当の生存競争の始まりです
4:03
そして深く踏み込む前に
4:05
戦いのための適切な武器が必要になります
4:07
マイクロソフトは2つの異なるキットを用意しており
4:09
それぞれルールが異なります
4:10
選択を誤ればプラスチックの剣でレードに挑むようなことになります
4:14
コパイロットスタジオかチームツールキットか
4:16
武器を選ぶのです
4:17
そこにこそ真の問いが生まれます
4:19
あなたはどちらのツールを手に取りますか
4:21
コパイロットスタジオでしょうか
4:22
それともマイクロソフト365エージェントツールキットとも呼ばれるチームツールキットでしょうか
4:25
どちらもコパイロットを拡張すると歌っており
4:27
似たものに聞こえますが
4:28
対象とする構築者やニーズは大きく異なります
4:30
選択を誤れば時間と予算を浪費し
4:32
本番環境で華やかなデモが機能しなければ信頼を失うことにもなりかねません
4:34
コパイロットスタジオは作り手のための舞台です
4:37
これはスピードと明快さを追求したローコードのビジュアルビルダーです
4:40
ドラッグ&ドロップによるフロー作成
4:41
テンプレートガイド付き対話
4:43
そして組み込みの分析機能が利用できます
4:44
スタジオにはマイクロソフト365データソースへの接続が豊富に用意されており
4:48
パワーユーザーならコードを一切書かずに
4:50
シェアポイントコンテンツの抽出やチームメッセージの監視
4:53
人事規定ドキュメントの参照などが可能です
4:55
テスト調整を経てマイクロソフト365個パイロットへ直接公開できるほか
4:59
最小限の手間でスタンドアロンのエージェントとしてリリースすることもできます
5:03
来期ではなく今市販機中に機能するワークフローが必要な部署にとって
5:07
スタジオは最短ルートです
5:08
すでに16万社以上の顧客が財務データの称号
5:11
従業員のオンボーディング
5:13
小売店での製品に関する問い合わせ対応など
5:15
まさにこの用途でスタジオを活用しています
5:17
その理由は明白で単に導入のハードルが低いからです
5:20
チームがすでにパワーアップスを触ったり
5:21
パワーオートメートで提携レポートを自動化したりしているなら
5:23
スタジオは慣れ親しんだ環境のように感じられるでしょう
5:26
ソフトウェアエンジニアである必要はありません
5:28
明確な目標と基本的なローコードのスキルさえあれば
5:30
クリック設定デプロイが可能です
5:32
次にチームツールキットに目を向けましょう
5:34
ここはフルスタック開発者が活躍する領域です
5:36
ツールキットはブスコードに組み込まれるもので
5:38
ドラッグ&ドロップのキャンバスではありません
5:40
ここでは構造化されたルールを持つ宣言型エージェントを設計したり
5:43
さらに踏み込んでオーケストレーションモデルの呼び出しや
5:45
API処理をゼロから定義するカスタムエンジンエージェントを作成したりできます
5:48
コパイロット内だけでなくチームやマイクロソフト365アプリ
5:52
ウェブ外部チャンネル全体にわたって
5:53
スキャホールディングデバッグ構成公開のルートが手に入ります
5:57
コパイロットスタジオがカタログから選ぶ組み立て家具なら
5:59
ツールキットは木材を削り出し家を自ら配線するようなものです
6:02
その自由度は素晴らしいものですが
6:10
実際にはスタジオでの拡張はマイクロソフトが定めたガードレール
6:13
安全なコネクタ管理制御そして軽量なガバナンスの範囲内で行うことを意味します
6:17
一方でツールキットはガードレールの書き換え
6:19
独自のオーケストレーションの構築外部LLMの呼び出し
6:22
マイクロソフトが標準提供していないエージェント動作の実装を意味します
6:25
一方はテンプレートで安全を確保し
6:27
もう一方は性のパワーを提供してそれを責任を持って使いこなすことを期待します
6:30
多くの人はツールを選択すればUIも変わると思っています
6:33
いいえ違います
6:34
スタジオで構築したかツールキットで構築したかに関わらず
6:36
エンドユーザーが見るプロンプトボックスや回答カードは同じです
6:38
それは設計によるものでUX層は統一されています
6:41
実際に変わるのは舞台裏の部分です
6:43
グラウンディングの選択肢スケーラビリティそして管理制御です
6:46
だからこそこの決定は単なる見かけではなく運用の問題なのです
6:49
ここに実践的なルールがあります
6:51
シェアポイントのコンテンツチームのチャットや会議
6:53
埋め込まれたファイルデータバースのデータ
6:55
あるいはメールや人検索へのコネクタといったグラウンディング機能の一部は
6:58
テナントでマイクロソフト365コパイロットのライセンス
7:00
またはコパイロットスタジオの重量課金が有効になっている場合にのみ利用可能です
7:04
その権利がない場合スタジオを選択してもそれらの機能は開放されません
7:07
そのライセンスの確認一つがどちらの道を選ぶべきかの決定だとなり得ます
7:11
ではどのように選択を簡略化すれば良いのでしょうか
7:13
簡単なチェックリストを作成しましょう
7:15
1つ目IT部門を煩わせることなくパワーユーザーが構築できる
7:18
迅速で監査可能かつ管理者が制御可能なエージェントが必要ですか
7:20
それならコパイロットスタジオを選びましょう
7:22
2つ目カスタムオーケストレーションや外部AIモデル
7:24
あるいは企業の機関システムに直接組み込むような深い統合が必要ですか
7:26
それならエージェントツールキットを選びましょう
7:28
3つ目ラベルを信じるのではなくチームの実際のスキルセットと目標を信じてください
7:31
私がよく使う例えは住宅です
7:33
スタジオはプレハブ住宅です
7:35
色やキャビネットは選べますが配管や配線はすでに安全な状態です
7:38
ツールキットはさらちです
7:39
すべてを設計できますが設計が崩れた場合のリスクもすべて背負うことになります
7:43
どちらでも素晴らしい家を建てることができます
7:44
一方はより迅速で複雑さが少なくもう一方は制限がありませんが
7:47
うまく管理しなければ壊れやすいのです
7:48
どちらもグラウンディングなしでは崩壊します
7:50
選んだツールが構築を担うとはいえ正しいデータが与えられなければ
7:53
自信に満ちたデタラメを高速で生成するだけです
7:55
コネクタのないスタジオエージェントはただのオウムです
7:57
グラウンディングのないツールキットエージェントは
7:58
カスタムコードで書かれたオウムにすぎません
8:00
どちらにしてもユーザーに向かって推測をさえずる鳥を飼っているようなものです
8:03
そしてそれがあらゆるエージェントの生命線であるデータ接続につながります
8:07
これはエージェントの頭脳が不完全な情報で占い師のような振る舞いをすることを防ぐものです
8:10
エージェントをグラウンディングさせること
8:12
それは虚無ではなく脳に栄養を与えることです
8:14
グラウンディングによってエージェントは知ったかぶりをやめ
8:16
真の知識に基づいて動き始めます
8:18
適切なソースを与えればハッタリから根拠のある回答を提供できるようへと変わります
8:22
これを怠れば表面上は洗練されて見えてもその回答の根拠は
8:26
と誰かに聞かれた瞬間に崩れ去ってしまいます
8:28
マイクロソフト365個パイロットはすでにマイクロソフトグラフを通じて見えるデータに依存しています
8:32
ファイル、チャット、会議、そして予定表のイベントまで
8:35
それは良いスタートですが最も価値のあるコンテンツはその中心の外側にあります
8:39
ERPには在庫がありCRMは顧客ライフサイクルを管理し
8:43
人事部はシェアポイントの奥深くにプレイブックを保管し
8:46
ポリシー文書はホームの厳重なホルダーにあります
8:48
エージェントをそれらのソースにグラウンディングさせなければ
8:50
検証可能なものを指し示す代わりに
8:52
一般的なモデルの知識を使って自信たっぷりに推測するでしょう
8:55
それらを接続することは単なるドラッグ&ドロップではなく
8:57
繊細な配管作業なのです
8:59
コパイロットスタジオとマイクロソフトグラフコネクタを使えば
9:01
シェアポイントの保存済みドキュメント
9:03
データバースの構造化テーブル
9:05
エクスチェンジのメール記録
9:06
チームのチャット内容にアクセスできます
9:08
マイクロソフトの中核機能だけでなく
9:10
パワープラットフォームを介した1200以上のコネクタで
9:12
外部システムとの連携も可能です
9:14
財務、人事、チケット管理などあらゆる分野が対象です
9:17
既存のコネクタが使えない場合でも
9:18
APIを利用すれば
9:19
標準コネクタでカバーされていない業務アプリを組み込むことができます
9:22
正しく構築されたエージェントは
9:23
これらの保存先から最新の事実を取得し
9:25
文脈に沿って提示します
9:26
魔法のように見えるかもしれませんが
9:27
実は適切に整備されたパイプラインのおかげです
9:29
ただし注意点があります
9:30
これらのグラウンディング、根拠付け、オプションは
9:32
全て無料で使えるわけではありません
9:33
シェアポイントのコンテンツ、チームの会議録、メール、データバースなどのソースへのアクセスには
9:37
多くの場合、テナントでコパイロットのライセンスや課金設定が有効である必要があります
9:40
その権限がなければコネクタは機能せず
9:42
AIアシスタントは最も重要なデータの一部を参照できなくなります
9:46
単にスイッチをオンにするだけで全てが解決するとは思わないでください
9:48
まずはライセンスの構成を確認しましょう
9:50
人事ヘルプデスクの例を考えてみましょう
9:52
誰かが育児休暇のポリシーは何ですか?
9:54
と尋ねます
9:55
グラウンディングがない場合、エージェントはモデルが持つ一般的な知識から
9:58
最もらしい回答を組み立てます
10:07
このわずかな違いが、未検証の発言を監査担当者や人事が承認できる信頼性の高い回答に変えます
10:13
その監査証跡こそが真の強化ポイントです
10:15
根拠付けされた回答にはユーザーや規制当局を元のソースへ導く引用を添えることができます
10:19
コンプライアンス部門からボットの回答理由を問われても長々と説明する必要はありません
10:23
ログを見れば一目瞭然です
10:25
これがプロンプトです
10:26
これが参照したドキュメントです
10:27
そしてこれが生成された回答です
10:29
幸運を祈る必要はありませんが、すべての接続は同時にリスクポイントでもあります
10:32
人事データとの連携がずさんだと、公開FAQと一緒に従業員の個人記録が表示されてしまうかもしれません
10:37
ERPのアクセス権限の設定を誤れば、営業担当者が給与データを見てしまうといった事態になりかねません
10:41
そうした見落としは、本番環境において致命的なミスとなります
10:44
より安全な方法は、グラウンディング計画に秘密ドラベルやパービューによる分類を組み込むことです
10:49
そうすれば、エージェントは権限ルールに一致するコンテンツのみを取得し、データ分類を尊重して制御できるようになります
10:55
警告は単純です
10:56
根拠のないエージェントはもっともらしく嘘をつき、根拠付けが不十分なエージェントは漏えいすべきでない情報をさらけ出します
11:01
どちらにせよ、自社のブランド名の下で誤った情報を広めたり、機密情報を漏えいさせたりすることになります
11:06
パービューのようなガバナンスツールが存在するのには理由があるのです
11:09
データコネクタを利用する際は初日から分類機能を組み合わせましょう
11:11
さもなければ、後で評判の低下やコンプライアンス問題の対処に追われることになります
11:15
教訓は明らかです
11:16
グラウンディングは高度な付加機能ではありません
11:19
これは、役立つコパイロットと信頼できないおしゃべりボットを分ける基準となるものです
11:22
適切に行えば、裏付けとなるログに基づいた実際のコンテンツに紐づいた事実をユーザーに提供できます
11:27
適切に行わなければ、サポートチケットを開くよりも早いスピードで、ハルシネーションと情報漏洩が組織全体に広がります
11:31
だからこそ、次の課題も同様に重要なのです
11:34
なぜなら、グラウンディングされたエージェントが一つなら管理可能だからです
11:36
監視なしで何重ものエージェントが放たれると、そこに真のトラブルが始まります
11:39
ガバナンス、それはエージェントが増殖して変異するのを防ぐことです
11:43
この文脈におけるガバナンスとは、コパイロットエージェントが統制不能なカオスに陥るのを防ぐルールセットのことです
11:48
誰が作成できるか、どこで実行されるか、どのデータに触れられるかを、運任せにせず決定するための仕組みです
11:53
マイクロソフトは、それを強制するためのツールをすでに提供しています
11:56
マイクロソフト365管理センターのコパイロット制御システムパワープラットフォーム管理センターのライフサイクル管理
12:02
カンドラベルとDLPのためのマイクロソフトパービュー、そして監査のためのコパイロット診断ログです
12:08
これらを、カードの城が崩壊するのを防ぐ4つの柱と考えてください
12:12
最初に知っておくべきこととして、コパイロットのシナリオ管理は管理者アクセス権を持つ誰でもできるわけではありません
12:17
グローバル管理者やAI管理者といった特定の役割が必要です
12:20
最小権限の原則を守り、本人が気づかないうちに深く切り込むような権を渡さないようにしましょう
12:25
誰がスイッチを切り替えられるかを制限することも、一つのガバナンスの形です
12:28
そこから先は、事後ではなく設計段階からライフサイクルルールを組み込んでください
12:32
ルール1、エージェントを作成できるユーザーを定義し、それをパワープラットフォーム管理センターの環境に紐付けます
12:37
ルール2、365管理センターのコパイロット設定を使用して、エージェントを公開できるユーザーを定義し、リリースの承認またはブロックを行います
12:44
ルール3、エージェントを実行できる場所を定義し、分離された環境に割り当てることで、本番環境を無法地帯にしないようにします
12:50
ルール4、クレジットの割り当て方法を定義します
12:53
ここでコパイロットエージェント消費メーターが役立ちます
12:55
そのカウンターはいつ、マナバ、消費量が急速に減っているか、誰がそれを消費しているかを明確な数値で示します
13:00
パービューは、ドキュメントやメールですでに信頼されているコンプライアンスネットであり、ここでも同様に機能します
13:06
データに感度ラベルを適用すれば、エージェントがソースに接続しても、そのラベルは回答まで引き継がれます
13:11
DLPポリシーを使用して、エージェントが回答を通じて機密フィールドを公開しないようにブロックします
13:16
保持ポリシーにより古いコンテンツが残らないようにし、数週間前に期限切れになるべきデータでエージェントがグラウンディングするのを防ぎます
13:22
一度これらのガードレールを設定すれば、すべてのエージェントが自動的にその監視を引き継ぎます
13:27
多くのチームが見落としがちなもう一つの動き、それは診断ログの有効化です
13:30
そのスイッチを切り替えれば、すべてのやり取りを明確に可視化できるようになります
13:34
プロンプと、応答、コンテンツ参照、システムログ、これらすべてが後で活用できる記録となります
13:39
マネージャーから、なぜエージェントが誤った指示を出したのかと問われても、肩をすくめる代わりに履歴を再生できます
13:44
さらに、エンドユーザー自身がフィードバックを送らない場合でも、管理者がユーザーに代わってログを送信できます
13:49
これにより、トラブルシューティングは事後対応型ではなく、予防型になります
13:52
これはイノベーションを遅らせることではなく、それを正しい方向に導くためのものです
13:55
スタジオを使えばパワーユーザーは午後までにフローを簡単に作成でき、ツールキットを使えば開発者は大規模なビルドを素早く本番環境に展開できます
14:01
管理体制がなければ、そのスピードは重複や矛盾を生むことになります
14:04
ガバナンスがあれば、同じスピードで、コンプライアンスが守られ監視された再利用可能な資産を生み出せます
14:10
違いはスタッフの創造性ではなく、それを取り巻くフレームワークの規律にあります
14:14
A、コスト追跡さえもガバナンスの一部です
14:17
管理センターの消費メーターは単なる会計ビューではなく、バランスを調整するためのダイヤルです
14:21
クレジットパックの割り当て、重量課金モデルでの超過監視を行い、予算の枠内で利用を維持できます
14:26
これを無視すると、クレジットが枯渇してエージェントがワークフローの途中で突然停止した時に初めて制限を知ることになります
14:31
空っぽのタンクで本番環境のデバッグなどしたくないはずです
14:34
デメ20のガバナンスは、鎧のように機能します
14:37
開発者が迅速に動ける柔軟性を保ちつつ、一度の失敗でパーティ全体が全滅しないだけの保護力があります
14:42
デメ1の状況では、ガバナンスを無視して承認なしにエージェントを生成させ、監査人が頭上で目を光らせる中、各部署の不具合修正に追われることになります
14:49
ガバナンスはゲームを退屈にするものではなく、生き残るためのものです
14:52
そして生き残ることは、ダンジョンで待ち受ける次の罠へと直結します
14:56
ガバナンスを制御下においても、次の驚きは技術的なものではなく、経済的なものだからです
15:00
財務チームがメーターを確認するたびに管理者が冷や汗をかくのには理由があります
15:03
うまく動いているビルドも、それが生み出す請求書を見るほど台無しになるものはありません
15:07
ライセンスとコスト、それは見えていないトラップカードです
15:10
ライセンスとコストは、ほとんどのチームがボードに置かれるまで気づかないトラップカードです
15:14
マイクロソフトは迅速な構築と華やかなデモという夢を売りますが、月半ばでクレジットが消えたり、コネクタがひっそりとライセンス要件を追加したりすれば、それも台無しです
15:22
これは付随的な問題ではなく、管理すべき中心的な仕組みであり、これを怠れば人々が依存し始めた瞬間にエージェントは停止してしまいます
15:29
コパイロットスタジオはコパイロットクレジットで動作します
15:32
クレジットはパックで購入し、テナント全体で月額約200ドルで25,000クレジットを利用するか、組織の消費量に応じて期間終了後に請求される重量課金メーターを使用します
15:41
寒大に聞こえますが、ドキュメントを読めば消費が一定ではないことは明らかです
15:45
段階的な料金体系を採用しており、標準的な非生成アクションは安価ですが、生成型回答はより多くのコストを消費します
15:51
正確な数値はマイクロソフトのライセンスガイドによって変動するため、課金に関するドキュメントはビルドキットの一部として扱ってください
15:57
重要な点は、テスト用のプロンプトも本番環境の応答も同じリソースプールから消費されるということです
16:02
システム内のどこにも無料のサンドボックスは隠されていません
16:04
どれほど望んだとしてもです
16:06
クレジットはテナント全体で共有されるため、人事のオンボーディングボットであれ、営業の案件支援ボットであれ、財務の報告アシスタントであれ、すべてのエージェントが同じプールを利用します
16:14
この設計は柔軟性をもたらしますが、ある部門の集中的なテストによって、別のチームの本番稼働用リソースが枯渇する可能性もあります
16:20
プールが空になると、コパイロットスタジオはスロットル、制限、おかけたり、優しく警告したりはしません
16:24
クレジットが補充されるまで、ただ単純にそれらのエージェントを停止させます
16:28
他のグループがテストループを一晩中動かしていたせいで、稼働中のサポートボットが取引の途中で沈黙した理由を説明するような事態は避けたいはずです
16:35
重量課金制は、その月に実際に消費した分だけを支払えば良いため、前払いのコミットメントを避けたい場合には役立ちます
16:40
しかし、そのメーターは極めて無慈悲です
16:43
プロトタイプの簡単なテストでも本番ワークフローと同じようにクレジットを消費するため、予算アラートを設定していないと、簡単に予算を超過してしまいます
16:50
安全なアプローチは、テストビルドであってもクレジット計画の一部として扱い、早い段階で制限を割り当てることです
16:55
チームツールキットやブスコードのエージェントツールキットは、異なる視点を提供します
16:59
スイートに公開した場合、作業はユーザーのマイクロソフト365個パイロットライセンスの下で実行されるため、プロンプトごとのクレジット消費は発生しません
17:06
スタジオに比べれば自由に見えますが、それは基本的な機能のみをカバーするものです
17:09
カスタムエンジンエージェントを構築したり、外部サービスと連携したりした瞬間から、コストが積み重なり始めます
17:14
APIには独自の測定基準があり、エンタープライズコネクタにはベッドライセンスが必要なことが多く、管理者の同意によって予算外のティアへ移行することもあります
17:21
スタジオはアクションごとに課金しますが、ツールキットはクレジットモデルを回避させてくれます
17:25
しかし、どちらも何らかの形で支出が発生します
17:27
これは無料の抜け道ではなく、トレードオフと呼ぶべきものです
17:29
実用上のルールとして、チームズツールキットはコストを統合やサービスレイヤーに隠しますが、スタジオはクレジットという形で前払いさせるという違いがあります
17:35
どちらが常に安いとは限りません
17:37
道を選ぶ前に、想定されるワークフローを文書化された価格体系に照らし合わせて検討する必要があります
17:41
シェアポイントに基づいた軽量な承認ボットであれば、スタジオでクレジットを低コストで消費しながら運用するのが適しているでしょう
17:46
外部CRMとの大規模な統合であれば、コパイロットのクレジットを消費する代わりにCRMのAPI料金を支払うことにはなりますが、ツールキットの方が理にかなっている可能性があります
17:54
重要なのは、完全にコストを回避することではなく、どこにコストが発生するかを把握することです
17:57
では、こうした落とし穴によって計画が台無しになるのをどう防げば良いのでしょうか
18:00
まずは、コパイロットエージェントの消費メーターや重量課金レポートを使用して、テナントレベルの利用監視を有効にしてください
18:05
次に、予算がゼロになる前に財務部門やIT部門へ通知が届くよう、アラートの指揮位置を設定します
18:11
3つ目は、特定のチームが予算を使い切らないよう、指定のクレジットパックや明確な社内規定を用いて、部署ごとに予算を割り当ててください
18:18
これら3つの管理策が、予期せぬ事態のほとんどを防いでくれます
18:21
開発規模が広がると、さらなる複雑さが加わります
18:23
統合には明示的な管理者の承認が必要なことが多く、承認の度にデフォルトで新たなコストが発生する可能性があります
18:28
テスト中に利用した外部APIは、マイクロソフトではなく記者に請求されます
18:33
設計段階でライセンスとコネクタをリスト化し、展開前に誰が何に対して支払うかを確認するのが賢明です
18:38
機能だけでなく、コストの変更管理として扱う必要があります
18:42
ライセンスは細かい規定ではなく、アーキテクチャの一部なのです
18:44
クレジットは無計画にではなく、0度攻略のトークンのように慎重に消費してください
18:48
最初に適切なライセンスを装備し、消費量を監視し、新しいコネクタを追加するたびに統合コストが発生することを予期しておきましょう
18:55
ユーザーがエージェントを頼りにする状況を作るなら、どれも不可欠な手順であり、いよいよ最終段階へと進みます
19:00
エージェントの構築、グラウンディング、ガバナンス、資金確保は重要な通過点ですが、真の成果は本番導入ではなく、長期的な運用にあります
19:07
最後に、この視点が何よりも重要になります
19:10
それでは、結論を述べましょう
19:12
成功とは華やかなデモではなく、エージェントが暴走せず有用であり続けるためのルールを守ることです
19:16
まずは、構築パスを慎重に選択してください
19:18
ローコードで素早く開発するならコパイロットスタジオ、フルカスタムのエンジンとより詳細な制御ならチームツールキットです
19:22
次に、開始時点からガバナンスを確実に適用してください
19:25
パービューラベル、管理者ロール、診断ログ、利用状況の監視をすべて公開前に有効にします
19:29
3つ目は、支出計画の策定です
19:31
スタジオはテナント全体のクレジットパックや重量課金を消費し、ツールキットはコストを外部APIやサービスへと移行させます
19:37
以上です
19:37
チャンネル登録と通知設定、そしてコメントをお待ちしています
19:40
次のクエストに向けて、スタジオとツールキットのどちらを選択しますか?