はじめに
ブログを自動化していくとき、最後まで難しいのがアフィリエイト連携です。記事本文の生成や投稿は標準APIで完結しますが、商品紹介のショートコード管理だけは、プラグイン側の都合に振り回されます。
私のブログではRinkerをアフィリエイトの中核に置いています。AmazonアソシエイトとValueCommerceの商材を、見た目を統一して表示するための事実上の標準プラグインです。ただし、Rinker単体では自動投稿フローと噛み合わない部分があり、functions.phpの拡張で橋渡しを作る必要がありました。
この回は、その橋渡しの設計判断を記録します。
標準Rinkerの構造とその限界
Rinkerは、WordPress内で「商品データベース」を持つ仕組みです。商品ごとに固有のpost_idが振られ、本文にはという形のショートコードを書き、表示時に商品ボックスに展開されます。
この仕組みは手動運用には十分ですが、自動投稿フローに組み込もうとすると三つの壁にぶつかります。
順に解きほぐします。
壁1は、Rinker公式が商品登録のREST APIエンドポイントを提供していないことです。商品を増やすたびにWP管理画面で操作するか、データベースを直接いじるかの二択になります。
壁2は、商品post_idと原稿の対応関係を、自前で持つ必要があることです。原稿に直接post_idを書くと、商品データを再生成したときに番号がずれて、過去記事が一斉に壊れます。
壁3は、商品の価格や取扱状況が変わったとき、それを記事側に通知する仕組みがないことです。Amazon側で取扱終了になった商品のリンクは、リンク切れのまま放置されます。
自動化のために置いた三つの拡張
これら三つの壁を、WordPressのfunctions.phpに独自関数を追加して解決します。プラグインは公式の更新で上書きされる可能性があるので、テーマ側のfunctions.php（または子テーマ）で拡張する形が安全です。
各拡張の中身を順に見ていきます。
拡張1：商品登録エンドポイント
WordPressのREST APIで独自エンドポイントを追加するのは、register_rest_route()を呼ぶだけです。
add_action('rest_api_init', function() {
register_rest_route('custom/v1', '/rinker', [
'methods' => 'POST',
'callback' => 'register_rinker_product',
'permission_callback' => 'verify_admin_app_password',
]);
});
register_rinker_product関数の中で、Rinkerが内部的に使っている商品登録ロジックを呼び出します。Rinkerのソースを読んで、商品データの保存先テーブルとカラム構造を確認した上で、必要なフィールドを書き込みます。
このエンドポイントを叩く側は、Chrome拡張が出力するJSON（amazon_affiliate_*.json）をペイロードに乗せます。商品名、ASIN、価格、画像URL、アフィリエイトリンクが入った辞書を渡して、新規post_idを返してもらう、という流れです。
拡張2：商材IDマッピング管理
私のブログの原稿には、商品の「読者から見える名前」をスラッグ風に書いています。たとえばdrucker-management-essenceのような形です。これを、Rinker側のpost_idに変換するエンドポイントを置きます。
原稿は「人間が読んで意味のある名前」だけを持ち、内部IDの世界には触れない。これは第3回で扱った人間が書く領域と機械が読む領域の分離を、Rinker側にも拡張した形です。
拡張3：商品データ更新検知
Rinkerの商品データを更新したとき（価格を直したり、リンクを差し替えたりしたとき）、その商品を使っている記事一覧をログ出力するフックを入れます。
ここはあえて自動修正をしません。価格変動や取扱終了の事実は記事の内容に直結するため、機械的に置換すると本文と矛盾する可能性があります。検出と通知だけを自動化して、対応は人間が判断する。これも「止まる方が、進むより安全」の原則です。
認証とセキュリティ
独自エンドポイントを置くと、認証が一番の悩みどころになります。商品データは原稿よりむしろ書き換え影響が大きいため、保護を強くします。
ここでの判断点は二つあります。
判断1：アプリケーションパスワードを使う、JWTは使わない
WordPress 5.6以降で標準搭載されたアプリケーションパスワード機能を使います。JWTやOAuthはWordPress側の追加プラグインが必要で、複雑度に見合うメリットがありませんでした。一人運営では、ユーザーごとに発行・無効化できる仕組みがあれば十分です。
判断2：IP制限を追加する
アプリケーションパスワードに加えて、特定IPからのリクエストのみ受け付ける制限を入れます。アプリケーションパスワードが漏洩しても、攻撃元のIPが制限外なら一段防げます。自宅IPが固定でない場合は、固定IPのVPS経由に絞るなどの組み合わせが現実的です。
商材IDから記事への注入フロー
ここまでの拡張が揃うと、原稿から記事公開までの一連の流れが組み上がります。
このフロー全体を冪等に保つことが大事です。同じ原稿で再実行しても、商品が二重登録されないように、商材スラッグでの存在確認を必ず先に行います。
標準Rinkerと拡張Rinkerの違いを言語化
設計判断を表でも整理しておきます。
| 観点 | 標準Rinker | 拡張Rinker（本記事の設計） |
|---|---|---|
| 商品登録 | WP管理画面 | REST API経由 |
| 原稿との対応 | post_id直書き | スラッグ経由で抽象化 |
| データ更新通知 | なし | save_postフックで検知 |
| 認証 | WPログイン | アプリケーションパスワード＋IP制限 |
| 自動投稿との適合 | 手作業前提 | 完全自動化可能 |
標準のRinkerが悪いわけではありません。手動でブログを書く前提では、これ以上の機能は過剰です。自動化フローを組み上げるという特殊用途でのみ、ここまでの拡張が必要になります。
設計時に却下した代替案
案：Rinkerを使わず、自前で商品ボックスを実装
Rinkerに依存しない構成として、商品ボックスを自前のショートコードとテンプレートで実装する案もありました。
却下した理由は、機能の豊富さです。Rinkerは価格表示、複数モールリンク、アコーディオン、レスポンシブ対応、A/Bテスト機能を全部持っています。これを自前でゼロから作る工数は、得られる柔軟性に見合いません。Rinkerが提供する基盤の上に独自エンドポイントを足す形が、コストパフォーマンスとして最適でした。
案：商品データをGitリポジトリで管理
商品データをWordPressの外（YAMLやJSONファイル）に置いて、Gitで管理する案もありました。
却下した理由は、Rinkerの表示機能と切り離せないことです。WP内部のpost_idと紐づいた状態で表示しているので、外に出すと表示時の連携が崩れます。商品データの所在をWordPress内に集約しておく方が、表示と管理の一貫性が保てます。
案：Rinker依存をやめて、Amazon PA-APIを直接叩く
中長期で見れば、Rinkerが開発停止する可能性もゼロではありません。AmazonのProduct Advertising API（PA-API）を直接叩いて、自前で商品表示を組む案も検討しました。
却下した理由は、PA-APIの利用条件の厳しさです。直近一定期間の売上実績がないとAPI利用が停止される条件があり、個人ブログでは安定運用しづらい。Rinkerに依存するリスクと、PA-API利用条件のリスクを比べて、現状はRinker依存の方が現実的という結論でした。これは将来見直す可能性のある判断です。
次回予告
次回は 画像処理パイプライン を扱います。WebP変換のタイミング、alt属性の自動付与判断、CDN連携、失敗時のフォールバック。記事の見た目とSEO・表示速度の両方に効く、画像周りの設計判断を解説します。
このシリーズで紹介する設計は、執筆時点の各ツールバージョンに基づきます。Claude Code、MCP、WordPress、各種APIは仕様変動が大きいため、最新ドキュメントとの照合をおすすめします。
