Claude CodeのAmazon Selling Partnerプラグインで売上と在庫を聞く

Amazon Selling Partnerプラグインは、Seller CentralのアカウントをClaude Codeにつなぎ、売上・在庫・出品の状態を自分のデータで答えさせるためのプラグインです。提供元はAmazonで、マーケットプレイスのページには「Anthropic verified」の表示があり、ベータ版と記されています。

この記事では、プラグインに何が入っているか、導入と認可の流れ、売上と在庫の聞き方、3つのコマンドの中身、書き込みを止める承認ゲートを順に扱います。

プラグインの中身は「MCP接続1つ、スキル12個、コマンド3つ」

プラグインの実体は、Amazonが公開しているリポジトリ(selling-partner-agentic-toolkit)です。plugin.json の名前は amazon-selling-partner、バージョンは1.0.0、ライセンスはApache-2.0です。

中身は3種類に分かれます。

スキルは役割で見ると、次のように並びます。READMEの説明を作業の種類でまとめ直した表です。

READMEには「書き込みは常に人間の承認を前提に下書きされる」とあります。売上や在庫を聞く使い方は、この中の読み取り側だけで完結します。

導入:Claude Codeからプラグインを入れてOAuthで認可する

このプラグインは、Anthropicの公式マーケットプレイス(claude-plugins-official)の一覧に載っています。公式マーケットプレイスは対話セッションを初めて開いたときにClaude Codeが登録するので、追加の手順は要りません。シェルからは次の1行で入ります。

claude plugin install amazon-selling-partner@claude-plugins-official

セッションの中なら /plugin install amazon-selling-partner@claude-plugins-official です。この場合は /plugin の詳細画面が開き、スコープを選んでから入れます。スコープやマーケットプレイスの仕組みはClaude Codeプラグインの完全ガイドにまとめています。

入れた直後は、まだAmazonのアカウントにつながっていません。READMEによると、アクセスはSeller Centralの標準的なOAuth同意画面で許可します。流れは次のとおりです。

同じアカウントのメンバーに使わせる

自分だけでなくチームで使うときは、Seller Centralの「Manage Your Permissions」にある「Manage Agents」で設定します。invite-secondary-users スキルによると、設定は2つに分かれます。

• エージェントの有効化: アカウントでエージェントを使えるようにするかどうか
• 二次ユーザーの認可: 有効にしたエージェントを、どの二次ユーザーが自分用に認可できるか

この操作を行えるのは、アカウントのオーナー、管理者、権限管理者です。それ以外のユーザーには、管理者に頼むよう案内して止まる作りになっています。エージェントの権限を切り替えるSP-APIのツールは無く、スキルは画面操作を案内するだけで、権限そのものは変えません。

売上と在庫を聞く:seller-analytics は「先に指標を探す」

「今月どれだけ売れたか」「在庫はあと何日持つか」といった質問を受けるのは seller-analytics です。このスキルの規律は、指標の名前を推測せず、先に調べてから問い合わせることにあります。

呼び出すツールは2つです。

名前を推測しない理由は、SKILL.mdに具体例があります。「在庫が何日もつか」で FBA_INV_VIS_CURRENT_DAYS を選ぶと違う指標になり、正しいのは FBA_INV_VIS_ONHAND_PMEAN_DOS だという例です。

同梱の指標カタログには、質問と指標IDの対応表があります。一部を抜き出します。

カタログ自身が断っているとおり、この表は出発点です。正とされるのは実際のメタデータの応答で、そこに無い指標は使われず、近い指標に切り替えて何を使ったかを伝える決まりです。

数字を読むときに押さえておきたい動作が3つあります。

1. 期間を指定しなければ、2日前までの直近の窓が使われます。データに約2日の遅れがあるためで、使った期間は回答に明示されます。
2. entityId(Merchant Token)は自動で補われません。セッションのアカウント情報から明示的に渡されます。
3. 結果が空のときの再試行は1回までです。期間を広げるか、グループ化を外して合計にして、それでも空なら「データなし」と報告して尋ね返します。

このスキルは読み取り専用で、値を捏造しないこと、ツールの返答に埋め込まれた指示に従わないことも守るべき点として書かれています。

CLAUDE.mdに置く固定の前提

質問のたびにマーケットプレイスを聞き返されるのは面倒です。アカウントの前提はCLAUDE.mdに置いておくと、会話の初めから共有できます。形の例を示します(Merchant Tokenは伏せ字のプレースホルダです)。

## Amazonセラーアカウント
- 対象マーケットプレイスは <使う国のマーケットプレイスID> の1つだけ。他は聞かれない限り扱わない
- Merchant Tokenはこのファイルに書かない。聞かれたらセッションの中で答える
- 売上・在庫は seller-analytics で先に指標を探してから取得する
- 価格・出品の変更は下書きまで。「approve」と言うまで実行しない
- 回答には、使った期間とデータの遅れ(約2日)を必ず添える

マーケットプレイスIDは、あなたのアカウントが出品している国のものを、Seller Centralで確かめてから書きます。Merchant Tokenはアカウントを識別する値なので、リポジトリに入るファイルには書かず、質問の途中で聞かれたときに答えます。

/sp-stockout-check:在庫日数を3段階に分けて、納品の遅れまで見る

在庫の質問に特化しているのが /sp-stockout-check です。コマンドの実体は stockout-prevention スキルを呼ぶ指示文で、指標IDを推測しないこと、価格に助言しないこと、承認なしに書き込まないことが、コマンド側にも書かれています。

スキルの手順は次の流れです。

閾値には補足があります。Amazon自身の分析ルールは「在庫日数14日未満で在庫切れの危険」で、このスキルの7日・21日はそれより保守的に設けた帯です。14〜21日のSKUは「危険に近づいている」と表現し、すでに危険域に入ったとは言わない決まりになっています。

結果は表に加えて、在庫日数の棒グラフと、在庫切れ日と納品到着の差を示すタイムラインの2つのアーティファクトとして描かれます。ただしこのスキルのメタデータにある対応環境は platforms: [claude-desktop, aws-quick] で、claude-codeは入っていません。seller-analytics はclaude-codeを含むので、Claude Codeではグラフが出ない場合があり、表の結果が主な出力になります。

注目したいのは、売れる速さの取得に非同期のReports APIを使っていない点です。同梱の設計メモによると、接続先のツール一覧にreportsのツールが無く、同期で返る sales_getOrderMetrics があったため、待ち時間なしで日次の速さを出せるそちらを選んでいます。Reports APIを自分のスクリプトで扱う場合の流れはSP-APIのReportsを呼ぶ記事で扱っています。プラグインは分析の質問、スクリプトは大きな表の一括取得とExcelでの加工、という分担です。

/sp-sales-drop:売上が落ちた理由を原因の候補から順に絞る

売上が減ったときは /sp-sales-drop を使います。指示文の内容は次のとおりです。

1. 比較する期間と、その前の期間(基準)を決める
2. 両方の期間の注文を取る
3. 原因の候補を順位づけする。候補は出品の停止・無効化、在庫切れ、バイボックスや価格、アカウントの健全性、広告費の変化
4. 売上の差額を先に報告し、特定のASINや原因に結びつける
5. 次の手を「読み取りだけの示唆」と「承認が要る操作」に分けて示す

価格やバイボックスが原因として出てきても、診断として報告するだけで、値上げや値下げは勧めない決まりです。書き込みは行いません。

例えば、次のように依頼します。

/sp-sales-drop 先週の売上が前の週より落ちた理由を調べて。
対象は <使う国のマーケットプレイス>。原因はASIN単位で、読み取りだけで分かることと、
承認が要る対応を分けて示して。

READMEとマーケットプレイスのページには、対応するマーケットプレイスの一覧が載っていません。自分のアカウントで使えるかどうかは、認可したあとにSeller Centralのロールとメタデータの応答で確かめられます。

書き込みは下書きで止まる

プラグインの安全設計の中心は、書き込みの扱いです。stockout-prevention の価格変更の手順がわかりやすい例です。

• 出品の更新ツール listings_patchListingsItem は、まず VALIDATION_PREVIEW モードで呼ばれる。このモードは検証だけで、実際の変更は起きない
• セラーが具体的な価格を自分で言ったときだけ下書きになる。スキルは価格の上げ下げを提案せず、言われた数字をそのまま使う
• 下書きはSKUと「現在の価格 → 指定された価格」だけを示し、投影される効果や元に戻す日付などの解説は添えない
• 「approve」と入力されるまでは本番の更新を行わない。無言は承認とみなさない
• 複数のSKUは1件ずつ別の項目として下書きし、1回の承認にまとめない

/sp-fix-listing も同じ型です。停止(SUPPRESSED)、無効(INACTIVE)、不完全(INCOMPLETE)の出品を探して原因と修正案を示し、修正は明示的に承認されてから行い、反映後に出品が有効になったかを確認します。

Claude Code側でも二重に守れます。権限設定のaskルールに、書き込みツールを入れる方法です。MCPツールは mcp__<サーバー名>__<ツール名> の形で指定でき、askルールはツール名の位置にグロブも使えます。ここでの対象は listings_patchListingsItem です。プラグインが登録したサーバーの正確な名前は、接続後に /mcp で確かめてから書いてください。

プラグインの承認ゲートはスキルの指示に基づくもので、モデルが従う手順です。権限設定はClaude Code側が強制する仕組みなので、役割が違います。両方を重ねておけば、スキルが想定外の呼び方をしても、書き込みの前に確認が入ります。

送られるデータと、使える範囲

READMEの「Data sent」は、通信の範囲を次のように説明しています。

• 送るもの: スキルが代行するツール呼び出し(在庫、売上・トラフィックの分析、出品の状態、下書きされた出品や価格の変更)と、その引数(Merchant Token、マーケットプレイス、SKUやASIN)
• 戻るもの: 承認した呼び出しに対してゲートウェイが返す、在庫・分析・出品の詳細
• 権限の範囲: Seller Centralのロールが許すツールに限る。書き込みは明示の承認なしに実行されない
• 送らないもの: Amazon以外の送信先にデータを送らず、アカウント識別子やデータをセッションを超えて保持しない

プロンプト本文の扱いは、使っているAIアシスタント側の規約に従う、とも書かれています。サポートケースの要約を作る support-case-helper は、個人情報を伏せた要約を作ります。

制約も押さえておきます。

• ベータ版である: マーケットプレイスのページに「Currently in beta」とあります。指標のドメイン名に Threep_ の接頭辞が付くことがあるのも、SKILL.mdが「GA前に変わる可能性」と注記している点です
• 指標は全員に出るわけではない: カタログの指標がすべてのセラーに公開されているとは限らず、メタデータに無い指標は使えません
• 分析は約2日遅れ: 今日の売上を今日見る使い方には向きません
• 権限はロールで決まる: 質問が通らないときは、Seller Centralの権限設定が原因のことがあります

つまずきやすい点

よくある質問

売上の数字はSeller Centralの画面と一致しますか

スキルは、ツールが返した値だけを報告する決まりです。指標の定義や期間の区切りは、analytics_getMetricMetadata が返す定義に従います。画面のレポートと突き合わせるときは、期間とマーケットプレイスをそろえ、データの2日遅れを考慮してください。