主要な識別子
AdCP では用途の異なる 2 種類の識別子を使用します:context_id と task_id
| Identifier | Purpose | Lifespan | Scope |
|---|---|---|---|
| context_id | 会話・セッションの継続 | 約 1 時間 | 複数のタスク呼び出しをまたぐ |
| task_id | 特定オペレーションの追跡 | 完了まで(数時間〜数日) | 個別オペレーション |
- プロトコル層から付与(A2A は自動、MCP は手動)
- 会話履歴とセッション継続を提供
- 複数タスク呼び出し間の状態維持に使用
- タイムアウト後に失効(一般的に 1 時間)
- 非同期になり得る個別リクエストに固有
- 会話をまたいで存続
- オペレーションの進行状況を長期にわたり追跡
- タスク完了まで保持(複雑なメディアバイでは数日かかることも)
- 別の会話やセッションから参照可能
使用例
プロトコルの違い
- A2A: コンテキストはプロトコルが自動で管理
- MCP:
context_idを手動で管理する必要あり
A2A のコンテキスト(自動)
A2A はセッションをネイティブに扱うため、コンテキスト管理は不要です:MCP のコンテキスト(手動)
MCP では状態を維持するために明示的なコンテキスト管理が必要です:MCP におけるコンテキスト管理パターン
コンテキストが保持するもの
context_id はプロトコルに関わらず会話状態を保持します:
- 現在議論中のメディアバイや商品
- 検索結果と適用済みフィルター
- 会話履歴とユーザー意図
- セッション内で示されたユーザーの嗜好
- ワークフロー状態と一時的な判断
context_id ではなく task_id で追跡します。
拡張フィールド (ext)
拡張フィールドはプロトコル互換性を保ちつつ、プラットフォーム固有の機能を実現します。
スキーマパターン
Extensions appear consistently across requests, responses, and domain objects:ext オブジェクトの特徴:
- 常に 任意(必須にしない)
- 任意の有効な JSON 構造を許容
- 実装側は未知のフィールドでも必ず保持
- AdCP スキーマでバリデートしない(実装側での検証は可)
名前空間(重要)
拡張は必ずベンダー/プラットフォームごとの名前空間を用います:アプリケーションコンテキスト (context)
コンテキストは、レスポンスや Webhook でそのまま返される不透明な相関データを提供します。
主な特性
- エージェントはコンテキストを解析せず、動作に利用しない
- 呼び出し元の内部トラッキング用途のみに存在
- レスポンスや Webhook で内容を変えずに返される
Schema Pattern
コンテキストの主な用途
- UI/セッショントラッキング - 非同期処理間の状態維持
- リクエスト相関 - 分散システムでのリクエスト追跡
- 内部 ID - 内部データ構造へのマッピング
- 組織コンテキスト - マルチテナントの追跡
使い分けの指針
| Field | Purpose | Agent Reads? | Agent Modifies? |
|---|---|---|---|
context_id | セッション継続 | Yes | Yes (creates/updates) |
task_id | オペレーション追跡 | Yes | Yes (creates) |
ext | プラットフォーム固有設定 | MAY | MAY add response data |
context | 不透明な相関情報 | NEVER | NEVER |
ext を使うとき:
- プラットフォーム側でデータを解釈する必要がある
- データがオペレーション動作に影響し得る
- プラットフォーム固有の設定を表現する
- 複数オペレーションにわたりデータを残す必要がある
context を使うとき:
- 呼び出し元の内部用途に限定される
- エージェントの動作に決して影響させない
- 相関/トラッキングのみの目的である
- そのままの内容で返してほしい
ベストプラクティス
A2A の場合
- プロトコルにコンテキスト管理を任せる
- 必要に応じて contextId で会話を明示的に紐づける
- セッション管理を信頼する
MCP の場合
- 呼び出し間で context_id を必ず保持
- セッションラッパーを実装(上記パターン参照)
- コンテキストの有効期限(1 時間)に対応
- 新しいワークフローでは新規コンテキストを開始
拡張フィールドについて
- 必ずベンダーキー配下で名前空間を分ける
- 拡張仕様を十分にドキュメント化する
- 共通パターンは標準化を提案することを検討
アプリケーションコンテキストについて
- 不透明のままにし、エージェントが解釈する前提で構造化しない
- 大きなペイロードは避ける(コンテキストは全レスポンスで返される)
- 相関用途のみに使い、運用データには使わない