Skip to main content
すべての AdCP レスポンスには status フィールドが含まれ、現在の状態と次に取るべき行動を示します。これはすべての AdCP 処理の基盤です。

ステータス値

AdCP は A2A プロトコルの TaskState enum と同じステータス値を使用します:

レスポンス構造

AdCP レスポンスはタスク固有フィールドがトップレベルにある フラット構造 です:

ステータス処理

基本パターン

確認フロー

ステータスが input-required のとき、必要な情報が message で示されます:
クライアントサイドの処理:

承認フロー

人による承認は input-required の特殊ケースです:
クライアントサイドの処理:

長時間オペレーション

非同期オペレーションは working または submitted で開始し、進捗を返します:
プロトコル別のポーリング:
  • MCP: context_id を使ってポーリング
  • A2A: SSE ストリームでリアルタイム更新を購読

ステータスの流れ

タスクは予測可能な状態を経由して進行する:
  • submitted: 実行待ち。Webhook を設定するかポーリング
  • working: 処理中。高頻度でポーリング
  • input-required: ユーザー入力が必要。会話を継続
  • completed: 成功。結果を処理
  • failed: エラー。適切に処理

ポーリングパターン

ステータス別ポーリング間隔

ステータスによってポーリング頻度を変えます:

タイムアウト処理

オペレーション種別に応じて妥当なタイムアウトを設定します:

タスク再同期

tasks/list で失われた状態を復元します:

ベストプラクティス

  1. まず status を確認 - 成功前提にしません
  2. すべてのステータスを処理 - 未知の状態も default でカバー
  3. context_id を保持 - 会話継続に必須
  4. task_id で追跡 - 特に長時間オペレーションで重要
  5. タイムアウトを実装 - 無限に待たない
  6. ステータス遷移をログ - デバッグと監査に有用

次のステップ

  • Async Operations: 異なるオペレーション種別の扱いは Async Operations
  • Webhooks: プッシュ通知パターンは Webhooks
  • Error Handling: エラー分類と復旧は Error Handling