🔀

WordPressのフロントエンドをClaude Codeで Next.js に置き換えた

2026/03/01に公開

!要約： WordPress テーマのフロントエンドを Next.js に置き換え、ヘッドレス CMS 化しました。Claude Code・Codex・ChatGPT の三刀流で 2 日間で完了。設計判断・AI の使い分けについてまとめます。

 はじめにフリーランスエンジニアとして事業サイト showma-tech.com を WordPress で運営していました。テーマのカスタマイズに限界を感じ、フロントエンドを Next.js に置き換えることにしました。
ただし、ゼロから手書きしたわけではありません。Claude Code（Anthropic の CLI エージェント） と対話しながら、設計からデプロイまでを 2 日間 で完了しました。
この記事では、ヘッドレス CMS 化の技術的な設計判断と、AI との協業で実際にどこまでできたのかをまとめます。

 前提：なぜ WordPress のフロントを捨てたのかWordPress 自体は CMS として優秀です。問題はフロントエンドでした。


課題
詳細


テーマの制約
デザインの自由度が低く、細かい調整に PHP テンプレートの修正が必要

表示速度
毎リクエストで PHP → DB → HTML 生成。キャッシュプラグインで誤魔化す運用

開発体験
PHP テンプレート + jQuery の世界。コンポーネント設計や TypeScript が使えない

SEO 制御
プラグイン依存。JSON-LD やメタデータを自由に設計できない

一方、WordPress の管理画面・エディター・メディア管理は十分に使いやすい。これを捨てるのはもったいないと感じていました。

 WordPress テンプレートをカスタマイズする選択肢はなかったのかもちろん、既存の WordPress テーマを PHP テンプレートレベルでカスタマイズするという選択肢もありました。しかし、これは早い段階で見送りました。理由は 2 つです。
1. 表示ロジックが WordPress の仕様に強く依存する
WordPress のテンプレートは、テンプレート階層・ループ・アクションフック・フィルターフックなど WordPress 固有の仕組みの上に成り立っています。「この部分のレイアウトを変えたい」と思っても、WordPress がどの順序でどのテンプレートを読み込み、どのフックでデータを渡しているかを把握しないと手が出せません。表示ロジックがフレームワークの仕様と密結合しているため、自由度が低く、改修コストも読みにくい。
2. AI 開発を活かしにくい
React / TypeScript / Tailwind CSS はドキュメントやコード例が豊富なため、AI コーディングツールの生成精度が高い。コンポーネント単位で設計し、型安全にデータを受け渡すモダンフロントエンドのコードは、AI が理解しやすい。一方、WordPress の PHP テンプレートは暗黙のグローバル変数やマジックメソッドが多く、AI にとっても人間にとっても「何がどこで起きているか」を追いにくい構造です。AI との協業を前提にするなら、AI が力を発揮できるスタックを選ぶべきだと判断しました。
結論：WordPress はコンテンツ管理に専念させ、フロントだけ Next.js に置き換える「ヘッドレス CMS」構成に決めました。


Before（WordPress テーマ）
After（Next.js）






 なぜ Next.js かNext.js を選んだ理由は 2 つです。

ISR の柔軟性 — 静的生成をベースにしつつ、記事更新時だけバックグラウンドで再生成できる。WordPress との組み合わせで「ほぼ静的サイトの速度 + CMS のリアルタイム更新」を両立できる

Claude Code との相性 — Claude Code の frontend-design スキルはプロジェクトのスタックに合わせた UI コンポーネントを生成でき、デザインの具現化が速い。AI にコードを書かせる前提なら、AI が得意とするエコシステムに合わせるのが合理的だった

 技術スタックサーバーは自宅のハイパーバイザ上に Linux VM を立てて運用しています。グローバル IP を持たないため、外部公開には Cloudflare Tunnel を使用しています。



レイヤー
技術


フロントエンド
Next.js, React, TypeScript, Tailwind CSS

アニメーション
Framer Motion

CMS
WordPress（REST API v2）

外部公開
Cloudflare Tunnel + Cloudflare CDN/WAF

インフラ
Linux VM, Docker Compose, Ansible

DB / キャッシュ
MariaDB + Redis


 アーキテクチャ設計の要点
 1. WordPress REST API との接続WordPress は wp-json/wp/v2 の REST API をそのまま使います。API へは内部ネットワーク経由でアクセスするようにしています。
// src/lib/wordpress.ts

// Docker 内部ネットワーク経由で WordPress REST API にアクセス
// WAF で /wp-json を外部からブロックしているため、内部ネットワーク経由が必須
const API_URL = process.env.WORDPRESS_INTERNAL_API_URL!;

// WordPress がリバプロ背後にある場合、
// HTTP→HTTPS リダイレクトループを防ぐヘッダ
const internalHeaders: HeadersInit = {
  "X-Forwarded-Proto": "https",
};
!ハマりポイント： Docker 内部ネットワークから WordPress に HTTP でアクセスすると、WordPress の site_url が HTTPS のため 301 リダイレクトが発生し、無限ループになります。X-Forwarded-Proto: https ヘッダを付与することで解決しました。

 2. ISR + オンデマンド再検証Next.js の revalidate: 3600（1 時間）をベースにしつつ、WordPress で記事が更新されたら即座にキャッシュをクリアする仕組みを入れました。
// wordpress/mu-plugins/nextjs-revalidate.php
add_action('transition_post_status', function ($new_status, $old_status, $post) {
    if (defined('DOING_AUTOSAVE') && DOING_AUTOSAVE) return;
    if (wp_is_post_revision($post)) return;
    if (!in_array($post->post_type, ['post', 'page'], true)) return;
    if ($new_status !== 'publish' && $old_status !== 'publish') return;

    wp_remote_post('http://<frontend-host>/api/revalidate', [
        'headers'  => ['x-revalidate-secret' => REVALIDATE_SECRET],
        'blocking' => false, // WordPress管理画面をブロックしない
        'timeout'  => 5,
    ]);
}, 10, 3);
WordPress の mu-plugins（Must-Use Plugins）に配置することで、プラグイン管理画面に依存せず確実に動作します。blocking: false で WordPress 側の操作を遅延させないのもポイントです。

 3. リバースプロキシ + Cloudflare Tunnel による公開リバースプロキシが /wp-* を WordPress に、それ以外を Next.js にルーティングし、同一ドメインで WordPress 管理画面と Next.js フロントエンドが共存しています。Cloudflare Tunnel 経由でインターネットに公開するため、サーバー側でのポート開放やグローバル IP は不要です。また、Cloudflare WAF で /wp-json を外部からブロックし、REST API は Docker 内部ネットワーク経由のみに制限しています。

 4. WordPress プレビュー → Next.js Draft Mode 連携ヘッドレス CMS 化で地味に困るのがプレビューです。WordPress の管理画面で「プレビュー」ボタンを押すと、通常は WordPress 自身がフロントエンドを描画します。しかし、フロントエンドが Next.js に移っているため、そのままでは下書き記事をプレビューできません。
これを Next.js の Draft Mode で解決しました。
Draft Mode は、ISR などで静的生成されたページを特定ユーザーだけ動的レンダリングに切り替える仕組みです。draftMode().enable() を呼ぶとブラウザーに __prerender_bypass という Cookie がセットされ、この Cookie を持つリクエストは静的キャッシュを無視してサーバーサイドレンダリングされます。Cookie の値は next build のたびに再生成されるため推測できず、デフォルトはセッション Cookie（ブラウザーを閉じると消える）なので、本番の静的配信に影響を与えません。
これを WordPress と繋ぐ流れはこうです：
ページ側では draftMode().isEnabled をチェックし、有効なら WordPress REST API に認証付きで下書き記事を取得、無効なら通常の公開記事を表示します。プレビューを終了したいときは /api/draft/disable にアクセスして Cookie を削除するだけです。

 Claude Code との開発プロセスここからは AI との協業プロセスについて。全コミットの Co-Author がすべて Claude Opus 4.6 です。どうやって進めたのかを振り返ります。

 使った AI ツール

ツール
用途


Claude Code
コード生成・レビュー・リファクタリング・インフラ構築の全般

Codex
アプリケーションコードのレビュー。Claude Code が書いたコードの設計・品質チェック

ChatGPT
デザインレビューとライティングレビュー。Web 画面のスクショを貼り付けて改善提案を取得

frontend-design スキル
Claude Code のスキル機能。プロジェクトのスタックに合わせた高品質な UI コンポーネントを生成

AI ツールの使い分け を整理すると、こうなります。
各ツールが向いていたタスク：

Claude Code — コーディング全般。指示すれば整合性を保って複数ファイルを一度に変更してくれる

Codex — アプリケーションコードのレビュー。自作のレビュースキル（セキュリティ・パフォーマンス・アーキテクチャ等の観点を定義）を読み込ませると、設計上の懸念点やエッジケースの指摘が的確だった

ChatGPT — UI・コピーのレビュー。画面スクショを貼り付けると、配色バランス・余白・CTA の視認性など具体的な改善提案が返ってくる
ライティング面の傾向の違い：

Claude Code — 無難にまとまる。安全寄り

Codex — 「ここまで言い切るのは不適切」「誇大表現に当たる可能性がある」といった指摘が多い

ChatGPT — 攻めた提案が多い。目立たせるための構造や言い回しを積極的に提案してくる
誇大表現は好みではないものの、目立たせるための構造には取り入れるべきものもある。このバランスは AI に任せず、最終的に自分で判断していました。AI はそれぞれ「安全寄り」「攻め寄り」の提案を出してくるだけで、どこに着地させるかは人間の仕事でした。
結果的に、Claude Code で書き、Codex でコードレビュー、ChatGPT でデザインとコピーをレビューという三刀流が最も効率的でした。


 開発の流れ
 Day 1：骨格づくりInitial commit from Create Next App
↓ Showma Tech フロントエンド構築: Next.js + WordPress ヘッドレスCMS
↓ 全ページのデザインを frontend-design スキルで刷新
↓ GA4・reCAPTCHA v3導入、お問い合わせ確認画面追加
↓ 料金・品質ページ新設、お問い合わせフォーム改善
↓ トップページ全面リニューアル
↓ ... 各ページの反復改善 ...
初日は「まず動くものを出す → 各ページを順に改善」という流れ。コンテンツ自体は既存の WordPress サイトに揃っていたため、サイトの URL を Claude Code に教えて読み取らせ、テキストや構成をそのまま Next.js に移植してもらいました。ゼロからコピーを考える必要がなかったので、骨格の構築は非常に速かったです。
ただし、最初に生成されたデザインが「いかにも AI が作った感」だったため、「現状のデザインが AI っぽいので、frontend-design スキルを使っていくつか案をください」とお願いしました。複数の方向性が提示され、そこから選んだうえで Claude Code や ChatGPT で繰り返し改善していく形で進めました。

 Day 2：本番デプロイ + 仕上げセキュリティ強化・各ページ改善
↓ reCAPTCHA v3→v2チェックボックスに変更
↓ 本番デプロイ基盤整備・WordPress APIリダイレクトループ修正
↓ WordPress MCP連携・コンテンツ更新
↓ WordPress記事更新時のNext.jsキャッシュ即時クリア機能を実装
↓ X(Twitter)用OGPメタデータ・SNSシェアボタン追加
実環境でしか再現しないバグ（reCAPTCHA のレースコンディション、リダイレクトループ）を潰しつつ、WordPress MCP での記事投入や OGP・シェアボタンなど公開に向けた仕上げを行いました。

 AI が得意だったこと1. API 連携を「よしなに」やってくれた
個人的に最も感心したのがこれです。「WordPress の記事をブログページに表示して」と伝えただけで、Claude Code は WordPress REST API の仕様を理解し、_embed パラメーターによるアイキャッチ画像の取得、X-WP-Total / X-WP-TotalPages ヘッダによるページネーション、カテゴリフィルタリングまで一通り実装してくれました。
API のエンドポイント設計やレスポンス構造を自分で調べる必要がなく、src/lib/wordpress.ts に 8 関数がきれいに整理された状態で出てきたのは衝撃的でした。Docker 内部ネットワーク用の URL 分岐や X-Forwarded-Proto ヘッダの付与も、こちらから指示していません。
2. ボイラープレートの高速生成
12 ページ分のレイアウト、メタデータ設定、JSON-LD 構造化データ、サイトマップ生成など、パターンが明確なコードは正確かつ高速に生成されました。
3. デザインの具現化
「信頼感があり、かつ身近さを感じるデザイン」のような抽象的な指示からも、配色・タイポグラフィ・スペーシングを含めた一貫したデザインシステムを提案してくれました。frontend-design スキルの効果は大きかったです。
OGP 画像やサムネイルの生成スクリプトも AI に作らせました。 「サイトのヒーローセクションの CSS スタイルを参考にして」と指示したところ、ヒーロー画像の上にグラデーションオーバーレイ・ドットグリッドパターン・サイトカラー（#1a2744, #3b82f6）を重ねる SVG を生成し、sharp でコンポジットする Node.js スクリプトが出てきました。サイトのトンマナと統一された OGP・サムネイルが node scripts/generate-ogp.mjs 一発で生成でき、記事ごとにデザインツールを開く必要がなくなりました。
4. Codex によるセキュリティ強化
お問い合わせフォームの初期実装は Claude Code が行いましたが、そのコードを Codex にレビューさせたところ、以下の不足を指摘されました：
レートリミット（IP あたり 5 リクエスト/時間）
リクエストボディサイズ制限（10KB）
メールヘッダインジェクション防止
フィールド長バリデーション
これらの指摘を Claude Code に伝えて実装させる、という流れです。Codex にはセキュリティ・パフォーマンス・運用品質などの観点を定義した自作のレビュースキルを読み込ませているため、毎回ブレずにチェックが回ります。書く AI と、観点を仕込んだレビュー AI を分けることで、一人開発でもレビューのない素通りコードを防げます。

 AI が苦手だったこと・人間の判断が必要だった場面1. 実環境固有のバグ
Docker ネットワーク内の HTTP/HTTPS リダイレクトループは、AI が事前に予測できるものではありませんでした。エラーログを共有して原因を特定する工程は人間主導です。
2. reCAPTCHA の実装
レースコンディション修正、ウィジェット重複描画修正など修正を重ねて安定させました。外部サービス連携はドキュメントと実際の挙動にギャップがあり、試行錯誤が必要でした。
3. ビジネス判断を伴うコピーライティング
「フリーランス × システム開発のポジショニング」といったマーケティング要素は、自分の事業戦略を理解したうえでの判断が必要でした。AI に草案を出してもらい、自分で方向性を修正するサイクルを繰り返しました。
なお、記事の投稿・管理には WordPress MCP を使い、ターミナルから AI 経由で WordPress を直接操作しています。MCP の詳細や記事管理ワークフローについては別記事で紹介予定です。

 完成したサイトの構成
 ページ一覧

パス
内容


/
ヒーロー、信頼バッジ、サービス概要、実績、ブログ、CTA

/blog
記事一覧（カテゴリ・検索・月別アーカイブ・ページネーション）

/blog/[slug]
記事詳細（目次自動生成、SNS シェア、関連記事）

/works
実績一覧

/services
サービス紹介

/about
自己紹介

/quality
品質方針

/pricing
料金

/flow
ご相談の流れ

/faq
よくある質問

/contact
お問い合わせ（簡易/詳細フォーム切替）

/privacy
プライバシーポリシー


 ブログ機能の詳細WordPress の記事データを Next.js で表示する部分は、以下の機能を実装しています：

目次自動生成：記事内の見出しタグを解析して TableOfContents コンポーネントで表示

SNS シェアボタン：X (Twitter)・Facebook・LinkedIn 対応

関連記事：同一カテゴリの記事を自動表示

アイキャッチ画像：WordPress の _embed で Featured Media を取得し、OGP にも反映

JSON-LD：BlogPosting スキーマで構造化データを出力

XSS 対策：isomorphic-dompurify で WordPress の HTML コンテンツをサニタイズ

 まとめ
 AIが向いていた場面
API 連携の実装 — 仕様を調べて繋ぎ込む定型作業は AI が圧倒的に速い

パターンが明確なコードの大量生成（ページ骨格、メタデータ、API クライアント）

デザインの具現化（抽象的な要件 → Tailwind CSS コンポーネント）

セキュリティのベストプラクティスの自動適用

CMS 操作の自動化（WordPress MCP による記事投稿・管理）

 人間が握るべき場面
実環境でのデバッグ（Docker ネットワーク、Cloudflare Tunnel、外部サービス連携）

ビジネス判断（ポジショニング、コピー、UX の方向性）

UI・コピーの最終判断（ChatGPT のレビューは参考になるが、決めるのは自分）
コミット粒度・PR 単位の設計

 AI の使い分けが鍵だった今回の開発で実感したのは、AI ツールにはそれぞれ得意領域があるということです。

Claude Code — コーディング、API 設計、インフラ構築。手を動かす仕事全般

Codex — コードレビュー。Claude が書いたコードの設計・品質を別の AI がチェック

ChatGPT — UI・コピーのレビュー。スクショを投げて視覚的にフィードバックをもらう
全コミットの Co-Author が AI だからといって、人間が不要だったわけではありません。むしろ「何を作るか」「なぜこの設計か」「このデザインで事業の意図が伝わるか」という上流の判断に集中できたことが最大のメリットです。
ヘッドレス CMS という構成は、WordPress の管理体験はそのままに、フロントエンドの自由度を手に入れるという意味で合理的な選択でした。今後もデザインや UX を継続的に改善していくつもりです。フロントを分離したおかげで「直したい」と思ったときにすぐ手を入れられる。この身軽さが、2 日間で得た一番の成果でした。
こちらが完成したサイトです。

https://showma-tech.com/

課題	詳細
テーマの制約	デザインの自由度が低く、細かい調整に PHP テンプレートの修正が必要
表示速度	毎リクエストで PHP → DB → HTML 生成。キャッシュプラグインで誤魔化す運用
開発体験	PHP テンプレート + jQuery の世界。コンポーネント設計や TypeScript が使えない
SEO 制御	プラグイン依存。JSON-LD やメタデータを自由に設計できない

レイヤー	技術
フロントエンド	Next.js, React, TypeScript, Tailwind CSS
アニメーション	Framer Motion
CMS	WordPress（REST API v2）
外部公開	Cloudflare Tunnel + Cloudflare CDN/WAF
インフラ	Linux VM, Docker Compose, Ansible
DB / キャッシュ	MariaDB + Redis

ツール	用途
Claude Code	コード生成・レビュー・リファクタリング・インフラ構築の全般
Codex	アプリケーションコードのレビュー。Claude Code が書いたコードの設計・品質チェック
ChatGPT	デザインレビューとライティングレビュー。Web 画面のスクショを貼り付けて改善提案を取得
frontend-design スキル	Claude Code のスキル機能。プロジェクトのスタックに合わせた高品質な UI コンポーネントを生成

パス	内容
`/`	ヒーロー、信頼バッジ、サービス概要、実績、ブログ、CTA
`/blog`	記事一覧（カテゴリ・検索・月別アーカイブ・ページネーション）
`/blog/[slug]`	記事詳細（目次自動生成、SNS シェア、関連記事）
`/works`	実績一覧
`/services`	サービス紹介
`/about`	自己紹介
`/quality`	品質方針
`/pricing`	料金
`/flow`	ご相談の流れ
`/faq`	よくある質問
`/contact`	お問い合わせ（簡易/詳細フォーム切替）
`/privacy`	プライバシーポリシー

はじめに

前提：なぜ WordPress のフロントを捨てたのか

WordPress テンプレートをカスタマイズする選択肢はなかったのか

なぜ Next.js か

技術スタック

アーキテクチャ設計の要点

1. WordPress REST API との接続

2. ISR + オンデマンド再検証

3. リバースプロキシ + Cloudflare Tunnel による公開

4. WordPress プレビュー → Next.js Draft Mode 連携

Claude Code との開発プロセス

使った AI ツール

開発の流れ

Day 1：骨格づくり

Day 2：本番デプロイ + 仕上げ

AI が得意だったこと

AI が苦手だったこと・人間の判断が必要だった場面

完成したサイトの構成

ページ一覧

ブログ機能の詳細

まとめ

AIが向いていた場面

人間が握るべき場面

AI の使い分けが鍵だった

Discussion