本文へ移動

WordPressは終わり? 本当にそうなのかを考えてみる

WordPressは「終わり」といわれますが、本当にそうなのでしょうか。「何でもWordPress」という選び方が終わったことと、WordPress自体が役割を失ったことは同じではありません。CMSとしてできること、用途、運用体制、AIを使った開発まで含めて考えます。

IN THIS ARTICLE

「WordPressはもう終わりですか」「AIでWebサイトを作れるのに、まだWordPressを使う意味はありますか」。WordPressの保守や開発に関わっていると、こうした質問を受ける機会が増えました。

たしかに、AIを使えば、数ページの静的なWebサイトを形にするまでの時間は大きく短縮できます。私たちも、AIは優秀で、時間効率を桁違いに変える、なくてはならない存在だと考えています。

ただし、画面が表示されたことと、担当者がコンテンツや利用者を管理し、複数人が権限を分け、安全に更新を続けられる仕組みが完成したことは同じではありません。

制作・更新に関わる全員がGitを扱え、変更履歴やレビューを共通の手順で管理できる環境なら、管理画面を持たない構成でも運用できるかもしれません。誰が、どのように、何のために使うのかによって、必要な仕組みは変わります。

この記事の結論

先に結論を言えば、WordPressは終わっていません。一方で、「Webサイトなら何でもWordPressで作る」という時代は終わりました。

静的サイト、SaaS、EC専用サービス、独自システム、WordPressを、用途と運用体制に応じて選ぶ段階に入っています。

「WordPressは終わり」の中身を分けて考える

「WordPressは終わり」という言葉をよく目にしますが、何をもって「終わり」とするのかについては、少なくとも次の3つに分けて考える必要があります。

  • ブログや企業サイトなら無条件でWordPress、という選び方
  • 専門知識がなくても、入れさえすれば安全に運用できるという期待
  • WordPressというCMS自体の利用や開発

前の2つは、すでに成り立ちにくくなっています。しかし、そこから「WordPressという仕組みそのものが終わった」と結論づけるのは飛躍があります。

WordPressは、良くも悪くも目立ちます。世界中で長く使われ、利用者もサイト数も多ければ、話題になりやすいのは当然です。それだけに、「古い」「AIで代替できる」「利用率が高い」といった表面の情報だけで、採用するか捨てるかまで語られることがあります。

投資の話題で企業の実態と市場の評判が一致しないことがあるように、技術にも実態と異なる風評が生まれます。これは今に始まったことではありません。話題の大きさと、目の前の用途に適しているかどうかは別です。

だからこそ、手段を決める前に、少なくとも次を明確にする必要があります。

  • 何を実現するためのWebサイトまたはシステムなのか
  • 誰が、どのように使うのか
  • 現在必要な機能と、将来追加する可能性がある機能は何か
  • 誰がWordPress本体、テーマ、プラグインの保守管理を行うのか
  • 誰が日々のサイト運営と、障害時の復旧対応を担うのか
  • サーバー、アプリケーション、外部連携を、それぞれ誰がどこまで監視するのか(マネージドサーバーを利用している場合は、契約範囲内のサーバー監視をサービス提供側に任せられます)

目的と責任範囲が曖昧なままでは、WordPressを選んでも、AIで独自に作っても、採用判断の妥当性を確かめられません。

静的サイトを簡単に公開できるサービス、ノーコードツール、EC専用サービス、ヘッドレスCMS、AIによるコード生成が増え、選択肢は広がりました。これはWordPressの消滅というより、WordPressだけで考える必要がなくなったという変化です。

WordPressそのものが終わったとは言えない

2026年9月6日に確認したW3Techsの統計では、WordPressはCMSが判別できるWebサイトの58.9%、全Webサイトの40.7%で使われています。調査方法や母集団には注意が必要ですが、少なくとも「すでに誰も使っていない」と呼べる状態ではありません。

開発も止まっていません。WordPress 7.1は2026年8月19日に公開されました。WordPress 6.9以降には、機能の入力・出力・権限を定義し、AIや外部システムから扱いやすくするAbilities APIも導入されています。

WordPressの主要言語であるPHPは歴史が長く、比較的レガシーな部類に入ると私たちも考えています。それでもPHP自体の開発は続いており、2026年9月時点ではPHP 8.5系まで公開されています。新しい世代ではパフォーマンスや型安全性の改善も続いています。

PHPだからという理由だけで、WordPressを候補から外すほどのことではありません。結局は、サイトの規模と実現したいこと次第です。仕様、実装例、トラブル事例などの情報が多いことを考えると、AIエージェントと開発を進める相性も悪い部類ではないと考えます。ただし、古い情報を参照する可能性があるため、対象バージョンと一次情報の確認は必要です。

数字を見るときの前提

ただし、利用率が高いことは、新しい案件でWordPressを採用すべき証明にはなりません。普及率は「終わったか」を見る材料の一つであり、「自社に合うか」は別の判断です。

ただし、何でもWordPressで作る必要はない

更新頻度が低い数ページの案内サイトなら、静的HTMLやホスティングサービスで十分な場合があります。商品販売が中心なら、決済・在庫・配送の機能を持つECサービスを先に検討したほうが自然です。会員ごとに複雑な処理を行う業務システムなら、最初から独自アプリケーションとして設計したほうがよいこともあります。

とくに、問い合わせフォームもログインも個人情報の保存もない静的なサイトであれば、作り手が使いやすい方法を選べばよいでしょう。そこまでWordPressにこだわる理由はありません。

一方で、フォーム、会員情報、決済、予約、外部API連携が入れば、話は変わります。入力値の検証、認証、権限、データ保護、障害時の復旧まで含めて、公開する側が責任を持つ必要があります。見た目が完成したかどうかだけでは判断できません。

WordPressは「記事管理だけ」のCMSではない

WordPressを記事投稿用の管理画面としてだけ捉えるのは適切ではありません。コンテンツと分類の管理、利用者の認証と権限、公開状態、メディア、API、拡張機構を持つCMSであり、設計と開発次第では会員サイト、決済を伴うサイト、独自の業務処理も構築できます。

  • コンテンツとデータ構造投稿、固定ページ、カスタム投稿タイプ、カテゴリ、タグ、独自分類、メタデータを扱う。
  • 利用者、認証、権限管理者、編集者、投稿者、会員など、役割に応じて閲覧・操作範囲を制御する。
  • 公開と変更履歴下書き、予約公開、公開範囲、リビジョンを管理し、必要なら以前の版へ戻す。
  • メディアと入力・編集画面画像やファイルを管理し、投稿、会員、商品など、用途に合わせた管理画面の入力・編集機能を構築する。
  • 拡張と外部連携既存プラグインだけでなく、独自プラグイン、REST API、外部サービス連携で機能を追加する。
  • 会員・決済・業務処理要件に応じて、会員サイト、EC、予約、社内向け処理などを構築する。
  • 運用と復旧更新、バックアップ、監視、移行、障害対応を継続する。

私たちも、既存プラグインを組み合わせるだけでなく、案件固有の要件に合わせてWordPressプラグインを独自開発することがあります。独自の業務処理があるという理由だけで、WordPressが不向きとは限りません。既存の仕組みをどこまで活かせるか、独自部分をどのように分離するかで判断は変わります。

もちろん、これらはWordPressにしか実現できない機能ではありません。Next.jsなどを使い、AIエージェントとともに同等の仕組みを一から作ることもできます。ただし、コンテンツ、ユーザー、権限、履歴、メディア、検索、プレビュー、公開、復旧までを実際に作ると、WordPressが長年の利用を通じて備えてきた機能の広さと、コンテンツ管理基盤としての優秀さを改めて感じる場面があります。

WordPressに限らず、エディタ、コンテンツ、ユーザー、権限などの管理機能を一から作ろうと思えば、AIエージェントを使って作ることはできます。ただし、制作速度や納期を優先するなら、月額数万円程度のAI利用料だけで収まるような作業量ではありません。要件整理、実装、テスト、修正を進める人の工数がかかり、追加の開発費用も必要になります。

機能を少しずつ作り、AIサービスの利用上限がリセットされるのを待ちながら時間をかけて進めるなら、費用の見え方は変わるでしょう。しかし、それは納期を決めて提供するシステム開発とは別の条件です。

自作する場合は、次のような挙動まで要件化し、実装し、テストし、保守します。

  • 分類や利用者を削除したとき、関連データをどう扱うか
  • 予約公開が重なったとき、正しい時刻と順序で反映されるか
  • 権限の異なる利用者が同時に操作したとき、何を許可するか
  • 入力途中、通信失敗、外部API停止時にデータを失わないか
  • バックアップから、どの単位と時間で復旧できるか

AIが作ったものを、誰が完成と判断するのか

AIにコードを書かせること自体を否定する理由はありません。私たちも開発で使います。調査、実装案の比較、定型処理、テスト補助などでは、以前とは比べものにならないほど速く進められます。

それでも、2026年9月時点でAIを万能だとは考えていません。AIが生成したシステムが公開できる品質か判断できない人が、その判断までAIに預けたままWebサイトやシステムを公開することには疑問が残ります。

依頼内容を正確に言語化できなければ、AIは書かれていない要件まで保証してくれません。たとえば、次のような問題は起こり得ます。

  • 一つの機能を直したら、別の機能に不具合が出る
  • 通常操作では動くが、例外時にデータが壊れる
  • 管理者には便利でも、一般利用者に許可してはいけない操作まで開放する
  • 見た目は完成しているが、スマートフォンや支援技術では利用しづらい
  • 復旧手順や運用資料がなく、作った本人以外は直せない

公開前に必要な判断

AIは優秀ですが、万能ではありません。案を出し、比較し、作業を速く進めることは得意でも、何を採用し、どこまでを完成として公開するかを決定することは苦手です。要件、設計、動作、セキュリティを確かめ、最後に決めるのは人間です。

また、「AIかWordPressか」という二択でもありません。AIを使ってWordPressの開発や保守を効率化することもできます。WordPress側にも、AIや外部サービスとの連携を意識した仕組みがあります。既存CMSの運用機能を使いながら、AIで作業を速める選択肢もあります。

AIへ指示する人には、Webディレクターの役割が必要

「いい感じの企業サイトを作って」とだけ伝えれば、AIはそれらしい画面を短時間で返します。ただし、カード、角丸、グラデーション、大きな見出しなど、どこかで見た構成を既存のHTMLフレームワークへ当てはめただけになることも少なくありません。

AIから意図した結果を得るには、指示する人がWebディレクターの役割を担う必要があります。職種名がWebディレクターである必要はありませんが、依頼内容を具体的に言語化し、出力を評価する役割は必要です。

  • 誰に、何を伝え、どの行動につなげるのか
  • どの情報を優先し、何を削るのか
  • 参考デザインの何を採用し、何を採用しないのか
  • PCとスマートフォンで、配置や操作がどう変わるのか
  • 入力中、完了、エラーなどの状態をどう見せるのか
  • 何をもって完成と判断するのか

Webデザインは、装飾の選択だけではありません。情報の優先順位、文章量、写真、余白、操作、状態変化まで設計します。ここを伝えられなければ、AIが返すものは、自分が想像していたサイトとは違うものになりやすいでしょう。

逆に、基準となるデザインがあり、コンポーネント、画面幅ごとの挙動、状態変化まで具体的に依頼できるなら、AIによるコーディングは有力です。AIはデザインが苦手だから使えないのではなく、曖昧な依頼から設計判断まで無条件に任せられる段階ではない、というのが私たちの見方です。

用途から選ぶための目安

主な用途先に検討したい選択肢確認したい点
数ページの案内サイト静的サイト、ホスティングサービス更新担当、フォームの有無、公開後の修正方法
コンテンツやデータを継続更新するWordPressを含むCMS利用者、データ構造、公開、履歴、検索、移行性
複数人・会員ごとに権限を分けるWordPress、権限管理を備えたCMS、独自システム認証、承認フロー、操作履歴、誤操作の防止
商品を販売するEC専用SaaS、WordPress+EC、独自EC決済、在庫、配送、法令対応、障害時の責任範囲
独自の業務や会員機能が中心WordPressの独自開発、Webアプリケーション、業務SaaS標準機能を活かせる範囲、認証、データ設計、監査、保守体制
表示と管理機能を分離するヘッドレスCMS、WordPress REST APIプレビュー、キャッシュ、公開連携、障害点の増加

WordPressを使わないほうがよい可能性があるケース

  • 更新がほとんどなく、管理画面を持つ利点より保守負担が大きい
  • 目的に合うSaaSがあり、独自実装する理由がない
  • WordPressの標準機能をほとんど活かせず、制約を避けるための実装が大半になる
  • 更新・バックアップ・監視を担当する人も外部委託先も決まっていない

WordPressが候補に残るケース

  • 非エンジニアを含む複数人が、コンテンツやデータを継続的に更新する
  • コンテンツ、分類、履歴、利用者、権限、会員、決済などを組み合わせたい
  • 独自プラグインやAPI連携により、案件固有の処理を追加したい
  • 既存の運用手順やデータ、連携、担当者の知識を活かせる
  • 更新、監視、バックアップ、復旧を担う体制がある

WordPressを選ぶにしても、選ばないにしても、「作れるか」だけでなく、誰がどう使い、誰がWordPressとプラグイン、サーバーを保守し、誰が公開を判断し、障害時に誰が復旧するかまで決める必要があります。

既存のWordPressは、移行より先に現状確認

すでにWordPressで運用しているサイトは、「もう終わりらしい」という理由だけで急いで移行する必要はありません。移行には、記事、画像、URL、フォーム、検索、会員、決済、計測、SEO設定など、現在動いているものを引き継ぐ作業が伴います。

既存サイトでは、次の点を確認します。

  • WordPress本体、PHP、テーマ、プラグインのバージョンと更新可否
  • サイト固有の機能が、どこへ、どのように実装されているか
  • 既存プラグインを増やした結果、機能重複や不要な依存が生じていないか
  • テーマやプラグインを更新したとき、独自変更が失われないか
  • バックアップから実際に復旧できるか
  • サーバー、WordPress、フォーム、決済、外部連携の監視担当が決まっているか

既存プラグインを追加し続けたサイトなら、移行だけでなく、不要機能の整理や独自部分のリファクタリングも候補になります。WordPress公式も、公式にサポートするのは最新バージョンのみと案内しています。古い版を放置したまま使い続けることと、保守されたWordPressを使うことは分けて考えるべきです。

制作時にお金や時間をかけなかったこと、あるいは当時それで十分だと判断して積み重ねた選択が、現在の要件には合わなくなっている可能性もあります。その問題を、すべてWordPressの欠点として片づけることはできません。

そのうえで、保守やリファクタリングを続ける費用と、別の仕組みへ移す費用・リスクを比べます。WordPressが悪なのではありません。手段を活かせるかどうかは、設計し、使い、保守する側にも左右されます。

よくある質問

WordPressは本当に終わるのですか?

2026年9月時点で、利用も開発も続いており、終わったとは言えません。ただし、すべてのWebサイトで第一候補になるわけではありません。用途ごとに使い分け、選定が進んでいるのは確かだと思います。

AIならWordPressと同じCMSを作れますか?

必要な機能を実装することは可能です。しかし、コンテンツとデータ構造、利用者、認証、権限、公開状態、履歴、メディア、検索、バックアップ、移行、例外処理まで要件化し、検証し、保守する必要があります。「AIに頼めば同等品が自動的に完成する」とは考えないほうが安全です。

AIが作ったWebサイトは、そのまま公開してよいですか?

静的な案内ページでも、表示崩れ、リンク、アクセシビリティ、権利関係、計測は確認が必要です。フォーム、ログイン、決済、個人情報を扱う場合は、機能・セキュリティ・復旧まで専門的な確認が必要です。

更新の少ない会社サイトにもWordPressは必要ですか?

必須ではありません。更新方法、担当者、フォーム、将来の拡張を確認し、静的サイトやホスティングサービスも含めて比較します。管理画面を持つこと自体が負担になるなら、WordPressを使わない判断も合理的です。

既存のWordPressは今すぐ移行すべきですか?

一律には言えません。現在の更新状態、利用機能、障害リスク、運用費、移行後の体制を確認して判断します。問題が「WordPressだから」ではなく、更新停止や保守不在にある場合は、先に保守状態を立て直すほうが適切なこともあります。

まとめ:終わったのは「何でもWordPress」という前提

WordPressは終わっていません。しかし、静的な案内サイトからEC、独自システムまで、検討せず何でもWordPressで作る時代は終わりました。一方で、ECや独自処理があるというだけで、WordPressを候補から外す理由にもなりません。

AIはWeb制作と開発の速度を大きく変え、すでに欠かせない道具です。同時に、要件の不足、生成コードの不具合、権限、セキュリティ、公開後の復旧まで自動的に保証するものではありません。作れることと、公開して運用できることの間には、今も人間の判断と確認があります。

選ぶ基準は、流行しているか、古いかではありません。何を実現するのか、誰がどう使うのか、どこまで機能が必要か、誰が保守・監視・復旧するのか。その答えにWordPressが合うなら使い、合わないなら別の方法を選ぶ。手段は、使う側次第だと私たちは考えています。

WordPressを残すかどうか、まだ決まっていない段階でも構いません。

grandworkでは、最初からWordPressの採用や移行を前提にせず、目的、現在の構成、必要な機能、運用できる体制から整理します。その結果、WordPressを保守して使い続けることも、独自に拡張することも、別の構成を選ぶこともあります。

  • 既存のWordPressを点検したい場合保守へ入る前に現在の構成や更新状態を調べ、対応の優先順位を整理する単発プランです。小規模サイト点検は22,000円、標準サイト点検は44,000円(いずれも税込)。継続課金はありません。対象範囲はプランのページでご確認ください。WordPress点検プランの内容を見る
  • 新しいサイトや独自機能を検討する場合WordPress、静的構成、ヘッドレスCMS、独自開発を要件から比較します。カスタムWebサイト制作の内容を見る
  • AIを開発や運用へ取り入れたい場合業務を言語化し、人が判断する工程を残しながら小さく検証します。AI活用 伴走支援の内容を見る

どのサービスに当てはまるかを先に決める必要はありません。まず、何を作り、誰がどう使い、誰が保守するのかを確認するところから始めます。