WordPressからNext.jsへ AIがサイトを更新する時代の移行術
このコーポレートサイトも、少し前まではWordPressで動いていました。ブログ機能は使っておらず、会社案内と事業紹介が中心の、よくある構成です。いまはNext.jsに載せ替えています。
乗り換えて一番変わったのは、表示速度でも運用コストでもありませんでした。サイトの直し方です。管理画面を開かなくなりました。いまこの記事も、テキストファイルとして書かれ、AIとの対話で修正され、履歴が残った状態で公開されています。
先に断っておくと、Next.jsはCMSではありません。WordPressの管理画面を別の管理画面へ置き換える製品ではなく、コンテンツの保存・編集・公開の方法まで含めて組み直す選択です。ここを取り違えたまま話を進めると、たいてい途中で行き詰まります。
そのうえで、AIにサイトを触らせる前提でサイトの土台を選び直すと、評価軸が変わります。その話をします。
WordPressの弱点は本体ではなく、プラグインという構造にある
まず公平に置いておくと、WordPressは十分に良いソフトウェアです。W3Techsの集計では、CMSが判明しているサイトの59.1%、全ウェブサイトの41.2%がWordPressです(2026年8月5日時点)。この規模で20年以上動き続けているものを、軽く扱うつもりはありません。
問題は本体ではなく、積み上げ方のほうにあります。
セキュリティ企業PatchstackのState of WordPress Security in 2026によると、2025年にWordPressエコシステムで見つかった脆弱性は11,334件で、前年比42%増。そのうち91%はプラグインで見つかったものです。コア本体ではありません。
もう2つ、経営判断に効く数字があります。
- 公開された脆弱性のうち46%は、公開の時点で開発元から修正が出ていなかった
- 大量に悪用された深刻な脆弱性が武器化されるまでの時間は、中央値で5時間
つまり「プラグインをこまめに更新していれば安全」という前提が、すでに成り立ちにくくなっています。更新すべきパッチが存在しないケースが半分近くあり、存在したとしても半日待たずに攻撃が始まる。
WordPressを使うということは、機能を足すたびに、自分ではコントロールできない他人のコードへの依存が1つ増えるということです。便利さと引き換えに何を抱えているのか。ここは一度、数えてみる価値があります。
AIが編集者になると、管理画面は強みから足かせに変わる
WordPressの最大の強みは、非エンジニアがブラウザだけで完結できることです。これは本物の価値で、20年かけて磨かれてきたものです。ただし、その価値は人が手で操作するという前提の上に乗っています。
AIエージェントに更新を任せようとすると、この前提が効かなくなります。管理画面はクリックの塊で、テーマの設定もプラグインの設定もデータベースの中。誰がいつ何を変えたのか、後から追うのも簡単ではありません。AIに「トップページのこの文言を直して」と頼んでも、渡せる手がかりが少ない。
一方、コードとテキストファイルで構成されたサイトは、AIにとって読みやすい対象です。どこを直せばいいかがファイルとして特定でき、変更は差分として残り、Gitの履歴で追える。人がレビューしてから公開する、という流れもそのまま作れます。
本当にそうでしょうか。WordPressだってWP-CLIやREST API経由でAIに触らせられるのでは、という反論はあり得ます。実際できます。ただ、その方向に進めば進むほど「コンテンツをコードとテキストとして扱う」形に寄っていきます。だったら最初からそう設計されているほうが素直ではないか、というのが私たちの結論でした。
Next.jsはAIエージェント対応を標準機能に組み込み始めた
ここが今回いちばん驚いた部分です。
Next.jsは、インストールしたバージョンと一致するドキュメントをパッケージの中に同梱しています。node_modules/next/dist/docs/ に丸ごと入っていて、ネットワーク越しに調べにいく必要がありません。そして create-next-app でプロジェクトを作ると、AGENTS.md と CLAUDE.md という2つのファイルが自動で生成されます。中身は、AIエージェントに向けた1行の指示です。
公式のAIコーディングエージェント向けガイドには、その意図がはっきり書かれています。あなたの訓練データは古い、同梱ドキュメントこそが正しい情報源だ、と。AIが古い知識で間違ったコードを書く問題を、フレームワーク側が仕組みで潰しにきているわけです。
さらに、MCPサーバーの公式ガイドもあります。next-devtools-mcp を入れると、AIエージェントが開発サーバーにつながり、ビルドエラー・実行時エラー・型エラー・ページのルート構成・開発ログを直接読めるようになります。エラーのスクリーンショットを人が貼り付ける手間が消えるということです(MCPそのものの解説はこちらの記事に書きました)。
ここまで正面から「AIが触る前提」を作り込んでいるCMSやフレームワークは、いまのところ多くありません。私たちがこのブログを回せているのも、この設計に乗っているからです。記事はMDXという拡張マークダウンのテキストファイルで、「この段落の表現をこう直して」と伝えれば直り、ビルドが通るかまでその場で確認できます。
速くなる理由は、ページを作り置きできるから
速度の話も、仕組みで理解しておくと判断しやすくなります。
WordPressは基本的に、アクセスのたびにPHPがデータベースを引いてHTMLを組み立てます。だからキャッシュプラグインを入れるのが定石になっているわけです。対してNext.jsでは、固定ページや記事のようなコンテンツを事前に生成し、CDNから配る構成を選べます。ページを組み立てる処理が、アクセスのたびではなく事前に一度だけ済む。
これはキャッシュを入れていないWordPressと、事前生成を使うNext.jsを比べた場合の構造の差です。WordPress側にもフルページキャッシュやCDNの選択肢はあるので、そこまで含めれば差は縮みます。
「じゃあ更新のたびにサイト全体を作り直すのか」という疑問には、ISR(増分的静的再生成)という答えが用意されています。全体を作り直さずに、更新があったページだけ差し替えられる仕組みです。
ただし、速くなることを保証する話ではありません。Next.jsでも遅いサイトは普通に作れます。正確に言えば速くしやすい構造を選べる、というだけです。目安としては、Googleが定めるCore Web VitalsのLCPが2.5秒以内なら良好とされています。まずは自社サイトの現在値を測ってから、移行で何秒縮むのかを見積もるのが順番です。
移行のやり方は3つある
いきなり全部作り直す必要はありません。実際には次の3方式から選びます。
| 方式 | 中身 | 向く会社 |
|---|---|---|
| ヘッドレス化 | WordPressは残し、REST APIでコンテンツだけ取り出して、表示側をNext.jsで作る | 編集者が複数いて、管理画面を手放せない |
| 完全移行 | 記事をマークダウンなどのテキストに移してリポジトリで管理し、WordPressを廃止 | 更新頻度が低い、または更新をAIに任せていく |
| ハイブリッド | 会社案内などの固定ページだけ先にNext.js化し、更新の多いお知らせはWordPressに残す | 段階的に移したい |
ヘッドレス化は、公開コンテンツを取得するところまでならハードルが低めです。REST APIはWordPressのコア機能で、ブロックエディタ自体がこの上に載っています。追加のプラグインなしで /wp-json/ から記事データを取り出せます。公開コンテンツは公開のまま、非公開のものは認証が必要という原則も、通常のサイトと同じです。
ただし、いまの編集体験をそのまま再現するとなると話は変わります。下書きプレビュー、画像とメディアの扱い、SEOプラグインが持っていたメタ情報、更新時のキャッシュ更新、フォーム、認証、リダイレクト。このあたりを1つずつ設計しなおす必要があります。「記事データが取れた」で終わりだと思っていると、残りの8割で足が止まります。
ヘッドレス化で編集者から必ず出てくる不満が「下書きのプレビューができない」なのですが、これにはDraft Modeという仕組みが用意されています。静的に作り置きしたページを、下書き確認のときだけ動的な表示に切り替える機能です。ここを最初に設計しておかないと、移行後に運用が止まります。
URLを1本も落とさないことが、移行の最優先事項
技術選定より先に決めるべきは、こちらです。検索から来ていた流入は、URLの引き継ぎやリダイレクトに漏れがあると失われます。
手順はこうなります。
- 全URLを棚卸しする。既存のサイトマップ、Search Consoleのインデックス済みページ、アクセス解析の上位ページを突き合わせる
- パーマリンク構造をそのままルーティングに写す。
/2024/05/slug/のような日付入りの形式も再現できます - どうしても変わるURLはリダイレクトで受ける。ここに注意点があって、Next.jsのリダイレクト設定は301や302ではなく、308と307を使います。多くのブラウザが301や302を受け取るとリクエストの種類をGETに変えてしまうため、それを保持する308と307をあえて採用している、と公式ドキュメントに書かれています。Google検索のリダイレクト解説では301と308のどちらも恒久的な移転として扱われるので、SEO上の不利はありません。恒久的な移転として扱ってほしいなら308のほうを指定します
- サイトマップ、robots.txt、構造化データ、OGPを移行先で作り直す。ここはプラグインが自動でやってくれていた領域なので、抜けやすい
- 切り替え後2週間から1か月、Search Consoleのインデックス状況と404を監視する
もうひとつ。移行のタイミングで「ついでにURLも整理しましょう」という話が出たら、いったん止めてください。サイト構造の変更と基盤の移行を同時にやると、順位が落ちたときにどちらが原因か切り分けられなくなります。まず同じURLのまま移し、落ち着いてから情報設計を見直す。遠回りに見えて、こちらのほうが速いです。
正直に言うと、向かない会社もあります
ここまで前向きに書いてきましたが、どの会社にも当てはまる話ではありません。判断を誤りやすい点を挙げます。
- プラグイン1つで済んでいた機能が、自前実装か外部サービスになります。問い合わせフォーム、会員制、EC、多言語、予約。ここの見積もりを甘くすると、移行そのものが破綻します
- ビルドとデプロイを理解している人が、社内に最低1人は必要です。AIがコードを書けても、それが意図どおりかを判断する人は要ります(この構図については以前書きました)
- 現場の編集者が管理画面から直接直せる体験は、完全移行だと失われます。ヘッドレス構成なら残せますが、その分だけ構成要素が増えます
- 記事が数千本あるサイトは、移行の設計そのものが一仕事になります。段階移行を前提に計画を組んでください
- Next.jsに移れば脆弱性がなくなるわけではありません。プラグイン依存は減らせますが、npmパッケージ、認証、ホスティング、独自実装の安全性を自分たちで管理する責任は増えます
判断の目安は、どちらの運用を残したいかです。管理画面を中心に人が編集する運用を続けたいならWordPressの強みがそのまま残ります。ファイルとGitを中心に、AIと一緒に更新していく運用へ移りたいならNext.jsの設計が効いてきます。自社がどちらに向かっているのか。そこだけ見極めれば答えは出ます。
まとめ WordPressが古いのではなく、編集する人が変わった
今回の話は「WordPressが時代遅れになった」ではありません。サイトを編集する主体が、人からAIに移りつつあるという変化に対して、どちらの設計が素直に応えるか、という比較です。
私たちは移行して正解でしたが、それは自社のサイト更新をAIに任せる方向に舵を切ったからです。同じ判断が全社に当てはまるとは思いません。
すぐ動くなら、まず2つ。自社サイトのURL一覧を書き出すこと。そして管理画面のプラグイン一覧を開いて、本当に使っているものが何個あるか数えることです。使っていないものが半分あったなら、その時点で答えは半分出ています。