フィードバックを見て改善する

このステップは、stakeholder が公開済みの体験を試し、ラフなフィードバックを残したあとに始まります。最も速い operator フローは、Histories で thread を見て、Copilot に何が起きたかを聞き、Add Case で危険な返答を eval case にし、Editor で Agent を直して、そのケースを Test Suite で実行する流れです。

ステップ1：Histories で stakeholder の thread を開く

stakeholder が公開済みの Web channel を使い始めたら、Histories で修正すべき thread を 1 つ選びます。

• 安全ではあるが、不自然または generic な返答
• 重要な確認質問が抜けている返答
• もっと早く人に引き継ぐべきだった返答
• stakeholder のフィードバックがすでに付いているメッセージ

ステップ2：thread の横で Copilot を開いて聞く

thread を開いたら、右下の Copilot ボタンを押して panel を開き、thread を見たまま Copilot panel の Ask a question... に、なぜその返答になったのか、instructions をどう直すべきかをそのまま聞きます。

stakeholder のフィードバックは、きれいに整理されている必要はありません。多くのチームでは、stakeholder は「何が変だったか」と、せいぜい一言の理由だけを書きます。そこから診断するのが operator と Copilot の役目です。

たとえば:

ある stakeholder が pricing の返答に次の feedback を残しました。
「この回答は安全ですが、まだ少し generic です。もっと短くして、価格は人が案内することを早めに伝え、human callback ももっと早めに提案してください。」

なぜ Agent はこう振る舞ったのでしょうか。Agent Editor では、どの instruction を変えるべきですか？

Copilot には、たとえば次のような点を整理してもらいます。

• どの instruction がこの振る舞いにつながったか
• どのルールが曖昧すぎるか、広すぎるか
• instructions をどう書き換えるべきか
• より良い返答ならどんな形になるか
• あとで Test Suite で見るべき Standard は何か

ステップ3：Histories の Add Case でケース化し、Copilot と Standard を整える

thread、feedback、Copilot の分析がまだ見えているうちに、その返答の Add Case を押します。

まだ Histories から離れないでください。実際の失敗をそのまま再利用できる eval case にする最適なタイミングです。

Copilot には、短くて判定しやすい Standard を作るのも手伝ってもらえます。たとえば:

この失敗を `Test Suite` 用の短い `Standard` 2 つか 3 つにしてください。
他の operator でも迷わず pass / fail を判断できる内容にしてください。

Case Detail では次を整えます。

• 前の会話文脈を残して、ケースに必要な流れを含める
• Input が再実行したい高リスク質問になっているか確認する
• Ideal Response を今回ほしい改善後の返答に合わせて直す
• Copilot の提案をもとに、短い Standard を書く
• Create を押す

ステップ4：Editor に戻って Agent を更新する

ケースを保存したら、Edit Agents に戻り、Consultation Desk を開いて、Instructions の必要な部分だけを更新します。

変更の準備ができたら:

1. Apply を押す
2. 更新した instruction を確認する
3. もう一度 Publish を押して、web client に新しいバージョンを反映させる

変更範囲は小さくする

一度に多くを変えると、何が効いたのか分かりにくくなります。まずは 1 つの明確な問題だけを直すほうが検証しやすくなります。

ステップ5：保存したケースを Test Suite で実行する

このフローでは Live Test に戻らず、保存したケースをそのまま Test Suite で実行します。更新後の version で、そのケースが通るかを見ます。

確認したいのは次の点です。

• ケースが pass するか、少なくとも明らかに良い方向へ動いたか
• Standard が本当にほしい挙動を見ているか
• 修正が狭く保たれていて、何が効いたかを理解できるか

ここから先の運用パターンはシンプルです。

1. 少人数の stakeholder に共有する
2. Histories でラフなフィードバックを見る
3. Copilot に何が起きたか聞く
4. Add Case で重要な thread を eval case にする
5. Editor で Agent を更新する
6. Test Suite でそのケースを再実行する

この繰り返しで、Agent は少しずつ安全になり、役に立つものになります。

最初の改善ループが完了しました

ここまでで、Agent の公開、実際の stakeholder feedback の回収、最初の再実行可能な eval case の保存、instructions の更新、そして Test Suite での検証まで完了しています。これが以後の改善の土台になります。

さらに構造化したくなったら

pilot が広がってきたら、次を追加します。

• 構造化された intake 情報が必要なら Request Form
• 二度と繰り返したくない失敗が増えたら 評価と改善 にケースを増やす
• 複数の変更を慎重に見たいなら Version Management

次のステップ

• フィードバックの収集
• 評価と改善
• バージョン管理