Amazon Creators APIをWordPressで実行｜Xserverへの設定から商品情報取得成功まで

Amazonアソシエイト・セントラルでCreators APIのアプリケーションを作成し、認証情報IDとシークレットを発行できました。

しかし、認証情報を発行できただけでは、Amazonの商品情報を取得できることまで確認できたわけではありません。

次に必要なのは、発行された認証情報を自分たちのシステムへ設定し、実際にCreators APIへ接続することです。

今回、TECNではXserver上のWordPressへ認証情報を設定し、Code Snippetsで接続診断用の管理画面を作成しました。（TECN　は　技術が生活を楽にする　楽しくする　というテーマで、関連記事をいろいろと書いています。)

TECN 公式サイト

その診断画面へAmazonの商品URLを貼り付けると、URLからASINを自動抽出し、Creators APIへ商品情報を問い合わせます。

結果は成功でした。

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

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

筆者は、最初からサーバー設定やAPIに詳しかったわけではありません。

wp-config.phpがどこにあるのかも分からない状態から、チャッピーことChatGPTと相談しながら一つずつ確認しました。

この記事では、XserverでWordPressの設置場所を探すところから、認証情報の設定、接続診断、Amazonの商品情報取得に成功するまでを紹介します。

---

H2-1　Amazon Creators APIをWordPressへ接続する準備

H3-1　第2回までに完了したこと

前回の記事では、Amazonアソシエイト・セントラルでCreators APIのアプリケーションを作成しました。

今回登録したアプリケーション名は、次のとおりです。

APICE_Product_Data_Integration

その後、新しい認証情報を追加し、次の情報を保存しました。

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

TECNで発行された認証情報には、バージョンとして次の値が記載されていました。

3.3

この時点での進捗は、次のとおりです。

Creators APIアプリケーション作成：完了
認証情報ID発行：完了
シークレット保存：完了
認証情報バージョン確認：完了
認証情報発行日時の記録：完了

ただし、まだWordPressには設定していません。

AmazonへのAPI通信も、この時点では行っていません。

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

今回の作業は、次の順番で進めます。

XserverでWordPressの設置場所を探す
↓
wp-config.phpを見つける
↓
編集前にバックアップする
↓
Creators APIの認証情報を設定する
↓
WordPressが設定を読み込めるか確認する
↓
API接続診断用のスニペットを登録する
↓
Amazonの商品URLを入力する
↓
URLからASINを自動抽出する
↓
Creators APIへ実際に接続する
↓
商品情報と画像情報を取得する

初心者にとっては、APIプログラムそのものよりも、

WordPressのどこへ設定するのか
wp-config.phpはどこにあるのか
どの位置へコードを追加するのか

という前段階の方が難しいことがあります。

今回は、その部分も省略せずに紹介します。

H3-3　商品キャッシュへの登録はまだ行わない

今回の目的は、Creators APIへ正常に接続できるかを確認することです。

まだ次の処理は行いません。

商品キャッシュへの保存
商品マスターの更新
商品シリーズの自動判定
WordPress記事への自動掲載
複数商品の一括登録

Creators APIから返される情報を十分に確認しないまま、商品データへ自動登録すると、色違い、セット品、Amazon限定商品などが重複して登録される可能性があります。

まずは、APIが動くことと、どのような情報が返るのかを確かめます。

---

H2-2　XserverでWordPressの設置場所を探す

H3-1　wp-config.phpはWordPress管理画面にはない

Creators APIの認証情報は、WordPressの設定ファイルであるwp-config.phpへ保存することにしました。

しかし、wp-config.phpはWordPressのダッシュボード内にはありません。

Code Snippetsの画面にもありません。

WordPressが設置されているサーバー内にあるファイルです。

一般的なWordPressの構成は、次のようになっています。

WordPress設置フォルダ
├─ wp-admin
├─ wp-content
├─ wp-includes
├─ wp-config.php
├─ index.php
└─ wp-login.php

wp-admin、wp-content、wp-includesの3つのフォルダが並んでいる場所を探すと、その近くにwp-config.phpがあります。

H3-2　Xserverのファイルマネージャーを開く

TECNでは、WebサーバーにXserverを利用しています。

まず、Xserverの管理画面へログインし、ファイルマネージャーを開きました。

ファイルマネージャーを利用すると、専用のFTPソフトを設定しなくても、ブラウザ上からサーバー内のフォルダやファイルを確認できます。

最初に確認したのは、次のフォルダです。

public_html

一般に、Webサイトで公開されるファイルは、このpublic_htmlの中に配置されています。

【画像挿入位置】

画像01
Xserverのファイルマネージャーを開いた画面

スクリーンショットを記事へ掲載する場合は、サーバーID、アカウント名、非公開フォルダなどが映っていないか確認します。

H3-3　TECNのサブドメインフォルダを確認する

public_htmlを開くと、次のフォルダが見つかりました。

tecn.apice-tec.co.jp

TECNはサブドメインで運営しているため、このフォルダがTECNの公開ルートである可能性が高いと判断しました。

構成は、次のような状態です。

public_html
└─ tecn.apice-tec.co.jp

サーバーの構成は、契約環境やWordPressの設置方法によって異なります。

必ず同じフォルダ名になるわけではありません。

自分のWebサイトで使用しているドメイン名やサブドメイン名を手掛かりに探します。

H3-4　WPフォルダの中でWordPress本体を見つける

tecn.apice-tec.co.jpフォルダを開くと、さらに次のフォルダがありました。

WP

このWPフォルダを開くと、次の項目が確認できました。

wp-admin
wp-content
wp-includes
wp-config.php

今回のTECN環境では、最終的に次の場所がWordPress本体でした。

public_html
└─ tecn.apice-tec.co.jp
   └─ WP
      ├─ wp-admin
      ├─ wp-content
      ├─ wp-includes
      └─ wp-config.php

【画像挿入位置】

画像02
wp-admin、wp-content、wp-includes、
wp-config.phpが見えるファイル一覧

ここで初めて、編集対象となるwp-config.phpを確認できました。

---

H2-3　wp-config.phpを編集する前にバックアップする

H3-1　wp-config.phpはWordPressの重要設定ファイル

wp-config.phpには、WordPressを動かすための重要な情報が記載されています。

例えば、次のような情報です。

データベース名
データベースユーザー
データベースパスワード
WordPressの認証キー
サイト固有の設定

記号を一つ間違えただけでも、WordPressが表示されなくなる可能性があります。

そのため、いきなり編集するのではなく、必ず元のファイルを保存しておきます。

H3-2　編集前にパソコンへダウンロードする

Xserverのファイルマネージャーでwp-config.phpを選択し、パソコンへダウンロードしました。

バックアップの保存名は、後から目的が分かるものにします。

例えば、次のような名称です。

wp-config_before_creators-api_20260715.php

ファイル名に、

何をする前のバックアップか
いつ保存したか

を入れておくと、復元が必要になったときに判断しやすくなります。

バックアップは、サーバー上の公開フォルダ内へコピーするのではなく、パソコン側の安全な場所へ保存しました。

H3-3　wp-config.phpの中身を公開しない

wp-config.phpの内容は、そのまま記事、チャット、メールなどへ貼り付けないようにします。

特に、次の情報を公開してはいけません。

データベース名
データベースユーザー
データベースパスワード
WordPress認証キー
Creators APIの認証情報ID
Creators APIのシークレット

サポートを受けるために画面を共有する場合でも、ファイル全体ではなく、秘密情報が含まれない一部分だけを共有します。

今回も、wp-config.phpの中身全体はチャットへアップロードしませんでした。

---

H2-4　Creators APIの認証情報をwp-config.phpへ設定する

H3-1　設定を追加する位置を探す

Xserverのファイルマネージャーでwp-config.phpを編集モードにしました。

ファイル内には多くの設定が書かれているため、すべてを理解する必要はありません。

編集画面の検索機能を使い、次の行を探しました。

/* That's all, stop editing! Happy blogging. */

環境によっては、末尾がHappy publishing.など、少し異なる場合があります。

Creators APIの設定は、この行の直前へ追加します。

配置イメージは次のとおりです。

/* Creators APIの設定をここへ追加 */

/* That's all, stop editing! Happy blogging. */

この目印より下には、WordPressを起動するための処理が続いています。

そのため、独自設定は目印の直前にまとめると管理しやすくなります。

H3-2　設定したCreators APIの項目

公開記事では、実際の認証情報を載せません。

次は説明用のダミーコードです。

/* =========================================================
 * APICE Amazon Creators API
 * ========================================================= */

define(
    'APICE_CREATORS_CREDENTIAL_ID',
    'ここに認証情報ID'
);

define(
    'APICE_CREATORS_CREDENTIAL_SECRET',
    'ここにシークレット'
);

define(
    'APICE_CREATORS_CREDENTIAL_VERSION',
    '3.3'
);

define(
    'APICE_CREATORS_PARTNER_TAG',
    '自分のトラッキングID'
);

define(
    'APICE_CREATORS_MARKETPLACE',
    'www.amazon.co.jp'
);

define(
    'APICE_CREATORS_CREDENTIAL_ISSUED_AT',
    '2026-07-15 10:40:00'
);

実際には、

ここに認証情報ID
ここにシークレット
自分のトラッキングID

の部分を、自分の情報へ置き換えます。

認証情報IDとシークレットは、記事やスクリーンショットへ掲載しません。

H3-3　スニペット本文へシークレットを書かなかった理由

認証情報をCode Snippetsのコード内へ直接書く方法もあります。

しかし今回は、秘密情報とプログラムを分離しました。

Code Snippetsのスニペットは、修正、コピー、共有を行う機会があります。

そのコード内にシークレットが含まれていると、

スニペットをほかの環境へコピーした
コード全文をチャットへ貼った
管理画面をスクリーンショットした
バックアップファイルを共有した

といった場面で、秘密情報まで漏れる可能性があります。

そこで、

秘密情報
→ wp-config.php

プログラム
→ Code Snippets

と役割を分けました。

これにより、診断スニペットを共有しても、認証情報そのものは含まれません。

H3-4　保存後にWordPressが開くか確認する

wp-config.phpを保存した後、最初に確認したのはWordPressが正常に動いているかどうかです。

次の画面を開きました。

TECNの公開ページ
WordPressのログイン画面
WordPressダッシュボード

WordPressダッシュボードは正常に表示されました。

これで、少なくとも追加したコードに大きなPHPの書式エラーがないことを確認できました。

画面が真っ白になったり、エラーメッセージが表示されたりした場合は、バックアップしたwp-config.phpへ戻します。

---

H2-5　WordPressが認証情報を読み込めるか確認する

H3-1　いきなりAPI通信をせず設定確認から始めた

wp-config.phpへ認証情報を追加できても、WordPressが正しく読み込めているかは、まだ分かりません。

そこで最初に、Amazonへ通信しない設定確認専用のスニペットを作りました。

スニペット名は次です。

APICE Amazon Creators API V1.0.0
00_Creators API設定確認

このスニペットの役割は、Creators APIへ接続することではありません。

wp-config.phpに追加した設定を、WordPressが読み込めているかを確認することです。

H3-2　秘密情報を表示せず設定状態を確認する

設定確認画面では、次の項目を表示しました。

認証情報ID：設定済み
シークレット：設定済み
認証情報バージョン：3.3
Partner Tag：設定済み
Marketplace：設定済み
認証情報発行日時：設定済み

ただし、シークレットの実際の値は表示しません。

認証情報IDについても、一部をマスクして表示します。

例えば、次のような考え方です。

完全な認証情報ID
→ 表示しない

先頭と末尾だけ残したマスク表示
→ 設定確認に利用

シークレット
→ 値は表示せず、設定済みかだけ確認

この画面なら、秘密情報を公開せずに、設定できていることを確認できます。

H3-3　発行からの経過時間も表示する

設定確認画面には、認証情報発行からの経過時間も表示しました。

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

今回の発行日時は次のとおりです。

2026年7月15日 10時40分

例えば、診断時には次のように表示されます。

正確な経過時間：3時間12分
ざっくり経過区分：3時間経過

【画像挿入位置】

画像03
Creators API設定確認画面
秘密情報は表示せず、設定済みと経過時間を確認できる状態

この段階では、まだAmazonへの通信は行っていません。

---

H2-6　Creators APIへ実際に接続する診断機能を作る

H3-1　設定確認とAPI接続診断は役割が違う

最初、設定確認スニペットを登録した時点で、

これでCreators APIへ接続できたのだろうか

と感じました。

しかし、設定確認とAPI通信は別の作業です。

今回、スニペットを次の2本に分けました。

00_Creators API設定確認
→ wp-config.phpの設定をWordPressが読めるか確認

01_Creators API基本接続・取得診断
→ Amazonへ実際に接続し、商品情報を取得

分けておくことで、問題が起きたときに、

WordPressが設定を読めていないのか
Amazonへの接続で失敗したのか

を切り分けられます。

H3-2　接続診断で確認する内容

実通信版の診断画面では、次を確認できるようにしました。

Amazonへ通信できるか
認証情報が受理されるか
商品情報が返るか
画像情報が返るか
HTTPステータス
APIエラーコード
APIエラーメッセージ
実行日時
認証情報発行からの経過時間

さらに、接続に成功した場合は、次の商品情報を表示します。

ASIN
商品名
ブランド
メーカー
型番候補
色候補
商品ページURL
商品特徴

画像についても、単に画像URLが取得できたかだけでなく、種類、枚数、幅、高さなどを確認します。

H3-3　接続結果を段階的に判定する

APIの結果を「成功」「失敗」だけで表示すると、原因が分かりません。

そこで、診断画面では次のように段階を分けました。

WordPressから通信できない
AmazonからHTTP応答がない
認証段階で拒否された
商品APIへのアクセスが許可されていない
指定したASINが見つからない
商品情報を取得できた
画像情報まで取得できた

例えば、Amazonからエラー応答が返ってきた場合でも、

Amazonへの通信自体はできている
商品情報の取得だけが失敗している

と判断できることがあります。

これにより、Amazon側の反映待ちと、プログラムの設定ミスを区別しやすくなります。

---

H2-7　Amazon商品URLからASINを自動抽出する

H3-1　ASINを知らない初心者でも使える画面にした

Creators APIで特定の商品を指定するには、ASINを使用します。

しかし、筆者は最初、ASINが何なのか分かりませんでした。

その状態で管理画面に、

ASINを入力してください

とだけ書かれていても、何を入力すればよいのか判断できません。

そこで入力欄の名称を、次のようにしました。

Amazon商品URL または ASIN

ASINを知っている人は、ASINを直接入力できます。

ASINが分からない人は、Amazonの商品ページURLをそのまま貼り付けます。

H3-2　Amazonの商品URLをそのまま入力できる

入力できる形式は、次の2種類です。

Amazonの商品URL：

https://www.amazon.co.jp/dp/B0FNQ3Z1FK

ASINのみ：

B0FNQ3Z1FK

検索結果から開いたAmazonの商品ページは、URLが非常に長くなる場合があります。

例えば、次のように商品名や検索情報が大量に付いていることがあります。

https://www.amazon.co.jp/商品名/dp/B0FNQ3Z1FK/ref=...

このような長いURLでも、そのまま入力できるようにしました。

H3-3　URLからASINを自動抽出する

今回のテストURLには、次の部分が含まれていました。

/dp/B0FNQ3Z1FK/

この10文字がASINです。

B0FNQ3Z1FK

診断スニペットは、Amazonの商品URLからこのASINを自動的に取り出します。

さらに、確認しやすいように、次の短いURLへ正規化して表示します。

https://www.amazon.co.jp/dp/B0FNQ3Z1FK

【画像挿入位置】

画像04
「Amazon商品URL または ASIN」の入力欄と
自動抽出されたASINが表示された診断画面

この仕様により、利用者はASINを自分で探す必要がありません。

普段見ているAmazonの商品ページURLをコピーし、貼り付けるだけです。

---

H2-8　Creators APIを実行して商品情報を取得する

H3-1　診断に使用したAmazon商品

今回の接続診断には、Sharkの商品ページを使用しました。

診断対象は次のとおりです。

ブランド：Shark
商品シリーズ候補：PowerClean 360
ASIN：B0FNQ3Z1FK

ただし、この段階ではTECNの商品マスターへ正式登録する商品とは決めていません。

今回のASINは、Creators APIが正常に動くかを確認するための診断対象です。

Amazon限定仕様や型番末尾の違いなどもあるため、商品マスターとの正式な対応付けは、返却データを確認した後に検討します。

H3-2　接続診断ボタンを押す

操作の流れは、次のとおりです。

Amazonの商品URLを入力
↓
URLからASINを自動抽出
↓
Creators API接続・取得診断を実行
↓
WordPressからAmazonへAPI通信
↓
Amazonから応答を受信
↓
結果をWordPress管理画面へ表示

ボタンを押すまでは、Amazonへの通信は行われません。

入力内容を確認し、診断実行ボタンを押した時点で、初めてCreators APIへ商品情報を問い合わせます。

H3-3　取得できた商品情報

接続に成功し、指定した商品の情報が返りました。

診断画面では、次の項目を確認できました。

ASIN
Amazon上の商品名
ブランド
メーカー
型番候補
色候補
商品ページURL
商品特徴

Creators APIから返されるAmazonの商品タイトルには、ブランド、シリーズ、型番、色、限定仕様などが含まれることがあります。

そのため、このタイトルをそのままTECNの商品表示名にするのではなく、後から読者向けに整理する必要があります。

今回は、情報を取得できたことを確認する段階です。

H3-4　商品画像情報も取得できた

商品画像についても情報が返りました。

診断画面では、次の内容を確認できます。

Primary画像
Variant画像
画像URL
画像サイズ区分
画像の幅
画像の高さ
縦横比
画像レコード数
ユニーク画像URL数
最大画像サイズ

同じ画像でも、Small、Medium、Largeなどのサイズ違いとして複数返ることがあります。

そのため、

APIから返った画像レコード数
実質的に異なる画像の枚数

を分けて考える必要があります。

次回の記事では、実際にどのような画像情報が返ったのかを詳しく確認し、商品カードとして表示する方法を試します。

---

H2-9　認証情報発行から約3時間で接続に成功

H3-1　認証情報を2026年7月15日10時40分に発行

今回、Creators APIの認証情報を発行した日時は次のとおりです。

2026年7月15日 10時40分

認証情報発行後、利用可能になるまで時間がかかる場合を想定し、発行時刻を診断画面へ設定しました。

H3-2　最大48時間を想定していた

Creators APIの画面には、認証情報を発行してからアクセスが付与されるまで、時間がかかる場合があるという趣旨の案内がありました。

そこで当初は、次のタイミングで繰り返し確認する予定でした。

2時間後
4時間後
8時間後
12時間後
24時間後
36時間後
48時間後

診断履歴には、実行日時、発行からの経過時間、成功・失敗、エラー情報を残します。

同じASINと同じ条件で繰り返すことで、どの時点で結果が変わったかを確認できます。

H3-3　TECN環境では約3時間後に取得成功

結果として、TECN環境では認証情報の発行から約3時間後にCreators APIへ接続できました。

実行環境：
Xserver
WordPress
Code Snippets
Amazon.co.jp

認証情報発行：
2026年7月15日 10時40分

初回成功：
認証情報発行から約3時間後

Amazonの商品URLからASINを自動抽出し、商品情報と画像情報が正常に返りました。

ただし、すべての利用者が3時間で利用可能になるという意味ではありません。

アカウントの状態やAmazon側の確認状況などにより、反映時間は異なる可能性があります。

記事では、

TECNの検証環境では、認証情報発行から約3時間後に商品情報取得へ成功しました。

という実測結果として紹介します。

【画像挿入位置】

画像05
Creators API接続成功画面
認証情報発行から約3時間と表示された状態

H3-4　構想から実現可能な開発へ変わった

今回の接続成功は、単にAPIが動いたというだけではありません。

これまで構想として考えていた次の仕組みを、実際のデータで検証できるようになりました。

商品情報の自動取得
商品画像の確認
商品候補の生成
商品キャッシュの半自動作成
ブランド別の商品一覧
カテゴリ別の商品一覧
商品詳細カード
記事への商品表示

商品マスターや記事生成の自動化が、単なるアイデアではなく、実際に設計できる段階へ進みました。

---

H2-10　Creators API接続診断で分かったこと

H3-1　Amazon側への通信と商品取得を確認できた

今回の診断で、次のことを確認できました。

WordPressからAmazonへ通信できた
発行した認証情報を利用できた
Amazon商品URLからASINを抽出できた
指定した商品の情報を取得できた
商品画像情報を取得できた
生のレスポンスデータを確認できた

これにより、TECNのAmazonアソシエイト環境で、Creators APIの商品情報取得機能を実際に利用できることが確認できました。

H3-2　商品シリーズの整理は次の段階

Creators APIから取得した情報を、そのまま商品マスターへ登録するわけではありません。

Amazonでは、同じ商品シリーズでも次の違いによって別の商品ページやASINが存在することがあります。

色違い
型番末尾違い
Amazon限定モデル
付属品違い
セット商品
容量違い
世代違い

TECNでは、個別の型番やASINを大量に並べるのではなく、読者にとって分かりやすい商品シリーズや主要モデルとして紹介したいと考えています。

その整理ルールは、複数商品の実データを比較した後に決めます。

H3-3　システム構築は初心者も参加できる時代になった

今回、筆者はAPIの専門家として作業したわけではありません。

最初は、

wp-config.phpはどこにあるのか
ASINとは何か
認証情報はどこへ入れるのか
設定確認とAPI通信は何が違うのか

というところから始めました。

それでも、チャッピーと相談しながら、

サーバー内のファイルを探す
設定位置を確認する
バックアップを取る
コードを登録する
APIを実行する
結果を確認する

ところまで進めました。

もちろん、本番運用のセキュリティ、大量データ処理、障害対応、保守設計には、専門家の知識が重要です。

しかし、現場の担当者や経営者がAIと会話しながら、小さな試作や検証へ参加できるようになりました。

システム構築は、完成した仕様書をエンジニアへ渡して待つだけのものではなくなりつつあります。

現場で課題を知る人が、AIと一緒に仕組みを育てられる時代になっています。

---

H2-11　次回は取得した商品情報を画面に表示してみる

H3-1　商品情報と画像の返却内容を詳しく確認する

次回は、Creators APIから実際に取得できた内容を詳しく確認します。

Amazonの商品名
ブランド
メーカー
型番候補
色候補
商品特徴
商品画像の種類
画像の枚数
画像サイズ
画像の縦横比
最大画像サイズ

Amazonの商品情報と、TECNの記事に必要な情報が同じとは限りません。

どの項目をそのまま使えるのか、どの項目は編集が必要なのかを分類します。

H3-2　商品カードの簡易テンプレートを作る

取得した商品情報と画像を使い、WordPressの記事内で利用できる簡易商品カードを作る予定です。

例えば、次のような表示です。

ブランドごとの代表商品一覧
カテゴリごとの商品一覧
一つの商品を詳しく紹介するカード
画像を中心に見せる商品カード
複数商品を並べた比較表示

同じ商品データを使いながら、記事の目的に応じてデザインを使い分けられるようにします。

H3-3　Creators APIの応用範囲を実際の画面で見せる

今回、Creators APIへ接続できることは確認できました。

次回は、

APIから商品情報を取得
↓
取得内容を整理
↓
画像と説明を商品カードへ配置
↓
WordPressの記事内で表示

という流れを、実際の画面で試します。

Creators APIは、商品情報を取得できるだけの仕組みではありません。

商品マスター、商品一覧、比較記事、更新作業の効率化など、さまざまな仕組みへ発展させられます。

次回は、その可能性を目に見える形にしていきます。