onboard

Coval の初回評価

お客様のエージェントから、信頼できる評価証拠を1つ得ます。 接続が機能することは最初のマイルストーンですが、タスク品質の信頼できる確認は別途必要です。セットアップを調査に変えたり、考えられるあらゆるリソースを作成したりしないでください。

1. コンテキストとアクセスを確立する

お客様が提示したユースケース、エンドポイント、要件を再利用します。不足している情報だけを尋ねます。エージェントが実行すべきこと、検出すべき重要な失敗を1つ、使用する組織／ワークスペース／環境です。完了済みの録音がすでにある場合は、新しい実行を希望しているのでなければ、coval-discover-failures を優先します。

coval --version
coval --agent agent doctor
coval --agent agent manifest

インストールや認証が済んでいない場合は、最新の CLI インストールガイドを使用します。認証情報はチャットではなく、ログインまたはユーザーのシークレット環境を通じて入力してもらいます。Doctor で確認できるのは接続性であり、テナントの識別ではありません。書き込みの前に、対象アカウントのコンテキストと選択されたリソースを確認します。既存のワークスペースを使用します。CLI で選択できない場合は、公開 API のドキュメントに記載されたワークスペースヘッダーを使用します。

そのスコープ内にある既存のエージェント、ペルソナ、テストセット、メトリクスを調べます。JSON エンベロープ（ok、data）、失敗、ページネーションを確認します。一致するリソースは再利用します。書き込み時に名前だけで一致を判断するのは安全ではありません。

2. エージェントを1つ接続する

coval agents create --help と coval --agent agents context を読みます。CLI で公開されていないフィールドについては、現在のエージェント仕様を https://api.coval.dev/v1/openapi/agents から取得します。実際のトランスポートを選択します。電話、ホスト型音声間接続、音声 WebSocket、LiveKit/Pipecat、チャット、チャット WebSocket、A2A、または SMS です。すべての WebSocket 接続がテキスト専用だと決めつけないでください。Coval のドキュメントインデックスから、一致する接続ガイドを使用します。

適切であれば、設定済みのエージェントを再利用します。新しく接続する場合は、スキーマに適合するリクエスト本文をローカルで準備し、機密情報を伏せた概要を提示してから、指定されたスコープ内でのみ作成します。認証情報をスキル、レポート、Git にコピーしないでください。作成したエージェントを読み戻し、秘密情報を表示せずにトランスポートとエンドポイントを確認します。URL に到達できることやエージェントのレコードが保存されていることは、音声接続の成功を意味しません。

3. 有用な最小限のテストを設計する

build-test-suite を使用し、お客様のワークフローに基づいた少数のケースを作成します。ライブ接続の確認は、短いケースを1つ、標準的なペルソナを1つ、反復回数を1回、同時実行数を1で開始します。その後、合意した予算内で、通常の成功パスと重要な境界／失敗ケースを追加します。これは出発点であり、普遍的な3カテゴリー分類ではありません。

ペルソナには発信者がどのような人物で、どのように振る舞うかを記述します。テストケースには発信者が何をしようとしているかを記述します。期待される振る舞いにはエージェントが何をすべきかを記述します。期待する回答を発信者に言わせないでください。シナリオは、目的が達成された時点で終了させ、終わりのない会話を避けます。

音声では、公開ペルソナカタログから、現在利用可能で互換性のある音声と言語を選択します。古いテンプレートにあるプロバイダーの音声名をハードコードしないでください。既存の適切なペルソナを使用するか、スキーマを確認してから coval personas create --input-json @persona.json を準備します。ノイズ、アクセント、中断を追加するのは、関連する仮説を検証する場合に限り、基本的な接続が機能した後にします。

4. 観測可能な評価基準を選ぶ

タスク固有の評価基準を1つと、必要であれば少数の運用測定を設定するために configure-metrics を使用します。メトリクス ID は動的に検出します。感情、口調、解決度のスコア一式を一律に適用したり、1回の実行を評価するだけのためにエージェントのデフォルトを変更したりしないでください。

トランスクリプトから、何が話されたかは確認できます。予約、支払い、送金が実際に行われたかどうかは確認できません。そのような主張には、ツールのトレースまたは外部証拠を使用します。新しいジャッジは、人間のラベルと照合するまでは暫定的なものです。

5. 実行して調査する

選択したケース ID と明示的なセッション予算を指定して、quick-eval を実行します。 実行前に何が行われるかを示し、お客様の既存の承認に従ってください。 呼び出し回数、メトリクス評価回数、設定された呼び出し時間の上限、 および実時間での停止条件を含めてください。現在の料金が分からない限り、件数を金額に換算しないでください。再実行も同じ予算に含まれます。

初回実行の各トランスクリプト、ステータス、メトリクス、録音を監査します。 呼び出し元は意図したシナリオを実行しましたか？両者の音声が含まれていますか？メトリクスは適切な話者と評価基準を採点しましたか？説明と根拠を照合してください。実行が完了したことや、1 つの例で満点を得たことは、統計的な信頼性を示すものではありません。

接続に失敗した場合は、テスト範囲を広げる前にその呼び出しの原因を調査してください。出力を利用できない場合は、不足している根拠と、それが結果に及ぼす影響を報告してください。チャットに黙って切り替えたり、環境を変更したり、再試行を続けたりしないでください。

6. 再利用できる出発点を残す

作成または再利用したリソース ID、組織／ワークスペースを照合して確認した実行／結果のリンク、実際のシミュレーション数とメトリクス数、確認された結果とその限界を提示します。次に最も有用な手順を 1 つ提案します。失敗を調査する、テスト範囲を広げる、または人手によるラベルを収集する、のいずれかです。テンプレートの保存は、依頼された場合、またはすでに合意済みの定期的なワークフローに必要な場合に限ります。スケジュールの作成は別の操作です。

調査できるようにリソースを保持してください。付随的な後片付けとして、リソースを削除したり、本番エージェントのデフォルト設定を変更したり、招待を送信したり、フォローアップをスケジュールしたりしないでください。