Amazon広告のレポート自動化｜Amazon Ads APIの使い方

Amazon広告の管理画面を開いて、キャンペーン別の実績をCSVでダウンロードし、Excelに貼り直す。ASIN別のACOSを毎週手作業で追いかける。この作業は自動化できます。ただしAmazon広告の場合、Google広告のように無料の公式転送先が用意されているわけではなく、自動化の選択肢と実装の手間をきちんと理解してから進める必要があります。

もう1つ、Amazon広告の自動化で最初につまずきやすいのが「APIの呼び方」そのものです。Amazonには広告管理専用のAmazon Ads APIと、出品者・ベンダー業務向けの**SP-API（Selling Partner API）**という、名前が紛らわしい2つのAPIが存在します。広告レポートが欲しいのに、うっかりSP-APIの利用申請を進めてしまい、何日も待たされたあとに「これでは広告データが取れない」と気づく、という遠回りは避けたいところです。

この記事は、その遠回りを避けるための順路です。SP-APIとの区別からLWA（Login with Amazon）でのOAuth認証、APIアクセス申請、レポートリクエスト→ポーリング→ダウンロードという非同期取得まで、実際に動くPythonコードつきで進めます。

どのやり方で自動化するか

Amazon広告のレポートを自動で集める方法は、大きく3つです。

• 週1回程度の確認で十分・コードは書きたくない → やり方1（広告コンソールでダウンロード）
• 実装せずにBigQueryやBIツールに流したい → やり方2（BIコネクタ・ETLツール）
• 自社仕様で自由に取得したい・他システムに組み込みたい → やり方3（Amazon Ads API直連携）

GoogleのBigQuery Data Transferのような「無料で申請も実装も不要」の公式ルートがAmazon広告には無いため、無料で自動化まで持っていきたい場合は、実質的にやり方3の一択になります。まずは手軽な2つから見ていきます。

やり方1: 広告コンソールでレポートをダウンロードする

いちばん手軽な方法です。Amazon Ads（旧Seller Central内の広告管理画面、または広告主向けの管理コンソール）のレポート画面から、キャンペーン別・広告グループ別・商品（ASIN/SKU）別などの粒度でレポートを作成し、CSVやExcel形式でダウンロードできます。

画面操作だけで完結し、費用もかかりません。ただし、ダウンロードは都度の手作業になる点が弱点です。過去データを時系列で蓄積して分析したい、複数アカウントを横断して見たいといった要件が出てきた時点で、この方法は手狭になります。

やり方2: BIコネクタ・ETLツールを使う

実装をせずにBigQueryやBIツールへデータを流したい場合は、有料のコネクタ・ETLツールを使う方法があります。FivetranやSupermetricsなど、Amazon Ads（Sponsored Products/Brands/Display）向けのコネクタを持つツールが存在し、契約するだけで定期的な取り込みが動き出します。

費用は月額数千円〜数万円が相場で、後述するAPIバージョンの変更やレポート仕様のアップデートへの追随をツール側が肩代わりしてくれるのが実質的な価値です。ツールごとの料金・対応媒体の比較は広告レポート自動化ツール比較｜主要9ツールの料金・対応媒体・選び方にまとめています。

やり方3: Amazon Ads APIで自由に取得する

無料で完結し、自由度も最大のやり方です。そのぶん、申請・認証・非同期処理の実装という段取りが必要になります。

着手前に、次の3つが手元に揃っていることを確認してください。

• Amazonアカウント（開発者登録に使用。会社で管理しているものを推奨）
• 稼働中のAmazon広告アカウント
• 公開済みのプライバシーポリシーページのURL（手順2のLWAセキュリティプロファイル作成で必須です）

手順1: Amazon Ads APIとSP-APIを混同しない

最初に押さえておくべきポイントです。Amazonが提供するAPI群の中で、名前も申請の入り口も似ているために混同されがちなのが、この2つです。

広告レポートの自動化が目的なら、申請すべきはAds API側です。SP-APIを申請しても広告データは一切取得できないため、最初にどちらのAPIを触っているのか、ドキュメントのURLや申請フォームの名称で必ず確認してください。

なお現行のレポート機能は「Reporting API version 3（v3）」と呼ばれ、以前のv1/v2から仕様が変わっています。移行期にはSponsored Display・Sponsored Brandsの一部レポートがv2 APIにしか無い状態が続いた経緯があり、広告タイプによってはv3でカバーされていないレポートが残っている可能性があります。本記事のコード例はSponsored Products（v3）のみを対象としているため、SB/SDのレポートが目的の場合は、対象レポートがv3で提供されているかを実装前に公式ドキュメントで確認してください。

手順2: LWAセキュリティプロファイルを作成し、Client ID/Secretを取得する

Amazon Ads APIの認証はLWA（Login with Amazon）を使ったOAuth 2.0です。まず認証の元になる「セキュリティプロファイル」（OAuthクライアントに相当するもの）を作ります。Amazonアカウントがあれば無料で作成できます。

※以降の画面手順・ボタン名は2026年8月時点の表記（開発者向け画面は英語UI）に基づきます。UIの更新で文言や配置が変わる場合があります。

1. ブラウザで https://developer.amazon.com/ を開き、画面右上の「Sign In」からAmazonアカウント（会社で管理しているものを推奨）でログインします。初回は開発者登録画面が表示されるので、会社名・住所などを入力して登録します（登録は無料です）
2. ログイン後、Developer Console上部のナビゲーションにある「Login with Amazon」をクリックします。見当たらない場合は、LWAコンソールのURL https://developer.amazon.com/loginwithamazon/console/site/lwa/overview.html を直接開いてください
3. 「Login with Amazon Console」画面にある「Create a New Security Profile」ボタンをクリックします
4. フォームの3つのフィールドを入力します
   • Security Profile Name: OAuthの同意画面で広告主に表示される名前です。例: mycompany-ads-report（社名＋用途が分かる名前）
   • Security Profile Description: 用途の説明です。例: Amazon広告レポートの自動取得用
   • Consent Privacy Notice URL: 自社サイトのプライバシーポリシーのURLです。例: https://www.example.co.jp/privacy/
5. 「Save」をクリックします。一覧（Security Profile Management）に作成したプロファイルが表示されれば成功です
6. 一覧の該当プロファイルにある「Show Client ID and Client Secret」をクリックすると、Client ID（amzn1.application-oa2-client. で始まる文字列）とClient Secretが表示されるので、両方をコピーしてパスワードマネージャーなど安全な場所に保存します
7. 次に、OAuthの戻り先URL（リダイレクトURI）を登録します。一覧の該当プロファイル行の右端にある歯車アイコンから「Web Settings」を開き、「Edit」をクリック→「Allowed Return URLs」に手順4で使うリダイレクトURI（例: https://www.example.co.jp/oauth/callback。自社サイトの実在ページでも構いません）を入力して「Save」をクリックします

ここまでで、手元に「Client ID」「Client Secret」「登録したリダイレクトURI」の3つが揃っていればこの手順は完了です。Client Secretは第三者に渡ればアカウントを操作され得る認証情報なので、ソースコードやチャットに直書きしないでください。

手順3: Amazon AdsでAPIアクセスを申請する

続いて、Amazon Ads側でAPIの利用申請を行います。手順2のLWAセキュリティプロファイルは「鍵」を作っただけで、この申請が通って初めてAds APIの呼び出しが許可されます。

1. 申請フォームは、公式ドキュメントのApply for accessページ https://advertising.amazon.com/API/docs/en-us/guides/onboarding/apply-for-access からリンクされています。検索エンジンで「Amazon API 申請」と探すとSP-API側の申請ページに迷い込みやすいため、必ずこのドキュメントページ（URLが advertising.amazon.com/API/docs 配下であること）を経由して開いてください
2. フォームを開く前に、advertising.amazon.com に広告アカウントを持つメールアドレスでサインインしておきます
3. フォームでは、担当者名・メールアドレス（このアドレスに承認メールが届きます）・会社名・利用形態などを入力します。利用形態は自社の状況に合わせて選びます
   • Direct Advertiser: 自社の広告アカウントのデータだけを扱う場合。この記事の想定（自社レポートの自動化）はこれです
   • Tool Provider: 他社向けにツール・SaaSを提供する場合
   • 代理店（agency）区分: 代理店として複数のクライアントアカウントを扱う場合
4. 送信後は審査待ちです。承認されると、入力したメールアドレスに承認メール（英文）が届きます
5. 承認メール内の「Continue」（または「Complete your registration」といった表記の）リンクを開き、アクセス許可を割り当てるLWAセキュリティプロファイルの選択画面で手順2で作成したプロファイルを選び、「Submit」をクリックします
6. 割り当て完了の画面（またはメール）が表示されれば、手順2のClient IDでAds APIを呼び出す許可が付与された状態になります

なお、手順2でdeveloper.amazon.comにログインした開発者用のAmazonアカウントと、広告アカウントを持つAmazonアカウントは同一でなくても構いません。承認メールのリンクから、割り当てるLWAセキュリティプロファイルを選択する流れになっているためです。

承認までの期間は申請区分によって差があります。公式が所要日数を公表しているわけではありませんが、自社アカウントのみを扱うDirect Advertiserであれば2〜3営業日程度、Tool Providerやエージェンシーとしての申請では数週間かかったという報告が目安になります。申請区分をどちらにするかで審査の重さが変わる点は、スケジュールを組むうえで見落とせません。承認メールが届かない場合は、迷惑メールフォルダの確認と、広告コンソールにサインインできるメールアドレスで申請したかの確認から始めてください。

手順4: OAuthで広告主の認可を得て、トークンを取得する

APIアクセスの承認が下りたら、実際にトークンを発行するOAuthフローに進みます。先に、地域ごとにURLが異なる点を押さえてください。日本の広告アカウントは極東（FE）リージョンです。この後の手順はすべてFEのURLで進めます。

自社アカウントの自動化であれば「広告主」は自分自身なので、認可用のURLを自分のブラウザで開くだけです。ツールとして他社に提供する場合は、このURLに広告主をリダイレクトする形になります。

1. 次のURLの <Client ID> と <リダイレクトURI> を自分の値に置き換えて、ブラウザのアドレスバーに貼り付けて開きます（リダイレクトURIは手順2-7で「Allowed Return URLs」に登録した値と完全一致が必要です。URLエンコードして指定します）

   https://apac.account.amazon.com/ap/oa?client_id=<Client ID>&scope=advertising::campaign_management&response_type=code&redirect_uri=<リダイレクトURI>

   例（リダイレクトURIが https://www.example.co.jp/oauth/callback の場合）:

   https://apac.account.amazon.com/ap/oa?client_id=amzn1.application-oa2-client.xxxxxxxxxxxx&scope=advertising::campaign_management&response_type=code&redirect_uri=https%3A%2F%2Fwww.example.co.jp%2Foauth%2Fcallback

2. Amazonのログイン画面が表示されるので、広告アカウントの権限を持つAmazonアカウントでログインします。続いて同意画面（手順2-4で入力したSecurity Profile Nameが表示されます）で「許可」（英語UIでは「Allow」）をクリックします

3. 登録したリダイレクトURIに ?code=xxxxxxxxxx&scope=... というパラメータ付きで転送されます。ページの中身はエラーでも構いません。ブラウザのアドレスバーから code= の後ろの値（認可コード）をコピーします。認可コードは短時間（数分）で失効するため、すぐに次のステップを実行してください

4. ターミナルから次のcurlを実行して、認可コードをトークンに交換します（<> の4箇所を自分の値に置き換え）

   curl -X POST https://api.amazon.co.jp/auth/o2/token \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -d "grant_type=authorization_code" \
     -d "code=<認可コード>" \
     -d "redirect_uri=<登録したリダイレクトURI>" \
     -d "client_id=<Client ID>" \
     -d "client_secret=<Client Secret>"

5. 成功すると、次の形のJSONが返ります

   {
     "access_token": "Atza|IwEBI...",
     "refresh_token": "Atzr|IwEBI...",
     "token_type": "bearer",
     "expires_in": 3600
   }

   refresh_token（Atzr| で始まる値）を必ず保存してください。これが以降の自動実行の鍵になります。invalid_grant エラーが返る場合は、認可コードの失効（再度手順1からやり直し）か、redirect_uri の不一致が典型的な原因です

このOAuth同意は、広告主1人につき最初に一度だけ行えばよいプロセスです。以降はRefresh Tokenを使って、Access Tokenを都度発行し直します。Access Tokenの有効期限は3,600秒（1時間）と短いため、バッチ処理では毎回次のリフレッシュ呼び出しから始める実装が前提になります。

curl -X POST https://api.amazon.co.jp/auth/o2/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=refresh_token" \
  -d "refresh_token=<Refresh Token>" \
  -d "client_id=<Client ID>" \
  -d "client_secret=<Client Secret>"

レスポンスに新しい access_token が入っていれば成功です。

手順5: Profile IDを取得する

Amazon Ads APIのリクエストには、対象アカウント×マーケットプレイスごとに割り振られる「Profile ID」の指定が必須です。手順4で取得したAccess Tokenを使って GET /v2/profiles を呼び出し、対象のProfile IDを取得しておきます。

1. ターミナルから次のcurlを実行します（<> の2箇所を置き換え。日本アカウントなのでFEエンドポイントです）

   curl "https://advertising-api-fe.amazon.com/v2/profiles" \
     -H "Amazon-Advertising-API-ClientId: <Client ID>" \
     -H "Authorization: Bearer <Access Token>"

2. 成功すると、アクセス可能なプロファイルの配列が返ります。countryCode が JP の要素の profileId の値（数値）を控えます

   [
     {
       "profileId": 1234567890,
       "countryCode": "JP",
       "currencyCode": "JPY",
       "timezone": "Asia/Tokyo",
       "accountInfo": {
         "marketplaceStringId": "A1VC38T7YXB528",
         "id": "ENTITY1AAAAAAAAAA",
         "type": "seller",
         "name": "自社ストア名"
       }
     }
   ]

つまずきやすいのは、空配列 [] が返ってくるケースです。権限エラーではなく「リージョン違い」が典型で、日本のプロファイルはFEエンドポイント（advertising-api-fe.amazon.com）でしか返りません。NA用の advertising-api.amazon.com に投げていないかをまず確認してください。401 Unauthorized の場合はAccess Tokenの失効（1時間）を疑い、手順4のリフレッシュを実行してから再試行します。

以降のすべてのAPIリクエストには、次の3つのヘッダーが必要になります。

• Authorization: Bearer <access_token>
• Amazon-Advertising-API-ClientId: <client_id>
• Amazon-Advertising-API-Scope: <profile_id>（上で控えたProfile ID）

Profile IDの指定を忘れる、あるいは別アカウントのProfile IDを指定してしまうと、レポートが取得できない、または意図しないアカウントのデータが返るといった事故につながります。複数マーケットプレイスを運用している場合は、countryCode と accountInfo.name の組み合わせで対象を確認してから使ってください。

手順6: レポートを非同期でリクエスト・取得する

ここまでで認証の準備が整いました。最後がレポート取得本体です。Amazon Ads APIのレポート取得は非同期で、「リクエスト→ポーリング→ダウンロード」の3ステップで構成されます。1つずつ、そのまま実行できる形で示します（エンドポイントはすべて日本のFE advertising-api-fe.amazon.com）。

ステップ1: レポート生成をリクエストする

POST /reporting/reports に、レポートの種類・期間・列を指定したJSONを送ります。Content-Type がv3専用の値である点に注意してください。次のcurlは「Sponsored Productsのキャンペーン別×日別レポート（2026年7月分）」のリクエスト例です（<> の3箇所を置き換え）。

curl -X POST "https://advertising-api-fe.amazon.com/reporting/reports" \
  -H "Content-Type: application/vnd.createasyncreportrequest.v3+json" \
  -H "Amazon-Advertising-API-ClientId: <Client ID>" \
  -H "Amazon-Advertising-API-Scope: <Profile ID>" \
  -H "Authorization: Bearer <Access Token>" \
  -d '{
    "name": "sp-campaigns-2026-07",
    "startDate": "2026-07-01",
    "endDate": "2026-07-31",
    "configuration": {
      "adProduct": "SPONSORED_PRODUCTS",
      "groupBy": ["campaign"],
      "columns": ["date", "campaignId", "campaignName", "impressions", "clicks", "cost", "sales14d", "purchases14d"],
      "reportTypeId": "spCampaigns",
      "timeUnit": "DAILY",
      "format": "GZIP_JSON"
    }
  }'

主なパラメータの意味は次のとおりです。

• reportTypeId: レポートの種類。キャンペーン別は spCampaigns、ターゲティング別は spTargeting、検索語句別は spSearchTerm、広告商品（ASIN）別は spAdvertisedProduct など
• adProduct: 広告タイプ。SPONSORED_PRODUCTS のほか SPONSORED_BRANDS・SPONSORED_DISPLAY（対応状況は手順1で触れたv3移行状況に注意）
• timeUnit: DAILY（日別行）または SUMMARY（期間合計1行）。DAILY の場合は columns に date を含める
• format: GZIP_JSON（gzip圧縮されたJSON）

成功するとHTTP 200で reportId を含むJSONが返ります。この時点では status は PENDING で、まだデータはありません。

{
  "reportId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "status": "PENDING",
  "url": null
}

HTTP 400が返る場合は columns と reportTypeId の組み合わせ違反、425が返る場合は同一内容のレポートを短時間に重複リクエストしたケースが典型です。

ステップ2: ステータスをポーリングする

受け取った reportId を使って、GET /reporting/reports/{reportId} を一定間隔（30秒〜数分）で呼び出します。

curl "https://advertising-api-fe.amazon.com/reporting/reports/<reportId>" \
  -H "Amazon-Advertising-API-ClientId: <Client ID>" \
  -H "Amazon-Advertising-API-Scope: <Profile ID>" \
  -H "Authorization: Bearer <Access Token>"

status は PENDING → PROCESSING → COMPLETED と遷移します（旧v2では SUCCESS 表記）。レポートの生成は通常数分で終わりますが、公式ドキュメントでは最大3時間程度かかり得るとされており、即座には完了しません。COMPLETED になると、レスポンスのダウンロードURLフィールド（v3では url。v2では location でした）にS3の一時URLが入ります。

{
  "reportId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "status": "COMPLETED",
  "url": "https://offline-report-storage-....s3.amazonaws.com/....json.gz?X-Amz-..."
}

ステップ3: ファイルをダウンロードする

url の値に対してGETリクエストを送り、gzip圧縮されたJSONファイル本体を取得します。このリクエストにはAds API用の認証ヘッダーを付けません（理由は後述）。URLには有効期限があるため、取得したらすぐダウンロードしてください。

curl -o report.json.gz "<urlの値>"
gunzip report.json.gz
# report.json に日別×キャンペーン別の行データ（JSON配列）が展開されれば成功

3ステップ目のダウンロードURLは、Amazon Ads APIとは別扱いの署名付きURLです。旧v1/v2時代の実装では、このダウンロードURLに対してAmazon Ads APIの認証ヘッダー（Authorization 等）を付けて叩くと「複数の認証方式は併用できない」というエラーになることが報告されています。v3でも同様の運用が踏襲されている可能性が高く、ダウンロード時はAds API用のヘッダーを外してリクエストするのが安全です。

料金・制限まわりをまとめると次のとおりです。

具体的なレート上限（req/秒等）の数値は公式ドキュメントで直接確認できていません。バーストに弱く、平均レートが枠内でも短時間の連投でトークンバケットが枯渇し得る前提で、リトライ処理を組んでおくことをおすすめします。

Pythonでの実装例

Refresh Tokenを使ったAccess Token更新から、レポートのリクエスト・ポーリング・ダウンロード・ファイル保存までを1本にした、そのまま実行できるスクリプトです。事前準備は requests のインストールだけです。

# 依存ライブラリのインストール（Python 3.9以上を想定）
pip install requests

以下を amazon_ads_report.py などの名前で保存し、冒頭の4つの認証情報を自分の値に書き換えてから python amazon_ads_report.py で実行します。

"""Amazon Ads API (Reporting v3) からSponsored Productsの
キャンペーン別×日別レポートを取得するスクリプト。

実行方法:
    pip install requests
    python amazon_ads_report.py
"""

import gzip
import json
import sys
import time

import requests

# ================================================================
# ここから4つを自分の値に書き換える
# （本番運用では環境変数やSecret Managerから読み込むこと。直書きしたまま
#   リポジトリにコミットしないよう注意）
# ================================================================
CLIENT_ID = "amzn1.application-oa2-client.xxxxxxxx"  # 手順2-6で控えたClient ID
CLIENT_SECRET = "xxxxxxxxxxxxxxxx"                   # 手順2-6で控えたClient Secret
REFRESH_TOKEN = "Atzr|IwEBIxxxxxxxx"                 # 手順4-5で保存したRefresh Token
PROFILE_ID = "1234567890"                            # 手順5で控えたProfile ID（数値を文字列で）

# 日本（FEリージョン）用のURL。北米はapi.amazon.com / advertising-api.amazon.com、
# 欧州はapi.amazon.co.uk / advertising-api-eu.amazon.com に読み替える
TOKEN_URL = "https://api.amazon.co.jp/auth/o2/token"
API_BASE = "https://advertising-api-fe.amazon.com"

# 取得したい期間（YYYY-MM-DD）
START_DATE = "2026-07-01"
END_DATE = "2026-07-31"


def get_access_token() -> str:
    """Refresh TokenからAccess Tokenを発行する（有効期限は1時間）。"""
    res = requests.post(
        TOKEN_URL,
        data={
            "grant_type": "refresh_token",
            "refresh_token": REFRESH_TOKEN,
            "client_id": CLIENT_ID,
            "client_secret": CLIENT_SECRET,
        },
        timeout=30,
    )
    if res.status_code != 200:
        # invalid_grant → Refresh Tokenの値やLWAプロファイルの割り当てを確認
        raise RuntimeError(f"トークン更新に失敗: {res.status_code} {res.text}")
    return res.json()["access_token"]


def auth_headers(access_token: str) -> dict:
    """Ads API共通の3つの認証ヘッダー。"""
    return {
        "Authorization": f"Bearer {access_token}",
        "Amazon-Advertising-API-ClientId": CLIENT_ID,
        "Amazon-Advertising-API-Scope": PROFILE_ID,
    }


def retry_after_sec(res: requests.Response, default: int = 30) -> int:
    """Retry-Afterヘッダーを待機秒数として読む。

    まれに秒数ではなくHTTP日付形式で返るケースがあるため、
    intに変換できない場合はフォールバック秒数に落とす。
    """
    try:
        return int(res.headers.get("Retry-After", str(default)))
    except ValueError:
        return default


def request_report(access_token: str, start_date: str, end_date: str) -> str:
    """レポート生成をリクエストし、reportIdを返す（ステップ1）。"""
    body = {
        "name": f"sp-campaigns-{start_date}-{end_date}",
        "startDate": start_date,
        "endDate": end_date,
        "configuration": {
            "adProduct": "SPONSORED_PRODUCTS",
            "groupBy": ["campaign"],
            "columns": [
                "date",
                "campaignId",
                "campaignName",
                "impressions",
                "clicks",
                "cost",
                "sales14d",
                "purchases14d",
            ],
            "reportTypeId": "spCampaigns",
            "timeUnit": "DAILY",
            "format": "GZIP_JSON",
        },
    }
    headers = auth_headers(access_token)
    headers["Content-Type"] = "application/vnd.createasyncreportrequest.v3+json"
    res = requests.post(f"{API_BASE}/reporting/reports", headers=headers, json=body, timeout=30)
    if res.status_code == 429:
        # レート制限。Retry-Afterヘッダーに従って1回だけ再試行
        time.sleep(retry_after_sec(res))
        res = requests.post(f"{API_BASE}/reporting/reports", headers=headers, json=body, timeout=30)
    if res.status_code == 425:
        # 同一内容のレポートを短時間に重複リクエストしたケース。
        # レスポンス内に既存レポートのreportIdが含まれていれば、それを使い回せる
        raise RuntimeError(
            "重複リクエスト(425): 直前に同じ条件のレポートをリクエストしています。"
            f"レスポンス内の既存reportIdを使うか、時間を置いて再実行してください: {res.text}"
        )
    if res.status_code not in (200, 202):
        raise RuntimeError(f"レポートリクエストに失敗: {res.status_code} {res.text}")
    return res.json()["reportId"]


def poll_report(access_token: str, report_id: str,
                interval_sec: int = 30, max_wait_sec: int = 10800) -> str:
    """ステータスがCOMPLETEDになるまで待ち、ダウンロードURLを返す（ステップ2）。

    公式ドキュメントではレポート生成に最大3時間程度かかり得るとされるため、
    待機上限のデフォルトも3時間（10800秒）にしている。
    """
    headers = auth_headers(access_token)
    waited = 0
    while waited < max_wait_sec:
        res = requests.get(f"{API_BASE}/reporting/reports/{report_id}", headers=headers, timeout=30)
        if res.status_code == 429:
            wait = retry_after_sec(res, default=interval_sec)
            time.sleep(wait)
            waited += wait
            continue
        res.raise_for_status()
        data = res.json()
        status = data.get("status")
        print(f"  status={status} ({waited}秒経過)")
        if status in ("COMPLETED", "SUCCESS"):
            # v3はurl、v2はlocationにダウンロードURLが入る
            download_url = data.get("url") or data.get("location")
            if not download_url:
                raise RuntimeError(f"完了したがダウンロードURLが無い: {data}")
            return download_url
        if status in ("FAILED", "FAILURE"):
            raise RuntimeError(f"レポート生成が失敗: {data}")
        time.sleep(interval_sec)
        waited += interval_sec
    raise TimeoutError(f"{max_wait_sec}秒待ってもレポートが完成しませんでした")


def download_report(download_url: str) -> list:
    """レポート本体を取得して行のリストを返す（ステップ3）。

    ダウンロードURLはS3の署名付きURLのため、Ads APIの認証ヘッダーは
    付けない（付けると認証方式の競合エラーになる）。
    """
    res = requests.get(download_url, timeout=120)
    res.raise_for_status()
    return json.loads(gzip.decompress(res.content))


if __name__ == "__main__":
    print("1/4 Access Tokenを更新中...")
    token = get_access_token()

    print("2/4 レポートをリクエスト中...")
    report_id = request_report(token, START_DATE, END_DATE)
    print(f"  reportId={report_id}")

    print("3/4 生成完了を待機中（通常は数分、混雑時は数時間かかることもあります）...")
    url = poll_report(token, report_id)

    print("4/4 ダウンロード中...")
    rows = download_report(url)

    out_path = f"amazon_ads_{START_DATE}_{END_DATE}.json"
    with open(out_path, "w", encoding="utf-8") as f:
        json.dump(rows, f, ensure_ascii=False, indent=2)
    print(f"完了: {len(rows)}行を {out_path} に保存しました")
    sys.exit(0)

実行して 完了: 310行を amazon_ads_2026-07-01_2026-07-31.json に保存しました のような出力（行数は「日数×キャンペーン数」でおおむね決まります）が表示されれば、取得パイプラインの骨格は完成です。

これをCloud FunctionsやCloud Runなどに載せてスケジュール実行し、取得したJSONをBigQueryに書き込めば、日次でAmazon広告のデータが自動的に溜まっていくパイプラインになります。

集めたデータをAIにつなぐ

レポートが自動で集まるようになったら、次はAI分析です。もっとも手軽なのは、取得したCSVやJSONをChatGPT・Gemini・Claudeに渡して考察させる方法です。Amazon広告ではACOS（広告費用対効果）やTACOS（総売上に対する広告費比率）が主要指標になるため、プロンプトはこの指標を軸にすると精度が安定します。

添付はAmazon広告のキャンペーン別・日別実績（過去30日、Sponsored Products）です。
1. ACOSが悪化しているキャンペーンと、考えられる要因の仮説
2. 予算を増やすべき・絞るべきキャンペーンの提案
3. 今週チェックすべきポイント3つ
を、根拠となる数字を引用しながら簡潔にまとめてください。

BigQueryにデータを蓄積している場合は、「SQLで前日実績を集計→生成AIのAPIに考察を書かせる→Slackに配信」という日次パイプラインも組めます。ここで効くコツは他媒体と同じで、生データを丸投げせず、集計してから渡すことです。何万行の生ログをそのまま渡すより、キャンペーン別・日別に集計した数十行を渡すほうが、考察の精度もAPI費用も良くなります。この考え方はなぜAI時代にこそデータ基盤が必要か｜生成AIが失敗する理由で掘り下げています。

こうしたAI分析・異常検知を既製で載せたい場合は、私たちのアドヨミAIのように、広告データのBigQuery集約とAI考察をセットで提供するサービスという選択肢もあります。

実務でハマる落とし穴5つ

Amazon広告のAPI連携で、実装して初めて気づきやすいポイントを並べます。

1. APIアクセス申請の審査に時間がかかる。審査期間は申請区分で桁が変わります（手順3参照）。Direct Advertiserなら数日、Tool Provider・エージェンシーなら数週間を見込み、プロジェクトの初期段階で申請だけ先に済ませておくべきです。

2. Ads APIとSP-APIを間違えて申請してしまう。手順1のとおりです。ドキュメントのURLが advertising.amazon.com/API/docs 配下かどうかを都度確認する癖をつけておくと安全です。

3. 取得できる日付範囲（lookback）が広告タイプで異なる。v3 Reportingの公式ドキュメントでは、アドプロダクト別のデータ保持期間（data retention）として、Sponsored Productsは約95日、Sponsored Brands/Displayは約60日と案内されています。それより古いデータはAPIから取得できないため、過去データを長期で保存・分析したい場合は、APIから定期的に取得して自前のDB（BigQuery等）に蓄積し続ける設計を前提にしてください。

4. Access Tokenの失効とProfile IDの管理。Access Tokenはおよそ1時間で失効するため、都度Refresh Tokenで更新する処理が必須です。またProfile IDはアカウント×マーケットプレイスごとに個別で、指定を誤ると別アカウントのデータが返るなどの事故につながります。この2つを自動化しないバッチ処理は、遅かれ早かれ止まります。

5. ダウンロードURLへの認証ヘッダーの付け方。レポート本体をダウンロードするS3の署名付きURLに対して、Amazon Ads API用の認証ヘッダーを付けてリクエストすると「複数の認証方式は使えない」というエラーになることが報告されています。手順6のコード例のとおり、ダウンロード時だけは認証ヘッダーを外す実装にしておく必要があります。

どこまで自分でやるか：内製の限界ライン

Amazon広告1媒体だけの自動化であれば、この記事のやり方3は内製できる範囲です。ただし、GoogleやYahoo!のような「無料の公式転送」がAmazon広告には無いため、実装コストはGoogle広告のBigQuery Data Transferと比べて確実に重くなります。OAuth・非同期のポーリング処理・トークン管理をすべて自前で書く必要があるためです。

内製の限界が来やすいのは、やはり媒体が増えたときです。Google・Meta・Amazonと連携先が増えるたびに、認証方式もレポート仕様も更新頻度も違う実装を1本ずつ作り、仕様変更のたびに直し続けることになります。Meta広告のトークン管理や数値のずれ方はMeta広告(Facebook)レポート自動化のやり方｜APIからAI分析までに、外注した場合の費用相場は広告レポート自動化の費用は？ツール・代行の料金相場と選び方にまとめています。

私たちが提供しているアドヨミAIは、まさにこの「複数媒体×BigQuery集約」を肩代わりするサービスです。Google・Meta・Amazonなどの広告データをAPIで自動連携して自社所有のBigQueryに集め、前処理からAI分析・異常検知まで載せて、初期5万円・月額1.5万円〜で運用できます。この記事のやり方3とAI分析を全媒体分まとめて外注する、と考えていただくと位置づけが近いです。

まとめ：まずはAPIの区別から

持ち帰っていただきたいのは、次の3点です。

• 最初の分かれ道はAmazon Ads API（広告管理専用）とSP-API（出品者・ベンダー業務向け）の区別。申請窓口もエンドポイントも別物で、取り違えると数日単位の遠回りになる
• レポート取得は非同期の3ステップ（リクエスト→ポーリング→ダウンロード）。即時応答を前提にした実装は動かない
• 運用の生命線はトークン管理。Access Tokenは約1時間で失効するため、Refresh Tokenでの自動更新をバッチ処理の起点に置く

まずはDeveloperアカウントでLWAセキュリティプロファイルを作成し、テスト用のAccess Tokenで GET /v2/profiles を1回呼んでみるところから始めてみてください。レスポンスが返ってくれば、あとはレポートリクエストのフローに進むだけです。

複数媒体の広告レポート自動化はEvastへ

株式会社EvastのアドヨミAIは、Google・Meta・Amazonなど主要媒体の広告データをAPIで自動連携し、自社所有のBigQueryに集約する半スクラッチ型の広告レポート自動化・AI分析サービスです。

• 「Amazon広告のAPI連携で、審査やOAuth実装につまずいている」
• 「複数媒体の認証・非同期処理の保守を社内で持ち続けたくない」
• 「レポートだけでなく、AIでの分析や異常検知まで載せたい」

現状の運用の棚卸しからで構いません。1媒体・最短2週間から始められます。

→ アドヨミAIの詳細・料金を見る → 無料相談を申し込む