楽天API・Amazon MWSの記事を今読み返すと ― SP-API時代の設計はどう変わったか

8月21日

読了時間: 6分

弊社のブログには、2020〜2023年頃に書いた「楽天商品検索APIの使い方」や「Amazon MWSの始め方」といった記事が残っています。楽天APIは今も現役ですが、MWSはもう存在しません。今回はこの2つの古い記事を振り返りながら、「今の自分ならどう作り直すか」を考えてみます。同じような自動化の仕組みをこれから作る方の参考になればと思います。

API設計の大進化を示す図解。左側にある単純接続のシステムから、右側のAmazon SQSやLambdaと連携するサーバレスアーキテクチャへと進化する過程を描写。

振り返る2つの記事

・楽天商品検索APIの使い方（2020年頃）：アプリID取得→検索パラメータ→URLを組み立ててリクエスト、という素朴な構成

・Amazon MWSの始め方（2020年頃）：AWSアクセスキー・シークレットキーを使った認証、Scratchpadでの動作確認

どちらも「セラーの商品リサーチを自動化したい」という同じ動機から書いた記事です。当時はまだ、API1本を単発で叩くだけの、素朴な作りでした。

MWSは、もう存在しない

まず前提として、Amazon MWS（Marketplace Web Service）は2024年3月31日をもって完全に終了しました。今からMWSの記事を読んでも、書いてあるエンドポイントはもう動きません。

MWSからSP-API（Selling Partner API）への移行は、AWS IAMを使った署名認証（Signature Version 4）が必須だった時代から、よりシンプルなOAuth方式の認証へと変わった大きな転換点でした。今のSP-API開発では、当時の記事に書いたAWSアクセスキー・シークレットキーの取得手順は一切不要です。

技術記事を書くときの教訓としても地味に重要な話です。「認証方式」を扱う記事は、サービスの仕様変更で真っ先に陳腐化します。うちの過去記事でも、認証周りだけは注意書きを添えるようにしています。

当時の設計：API1本を単発で叩くだけ

楽天APIの記事もMWSの記事も、当時の設計思想は共通していました。

・欲しい情報を、1回のAPI呼び出しで直接取りに行く

・レート制限は特に意識せず、必要なときに必要な分だけ叩く

・結果はその場で確認するか、せいぜいログに残す程度

これは当時の用途（月に数十件、手動でリサーチする商品を確認する程度）には十分な設計でした。プログラムというより「ブラウザでポチポチやる作業を、コードで代替した」くらいの位置づけです。

今の設計：非同期・レート制御・下限保護の3点セット

現在、弊社で運用しているAmazon FBM（自己発送）のリサーチ・価格自動調整システムは、同じ「Amazon商品情報を自動で取りに行く」という目的でも、構成がまったく別物になっています。

1. SQSを挟んで非同期化する

当時の「必要なときに直接叩く」から、「キューに積んで、Lambdaが順番に処理する」という構成に変わりました。SP-APIには厳格なレート制限があるため、直接叩く設計ではすぐに429エラー（レート超過）に当たります。SQS FIFOキューを挟むことで、処理速度をコントロールしながら大量のASINを捌けるようになります。

📚 関連書籍

▶ AWSではじめるインフラ構築入門第2版

翔泳社／ Lambda・SQSなどAWSサービスを組み合わせた構成の基礎を学びたい方に。今回のような非同期処理の設計を理解する土台になる一冊。

2. 指数バックオフでリトライする

それでも429は発生します。当時なら「エラーが出たら諦める」で終わっていたところを、今は自動でリトライする設計にしています。固定の待ち時間ではなく、失敗するたびに待ち時間を倍々に伸ばす指数バックオフを組み込むことで、レート制限がかかっている状況でも自動的に落ち着いて再試行できます。

# 指数バックオフの骨格（実際はSP-API呼び出し全般に共通化している）
MAX_RETRIES = 10
wait = 2
for attempt in range(MAX_RETRIES):
    try:
        response = call_sp_api()
        return response
    except Exception as e:
        if attempt == MAX_RETRIES - 1:
            raise
        time.sleep(wait)
        wait = min(wait * 2, 60)

📚 関連書籍

▶ AWS運用入門改訂第2版押さえておきたいAWSの基本と運用ノウハウ

翔泳社／動かして終わりではなく「運用し続ける」ための勘所をまとめた一冊。エラー対応やコスト管理の考え方が実務に直結。

3. 価格の下限を「壊さない」設計にする

価格自動調整の機能を作るとき、一番怖いのは「バグって際限なく値下げし続ける」事故です。当時のような単発API呼び出しの発想では、この手当てを後回しにしがちでした。

今の設計では、Amazon Listings Items APIで管理されているセラーセントラルの下限価格（minimum_seller_allowed_price）をそのまま参照し、新価格は必ず下限価格でクリップしてから更新するようにしています。

# 価格更新前に必ず下限でクリップする
new_price = calculate_new_price(competitor_price)
floor_price = get_listing_min_price(sku)  # Listings Items APIから取得
final_price = max(new_price, floor_price)
update_price(sku, final_price)

下限価格を自前のDBで二重管理する案も検討しましたが、セラーセントラルの値と食い違うリスクを避けるため、Amazon側のデータをそのまま正として使う設計に落ち着きました。下限が未設定のSKUには、現在価格の10%オフを初期値として一括投入し、以降はプログラム側で下限自体を変更しない、というルールにしています。

設計が変わった理由は「事故った経験」

正直なところ、この3つの変更はどれも「最初から見えていた」わけではありません。DynamoDBの費用が急増した話や、SQSにメッセージが33万件溜まった話は、以前このブログでも書いたとおりです。実際に痛い目を見てから、設計に手が入っています。

振り返ってみると、当時の記事も「その時点では正しい」設計でした。処理件数が月に数十件なら、単発API呼び出しでまったく問題ありません。設計をこじらせる最大の要因は、規模の変化に気づかず同じ作りを引きずることだと思います。件数が増えたら「非同期化」「レート制御」「下限保護」の3点は、早めに検討する価値があります。

もう1つの変化：スクレイピングからAPIへ

当時の記事には書いていませんが、この数年でもう1つ大きく変わったのが、データの取得手段そのものです。以前はBeautifulSoupを使ったスクレイピングでデータを取っていた場面も、今はSP-APIやKeepaのAPIなど、公式に許可された手段への置き換えを進めています。

スクレイピングは手軽な反面、サイト構造の変更で簡単に壊れますし、Amazonのようなプラットフォームではアカウント停止のリスクも伴います。公式APIが用意されているなら、多少手間がかかってもそちらを使う方が、長い目で見て運用コストは低くなります。

まとめ

2020年の記事と今の実装を並べてみて、変わった点を整理するとこの3つです。

・単発の直接呼び出し → SQSを挟んだ非同期処理

・エラー時は諦める → 指数バックオフで自動リトライ

・価格保護なし → Amazon側の下限価格を必ず参照してクリップ

技術記事は書いた瞬間から陳腐化が始まります。特に認証方式や料金体系のような「サービス側の都合で変わる部分」は、数年単位で見直しが必要です。とはいえ、当時の記事を恥ずかしいと思う必要はなくて、「その時点でベストだった設計の記録」として残しておくと、こうして振り返ったときに自分の成長が見える資料になります。

Amazon SP-APIを使った自動化システムの設計・構築でお困りの際は、ロビンプランニング合同会社までお気軽にご相談ください。レート制限対応から価格保護の仕組みまで、実際に事故りながら学んだ知見でお手伝いします。