【実践第1回】Codex + MCPでAIアフィリエイト支援システムを設計してみる〜商品情報取得・DB蓄積・記事作成・Next.jsサイトでの公開〜

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

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

はじめに

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

本シリーズでは、その開発過程を記録として残すとともに、商品情報の取得、PostgreSQLへの保存、商品・キーワード選定、記事生成、Next.js（TypeScript・CSS）で作る自前のWebサイトでの公開までを行うシステムを、全3回にわたって構築していきます。

商品データの取得元には、日本語の商品情報が豊富で、アフィリエイトリンクも取得できる楽天市場商品検索API（楽天ウェブサービス）を採用します。記事の掲載先には、WordPressなどのCMSではなく、Next.jsで作る通常のWebサイトを使います。記事はPostgreSQLに1か所で保存し、サイトはそれを読み取って表示します。

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

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

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

システム全体構成

本システムでは、人間がCodexへ指示し、Codexが自作のMCP Serverを通じて外部システム（楽天API・PostgreSQL）とやり取りします。Next.jsの記事サイトは、PostgreSQLから公開済みの記事を読み取って表示します。

Codexが「考える・書く・判断する」を担当し、MCP Serverが外部システムとの境界になり、PostgreSQLが事実と記事を保持し、Next.jsのサイトが公開済みの記事を表示します。記事を公開するかどうかは、人間が決めます。

各要素の役割

本システムでは、Codex、MCP Server、PostgreSQL / 楽天API、Next.jsの記事サイト、人間で役割を分担します。

役割	担当	具体例
考える・書く・解釈する	Codex	商品候補の評価、商品選定、キーワード選定、記事構成の作成、本文の生成
つなぐ・実行する	Affiliate MCP Server（Python）	楽天APIの呼び出し、データ整形、PostgreSQLへの読み書き（記事は下書きの保存・更新まで）
データを保持する	PostgreSQL / 楽天API	商品情報、記事（本文・公開状態）の保持・提供
記事を表示する	Next.jsの記事サイト（TypeScript・CSS）	公開済みの記事の一覧・詳細、下書きのプレビュー（ローカルだけ）
確認して公開する	人間	プレビューで内容を確認し、公開スクリプトで公開する

1. 全体フロー

記事を公開するまでの流れ

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

人間
 ↓
Codexへ指示
 ↓
Product Tools
 ↓
楽天API
 ↓
PostgreSQLへ商品保存
 ↓
Codexが商品選定
 ↓
Codexがキーワード選定
 ↓
Codexが記事生成
 ↓
Article Tools
 ↓
PostgreSQLへ記事を下書きとして保存
 ↓
人間がNext.jsサイトのプレビューで確認
 ↓
人間が公開
 ↓
Next.jsサイトに掲載

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

① 人間が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へ保存します。MCP Serverは、記事を公開するToolを持ちません。

⑩ 人間がプレビューで確認し、公開する
人間がNext.jsサイトのプレビュー画面（ローカル環境だけで表示）で記事を確認し、問題がなければ公開スクリプトで公開します。自動公開ではなく、人間が確認してから公開します。公開した記事は、Next.jsサイトの一覧・詳細ページに表示されます。

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

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

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

2. この記事のゴール

CodexをAIインターフェース、自作のAffiliate MCP Serverを業務機能との接続層、PostgreSQLをデータ基盤、Next.jsのサイトを記事の表示先として、商品情報の取得 → データ蓄積 → 記事作成 → 人間の確認 → 自前サイトでの公開までを行う、AIアフィリエイト支援システムの全体設計を理解します。

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

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

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

回	記事タイトル	ゴール
第1回	Codex + MCPでAIアフィリエイト支援システムを設計してみる（本記事）	システム・MCP Tool・DB・記事サイトを設計する
第2回	楽天商品をPythonのMCP Serverで取得・DB蓄積してみる	Product Toolsを実装する
第3回	Codexに商品・キーワードを選定させてアフィリエイト記事を作成してみる	Article Toolsと記事サイト（Next.js）を実装し、Affiliate MCP Serverを完成させる

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

3. MCP ServerのTool設計

独自MCP Serverを窓口にする

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

メリット	内容
認証情報を1か所に集約	APIキー・DBパスワードをMCP Server側で管理する（詳細は「7. 認証情報の管理」）
処理の標準化	「商品を検索する」といった処理を、取得元が異なっていても、統一されたインターフェースのToolとして提供できる
安全性	「記事は下書きの保存・更新まで」など、Toolでできることを限定できる。公開の操作はToolにしないので、Codexが記事を公開することはない
再利用性	一度作った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()      ← 必ず下書きで保存する
    ├─ get_article()
    └─ update_draft()      ← 下書きだけを更新する

（MCP Toolにしないもの）
公開スクリプト              ← 人間が記事を公開・非公開にする

Product Tools：楽天APIからランキング・検索・商品詳細を取得し、PostgreSQLへ保存する（第2回で実装。get_product_detail() は第3回）
Article Tools：記事化候補の抽出、重複記事チェック、記事の下書きの保存・取得・更新を行う（第3回で実装）
公開スクリプト：人間がプレビューで確認したあとに、記事を公開・非公開にする。MCP Serverには登録しない（第3回で実装）

記事サイト（Next.js）の設計

記事を掲載するサイトは、Next.js（App Router）、TypeScript、通常のCSSで作ります。

画面	URLの例	表示する記事
記事一覧	`/`	公開済みの記事だけ
記事詳細	`/articles/記事ID`	公開済みの記事だけ（下書きのIDを指定しても表示しない）
下書きのプレビュー	`/preview/記事ID`	下書きだけ。ローカルで確認するときだけ有効にし、公開する環境では表示しない

サイトはDBを読み取るだけです。書き込みは、MCP Serverと公開スクリプトだけが行います。

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

データライフサイクル

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

楽天市場商品検索API
   ↓
商品情報取得
   ↓
PostgreSQLへ保存
   ↓
Codexによる商品選定
   ↓
キーワード選定
   ↓
記事生成
   ↓
PostgreSQLへ記事を下書きとして保存（status = draft）
   ↓
人間がプレビューで確認して公開（status = published）
   ↓
Next.jsサイトに掲載

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：商品をもとに作成した記事（記事本文・キーワード・公開状態 status・公開日時 published_at を保持）。記事の正本はこのテーブルだけです。記事サイトは、status = 'published' の記事だけを表示します。

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

補足（記事の保存先を1か所にする理由）: CMSに記事を登録する構成では、記事がCMSとDBの2か所に保存され、片方への登録だけが成功したときに不整合が起きます。本シリーズでは記事をPostgreSQLだけに保存し、サイトはそれを読み取るだけにすることで、この問題を避けます。

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

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

「失敗前提」で設計する

外部APIやDBとの連携では、通信エラー・タイムアウト・接続断などの失敗を前提として設計します。「外部APIは失敗する」「DB接続は切れる」「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パスワードをコードに書いていないか。記事サイトが必要以上の権限でDBに接続していないか
Performance（性能）	大量商品を扱えるか
Operations（運用）	ログから障害原因を追えるか
Data（データ）	DBに正しいデータが保存されているか
AI Quality（AI品質）	AIの生成内容を検証できるか
Compliance（規約遵守）	ASP・EC・広告表示ルールを守れるか

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

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

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

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

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

Securityでは、APIキーやデータベースのパスワードなど、重要な情報を安全に管理します（具体的な方針は「7. 認証情報の管理」で説明します）。ソースコードにキーやパスワードを直書きせず、環境変数から読み込みます。加えて、最小権限（その処理に必要な権限だけを与える）が重要です。

対象	最小権限の考え方
Codex	記事は下書きの保存・更新まで。公開の操作はToolとして提供しない
記事サイト	DBへは読み取り専用のユーザーで接続する。サイトに不具合があっても、データを書き換えられない
記事の表示	AIが生成した本文をHTMLとしてそのまま埋め込まない。決めた書式だけを表示し、リンクは許可したドメインだけにする

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

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

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

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

記事の保存先をPostgreSQLの1か所にしているため、「別のシステムへの登録には成功したが、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
      ↓
PostgreSQLへ下書きとして保存
      ↓
人間がNext.jsサイトのプレビューで確認
      ↓
人間が公開スクリプトで公開
      ↓
Next.jsサイトに掲載

公開の操作をMCP Toolにしないことで、「Codexが誤って公開する」ことを、指示ではなく仕組みとして防ぎます。

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

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

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

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

7. 認証情報の管理

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

Codex
  │（認証情報は持たない）
  ▼
MCP Server（.env）
  ├─ RAKUTEN_APP_ID
  ├─ RAKUTEN_ACCESS_KEY
  ├─ RAKUTEN_AFFILIATE_ID
  └─ DATABASE_URL（読み書きできるユーザー）

Next.jsの記事サイト（.env.local）
  └─ DATABASE_URL（読み取り専用のユーザー）

原則は次の4つです。

コードに直接書かない：server.py やサイトのコードにキーやパスワードを直書きしない。
環境変数などで管理する：.env ファイル（記事サイトは .env.local）や環境変数から読み込む。
リポジトリに含めない：.env と .env.local は .gitignore に追加し、Gitにコミットしない。
ブラウザーに渡さない：Next.jsでは、NEXT_PUBLIC_ で始まる環境変数はブラウザーに送られます。DBの接続情報などの認証情報には、NEXT_PUBLIC_ を付けません。

「認証情報はMCP Serverと記事サイトのサーバー側に閉じ込め、Codexとブラウザーには渡さない」という方針を、最初に決めておきます。

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

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

アフィリエイト規約：利用するASP・ECサービス・広告主ごとに、リンクの生成方法・使用可能な画像・価格表示の条件などのルールがあります。必ず各サービスの最新規約を確認してください。
広告表示：アフィリエイトを含む記事には、「広告」「PR」などの表示が求められる場合があります（景品表示法のステルスマーケティング規制など）。本シリーズの記事サイトでは、記事の冒頭とサイトのフッターに広告であることを表示し、アフィリエイトリンクには rel="sponsored" を付けます。
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
Codexによる記事生成
Next.jsの記事サイト
人間による確認と公開
 ↓
Affiliate MCP Server・記事サイト完成

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

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

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

シリーズ記事一覧

【実践第1回】Codex + MCPでAIアフィリエイト支援システムを設計してみる〜商品情報取得・DB蓄積・記事作成・Next.jsサイトでの公開〜
【実践第2回】楽天商品をPythonのMCP Serverで取得・DB蓄積してみる〜商品検索・ランキング取得・保存まで〜
【実践第3回】Codexに商品・キーワードを選定させてアフィリエイト記事を作成してみる〜商品評価・キーワード選定・記事生成・Next.jsサイトでの公開まで〜

参考

※ 参考資料の内容は要約し、ライセンス上の配慮から表現を調整しています。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蓄積・記事作成・Next.jsサイトでの公開〜