Amazon Ads MCPを実際に触ってみた｜認証のハマりどころと運用Tips【2026年版】

「自然言語でAmazon広告のデータを呼び出せる」と話題の Amazon Ads MCPサーバー。2026年2月のオープンベータ公開以来、業界では華々しい紹介記事が増えました。

本記事は、Amazon広告運用に携わるエンジニア／代理店担当者の視点で、実際にAmazon Ads MCPサーバーをClaude Codeに接続し、本番ワークロードで使えるところまで持っていった体験記です。セールス的な「すごい」より、「どこでハマったか」「どう回避したか」「実運用にあたって何を決めておくべきか」をまとめました。

なお、MCP（Model Context Protocol）そのものの全体像や、Amazon公式の発表内容については、別記事「Amazon Ads MCPサーバー徹底解説」で網羅的に触れています。本記事は実装サイドの体験記として、より生々しい話に絞ります。

そもそもMCPとは？運用者目線で30秒解説
セットアップ実録：認証でハマった話
動かしてみた：自然言語で広告データを分析する体験
運用上の工夫1：書き込み系はAction GateとHITLで守る
運用上の工夫2：レート制限・タイムアウトとの付き合い方
結局、このMCPサーバーは誰が使うのか？
まとめ

そもそもMCPとは？運用者目線で30秒解説

細かい仕様は他記事に譲り、運用者が押さえるべきポイントだけ短くお伝えします。

MCP（Model Context Protocol）は、ClaudeやChatGPTといったAIエージェントが、外部のツールやデータベースに安全につながるための共通規格です。Anthropicがオープンソースとしてリリースしたもので、Amazon・Google・Microsoftといった大手も対応を表明しています。

従来、AIにAmazon広告のデータを扱わせるには、運用者がAPIから値を取得しCSVをコピペするか、エンジニアがAPI連携ツールを別途構築する必要がありました。MCPはこの間に立つ「共通の差し込み口」です。MCPサーバーを1本立てておけば、Claude／ChatGPT／Geminiなど対応する任意のAIクライアントから利用できます。

運用者目線での価値はシンプルです。「先週のSPキャンペーンでCPCが急騰した上位5本を出して」とチャットで投げかけるだけで、AIが裏でAmazon Ads APIを叩いて結果をテーブルで返してくれる。Excelを開いてピボットを切り直す作業から、運用者が解放される。それがMCPの実用価値です。

そしてMCPの本領は「読む」だけにとどまりません。Amazon Ads MCPサーバーは、データ取得系のツールに加えてキャンペーン作成・広告グループ追加・キーワード入札変更・予算変更・スケジュール調整といった編集系の操作にも対応しています。たとえば次のような指示が、理論上は1往復の会話で完結します。

「商品ASIN B0XXXXXXXX の新作向けにSPオートキャンペーンを日予算3,000円で立ち上げて」 → `createCampaigns` ＋ `createAdGroups` ＋ `createProductAds` が連鎖実行
「先週ACOSが40%を超えたキーワードの入札を一律20%下げて」 → `listKeywords`（条件抽出）→ `updateKeywords`（bid一括更新）
「来週月曜から金曜は予算を1.5倍に引き上げて、土日は元に戻して」 → `updateCampaigns`（budget変更）のスケジュール実行

運用者が頭の中で組み立てているオペレーションをそのまま日本語で伝えるだけで、AIが該当ツールを選び、必要なパラメータを揃え、APIを叩く――というのがMCPの真の姿です。「分析だけしてくれるBI」ではなく、「分析から実行までを一気通貫でこなすオペレーター」として使える点が、従来のレポーティングツールと決定的に違うところです。

もっとも、この「書き込み機能」はそのまま使うと怖いのも事実です。AIが意図を取り違えて全キャンペーンの入札をゼロにしてしまうリスクは確実に存在します。本記事の後半で触れるAction GateとHuman-in-the-Loop（HITL）のような安全策と組み合わせて、段階的に書き込みを解放していく――この順序が、現時点での実用的な落としどころだと考えています。

API直叩きとの違いは、「リクエスト構造を運用者が知らなくてよい」こと。プロファイルIDの指定、エンドポイントURL、ヘッダーの組み立て、ページネーション、レート制限の制御――これらはすべてMCPサーバーとAIエージェントが裏で処理します。利用者は欲しい情報を日本語で伝えるだけです。

セットアップ実録：認証でハマった話

本記事の本題はここからです。Amazon Ads MCPサーバーは公式ドキュメントに沿えばスムーズに動く――と思いきや、現実はOAuth認証のあちこちに落とし穴が点在しています。順を追ってお話しします。

本記事はAmazon Ads Developer Portalでのアプリ登録からRefresh Tokenの取得、Claude Codeとの接続、本番運用までの全工程を自分の手で通した体験ベースで書いています。順を追って、Refresh Tokenを取得するところから始めましょう。

Refresh Tokenを取得する

Amazon Ads APIを叩くにはまずLogin with Amazon（LWA）のOAuth 2.0フローを通って、長期保管用のRefresh Tokenを取得する必要があります。Amazon Ads Developer Portalでアプリケーションを登録し、Client IDとClient Secretを取得するところまでは公式ドキュメント通りで、特に難しいことはありません。問題はその次の認可フローで、ここはブラウザ操作とcurlを組み合わせる手作業になります。

本セクションの手順は、Amazon公式の Step 1: Create an authorization grant および Authorization Grants ガイドに準拠しています。エンドポイントURLやscopeはAmazon側で更新される場合があるので、最新仕様は必ず公式ドキュメントもあわせて確認してください。

ステップ1：認可URLをブラウザで開く。redirect_uriには、Amazon Ads Developer Portalで事前に登録した「許可された返信URL（Allowed Return URLs）」のいずれかを指定します。

https://apac.account.amazon.com/ap/oa
  ?client_id=<CLIENT_ID>
  &scope=cpc_advertising:campaign_management
  &response_type=code
  &state=任意の文字列
  &redirect_uri=<許可された返信URL>

本記事はAmazon Japan（JPマーケット）の運用者を前提に解説しています。JPでは認可エンドポイントはwww.amazon.com系ではなくapac.account.amazon.comを使い、scopeもcpc_advertising:campaign_managementを指定するのが一般的です。必ず公式ドキュメントで確認してください。

ステップ2：同意画面で「許可」を押す。redirect_uriに?code=xxxxx付きでリダイレクトされるので、このcodeパラメータの値（認可コード）を控えます。このコードは数分で失効するので、ここから先は手早く進めます。

https://<許可された返信URL>/?code=SRDWxxQpvuZWkNKtRgSR&scope=cpc_advertising%3Acampaign_management

ステップ3：認可コードをトークンに交換する。次のcurlを即座に叩きます。ここから先（ステップ3以降）の作業は、すべてClaude Code内のターミナルで実行できます。ブラウザ作業はステップ2までで終わり、トークン交換・.mcp.jsonの編集・以降のトークン更新ループまで、Claude Codeに張り付いたまま完結します。

curl -X POST \
  -H "Content-Type:application/x-www-form-urlencoded;charset=UTF-8" \
  --data "grant_type=authorization_code\
&code=<認可コード>\
&redirect_uri=<許可された返信URL>\
&client_id=<CLIENT_ID>\
&client_secret=<CLIENT_SECRET>" \
  https://api.amazon.com/auth/o2/token

成功すると次のようなJSONが返ってきます。

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

このうちrefresh_token（Atzr|で始まる文字列）が今後のすべての起点になります。access_tokenは1時間で失効しますが、Refresh Tokenを使えばいつでも再発行できます。再発行は次のリクエストです。

curl -X POST \
  -H "Content-Type:application/x-www-form-urlencoded;charset=UTF-8" \
  --data "grant_type=refresh_token\
&client_id=<CLIENT_ID>\
&client_secret=<CLIENT_SECRET>\
&refresh_token=<REFRESH_TOKEN>" \
  https://api.amazon.com/auth/o2/token

ハマりポイント：認可URLのscopeに何を指定するかで、後で取れるトークンの権限範囲が決まります。「とりあえず動かしたい」と最小スコープで取得すると、後でレポートAPIを叩いた瞬間に権限エラーが返って再取得から始める羽目になるので、最初から必要なスコープを揃えておくのが無難です。

Amazon Ads API Refresh Token取得フロー：Developer Portal登録→認可URL→同意・認可コード取得→トークン交換→Refresh Token保管の5ステップ — 図1：Refresh Tokenを取得するまでの5ステップ（JP前提：APACエンドポイント／cpc_advertising scope）

Refresh Tokenを安全な場所に保管できたら、ここからはこのrefresh_tokenを使ってaccess_tokenを発行し、Claude CodeのMCPサーバーとして組み込んでいく段階に入ります。ここから先で、認証まわりの本当の落とし穴に次々とハマっていくことになります。

Claude Codeの`.mcp.json`設定例（アカウント横断 vs 特定アカウント固定）

取得したaccess_tokenは、Claude Codeのプロジェクトルートに置く.mcp.jsonに書き込みます。Amazon Ads MCPサーバーには2つの動作モードがあり、ヘッダー指定で切り替える設計になっています。

(1) Dynamic Mode：複数アカウントを横断的に扱う場合（デフォルト）

基本ヘッダー2つだけを指定すれば、ログインユーザーがアクセスできる全アカウントを横断的に呼び出せます。代理店で複数クライアントのアカウントを切り替えながら分析する場合、こちらが便利です。AIエージェントが各ツール呼び出し時にprofileIdやaccountIdをパラメータとして明示する形になります。

{
  "mcpServers": {
    "amzn-ads-mcp": {
      "type": "http",
      "url": "https://advertising-ai-fe.amazon.com/mcp",
      "headers": {
        "Authorization": "Bearer Atza|<access_token>",
        "Amazon-Ads-ClientId": "<client_id>",
        "Accept": "application/json, text/event-stream"
      },
      "timeout": 60000,
      "disabled": false
    }
  }
}

(2) Fixed Mode：特定1アカウントに固定する場合

「今週はこのクライアントの分析だけに集中したい」「事故防止のためアカウントを誤って切り替えたくない」――そんな時はFixed Modeにします。追加でAmazon-Ads-AI-Account-Selection-Mode: FIXEDと、アカウント識別子（通常はAmazon-Advertising-API-ScopeにprofileIDを入れる）を指定します。これでこのMCPサーバー越しの全ツール呼び出しが、指定アカウント1つに固定されます。

{
  "mcpServers": {
    "amzn-ads-mcp": {
      "type": "http",
      "url": "https://advertising-ai-fe.amazon.com/mcp",
      "headers": {
        "Authorization": "Bearer Atza|<access_token>",
        "Amazon-Ads-ClientId": "<client_id>",
        "Accept": "application/json, text/event-stream",
        "Amazon-Ads-AI-Account-Selection-Mode": "FIXED",
        "Amazon-Advertising-API-Scope": "<profileId>"
      },
      "timeout": 60000,
      "disabled": false
    }
  }
}

レポート系（Reporting API）を叩く場合は前述のとおりAmazon-Ads-AccountId（グローバルアカウントID）の併記も必要です。

ハマりポイント："type": "http"の指定を忘れないこと。これを省略するとClaude Codeは.mcp.jsonのエントリ自体を無視し、MCPサーバー一覧に表示すらされません。「設定したはずなのに見えない」時はまずここを疑います。

運用としては、普段はDynamic Modeで複数アカウントを横断、特定クライアントの集中作業時だけFixedに切り替える、という使い分けが扱いやすいと感じました。切り替え方法はヘッダー2行を追加／削除してClaude Codeを再起動するだけです。

つまずき1：「Malformed Request uri」という誤誘導エラー

Refresh Tokenを使ってアクセストークンを発行し、いざClaude Codeの.mcp.jsonに書き込んで起動――というところで、最初の壁にぶつかりました。MCPサーバーが返してきたのは次のエラーです。

HTTP 400: Malformed Request uri

「URIが不正？」と聞かれても、URL文字列はドキュメント通りで何も間違っていません。1時間ほど.mcp.jsonとにらめっこした後で気づいたのは、このエラーは実は「トークンが無効」であることを示しているという事実でした。

原因はこうです。Claude CodeはMCPサーバーから401を受け取ると、自動的にOAuthのディスカバリーエンドポイント（/.well-known/oauth-authorization-server）にアクセスを試みます。AmazonのMCPサーバーはこのパスをそもそも公開していないため、Amazon側で400 Malformed Request uriを返す――という仕組みでした。表示されるエラーと根本原因がまったく一致しない典型例です。

切り分け方法も学びました。MCPクライアント経由ではなく、ターミナルから直接curlでMCPエンドポイントを叩けば、原因が即時に判定できます。

curl -s -i -X POST "https://advertising-ai-fe.amazon.com/mcp" \
  -H "Authorization: Bearer Atza|<access_token>" \
  -H "Amazon-Ads-ClientId: <client_id>" \
  -H "Accept: application/json, text/event-stream" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}},"id":1}'

これで200 OK + サーバー情報が返ればトークンは有効、401が返れば失効――と一発で分かります。MCPクライアント越しのエラーメッセージに振り回されるより、まず生のHTTPで叩いて切り分ける。これが鉄則です。

つまずき2：アクセストークンは1時間で切れる

これが運用上もっとも影響の大きい仕様です。Amazon LWAのアクセストークンは1時間で失効します。失効すると当然MCPサーバーは401を返し、上記の通り「Malformed Request uri」エラーに化けます。

「Refresh Tokenを使って自動更新してくれないの？」と思うかもしれませんが、Claude Codeの.mcp.jsonはアクセストークンしか保持できない構造です。Refresh Tokenを.mcp.jsonに書いておけば自動でアクセストークンに変換してくれる、という機能はありません。

つまり、毎時間こんなフローを回す必要があります。

Refresh Tokenを使ってAmazon LWAエンドポイントにcurlでアクセストークンを再発行
新しいアクセストークンを.mcp.jsonのAuthorization: Bearer ...に上書き
Claude Codeを再起動（重要：MCPサーバーの設定はクライアント起動時にしか読み込まれない）

「自然言語で広告データを操作する未来」のはずが、現実は1時間ごとに設定ファイル書き換え→クライアント再起動。さすがに毎時間これを手作業でやるのは現実的ではないので、私たちのチームでは以下のような自動化スクリプトを組みました。

# refresh-amzn-token.py（概要）
# 1. 秘匿ファイルから refresh_token / client_id / client_secret を読み込み
# 2. Amazon LWA に POST してアクセストークンを再取得
# 3. .mcp.json の Authorization ヘッダを上書き
# 4. refresh_token がローテートされていれば秘匿ファイルも更新
# 5. ユーザーに「Claude Code を再起動してください」と通知

運用上はこのスクリプトを「401が出たら手動で呼ぶ」のと「カスタムスラッシュコマンドとして登録して/amzn-ads-refreshと入力すれば走るようにする」のと両建てで運用しています。Refresh Token自体は基本的に長期間有効ですが、Amazonが任意のタイミングでローテートするケースもあるため、スクリプト側で新しいRefresh Tokenが返ってきたら自動で保存する処理を入れておくと安全です。

Amazon Ads MCP アクセストークン更新ループ：1時間ごとにRefresh Tokenで再発行し.mcp.jsonを書き換えClaude Codeを再起動するフロー — 図2：1時間ごとに回す必要があるアクセストークン更新フロー（Claude Code再起動が必須）

つまずき3：「ヘッダー1つ足りない」で特定APIだけ落ちる

ようやくMCPサーバーへの接続が安定し、レポートAPI（reporting-create_report）を叩いてみたところ、今度は次のエラーが返ってきました。

The provided account identifier header is not supported for this tool

キャンペーン取得や検索クエリ取得は問題なく動くのに、レポート取得だけが失敗する。最初は権限の問題かと思いましたが、原因はヘッダーの違いでした。

Amazon Ads APIは歴史的にAmazon-Advertising-API-Scope（プロファイルID）でアカウントを指定する設計でしたが、新しいレポートAPI群はAmazon-Ads-AccountId（グローバルアカウントID）を要求するようになっています。プロファイルIDだけ送っていると、新APIが対応するアカウント識別子を見つけられず、上記のエラーになる、という仕組みです。

解決策は両方のヘッダーを併記すること。

"Amazon-Advertising-API-Scope": "<profile_id>",
"Amazon-Ads-AccountId": "amzn1.ads-account.g.<account_id>"

これで旧API・新APIの両方に対応できます。「全API失敗 = 認証問題」「特定API失敗 = ヘッダー or フィールド名問題」というエラー切り分けの定石が、ここで身に染みました。

つまずき4：レポートの作成は非同期。chatで頼んで即返ってこない

ヘッダー問題を乗り越えてレポートAPIを叩けるようになって最初に戸惑ったのは、Amazon AdsのレポートAPIが完全な非同期設計だったことです。「レポートをください」と頼んでも、即座にデータは返ってきません。流れはざっくりこうなります。

reporting-create_reportで生成をリクエストすると、reportIdだけが返る（中身はまだ無い）
裏でAmazon側が集計処理を走らせる――ここに数分〜十数分かかる
reporting-retrieve_reportを叩いてstatus: COMPLETEDになるのを待つ
完成後、レスポンスのcompletedReportParts.url（gzip圧縮されたS3の署名付きURL）から実データをダウンロード
gunzipで展開して中身を取り出す

「ちょっと待てば返ってくるだろう」と思っていたのですが、実測してみると期間14日 × キャンペーン数約30本のレポートで完成まで9〜15分。一度ChatGPTの感覚で「あ、ACOS悪化要因も見たい」と追加レポートを頼むと、それも同じだけ待つことになります。チャットの中で会話のリズムを保ったまま分析を進める、という体験はここでは成立しません。

面白いのは、レコード数が10件でも4,600件でも所要時間がほぼ変わらないこと。集計対象の規模より、Amazon側のジョブキュー待ちのほうが支配的なようです。「小さなレポートなら速い」が通用しないので、軽い試打のつもりで投げても10分は覚悟する必要があります。

現実的な運用としては、レポートは「頼んだら一旦忘れて別作業を進め、10分後くらいに様子を見に行く」という非同期前提の段取りに切り替えました。チャットを開きっぱなしで待つ作業ではなく、裏で走らせておくバッチ的なお願いごととして扱う、というメンタルモデルです。これに慣れるまでが、認証まわりの試行錯誤とは別の意味で時間がかかりました。

Amazon Ads MCP レポート非同期フロー：create_report→reportId返却→9〜15分の待機→retrieve_report→S3署名付きURLからgzipダウンロード→gunzip展開 — 図3：レポート非同期フロー。Amazon側ジョブキュー待ちで9〜15分かかる

動かしてみた：自然言語で広告データを分析する体験

認証まわりの試行錯誤を乗り越え、ようやくAmazon Ads MCPサーバーが安定稼働した時点で、Claude Codeのチャットに以下のようなプロンプトを投げてみました。

「プロファイルID xxxxxの過去14日間のSponsored Productsキャンペーンを、ACOSが悪い順に並べてください。ACOS 30%以上かつ広告費5,000円以上のキャンペーンだけ抽出して、テーブル形式で出してください。」

すると、Claudeは裏側で次のような流れを自動的に組み立ててくれました。

ads_accounts-list_ads_accountsでアカウント一覧を取得し、指定プロファイルを特定
reporting-create_reportで14日間のキャンペーンレポートを発行
レポート生成完了をポーリングして待機（数分）
完成したレポートをダウンロード・解凍
ACOS降順でフィルタ・並べ替え
結果をMarkdownテーブルで返答

結果は数分でテーブル形式で返ってきました。ここまでを1回のチャットプロンプトで完結させられるのは、Excel作業に慣れた身としては衝撃的な体験でした。今までだったら、管理画面にログインして、日付を指定して、CSVをダウンロードして、ピボットを切って、フィルタをかけて……という工程が、すべて自然言語1往復で済む。

続けてこんなプロンプトも試しました。

「今特定したACOSワースト5キャンペーンについて、検索クエリレポートを取得してください。コンバージョン0件かつクリックが20回以上ある検索語句をリストアップしてください。」

これも数分後にテーブルで返ってきました。「ACOS悪化キャンペーンの中で、無駄打ちしている検索語句」が、対話1回で抽出される。ネガティブキーワード追加の候補リストが、運用者の手作業ゼロで揃う。この体験を一度味わうと、過去の作業スタイルには戻りたくなくなります。

もっとも、すべてがバラ色というわけではありません。実運用には留意すべき制約がいくつもあります。

運用上の工夫1：書き込み系はAction GateとHITLで守る

そもそもAmazon Ads MCPサーバーの本領は、レポート取得ではなくキャンペーン作成・入札調整・予算変更といった編集系の操作をAIエージェントに任せるところにあります。今回はあくまでテストフェーズということで読み取り専用で触りましたが、本来このMCPは「分析から実行までを一気通貫」でこなすために設計されている、ということは強調しておきたいポイントです。

その上で大事なのは、書き込み系を本格的に使うなら、事前に十分なハーネス（安全装置）の設計をしておかないと危ないということです。AIエージェントは指示に対して善意かつ高速に動くので、ハーネスが甘いまま書き込み権限を渡すと、人間が気付く前に取り返しのつかない操作が走ります。今回触ってみた範囲で「これは必須だな」と感じたのが、特にAction GateとHuman-in-the-Loop（HITL）の2つです。

Action Gate（行動ゲート）：AIエージェントの判断とは独立した層で、ツール呼び出しそのものを機械的に許可／不許可するレイヤー。プロンプトでの「やらないでね」は容易にすり抜けられるので、行動の外側にハード制約を置く発想です。
HITL（Human-in-the-Loop）：書き込み系の実行前に必ず人間の承認を挟む仕組み。AIは提案者、人間は決裁者という役割をシステム的に固定し、入札や予算の変更は最終的に人間がボタンを押してはじめて反映される設計にします。

過去の事例：AIエージェントがマネージャーアカウントを実質「乗っ取った」結果のBAN
2025年には、ある広告主がClaude CodeをMeta Ads Managerに書き込み権限付きで直結した結果、AIエージェントが人間離れした頻度でレポート取得・予算変更・最適化を繰り返し、わずか1週間ほどでMetaに該当ビジネスポートフォリオ（マネージャーアカウント）全体を永久停止される事例が報じられました。AIに悪意はなく、むしろ「真面目に最適化した」結果としての出来事です。同年7月のReplit AI本番DB削除事件（コードフリーズ中にAIが本番データを消去）と並んで、「書き込み権限を持たせたAIエージェントが、人間の想定速度を超えて動き始めた時に何が起きるか」を象徴する出来事として業界では強く記憶されています。Amazon Ads APIで同じことが起きないとは限らないので、書き込み解禁は必ずAction Gate＋HITLとセットで設計するのが安全だと思います。

AIに入札調整を任せる未来は確実に来ますし、それこそがこのMCPサーバーが目指しているゴールです。ただし「MCPサーバーが書き込みに対応している」ことと「AIエージェントに無条件で書き込みをさせてよい」ことは別問題です。この境界線をAction GateとHITLという形で実装しておけるかどうかが、組織で安全にMCPを使うための分岐点になると感じました。

Amazon Ads MCP Action Gate + HITL 概念図：AIエージェントとAmazon Ads APIの間に許可ツールホワイトリストのAction Gateと人間承認のHITLを2層配置 — 図4：Action Gate（ツール許可リスト）＋ HITL（人間承認）の2層ハーネス

運用上の工夫2：レート制限・タイムアウトとの付き合い方

もう一つ実運用で気づいたのは、レート制限とタイムアウトの存在感です。Amazon Ads MCPサーバーは内部的に既存のAdvertising APIを呼び出すラッパー構造なので、APIのレート制限がそのまま継承されます。具体的には次のような癖があります。

レポート発行系（create_report）は3秒間隔で連続実行すると429（Too Many Requests）が返る。安全圏は1分あたり2〜3回
レポート完成までの待ち時間は、期間14日 × キャンペーン数〜30本程度で9〜15分。レコード数に関係なくほぼ一定
並列で複数レポートを発行する場合は30秒間隔を空けると安定する

こうした特性を運用者が把握していないと、AIエージェントに「先月分のレポートを全部出して」と頼んだ瞬間に裏で大量の非同期ジョブが走り、結果としてタイムアウトする・他のバッチ処理を巻き添えにする、といった事故が起こります。

運用上の鉄則は「プロンプトで取得範囲を明示する」こと。「過去14日間の」「SPキャンペーンのみ」「指定したプロファイルだけ」のように、AIに任せず人間側で範囲を絞ります。AIエージェントに「賢く判断してね」と丸投げするのは、API仕様を知っている運用者がやってはいけない悪手です。

結局、このMCPサーバーは誰が使うのか？

ここまで実装サイドの話をしてきたうえで、改めて立ち返って考えたいのが「結局このAmazon Ads MCPサーバーは、誰が日常的に使うものなのか？」という問いです。結論から言うと、現状の素のままだと、非エンジニアの一般運用者が使うにはハードルが高いと感じました。理由は主に3つあります。

Amazon Ads Developer Portalでのアプリ登録が事前に必須：Client ID／Client Secretの発行、Allowed Return URLsの設定、申請審査――この一連の手続きは、広告運用しか経験していない人にとっては馴染みのない世界です。「広告データを見たいだけなのに、なぜ自分でアプリを登録？」という心理的ハードルがそもそも高い
OAuth／refresh_tokenまわりの認証作業：本記事でここまで延々と書いてきた通り、認可URLの組み立て、認可コードの即時交換、Refresh Tokenの保管、毎時間のアクセストークン再発行、.mcp.jsonの編集、Claude Codeの再起動――これらは「ツールを使う」というより「ツールを作る」側の作業です。広告運用の本業に乗せるには遠い
cowork（Claude Codeのチーム共有機能）は未対応：個人マシン上でセットアップしたMCPは、チーム全員に展開できません。代理店で複数の運用者が同じ設定を共有する、というユースケースで詰まります。誰か1人が動かせても、組織として運用に乗せにくい

では、誰が実際にこのMCPを業務として使いこなすのか。「すでにAmazon Ads APIを利用している既存ベンダー」が、自社のハイエンドユーザー向けにMCPサーバー＋Claude Codeの環境を構築して提供する――これが、日本国内のトライアルの最初の形になるだろう、と見ています。

Amazon広告の既存ベンダー（広告自動化SaaS、レポーティングツール、運用代行プラットフォーム等）は、自社サービスにユーザーがAmazon広告アカウントを連携するタイミングで、すでに各ユーザーのRefresh Tokenを取得・保管済みだからです。アプリ登録もOAuthフローもとっくに通過済み――つまり「MCPを本格的に使うために最も時間のかかる準備工程を、すでに終わらせている事業者」が国内にすでに存在している、ということです。

具体的には、この事業者群が、自社で保管しているRefresh Tokenを使って「お客様自身のClaude CodeにAmazon Ads MCPをセットアップする作業」を代行するという形が、極めて自然な拡張になります。ユーザー側は、自分でアプリ登録もOAuthも一切やらず、普段使っているClaude CodeにベンダーがMCPを組み込んでくれた状態で受け取る。立ち上げた瞬間から「自然言語でAmazon広告データを扱える」環境ができている、というイメージです。MCPの国内普及はおそらく、まずこの「ベンダーによるセットアップ代行 × ハイエンドユーザー」のレイヤーから始まると考えています。

その先、広く一般の運用者にまで普及していくフェーズには、もう一段の進化が必要です。具体的には、広告運用に適したハーネス（Action Gate／HITL／業務UI／ビジネスデータ統合など）を完備したAIエージェントの登場です。生のMCPに自然言語で話しかけられる、というだけでは一般運用者には届きません。誰が、どんな形でそれを提供するのか――Amazon自身が広告運用専用エージェントを公式リリースするのか、既存の自動入札ツールベンダーが独自エージェントとして拡張するのか、Claudeのプラグインとして組み込まれるのか、あるいは全く新しいサービスとして生まれるのか。この問いの答えはまだ誰にも見えておらず、しばらく業界全体の動向を見守る必要があると感じています。

まとめ

本記事で共有したセットアップ体験を整理します。

Amazon Ads MCPサーバーは確かに強力だが、セットアップで認証関係に相応の時間を要する覚悟が必要
.mcp.jsonには"type": "http"の指定が必須。Dynamic Mode（複数アカウント横断）とFixed Mode（特定アカウント固定）をヘッダーで切り替える
「Malformed Request uri」エラーは誤誘導。実態は401（トークン失効）。curlで生のHTTPを叩いて切り分けるのが最速
アクセストークンは1時間で失効し、Refresh Tokenから自動再発行する仕組みを自前で組む必要がある。.mcp.json更新後はClaude Code再起動も忘れずに
レポートAPIは非同期。期間14日・キャンペーン30本程度で完成まで9〜15分。チャットの会話リズムでは進まない
レート制限と付き合うには、プロンプトで取得範囲を明示するクセが必要
書き込み系を本格的に使うなら、事前にAction GateとHITLのハーネス設計が必須
非エンジニアの一般運用者にはまだハードルが高く、国内普及はまず「既存Ads API利用ベンダーがハイエンドユーザー向けに環境構築代行する」形から始まると予想

Amazon Ads MCPサーバーは、AIエージェント時代の広告運用の入り口に立つ重要な技術です。今回の体験記が、これから自分の手でセットアップに挑戦する方の同じ落とし穴を回避するための地図として役立てば嬉しいです。

田中友章

株式会社ウブン　PdM of UbunBASE

2007年に株式会社オプトに入社し、金融業界向けインターネット広告の提案・運用を担当。株式会社電通に出向し、大手ナショナルクライアントのデジタルメディア戦略の立案と実行に従事。2012年にオプトに帰任後、DSPや広告効果測定ツールのプロダクトマネージャーを歴任。グループ会社のスキルアップビデオテクノロジーズでは取締役として動画広告のアドテクノロジー事業を推進。2020年に株式会社ウブンに参画し、Amazonレポートの自動化ツール「Ubun BASE」を立ち上げ、開発とマーケティングを統括。