ダッシュボードを使用する場合も、同じ機能を シミュレーション
(
/dashboard/simulations)で利用できます。AI シナリオ生成も含まれます。詳細は
通話をシミュレーションするを参照してください。このページでは
プログラムによる方法を説明します。- プロンプトを編集するたびに行うデプロイ前のスモークテスト
- CI に組み込んだリグレッションスイート(
test-call.completedwebhook をフックし、 スコアが低下した場合はビルドを失敗させる) - 同時実行数の上限に対するストレステスト
単発実行:1 回の実行
レスポンスは、
status="queued" の テスト通話実行オブジェクト
です。status が completed または failed になるまでポーリングしてください。call_id が設定されたら、
GET /v1/calls/{call_id}/transcript で文字起こしを取得します。
バッチ:並列シナリオ
N 個のシナリオを同時に実行します。既知のすべてのエッジケースを並列でテストする リグレッションスイートに適しています。run_ids リストが含まれます。バッチステータスを取得します。
run_count の上限は 20 です。stagger_seconds は、エージェントに過度な負荷をかけないよう
起動間隔を空けます(0~60 秒)。
CI に組み込む
シミュレーションページ (/dashboard/simulations) でリリースゲート用スイートを作成します。エージェントを選択し、シナリオを手動で追加するか、AI でシナリオを生成をクリックしてエージェントのプロンプトからシナリオを下書きします(必要に応じてエッジケースの確認も可能です)。その後、それらをスイートにまとめます。
スイートには、シナリオとエージェント、最低合格率、任意の重大な失敗をゼロにするルールが固定されます。合格した実行は承認済みベースラインとなり、その後の pass→fail の移行はリグレッションとして返されます。
CI では組織 API キーを使用します。
このスクリプトはスイートをトリガーし、採点と比較が完了するまでポーリングし、判定が pass でない限りゼロ以外の終了コードで終了します。
POST /v1/orgs/{org_id}/suites/{suite_id}/run は実行 ID とともに 202 を返します。GET /v1/orgs/{org_id}/suites/{suite_id}/runs/{run_id} は
status、verdict、pass_rate、critical_failure_count、およびベースラインの
regressions リストを返します。どちらのエンドポイントも、URL の組織を API キーの組織に紐付けます。
パターン
プロンプトごとのリグレッションコーパス
{name, scenario_prompt, expected_outcome}
のタプルを含む JSON ファイルを維持します。プロンプトを変更するたびに、完全なセットをバッチとして実行し、前回の実行結果と文字起こしおよび採点を比較します。
リリースごとのスモークテスト
デプロイ後に毎回実行する、正常系シナリオ 5 件の単一バッチです。レイテンシの影響を受けやすいため、stagger_seconds: 0 を維持します。
レイテンシのベンチマーク
異なるプロダクトティア(spark、
bolt、storm-base)に対して同一のシナリオを実行します。各コールログの call.graded スコアと
duration_seconds を比較します。
次のステップ
テスト通話リファレンス
すべてのクエリパラメータ、ステータスコード、バッチ形式。
AI 採点
すべてのテスト実行を自動採点し、時間の経過に伴う品質を追跡します。
問題レポート
特定のテストに人手によるレビューのフラグを付けます。
test-call.completed Webhook
結果を CI / Slack / PagerDuty にストリーミングします。