ホーム › AI駆動開発ジャーニー › Claude Code で楽天アフィリエイト商品カードシステムを 3 時間で本番稼働させた実装ログ
AI駆動開発ジャーニー

Claude Code で楽天アフィリエイト商品カードシステムを 3 時間で本番稼働させた実装ログ

公開: 2026-05-24 · 著者: Sasaki Ryuji

個人開発者が AI に外部 API 統合 + 本番稼働まで任せた 3 時間の実装ログ

Claude Code で楽天アフィリエイト商品カードシステムを 3 時間で本番稼働させた実装ログ

「AI に楽天アフィリエイトの商品カードシステムを実装してもらう」を実体験で検証しました。個人開発者である私 (Sasaki Ryuji) が 2026 年 5 月 23 日、Claude Code (Opus 4.7) に楽天 API + 商品カードシステム + ステマ法対応 [PR] ラベル + サイトビルダー統合を任せた 3 時間の実装ログ を時系列で公開します。本人作業は楽天アプリID 発行と確認のみ 10 分、それ以外は全て AI 主導で進行しました。

本記事の結論を先出しすると、以下の3点です。

  1. Claude Code に「楽天検索ページ誘導 (CTR 0.5-1%) → 個別商品ディープリンク (CTR 2-3%) に置き換えるシステムを実装して」と依頼した結果、3 時間で本番稼働 + lab.ai-pick.tech 1 記事目に組み込み完了。同日中に 5 記事へ拡大
  2. 1 件想定外の失敗が発生 (旧 API エンドポイントが HTTP 400)、Claude が公式ドキュメントを読み直して 新エンドポイント (2026 年 4 月仕様) を 15 分以内に発見、即時修正
  3. 本人 (個人開発者) がやるべきは API キー取得 + ステマ法対応の最終判断 + 本番動作の最終視認 の 3 つのみ、それ以外は全て AI に任せられる時代になっている

以下、3 時間の進行を時系列で記録します。AI に外部 API 統合 + 本番稼働まで任せる際の現実的な境界線が見える内容です。

実装着手前の状況 (2026年5月23日朝)

当時の lab.ai-pick.tech (AI 自動化レシピサイト、14 記事) では、楽天アフィリエイトを「楽天検索ページへの誘導」形式で運用していました。具体的には記事末尾に「Notion 入門書を楽天で見る」のようなリンクを配置し、楽天市場の検索結果ページに遷移させる構造です。

この方式の CTR は業界統計で 0.5-1% (記事 PV の 0.5-1% がクリックする) が標準です。リンク先がカテゴリ検索ページなので、ユーザーは「で、結局どれがいいの?」と迷ってブラウザを閉じてしまうケースが多発します。一方、個別商品ディープリンク (具体的な商品ページに直接遷移) は CTR 2-3% で、収益は 2-3 倍に伸ばせる可能性がありました。

朝の最初に Claude に依頼したのは「楽天 API + 個別商品ディープリンク + 商品カード HTML テンプレ + ステマ法対応 [PR] ラベル」のフルセット実装です。本人作業として「楽天ウェブサービスでアプリID 発行」だけ依頼を受け、10 分で準備完了しました。

10:00 — 設計フェーズ (Claude が 15 分で設計確定)

朝の 10:00、Claude に要件を伝えた直後、15 分で以下の設計が返ってきました。

  1. lib/rakuten-search.mjs: 楽天商品検索 API クライアント。1 QPS のレート制限管理、レスポンスから個別商品 URL + 画像 + 価格抽出
  2. lib/product-card.mjs: 商品カード HTML テンプレ。画像 + 商品名 + 価格 + 「楽天で詳細を見る」ボタン + [PR] ラベル (ステマ法対応)
  3. scripts/build-rakuten-cache.mjs: articles.json の rakuten_keyword フィールドをスキャン → 楽天検索 API 呼び出し → data/rakuten-cache.json に保存 (TTL 7 日)
  4. lib/site-html-builder.mjs 統合: renderRakutenCards() を追加、buildArticleHtml の body 内 FAQ 直前に商品カードを差し込み
  5. saas-diary 自動除外: siteId === 'saas-diary' チェックで AdSense 主軸サイトには楽天カードが入らないガード

設計時間 15 分。私の介在は「方針の最終確認 + GO サイン」のみ。設計をゼロから自分で考えると 1-2 時間かかる作業を、Claude が memory ([[affiliate-link-registry]] [[saas-diary-affiliate-prohibition]]) を引き出して 15 分で構造化しました。memory システムが「同じ判断を毎回考え直す」コストを大きく削減しています。

10:30 — 実装フェーズ 1 時間目 (失敗 1 件発生)

設計確定後、Claude が lib/rakuten-search.mjs の実装に着手。最初の 30 分で書き上がりましたが、E2E テストで HTTP 400 エラーが発生しました。

原因は楽天 API のエンドポイント仕様変更でした。旧エンドポイント app.rakuten.co.jp/services/api/IchibaItem/Search/20220601 は applicationId 単独で動いていましたが、2026 年仕様では HTTP 400 を返すようになっていました。古い実装記事や Stack Overflow の情報が現実と合わなくなっていたのです。

Claude の対応は素早く、5 分以内に公式ドキュメントを読み直して以下の事実を発見しました。

  • 新エンドポイント: https://openapi.rakuten.co.jp/ichibams/api/IchibaItem/Search/20260401
  • 必須パラメータ: applicationId に加えて accessKey (pk_ プレフィックスの新仕様)
  • 変更日: 2026 年 4 月から強制移行
  • affiliateId 渡し方: 新エンドポイントでは affiliateId を渡せば API が直接 affiliate URL を返す = もしも経由ラッパー不要、設計シンプル化

修正は 10 分で完了。新エンドポイントに切り替え、accessKey を .env から読み込む形に修正。E2E テスト再実行で「Claude AI 入門」検索で 70 件のヒット、商品カード HTML が出力されました。失敗から修正完了までの所要時間 15 分、これが AI 駆動開発の「即時自己修正」の典型例です。

11:30 — 実装フェーズ 2 時間目 (product-card.mjs + ステマ法対応)

API クライアントが動いた後、商品カード HTML テンプレに着手。ここで重要だったのがステマ法対応の [PR] ラベル付与でした。

日本の景品表示法は 2023 年 10 月から「ステルスマーケティング規制」を本格運用しています (消費者庁公式)。アフィリエイトリンクを設置する際、広告であることをユーザーに明確に伝えないと景表法違反 (措置命令 + 事業者名公表 + 最大 3 億円の罰金) のリスクがあります。

Claude が実装した [PR] ラベルは以下の構造です。

<aside class="product-card">
  <span class="pr-label">[PR]</span>
  <img src="..." alt="商品名" />
  <h4>商品名</h4>
  <span class="price">¥1,580</span>
  <span class="rating">★4.5 (30件)</span>
  <a href="..." rel="sponsored noopener" target="_blank">
    楽天で見る ★4.5 (30件) →
  </a>
</aside>

ポイントは 3 つです。(1) [PR] ラベルを目立つ位置 (左上) に配置、(2) リンクに rel="sponsored" を付与 (Google の推奨実装)、(3) ボタン文言にレビュー数を併記して信頼性訴求。これらは Claude が memory [[gramshift-stealth-marketing-boundary]] + Google Search Central のリンク属性ガイドラインから自動的に組み立てた構成です。

12:30 — site-html-builder.mjs 統合 + saas-diary 自動除外

商品カードを各サイトのビルドパイプラインに統合します。lib/site-html-builder.mjs の buildArticleHtml() 関数に renderRakutenCards(article, siteConfig) を追加し、body 内の FAQ 直前に商品カードを差し込む形にしました。

ここで最重要だったのが「saas-diary は自動除外」のガードです。saas-diary.com は AdSense 主審査用にクリーン保持が必須 ([[saas-diary-affiliate-prohibition]])、楽天アフィカードを設置すると AdSense 申請 (2026/8/16 予定) で「広告過剰サイト」と判定されるリスクがあります。

Claude が実装したガードは以下のシンプルな構造です。

// lib/site-html-builder.mjs
function renderRakutenCards(article, siteConfig) {
  // saas-diary は自動除外 (AdSense クリーン維持)
  if (siteConfig.siteId === 'saas-diary') return '';

  // rakuten_keyword が指定されてる記事のみカード表示
  if (!article.rakuten_keyword) return '';

  // キャッシュから該当商品を取得 + product-card.mjs でレンダリング
  const items = loadRakutenCache(article.rakuten_keyword);
  return renderProductCards(items, article);
}

この 1 行の if (siteConfig.siteId === 'saas-diary') return '' が、AdSense 主審査の安全性を保証する重要な防御線です。コードレビューでもこのガードがあるかどうかを必ず確認、というルールを memory に永続化しました。

12:45 — 本番デプロイ + 動作確認

実装完了後、lab.ai-pick.tech の notion-ai-meeting-notes-automation 記事 (AI_TOOLS カテゴリ) に rakuten_keyword: "Notion 仕事術" を追加。build-rakuten-cache.mjs で 3 商品取得 → site build → FTPS デプロイで本番反映しました。

本番動作確認の結果:

  • https://lab.ai-pick.tech/ai-tools/notion-ai-meeting-notes-automation/ HTTP 200
  • 商品カード 3 件表示 (Notion 関連書籍)
  • hb.afl.rakuten アフィリエイト URL 6 個 (ボタン + サムネ画像両方アフィ化)
  • [PR] ラベル 3 個表示
  • 本人のブラウザで見た目 OK 確認

朝 10:00 着手から本番稼働まで 3 時間ジャスト。Step 1 (本人作業 10 分) + 設計 15 分 + 実装 2 時間 + 統合 30 分 + 本番反映 15 分の内訳です。

13:30 — CVR 改善 4 点を追加実装 (本人指示「全部やって」)

本番稼働後、本人視点で「もっと CVR を高められる改善点」を 4 点提案、Claude が即実装に着手しました。

  1. ボタンに ★評価 + 件数を併記: レビューあり商品は「楽天で見る ★4.5 (30件) →」、無しは「楽天で見る →」。社会的証明を強化
  2. 本文中差し込みマーカー <!--RAKUTEN_CARDS--> サポート: body_html にマーカーがあればそこに展開、無ければ従来通り FAQ 直前。記事の文脈に合った位置に商品カード配置可能
  3. 段階フィルタ実装: minReviews 以上 → レビューあり全件 → レビューなし の順で want 件確保。書籍はレビュー 0 件商品が大半なので、厳しい minReviews でも 0 件にならないよう自動 fallback
  4. 記事側に rakuten_min_reviews フィールド追加可 (デフォルト 0、優先順位だけ変わる、絶対除外ではない)

4 改善の所要時間 1 時間。実装直後の Notion 記事を「比較表後 → 商品カード 3 枚 → 失敗ケース → 次に試すなら」の順序で本文中展開する形に再構成しました。記事の流れの中に商品カードが自然に配置され、ユーザーの「で、結局どれがいいの?」の疑問にカードで答える構造です。

同日夜 — lab.ai-pick の 4 記事に拡大 (合計 5 記事カバー)

23:00 頃、Claude に「他の lab 記事にも展開して」と依頼。記事ごとに「最適な楽天検索キーワード」を Claude が選定 + テスト → 1 件失敗 → リカバリのパターンを経験しました。

  1. zapier-make-n8n-comparison-2026 (NOCODE): キーワード「ノーコード 入門」hits=3 → 成功
  2. claude-gemini-article-mass-production (WORKFLOW): キーワード「Claude AI 入門」hits=3 → 成功
  3. powershell-claude-daily-task-report (WORKFLOW): キーワード「PowerShell 入門」hits=3 → 成功
  4. individual-dev-saas-conoha-vps-2gb-real-operation-2026 (NOCODE): 当初「VPS Linux サーバー 入門」で 0 件 → 「Linux 入門」に短縮で 3 件取得

4 記事目で「楽天検索キーワードは 1-2 語に絞った方がヒットしやすい」という新しい教訓を発見、memory に永続化しました。結果、lab.ai-pick の楽天カバレッジは 1 記事 → 5 記事に拡大 (5 倍)、本番全部稼働確認済。

楽天 API 実装で得た 3 つの教訓 — 仕様変更対応 / ステマ法対応 / AdSense 安全ガード

3 時間の実装で得た教訓は 3 つです。外部 API 統合を AI に任せる際の現実的な落とし穴と対処を、楽天 API のケースで具体的に共有します。

教訓 1: API 仕様変更への即時対応こそ AI 駆動の威力

旧エンドポイントが HTTP 400 を返した際、Claude が 15 分以内に公式ドキュメントを読み直して新エンドポイント (2026 年 4 月仕様、accessKey 必須) を発見しました。これが人間単独だと「ネットの古い情報を信じて 1-2 時間迷う」パターンになりがちです。AI に外部 API 統合を任せる場合、「公式ドキュメントを再確認させる指示」を明示すると失敗復旧が劇的に速くなります。memory に永続化して次回以降の API 統合で再利用可能です。

教訓 2: ステマ法対応は AI の memory ガイドラインから自動推論される

[PR] ラベルの配置、rel="sponsored" の付与、ボタン文言のレビュー数併記は、Claude が memory の [[gramshift-stealth-marketing-boundary]] + Google Search Central のリンク属性ガイドラインから自動的に組み立てました。本人が「ステマ法対応で実装して」と指示するだけで、3 つの実装ポイントが揃った状態で出力されます。memory への法的ガイドライン蓄積が、こうした「AI が法的境界を理解した実装を出す」状態を成立させます。

教訓 3: AdSense 安全ガードは 1 行のコードが事業を守る

if (siteConfig.siteId === "saas-diary") return "" という 1 行のガードが、AdSense 主審査用サイトを「広告過剰判定」から守ります。AI 駆動開発で複数サイトを並走運用する際、サイトごとの「やってはいけないこと」をコードレベルで明示するガード設計が事業継続性を支えます。今回は saas-diary だけが対象でしたが、将来サイトが増えても同じパターンで拡張可能です。

結論として、「本人作業 10 分 + Claude 作業 3 時間」で外部 API 統合 + 本番稼働 + ステマ法対応 + AdSense 安全ガードまで完了できる時代 です。同じ規模の機能を人間が単独で実装すると 2-3 日かかる作業を、3 時間で本番稼働に持ち込めたのは AI 駆動開発の大きな前進です。これら 3 教訓は外部 API 統合全般に転用可能なパターンとして memory に蓄積しました。

1 週間後の効果検証予定

2026 年 5 月 30 日頃に楽天アフィリエイト管理画面で初週の CTR + コンバージョン数を確認予定です。検証する指標は以下の通り。

  • 5 記事の合計クリック数 (旧方式 0.5-1% → 新方式 2-3% の改善検証)
  • コンバージョン数 (購入発生件数)
  • 最も効いた記事 / 最も効いた商品キーワード
  • CVR が低い記事の改善案 (キーワード変更 / 配置位置調整)

効果が高ければ ai-pick.tech (4 言語、54 記事) にも展開予定です。Amazon PA-API は楽天で売上経験を積んだ後、過去 180 日で 3 件以上の売上達成後に取得可能、その段階で Amazon ディープリンク化も同じパターンで実装予定です。

連載 3 本目の意味と次のステップ

3 時間で外部 API 統合を本番稼働まで持ち込めた経験は、「AI に個人開発の機能追加を任せる」が現実的に可能であることを示しました。失敗事例 (旧 API エンドポイント) も即時自己修正で 15 分で復旧、ステマ法 + AdSense + 楽天アフィの 3 軸を同時に満たす設計を Claude が memory から組み立てたのも印象的でした。

本連載「AI 駆動開発ジャーニー」は、こうした実証実験を 4 媒体 (X / saas-diary / dev.to / Reddit) でリアルタイム公開実況する取り組みです。次回は 「Claude Opus 4.7 ペアモデルで月 1,500 コミットした個人開発の現実」 を予定しています。

筆者: Sasaki Ryuji — Instagram 自動運用 SaaS『GramShift』開発者、saas-diary.com / ai-pick.tech / lab.ai-pick.tech / host.ai-pick.tech 等 複数メディア運営。本記事内のコード + 数値はすべて私が運用しているシステムの実装値です。

よくある質問

楽天 API は 2026 年 4 月から仕様変更があったのですか?

はい。旧エンドポイント <code>app.rakuten.co.jp/services/api/IchibaItem/Search/20220601</code> は 2026 年から HTTP 400 を返すようになり、新エンドポイント <code>https://openapi.rakuten.co.jp/ichibams/api/IchibaItem/Search/20260401</code> に強制移行されています。新エンドポイントでは <code>applicationId</code> に加えて <code>accessKey</code> (pk_ プレフィックス) が必須。ネット上の古い実装記事や Stack Overflow の情報が現実と合わなくなっているため、公式ドキュメントの確認が必須です。

なぜ saas-diary には楽天アフィカードを設置しないのですか?

saas-diary.com は AdSense 主審査用にクリーン保持が必須だからです (申請日 2026/8/16 予定)。アフィリエイト広告と Google AdSense を同一サイトに混在させると「広告過剰サイト」と判定され、AdSense 通過率が大きく下がるリスクがあります。lib/site-html-builder.mjs に <code>if (siteConfig.siteId === "saas-diary") return ""</code> のガードを実装し、saas-diary では楽天カードが自動的に出力されない設計です。アフィリエイト収益化は他 3 サイト (ai-pick.tech / lab.ai-pick.tech / host.ai-pick.tech) で実施します。

ステマ法対応の [PR] ラベルは具体的にどう実装していますか?

3 つの実装ポイントがあります。(1) [PR] ラベルを商品カードの左上 (目立つ位置) に配置、(2) リンクに <code>rel="sponsored noopener"</code> を付与 (Google Search Central のリンク属性ガイドラインに準拠)、(3) ボタン文言にレビュー数を併記して信頼性訴求。日本の景品表示法 (2023 年 10 月から本格運用のステマ規制) は措置命令 + 事業者名公表 + 最大 3 億円罰金のリスクがあるため、広告であることの明示が法的に必須です。

本人作業 10 分とは具体的に何をしましたか?

楽天ウェブサービスでのアプリ ID 発行作業 5 分 + 本番動作の最終視認 5 分 = 合計 10 分です。具体的には (1) 楽天アフィリエイトにログイン、(2) 「ウェブサービス」→「アプリ ID 発行」、(3) アプリ名と URL 入力、(4) 発行された applicationId / accessKey / affiliateId を Claude に渡す、(5) Claude が実装後、ブラウザで本番サイトを開いて見た目とリンク先遷移を目視確認。残り 3 時間の実装は全て Claude Code (Opus 4.7) が主導しました。