Amazon広告を運用していると、「昨日のレポートを見て翌日に入札を直す」だけでは、予算切れや時間帯ごとの需要変化に間に合わない場面があります。Amazon Marketing Streamは、こうした日中の変化を捉えるための広告データ配信の仕組みです。2026年8月28日時点のAmazon Ads公式情報を基に、できることと導入条件、AMCや通常レポートとの役割の違いを整理します。

Amazon Marketing Streamとは

Amazon Marketing Streamは、Amazon Adsのキャンペーン指標と変更情報を、1時間単位でほぼリアルタイムに配信するプッシュ型メッセージングシステムです。従来のように利用者側が一定間隔でレポートAPIを呼び出すのではなく、購読したデータセットがAWS環境へ継続的に届く設計です。

公式製品ページでは、対象はAmazon Ads APIと連携している代理店、テクノロジープロバイダー、直接広告主（ベンダーやセラー）とされています。対応地域には日本も含まれます。ただし、日本で広告を出していれば誰でも即時に使えるという意味ではありません。Amazon Ads APIアクセス、組織区分に応じた申請・承認、アカウントやデータセットごとの個別利用条件を確認する必要があります。

「ほぼリアルタイム」という言葉にも注意が必要です。Marketing Streamが届ける中心は、時間単位に集計された広告パフォーマンスや、予算消費などのキャンペーン変化です。ユーザー一人ひとりの行動を逐次送る個票イベント基盤ではありません。データの粒度と到着タイミングを確認し、日中の判断を早めるための運用データとして扱うのが適切です。

取得できるデータと主なユースケース

Amazon Ads公式ガイドでは、スポンサー広告とAmazon DSPについて、トラフィック・コンバージョン指標の時間単位の変化を取得できると説明されています。データセットや利用可能な項目は更新される可能性があるため、実装時には開発者向け資料で対象広告、指標、配信仕様を再確認します。

代表的なユースケースは次の4つです。

  1. 日中のキャンペーン管理：時間帯別のクリック率、コンバージョン率、広告費などを比較し、入札や予算の見直し候補を抽出します。
  2. 変化への応答：キャンペーンの予算切れ、予算消費の進行、ASINが広告掲載対象外になった変化などを検知し、担当者へ通知します。
  3. レポート同期：pushされたキャンペーン変更を内部のダッシュボードや運用台帳へ反映し、Amazon Ads側との情報差を小さくします。
  4. トリガー通知：重要な変化だけをSlackや社内システムへ送り、人が確認すべき対象を絞ります。

通常レポート・Amazon Ads API・AMCとの違い

通常レポートは、日次や指定期間の結果を振り返る用途に向きます。週次の評価設計や報告粒度は、Amazon広告レポートの設計記事で扱う領域です。一方、Marketing Streamは1日の途中で起きる変化を捉え、判断を早める役割を持ちます。

Amazon Ads APIは、レポート取得、キャンペーン管理、入札・予算調整などをプログラムから行うための広い入口です。Amazon Ads APIの製品群と導入の全体像に対し、Marketing StreamはそのAPIアクセスを前提に、時間単位データをpushで受け取る特定の機能です。受信と変更操作は別の責務として分け、受信したデータが自動的に広告設定を書き換えない設計にすると安全です。

AMC（Amazon Marketing Cloud）は、プライバシーに配慮したクリーンルームで、より長い期間の履歴やカスタマージャーニーを分析する用途に向きます。AMCの分析ユースケースのようなSQLによる深掘り、オーディエンス理解、長期傾向の把握が中心です。Marketing Streamは日中の即時的な監視、AMCは中長期の分析という違いがあり、競合するというより時間軸を分けて併用できます。

時間帯別入札・予算切れ通知へどう使うか

時間帯別入札へ使う場合、最初から全自動にするのではなく、観測、提案、承認、反映、検証の5段階に分ける方法が現実的です。

まず数週間分の時間単位指標を蓄積し、曜日やセール日の違いを確認します。次に、十分なクリックや注文がある時間帯だけを対象に、入札変更の候補を算出します。件数が少ない時間帯は偶然の振れが大きいため、単独の1時間だけで結論を出しません。候補は担当者が利益率、在庫、予算残高と照合し、承認した場合だけAmazon Ads APIの変更処理へ渡します。

予算切れ通知では、「予算消化率が一定値を超えた」「残り時間に対して消化が速い」といった条件を設定できます。ただし、通知と自動増額は分離します。ブランドキャンペーン、利益率の低い商品、在庫が少ないASINでは、予算追加が適切でないこともあります。通知には対象キャンペーン、観測時刻、現在値、比較基準、推奨ではなく確認事項を含めると、担当者が判断しやすくなります。

変更後は、時刻、変更前後の値、承認者、理由を監査ログへ残します。Marketing Streamだけを理由にROAS向上を断定せず、広告費、在庫、セール要因も合わせて評価します。

導入前に確認するAPI・AWS・運用体制

セルフサービスで始める場合は、Amazon Ads APIアクセスとAWS統合が必要です。すでにAPI統合がある組織は、同じアクセストークンを使ってMarketing Streamのデータセットを購読できると公式ページに記載されています。一方、直接統合する開発体制がない場合は、Amazon Adsパートナー経由の導入も選択肢です。AMCの利用条件を整理した記事と同様に、組織・アカウント・地域・契約ごとの条件を確認してください。

AWS側では、受信先、暗号化、権限、再処理、監視、保存期間を設計します。欠損や重複処理を検知し、時刻とタイムゾーンを統一します。認証情報をログへ出さず、最小権限のIAMロールを使います。

運用開始前には、次を確認します。

  • Amazon Ads APIの申請・承認と対象アカウントが揃っている
  • 利用したい広告種別・データセット・指標が対象になっている
  • AWSの受信、再試行、監視、保存、障害通知を設計している
  • 自動変更の上限、承認者、停止条件、監査ログを決めている
  • 日次レポートやAMCと数値差が出たときの照合方法を決めている

小さく始めるなら、最初は受信と可視化だけに限定し、次に通知、最後に人の承認付き変更へ進めます。十分なデータ量と運用経験が蓄積する前に完全自動化すると、異常値や一時的な変化へ過剰反応するおそれがあります。

出典・参考文献

  • https://advertising.amazon.com/ja-jp/solutions/products/amazon-marketing-stream
  • https://advertising.amazon.com/ja-jp/library/guides/amazon-marketing-stream
  • https://advertising.amazon.com/ja-jp/library/guides/amazon-marketing-stream-amazon-marketing-cloud
  • https://advertising.amazon.com/about-api