2026年5月20日、WordPressの歴史における極めて重要な転換点となるメジャーアップデート「WordPress 7.0」が正式にリリースされた 1。当初は2026年4月9日にWordCamp Asia 2026のコントリビューターデイに合わせてリリースされる予定であったが、データベースの安定性担保および画期的な機能群のチューニングのために約1ヶ月半の延期が行われた 3。開発チームが「極限の安定性」を追求した結果、延期期間中にさらに3つのリリース候補（RC）が重ねられ、最終的なリリースプロセスが完了した 2。

このメジャーリリースの中心テーマは、協調型プラットフォームの構築を目指す「ワークフロー（Workflows）」に据えられている 4。コア開発においては419件以上のCore Tracチケット（300件以上のバグ修正、76件の機能強化）が処理され、Gutenbergプラグイン（バージョン22.0から22.6）関連の変更では411件の機能強化と486件のバグ修正が反映された 8。これは2018年にブロックエディタが初めて導入されたWordPress 5.0以来、過去8年間で最大の開発規模となる 9。

本技術報告書では、WordPress 7.0がWebサイト運営者や開発者にもたらす構造変化を多角的に分析し、ブログなどのメディア運営者が安全な移行を果たすための専門的かつ実践的な移行戦略を提示する。

開発ロードマップとWordPress 7.0のリリースの経緯

WordPress 7.0は、アルファ版の開発開始から始まり、長期にわたる広範な検証プロセスを経て一般公開に至った 2。開発の最終段階で生じたデータベースの安定性課題に対応するため、開発スケジュールは4月に一度見直されている 2。

以下は、開発の初期フェーズから正式リリースに至る全ロードマップのタイムラインをまとめたものである。

WordPress 7.0のコア開発では、リリース・スクワッドを中心とする世界中の開発者が関与し、特にWebホスティング事業者への呼びかけを通じて、サーバー互換性検証が徹底的に行われた 11。

インフラストラクチャ要件の引き上げと技術的乖離

WordPress 7.0の導入に伴い、サーバー側への動作要件は過去最大規模の引き上げが行われた 13。これは、肥大化するボットトラフィックへの対策やセキュリティ向上、そしてAI機能や高度な管理システムを稼働させるためのインフラモダン化が不可避となったためである 13。2026年のWeb統計によれば、グローバルなトラフィックの3分の1近くが自動化されたボットによるものであり、その76%が未検証の不正なアクセスであるため、インフラの堅牢化とセキュリティ管理はCMSの死活問題となっている 14。

PHP 7.4への最低動作保証の引き上げ

本バージョンより、長年維持されてきたPHP 7.2および7.3のサポートが完全に終了し、最低動作環境がPHP 7.4.0に設定された 13。PHP 7.2/7.3のシステム利用率が監視対象のWordPress環境において4%未満に低下したことがこの判断の背景にあり、これによりPHPの型安全性の担保や最新SDKとの親和性が確保されることとなった 4。PHP 8.3以降の環境が強く推奨されており、さらにPHP 8.4の最適環境では、PHP 7.4と比較して12%から14%程度の処理速度向上が確認されている 13。なお、サーバーがPHP 7.4未満の場合、WordPress 7.0への自動アップデートは提供されず、安全のためにWordPress 6.9セキュリティブランチに強制残留となる 15。

データベース要件における仕様と実質の乖離

データベースの動作仕様について、公式コミュニティおよび専門監査機関の検証により、重要な要件が明らかになっている 15。2026年5月中旬の公式訂正によると、WordPress 7.0のインストーラーレベルでのハードウェア的な最小起動制限自体はMySQL 5.5.5 / MariaDB 10.4のままである 16。しかしながら、新機能である「DataViews」管理画面は、共通テーブル式（CTE）やウィンドウ関数、拡張JSON関数など、MySQL 8.0以降でないと利用できないクエリ構造に依存している 13。そのため、MySQL 5.7などのサポート期限切れ（EOL）の古いデータベースで運用を強行した場合、アップデート後に管理画面の一部が動作停止または致命的エラーに遭遇する危険性がある 13。したがって、実質的な必須要件としてMySQL 8.0またはMariaDB 10.6以上が規定されている 13。

以下に、WordPress 7.0を稼働させるために必要とされるインフラ要件を提示する。

リアルタイム共同編集機能の見送りと非同期「Notes」システム

WordPress 7.0は、ガテンバーグプロジェクトの「フェーズ3（共同編集）」の幕開けとして位置づけられていた 9。しかし、最も期待されていた「リアルタイム共同編集（同一投稿内での複数人による同時執筆・カーソル移動同期）」は、RCテスト中の検証に基づき、2026年5月8日に正式にコア実装が見送られ、将来バージョンへの延期がアナウンスされた 2。

リアルタイム共同編集の除外プロセスとその要因

リアルタイム共同編集は当初、Yjs衝突回避データ統合ライブラリを利用し、コンフリクトを起こさないデータ統合（CRDTアーキテクチャ）を目指して設計されていた 2。しかしながら、開発チームによる大規模な環境テストの結果、複数の重大なシステム負荷が明らかとなった 3。

まず、複数ユーザーがアクティブに執筆を行った場合、WordPressの持続的なポストキャッシュシステムと激しい衝突を起こし、キャッシュデータの整合性が破綻することが確認された 3。また、ライブ同期を可能にするために新しいデータベース用同期テーブルをコアへ設置する必要があったが、これが共有ホスティング環境などに多大なディスクI/Oおよびクエリ負荷を与えたことも大きい 2。さらに、WebSocketsをサポートしていない一般的な安価なホスティングサービスが多く、HTTPポーリング方式に頼らざるを得ないアーキテクチャでは、データベースに対する負荷とトランザクション遅延が実用レベルに達しなかった 15。

WordPress開発チームは、安定性と安全性を最優先し、不完全なリアルタイム編集エンジンを強行実装するのではなく、いったん7.0のリリースブランチからこの機能を完全に除去し、より堅牢な実装へと作り直す決断を下した 2。

チームのための新コラボレーション機能：Notesシステム

リアルタイム機能は延期されたものの、代わりとしてチーム運用を支援する完全なインライン・フィードバック機構「Notes」システムが標準実装された 4。これにより、従来のようにGoogleドキュメントやSlack等を経由した外部でのやり取りを排除し、エディタ内で執筆とレビューのワークフローを完結させることが可能となった 4。

Notesシステムは非同期のコミュニケーションに最適化されており、エディタ上の特定のブロックやテキスト範囲に対して直接コメントを紐付けられる 4。さらにユーザーはチームメンバーを「@メンション」して通知を送ることができ、更新履歴や通知はダッシュボードまたはメール経由で即座に共有される 4。このアプローチは、共同編集者やクライアントとメディア運営者が直接コンテンツ上で調整作業を行う際の作業コストを大幅に引き下げる効果を発揮している 4。

コア統合型AIプラットフォームの全貌：「WP AI Client」と「Abilities API」

WordPress 7.0のアーキテクチャ的な最大の変化は、AIをCMSのコアシステムレベルで統合し、プラットフォーム化したことにある 19。これは特定のAIライティングプラグインを追加するような末端の機能変更ではなく、プラグイン開発者がAIを画一的かつ安全に利用するための抽象化された「レイヤー」の設置を意味する 19。

プロバイダーに依存しない共通PHP SDK

WordPress 7.0に搭載された「WP AI Client」（wordpress/php-ai-client）は、プロバイダー非依存のPHP SDKであり、コアシステムが外部APIとの通信、AIモデルの選定、レスポンスの正規化をすべて肩代わりする 21。

サイト管理者は「Settings > Connectors」から、デフォルトで提供されている「OpenAI」「Google (Gemini)」「Anthropic (Claude)」用のコネクタープラグインを有効化し、APIキーを入力するだけで、サイト全体のAI接続を一元管理できる 21。

開発者向けのAPIも整備されており、using_model_preference()関数を使用することで、利用したいモデルの優先順位をコード側から柔軟に定義できる 21。これにより、安価な処理には軽量モデルを使い、高度な推論には高性能モデルを割り当てる「機能検出」に基づく設計が可能となり、コスト削減と応答速度向上が両立されている 21。また、プロンプトを構築するためのヘルパークラスであるWP_AI_Client_Prompt_Builderが導入され、AIを組み込んだプログラムの品質担保が容易となった 21。

Abilities API と Model Context Protocol（MCP）の高度な統合

このAIアーキテクチャの真価は、Abilities API（アビリティAPI）およびオープンソースの通信プロトコルであるModel Context Protocol（MCP）との連携にある 4。Abilities APIは、プラグインが自らの持つ独自の処理（コンテンツ生成、SEO分析、画像加工など）を「能力（Abilities）」としてAIシステム側に登録する仕組みを提供する 4。

MCPにより、Claudeなどの外部AIアシスタントやAIオーケストレーターは、WordPressがどのようなアビリティを公開しているかを自動的に「発見」し、セキュアなポリシーの制限下でWordPress内のデータ取得や投稿生成などのアクションを要求・実行できるようになる 4。これは、単にAIが文字を書くだけでなく、AIエージェントが自律的にWordPressサイトの運営やメンテナンスをサポートする「自律エージェント型Web（Agentic Web）」の実現へ向けた土台が完全に整備されたことを意味している 4。

管理画面の近代化：DataViewsへの完全移行と互換性リスク

WordPress 7.0におけるもう1つの劇的な変化は、管理画面（wp-admin）が2013年以来初めてとなる、大規模なビジュアルおよびUXの再構築を行ったことである 4。

DataViewsによる管理機能の近代化

これまでの記事一覧や固定ページ一覧を出力してきた、サーバーサイドPHP駆動の WP List Tables は完全にDataViewsシステムに置き換えられた 10。これにより、従来のページリロードを必要とするフィルタリングや検索から解放され、ブラウザ内で即時にコンテンツを並び替え、絞り込み、整理する柔軟なダッシュボードが実現した 4。テーブルビュー、グリッドビュー、リストビューを切り替えて利用することができ、管理画面全体が最新のSaaSアプリケーションに近い手触りへと変貌を遂げている 4。

また、新しいデフォルト配色である「Modern」スキームによるタイポグラフィの改訂、さらに画面遷移時のハードリロードを不要にする「View Transitions API」の採用により、各管理画面を滑らかなアニメーション効果で横断することができるようになった 9。

カスタム管理画面におよぶ互換性の危機

これらの洗練されたUI/UXは、一方でレガシーなサードパーティ製プラグインやカスタムテーマに対して深刻な「破壊的変更」をもたらす 10。

まず、自社製プラグインやカスタム投稿タイプで、旧来のPHPテーブルクラスに依存したダッシュボードデザインを行っている場合、DataViewsのReactコンポーネントと競合して表示崩れやJavaScriptエラーを誘発する 10。さらに、従来のブラウザ再読み込み（ハードリロード）を前提に設計されたjQueryプラグインやトラッキングスクリプトは、View Transitionsによるノンリロードな動的遷移によって、画面遷移時にイベントリスナーが適切に初期化されず、動作を停止するケースが多発している 10。

新テーマ戦略と「Twenty Twenty-Six」の不採用

前述の通り、WordPress 7.0は恒例の新しいデフォルトテーマ「Twenty Twenty-Six」の同梱を見送った 9。これは現在のデフォルトテーマである「Twenty Twenty-Five」および既存のブロックテーマが十分に成熟し、高度な機能カスタマイズに対応できるようになったことを裏付けている 4。

テーマそのものを毎年入れ替えるという過去のパラダイムを捨て去り、充実したエディター機能や「Appearance > Fonts」による高度なフォントライブラリの管理、スタイルバリエーションを活用することで、既存のテーマを進化させるアプローチへと舵を切っている 4。なお、次期デフォルトテーマである「Twenty Twenty-Seven」は、Henrique Iamarinoを筆頭とした新しい体制で開発が進められている 24。

エディター機能の進化と「保留・除外された機能」の徹底検証

コンテンツエディターは、デザインの一貫性を高めるいくつかの新しいコアブロックや機能強化を受けている 2。一方で、開発の最終局面で実装が見送られ、将来リリースに「保留（デファード）」された技術的な要素も多く、その識別がブログ作成や開発において必須となる 10。

実装された最新ブロックと機能

• Breadcrumbs / Icons ブロックの登場: 外部プラグインに依存せず、パンくずナビゲーションとSVGアイコン（初期88種）を自由に挿入できる仕組みが整った 19。ただし、Iconsブロックは現在ユーザー独自のSVGファイルの直接アップロードに対応しておらず、より高度なアイコン運用を行っている場合は引き続きサードパーティプラグインが選定される 19。
• Visual Revisions（ビジュアルリビジョン）: 旧来の生コード比較とは異なり、実際にブラウザ上で表示されるレイアウトの状態で、追加箇所（緑）、削除箇所（赤）、変更箇所（黄）がカラーコーディングされて変更を追跡できるシングルカラム型リビジョン管理インターフェースが実装された 9。
• Block API v3およびIframedエディタの浸透: ブロック構築の標準規格がBlock API v3へと引き上げられ、ブロックエディタのIframe（インラインフレーム）保護が強化された 10。これによりサードパーティプラグインの競合によるエディタのレイアウト破損が完全に防止され、フロントエンドと完全に同一の見た目で編集可能となった 4。
• デザインの利便性向上機能: CSSを書かずに1行目の字下げができる「Text Indent」や、カラムブロックを分けずに段組を作れる「Text Columns」のほか、Coverブロックでの動画埋め込み、GalleryブロックのLightbox機能など、コンテンツ制作をサポートする多くの機能強化が行われた 21。

クライアントサイド・メディアプロセッシングの差し戻し

ベータ段階の各種リリース情報やアーリーアダプター向けの解説記事では、画像のアップロード時にサーバーのリソースを消費せず、ユーザーのブラウザ側（クライアントサイド）のコンピューティングパワーを利用して画像をあらかじめリサイズ・圧縮する「Client-Side Media Processing」が画期的な機能として紹介されていた 3。

しかし、最終的なパッケージログによれば、この機能はいくつかのブラウザ依存のエラーや画像劣化、互換性上の問題から、ベータ6の段階でコア実装から一時的に「リバート（差し戻し・取り消し）」が完了している 9。現在のWordPress 7.0安定版においては同機能は有効化されておらず、従来通りサーバー側でのメディア処理が引き継がれている点に注意を払う必要がある 9。

WordPress 7.1へ保留・延期された主な機能

開発が完了せず、または安定性テストの結果、次回のマイナーバージョン「WordPress 7.1」（2026年8月予定）以降へと持ち越された機能群を以下の表に整理する 2。

実践的なWordPress 7.0 移行計画：エラー回避のための専門的ワークフロー

WordPress 7.0の劇的なアーキテクチャ再構築に伴い、Webサイトのアップグレードは極めて慎重に進める必要がある 10。本節では、サイト監査からデプロイ、稼働後の監視に至る実践的な技術移行プロセスを提示する 10。

第1フェーズ：サイトの事前監査と互換性確認

サイトの運営チームは、本番環境の直接操作を行うべきではない 10。まずは、管理画面上の「Site Health（サイトヘルス）」または専門監査ツール「mySites.guru」等を利用して、稼働環境の徹底監査を実施する 13。これには、PHPが最低動作基準である7.4（推奨8.3/8.4）をクリアしているか、そしてデータベースがDataViewsのウィンドウ関数やCTEに対応したMySQL 8.0以上であるかの判定を含む 13。これらのインフラレベルでのアップデートを、WordPress本体の更新よりも「前」に完了させておくことが、致命的な画面停止や管理画面クラッシュを防ぐ絶対条件となる 10。

第2フェーズ：テスト環境での稼働検証とレガシーコードの検出

インフラが基準に達したら、本番環境の完全なクローンとなる「ステージング（テスト）環境」を構築する 10。このステージング環境において、「Query Monitor」プラグインをインストールし、カスタムテーマ内の古いテンプレート記述やフックに由来する「非推奨関数（Deprecated Functions）」のワーニングが発生していないかを監視する 12。

特に、クラシックなテーマ構造で functions.php テンプレートタグを多用した設計や、初期の古い @wordpress/scripts に依存したままアップデートを怠っているブロック、あるいはREST APIの独自エンドポイントのバージョン不整合は、WordPress 7.0上で重大な不具合を引き起こす可能性が高い 10。

第3フェーズ：AIコネクターとキャッシュの設定調整

AI接続がアクティブ化された後は、生成処理の遅延から生じる「サーバーのタイムアウトエラー」に配慮しなければならない 12。外部プロバイダーとの頻繁な接続要求によって、AIのレスポンスが極端に低下する場合は、AI生成コンテンツのオブジェクトキャッシュや一時データベースへの結果保存などの「キャッシング機構」を導入することが実効的である 12。

また、社内の機密情報やコンプライアンスに配慮するエンタープライズサイトにおいては、ローカル環境でホストされたプライベートLLMとの連携や、障害発生時に別プロバイダーへ即時にフェールオーバーする「フォールバック」の設定を行うことで、システムの持続性を担保することが可能となる 12。

第4フェーズ：本番環境への安全な段階的デプロイ

すべてのテストが完了した場合でも、一般リリース直後に本番サイトへの適用を行うことは推奨されない 10。世界各国の多様なプラグイン環境で発見された初期不具合がパッチされるマイナーリリース「WordPress 7.0.1」の登場（通常、メジャーリリースから2週間前後で提供される）を待ち、同バージョンを用いて本番環境にアップデートをかけるのが、企業サイトや影響力の大きいプロフェッショナルブログが取るべき最も賢明なデプロイ戦略である 10。

結論

WordPress 7.0は、これまでの単なるコンテンツ投稿のためのシステムから、AIとの自律的な協調運用や、高度にインタラクティブな管理を実現する次世代のインテリジェントWebプラットフォームへと進化を遂げた 4。リアルタイム共同編集機能の延期という一時的な後退はあったものの 2、非同期による充実した「Notes」コラボレーション環境の実装、プロバイダー非依存のAIコアアーキテクチャの確立、そして直感的なビジュアルリビジョンなどの品質向上により、その全体的な完成度は過去最高水準に達している 10。

これに伴い、Webサイトの管理者および開発者は、データベース（MySQL 8.0等）およびPHP要件の厳格化に対する正しい理解と、DataViews導入による既存ダッシュボードコードへの影響範囲を明確に見定める責任が生じることとなった 10。2026年後半に予定されているバージョン7.1および7.2における本格的な共同編集フェーズおよび多言語対応の標準搭載に向けて 2、今回の7.0をインフラから適切に導入し、移行を成功させることが将来のエコシステムで優位に立つための重要な基盤となる 4。