【実践シリーズ① 第1回】Codex + MCPでAIアフィリエイト支援システムを設計してみる〜商品情報取得・DB蓄積・記事作成・WordPress連携〜

Last updated at 2026-10-07Posted at 2026-09-16

第1回 Codex + MCPでAIアフィリエイト支援システムを設計してみる

はじめに

現在、アフィリエイト記事の作成や商品選定を支援するツールやサービスは数多く存在します。しかし、今回はあえて既存のサービスを利用するのではなく、Codexと自作MCP Serverを活用して、AIアフィリエイト支援システムを自分で構築してみることにしました。

本シリーズでは、その開発過程を記録として残すとともに、商品情報の取得、PostgreSQLへの保存、商品・キーワード選定、記事生成、WordPressへの下書き登録までを行うシステムを、全3回にわたって構築していきます。

商品データの取得元には、日本語の商品情報が豊富で、アフィリエイトリンクも取得できる楽天市場商品検索API（楽天ウェブサービス）を採用します。

開発はWindowsのローカル環境で行い、Codexから自作MCP Serverを呼び出す構成とします。

単にシステムを完成させるだけでなく、CodexとMCP Serverを組み合わせることで、どこまで開発や作業を自動化できるのかを実際に試し、その手順や得られた知見を記事として残していきます。

第1回は、その全体像を設計する回です。実装は第2回・第3回で行い、第3回でAffiliate MCP Serverの完成を目指します。

システム全体構成

本システムでは、人間がCodexへ指示し、Codexが自作のMCP Serverを通じて外部システム（楽天API・PostgreSQL・WordPress）とやり取りします。

Codexが「考える・書く・判断する」を担当し、MCP Serverが外部システムとの境界になり、PostgreSQLが事実を保持します。

各要素の役割

本システムでは、Codex、MCP Server、PostgreSQL / 楽天API / WordPressで役割を分担します。

役割	担当	具体例
考える・書く・解釈する	Codex	商品候補の評価、商品選定、キーワード選定、記事構成の作成、本文の生成
つなぐ・実行する	Affiliate MCP Server（Python）	楽天API・WordPress REST APIの呼び出し、データ整形、PostgreSQLへの読み書き
データを保持する	PostgreSQL / 楽天API / WordPress	商品情報、記事情報の保持・提供

1. 全体フロー

記事を下書き登録するまでの流れ

第1回から第3回で作るのは、人間の指示を起点に、商品取得から記事のWordPress下書き登録までを行う流れです。

人間
 ↓
Codexへ指示
 ↓
Product Tools
 ↓
楽天API
 ↓
PostgreSQLへ商品保存
 ↓
Codexが商品選定
 ↓
Codexがキーワード選定
 ↓
Codexが記事生成
 ↓
Article Tools
 ↓
PostgreSQLへ記事保存
 ↓
WordPress Tools
 ↓
WordPressへ下書き登録
 ↓
人間が確認

各ステップの内容は次の通りです。

① 人間がCodexへ指示する
「売れ筋商品から記事を作って」といった指示をCodexへ与え、処理を開始します。

② Codexが商品取得用のMCP Toolを呼び出す
CodexはMCP Serverが提供する商品取得Toolを呼び出します。

③ 楽天APIから商品情報を取得する
MCP Serverが楽天APIを呼び出し、ランキング、商品名、価格、レビュー、商品URLなど、記事作成に必要な商品情報を取得します。

④ 商品情報をDB（PostgreSQL）へ保存する
MCP Serverが取得した商品情報を整形し、PostgreSQLへ保存します。すでに登録されている商品については、必要に応じて情報を更新します。

⑤ 商品情報をCodexへ返す
MCP ServerがPostgreSQLに保存した商品情報から、記事作成に必要なデータを取得し、MCP Toolの実行結果としてCodexへ返します。

⑥ Codexが記事化する商品を選定する
Codexがランキング、価格、レビュー件数、評価などの商品情報をもとに、記事化する商品を選定します。

⑦ Codexがキーワードを選定する
選定した商品の特徴、想定読者、検索意図などを考慮し、記事で使用するキーワードを決定します。

⑧ Codexが記事を生成する
商品情報とキーワードをもとに、記事タイトル、記事構成、本文などを生成します。

⑨ 記事情報をDB（PostgreSQL）へ保存する
CodexがArticle Toolsを呼び出し、対象商品、キーワード、記事タイトル、本文、作成日時などの記事情報をPostgreSQLへ保存します。

⑩ WordPressへ記事を下書き登録する
CodexがWordPress Toolsを呼び出すと、MCP ServerからWordPress REST API経由で記事をWordPressへ登録します。自動公開ではなく下書き登録とし、人間が内容を確認してから公開します。

収益性について: どのAPI・ASPを使うかだけで収益が決まるわけではありません。実際の成果は、扱うジャンル・検索流入・記事のCVR・報酬率などに大きく左右されます。本シリーズは「仕組みの作り方」を学ぶことが目的です。

前提となる記事: 本記事は、以下の入門編・発展編を読んで、MCPの仕組みとPythonでのMCP Server自作を理解していることを前提にしています。

【発展編】PythonでMCP Serverを作ってCodexから使ってみる

2. この記事のゴール

CodexをAIインターフェース、自作のAffiliate MCP Serverを業務機能との接続層、PostgreSQLをデータ基盤として、**商品情報の取得 → データ蓄積 → 記事作成 → WordPress連携（下書き登録）**までを行う、AIアフィリエイト支援システムの全体設計を理解します。

「Codexが全部やる」のではなく、Codexは判断・指示・文章生成を担当し、MCP Serverが外部システムとの境界になり、DBが事実を保持する。MCPを使うこと自体が目的ではなく、AIと既存システム・データ・業務処理の境界をToolとして設計することが目的です。

シリーズ全体の構成（全3回）

シリーズ全体の構成は、次のようになります。本シリーズは第3回でAffiliate MCP Serverの完成を目指します。

回	記事タイトル	ゴール
第1回	Codex + MCPでAIアフィリエイト支援システムを設計してみる（本記事）	システム・MCP Tool・DBを設計する
第2回	楽天APIから商品情報を取得してPostgreSQLへ保存してみる	Product Toolsを実装する
第3回	Codexで商品・キーワード選定、記事生成、WordPress連携してみる	Article / WordPress Toolsを実装し、Affiliate MCP Serverを完成させる

後続シリーズについて: 完成したMCP ServerをLinux VPSへ配置し、OpenAI APIとAutomation Workerを組み合わせてWordPress記事作成を自動化する方法は、別シリーズ「AIアフィリエイト自動運用編」で扱います。さらに、公開後の成果データの収集・分析・記事改善についても、別シリーズとして扱う予定です。

3. MCP ServerのTool設計

独自MCP Serverを窓口にする

本シリーズでは、独自のMCP Serverを唯一の窓口（境界）にする設計を採ります。

メリット	内容
認証情報を1か所に集約	APIキー・DBパスワード・トークンをMCP Server側で管理する（詳細は「7. 認証情報の管理」）
処理の標準化	「商品を検索する」といった処理を、取得元が異なっていても、統一されたインターフェースのToolとして提供できる
安全性	「WordPressは下書き登録まで」など、Toolでできることを限定できる（誤操作を防ぐ）
再利用性	一度作ったToolは、さまざまな依頼で使い回せる

Affiliate MCP Serverが提供するToolを、機能ごとに整理します。第2回・第3回でこれらを段階的に実装していきます。

Affiliate MCP Server
│
├─ Product Tools
│   ├─ get_ranking_products()
│   ├─ search_products()
│   ├─ get_product()
│   ├─ get_product_detail()
│   └─ save_product()
│
├─ Article Tools
│   ├─ list_article_candidates()
│   ├─ check_duplicate_article()
│   └─ save_article()
│
└─ WordPress Tools
    ├─ create_draft()
    ├─ get_post()
    └─ update_draft()

Product Tools：楽天APIからランキング・検索・商品詳細を取得し、PostgreSQLへ保存する（第2回で実装）
Article Tools：記事化候補の抽出、重複記事チェック、記事情報の保存を行う（第3回で実装）
WordPress Tools：WordPress REST API経由で下書きの作成・取得・更新を行う（第3回で実装）

4. データの流れとDB設計

データライフサイクル

本システムにおける基本的なデータライフサイクルです。商品情報の取得元には楽天市場商品検索APIを使います。

楽天市場商品検索API
   ↓
商品情報取得
   ↓
PostgreSQLへ保存
   ↓
Codexによる商品選定
   ↓
キーワード選定
   ↓
記事生成
   ↓
PostgreSQLへ記事保存
   ↓
WordPressへ下書き登録

DB設計

データライフサイクルを支えるDBは、最初から複雑なスキーマは不要です。第2回・第3回で実装・利用するのは、次の3テーブルです。

products：紹介する商品の基本情報（商品コード・商品名・価格・URL・アフィリエイトリンク・カテゴリ・レビュー、記事生成で使う画像URL・キャッチコピー・商品説明）。楽天APIの itemCode / itemName / itemPrice / itemUrl / affiliateUrl / genreId を、それぞれ item_code / name / price / url / affiliate_url / genre_id に対応させて保存します。
product_attributes：商品カテゴリによって異なる詳細スペック（例: CPU = Core Ultra 7）を、属性名・属性値のペアで保存します。より詳細な比較記事が必要になったときに利用します（第3回以降、必要時）。
articles：商品をもとに作成した記事（記事本文・キーワード・WordPressの投稿IDや公開ステータスを保持）。

補足: 楽天APIのフィールド名をDBの列名へ変換するのはMCP Serverの役割です（「MCP Serverは境界」という責務分離）。DBやCodexから見たデータの形を、APIの都合に振り回されないようにします。

5. 設計の考え方 ―「失敗前提」と設計・レビューの区別

本格的な実装に入る前に、このシステムを貫く2つの設計スタンスを整理しておきます。

「失敗前提」で設計する

外部APIやDBとの連携では、通信エラー・タイムアウト・接続断などの失敗を前提として設計します。「外部APIは失敗する」「DB接続は切れる」「WordPress APIは失敗する」「AIは誤った文章を生成する」ことを、あらかじめ織り込んでおきます。

具体的な Retry / Timeout / Transaction / Idempotency（冪等性）などの仕組みは、後述する「6. システム全体を横断する非機能要件」で整理します。また、AIが生成した記事を人間の確認なしに公開しない、という運用ルールについても、同じく非機能要件（Governance）で扱います。

「設計」と「レビュー」は役割が違う

もう1つ、区別しておきたいのが「設計」と「レビュー」の違いです。

非機能要件（後述の6章）：システムをどう設計するか（安全に・壊れにくく・追跡できるように作る）
Well-Architectedレビュー（この章の後半）：その設計が適切かをどう評価するか（公開された設計フレームワークの観点で点検する）

両者は似た言葉（SecurityやReliabilityなど）が出てきますが、「作るための指針」と「評価するためのものさし」という違いがあります。

Well-Architectedの観点で評価する

AWS Well-Architected Frameworkは、アーキテクチャを次の6本柱で評価します。

Operational Excellence（運用の優秀性）
Security（セキュリティ）
Reliability（信頼性）
Performance Efficiency（性能効率）
Cost Optimization（コスト最適化）
Sustainability（持続可能性）

（AWS Well-Architected Framework）

Microsoftの Azure Well-Architected Framework も、上記を柱に、設計上のトレードオフを継続的に評価する構造を採っています。（Azure Well-Architected Framework）

※ 上記は各社が公開している設計フレームワークの内容にもとづいています（内容は要約のうえ、ライセンス上の配慮から表現を調整しています）。

これらの観点を、Affiliate MCPに落とし込むと次のようになります。

観点	Affiliate MCPで確認すること
Reliability（信頼性）	API障害時に壊れないか
Security（セキュリティ）	APIキー・DBパスワードをコードに書いていないか
Performance（性能）	大量商品を扱えるか
Operations（運用）	ログから障害原因を追えるか
Data（データ）	DBに正しいデータが保存されているか
AI Quality（AI品質）	AIの生成内容を検証できるか
Compliance（規約遵守）	ASP・EC・広告表示ルールを守れるか

6. システム全体を横断する非機能要件

ここまで見てきた機能は、「商品を取得する」「記事を作る」といった、システムが何をするかに関するものです。一方で、実際にシステムを使うためには、機能そのものだけでなく、

安全に使えるか
障害が起きても止まりにくいか
問題が起きたときに原因を追えるか
AIや外部サービスを適切に使えているか

といった点も重要になります。これらは、特定のToolだけに必要なものではなく、システム全体に共通して必要となる設計上の考え方です。本システムでは、次の4つを特に重要な非機能要件として考えます。

1. Security：安全に利用するための仕組み

Securityでは、APIキーやデータベースのパスワードなど、重要な情報を安全に管理します（具体的な方針は「7. 認証情報の管理」で説明します）。ソースコードにキーやパスワードを直書きせず、環境変数から読み込みます。加えて、最小権限（その処理に必要な権限だけを与える）が重要です。例えばWordPress連携で記事の下書き登録だけを行うのであれば、必要以上にサイト全体を管理できる権限を与えないようにします。

2. Reliability：エラーが起きても壊れにくくする

外部APIやデータベースを利用するシステムでは、通信エラーやタイムアウトが発生する可能性があります。そのため、次のような仕組みを用意します。

Reliability
├─ Retry
├─ Timeout
├─ Transaction
└─ Idempotency

Retryは、一時的な通信エラーが発生した場合に処理を再試行する仕組みです。
Timeoutは、外部APIから応答が返ってこない場合に、いつまでも待ち続けないための仕組みです。
Transactionは、複数のDB処理をひとまとまりとして扱い、途中で失敗した場合に中途半端な状態を残さないために利用します。
**Idempotency（冪等性）**は、同じ処理が複数回実行されても、結果がおかしくならないようにする考え方です。例えば、同じ商品を何度取得しても、DBに重複行が増えないようにします。

3. Observability：何が起きたのか分かるようにする

システムで問題が発生した場合、「なぜ失敗したのか」が分からなければ、原因を調査できません。そこで、次を用意します。

Loggingでは、いつ、どのToolが、どのような処理を実行したのかを記録します。例えば、

2026-09-11 10:00
search_products 実行
検索キーワード: ノートPC
取得件数: 20件

といった情報を残しておけば、後から処理内容を確認できます。あわせて、発生したエラーを記録し、どの処理で問題が起きたのかを追跡できるようにします。

4. Governance：AIや外部サービスを適切に利用する

AIアフィリエイト支援システムでは、技術的に動作するだけでは十分ではありません。生成された内容や外部サービスの利用方法についても確認する必要があります（なぜ確認が必要かは「8. アフィリエイト規約・広告表示・AI生成コンテンツの注意点」で説明します。ここではどう仕組みで実現するかを扱います）。

Human approvalでは、AIが生成した記事をそのまま公開せず、人間が確認してから公開する流れにします。

Codexで記事生成
      ↓
MCP Server
      ↓
WordPressへ下書き登録
      ↓
人間が内容を確認
      ↓
公開

また、同じ商品・キーワードの記事を重複して作らないようにする重複記事防止も、Governanceの一部として扱います。楽天アフィリエイトや楽天ウェブサービスなどを利用する場合は、それぞれのサービスが定めている広告・アフィリエイト・API利用の規約を確認します。AIが生成した文章についても、「商品価格が正しいか」「存在しない機能を書いていないか」「誇張表現になっていないか」「古い商品情報を使っていないか」などを確認します。

4つの非機能要件のまとめ

非機能要件	目的
Security	安全に使う
Reliability	エラーが起きても壊れにくくする
Observability	何が起きたのか分かるようにする
Governance	AIや外部サービスを適切に利用する

これらは個別のToolだけに必要なものではなく、Affiliate MCP Server全体に共通して適用する設計ルールとして考えます。

7. 認証情報の管理

楽天API・WordPress・DBにアクセスするには、楽天のアプリID・アフィリエイトID・WordPressトークン・DBパスワードといった認証情報が必要です。これらは環境変数での管理が前提です。認証情報は、次のようにMCP Server側へ閉じ込めます。

Codex
  │
  ▼
MCP Server
  │
  ├─ RAKUTEN_APP_ID
  ├─ RAKUTEN_AFFILIATE_ID
  ├─ WORDPRESS_TOKEN
  └─ DATABASE_URL

原則は次の3つです。

コードに直接書かない：server.py にキーやパスワードを直書きしない。
環境変数などで管理する：.env ファイルや環境変数から読み込む。
リポジトリに含めない：.env は .gitignore に追加し、Gitにコミットしない。

「認証情報はMCP Server側に閉じ込め、Codexには渡さない」という方針を、最初に決めておきます。

8. アフィリエイト規約・広告表示・AI生成コンテンツの注意点

技術以外に、必ず押さえておくべき点があります。ここでは**「なぜ人間の確認が必要なのか」という理由を整理します（それをどう仕組みで実現するか**は、非機能要件のGovernanceで扱いました）。

アフィリエイト規約：利用するASP・ECサービス・広告主ごとに、リンクの生成方法・使用可能な画像・価格表示の条件などのルールがあります。必ず各サービスの最新規約を確認してください。
広告表示：アフィリエイトを含む記事には、「広告」「PR」などの表示が求められる場合があります（景品表示法のステルスマーケティング規制など）。適切な表記を行ってください。
AI生成コンテンツ：AIが生成した文章には、事実誤認（ハルシネーション）が含まれることがあります。特に価格・仕様・成分などの事実は、必ず一次情報で裏取りしてください。本シリーズで「LLMの記憶だけで書かせない」ことを繰り返し強調し、DBに保存した事実を根拠にさせるのは、このためです。

重要: 本シリーズはシステムの作り方を学ぶことが目的です。実際の運用にあたっての規約遵守・法令遵守・事実確認は、自身の責任で行ってください。

まとめ

第1回では、Codexと自作MCP Serverを組み合わせたAIアフィリエイト支援システムの全体設計を行いました。本シリーズは、次の3回でAffiliate MCP Serverの完成を目指します。

第1回
Affiliate MCP Serverを設計
 ↓
第2回
Product Tools
楽天API
PostgreSQL
 ↓
第3回
Article Tools
WordPress Tools
Codexによる記事生成
 ↓
Affiliate MCP Server完成

項目	ポイント
何を作るか	商品取得 → DB蓄積 → 記事作成 → WordPress下書き登録までを行うシステム
実行の起点	人間がCodexへ指示して処理を開始する
開発環境	Windowsのローカル環境でCodexから自作MCP Serverを使う
中心となる考え方	Codexは判断・生成、MCP Serverは境界、DBは事実の保持という責務分離
なぜMCP自作か	AIと既存システム・データの境界をToolとして設計するため
Tool設計	Product / Article / WordPress の3カテゴリで整理
データ基盤	PostgreSQLに products / product_attributes / articles を蓄積する
失敗前提の設計	非機能要件（Reliability）で timeout / retry / 冪等性 / transaction を整える
設計とレビュー	「どう作るか（非機能要件）」と「適切かをどう評価するか（Well-Architected）」を区別
認証情報	環境変数でMCP Server側に閉じ込め、Codexには渡さない
注意点	アフィリエイト規約・広告表示・AI生成コンテンツの事実確認

本シリーズは第3回でAffiliate MCP Serverの完成を目指します。完成したMCP ServerをLinux VPSへ配置し、OpenAI APIとAutomation Workerを組み合わせてWordPress記事作成を自動化する方法については、別シリーズ「AIアフィリエイト自動運用編」で扱います。さらに、公開後の成果データの収集・分析・記事改善についても、別シリーズとして扱う予定です。

次回・第2回からは、いよいよ実装を開始します。発展編で作ったMCP Serverをベースに、楽天APIへアクセスする商品情報取得Tool（search_products() / get_ranking_products() / get_product()）を追加し、取得した売れ筋商品をPostgreSQLへ保存する、商品収集・保存基盤を作ります。

シリーズ記事一覧

LinuxにWordPressを構築して独自ドメインでHTTPS公開するまで ― インストール手順とシェルスクリプトによる自動化
 【実践第1回】Codex + MCPでAIアフィリエイト支援システムを設計してみる〜商品情報取得・DB蓄積・記事作成・WordPress連携〜
【実践第2回】楽天商品をPythonのMCP Serverで取得・DB蓄積してみる〜商品検索・ランキング取得・保存まで〜
【実践第3回】Codexに商品・キーワードを選定させてアフィリエイト記事を作成してみる〜商品評価・キーワード選定・記事生成・WordPress下書き登録まで〜

参考

※ 参考資料の内容は要約し、ライセンス上の配慮から表現を調整しています。API・アフィリエイトの仕様や規約は更新されることがあるため、実装前に公式の最新情報を確認してください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

【実践シリーズ① 第1回】Codex + MCPでAIアフィリエイト支援システムを設計してみる 〜商品情報取得・DB蓄積・記事作成・WordPress連携〜