API
Python
アプリケーション開発
技術

Amazon MWS から SP-API への移行 [準備編]

Amazon MWS から SP-API への移行 [準備編]

きっかけ編で書いたMWSからSelling Partner API（以下、SP-API）への移行について、自分の備忘録としても残していきたいと考えています。何章かに分けて、アカウント準備～テスト接続（Postman）～スクリプト接続（Python）という流れで記事を書いていこうと思います。

今回は[準備編]ということで、SP-APIへアクセスするために必要となる各種アカウントやリフレッシュトークンの準備方法についてまとめます。

この記事で出来るようになること

この記事の内容に沿って各アカウント登録や設定を実施することで、SP-APIへアクセスするための一通りの情報が揃うことになります。

必要となる知識

  • PCやWebブラウザの基本的な操作方法
  • Webサービスのアカウント作成の知識

SP-APIの利用イメージ

SP-APIへアクセスするまでのアカウントの準備の流れをイメージ化してみました。

上記イメージは、Amazonセラーオーナー兼自社システム開発者が、自身のショップの情報を、自身が開発したシステムからSP-APIにアクセスして取得する場合、を例としています。（文章が分かり辛い。。。）

(3-A)でアプリケーション登録をする際は、(1-A)で取得した「③ユーザーARN」情報を使用します。

なお、(1-A)(1-B)と(2-A)(2-B)は順序が逆でも大丈夫です。

SP-API利用に向けた準備の流れ

イメージにも記載しましたが、以下の流れでSP-APIにアクセスするための情報を揃えます。

  1. AWSアカウント登録
  2. AWS IAMユーザー作成／ポリシー作成／ポリシー設定
  3. Amazon Seller Central 開発者登録
  4. Amazon Seller Central アプリケーション登録

公式ドキュメントの場所

公式ドキュメントを参考にしつつ、こちらの記事は補足として利用すると理解が深まると思います。

https://developer.amazonservices.jp/blog-others-spapirelease
https://github.com/amzn/selling-partner-api-docs

ここらへん見ればわかる！（ということになってますが解読は大変でした）

アカウント準備

それではサクッと準備していきましょう！

AWSアカウント登録

基本的にはこちらを参考に進めれば大丈夫です。

AWS アカウント作成の流れ（公式）

https://aws.amazon.com/jp/register-flow/

とても親切丁寧に書いてあるので、説明通りに作成すれば間違うことはないかと思います。

AWSアカウント作成の流れ (2021.09.06時点)

AWS IAMユーザー作成/ポリシー作成/ポリシー付与

AWSアカウントを作成したら、AWSマネジメントコンソールにてIAMユーザーの作成と、IAMユーザーへのポリシー付与を実施します。
IAMは、Identity and Access Management （和訳：IDとアクセス管理）の略です。

このIAMユーザーによって、Selling Partner APIへのアクセス管理を実施しています。

IAMユーザー作成

AWSマネジメントコンソールから、IAM画面へ移動します。

AWSマネジメントコンソール画面

移動方法は複数ありますが、下記説明では検索にて「IAM」と入力し、移動する形をとっています。

画面上部にある検索窓から、「IAM」と入力し、候補に出てくる一番上の「サービス：IAM」を選択します。

IAMダッシュボード画面に移動できたら、ユーザー追加を実施していきます。

画面左側メニューにある「ユーザー」を選択し、ユーザー管理画面へ遷移後、画面右側にある「ユーザーを追加」ボタンを選択し、ユーザー追加を実施します。

IAMダッシュボード画面で「ユーザー」を選択

「ユーザーを追加」画面のSTEP1にて、IAMユーザー名とアクセスの種類を入力/選択します。今回、ユーザー名は「AWS_IAM_SPAPI_Access_User」としています。自身が判別しやすい名前にするといいかと思います。

アクセスの種類は「プログラムによるアクセス」を選択します。

問題なければ、画面下にある「次のステップ：アクセス権限」を選択します。

「ユーザーを追加」画面のSTEP2にて、ユーザーのアクセス許可の設定を実施します。

この画面はこのままで問題ありません。（必要に応じてグループ等を作成してください。）

問題なければ、画面下にある「次のステップ：タグ」を選択します。

「ユーザーを追加」画面のSTEP3にて、タグの追加 (オプション) を設定します。

この画面もこのままで問題ありません。（必要に応じて識別用の情報を付与してください。）

問題なければ、画面下にある「次のステップ：確認」を選択します。

「ユーザーを追加」画面のSTEP4にてユーザー作成情報の確認を実施します。

入力/選択情報に問題ないかを確認します。

画面には以下の注意が出ますが、問題ありません。

[!] このユーザーにはアクセス権限がありません
このユーザーにまだアクセス権限を付与していません。したがって、ユーザーはいずれの AWS サービスやリソースにもアクセスできません。前のステップに戻って、いずれかの種類のアクセス権限を追加することを検討してください。

最終確認を実施し、画面下にある「ユーザーの作成」を選択します。

「ユーザーを追加」画面のSTEP5にて、作成したユーザーの確認ができます。

こちらに表示されている、IAMユーザの「アクセスキーID」と「シークレットアクセスキー」は、SP-APIへアクセスする際に必要となる情報なので、厳重な管理のもと扱ってください。

ユーザー作成は以上で終了となります。

問題なく作成できていれば、IAMダッシュボードの「ユーザー」画面にて以下の表示になっています。

ユーザー登録完成！

次に、ユーザーへポリシー付与するためのポリシー作成を実施します。

ポリシー作成

IAMダッシュボード画面に戻り、ポリシー作成を実施します。

IAMダッシュボード画面にて、 画面左側メニューにある「ポリシー」を選択し、ポリシー管理画面へ遷移後、画面右側にある「ポリシーを追加」ボタンを選択し、ポリシー追加を実施します。

IAMダッシュボード画面からポリシーを作成

「ポリシーの作成」画面のSTEP1にて、「JSON」タブを選択します。

赤枠の部分（デフォルト設定として４行入ってます）を、修正していきます。

編集前

これ（↑）を、この（↓）内容に修正。以下を入力します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "execute-api:Invoke",
            "Resource": "arn:aws:execute-api:*:*:*"
        }
    ]
}
編集後

修正後、画面下にある「次のステップ：タグ」を選択します。

「ポリシーの作成」画面のSTEP2にて、タグを追加 (オプション) を設定します。

この画面はこのままで問題ありません。（必要に応じて識別用の情報を付与してください。）

問題なければ、画面下にある「次のステップ：確認」を選択します。

「ポリシーの作成」画面のSTEP3にて、 作成したポリシーの確認を実施します。

ポリシーの名前は入力必須項目になっています。 今回、ポリシー名は「AWS_IAM_SPAPI_Policy」としています。自身が判別しやすい名前にするといいかと思います。「説明」の入力項目は任意なので、後で見てわかりやすいものを入れるといいかと思います。

問題なければ、画面下にある「ポリシーの作成」を選択します。

ポリシー作成は以上で終了となります。

問題なく作成できていれば、IAMダッシュボードの「ポリシー」画面にて以下の表示になっています。

次に、ユーザーへポリシー付与を実施します。

ポリシー付与

IAMダッシュボード画面に戻り、IAMユーザーへのポリシー付与を実施します。

IAMダッシュボード画面にて、 画面左側メニューにある「ユーザー」を選択し、今回作成したIAMユーザーを選択します。

選択したユーザーの画面（以下）にて、「アクセス権限の追加」ボタンを押します。

この際、画面上部にある赤枠の「ユーザーのARN」情報を控えておきます。この情報は、後で出てくるAmazon Seller Central でのアプリケーション登録の際に利用します。

「アクセス許可の付与」画面のSTEP1にて、作成したポリシーの付与を実施します。

画面赤枠（一番上）の「既存のポリシーを直接アタッチ」ボタンを押し、ポリシーのフィルタ部分に自身で作成したポリシー名称を入力します。（ここでは「SPAPI」と入力してフィルタしています。）

自身が作成したポリシーが表示されるので、ポリシー左側のチェックボックスにチェック（赤枠部分）を入れます。

問題なければ、画面下にある「次のステップ：確認」を選択します。

「アクセス許可の付与」画面のSTEP2にて、アクセス権限の追加の確認実施します。

問題なければ、画面下にある「アクセス権限の追加」を選択します。

ポリシー付与は以上で終了となります。

問題なく作成できていれば、IAMダッシュボードの「ユーザー」画面にてポリシー付与を実施したユーザーの表示が以下になっています。

「アクセス権限」タブにて、先ほど付与したポリシー名が表示され、「直接アタッチ済み」になっているかと思います。

Amazon Seller Central 開発者登録

SP-APIを利用するには、Amazon出品用アカウント登録を実施したうえで、Amazon開発者登録を実施し、アプリケーション登録を実施するという流れになります。

Amazon出品用アカウント登録

Amazon出品用アカウント登録については、基本的にこちらを参考に進めれば大丈夫です。

Amazon出品用アカウント登録手順（公式）

https://sell.amazon.co.jp/sell/account-registration

こちらも、とても親切丁寧に書いてあるので、説明通りに作成すれば間違うことはないかと思います。

Amazon出品用アカウント登録手順 (2021.09.06時点)

Amazon開発者登録

Amazon出品用アカウント登録が完了すると、Amazon Seller Central にログインできるようになります。Amazon開発者登録を実施するには、Amazon出品サービスのプランが「小口契約」ではなく「大口契約」になっている必要があります。

出品プランの小口出品と大口出品の違いは以下に比較表があります。

出品にかかる費用（公式）

https://sell.amazon.co.jp/pricing?ref_=sdjp_pricing_n

大口出品プランは、4,900円/月 + 販売手数料 となっています。

大口出品プランになっている前提で、Amazon開発者登録の流れを記載します。

Amazon Seller Central のトップページより、画面下部（赤枠部分）にある「アプリの開発」を選択します。

「デベロッパーセントラル」画面が表示されます。

この画面にある「■開発者プロフィール」（赤枠）にて、開発者申請を実施します。

開発者プロフィールの入力フォームが表示されます。

こちらに必要情報を記載していきます。

開発者プロフィール入力欄 ( 2021.09.06時点)

入力項目、項目の概要、参考となる入力例は以下の通りです。

入力項目項目の概要と入力例
■連絡先情報
組織名開発者として申請している方の所属組織名を記載します。

会社名＋組織名や、ショップ名の記載が良いかと思います。
ウェブサイトご自身の所属組織、もしくはご自身で管理されているウェブサイトのURLを記載します。

私はこちらのウェブサイトのURLを記載しました。
組織の所属国プルダウンでの選択となります。

基本的にこちらのブログを見ている方は日本の方だと思うので「日本」を選択する形でよいかと思います。

もし、日本以外の国から申請される方は在住されている国を選択します。
主な担当者名開発者として申請している方の氏名を記載します。
連絡先Eメールアドレス開発者として申請している方の氏名を記載します。
連絡先コード連絡先電話番号が日本のものであれば、「81」と記載します。

もし、日本以外であれば、「連絡先国コード」と検索して該当の国コードを記載します。
連絡先電話番号開発者として申請している方の連絡先電話番号を記載します。
■データアクセス
貴組織に最も適したオプションを選択してください。プルダウンで選択します。（2択です。）

私の場合は、自ショップの業務管理のための開発だったので「プライベート開発者：自社をAmazonのサービスAPIと統合するアプリケーションを構築しています。私の組織はAmazonのサービスに参加していますが、私は自分の業務だけを管理するために統合します」を選択しました。 (※項目の内容が変更になっていたので修正しました。)
開発者の場合は、組織の開発者IDを入力してください。もし、MWSの開発者IDをお持ちの場合はこちらに記載します。

複数お持ちの場合は、コンマ区切りで入力するようです。
ロール

※ロールは、SP-API (Selling Partner API) へのアクセス権を決定するものとなります。		SP-API にてアクセスを許容するロールにチェックを入れます。

(制限)と記載のある制限付きロールについては「Amazon購入者に関する個人情報（PII）が含まれており、データの使用とセキュリティ管理に関する追加情報を提供する必要があります。」という注意書きがありますので、必要に応じて申請し、指示があった場合は情報提供を実施してください。

私の場合は、自身のショップ管理用システムの開発だったので、制限付きロール以外（以下の項目）に全てチェックをつけて申請しました。
　・商品の出品
　・価格
　・Amazonから発送
　・購入者とのコミュニケーション
　・購入者にフィードバックを依頼
　・販売パートナーのインサイト
　・財務会計
　・在庫と注文の追跡
　・ブランド分析
■ユースケース
要求されたロールの機能を使用して構築しようとしているアプリケーションまたは機能について説明してください。

＞＞画面キャプチャはこちら＜＜		選択したロール権限にて取得したデータをどのように使用するかについて記載します。

私は、他のサイトも参考にさせていただきながら下記のように記載しました。

========
自身の業務効率化を目的に、上記ロール権限を用いて～～～アプリケーション開発を実施します。

■価格～～機能
出品対象商品の価格を～～～し、適切なタイミングで～～～を実施します。

■ 在庫～～機能
自組織の～～～システムと連携し、適切な在庫～～～を実施します。

■ 発送～～機能
倉庫に納品されている商品の発送を～～～する機能を実装します。

■ 購入者とのコミュニケーション機能
購入者とのコミュニケーションを円滑にするための～～～機能を実装します。

■ 販売パートナー～～機能
販売パートナーの情報を自身の～～システムから～～可能とする機能を実装します。

■ 財務～～機能
～～情報、～～情報との連携機能を実装します。
========
みたいな感じです。
■セキュリティ管理※注意：以下については基本的に「はい」を選択します。

ここは単なるチェックというよりは、Amazonとして開発者登録をする上で「このポリシーは絶対守ること！」という勧告としてとらえるべき項目です。

情報の取り扱い方法が脆弱だった場合、他社/他者への損害を与えることになり兼ねないため、セキュリティ管理については細心の注意を払う必要があります。
ネットワーク制御を使用して、Amazon情報への不正アクセスを防止していますか？内容を理解し、必要な措置を取る/準備したうえで「はい」を選択します。
ユーザーの職務や業務に基づいて、Amazon情報へのアクセスを制限していますか？内容を理解し、必要な措置を取る/準備したうえで「はい」を選択します。
Amazon情報を送信中に暗号化していますか？内容を理解し、必要な措置を取る/準備したうえで「はい」を選択します。
潜在的な脅威やセキュリティインシデントの監視、検知、対応についてのインシデント対応計画はありますか？内容を理解し、必要な措置を取る/準備したうえで「はい」を選択します。
そのインシデント対応計画には、Amazon情報に関連するセキュリティインシデントを3p-security@amazon.comに報告することが含まれていますか？内容を理解し、必要な措置を取る/準備したうえで「はい」を選択します。
人員とシステムに対して最低限のパスワード要件が設定されていますか？内容を理解し、必要な措置を取る/準備したうえで「はい」を選択します。
アプリケーションの変更は、本番環境に展開する前に専用のテスト環境で評価されますか？内容を理解し、必要な措置を取る/準備したうえで「はい」を選択します。
認証情報（パスワード、暗号化キー、秘密アクセスキー）は安全に保管されていますか？ つまり、認証情報を公開リポジトリに保存したり、認証情報を共有したり、認証情報をアプリケーションにハードコーディングしたりしていない、ということです。内容を理解し、必要な措置を取る/準備したうえで「はい」を選択します。

※語尾が「ことです。」になっているあたり、強いメッセージを感じます。
PIIを処理するアプリケーションやネットワークコンポーネント（ハードウェアを含む）に対して、定期的なチェック（脆弱性スキャンや侵入テストなど）を少なくとも180日ごとに行っていますか？内容を理解し、必要な措置を取る/準備したうえで「はい」を選択します。
アプリケーションのコードに脆弱性がないか、各リリースの前にスキャンしていますか？内容を理解し、必要な措置を取る/準備したうえで「はい」を選択します。
変更のテスト、検証、承認に関する責任を定義し、これらのアクションを実行できるユーザーへのアクセスを制限する正式な変更管理プロセスがありますか？内容を理解し、必要な措置を取る/準備したうえで「はい」を選択します。
Amazon情報を共有するすべての外部第三者を記載して、貴組織がこの情報を共有する方法を説明してください。こちらは、Amazonから取得した情報を外部の第三者に共有する場合は、その方法を記載してくださいというものです。

私の場合は、外部の第三者に情報を提供することはないため、その旨を記載しました。
Amazonの情報を取得するAmazon MWS以外のソースをすべて記載してください。こちらは、MWSの開発者ID申請の残骸でしょうか。この文章だけでは、あまり意味がわかりませんでした。

MWSをSP-APIとして置き換えて考えて、SP-API以外からAmazon情報を取得するソース(取得元)があれば記載してください、と読み取りました。

私は、SP-API以外からAmazon情報を取得することはないので、その旨記載しました。
私はAmazonサービスAPI開発者契約、利用規約、および データ保護ポリシー を読み、同意します内容を理解し、必要な措置を取る/準備したうえでチェックボックスにチェックを入れます。

以上が申請情報の入力/選択項目になります。

記載内容を確認し、問題なければ画面下にある「登録」を選択し、開発者申請を実施します。

開発者登録申請後の承認について

承認については、その時々で審査の通りやすさが変わるかもしれないのですが、私は内部の人間ではないので何とも言えません。

今回、私が実施した申請は1日以内に問題なく受理/承認されました。

過去のMWSにおける開発者申請では、最初の方は比較的申請が通りやすかった一方で、ある一定の期間を経ると途端に申請が通らなくなる、といった状況もありました。

ご不明な点については、問い合わせをしながら解決していく必要が出てくるかもしれませんね。

Amazon Seller Central アプリケーション登録

Amazon開発者登録が完了したら（承認されたら）、SP-APIへアクセスするためのアプリケーション登録を実施します。

上の方で記載した「デベロッパーセントラル画面への遷移」を参考に、Amazon Seller Central の「デベロッパーセントラル」画面に移動し、「新しいアプリクライアントを追加」ボタン（赤枠）を選択します。

「アプリを作成する」画面が表示されるので、必要事項を記載/選択していきます。

こちらの画面にて、登録する「アプリ名」を入力し、APIタイプ「SP-API」を選択します。

APIタイプで「SP API」を選択すると、必要情報の入力ならびにロール選択のチェックボックス、OAuth用の入力フォームが表示されます。

今回、アプリ名は「SPAPI_Access_Sample_App」としています。自身が判別しやすい名前にするといいかと思います。IAM ARN については、「ポリシー付与」手順で取得した「ユーザー ARN」情報を入力します。また選択するロールについては、登録するアプリにアクセスを許容するロールのみを選択します。

今回は、サンプルアプリ登録のため全てのロールにチェックを入れています。

「制限データトークン（RDT）により、個人識別情報（PII）へのアクセスを他の開発者のアプリケーションに安全に以上できます。PIIへのアクセスを別の開発者のアプリケーションに委譲しますか？」という確認がありますが、OAuthについては、今回のアプリ実装のスコープ外なので何も入力しませんでした。こちらは、必要に応じて入力し、アプリ開発を実施する形になるかと思います。
（※OAuthの記載ではなくなっていたので修正しました。）

【入力例】

IAM ARN：arn:aws:iam::XXXXXXXXXXXX:user/AWS_IAM_SPAPI_Access_User

ロール：すべてにチェック

入力内容に問題なければ、画面下にある「保存して終了」を選択します。

アプリ登録が完了すると、「デベロッパーセントラル」画面に登録したアプリケーションが表示されます。

この画面から、SP-APIを利用するために必要な以下の情報を取得します。

  1. リフレッシュトークン
  2. LWA 認証情報 クライアントID
  3. LWA 認証情報 クライアント機密情報
    ※本ページ上部にあるSP-API利用イメージでは、シークレットキーと表現しました。

LWA認証情報は「表示」（左側の赤枠部分）を押すことで確認が可能です。

以下の画面がモーダル表示されるので、2つの情報を控えます。こちらも、SP-APIへアクセスする際に必要となる情報なので、厳重な管理のもと扱ってください。

リフレッシュトークンについては、「承認」（右側の赤枠）を選択して取得します。

「承認」を押すと、以下の「アプリケーションを承認」画面に遷移します。

リフレッシュトークンについて以下の記載があるので、内容を確認して問題なければ「アプリを承認」ボタン（赤枠）を押します。

アプリを承認ボタンをクリックして、マーケットプレイスアカウントごとに新しいリフレッシュトークンを生成します。
リフレッシュトークンを生成しても、以前のリフレッシュトークンは無効になりません。
リフレッシュトークンはアクセストークンと交換できます。
このアクセストークンは出品パートナーAPIの呼び出しに含めます。

「アプリを承認」ボタンを押すと、下記画面に遷移し「リフレッシュトークン」の取得が可能になります。

以上の操作で、下記３つの情報が揃うことになります。

  1. リフレッシュトークン
  2. LWA 認証情報 クライアントID
  3. LWA 認証情報 クライアント機密情報

最後のまとめ

本ページに記載した流れに沿って処理をすることで、以下の情報が取得できたと思います。

  • AWS IAMユーザー情報
    • アクセスキーID
    • シークレットアクセスキー
    • ユーザー ARN
  • アプリケーション登録情報
    • リフレッシュトークン
    • LWA 認証情報 クライアントID
    • LWA 認証情報 クライアント機密情報

これらをもとに、次の回では実際にSP-APIへアクセスしてみたいと思います。

今日はここまでです。お疲れさまでした。

Amazon Seller Central の技術的な問い合わせ先

困ったときは以下にて問合せが可能です。

過去の問い合わせナレッジを参照しつつ、状況に応じてAmazon側に問い合わせをすることが問題解決への近道になると思います。

APIに関する問い合わせはこちらになっています。

Amazonセリングパートナー開発者サポートにお問い合わせください

https://sellercentral.amazon.co.jp/gp/mws/contactus.html

以上となります。

この記事を書いた人
Sovayanagi
Sovayanagi
会社員をしながら副業でWebアプリケーション開発をして癒されている。 ３児の父。
全くTVを見られない生活のため、世の中の流行り廃りに追いつけないでいる。息子にゲームで勝てなくなりつつあり、世代交代を思い知る。

得意技は、Python, Django, Selenium, CentOS, 動画作成, セキュリティ全般, 蕎麦, 自転車, サッカー, ゲーム, 家族, 人の悩みをITで助けること。
最近書いた記事
【ネット予約システム】ReserveStock (リザスト) でネット予約サイトを作ってみた
予約管理システム
【ネット予約システム】ReserveStock (リザスト) でネット予約サイトを作ってみた
【ネット予約システム】STORES 予約 でネット予約サイトを作ってみた
予約管理システム
【ネット予約システム】STORES 予約 でネット予約サイトを作ってみた
【MWSの廃止期限】MWSからSP-APIへの移行はいつまでに済ませればいいの？
API
【MWSの廃止期限】MWSからSP-APIへの移行はいつまでに済ませればいいの？
【GoPro x STRAVA】Garmin VIRB Edit でオーバーレイ表示に挑戦！
GARMIN
【GoPro x STRAVA】Garmin VIRB Edit でオーバーレイ表示に挑戦！

この記事が気に入ったら
フォローしよう

最新情報をお届けします

Twitterでフォローしよう

おすすめの記事