Amazon Creators APIの始め方｜アプリケーション作成と認証情報発行を初心者向けに解説

Amazon Creators APIの始め方｜アプリケーション作成と認証情報発行を初心者向けに解説

Amazonの商品情報をAPI経由で取得できれば、商品紹介記事の作成、商品データの登録、画像表示などを効率化できそうです。

前回の記事では、Amazon Creators APIに挑戦し、Xserver上のWordPressから実際の商品情報を取得するところまで成功したことを紹介しました。

ただし、最初からCreators APIの仕組みを理解していたわけではありません。

筆者はAmazonの商品APIを専門に扱ってきたエンジニアではなく、

Creators APIのアプリケーションとは何だろう。
認証情報は何のために必要なのだろう。
発行されたシークレットはどこへ保存すればよいのだろう。

という基本的な疑問から、チャッピーことChatGPTと一緒に一つずつ確認しながら進めました。

旧PA-APIの公式資料では、2026年5月15日を区切りとしてCreators APIへの移行が案内されています。旧PA-APIの資料は更新終了扱いとなり、現在はCreators APIのドキュメントを参照するよう案内されています。

この記事では、Amazonアソシエイト・セントラルでCreators APIの画面を開き、

アプリケーションを作成
↓
認証情報を発行
↓
認証情報を安全に保存

するところまでを、実際の操作に沿って紹介します。

XserverやWordPressへの設定は、次回の記事で詳しく取り上げます。

---

H2-1　Amazon Creators APIを使うには最初に何が必要？

H3-1　Creators APIは画面を開いただけでは使えない

Amazonアソシエイト・セントラルにCreators APIの画面が表示されていても、それだけで商品情報を取得できるわけではありません。

実際に商品情報を取得するまでには、次の工程があります。

Amazonアソシエイトへ参加
↓
Creators APIの利用条件を満たす
↓
アプリケーションを作成
↓
認証情報を発行
↓
認証情報を自社システムへ設定
↓
API接続テスト
↓
商品情報を取得

今回の記事で行うのは、Amazon側でのアプリケーション作成と認証情報発行までです。

それぞれの役割を簡単に整理すると、次のようになります。

アプリケーション作成
＝APIを利用するシステムをAmazonへ登録する

認証情報発行
＝APIへ接続するための鍵を取得する

商品情報取得成功
＝発行された鍵を使って実際にAPIを利用できた

アプリケーションを作成しただけでは、まだAmazonの商品データへアクセスできません。

H3-2　今回の記事で行う作業

この記事では、次の範囲を扱います。

Creators APIの初期画面を開く
アプリケーションの意味を確認する
アプリケーション名を決める
アプリケーションを作成する
新しい認証情報を追加する
認証情報IDとシークレットを保存する
認証情報の発行日時を記録する

認証情報をWordPressへ設定する作業や、Amazonの商品情報を取得する接続テストは次回以降へ分けます。

一つの記事にすべてを詰め込むよりも、

第1段階：Amazon側で登録
第2段階：WordPressへ設定
第3段階：Amazonへ実際に接続

と分けた方が、問題が起きた工程も判断しやすくなります。

H3-3　TECNではこの後の接続まで成功した

TECNでは、今回紹介する方法でアプリケーションと認証情報を作成した後、Xserver上のWordPressへ設定しました。

さらに、Amazonの商品URLを入力するとASINを自動抽出し、Creators APIから商品名や画像情報を取得する診断プログラムも作成しています。

認証情報を発行したのは、2026年7月15日10時40分です。

その約3時間後には、WordPressからCreators APIへ接続し、指定商品の情報を取得できました。

ただし、約3時間という時間はTECN環境での実測結果です。すべての利用者が同じ時間で利用できることを保証するものではありません。

---

H2-2　Amazonアソシエイト・セントラルでCreators APIを開く

2026/7/15　現在　　まだAmazon Creator API はリリースして間がないのか、PA　APIメニューしかありません、PA　API　ページにCreator API ページ遷移があるのですが、ちょっとわかりにくいので、画面ショットを添付しておきますね。

H3-1　Amazonアソシエイト・セントラルへログインする

Creators APIの管理画面は、Amazonで商品を購入する通常の画面ではなく、Amazonアソシエイト・セントラルの中にあります。

Creators APIを利用するAmazonアソシエイトのアカウントでログインします。

複数のストアIDを持っている場合は、画面上部に表示されているストアIDも確認しておきましょう。

今回TECNで確認した画面には、次の項目が表示されていました。

Amazonアソシエイト
ストアID
クリエイターAPI
アプリケーション
よくある質問

ストアIDは、後にCreators APIへ接続するときにも関係する情報です。

ただし、認証情報IDやシークレットとは別のものです。

H3-2　Creators APIの初期画面を確認する

Creators APIの最初の画面には、次の内容が表示されていました。

クリエイターAPIの説明
APIリファレンス
アプリケーション
アプリケーションを作成
よくある質問

画面中央には、黄色い「アプリケーションを作成」ボタンがあります。

【画像挿入位置】

画像01
Creators APIの初期画面
「アプリケーションを作成」ボタンが表示されている状態

推奨ファイル名：

01_amazon-creators-api_start-screen.png

この最初の画面は、後から操作手順を振り返るときにも重要です。

ボタンを押す前にスクリーンショットを保存しておくと、記事化や社内マニュアルの作成にも利用できます。

H3-3　初期画面で利用資格も確認する

Creators API画面の「よくある質問」には、商品APIへアクセスするための条件についても説明がありました。

今回の画面では、

承認されたクリエイターアカウントが必要
商品APIへのアクセスには対象売上条件がある
認証情報発行後、アクセス付与まで時間がかかる場合がある

という趣旨の案内が確認できました。

TECNの画面には、商品APIへのアクセス条件として、直近30日間に対象となる売上が10件以上必要であることが記載されていました。

ここは、

毎月必ず10件

という意味ではなく、

直近30日間に対象売上10件以上

と理解するのが適切です。

Amazonアソシエイトへ登録しただけではなく、一定の継続的な運営実績がある人を対象としたAPIと考えられます。

---

H2-3　Creators APIの「アプリケーション」とは何か

H3-1　スマートフォンアプリを作るという意味ではない

Creators APIの画面で突然、

アプリケーションを作成

と表示されると、新しいスマートフォンアプリを開発しなければならないのかと感じるかもしれません。

ここでいうアプリケーションとは、スマートフォンアプリや一般公開するソフトウェアだけを指すものではありません。

Creators APIを利用する自社Webサイト、商品管理システム、データ連携プログラムなどを、Amazon側で識別するための管理単位です。

今回の場合は、

Amazonの商品情報を取得
↓
商品名や画像を確認
↓
アピスの商品データへ連携
↓
WordPressの記事内で商品を表示

する仕組み全体を、一つのアプリケーションとして登録します。

H3-2　今回登録したのはAPICEの商品データ連携システム

TECNでは、Amazonの商品を一つ表示するためだけにCreators APIを利用するわけではありません。

将来的には、次のような仕組みに発展させる予定です。

商品候補の取得
商品名・ブランド・型番候補の確認
商品画像の取得
商品マスター登録候補の生成
記事内の商品一覧表示
商品情報の定期更新

Creators APIを単発の商品取得ツールとしてではなく、商品情報を収集するための共通基盤として利用します。

そのため、アプリケーション名も特定の商品やブランドに限定しない名称にしました。

H3-3　ブランドごとにアプリケーションを分ける必要はない

Sharkの商品を取得するからといって、

Shark用アプリケーション

を作り、Ninjaの商品を取得するときに、

Ninja用アプリケーション

を別に作る必要はないと判断しました。

同じシステム、同じ運営者、同じ利用目的でAmazonの商品情報を取得するため、APICEの商品データ連携全体を一つのアプリケーションとして管理します。

今後扱う商品が1,000件、2,000件へ増えても、ブランドごとにアプリケーションを増やすのではなく、商品データ連携の共通入口として利用する考え方です。

---

H2-4　Creators APIのアプリケーション名を決める

H3-1　最初は「APICE 商品データ連携」を考えた

「アプリケーションを作成」を押すと、アプリケーション名を入力する画面が表示されました。

最初に考えた名前は、

APICE 商品データ連携

です。

人が読めば、何をするシステムなのかが分かりやすい名称です。

しかし、実際に入力すると、アプリケーション名には使用できる文字の制限がありました。

H3-2　スペースや特殊文字は使用できなかった

画面には、アプリケーション名に使用できる文字として、次の内容が表示されました。

文字
数字
ハイフン
アンダースコア

一方で、スペースや特殊文字は使用できませんでした。

そこで、日本語とスペースを含む名称ではなく、英語とアンダースコアを使用する形へ変更しました。

アプリケーション名は、後から認証情報を管理するときにも表示されます。

そのため、

何のためのアプリケーションなのか
ほかのアプリケーションと区別できるか
将来も使い続けられる名称か

を考えて決めるとよいでしょう。

H3-3　正式名称はAPICE_Product_Data_Integration

最終的に採用したアプリケーション名は、次のとおりです。

APICE_Product_Data_Integration

日本語にすると、

APICE 商品データ連携

という意味です。

TECN専用の名称にしなかったのは、将来ほかのWebサイトや商品管理基盤へ展開する可能性も考えているためです。

【画像挿入位置】

画像02
アプリケーション名入力画面
APICE_Product_Data_Integrationを入力した状態

推奨ファイル名：

02_amazon-creators-api_application-name.png

---

H2-5　アプリケーションを作成する

H3-1　アプリケーション名を入力して作成する

アプリケーション名を入力したら、作成ボタンを押します。

操作自体は難しくありません。

アプリケーション名を入力
↓
作成ボタンを押す
↓
Creators APIの一覧画面へ戻る

作成に成功すると、画面右側に、

アプリケーションが作成されました

という完了メッセージが表示されました。

これで、Amazon側にAPIを利用するシステムを登録する最初の工程が完了です。

H3-2　Application IDが自動発行される

アプリケーション作成後の画面には、次の情報が表示されました。

アプリケーション名
Application ID
最終更新日時
作成完了メッセージ

Application IDは、自分で入力するものではありません。

アプリケーションを作成すると、Amazon側から自動的に発行されます。

アプリケーション名は人が管理しやすい名称、Application IDはAmazon側がアプリケーションを識別するためのIDと考えると分かりやすいでしょう。

公開記事へ画面を掲載する場合は、Application IDも必要に応じて一部を隠しておくと安心です。

H3-3　アプリケーションだけではまだAPIを使えない

アプリケーション作成後の画面には、

認証情報が見つかりません。

という表示がありました。

その下には、

新しい認証情報を追加

というボタンがあります。

【画像挿入位置】

画像03
アプリケーション作成完了画面
「認証情報が見つかりません」と表示された状態

推奨ファイル名：

03_amazon-creators-api_application-created.png

この状態を整理すると、次のようになります。

アプリケーション
＝APIを利用するシステムの登録

認証情報
＝登録したシステムがAPIへ接続するための鍵

次は「新しい認証情報を追加」を押し、API接続に必要な認証情報を発行します。

---

H2-6　新しい認証情報を発行する

H3-1　「新しい認証情報を追加」を押す

アプリケーションが正常に作成されても、認証情報がなければAPIへ接続できません。

そこで、

新しい認証情報を追加

を押します。

この操作を行うたびに、新しい認証情報の組み合わせが発行されます。

何度も押すと複数の認証情報が作られるため、初回は一つずつ内容を確認しながら進めた方が安全です。

H3-2　発行された3つの情報

今回保存した認証情報には、次の項目がありました。

認証情報ID
シークレット
バージョン

TECNで発行された認証情報では、バージョンに、

3.3

と表示されました。

これはWordPressやPHPのバージョンではなく、今回Amazonから発行されたCreators API認証情報に記載されていた値です。

実際にWordPressへ設定するときには、発行画面または保存したファイルに記載されている値をそのまま使用します。

H3-3　認証情報IDとシークレットはセットで管理する

API接続では、認証情報IDだけを保存しても利用できません。

必要なのは、

認証情報ID
＋
対応するシークレット

の組み合わせです。

新しい認証情報を複数発行すると、それぞれ異なるIDとシークレットが作られます。

認証情報AのID
＋
認証情報Aのシークレット

認証情報BのID
＋
認証情報Bのシークレット

という別々の組み合わせです。

どのIDとどのシークレットが対応しているか分からなくなると、後の接続テストで混乱します。

保存するファイル名やフォルダを分け、どのアプリケーションで発行した認証情報なのかを明確にしておきましょう。

---

H2-7　シークレットは発行直後に必ず保存する

H3-1　シークレットは後から同じ値を確認できない

認証情報の発行時には、

二度と表示されないため保存してください

という趣旨の注意が表示されました。

これは、認証情報を作成した直後にシークレットを保存しなければ、後から同じ値を再確認できないという意味です。

認証情報を発行したら、ほかの操作へ進む前に保存しましょう。

H3-2　スクリーンショットや記事に載せない

認証情報発行の手順を記事にする場合、画面キャプチャの扱いには特に注意が必要です。

公開してはいけない情報は次のとおりです。

認証情報IDの完全な値
シークレット
認証情報ファイルの中身
API接続時に取得する秘密情報
秘密情報が表示された管理画面

記事用画像では、秘密情報を完全に隠します。

薄いぼかしではなく、文字列全体が読めない状態にする方が安全です。

H3-3　TECNでの保存方法

TECNでは、次の方針で管理しました。

認証情報をパソコンへ保存
↓
安全な保管場所へ移動
↓
API設定時だけ参照
↓
チャットには貼らない
↓
記事用画像では秘密部分を完全に隠す

また、WordPressのCode Snippets本文へシークレットを直接書くことも避けました。

スニペットを共有したり、管理画面を撮影したりしたときに、認証情報まで漏れてしまう可能性があるためです。

次回は、認証情報をWordPressの設定ファイルへ分離して保存した方法を紹介します。

---

H2-8　複数の認証情報はどのように扱う？

H3-1　新しい認証情報を作るたびに別の組み合わせが発行される

Creators APIの画面では、一つのアプリケーションに複数の認証情報を作成できるようになっていました。

新しい認証情報を発行すると、毎回異なる認証情報IDとシークレットが作成されます。

新しいものを作成したからといって、既存の認証情報が必ずその場で置き換えられるわけではありません。

管理画面に残っている認証情報は、それぞれ別の接続情報として管理します。

H3-2　複数発行する目的は安全な交換

複数の認証情報を持てる仕組みは、将来認証情報を安全に切り替えるときに役立ちます。

認証情報Aで運用
↓
新しい認証情報Bを発行
↓
Bをシステムへ設定
↓
Bで接続テスト
↓
正常動作を確認
↓
古いAを削除

先に古い認証情報を削除してしまうと、新しい認証情報で問題が起きたときにAPIが停止します。

一時的に新旧を併用できれば、動作確認後に安全に切り替えられます。

H3-3　初回は1セットに絞る

初めてCreators APIへ接続する段階では、認証情報をむやみに複数作らない方が分かりやすいでしょう。

今回も、

今回の接続テストで使用する認証情報

を1セットに決めました。

複数作成すると、

どの認証情報IDをWordPressへ入れたのか
どのシークレットと組み合わせるのか
どの認証情報を削除してよいのか

が分からなくなりやすいためです。

まずは1セットで接続に成功し、交換が必要になった段階で2セット目を作る方法が扱いやすいでしょう。

---

H2-9　認証情報の発行日時を記録する

H3-1　TECNでは2026年7月15日10時40分に発行

今回、Creators APIの認証情報を発行した日時を次のように記録しました。

2026年7月15日 10時40分

日付だけでなく時刻まで残したのには理由があります。

認証情報が発行されても、商品情報へアクセスできる状態がすぐ反映されるとは限らないためです。

認証情報を作成した時刻を基準に、どの程度で実際に利用可能になったのかを測定しました。

H3-2　利用可能になるまでの時間を測る

WordPress側には、認証情報発行からの経過時間を表示する診断画面を作りました。

当初は、次のタイミングで接続確認する予定でした。

発行直後
2時間後
4時間後
8時間後
12時間後
24時間後
36時間後
48時間後

診断画面には次を表示します。

認証情報発行日時
現在日時
正確な経過時間
ざっくりした経過時間
48時間到達予定
48時間までの残り時間