Skip to main content
AdCP にはアセットアップロードタスクは含まれない。クリエイティブエージェントはバイヤーに代わってファイルのアップロードを受け入れたりストレージを管理したりすることは想定されていません。代わりに、バイヤーエージェントは自分のアセットをホストし、クリエイティブマニフェストでアクセス可能な URL を提供する責任があります。 アセットがプライベートストレージ — 内部の DAM、プライベートな S3 バケット、または認証が必要なもの — に存在する場合、バイヤーエージェントはマニフェストに URL を渡す前にそれらをアクセス可能にしなければなりません。

プレサインド URL

推奨されるパターンはプレサインド URL だ。ほとんどのクラウドストレージプロバイダーは、認証ヘッダーを必要とせずに一時的な読み取りアクセスを許可する時間制限付き URL の生成をサポートしています。

仕組み

  1. バイヤーエージェントがプライベートアセットを受け取るか特定する(例: S3 のブランドロゴ)
  2. バイヤーエージェントが短い有効期限でプレサインド URL を生成します
  3. バイヤーエージェントがクリエイティブマニフェストにプレサインド URL を渡します
  4. クリエイティブエージェントが他のパブリック URL と同様にアセットをフェッチします
標準マニフェストとの唯一の違いは URL 自体です。banner_image.url にはプレサインドクエリパラメーター(X-Amz-AlgorithmX-Amz-ExpiresX-Amz-Signature)が含まれます。他のフィールドは変更なし。

プロバイダー例

有効期限のガイドライン

プレサインド URL の有効期限をワークフロー全体をカバーするのに十分な長さに設定しつつ、必要以上に長くしないようにします。

ローカルファイルのアップロード

すでにクラウドストレージに存在しないアセット——ローカルファイル、Slack の添付、メールの添付——については、バイヤーエージェントはまずそれらを自身のストレージにアップロードし、それからプレサインド URL を生成すべきです。

なぜ認証ヘッダーではないのか?

AdCP のマニフェストは、エージェント間で JSON として渡される宣言的なデータです。URL ごとの認証ヘッダーを追加すると、信頼境界をまたいでストレージのクレデンシャルを共有することになります——マニフェストに触れるすべてのシステム(クリエイティブエージェント、プレビューサービス、アドサーバー、ロギングインフラ)が、それらのクレデンシャルを安全に扱う必要が生じます。 プレサインド URL は、認可を URL 自体にエンコードすることでこれを避けます:
  • 読み取り専用アクセスで単一のオブジェクトにスコープされる
  • 組み込みの有効期限で時間制限される
  • クレデンシャルの転送が不要
  • 失効は自動(URL が期限切れになる)

関連ドキュメント