検証済みシナリオ

Codeer が最も力を発揮するのは、Agent と重要シナリオを一緒に作るときです。

Agent は、どう答え、どう判断し、いつ handoff するかを定義します。シナリオは、実際の質問でどう振る舞うかを見せてくれます。両方を同時に考える必要があります。Agent だけを書けば、まだ推測に頼っています。最初の version が本当に安定してできることを考えずに case だけを増やすと、scope が散らばりすぎて安定させにくくなります。

最初の scope から始める

最初の version では、狭くて重要なシナリオを選びます。通常は 20 から 30 件で十分です。

次の四つに分けると整理しやすくなります。

Core scenarios: Agent が今答えるべき質問
Boundary scenarios: Agent が慎重に扱い、必要なら handoff や追加情報の依頼をすべき質問
Out-of-scope scenarios: Agent がまだ答えるべきではなく、拒否、handoff、または form に流すべき質問
Action scenarios: form、payment、booking link、API call、specialist agent などの tool が必要な依頼

シンプルな customer service Agent なら、最初の set は次のようになります。

顧客が返金ポリシーを聞く
顧客が未承認の返金保証を求める
reseller 経由の購入で、適用ポリシーがはっきりしない
顧客が担当者からの連絡を希望する
対応範囲外の legal、medical、competitor advice を求める

目的は、あらゆる質問を網羅することではありません。最初に理解でき、テストでき、改善できる scope を定義することです。

まず Copilot に現在の Agent からこの最初の set を作らせ、operator が確認して本当に重要な boundary を加えることができます。これにより、Agent の能力と scenario scope がそろい、最初から広げすぎることを避けられます。

各シナリオを case にする

Test Suite では、重要なシナリオを再実行できる case にします。

役に立つ case には次が含まれます。

現実的な user input
Agent が答える、または handoff するために必要な context
AI response が何をすべきか、何をしてはいけないか、いつ handoff すべきかを示す Standard

強い standard は確認可能です。別の operator が AI response を読んでも、何をもって合格かを推測せず判断できる必要があります。

最初の case を作ったら、すぐに実行してください。目的は Agent が完璧だと証明することではありません。今どこが不安定かを早く見つけることです。

Boundary と out-of-scope も検証する

Out-of-scope behavior も product experience の一部です。

Agent が答えるべき質問だけをテストしないでください。まだ答えるべきではない質問もテストします。安全な first version は、次のタイミングを知っている必要があります。

対応範囲外であると伝える
人に handoff する
form で構造化された情報を出してもらう
未承認の promise、price、guarantee、advice を避ける

これにより、何でも扱えるふりをせず、狭く安全な Agent を公開できます。

Agent が拒否または handoff した会話にも価値があります。それらは実際の user query set になり、次にどの scope を広げるべきかを判断する材料になります。

最初の knowledge は小さく保つ

存在する document をすべて upload する必要はありません。

最初の重要シナリオに必要な最小限の source of truth から始めます。失敗した case が、知識不足こそ原因だと示したときだけ knowledge を追加します。

case が失敗したら、content を増やす前に原因を診断します。

Standard が間違っているなら、Standard を直す。
behavior rule が曖昧なら、Instructions を直す。
必要な事実が足りないなら、関連する Knowledge Base content を追加または整理する。
action が必要なら、適切な tool を追加または絞る。
シナリオが first scope の外なら、安全な fallback に残し、後の version で扱う。

Version ごとに scope を広げる

pass している case が、今信頼できる scope を定義します。

最初の launch では、検証済み scope を小さく保ちます。それ以外は human handoff、refusal、request form などの安全な fallback に流します。

scope を広げるときは、次の順番で進めます。

新しいシナリオを Test Suite に追加する。
各シナリオの Standard を定義する。
失敗した case が必要性を示した場所だけ、Agent、knowledge、tool を更新する。
影響する case を実行する。
既存 behavior に影響する可能性がある場合は、より広い suite を実行する。
広げた scope が安定してから新しい version を publish する。

この流れにより、小さく制御された Agent から、より広い service layer へ version ごとに広げられます。

二つの方法で進められる

この方法は Codeer だけで進めることも、別の AI assistant に作業材料の draft を手伝わせることもできます。

方法	向いている場合	進め方
Codeer UI と自分の AI assistant	ChatGPT、Claude、Gemini などで計画を立てることに慣れている	シナリオ、standard、修正案の draft を作らせ、確認したものを Codeer に入れる
Codeer Skill workflow	scope、case、debug、improvement を guided workflow で進めたい	この guided workflow が利用可能になったときの案内が必要な場合は `ian@codeer.ai` に連絡する

どちらでも方法は同じです。シナリオ set を定義し、AI response を standard に照らして検証し、信頼できる scope だけを公開し、version ごとに広げていきます。