接続方法は二つあります。一つはローカルに補助ツールを入れ、クライアントが stdio 経由で呼ぶ方式。もう一つはクライアントがリモートの端点に直接つなぎ、ブラウザで認可する方式です。
コードを書かずに Claude Code で Amazon データを引く は前者です。この記事は後者を扱います。
リモートしか選べない場面
ローカルインストーラーは、クライアントと同じマシンでコマンドを実行できることが前提です。それができない状況が三つあります。
- ChatGPT のウェブ版 — ブラウザ内で動くため、インストール先のプロセスがない
- チームでの共用 — 全員に個別インストールさせたくない、キーも配りたくない
- 設定ファイルにキーを置きたくない — ローカル方式はキーをローカル設定に書き込みますが、リモート方式は書き込みません
実務上の理由は三つ目です。OAuth 接続はアカウント、選択したキー ID、現在の認証情報のフィンガープリントに紐づき、API キーそのものはクライアントに送られません。 クライアント側に漏れるキーが存在しません。
クライアント対応状況
| クライアント | リモート OAuth | ローカル stdio | 推奨 |
|---|---|---|---|
| ChatGPT ウェブ版 | 対応 | 該当なし | リモート OAuth |
| Claude Code | 対応 | 対応 | どちらでも |
| WorkBuddy | 互換時は優先 | 対応状況による | リモート OAuth |
| Hermes | Streamable HTTP OAuth の対応による | stdio の対応による | 対応時は OAuth |
Claude Code は両方通るので、前の記事でもこの記事でも構いません。他の三つは実質リモート一択です。
端点は https://ecommercedataapi.com/mcp、Streamable HTTP、OAuth 2.1 + PKCE です。
ChatGPT ウェブ版で接続する
- ウェブ設定を開き Developer mode を有効にする
- リモート MCP サーバーを追加し、上記アドレスを入力、認証は OAuth を選ぶ
- Ecommerce Data API にサインインする
- 既存のキーを選んで確認するか、明示的に作成して認可する
4 番目に引っかかりやすい点があります。キーが一つだけで既定で選択済みでも、確認操作は必要です。 認可画面が代わりに決めることはありません。
最初のプロンプトはコストゼロで
接続直後にデータ取得へ進まないでください。まずこれを送ります。
接続確認プロンプト
残高の参照のみで、呼び出しクレジットを消費しません。接続直後のクライアントに送ってください。
ecommerce_account で残りのクレジットを確認してください。有料のデータ API はまだ呼ばないでください。
残高が返れば、OAuth の完了・ツールの読み込み・アカウント紐づけの三つが一度に確認できます。しかも消費はゼロです。
サインイン要求や「ツールが見つからない」が返る場合、問題は認可側でありデータ API 側ではありません。リクエストのパラメータを触り始めないでください。
読み込まれるもの
リモート接続では 49 のツールが読み込まれます。業務 API が 45、汎用ツールが 4 です。
| 汎用ツール | 役割 |
|---|---|
ecommerce_api_search | API カタログを検索する |
ecommerce_api_describe | 特定 API の説明とパラメータを読む |
ecommerce_api_call | code と input を指定して呼び出す |
ecommerce_account | アカウントのクレジットを確認する |
覚えるのはこの四つだけです。業務 API を暗記する必要はありません。 ecommerce_api_search で探させ、ecommerce_api_describe でパラメータを読ませ、ecommerce_api_call で呼ばせます。
この経路が API パスの記憶を要求しないのは、カタログ自体が検索可能だからです。
リモート MCP 接続ドキュメントクライアント別の手順、コピー可能な設定、認可に失敗したときの確認順序課金と取り消しは別の話
課金は呼び出しに対して発生し、接続方式とは無関係です。 リモート OAuth がローカル stdio より高い/安いということはなく、同じ残高から引かれます。ecommerce_account とアカウントページは同じ数字を示します。
MCP 接続の取り消しは、REST キーの無効化ではありません。
- 設定で MCP 接続を切断 → そのクライアントからは呼べなくなるが、キー自体は REST で使える
- キーを無効化 → そのキーに紐づく MCP 接続も含めてすべて停止する
チーム運用ではこの区別が効きます。退職時に、あるクライアントの認可を取り下げるのか、キーを完全に廃止するのかを決める必要があります。
MCP が向かない場面
MCP は探索的な作業に向きます。何を調べるか決まっていない、毎回問いが変わる、といった場合です。
定期実行には向きません。 毎日回す監視フローは、モデルに毎朝どの API を使うか決め直させるのではなく、REST を直接呼ぶべきです。モデルの選択は実行ごとに完全には一致せず、定期実行に必要なのはまさにその一致です。
大量処理にも向きません。 数百件の ASIN をモデル経由で一件ずつ呼ぶのは遅く、費用もかさみます。スクリプトを書いてください。
境目はおおむね、判断するなら MCP、繰り返すなら REST です。
後者にあたるなら、Amazon データ API 完全ガイド が 46 の API を業務シーン別に分解しています。
よくある質問
開発者モードは必須ですか。 ChatGPT ウェブ版では現状必要です。他のクライアントは異なるので、各設定ドキュメントに従ってください。
OAuth を使わずキー直指定にできますか。
一部のクライアントは設定に Authorization: Bearer ヘッダーを書く代替手段に対応します。ただしそれではキーが設定ファイルに戻り、この経路の主な利点が失われます。
一つのアカウントで何台つなげますか。 複数つなげます。各接続は選択したキーに紐づき、設定画面で個別に確認・切断できます。
接続後もツールが見つからないと言われます。 接続が認可済みになっているか確認し、新しい会話を開いてください。既存の会話は新しい接続のツールを読み込みません。