WordPress 7.0の新機能と注意点｜本番6週間の運用記録

上げる前に見たのは、結局2か所だけでした
本番に入れて、最初に変わって見えたのは一覧画面でした
RTCはなぜ7.1へ動いたのか、そして共用サーバーの話
開発者としての宿題は、まだ残っています
これから上げる人は、ここだけ見れば足ります
参考にした公式情報

結論から。WordPress 7.0は、Cocoon＋Xserverのこのサイトの本番で、リリース当日から6週間そのまま動いています。RTCは入っていません。中心はAI連携の基盤とDataViewsによる管理画面の刷新で、上げる前に見るべきはPHPとMySQLのバージョン、上げたあとに効いてくるのは一覧画面の変化とAI基盤の作法でした。この記事は5月20日のリリース当日に書いたまとめを、6週間運用した結果で書き直したものです。

2026年5月21日の未明、寝る前にスマホでMake WordPress Coreを開いたら、7.0「Armstrong」のリリース告知が出ていました。少し前まで目玉と言われていたリアルタイム共同編集（RTC）は、結局7.0から外れて7.1へ。コードネームはジャズ奏者のLouis Armstrongにちなみます。私はWordPress.orgにプラグインを3本公開している開発者で、このサイト自体が7.0の実験台です。運営者として何が変わったか、開発者として何を直したか、時系列で残します。

上げる前に見たのは、結局2か所だけでした

多くの運営者に直接効くのは、新機能よりサーバー要件の引き上げです。PHPは7.4.0以上が必須になりました（推奨8.3以上。8.0〜8.3が完全互換、8.4・8.5はベータ扱い）。注意したいのは、PHP 7.2 / 7.3のサイトには7.0の自動更新が来ないこと。6.9ブランチに留まり、セキュリティパッチだけ受け取る形になります。データベースはMySQL 8.0以上、またはMariaDB 10.6以上が推奨。PHPより厄介で、レンタルサーバーではMySQLの側がサーバー固定のことが多いからです。

確認場所はどちらも「ツール → サイトヘルス → 情報」。うちのXserverスタンダードはPHP 8.3.21 / MySQL 8.0系で、両方ともそのまま通過でした。AI連携を使うつもりなら、外部SDKがPHP 8.0以上を求めることが多いので、実質8.2以上と考えておくほうが安全です。

本番に入れて、最初に変わって見えたのは一覧画面でした

RTCが外れたと聞いて目玉がなくなったと思ったのですが、早とちりでした。875名超の貢献者、420超の機能強化と修正、Gutenberg 22.0〜22.6のマージ。土台レベルの変更がいくつも入っています。6週間使って、運営者として体感があった順に書きます。

DataViewsが投稿一覧を置き換えました

投稿・ページ・メディアの一覧が、従来のWP_List_TableからReactベースのDataViewsに変わりました。リロードなしで絞り込みと並び替えができます。実際につかってみてWordPress 7.0にしたからと言った速度の大幅な違い、デザインの大幅な崩れはありません。ただ一点、管理画面で絵文字の表示位置がずれているという軽微なものがありました。リリース直後に互換性トラブルが出やすいのもここで、一覧に独自の列やフィルターや一括アクションを足すプラグインを使っているなら、更新前に確認する場所の筆頭です。

AI連携は、入れただけでは何も起きません

7.0の基盤はWP AI ClientとConnectors APIです。誤解されやすいのですが、7.0に更新しただけでAIが動き出すことはなく、外部にデータも送られません。使うにはプロバイダープラグインを入れて「設定 → Connectors」でAPIキーを設定します。公式のOpenAI / Google / Anthropicプラグインはコア同梱ではなく別配布です。

ここは開発者として一度痛い目を見ました。自作チャットボットをWP AI Clientへ移行したとき、エラーも出さずに会話の履歴だけが消える挙動を踏んでいます。with_history()に生配列を渡すと例外なしで履歴が落ちる、という種類の罠でした。顛末はコード付きで別記事にまとめてあります。5月のまとめで「実機検証は別記事で」と書いた宿題の、これが一つ目の回収です。

Notesとビジュアルリビジョンは、地味に外部ツールを減らします

Notesは編集画面でブロックにコメントを付けて@メンションで通知できる仕組みで、Googleドキュメントに貼って戻す往復から抜けられます。ビジュアルリビジョンはテキスト差分ではなく見た目の変化で過去の版と比較できます。どちらも派手さはないけれど、複数人でサイトを回している人ほど効くはずです。

コマンドパレットと新ブロック、そしてフォントライブラリ

どの管理画面からでも⌘K / Ctrl+Kでツールに飛べるようになりました。ブロックはアイコン、パンくず、カバーの動画背景（YouTube / Vimeo）、Gridのレスポンシブ対応あたりが増えています。個人的に一番うれしかったのはフォントライブラリのクラシックテーマ対応です。ブロックテーマ中心だったフォント管理が、外観 → フォントから、Cocoonのようなクラシックテーマでも使えるようになりました。日本語サイトはフォントが読みやすさに直結するので、これは効きます。

7.0に入ったものと、7.1へ外れたもの（RTC）の仕分けです。

RTCはなぜ7.1へ動いたのか、そして共用サーバーの話

RTCはGoogleドキュメントのように複数人が同じ投稿を同時編集する仕組みとして予定されていました。当初の7.0は4月9日目標でしたが、データベース設計を作り直す必要が出て延び、5月8日のRC3のタイミングで7.0から外して7.1で再評価する判断が出ました。Matt Mullenwegは、現状のアプローチがCoreに入れるほど堅牢だと確信が持てない、として競合状態やサーバー負荷を理由に挙げています。7.1はWordCamp USに合わせた2026年8月19日が目標です。

私が個人的に引っかかったのは、RTCのデフォルト同期方式がHTTPポーリングだった点です。当初候補のWebRTCは共用レンタルで使えないことがあり、互換性を理由に却下された。じつは私自身、別件でXserverの共用レンタルにチャットを入れようとして、WebSocketもSSEも通らずLong Pollingに落ち着いた経験があります（その記録）。共用サーバーで動くことを最優先すると、コア側もほぼ同じ場所に着地していたわけです。RC3のテスト協力ホストにXServerが入っているので、7.1で実装されたら動作情報は比較的早く出ると見ています。クラシックメタボックスを使う投稿ではRTCが無効化される設計なので、ACFやSEOプラグインを多用しているなら7.1の前に一度確認を。

開発者としての宿題は、まだ残っています

いちばん大きいのがblock.jsonのapiVersion 3への移行です。7.0以降、apiVersion 3のブロックはiframe内でレンダリングされ、v2以下はその投稿でiframeモードが無効になります。私の作った3プラグイン（Rapls AI Chatbot、Thanks Mail for Stripe、Rapls PDF Image Creator）は、AIコネクターに対応した以外はapiVersion 3で問題ありませんでしたので、Tested up 7.0でアップしてあります。これから新規で書く人は、最初からapiVersion 3で始めるのが安全です。

もうひとつ、投稿一覧に独自の列・フィルター・一括アクションを足しているプラグインは、manage_posts_columnsなどのWP_List_Table系フックがDataViews化の影響を受けることがあります。DataViews自体のAPIにもgroupByFieldがgroupByオブジェクトに変わるといった破壊的変更が入っているので、一次情報はMake WordPress CoreのField Guideと各Dev Noteです。クラシックメタボックスからの移行は、RTCが7.1へ延びたぶん優先度が下がりました。焦らなくて間に合います。

これから上げる人は、ここだけ見れば足ります

リリースから6週間経って、初期の互換性の混乱は一巡しました。上げる手順は、サイトヘルスでPHPとMySQLを確認、ファイルとデータベースの完全バックアップ（戻し方の確認まで）、そしてステージングか本番かの判断です。ステージングで見るなら、投稿編集画面、トップ、問い合わせフォーム、SEO・キャッシュ系プラグイン、独自ブロック。仕事用サイトやWooCommerceで販売しているサイトは、いまでも慎重に進める価値があります。うちは当日に上げて6週間無事でしたが、それはプラグイン構成が自分の管理下にある個人サイトだから取れたリスクでもあります。

2026年は7.0、7.1、7.2と年3回のメジャーリリースが予定されています。7.0で入った基盤の上に、8月の7.1でRTCを含む共同編集が載る予定です。そのとき、あなたのサイトの投稿一覧はもうDataViewsで動いていますか。