Latest / M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語） / Copilot Studioエージェント構築：グラウンディング、ペルソナ、デバッグ、公開で初心者のミスを防ぐ方法（AI吹き替え）

Transcript

Copilot Studioエージェント構築：グラウンディング、ペルソナ、デバッグ、公開で初心者のミスを防ぐ方法（AI吹き替え） · M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語）

0:00
COパイロットスタジオで初めてエージェントを公開したとしましょうところが周囲を驚かせるどころかポリシーには
0:05
多分それがボット構築の自然な姿だと書いてある気がしますなどと頼りない回答をしてしまうのです
0:09
しかしいくつかの修正を加え実際のポリシー文書に基づいた明確な指示を与えることでその失敗を正確な根拠を引用する完璧な回答へと変えることができます
0:16
この動画を見終わる頃にはテストペインで悪い回答を再現する方法ボットが実際の文書を引用するように修正する方法
0:21
そして機能するパイロットを公開する方法がわかるはずです本題の前にチャンネル登録をお願いします
0:25
そうすればこれらのチュートリアルが自動的にプレイリストに追加されますもちろんテストウィンドウでうまくいくのは簡単なことです
0:31
本当の苦労はボットが道場を離れ現実世界でつまずいた時に始まりますなぜ完璧だったはずのテスト用ボットが現実世界で崩壊してしまうのか
0:38
テストペインでは完璧に見えたボットがなぜ実際のユーザーに対応した途端に混乱し始めるのでしょうか
0:42
手短に言えばスタジオは状況を整理し丁寧に対応しますが現実世界にはそのような配慮が存在しないからですスタジオでは入力されるデータは整理されています
0:50
質問は短く綺麗に構成されており通常は準備したトレーニング例と一致しますだからこそ完璧な結果が続いているように感じるのです
0:56
しかし本番環境に移ると人々は人間らしく入力してきます上級社員ならホテル滞在時の請求額はいくらまでと尋ねるかもしれません
1:02
担当者ならホテル経費制限と5時混じりで入力するかもしれませんまた別の人は出張費について教えてとだけ言うかもしれません
1:08
これらはすべて同じ意味ですが経費制限はいくらですかというテストしかしていない場合ボットは常にそれらを結びつけられるとは限りません
1:15
このギャップを確認する方法を今すぐ教えしましょうテストペインを開き3つの異なるパターンの質問をボットに投げかけてみてください
1:20
まず綺麗な質問文次にカジュアルな書き換えそして5時のあるパターンです回答が変化する様子を観察してください
1:25
すべてうまくいくこともあれば綺麗な質問にしか正しく回答できないこともありますそれが美しいテスト結果が現実世界での成功を保証するわけではないという最初の兆候です
1:32
技術的な理由はインテント意図の網羅性にありますボットはトリガーフレーズとトピック定義に依存していつ回答すべきかを判断します
1:37
例がすべて同じようなものだとモデルは柔軟性を失ってしまいますたった一つの類義語でもボットを困惑させることがあります
1:42
解決策は地味ですが非常に効果的ですポリシー文書の正式な言葉だけでなくより幅広いトリガーフレーズをトピックに追加しましょう
1:48
人々が実際に使うようなカジュアルで略語を含んだ少し乱れた表現も混ぜておきます何十個も必要はありません
1:53
明白なバリエーションをカバーするだけで十分ですその後再テストしてください
1:56
チャンネルの違いが状況をさらに難しくしますスタジオのテストペインはあくまでシミュレーションに過ぎないからです
2:00
チームシェアポイントデモ用ウェブサイトなどのチャンネルに公開するとプラットフォームによって入力テキストの処理方法や応答のレンダリングが変わる可能性があります
2:06
チームでは開業のされ方が異なるかもしれませんウェブページでは書式設定が削除される可能性があります
2:10
重要なフレーズを別の行に移すといった些細な変更でもモデルがそれをどう評価するかが変わってしまうのですそのためマイクロソフトは各チャンネルで繰り返しテストを行う必要性を強調しています
2:18
スタジオでは正常に動作したボットでも現実世界のフォーマットに直面するとつまずくことがありますユーザーにはユーザーの期待があります彼らにとって質問の言い換えはごく自然な会話の一部です
2:27
彼らはインテントやトリガー意味の重複などについては考えていません彼らは同僚と同じようにボットが理解してくれるものだと単に思い込んでいます
2:33
一度でもひどい失敗をすれば特にデモの場では信頼は失われてしまいますこれが初めて作成する人が痛い目を見るポイントです
2:38
スタジオ内でのリハーサルが誤った安心感を与えてしまいましたがチームでユーザーが何気なく入力した内容がその幻想を打ち砕くのです
2:43
もう一つ例を挙げて具体的に説明しましょうスタジオで経費の制限はと入力します
2:48
ボットは規定では宿泊費は1日200ドルですと直接回答します完璧ですこれをデプロイします次にねホテルの代金はいくらまで戻るんだっけ
2:55
と試してみます規定を引用する代わりにボットは人事に確認するように促したり曖昧な推測をしたりします
3:01
意図は同じでも結果は全く異なりますリハーサルでは正確なのに本番では曖昧になるというこの入れ替わりこそ私たちが話している問題そのものです
3:08
ここから得られる教訓はこれですスタジオはスパーリングの練習相手として扱いましょう
3:12
学習には役立ちますが準備万端であることの証明にはなりません次に進む前にテストペインで3種類のバリエーションテストを試し
3:17
類義語やカジュアルな言い回しを含めてトピックを広げてください最後に公開する際はボットが展開されるすべてのチャンネルで再テストを行ってください
3:23
そうすればユーザーに見つかる前に問題を捉えられますさらに大きな罠が待ち受けています言い回しやチャンネルをカバーしていても適切なソースに基づいていなければボットは崩壊してしまうからです
3:32
質問を見逃すだけでなく事実とは異なることを捏造し始めるのです自信ありげに聞こえるけれど実際は当てずっぽうなボットを想像してみてください
3:38
そこから状況は厄介なことになりますそれがボットをグラウンディング根拠付けさせないという初心者のミスです
3:44
初心者が犯す最初のミスはコパイロットスタジオをルールブックではなく水晶玉のように扱ってしまうことです
3:48
十分な知識に基づかずにエージェントを立ち上げることは準備ゼロで新人を役員会議に送り込むようなものです
3:54
彼らは早口で話し自信ありげに見えますが誰かが確認した瞬間にその話の半分は崩れ去るでしょうそれがボットをグラウンディングさせずに放置する罠なのです
4:01
最初はその輝きに隠れて見えないかもしれませんがスタジオで作成したばかりのビルドは丁寧な挨拶と素早い返信で遅延もなく宣伝されて見えます
4:07
しかしその裏側では言葉を裏付ける確かな根拠がありませんシステムが抽出しているのは事実ではなくパターンに過ぎないのです
4:12
グラウンディング根拠付けされていないボットは何も知りませんただのハッタリです
4:16
テスト画面ではうまく見えるかもしれませんが本番環境のユーザーはすぐに見抜いてしまいます最悪の事態は回答の質の低さではなくハルシネーション幻覚です
4:31
に断る代わりにありそうな数字をでっち上げますその不正確な回答を機にスタッフがホテルを予約してしまい経費のトラブルや苦情メールの対応に追われることになるのです
4:39
文章はプロフェッショナルでも中身は空っぽでしたコントソラボの例でこれが現実の問題であることがわかります
4:44
公式のハンズオン演習ではエクスペンセスポリシーdocxというファイルをアップロードしますその中には宿泊費の上限が1泊200ドルと明確に記されています
4:52
もしグラウンディングをせずに新しいボットにホテルの規定はと尋ねると一泊100ドルと自信満々に答えるかもしれません完全にデタラメですエクスペンセスポリシーdocxを実際に添付して
5:02
初めてモデルは適当な回答をやめますグラウンディングされたボットはドキュメントを引用します
5:06
社内規定によると宿泊費は1日200ドルまでとなっていますその違いつまりレッチ上げか引用かを決めるのがグラウンディングのステップなのです
5:14
ではインターフェースで修正する方法を具体的に説明しますコパイロットスタジオで対象のエージェントを開きます概要画面からナレッジをクリックします
5:20
プラスナレッジの追加を選択しファイルをアップロードしますエクスペンセスポリシーdocxやその他の信頼できるソースを指定してください
5:26
公開ウェブサイトやシェアポイントに接続することも可能ですがファイルの型が管理しやすいでしょうアップロードしたら待ちますコンテンツが準備できるまでインデックス作成に10分以上かかることがあります
5:36
最初のテストクエリですぐに反映されなくても慌てないでくださいインデックス作成が完了したらもう一度質問してみましょう正しくグラウンディングされていればアップロードした
5:43
ドキュメントからの引用元が表示され正しい200ドルという回答が得られますその引用こそが完璧な成功の証ですよくある誤解として会話ブースティングが魔法のように
5:53
欠落を補ってくれると思い込むことがありますブースティングは規定を理解するわけではなく単にテキストパターンを強化するだけです
5:58
知識ソースというアンカーがなければブースティングは一般的な空虚な言葉を並べるだけですそれはまるで知識のないインターンにコーヒーを3杯飲ませてカフェインで無知を補おうとするようなものです
6:07
ラボのドキュメントにもその旨が警告されています知識ベースに一致するものがない場合ブースティングはモデルに組み込まれた一般知識に頼ってしまい
6:14
曖昧または不正確な回答を返す可能性がありますそのため正確性が求められる重要なトピックについては追加したソースのみを検索するように設定する必要があります
6:21
コンプライアンス財務人事などの重要な分野ではボットを広範な言語モデルの中で自由に動かさないようにしてくださいこの手順を無視した場合の悪影響はすぐに積み重なってしまいます
6:29
根拠のないボットは雑談には適していますが経費生産や休暇規定について回答し始めるとヘルプデスクへの問い合わせを誘発してしまいます
6:35
ボットが勝手に限度額を作成したせいで5人の従業員が誤った料金で申請してしまい財務部門に説明しなければならない状況を想像してみてください
6:41
その修正にかかるコストは最初からドキュメントをアップロードする手間よりもはるかに大きくなります
6:44
グラウンディング根拠付けによってあなたのエージェントはやる気はあるが何も知らないインターンからゲーマーが言うところのルール市場主義者に変わります
6:50
それは自身の直感ではなくマニュアルに従って引用するようになります経費規定のドキュメントを添付すればシステムは即座にアドリブではなく企業のルールを強制するようになります
6:56
さらに良いことに回答には根拠となる裏付けや明確な引用が示されるため確認が可能です
7:00
それこそが信頼を守る方法なのです最悪の結果になればあなたはそのデタラメなルールを広める自信満々な噂話マシンを作り上げてしまうでしょう
7:05
最高の結果になれば引用付きで回答する確かな専門家を作り上げることができます後者を実現する唯一の方法は最初から検証済みの知識ソースを読み込ませることです
7:14
ボットが正しく真実を語れるようになっても次の課題が待っていますそれはどう伝えるかです
7:19
正確であっても個性がなければユーザーは離れてしまいます次にボットに個性を教え込む必要がありますがコパイロットスタジオでは標準で個性はついてきません
7:27
あなたが書き込む必要があるのですここでシステムをテスト用ダミーのような話し方から卒業させユーザーが話したくなるような相手と形作って
7:34
いきます具体的には概要ページにある名前説明指示フィールドを編集することを意味します
7:39
これらを空のままにするとチュートリアルモードから抜け出せない npc のようなありきたりな返答しか返ってきませんこれは初めて構築する人の多くが見落とすポイントです
7:47
作成ボタンを押した瞬間にシステムにはすでにデフォルトのスタイルが設定されていますフィールドを編集しなければ権威も文脈もない当たり障りのない挨拶をするだけのボットになってしまいます
7:54
信頼を獲得するのは文脈コンテキストです人事や財務のような環境で一般的な口調だとユーザーは信頼できるツールを使っているのではなく
8:01
プロトタイプをテストしているのだと考えてしまいます例えば経費規定の専門家を作ろうとしても名前や説明を変更しなければエージェントは背景情報のない
8:09
一般的なコパイロットとして表示されてしまいます誰かがホテルの生産について尋ねた時ユーザーは専門的なアドバイスを期待しているのです
8:15
ユーザーが目にするのは何の工夫もない素っ気ないテキストですこれでは私を信用しないでくださいというかすかですが強力なサインを送っているようなものです
8:21
信頼はすぐに失われます最初の接触でユーザーを逃がせば二度と戻ってはきません全体の設定を手早くキャラクターシートを作るような感覚で考えてみてください
8:28
名前は職業クラス説明は背景バックストーリー長い指示ボックスは能力値そしてトーンは属性アライメントです能力値を割り振らずにキャンペーンに挑むことはないでしょう
8:37
ボットを公開するときも同じですさてここでは具体的な数字が重要になりますボットの名前は30文字が上限なので短く鋭いものにしましょう
8:44
経費規定エキスパートトラベルガイド福利構成ヘルパーなどがいいですね説明欄は約1000文字まで入力可能で明確な文章をいくつか書くには十分な長さです
8:52
例えばこのエージェントは公式の出張規定に基づいた最新の回答を従業員に提供します関連する条文を引用し推測による回答は避けますといった具合です
9:00
次に指示フィールドがありますこれは自由に使える枠で最大8000文字まで入力可能です
9:05
ここで実際の運用ルールをしっかりと固定できます単に親切にと書くのではなくプレイブックを具体的に明記しましょう
9:10
ポリシーの該当箇所がある場合は必ず引用すること推測による回答は避けること役員向けには簡潔な一問で要約しその後に引用元を提示すること
9:18
作成時に読み上げられる便利なチェックリストはこのようなものです役割に名前を付け専門性について短い説明を書き
9:24
トーンフォーマルカジュアル専門外の人にも分かりやすくを設定し指示欄を行動ルール含めるべき内容避けるべき内容フォーマット方法で埋めること
9:32
これらのステップの一つ一つがアイデンティティを強固にしていきますどれも高度な設定は必要ありません
9:36
作成時にすぐ行えますし概要ページから後で編集することも可能ですトーンのガイダンスは控えめながら強力です
9:42
フォーマルかつプロフェッショナルにや技術的背景のないスタッフにも分かりやすくカジュアルにといったフレーズで明示的に誘導できます
9:49
必要であれば指示欄に直接例を追加しましょうボットがすべての文章をどのように構成するかを制御するのに多くのテキストは必要ありません
9:55
あまり知られていない2つの迅速な改善策を紹介します会話開始トピックを編集しエージェントアイコンを変更することです
10:01
どちらも5分以内で完了しますテストペインでチャットを開いた時にボットが最初に行う挨拶メッセージを確認できます
10:06
デフォルトでは汎用的な内容になっていますそこをクリックして会話開始トピックを編集し決まりきった挨拶文を出張規定の理解をサポートします
10:13
可能な限り公式ドキュメントを引用しますといった役割に応じた紹介文に置き換えましょうその後会話をリフレッシュしてテストします
10:19
一瞬でプロフェッショナルな印象になりますアイコンについては192x192ピクセル以下30kb未満のpng形式に対応しています
10:26
ブランドロゴなどの画像を一つ入れるだけでもデモ感が払拭され最初の回答に対する信頼性が損なわれなくなります
10:31
こうした修正を単なるオプションの仕上げだと考える人もいますしかしこれは最低限の防具だと考えてください
10:36
防具のないキャラクターでも攻撃はできますが強烈な一撃を食らえば一瞬で倒されてしまいます味気ない名前と曖昧な挨拶でユーザーを迎えるボットはこれと同じ無防備な状態です
10:45
基本をしっかり抑えておけば混乱や離脱に対する強力な防御策となります小さな調整の積み重ねが大きな効果を生みます
10:51
役割を明記した導入文を設定すればユーザーは適切な質問をしやすくなります口調のルールを決めれば長すぎる冗長な回答を防げます指示を明確にすることで
10:59
aiは余計な情報をそぎ落とし人間にとって読みやすい形式で回答しますこうした調整の一つ一つがわかりませんという問い合わせを減らし新しいコネクタやプラグインなしでスムーズなやり取りを実現します
11:07
ですからこれをルールにしてください高度なロジックを組む前にまずはペルソナを設定しましょう
11:10
目的が伝わる名前を選びます短く明確な説明文を作成します口調を設定します守らせたいルールを指示に盛り込みます会話の最初の挨拶文を更新します
11:18
シンプルなアイコンに変更しますこれらは少ない労力で大きな成果が得られるアクションですうまく機能すれば明確なペルソナを設定するだけで作りたてのボットでもユーザーから頼りにされる存在になります
11:27
逆にペルソナを怠ると誰も二度と使いたがらない不自然な npc になってしまいますエージェントに個性を与えたらいよいよ本番の作業です
11:34
本当のテストは作成時ではなく実際のやり取りで成功や失敗を目の当たりにした後に始まります一度の失敗で諦めるのではなくその時こそ立ち止まってログを確認する必要があります
11:45
リアルタイムで失敗をデバッグするのですリアルタイムでのデバッグこそが失敗を問い合わせではなく学びへと変える鍵となります
11:50
これこそすべての開発者が実践すべき実践的なループです間違いを見つけ特定し修正しそして再度テストを実行する
11:56
コパイロットスタジオにはツールが揃っていますが順序立てて使うことが大切ですデモを行いながら実際に口に出して進められる手順がこちらです
12:02
ステップ1テストウィンドウで失敗したユーザーのクエリを再現します曖昧に流してはいけませんユーザーが尋ねたものと全く同じ質問を入力してください
12:09
ステップ2リフレッシュアイコンか新しいチャットを押して再度実行する前に会話をリセットします白紙の状態から始めることが重要です
12:15
ステップ3トピックを開いてどのトピックが作動したかを確認しますそれが自分で作成したものではなくシステムの会話ブースト機能によるものならボットが独自の知識ではなくモデルの知識に頼ったというヒントになります
12:24
ステップ4ブースト機能が働いていた場合関連するファイルやサイトがアップロードされインデックスされているか確認しますインデックスがなければ根拠付けも行われませんインデックス作成には数分かかる場合があることを覚えておいてください
12:33
ステップ5指示やトピックの内容を編集して保存し全く同じクエリを再実行します再現修正再実行繰り返しというサイクルがあなたのマントラですこれを飛ばすと次回は運任せで結果が良くなることを願うだけになってしまいます
12:44
回答が曖昧なのはトーンの問題ではなく構造の欠如である場合もありますそこで新しいトピックを作成することが効果を発揮します
12:49
スタジオにはトピックページから直接コパイロットを使って説明文から追加できる便利なオプションがあります経費の上限について聞かれたら直接答えるなど必要なことを記述します
12:58
追加を押せばシステムはその説明からトピックのノートツリーを下書きします迅速かつ明確であの厄介で曖昧な回答が次回からは確実な回答パスになることを保証します
13:08
ボットが同じ基本的な質問を交わし続けるときはいつでもこれを使ってくださいただしイエスかノーかの修正だけで満足しないでください
13:14
トーンのabテストのような10分間の実験を行いましょう指示フィールドに移動し形式的な規定言語を用いたパターンaを作成します
13:20
保存して出張費の上限はと質問し回答を記録します次に指示をパターンbに変えます
13:26
ルールを引用しつつ親しみやすい人事担当者のように説明させます同じ質問をもう一度実行すればどちらのペルソナがより優れているかを示すログが並んで表示され
13:35
テストペイン以外に何も必要ありませんそうすれば推測ではなく証拠に基づいてトーンを決定できます
13:40
次にグラウンディング根拠付けの確認を追加しますテスターがホテルの経費はいくらまでと質問したとします
13:45
そこでボットが人事に確認してくださいと曖昧に答えたとしますそれは完全な失敗ではなくフィードバックです
13:49
おそらく経費規定のドキュメントがまだインデックス化されていないのでしょうあるいはトリガーフレーズにホテルが含まれていないのかもしれません
13:55
ナレッジタブを再確認してファイルが反映されているかを確認しトピックのトリガーフレーズにホテル経費を追加して修正します
14:00
さあ再実行です規定により宿泊費は1泊200ドルまでですという回答が得られれば問題は無事に修正されました
14:07
繊細ですが重要なコツは会話のきっかけスターターを使うことですテキストボックスが空だとユーザーは戸惑いますが
14:13
概要ページから推奨プロンプトをいくつか事前入力しておけますホテルの上限はのような質問のフックを3から5個追加します
14:20
出張経費の申請方法は食事代は生産されるユーザーは直接クリックできるため実際のパスをより早くテストでき
14:27
入力する前からボットが自分の役割を理解していると感じてもらえますこのリズムを繰り返すことでボットはパスを重ねるごとに頑強になります
14:33
自然な失敗を無視して次の実行で魔法のように成功することを期待してはいけませんそれではユーザーはサポートチケットを作成する羽目になり信頼を失ってしまいます
14:40
クリティカルヒットが出たらボットが引用元を明示し適切なペルソナで複雑な入力すら理解できると証明するまでそのルーティンを繰り返します
14:46
繰り返すたびにサイコロ任せの不安定な存在から頼りになるチームメイトへと近づいていきますそしてこれが現実です
14:52
テストペイン内での調整はいわば安全モードですループがうまく機能するようになったら次の段階はその修正が自分の環境以外でどう動作するかを確認することです
14:59
そこでチャンネルごとの違いが顔を出し始めますこれこそ多くの初心者が過小評価している部分です
15:04
ダンジョンが公開されるときつまりパブリッシュとチャンネルにまつわる驚きですいざパブリッシュを実行するとエージェントは攻防を離れ実際のユーザーの目にさらされることになります
15:12
コパイロットスタジオではこのステップをダンジョンが公開されるときと呼びますパブリッシュによって入念にリハーサルしたボットが独自のルールを持つチャンネルへと放り込まれるからです
15:20
最初の驚きはパブリッシュはクリック一つで完了する単純なものではないということですそれは誰がエージェントにアクセスできどうやって接続しその応答が現場でどのように表示されるかを決定するプロセスなのです
15:30
チームシェアポイントデモ用ウェブサイト各チャンネルには特有の癖がありますスタジオで完璧だった返信もデプロイした途端に見た目が変わったり表示に失敗したりすることがあります
15:37
チームを例に挙げてみましょうスタジオでは回答は明瞭に返ってきますポリシーでは宿泊費は1日200ドルです同じフレーズをチームでテストするとボット側は何も変えていないのに突然理解できませんと返されてしまいます
15:48
これはチームがテキストを折り返しメタデータを渡す際の方法が表示の整合性を崩しているためですシェアポイントは業間に関して独自の挙動をしますデモ用ウェブサイトが最もシンプルですがそれでもスタジオとは異なる形式でレンダリングされる可能性があります
15:59
パブリッシュ先はそれぞれ異なるアリーナであり個別にテストしなければなりません完了とする前に踏むべき正しい手順は何でしょうか初心者が陥りやすい罠を避けるためのパブリッシュチェックリストをご紹介します
16:08
まずナレッジファイルが完全にインデックス化されていることを確認してくださいアップロードしたばかりだとまだライブ回答には対応できていない可能性があります
16:14
次に認証を設定します広範囲なデモを行う場合は認証なしを選択しリンクを持つ誰でも試せるようにします 3番目にパブリッシュボタンを押し緑色の確認バナーまたはチャンネルページのステータス更新が表示されたことを確認します
16:26
4番目にデモ用ウェブサイトのチャンネル設定を開きますウェルカムメッセージと会話のきっかけを更新しテスターが空のチャットボックスを前に固まらないようにしましょう
16:33
最後にクローズドパイロットを実施しますまだテナント全体に配信してはいけません明確な指示を与えた小規模なグループで進める方が全体リリースよりも賢明です
16:40
そのパイロットグループには彼らがテスト体であることを認識してもらう必要がありますカジュアルな言葉遣いや誤字を含めたり適切な場面でファイルをアップロードしてみるよう依頼しましょう
16:47
彼らのミスが弱点を浮き彫りにするのです限定的なパイロット運用は単にリリースをスムーズにするだけではありません
16:52
全社展開の前にビルドを修正するために必要な性のレポートが得られるのですチャネルごとの挙動を確認するためにはこの手順が不可欠です
16:59
スタジオでテストしたあらゆるシナリオ正式なクエリカジュアルな表現誤字根拠となる引用をすべてのターゲットチャンネルで再度実行してください
17:05
チームでの表示に違いがないか確認しましょうシェアポイントで感覚が崩れていないか確認します
17:09
webデモでソースの引用が正しく付加されているかも確認してくださいこれが一貫性を証明する唯一の方法です
17:14
スタジオで一度完璧に動作したからといってロールアウトでうまくいくとは限りません公開するということはユーザーのフィードバックだけに頼るのではなくテレメトリの監視を始めることでもあります
17:21
ボットがチームやデモサイトで公開されると利用データの収集が始まりますパワープラットフォーム管理センターと組み込みの分析機能がその助けとなります
17:29
導入数やエラー数どの会話がトピックをトリガーできなかったかまで把握できますそれは余計な作業ではなく監視システムなのです
17:35
一度公開して終わりではありませんログを監視しボットが正しく使われヘルプデスクのチケットを増やしていないか確認する必要があります
17:41
この手順を急ぐと信頼を損ないます最悪の場合公開ボタンを押し全部書にロールアウトした途端チームで重要な回答が欠落し動かないというチケットで
17:49
あふれ返ることになりますユーザーは離れてしまい彼らを取り戻すにはボットを修正する以上の時間がかかります
17:53
最高の結果を目指すなら公開を新たなテストフェーズと捉えましょうインデックスの完了認証の設定公開の確認デモサイトの調整パイロット運用の実施です
18:01
散らかったフィードバックを集め応答を修正しすべての主要なクエリを各チャンネルで再実行します本格的なロールアウトへと拡大する頃にはストレステストは完了しているはずです
18:09
真のコツは公開を終わりと考えるのをやめることです公開ボタンは物語の結末ではなくフィールドキャンペーンの始まりなのです
18:15
パイロットのデータが集まりログですべてのユーザーが適切な回答を得ていることが確認できればようやく安定していると呼べるようになります
18:21
この認識はコパイロットスタジオでの構築という大きな全体像につながります一度作って終わりではなく何度も調整を繰り返すシステムだからです
18:28
それでは本当に重要なポイントをまとめますビルドを不安定から信頼できるものへと変えるのは3つの要素です
18:33
第1にエージェントに根拠を与えること実際のドキュメントをアップロードするか信頼できるソースを指定して推測を防ぎます
18:38
第2にヘルソナを与えること 8000文字の指示フィールドで名前説明トーン挙動を具体的に指定してください
18:44
3つ目リハーサルがうまくいったからと油断せずテストパネルを使い限定的な試験運用を経てから公開し監視しましょう
18:49
最高の成果が出ればこれらの手順で問い合わせチケットを増やすのではなくユーザーの信頼を獲得するボットが完成します
18:54
チャンネル登録をしてあなたのエージェントの根拠とするポリシー文書を一つだけコメント欄で教えてください