準拠レベル
セラーはエラーハンドリングを段階的に採用できます。各レベルは前のレベルの上に構築されます:| Level | 実装する内容 | エージェントができること |
|---|---|---|
| Level 1 | すべてのエラーに code と message を返す | エラーコードで失敗を分類できる |
| Level 2 | recovery、retry_after、field、suggestion を追加する | 一時的エラーの自動リトライと修正可能なエラーの自己訂正ができる |
| Level 3 | トランスポートバインディング で MCP の structuredContent または A2A のアーティファクト DataPart にエラーを入れる | プログラム的クライアントがテキスト解析なしに型付きエラーオブジェクトを取得できる |
recovery がなければエージェントはエラーコードから推測するしかありません。Level 3 で @adcp/client のようなクライアントライブラリが完全な型付きエラーオブジェクトを提供できます。
エラーの分類
1. プロトコルエラー
AdCP ビジネスロジック外の通信・接続問題:- ネットワークタイムアウト
- 接続拒否
- TLS/SSL エラー
- JSON パースエラー
2. タスクエラー
status: "failed" で返るビジネスロジックの失敗:
- 在庫不足
- 無効なターゲティング
- 予算バリデーション失敗
- リソース未検出
recovery フィールドを確認して、リトライするか、リクエストを修正するか、エスカレートするかを判断します。
3. バリデーションエラー
スキーマ検証に失敗する不正リクエスト:- 必須項目の欠落
- 無効な型
- 範囲外の値
エラーレスポンス形式
失敗した処理はステータスfailed とエラー詳細を返します。エラーオブジェクトは error.json スキーマに従います:
エラーオブジェクトのフィールド
これらのフィールドはerror.json スキーマで定義されています:
| Field | Type | Required | Description |
|---|---|---|---|
code | string | Yes | 標準コードまたはセラー固有の機械判読用エラーコード |
message | string | Yes | 人向けのエラー説明 |
recovery | string | No | エージェントの復旧分類: transient、correctable、terminal |
retry_after | number | No | リトライまでの待機秒数(一時的エラー) |
field | string | No | エラーの原因フィールドパス(例: packages[0].targeting) |
suggestion | string | No | エラーの修正提案 |
details | object | No | 追加のコンテキスト情報 |
標準エラーコード
AdCP はerror-code.json に 20 の標準エラーコードを定義しています。セラーはプラットフォーム固有エラーにこの語彙外のコードを使用してもよいです。エージェントは未知のコードを recovery 分類にフォールバックして処理しなければなりません。
認証とアクセス
| Code | Recovery | Description | Resolution |
|---|---|---|---|
AUTH_REQUIRED | correctable | 認証が必要、または認証情報が無効 | auth ヘッダーで認証情報を提供する |
ACCOUNT_NOT_FOUND | terminal | アカウント参照を解決できない | list_accounts で確認するか、セラーに連絡する |
ACCOUNT_SETUP_REQUIRED | correctable | 使用前にアカウントのセットアップが必要 | details.setup の URL または手順を確認する |
ACCOUNT_AMBIGUOUS | correctable | 自然キーが複数のアカウントに解決する | 明示的な account_id またはより具体的な自然キーを渡す |
ACCOUNT_PAYMENT_REQUIRED | terminal | 未払い残高の支払いが必要 | バイヤーが請求を解決しなければなりません |
ACCOUNT_SUSPENDED | terminal | アカウントが停止されている | セラーに連絡して解決する |
リクエストバリデーション
| Code | Recovery | Description | Resolution |
|---|---|---|---|
INVALID_REQUEST | correctable | リクエストが不正またはスキーマ制約に違反している | リクエストパラメーターを確認して修正する |
UNSUPPORTED_FEATURE | correctable | このセラーがサポートしていない機能を要求している | get_adcp_capabilities を確認してサポートされていないフィールドを削除する |
POLICY_VIOLATION | correctable | リクエストがコンテンツまたは広告ポリシーに違反している | エラー詳細のポリシー要件を確認する |
COMPLIANCE_UNSATISFIED | correctable | 必要な開示事項をターゲットフォーマットで満たせない | 必要な開示機能をサポートするフォーマットを選択する |
インベントリと商品
| Code | Recovery | Description | Resolution |
|---|---|---|---|
PRODUCT_NOT_FOUND | correctable | 参照した商品 ID が不明または期限切れ | 無効な ID を削除するか、get_products で再探索する |
PRODUCT_UNAVAILABLE | correctable | 商品が売り切れまたは利用不可 | 別の商品を選択する |
PROPOSAL_EXPIRED | correctable | 参照したプロポーザルの expires_at が過ぎている | get_products を実行して新しいプロポーザルを取得する |
AUDIENCE_TOO_SMALL | correctable | オーディエンスセグメントが最小サイズを下回っている | ターゲティングを広げるか、より多くのオーディエンスメンバーをアップロードする |
予算とクリエイティブ
| Code | Recovery | Description | Resolution |
|---|---|---|---|
BUDGET_TOO_LOW | correctable | 予算がセラーの最小値を下回っている | 予算を増やすか capabilities.media_buy.limits を確認する |
BUDGET_EXHAUSTED | terminal | アカウントまたはキャンペーン予算を使い切った | バイヤーが資金を追加するか予算上限を増やさなければなりません |
CREATIVE_REJECTED | correctable | クリエイティブがコンテンツポリシーレビューに不合格 | セラーの advertising_policies に従って修正する |
システム
| Code | Recovery | Description | Resolution |
|---|---|---|---|
RATE_LIMITED | transient | リクエストレートを超過した | retry_after 秒待ってからリトライする |
SERVICE_UNAVAILABLE | transient | セラーサービスが一時的に利用不可 | 指数バックオフでリトライする |
CONFLICT | transient | 同時変更が検出された | リソースを再読み込みして最新状態でリトライする |
復旧分類
recovery フィールドを使ってエラーの処理方法を決定します:
| Recovery | 意味 | アクション |
|---|---|---|
transient | 一時的な失敗(レート制限、サービス停止、競合) | retry_after 後または指数バックオフでリトライする |
correctable | リクエストを修正して再送可能(無効フィールド、予算不足、クリエイティブ不合格) | リクエストを変更してリトライする |
terminal | 人の対応が必要(アカウント停止、支払い必要) | 人のオペレーターにエスカレートする |
recovery 値(前方互換性)は terminal として扱います。
リトライロジック
指数バックオフ
リトライ可能なエラーには指数バックオフを実装します:レート制限の処理
エラーハンドリングパターン
基本的なエラーハンドラー
ユーザーフレンドリーなメッセージ
技術的なエラーをユーザー向けメッセージに変換します:構造化されたエラーログ
デバッグのためにコンテキスト付きでエラーを記録します:Webhook のエラーハンドリング
Webhook 配信失敗
Webhook 配信に失敗した場合、ポーリングにフォールバックします:Webhook ハンドラーのエラー
Webhook エンドポイント内のエラーを丁寧に扱います:復旧戦略
コンテキストの復旧
コンテキストが期限切れの場合は新しい会話を開始します:部分的成功の扱い
一部のオペレーションは部分的に成功する場合があります:ベストプラクティス
- まず
recoveryを確認する — エラーの処理方法として最も信頼できるシグナルです - リトライを実装する — 一時的エラーは指数バックオフを使用します
- レート制限を尊重する —
retry_afterの値を順守します - 未知のコードを適切に扱う —
recovery分類にフォールバックします - コンテキスト付きログ — デバッグ用に
code、recovery、fieldを含めます - フォールバックを用意する — 常に代替策を持ちます(例: Webhook 失敗時のポーリング)
- terminal エラーはリトライしない — 人のオペレーターにエスカレートします
- 部分成功に対応する — 成功レスポンスの警告も処理します
次のステップ
- Transport Bindings: エラーが MCP と A2A でどう伝達されるかは Transport Errors
- Task Lifecycle: ステータス処理は Task Lifecycle
- Webhooks: Webhook エラー処理は Webhooks
- Security: 認証エラーは Security