最初の draft を作成してデバッグする

Live Test で最初の動作を素早く確認し、重要な状況を Test Suite で再実行できる case として残します。

Live Test は探索に使います。Test Suite は、version の動作を、残したい専門判断と比較するために使います。

ステップ1：`Live Test` で実際の状況を実行する

workspace を開きます。
AIエージェント を選択します。
Agent を開きます。
Agent Editor の Live Test panel を使います。
仕事の説明に使った実際の状況を入力します。

文章の流暢さだけでなく、仕事の結果として確認します。

Agent は利用者が完了しようとしたことを理解したか
本当に必要な情報を質問したか
有用な次の行動または結果を出したか
根拠のない事実、約束、アクションを避けたか
専門家の判断が必要な場面で handoff したか

同じシナリオを続けるか、新しいテストを始める

Live Test は送信済みの会話を保存します。history selector から以前のテストを開き直せます。次の variation に過去の message を引き継がせない場合は Start new test を選びます。

以前の回答が必要な multi-turn scenario は同じ history を続ける。
独立した variation、model 比較、regression check は新しいテストを始める。
他の reviewer がシナリオを識別できる名前に変更する。
証拠として不要になった場合だけ削除する。作成者または workspace resource-management 権限を持つ member が名前変更・削除できます。

必要な workflow では音声入力をテストする

現在の Agent model が audio input に対応していれば、Record voice message でテスト依頼を話せます。microphone を許可し、録音を停止して添付音声を確認し、通常の message と同じように送信します。

録音が使えない場合は、選択した model と browser support を確認してください。音声録音は Agent が音声を理解できるかを試す機能です。Agent の回答を音声化する Text to Speech は別の tool です。

ステップ2：隣接する境界を試す

設計上の問題を見つけるため、近い変化をいくつか追加します。

重要な情報が不足している。
依頼が最初の scope の外にある。
自信のある回答がリスクを生む。
ツールまたは情報源が利用できない。
人が引き継ぐべきである。

確認する動作は仕事によって異なります。

仕事の型	基本動作	有用な境界確認
回答と対応	承認済みの回答を出す、または対応可能な次の行動を完了する	未承認の例外を勝手に処理せず、正しい handoff を行う
導きと判断	適切な質問を行い、実行可能な次の行動を示す	専門家レビューが必要な状況で確実性を誇張しない
レビューと成果物	明示された品質条件を提出物に適用する	根拠を作り話しせず、不足している根拠を示す

この段階では最初の設計を確認します。すべての変化に対応できることを証明する段階ではありません。

ステップ3：must-pass の状況を `Test Suite` に保存する

今後も正しく保つ必要がある動作を、再実行できる case にします。

各 case に必要な項目は次のとおりです。

Input：実行する利用者メッセージまたは仕事
Standard：AI response を確認できる明確な条件

任意の項目には次があります。

Note：reviewer のための context
Ideal Response：表現や構造が重要な場合の参考例

完璧なサンプル回答より、明確な Standard の方が重要です。回答が何を行い、何を避け、いつ handoff するかを別の reviewer が判断できるようにします。

Case は何件必要か

次の判断に必要な証拠の量で決めます。

判断	準備する証拠
最初の動作を続ける価値があるか	実際の状況と、いくつかの隣接する境界
制御された pilot の準備ができたか	頻度、失敗時の影響、ツール利用、handoff risk で選んだ must-pass case
次の version を公開できるか	影響する case と、変更が既存動作に影響する場合の広い regression case

すべての Agent に共通する固定件数はありません。影響の大きい仕事は、範囲が狭くても低リスクの社内 helper より多くの境界確認が必要な場合があります。

ステップ4：case を実行して失敗を読む

適切な evaluator で case を実行します。Content Compliance を使う場合は、Standard に対する pass または fail として結果を読みます。

Agent を編集する前に失敗を確認します。

回答が受け入れ可能なら、Standard が不明確または誤っている可能性がある。
Standard と情報源が矛盾する場合は、どちらを正とするか決める。
必要な事実がない場合は、関連する Knowledge Base content を追加または整理する。
事実があるのに判断が誤っている場合は、関連する instruction を明確にする。
アクションが失敗した場合は、ツール設定と呼び出し境界を確認する。
最初の scope 外なら、広い回答を強制せず安全な fallback を保つ。

失敗を有用な証拠にする

失敗した case は現在の設計についての証拠です。変更する前に、問題が期待動作、instructions、knowledge、tool、scope のどこにあるかを診断します。

ステップ5：関係する最小の修正を行う

失敗結果の横で Copilot に依頼するか、case と Agent を直接確認します。

この case は合格しませんでした。問題が Standard、情報源、ツール動作、Agent instruction のどこにあるか診断してください。一つの case だけに overfit せず、この pattern を改善する最小の変更を提案してください。

限定した変更を適用し、失敗した case を再実行します。既に合格した動作に影響する可能性がある場合は、より広い case も再実行します。

制御された pilot に進めるか判断する

合格した case を、そのまま公開許可とは見なしません。次の条件がすべて満たされた場合にのみ、制御された pilot に進みます。

最初の仕事と、明確に対象外とする scope が記録されている。
よくある状況と影響の大きい境界に、名前付き case と確認可能な Standard がある。
必要なツール、情報源、handoff が、それらを使う状況で合格している。
既知の失敗または未テストの状況に安全な fallback があるか、pilot の対象外になっている。
残るリスクを受け入れる release approver と、公開後の handoff・incident を担当する operator が決まっている。

未解決の項目があれば Agent を draft のままにするか、pilot の範囲を狭めます。この gate はテスト証拠に基づくチーム判断です。緑の結果だけでは、許容できるリスクは決まりません。公開手順は検証済みの範囲だけを公開を参照してください。