フィードバックを見て範囲を広げる

このステップは、stakeholder が公開済みの検証済み scope を試したあとに始まります。Production feedback は、次に何を広げるべきかを決める材料です。最も速い operator flow は、Histories で thread を見て、Copilot に何が起きたかを聞き、新しい scenario を Add Case で再実行できる case にし、必要な部分だけ Agent を直して、影響する case を Test Suite で実行する流れです。

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

stakeholder が公開済みの Web channel を使い始めたら、Histories で学びのある thread を 1 つ選びます。

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

ステップ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 から離れないでください。実際の pattern を再実行できる case にする最適なタイミングです。

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

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

Case Detail では次を整えます。

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

ステップ4：これは scope expansion かを判断する

case を保存したら、まず変更の種類を判断します。

• すでに検証済み scope の中の修正
• 次の version で広げるべき新しい scenario
• 今は安全な fallback に残すべき case
• 広げる前に解消すべき knowledge gap や tool gap

修正または拡張すると決めた場合だけ、Edit Agents に戻り、Agent を開いて、関連する Instructions、knowledge、tool setup だけを更新します。

変更の準備ができたら:

1. Apply を押す
2. 更新した instruction を確認する
3. まだ publish しない。先に Test Suite で影響する case を再実行する

変更範囲は小さくする

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

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

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

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

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

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

1. Histories で real traffic を見る
2. Copilot に何が起きたか聞く
3. Add Case で重要な thread を reusable case にする
4. それぞれの case が修正、scope expansion、fallback のどれかを判断する
5. 必要な場所だけ Agent、knowledge、tool を更新する
6. 影響する case を実行し、既存 behavior に影響するならより広い case set も実行する
7. 広げた scope が安定してから新しい version を publish する

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

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

ここまでで、実際の stakeholder feedback の回収、reusable case の保存、scope expansion かどうかの判断、Agent の改善、そして新しい version を publish する前の Test Suite 検証まで完了しています。

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

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

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

次のステップ

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