Skip to main content
バイヤーエージェントが AdCP セラーを呼ぶとき、レスポンスは一握りのキュレーションされたプロダクトから、詳細なカード、シグナルメタデータ、プレースメント仕様を伴う完全なホールセールカタログまで及びます。このページは、AdCP が既に提供するレスポンスを適切なサイズに保つ制御 — そしてほとんどのトークン予算の懸念をプロトコル問題ではなくクライアント側の問題にするアーキテクチャの洞察 — をカバーします。

​
ワイヤーレスポンス ≠ モデルコンテキスト

最も重要な単一の点: ワイヤー上のバイトはあなたのモデルが消費しなければならないものではありません。 AdCP レスポンスは構造化データです。MCP レスポンスは structuredContent として到着します — 任意のモデルが見る前にクライアントがパースする型付き JSON。A2A レスポンスは人間可読な TextPart と権威ある DataPart をペアにします。両方のケースで、よく構築されたクライアントは完全なレスポンスを保存し、次のモデルターンをプロンプトする前にそれを投影または要約します。
エージェントが生のツール結果を変更せずにモデルコンテキストに転送している場合、修正はプロトコルではなくクライアントにあります。レスポンスを保存し、モデルが次の決定に必要なものを抽出し、後で詳細が必要なとき保存されたデータを ID で参照してください。
素朴なホストの注意点。 一部の MCP ホストは structuredContent blob 全体をそのままモデルコンテキストに渡します。ホストを制御しているなら、プロンプト前に投影してください。していないなら、下の制御が過大なコンテキストに対するあなたの主要な防御になります。

​
セラーにキュレーションを頼む — フィードを引かない

キュレーションされたおすすめを得るには、厳しい pagination.max_results を伴う buying_mode: "brief" を使います:
セラーはそのベストマッチを返します — ランク付けされ、価格付けされ、実行準備完了。これは軽量なパスです。 カタログミラーを構築していない限り buying_mode: "wholesale" を避けてください。 ホールセールはセラーの全プロダクトフィードをページ分割して列挙します。ストアフロントとフィード同期のために存在し、ディスカバリーのためではありません。エージェントが数個の良いものを見つけるために数百のホールセール結果をページ分割している場合、brief モードに切り替えてセラーにフィルタリングをさせてください。 前の brief レスポンスを反復するとき — 予算の調整、地理の絞り込み、プロダクトの交換 — は buying_mode: "refine" を使います。Refine は、ディスカバリーを一から再実行するのではなく、セラーの既存のキュレーションに作用します。

​
軽量ディスカバリーのための fields セレクター

プロダクトデータのサブセットのみが必要なとき、レスポンスを制限するため fields を渡します:
これは次のとき有用です:
  • エージェントが複数のセラーをスキャンしていて初期比較のため ID と価格のみが必要
  • product_card、product_card_detailed、placements、シグナルメタデータのような重いフィールドをスキップしたい
  • 特定のプロダクトに掘り下げる前にサマリービューを構築している
fields なしでは、セラーは完全なプロダクトオブジェクト — ビジュアルカード定義、プレースメント仕様、任意のバンドルされたシグナルメタデータを含む — を返します。複数のセラーにわたる第一段階のディスカバリーには、それは必要以上のデータです。

​
カーディナリティ制御のためのページネーション

すべての get_products モードはカーソルベースのページネーションをサポートします: レスポンス: brief と refine モードでは、エージェントが実際に推論できるオプションの数に max_results を設定します。モデルがどのみち比較するなら、5 つのキュレーションされたプロダクトは 50 より有用です。 wholesale モードでは、ページネーションがフィードをたどります。各レスポンスから cursor を渡して次のページを得ます。ミラーを維持しているなら、変更されていないフィードを完全にスキップするため wholesale_feed_versioning を確認してください。

​
配信の切り詰めフラグ

get_media_buy_delivery は、大きく成長しうる内訳配列（geo 別、クリエイティブ別、日別など）を返します。各内訳配列は、返された行が完全なセットか top-N だけかを教える兄弟の boolean フラグ — by_geo_truncated、by_creative_truncated など — を持ちます: フラグが true のとき、返された行は要求されたメトリクスで降順ソートされます — 最も重要な内訳を持ち、裾野は省略されます。これは設計上: 配信内訳はアーカイブレポートではなく最適化決定のためです。完全なデータセットが必要なら、セラーのネイティブレポート API を使ってください。

​
まとめ

トークン効率の良い AdCP 統合はこのパターンに従います:
  1. brief + fields + 厳しい max_results でディスカバリー。 初期比較に必要なフィールドのみを持つキュレーションされたプロダクトを得る。
  2. refine モードで絞り込み。 再クエリするのではなくセラーのキュレーションを反復する。
  3. 生のレスポンスをクライアント側で保存。 完全なプロダクトオブジェクトをモデルコンテキストに供給しない。重要なものを抽出し、残りを要約する。
  4. 配信をページ分割する前に切り詰めフラグを読む。 by_geo_truncated: false なら、既にすべてを持っている — フォローアップ呼び出し不要。
  5. wholesale はフィード同期にのみ使う。 ユースケースがカタログミラーリングなら、wholesale + 条件付きバージョニングが正しいツール。他のすべてには brief が安い。

get_products リファレンス

fields、buying_mode、ページネーションを含む完全なリクエスト/レスポンススキーマ。

配信レポート

内訳配列、切り詰めフラグ、ソートセマンティクス。

エージェントの通信方法

MCP 対 A2A トランスポートとレスポンスの構造。

メディアプロダクト

プロダクト構造、product_card 対 product_card_detailed、レンダリング。