BackOps

Amazon SP-API でレビュー依頼を自動化（事例）

年数万円のレビュー依頼SaaSを自前実装に置き換えた事例。Claude Code を使い、半日で本番運用まで到達した。

自動化ワークフローを抽象的に表現したイラスト

AIでバックオフィス自動化を専門にしている mzohya です。 経理・EC・業務ワークフローの自動化を実装事例ベースで発信しています。 今回は Amazon SP-API を使ったレビュー依頼自動化の話。

結論

  • Amazon の購入者向けレビュー依頼を、SP-API（Selling Partner API）で完全自動化した
  • ローカルからセットアップ → 本番運用（GitHub Actions）まで 約半日
  • 既存の有料SaaS（FeedbackWhiz等、年数万円）が ¥0 に
  • 開発の大半は Claude Code とのペアプロ。詰まりどころも実体験ベースで共有する

なぜ作ったか

Amazon 出品者にとって、レビューは売上に直結する超重要指標。

ただ、購入者にレビューを依頼する作業は地味につらい：

  • Amazon Seller Central で1件ずつ「Request a Review」をクリック
  • 配送完了から 5〜30日以内 という縛り
  • 1日数十件の注文があると、漏れなく送るのが現実的に無理

これを解決するために、有料の SaaS（FeedbackWhiz、Helium 10、Jungle Scout等）が存在する。年数万円〜数十万円。

ただ、Amazon SP-API には Solicitations API という公式の自動依頼エンドポイントがあって、自分で叩けば実質無料で完全自動化できる。

「半日で作れるなら、SaaS 解約してこれで運用しよう」というモチベーション。

技術選定

シンプルに：

  • 言語: Python 3.13 — SP-API のラッパーライブラリが成熟
  • パッケージ管理: uv — 高速、最近の標準
  • SP-APIクライアント: python-amazon-sp-api — デファクト
  • 実行環境: GitHub Actions — 無料枠で十分（月60分以内）
  • 履歴管理: JSON in repo — 外部DB不要、見やすい
  • 型 / Lint / テスト: mypy strict + ruff + pytest — 品質担保

アーキテクチャ

src/review_automation/
  config.py         # 環境変数読み込み（pydantic-settings）
  client.py         # SP-API クライアント生成
  orders.py         # 注文取得・対象抽出
  solicitations.py  # レビュー依頼送信
  storage.py        # JSON履歴管理
  throttle.py       # レート制限・スロットリング対応
  main.py           # エントリポイント
.github/workflows/
  send-reviews.yml  # 日次cron
data/
  history.json      # 送信履歴（自動コミット）

ロジックはシンプル：

  1. Orders API で過去30日の注文を取得
  2. 配送完了から7-28日以内 + Shipped/Delivered ステータスのものに絞る
  3. 履歴に残っていない注文だけ Solicitations API でレビュー依頼を送信
  4. 結果を JSON に追記してコミット

実装の流れ

Step 1: SP-API 開発者登録

Seller Central → アプリ＆サービス → 開発者セントラル。

  • Private App（自社利用）として申請
  • ロール: 「購入者にフィードバックを依頼」「在庫と注文の追跡」「販売パートナーのインサイト」など
  • PII（個人情報）アクセスは申請しない方が審査が早い

審査は数時間〜数週間（自分は数十分で通った）。

Step 2: LWA 認証情報の取得

開発者セントラル上で：

  • LWA Client ID
  • LWA Client Secret
  • Refresh Token（自己承認で生成）

の3点を取得。.env に保存。

Step 3: コード実装

ここからが Claude Code とのペアプロ。

要件を伝える：

Amazon SP-API の Solicitations API を使って、購入者にレビュー依頼を自動送信するツールを作りたい。Python、uv、GitHub Actions、JSON履歴で。型安全・テスト付きで。

Claude Code が雛形を一気に作ってくれる：

  • pyproject.toml（依存関係）
  • src/ 配下のモジュール構成
  • tests/ 配下のユニットテスト 16件
  • GitHub Actions ワークフロー
  • README

最初のコミットまで30分かからない。

Step 4: GitHub Actions セットアップ

gh repo create amazon-review-automation --private --source=. --push
gh secret set LWA_CLIENT_ID --body "..."
gh secret set LWA_CLIENT_SECRET --body "..."
gh secret set SP_API_REFRESH_TOKEN --body "..."
gh secret set SP_API_MARKETPLACE_ID --body "A1VC38T7YXB528"
gh workflow run send-reviews.yml

JST 09:00 に毎日実行。

ハマりどころ（実体験）

順調に見えて、実際には4つの罠にハマった。AI ペアプロでも完全には避けられない。

ハマり1: タイムスタンプの ISO8601 形式

最初の動作確認で 400 エラー：

sp_api.base.exceptions.SellingApiBadRequestException:
  [{'code': 'InvalidInput', 'message': 'timestamp must follow ISO8601'}]

Pythonの datetime.isoformat() は 2026-04-03T08:55:09.269441+00:00 を返すが、SP-API はマイクロ秒なし・Z 終端を期待していた。

修正:

def _format_iso8601(dt: datetime) -> str:
    return dt.astimezone(UTC).strftime("%Y-%m-%dT%H:%M:%SZ")

ライブラリ任せだと油断する典型例。

ハマり2: 引数名の食い違い

最初のテスト送信で TypeError：

Solicitations.create_product_review_and_seller_feedback_solicitation()
  missing 1 required positional argument: 'amazonOrderId'

order_id で呼んでいたが、ライブラリは amazonOrderId （camelCase）を期待。 Python っぽい snake_case で書いてしまっていた。

ライブラリの実装を読まずに、Amazon 側の API ドキュメントの引数名のままで呼ぶのが正解だった。

ハマり3: レート制限とクオータ

数百件を一気に送ろうとしたら：

sp_api.base.exceptions.SellingApiRequestThrottledException:
  [{'code': 'QuotaExceeded', 'message': 'You exceeded your quota for the requested resource.'}]

SP-API は API ごとに rate limit と burst quota がある。

  • Orders API: 0.0167req/sec, burst 20
  • Solicitations API: 1req/sec, burst 5

特に Orders API は厳しく、analyze スクリプトと dry-run を連続で叩いただけで枯渇した。

対策として、独自のリトライ機構を実装：

def retry_on_throttle[T](
    fn: Callable[[], T],
    *,
    max_retries: int = 5,
    initial_wait_seconds: float = 30.0,
    backoff_factor: float = 2.0,
) -> T:
    """スロットリング時に指数バックオフで再試行."""
    attempt = 0
    wait = initial_wait_seconds
    while True:
        try:
            return fn()
        except Exception as exc:
            if not is_throttle_error(exc) or attempt >= max_retries:
                raise
            time.sleep(wait)
            attempt += 1
            wait *= backoff_factor

加えて、Solicitations API には毎回 1.2秒の sleep を挟む。

ハマり4: 「期間外」エラーで workflow が失敗扱い

GitHub Actions の動作確認で全件「outside the 5-30 day range」エラー → exit code 23 → workflow 失敗。

ただ、これは Amazon 側の 正常な拒否（実際の配送日が範囲外）であって、システムの失敗ではない。

修正：

EXPECTED_REJECT_PHRASES = (
    "already requested",
    "outside the 5-30 day range",
)

def _is_expected_reject(message: str | None) -> bool:
    if message is None:
        return False
    return any(phrase in message for phrase in EXPECTED_REJECT_PHRASES)

予期される拒否は失敗カウントから除外。これで正常に exit 0 を返すように。

結果

数百件の注文を一気に処理した結果：

  • 新規送信成功: 14%
  • 過去に手動送信済み: 82%
  • Amazon側で期間外と判定: 4%

過去の手動送信で漏れていた数十件分を、初回バッチで救えた。

明日以降は GitHub Actions で完全自動化。新規注文に対して取りこぼしゼロ。

Claude Code とのペアプロ所感

半日で本番運用まで到達できたのは、明らかに AI のおかげ。特に効いたのは：

良かった点:

  • 雛形作成の速度: pyproject.toml、ディレクトリ構成、テスト、CI まで一気に揃う
  • 型・Lint・テスト前提で書いてくれる（自分で頼まなくても）
  • エラーが出た瞬間に修正案が出てくる: ISO8601 問題も amazonOrderId 問題もすぐ気づいた
  • デバッグ時の仮説生成: 「Orders API のクオータ枯渇では？」という仮説をすぐ出してくれる

自分が関与する必要があった点:

  • ビジネス判断: 数百件を一気に送るか段階的に送るか、リスク・リターンの判断は人間
  • 本番への踏み込み: 「実際に送信」という不可逆操作の最終承認
  • 要件の取捨選択: AI は「あれもこれも」と機能を提案しがち。何を作らないかを決めるのは自分
  • ハマった時の根本原因特定: 「13分間プロセスが止まっている」の原因を最終的に判断するのは人間

所感: AI ペアプロは「速い手」を手に入れた感覚に近い。判断力は人間が持ち続ける。両方ないと、こういう「軽く作って本番に乗せる」ができない。

まとめ

  • SP-API の Solicitations API を直接叩けば、レビュー依頼自動化は SaaS 不要
  • Claude Code とのペアプロで、半日で本番運用まで到達
  • 既存ハマりポイントは ISO8601 / 引数名 / レート制限 / 失敗判定の4つ
  • 自社利用（Private App）なら審査も軽い

こういう自動化を、自社でやりたい方へ

「同じような自動化を自社にも欲しい」「内製化したいがリソースがない」という方の相談を受け付けています。

BackOps では、Claude Code を活用した以下のような自動化を専門に扱っています：

  • Amazon SP-API、楽天市場API などの EC 自動化
  • MoneyForward / freee 連携の 経理自動化
  • Notion / Slack を起点とした 業務ワークフロー構築
  • 既存の有料 SaaS から自前実装への 移行・脱SaaS

定型業務に時間を取られている事業者・出品者の方は、お問い合わせ からお気軽にどうぞ。

#事例 #Amazon #SP-API #自動化 #GitHub Actions