Selling Partner API

Amazon は、サードパーティの販売者やサプライヤーがプログラムでストアデータにアクセスできるように、REST アーキテクチャに基づいたプログラミングインターフェイスを公式に提供しています。

APIサービス

https://developer-docs.amazon.com/sp-api/

公式サイトへ

詳細レポート

Selling Partner API (略して SP-API) は、Amazon が公式に提供する REST アーキテクチャに基づいたプログラミングインターフェイスです。これは、サードパーティの販売者やサプライヤーが、注文、在庫、支払い、広告などの中核的なビジネス情報を含む店舗データにプログラムでアクセスできるように設計されています。この API は、Amazon が 2020 年に開始した MWS (Amazon Marketplace Web Service) の後継であり、サードパーティ開発者に対する Amazon のサポートの新たな段階を示します。現在、Amazon 販売者の 4 分の 3 以上が販売関連事項の処理にサードパーティソフトウェアを使用しており、SP-API は電子商取引自動化ツールエコシステムの技術インフラストラクチャとなっています。
販売パートナー API は Amazon によって正式に開発および保守されており、Amazon Developer Services の一部です。この API は、2024 年 9 月 30 日に正式に廃止された、以前広く使用されていた MWS (Marketplace Web Service) を置き換えるために開始されました。SP-API は、最新の RESTful 設計原則に基づいて構築され、JSON 形式でのデータ交換をサポートし、C# や Java などの主流のプログラミング言語のクライアントライブラリを含む、開発者が使用できる SDK スイートを提供します。市場でのポジショニングの観点から、SP-API は主に 3 種類のユーザーグループをターゲットとしています。1 つは、店舗運営プロセスの管理を自動化する必要がある Amazon のサードパーティ販売者です。 2 番目は、Amazon ベンダー (ベンダー) で、注文書と在庫管理に使用されます。 3 つ目は、ソリューションプロバイダー (ソリューションプロバイダー)、つまり、Amazon 販売者のニーズに合わせた ERP およびツールソフトウェアを開発するサードパーティテクノロジー企業です。 Amazon は、Seller Platform Partner Network (Amazon Partner Network) を正式に設立し、認定パートナーが SP-API を使用して構築されたアプリケーションを公開できるようにしました。技術アーキテクチャレベルでは、SP-API は OAuth 2.0 認証モデルを採用しています。開発者はまずAWSアカウントを登録し、開発者情報を申請した後、セラーセントラルでアプリケーションを作成して認可を取得する必要があります。アクセスプロセス全体は 2024 年に最適化されます。新しく登録した開発者は、AWS 開発者アカウントを個別に申請する必要はなくなり、セラーセントラルのアプリケーション登録を完了するだけで済みます。
SP-API は、Amazon 販売者のビジネスプロセス全体をカバーするインターフェイス機能を提供します。公式ドキュメントによると、API には数十のセグメンテーションエンドポイントが含まれており、主な機能モジュールには次のディメンションが含まれています。注文管理の点では、Orders API を使用すると、開発者は注文リスト、注文の詳細、注文製品情報、注文住所データを取得でき、時間範囲、注文ステータス、その他の条件によるフィルタリングをサポートします。出荷 API は、出荷の作成、出荷ステータスのクエリなど、出荷情報の管理に使用されます。フルフィルメント by Amazon (FBA) を使用する販売者向けに、在庫 API はリアルタイムの在庫クエリと在庫管理機能を提供します。製品カタログの管理に関しては、Catalog Items API と Listings API をそれぞれ製品カタログ情報のクエリと製品リストの管理に使用します。 Product Pricing API は、製品価格のクエリ機能を提供し、競合他社の価格監視と動的な価格設定戦略の実装をサポートします。レポート作成とデータ取得は、SP-API の中核機能の 1 つです。 Reports API は、在庫レポート、販売レポート、広告レポート、財務調整レポートなど、複数の種類のレポートの生成をサポートします。開発者は、データ分析用のレポートデータを定期的に取得できます。フィード API は、商品情報や価格在庫などを一括で更新するなど、データを一括でアップロードするために使用されます。財務調整の観点から、Finances API は、販売収益、プラットフォーム料金、広告支出、返金額などを含む詳細な財務データを提供し、販売者の財務会計にデータサポートを提供します。さらに、出荷請求書 API は出荷請求書の処理に使用され、メッセージング API は購入者への通知メッセージの送信をサポートします。ブランド販売者は、A+ Content API を使用してブランドコンテンツをプログラムで管理し、商品詳細ページの表示効果を向上させることができます。 Easy Ship API と Merchant Fulfillment API は、それぞれ Easy Ship 配送サービスと販売者の自己配送シナリオをサポートします。ユーザーエクスペリエンスの観点から、SP-API は以前の MWS と比較して大幅なアップグレードを実現しました。 1 つ目はデータの適時性です。注文などの重要なデータは、通常のプルではなくプッシュメカニズムを使用し、情報のリアルタイム性を確保します。 2 つ目はインターフェースの安定性です。 SP-API は、完全なバージョン管理と変更通知メカニズムを提供します。次にセキュリティです。 OAuth 2.0 認証モードは、古い MWS キー認証よりも安全で柔軟です。ただし、SP-API の使用には一定のしきい値があります。開発者はプログラミングスキルを持っている必要があり、ドッキングプロセスには AWS 登録、開発者アプリケーション、アプリケーション作成、権限の取得などの複数のリンクが含まれます。さらに、API エンドポイントごとに異なる使用制限 (レート制限) があり、大規模なデータ処理には呼び出し戦略の合理的な設計が必要です。
公開情報によると、Amazon は 2025 年 11 月に SP-API の価格体系を発表し、2026 年 2 月 11 日にプレミアムパッケージを発売しました。価格体系の変更により、ソリューションプロバイダーからのフィードバックが発生し、この料金体系により事業計画と予測が複雑になるとの意見がありました。ほとんどの中小規模の販売者にとって、サードパーティソフトウェアを介して SP-API を使用することは、より経済的なオプションです。市場には、ERP システム、在庫管理ソフトウェア、価格設定ツールなど、SP-API に基づいて構築された多数のサードパーティツールが存在します。これらのソフトウェアは通常、サブスクリプションベースの課金モデルを採用しています。販売者は、月々のソフトウェア料金を支払うだけで、独自のインターフェイスを開発することなく、これらのツールを通じて SP-API の機能を間接的に使用できます。業界調査によると、Amazon 販売者の 4 分の 3 以上が、商品情報管理、自動価格設定、配送管理、データ分析などの販売関連事項の処理にサードパーティソフトウェアを使用しています。これは、SP-API の価値が主にサードパーティソフトウェアエコシステムを通じて最終販売者に移転されることを示しています。
業界からのフィードバックから判断すると、SP-API は販売者の間で高い評価を得ています。 Amazon が公式に提供するインターフェイスである SP-API には、サードパーティのデータ取得方法に比べて明らかな利点があります。データソースは合法かつ準拠しており、アカウント関連付けのリスクはありません。データは非常に正確で、Amazon の公式データベースから直接取得されます。データはタイムリーであり、スケジュールされたプルではなくリアルタイムのプッシュをサポートします。 SP-API を使用する一般的なアプリケーションシナリオには、複数のストアの統合管理が含まれます。販売者はサードパーティの ERP を通じて複数の Amazon ストアを同時に管理できます。自動価格調整、自動レビューリクエスト、自動出荷通知などの運用自動化。財務調整の自動化、財務会計のための販売データのリアルタイム同期。広告管理、広告戦略のプログラムによる調整。否定的なフィードバックは主にいくつかの側面に焦点を当てています。まず、アクセスのしきい値が高く、技術開発能力が必要です。 2 番目に、一部の API エンドポイントの呼び出し割り当ては制限されており、大規模な販売者はより高い割り当てを申請する必要がある場合があります。第三に、価格構造が調整された後、サードパーティソフトウェアプロバイダーのコストがエンドユーザーに転嫁される可能性があります。
業界観察の観点から見ると、SP-API の開始は Amazon Seller Services エコシステムに大きな影響を与えました。販売者ツールの分散化からプラットフォーム化への進化を促進し、多くの専門的な電子商取引 SaaS 企業を生み出しました。技術動向としては、AI技術の発展に伴い、SP-APIと生成AIの組み合わせが進んでいます。 AWS は、大規模な言語モデル機能を使用して、注文データのインテリジェントな分析や運用上の洞察の生成など、SP-API アプリケーションを強化する方法に関する関連する規範的ガイダンスを正式にリリースしました。2026 年 4 月の最新アップデートでは、Amazon が SP-API と AI 機能の緊密な統合を推進していることが示されています。競合他社に関して言えば、SP-API の主な代替手段には、他の電子商取引プラットフォームの API (Shopify API、eBay API など) や一般的な電子商取引データ集約サービスが含まれます。ただし、Amazon プラットフォームに重点を置いている販売者や開発者にとって、SP-API は最も権威があり信頼できるデータソースです。
データコンプライアンスの観点では、世界的にデータ保護規制（GDPRや中国の個人情報保護法など）が強化される中、SP-APIを通じて販売者データを取得するサードパーティソフトウェアのコンプライアンスが注目されています。開発者と販売者は、データ処理プロセスが関連する規制要件に準拠していることを確認する必要があります。技術的なリスクという点では、API の変更は既存のアプリケーションの安定性に影響を与える可能性があります。 Amazon はバージョン管理と変更通知メカニズムを提供していますが、開発者は引き続き API の更新に注意を払い、タイムリーにコードを調整する必要があります。 2022 年 1 月以前のバージョン変更記録の履歴については、GitHub リポジトリのお知らせを参照してください。ビジネスリスクの観点から見ると、Amazon はプラットフォーム当事者として API を完全に制御しています。 API アクセスポリシーまたは価格が将来調整される場合、SP-API に依存するサードパーティソフトウェアエコシステムに重大な影響を与える可能性があります。 2025 年末の価格構造調整はすでに業界の議論を引き起こしています。
販売パートナー API は、次のユーザーグループに適しています。効率を向上させるために運用プロセスを自動化する必要がある、1 日あたりの平均注文数が多いプロの販売者。複数の顧客店舗を同時に管理する必要があるEC運営会社。 Amazon データに基づいて SaaS 製品を構築することを計画している e コマースツール開発者。 Amazon データを内部システム (ERP、財務システムなど) と統合する必要がある企業。一般の個人販売者にとって、サードパーティソフトウェアを直接使用することは、通常、より現実的な選択です。 Seller Wizard、Shukoborder、Yicang など、すでに成熟したツールが市場で入手可能です。これらのツールは SP-API と統合されており、販売者は毎月サブスクリプションするだけで使用できます。技術的な能力のある開発者は、Amazon の公式ドキュメントを注意深く読んで、完全なアクセスプロセスとインターフェイスの仕様を理解することをお勧めします。 AWS 公式ブログでは、2024 年 8 月に最新のドッキングプロセスガイドが公開されており、非常に貴重な参考資料となります。さらに、GitHub の amzn/delivery-partner-api-models リポジトリでは、クライアントコードを迅速に生成するために使用できる Swagger モデルファイルが提供されています。
販売パートナー API は、Amazon が公式に提供する中核となるデータインターフェイスであり、Amazon 販売者サービスエコシステムの技術インフラストラクチャとなっています。これは販売者と開発者に合法的で効率的かつ安定したプログラムによるアクセス機能を提供し、電子商取引の自動化とデータ分析の重要な基礎となります。 AI技術の融合により、SP-APIの活用シーンはさらに広がることが期待されます。技術的な能力があるユーザーの場合は、公式ドキュメントをよく読んで接続してみることをお勧めします。一般の販売者にとっては、成熟したサードパーティツールを選択するのがより現実的な方法です。

ユーザーレビュー

THarris_88

—

SP-API の AWS Signature バージョン 4 署名アルゴリズムは非常に複雑すぎます。すべてのリクエストを計算する必要があります。最初はさまざまな署名が一致せず、デバッグに 3 日 3 晩かかりました。

MirandaHughes

—

アクセストークンは 1 時間ごとに期限切れになります。自動更新ロジックを追加するのを忘れた場合は、手動で再接続する必要があります。リフレッシュトークンの有効期間は 1 年間ですが、紛失した場合は再認証することしかできません。

春雨280

—

The rate limit is really gentle. Each API quota and recovery rate are different.指数関数的バックオフが時間内に実装されない場合、データ同期は営業時間のピーク時に直接崩壊するため、現在の制限数を確認するために CloudWatch を監視する必要があります。

SandyFreier

—

コールバック URL は HTTPS で設定する必要があります。そうしないと Amazon が認識しないため、ドメイン名を事前に登録する必要があります。多くの人が最初のラウンドでこの落とし穴にはまってしまいます。

汪月睿

—

SP-API の開発から 6 か月が経過した後、SKU が 500 未満の販売者にとって、価格性能比は実際には高くありません。投資した時間と開発コストは、サードパーティのツールを数年分購入するのに十分な額です。盲目的に独自のものを構築しないでください。

TAlar777

—

中小規模の販売者の場合、SP-API に直接接続するのは費用対効果が高くありません。開発費が高すぎる。開発者を雇って実装するには 3 ～ 4 か月かかります。既製の SaaS ツールを使用すると、手間とコストを節約できます。

Julie_Wood_20225

—

SP-API の getCompetitivePricing インターフェイスは制限が厳しすぎ、1 秒あたりのリクエスト数はわずか 0.5 です。 10,000 SKU の競合製品の価格を監視することは不可能です。プロセス全体が完了するまでに 22 時間以上かかります。リアルタイムの価格設定は不可能です。

Daniel_Martin_99

—

フィード API は、商品データを一括でアップロードするのに非常に便利です。以前は、手動でアップロードすると、コーディングの問題やフォーマットエラーが発生することがよくありました。今では完全に自動化されており、大きな心配がなくなりました。

TRobinsonK

—

SP-APIのNotifications APIは実に実用的です。注文が来るとリアルタイムで通知されるため、ポーリングの必要がなくなります。また、多くの API 呼び出しも節約されます。 SP-API にアクセスするすべてのチームが SP-API を使用することをお勧めします。

Ronald_Thompson_Plus

—

SP-API の正式な認可を得るには、プラットフォーム全体を DigitalOcean から AWS に移行する必要がありました。 CI/CD を再構築し、環境の分離と完全な監視システムを実装するのに 2 週間かかりました。このプロセスは苦痛ですが、Amazon のセキュリティ監査により、インフラストラクチャで適切な作業を行うことが強制され、その後の運用とメンテナンスがはるかに簡単になります。

d1j6o

—

最も厄介なことは、SP-API セキュリティ監査が初めて拒否された後、具体的なフィードバックがないことです。どこでテストに合格できなかったのかわかりません。目の見えない人が象に触るような感じの包括的な調査しかできません。

realRadoslavaGerasim'yuk

—

Amazon ERPやWMSをやっているのであれば、基本的にSP-APIは避けられません。注文、在庫、財務データはすべてこれに依存しています。接続後は全体の業務効率が大幅に向上します。レポートを手動でダウンロードする時代は永遠に終わりました。

lazycat197

—

正直に言うと、SP-API のドキュメントの品質は以前の MWS よりもはるかに優れており、少なくとも標準の REST 形式であり、Swagger モデルは以前のようにインターフェイスの形式やパラメーターを推測する必要がなく、SDK を直接生成することもできます。

HHoward_2023

—

SP-API の OAuth 認証プロセスの全体的な設計は比較的安全ですが、学習曲線は確かに急です。 JWT 署名や STS 一時認証情報などの概念は、一般の販売者がフルタイムの開発なしで扱うには高すぎます。

Madison.Alvarez168

—

サンドボックス環境は、SP-API を初めて使用するチームにとって非常に使いやすく、実際のデータに影響を与えることなく API 呼び出しをテストできます。ただし、一部のインターフェイスのサンドボックス動作は運用環境と完全に一致しているわけではないため、オンラインにする前に運用検証が必要であることに注意してください。

Roy.GutierrezK

—

Data Kiosk API には優れた機能があります。カスタム SQL を使用して販売データを確認できます。事前定義されたレポートよりもはるかに柔軟です。唯一の問題は、クエリの設計にはある程度の SQL スキルが必要であり、誰もがすぐに使い始められるわけではないことです。

苏静妍

—

SP-APIを利用することで複数店舗の一元管理を実現します。これまで、北米、ヨーロッパ、日本の 3 つのサイトでは、手動操作のためにセラーセントラルにログインする必要がありました。今ではすべてが 1 つのシステムで行われます。毎朝概要を確認してください。

LisaPowell

—

FBA 出荷が SP-API を介して接続されると、物流プロセス全体が自動化されます。注文が届くと、自動的に倉庫にプッシュされ、注文が生成され、追跡番号が更新されます。ピッキングから出荷までの時間が約半分に短縮されます。

Alexander_Green_75

—

Amazon が以前 SP-API をリリースしたときは、すべてのサードパーティツールが期限までに移行を完了する必要がありました。当時は本当に混乱しましたが、今ではそれが良かったようです。インターフェースの品質とセキュリティがより高いレベルに向上しました。

ChainMjx

—

SP-APIを利用して広告管理ツールに接続した後、広告の入札単価調整は、1日30分ごとの手動調整から、ACOSをベースとしたシステムによる自動かつ動的な調整に変更された。 ROAS が約 20% 増加しました。これは明らかです。

DKelly_2021

—

SP-API には、暗号化スキーム、アクセス制御、監査ログなどのデータ処理に対する高度なセキュリティ要件があります。しかし、別の観点から見ると、これらの仕様によりデータセキュリティシステムの構築が強制され、これは ISO 認証に合格するためにも役立ちます。

GEjam

—

EC代行運営会社は現在、顧客店舗との接続にはSP-APIを利用するのが基本となっている。自動化の度合いが高まるほど、利益率は大きくなります。手作業に頼る時代は終わりました。 API接続ができない代理店事業者は、今後大規模な顧客を獲得することは困難になるだろう。

TheresaMendoza1683

—

AmazonがついにSP-APIの年会費を廃止しました。年間 1,400 ドルのサブスクリプション料金は、以前は小規模開発者を息苦しくさせましたが、幸いなことに、最終的には撤回されました。

CLbau

—

過去には、一部のツールベンダーが SP-API の料金を理由に価格を 5 ～ 15% 値上げしました。その結果、手数料が撤回された後も価格は引き下げられませんでした。売り手は過去数か月の請求書を徹底的に調べて修正する必要があります。返金を要求する必要がある場合は、返金を要求する必要があります。

KAtur

—

アマゾンが充電開始！ 4月30日からAPI呼び出しに費用がかかるようになり、その費用が一気に値上がりしました。

BrianYoung

—

SP-API を半年使用しましたが、以前の MWS よりもはるかに安定しており、リアルタイムデータも優れています。ただし、アクセスのしきい値は少し高く、技術的な背景が必要です。

MJenkins_2020

—

接続が完了した直後のプロセスは、確かに予想よりも複雑でした。 OAuth 認証だけで丸 1 日かかりましたが、ドキュメントは非常に詳細でした。

silverfrog759

—

強くお勧めします！ドッキング後は注文管理が自動化され、効率が大幅に向上し、毎日 2 ～ 3 時間の手動操作時間が節約されます。

DanielLopez_Pro

—

マルチストア管理に SP-API を使用すると、ストレスなく 5 つの Amazon ストアを同時に制御でき、データの同期も非常にタイムリーです。

x890p

—

API ドキュメントはすべて英語なので、頭皮がしびれてしまいます。 Amazonが中国語版を出版することをお勧めします。

Selling Partner API

詳細レポート

ユーザーレビュー

類似の製品