Amazonは2026年2月2日、Amazon Ads MCP ServerをAPI認証済みパートナー向けglobal open betaとして発表しました。初期設定は「Amazon Ads MCP Serverとは？open betaでできること・API認証・活用条件」で解説しています。

接続後は認証・対象・API混雑・レポート条件を監視し、異常時は広告費に影響する変更を止めます。open betaではtool名より処理の役割と結果を追います。

接続後に監視する4つの層

公式のAPI連携ダッシュボード事例は、response code、product、function、resource、geography、hourでcall patternを切り分けています。MCPも4層で見ます。

層

主な監視項目

完了の目印

MCPクライアント

接続、tool応答、時間、失敗理由

期待形式の結果を受信

API

resource別4xx、429、5xx、timeout

種類と範囲を特定

認証・対象

token更新、権限、profile、region

意図した広告アカウントを参照

データ・KPI

期間、件数、通貨、時差、定義

基準レポートと整合

日次ログは初回エラー率、429、再試行、時間、行数をresource・profile・region別に残します。他社値でなく、自社通常時との差、連続失敗、行数急減を警戒します。

接続後の認証エラーを切り分ける

多くのAPIリクエストにはclient ID、access token、marketplace別profile IDが必要です。access tokenは60分で失効するため更新結果も監視します。

OAuth 2.1 for MCPでは、Public clientはClient IDのみを使い、access token失効後にブラウザで再認証します。Private clientはClient IDとClient Secretを使い、安全に保存したrefresh tokenで自動更新します。手動OAuth 2.0はrefresh tokenから更新します。

2026年7月30日以降に広告scopeで発行されたrefresh tokenは、広告主の同意日から365日で失効します。以前のtokenも取消などで無効になり得ます。invalid_grantなら連打せず書き込みを止め、再認可します。tokenとclient secretは記録しません。

profileはmarketplace別広告アカウントです。日本のendpointはFar East（FE）の https://advertising-api-fe.amazon.com です。次を確認します。

  1. access tokenを更新できるか
  2. profileが認可範囲内か
  3. marketplaceとregionが一致するか
  4. 認可ユーザーとresourceに権限があるか

第三者アプリは認可ユーザーと同水準でアクセスします。専用ユーザーを最小権限にし、退任・契約終了時の解除担当も決めます。

APIエラーとスロットリングの対応を分ける

一律に再試行すると、認証ミスの連打や結果不明の変更が起きます。

応答・状態

主な確認

初動

400 / invalid_grant

token取消・再認可

自動再試行を止める

400 / 401

client ID、token、profile、必須項目

認証を1回更新し、再失敗なら停止

403

ユーザー・アプリ・resource権限

解決まで実行しない

429

resource別の量、並列数、時刻

queue化し、上限付きbackoff

5xx / timeout

処理の完了有無

回数限定で再試行。書き込みはreadback

2xxだが空・急減

profile、region、期間、filter、pagination

正常とせず基準値と比較

429はresourceと時間帯で見る

Amazon公式GitHubのEvents APIサンプルは429・5xxで待機を延ばしますが、秒数・回数は全Ads API共通ではありません。resource別に集計し、並列と重複jobを減らし、上限超過分は次の運用枠へ送ります。

初回失敗と再試行後成功を分け、response codeとhourからresource集中か広域障害か判断します。

異常時はread-onlyへ止めて段階復旧する

read-onlyは製品機能でなく、自社が書き込みtoolを止める運用状態です。認証連続失敗、対象不明、429・5xx急増、結果不明、行数急減で切り替えます。

  1. campaign、budget、bid、targeting変更を停止
  2. 秘密情報を除く証跡と未確定jobを保全
  3. token、権限、profile、regionを最小の読み取りで確認
  4. 1つのprofile・固定期間を基準exportと比較
  5. pagination、通貨、時差、行数、指標定義を確認
  6. 人が承認し、小さな1件を実行して前後をreadback
  7. 監視値が戻ったらqueueを段階的に開放

書き込みのtimeout時は再実行せず、現在値と履歴から未実行・実行済み・結果不明に分けます。重複を防げなければ人の確認まで停止します。

証跡ログとKPIの正しさを別々に確認する

証跡には時刻、環境、tool、read/write、profile、region、resource、HTTP status、service error、再試行、行数、入力条件hash、承認者、変更前後、readbackを残します。token、secret、認可URL、個人情報、不要な生データは残しません。

判定は次の3つに分けます。

  • 接続正常性: APIへ到達し、期待形式で応答したか
  • データ完全性: profile、期間、全ページ、通貨・時差が正しいか
  • KPI妥当性: ACOS・ROAS・CTR・CVRの定義と比較条件が合うか

APIが200でも期間・profileが違えばKPIは誤ります。固定条件のcontrol reportで行数と主要合計を管理画面か保存済みexportと照合します。設計は「Amazon広告レポート設計と改善ロードマップ」、指標は「Amazon広告のROAS目安｜CTR・CVR・ACOSの見方」も参照してください。

Amazon Ads MCP Serverの運用設計を相談する

監視、権限分離、read-only停止、レポート照合、変更承認を自社だけで設計しにくい場合は、GoalTechのAmazon広告・AI活用支援をご確認ください。

出典・参考文献

※提供状況、tool、endpoint、認証・rate limitは変わり得ます。実装・復旧時は最新公式情報と自社アカウントを確認してください。