> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thunderphone.com/llms.txt
> Use this file to discover all available pages before exploring further.

# エージェントをエンドツーエンドでテスト（API）

> test-calls API を使用してエージェントで定型シナリオを実行し、顧客に届く前にリグレッションを検出します。

<Note>
  ダッシュボードを使用する場合も、同じ機能を **シミュレーション**
  （`/dashboard/simulations`）で利用できます。AI シナリオ生成も含まれます。詳細は
  [通話をシミュレーションする](/ja/guides/simulate-a-call)を参照してください。このページでは
  プログラムによる方法を説明します。
</Note>

AI エージェントの改善とは、プロンプト、ツール、エッジケースの処理方法を
繰り返し改善することです。**test-calls API** は、指定したシナリオプロンプトを使用して
エージェントに対する実際の（bot-to-bot または SIP ループバック）通話を実行します。各実行では、
文字起こし、評価、課金を含む実際の通話ログが生成されるため、エージェントの動作と
コストを正確に確認できます。

用途：

* プロンプトを編集するたびに行うデプロイ前のスモークテスト
* CI に組み込んだリグレッションスイート（`test-call.completed` webhook をフックし、
  スコアが低下した場合はビルドを失敗させる）
* 同時実行数の上限に対するストレステスト

## 単発実行：1 回の実行

```bash theme={null}
curl -X POST https://api.thunderphone.com/v1/test-calls \
  -H "Authorization: Bearer sk_live_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "target_type":     "agent",
    "target_id":       12,
    "direction":       "outbound",
    "scenario_prompt": "You are a polite caller asking about refund policy for order 12345.",
    "consent_to_charge": true
  }'
```

フィールド：

| フィールド               | 型       | 必須     | 説明                                           |
| ------------------- | ------- | ------ | -------------------------------------------- |
| `target_type`       | string  | はい     | `agent` または `phone_number`                   |
| `target_id`         | integer | はい     | エージェント ID（または電話番号 ID）                        |
| `direction`         | string  | はい     | `outbound`（bot が発信）または `inbound`（bot が応答）    |
| `scenario_prompt`   | string  | いいえ    | テスト bot の発話内容を指定                             |
| `mode`              | string  | いいえ    | `bot`（bot-to-bot、デフォルト）または `sip`（SIP ループバック） |
| `consent_to_charge` | boolean | **はい** | `true` である必要があります。テスト通話の料金は通常レートの 2 倍です      |
| `target_number`     | string  | いいえ    | bot の発信者 ID（E.164）を上書き                       |

レスポンスは、`status="queued"` の [テスト通話実行オブジェクト](/api-reference/test-calls#test-call-run-object)
です。`status` が `completed` または `failed` になるまでポーリングしてください。`call_id` が設定されたら、
[`GET /v1/calls/{call_id}/transcript`](/api-reference/calls#get-transcript) で文字起こしを取得します。

## バッチ：並列シナリオ

N 個のシナリオを同時に実行します。既知のすべてのエッジケースを並列でテストする
リグレッションスイートに適しています。

```bash theme={null}
curl -X POST https://api.thunderphone.com/v1/test-call-batches \
  -H "Authorization: Bearer sk_live_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "target_type":     "agent",
    "target_id":       12,
    "direction":       "outbound",
    "run_count":       5,
    "stagger_seconds": 2,
    "scenario_prompts": [
      "Ask about refund policy.",
      "Ask for hours of operation.",
      "Complain about a delayed shipment.",
      "Ask to speak with a human.",
      "Ask an unrelated trivia question."
    ],
    "consent_to_charge": true
  }'
```

レスポンスには、子実行 ID の `run_ids` リストが含まれます。バッチステータスを取得します。

```bash theme={null}
curl https://api.thunderphone.com/v1/test-call-batches/{batch_id} \
  -H "Authorization: Bearer sk_live_YOUR_API_KEY"
```

`run_count` の上限は 20 です。`stagger_seconds` は、エージェントに過度な負荷をかけないよう
起動間隔を空けます（0～60 秒）。

## CI に組み込む

**シミュレーション**ページ
(`/dashboard/simulations`) でリリースゲート用スイートを作成します。エージェントを選択し、シナリオを手動で追加するか、**AI でシナリオを生成**をクリックしてエージェントのプロンプトからシナリオを下書きします（必要に応じてエッジケースの確認も可能です）。その後、それらをスイートにまとめます。
スイートには、シナリオとエージェント、最低合格率、任意の重大な失敗をゼロにするルールが固定されます。合格した実行は承認済みベースラインとなり、その後の pass→fail の移行はリグレッションとして返されます。

CI では[組織 API キー](/api-reference/developer-api-keys)を使用します。
このスクリプトはスイートをトリガーし、採点と比較が完了するまでポーリングし、判定が `pass` でない限りゼロ以外の終了コードで終了します。

```bash theme={null}
#!/usr/bin/env bash
set -euo pipefail

: "${THUNDERPHONE_API_KEY:?Set THUNDERPHONE_API_KEY}"
: "${THUNDERPHONE_ORG_ID:?Set THUNDERPHONE_ORG_ID}"
: "${THUNDERPHONE_SUITE_ID:?Set THUNDERPHONE_SUITE_ID}"

base="https://api.thunderphone.com/v1/orgs/${THUNDERPHONE_ORG_ID}/suites/${THUNDERPHONE_SUITE_ID}"
auth="Authorization: Bearer ${THUNDERPHONE_API_KEY}"

run_id="$(curl --fail --silent --show-error -X POST "${base}/run" \
  -H "$auth" -H "Content-Type: application/json" -d '{}' | jq -r '.id')"

deadline=$((SECONDS + 1800))
while (( SECONDS < deadline )); do
  result="$(curl --fail --silent --show-error \
    "${base}/runs/${run_id}" -H "$auth")"
  status="$(jq -r '.status' <<<"$result")"
  if [[ "$status" == "completed" ]]; then
    jq . <<<"$result"
    [[ "$(jq -r '.verdict' <<<"$result")" == "pass" ]]
    exit
  fi
  sleep 10
done

echo "ThunderPhone suite timed out" >&2
exit 1
```

`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` を比較します。

***

## 次のステップ

<CardGroup cols={2}>
  <Card title="テスト通話リファレンス" icon="flask" href="/api-reference/test-calls">
    すべてのクエリパラメータ、ステータスコード、バッチ形式。
  </Card>

  <Card title="AI 採点" icon="chart-line" href="/api-reference/calls#ai-call-grading">
    すべてのテスト実行を自動採点し、時間の経過に伴う品質を追跡します。
  </Card>

  <Card title="問題レポート" icon="triangle-exclamation" href="/api-reference/issue-reports">
    特定のテストに人手によるレビューのフラグを付けます。
  </Card>

  <Card title="test-call.completed Webhook" icon="bolt" href="/ja/webhooks/events">
    結果を CI / Slack / PagerDuty にストリーミングします。
  </Card>
</CardGroup>