
結論を先に言うと──
WordPress本体を丸ごと再現するのは、ほぼ不可能です。
ただし、WordPress的な思想を持つCMSを設計・実装するなら、Claude Codeはかなり使えます。
この違いを理解することが、AI活用の第一歩です。
そもそも、なぜWordPressの再現は難しいのか
これはAIの性能の問題ではありません。WordPressという存在そのものの特殊さが原因です。
◼︎WordPressは「設計されたプロダクト」ではない
WordPressは20年以上にわたり、世界中の開発者が「後方互換を最優先」で積み上げてきたプロダクトです。一貫した設計思想があるわけではなく、歴史の堆積物というのが正確な表現でしょう。
一方、Claude Codeが得意なのは、整った設計、明確な責務分離、現代的なアーキテクチャです。つまり、両者の相性は根本的に噛み合いません。
◼︎本当の価値は「互換性」にある
WordPressの真の強みは、数万のプラグイン、無数のテーマ、そして長年の運用で培われた暗黙の仕様にあります。
たとえば、wp_postsにあらゆるコンテンツを詰め込む設計、postmetaのkey-value構造、グローバル変数への依存、フックの実行順──。これらは仕様書に書かれていない挙動が事実上の「仕様」として機能しています。
Claude Codeは明文化された仕様の実装は得意ですが、こうした暗黙の挙動を再現するのは苦手です。
◼︎フック・フィルタは「動的すぎる」
WordPressの拡張性を支えるadd_actionやapply_filtersは、実行順が状況に依存し、他のプラグインの存在を前提とし、グローバルな状態に紐づいています。静的な解析がほぼ不可能な構造です。
Claude Codeはコード全体を把握しようとしますが、WordPressは「実行してみないと分からない」世界で成り立っています。
◼︎セキュリティと後方互換の板挟み
WordPressはPHP 5時代との互換性を保ちながら、最新の脆弱性対策にも対応し、古いテーマの動作も保証しなければなりません。Claude Codeにこれを任せると、モダンな書き方に直そうとしたり、型を導入しようとしたり、グローバル変数を排除しようとします。それ自体は正しい判断ですが、そうした「改善」を加えた時点でWordPressではなくなります。
Claude Codeで作ると、何ができるのか
Claude Codeに「WordPressを作って」と指示すると、ほぼ確実に「別物」ができあがります。ただし、それは失敗ではなく、むしろ必然的な結果です。
Claude Codeが生成するCMSは、おおむね以下のような特徴を持ちます。
- Post / Page / カスタムタイプが明確に型定義されている
- メタデータはJSONまたは型付きの構造で管理される
- フック機構はイベントバスやミドルウェアとして実装される
- REST APIがフロントエンドに先行する設計
- 管理画面はReactベースのSPA
つまり、「理想化されたWordPress」が出来上がります。WordPressの思想は残しつつ、歴史的な負債を取り除いた姿です。
◼︎例えるなら
WordPressが「増改築を繰り返した巨大な商店街」だとすれば、Claude Codeで作るCMSは「その商店街の思想を反映した新築ビル」です。同じ商売はできますが、構造はまったく違います。
実験:あえてWordPressに寄せたらどこで破綻するか
ここからは少し実験的な話をします。Claude Codeで意図的にWordPressの構造に寄せていくと、どの段階で限界が見えるのかを検証する方法です。
◼︎フェーズ1:データ構造を再現する
まずwp_postsとwp_postmetaのテーブル構造をそのまま再現させます。
WordPressの wp_posts と wp_postmeta の構造を
できるだけ忠実に再現してください。
設計上の違和感があっても無視して構いません。
Claude Codeは一応これに従います。ただし、途中で必ず「これは正規化されていません」「JSONカラムにした方が効率的です」といった指摘が入ります。この段階で、すでに思想の衝突が始まっています。
◼︎フェーズ2:フック機構を再現する
次にadd_action/apply_filtersの仕組みを再現させます。
WordPress互換のフック機構を実装してください。
グローバル状態や実行順依存も許容します。
ここが最初の明確な破綻ポイントです。Claude CodeはイベントバスやObserverパターン、ミドルウェア構成を提案し始めます。しかし、WordPressのフックは実行順が暗黙的で、グローバル状態に依存し、他プラグインの副作用を前提としています。Claude Codeは本質的に「汚い実装」を避けようとするため、ここで方向性がずれ始めます。
◼︎フェーズ3:テーマ・レンダリングで完全に破綻する
the_contentフィルタの再現を試みます。実行順に依存し、HTML文字列を次々に書き換え、プラグイン同士が競合する構造です。
Claude Codeはほぼ確実に「これは安全で予測可能な設計ではありません」と指摘し、拒否するか、勝手に改善してしまいます。ここが越えられない壁です。
この実験から得られるもの
「どこまで寄せられて、どこで破綻するか」を把握できたこと自体が成果です。この実験を通じて得られるのは以下の3つです。
- WordPressの技術的負債マップ──どの部分が歴史的経緯で複雑化しているのかが明確になる
- 「なぜWordPressはこうなったのか」を説明する力──設計判断の背景を言語化できるようになる
- 次世代CMS設計の根拠──何を残し、何を捨てるべきかの判断材料が手に入る
Claude Codeの得意・不得意を正しく理解する
| WordPress完全互換の再現 | … ❌ 不可能 |
| WordPress設計思想の再構築 | … ✅ 得意 |
| WordPress卒業用CMSの開発 | … ✅ 得意 |
| 学習・技術検証(R&D) | … ✅ 最適 |
Claude Codeが本当に力を発揮するのは、WordPressの構造を言語化し、本質的な要素(Post / Meta / Hook)を抽出し、それをモダンなアーキテクチャに再設計する作業です。
まとめ
WordPressは「作るもの」ではなく「積もったもの」です。
Claude Codeは、積もった歴史を再現する道具ではありません。
しかし、「次のWordPress」を構想するパートナーとしては非常に優秀です。
正しい問いは「Claude CodeでWordPressを作れるか?」ではなく、
「Claude CodeでWordPressを卒業するためのCMSを作れるか?」です。
その答えは──Yes。



