WordPress 7.0 は 2026年5月20日、Armstrong というリリース名で公開されました。当初の2026年スケジュールにあった日付より6週間遅れており、block editor 以来、制作会社にとって最も影響の大きいコアリリースです。見出しになるのは、コアが生成AIモデルと直接やり取りできるようになったことです。しかし、それ以上に重要なのは、プラグインがモデルとどうやり取りすべきかをコア自身が定義するようになった点です。これは、サイト上のすべてのプラグインが自分の領域について前提としてよいことを、静かに変えてしまいます。

編集者から見た変更は控えめです。Command Palette、整理されたダッシュボード、フォント管理画面、そして改善されたリビジョンがあります。しかし、業務としてサイトを保守する人間にとって重要な変更は、管理画面の下にあります。options テーブルに置かれる資格情報のストア、サイトができることのレジストリ、そしてそれらを一覧する REST の面です。どれも任意ではありません。誰かが選んだプラグインではなく、コアとともに届くからです。

これは実務者向けの読み解きです。実際に何が入ったのか、リリースの12日前に何が引き抜かれ、それはなぜだったのか、アップデートで何が壊れて何が壊れないのか、そして AI が WordPress に入るという見出しを読んだばかりのクライアントに何と説明すべきか。

アップデートすべきでしょうか。 すべきです。ただし 7.0 で止めず 7.1 まで進めてください。WordPress 7.1 は 2026年8月19日に公開されており、7.0 には4本のメンテナンスリリースが積み上がっています。AI 機能は、管理者が設定から Connectors でプロバイダーのキーを保存するまで動きません。つまりアップデートそのものが、あなたのコンテンツをどこかへ送ることはありません。このアップデートの本当のリスクは AI ではなく、ごく普通のプラグインとテーマの互換性です。


WordPress 7.0 で実際に出荷されたもの

リリース名はルイ・アームストロングにちなんでいます。メジャーバージョンをジャズミュージシャンの名前で呼ぶ、プロジェクトの慣習に沿ったものです。リリースアナウンスは、875人を超える貢献者と、420件を超える機能強化および修正を挙げています。

入ったものの一覧は、役に立つ程度に短いです。コアは AI Client を得ました。生成モデルへプロンプトを送るための、プロバイダー非依存の PHP インターフェースです。設定の下には Connectors 画面が加わり、管理者がプロバイダーの資格情報をそこに保存します。そして Abilities API の JavaScript 側が入りました。PHP 側はすでに 6.9 で出荷済みでした。

編集面では、Ctrl+K または Cmd+K で開く Command Palette、刷新されたダッシュボード、専用のフォント管理ページ、リビジョンを視覚的にスクラブする機能、そして Heading、Breadcrumbs、Icons の各ブロックと、ギャラリー用のライトボックス・スライドショーが追加されました。

入らなかったのは、このリリース全体がその周りに組み立てられていた機能でした。リアルタイム共同編集は、公開の12日前に削除されました。その不在と、その理由こそが、機能一覧よりもコアの現状をよく物語ります。

日付が動いた理由

リリースは当初 2026年4月9日に予定されていました。共同編集が仕上がっておらず、プロジェクトがその状態のまま出荷しないと判断したため、5月20日にずれ込みました。今後の道筋を示した投稿は、遅延が「リアルタイム共同編集の実装に関するテストのフィードバックへ対応する時間を確保するため」に存在したと明言しており、開発サイクルは技術的な理由からリリース候補のバージョン番号を保ったまま、ベータへ戻りました。

これは異例です。RC に到達したメジャーリリースがベータへ戻るのは強いシグナルであり、そしてそれは正しい判断でした。

AI Client、コアが出荷するのは抽象化であってモデルではない

WordPress 7.0 について最も重要なアーキテクチャ上の事実は、コアが AI モデルも API キーも、どのベンダーとの関係も含んでいないことです。AI Client の開発ノートは「WordPress コアは AI プロバイダーを直接同梱しない」と平易に述べています。

コアが出荷するのは、一貫した PHP インターフェースです。プラグインは wp_ai_client_prompt() を呼び、返ってきた WP_AI_Client_Prompt_Builder オブジェクトに using_temperature()using_model_preference() といった設定をチェーンし、最後に generate_text() または generate_image() で締めます。エラーは WP_Error として返り、リクエストは WordPress の HTTP トランスポートを通り、全体がフックの仕組みに組み込まれています。

実務的な効果は、プラグイン作者がモデルのベンダーごとに HTTP クライアント、リトライループ、キーの保存画面、設定ページを書かなくてよくなることです。何が欲しいかを記述すれば、コアが経路を用意します。

これは重複コードの本物の削減です。同時に信頼の集中でもあり、何かを有効にする前に考えておく価値があるのは、その部分です。

コネクターとは何か

コネクターとは、あなたのサイトと外部サービスとのあいだに登録された関係のことです。7.0 でのコネクターの種類は AI プロバイダーだけで、Anthropic、Google、OpenAI をそれぞれ扱う3つの旗艦プロバイダープラグインがあり、いずれも個別にインストールします。

Connectors API の開発ノートは、資格情報がどう解決されるかを説明しています。キーは環境変数、PHP 定数、データベース設定のいずれかから来て、その順に確認され、オプション名は connectors_ai_{$id}_api_key というパターンに従います。

サイトに責任を持つ人が注目すべき点がひとつあります。開発ノートは、データベースに保存された API キーは「暗号化されていないが、ユーザーインターフェースではマスクされる」と述べ、暗号化は今後の作業として追跡されているとしています。管理画面からキーを設定すると、それは平文のまま wp_options に置かれ、そのデータベースのバックアップはすべて、課金対象の資格情報を含むことになります。

コードを書かない人にとっての意味

サイトの持ち主にとって、変化は聞こえるほど複雑ではありません。2つの条件がそろうまで、何も生成されず、要約されず、書き換えられません。プロバイダープラグインがインストールされていること、そして誰かが有効なキーを設定から Connectors に貼り付けていることです。

それまで AI Client は休眠中のライブラリにすぎません。WordPress 7.0 へのアップデートは、あなたの投稿をモデルへ送りませんし、どこかにアカウントを作ることも、請求を発生させることもありません。

ただし、次にインストールするプラグインにとっての敷居は下がります。これまであなたにキーを尋ねる必要があったプラグインが、サイトにすでに設定済みのキーを見つけて使えるようになります。それは便利であり、まさに、偶然そうなってしまう前に方針を書いておくべき類のことです。

Abilities API と、プラグイン設計が変わる理由

3年後にも意味を持ち続けるのは Abilities API のほうで、これは本質的には AI と関係がありません。レジストリです。プラグインは wp_register_ability() によって、namespace/ability-name という形式の名前付きの機能単位を、人間が読める説明、入出力の JSON Schema、実行コールバック、そして任意の権限コールバックとともに登録します。

公式ドキュメントは、権限コールバックをごく普通の権限チェックとして示しています。たとえば current_user_can( 'manage_options' ) を返すだけです。それがセキュリティモデルのすべてであり、プラグイン作者の判断の質を超えることはありません。

アビリティが存在すれば、ほかのものがそれを列挙できます。モデルは、このサイト固有のできることの一覧をスキーマの形で渡され、そのひとつを呼び出せます。クライアント側の Command Palette も同じことができます。API の JavaScript 側が Command Palette と同じリリースで入ったのは、そのためです。

プラグイン作者にとっての設計上の帰結は現実的です。これまで自分の管理画面から、自分の nonce と自分のフォームを通してしか到達できなかった機能を、機械可読な契約を持つアビリティとして公開するよう期待されるかもしれません。それは異なる攻撃面であり、異なるドキュメントの負担です。

7.1 で変わったこと

WordPress 7.1 はレジストリを拡張するのではなく、締め上げました。7.1 の Abilities 開発ノートは、検証フィルター wp_ability_validate_inputwp_ability_validate_output、実行の開始時に発火するアクション wp_ability_invoked、そして /wp-json/wp-abilities/v1/abilities の REST でアビリティが発見可能かどうかを制御する public メタデータフラグを追加しています。

その開発ノートには、ログを扱うプラグイン作者が全員読むべき一文もあります。呼び出しフックは生の、正規化されていない入力を受け取るため、開発者は「資格情報、個人情報、その他の機微なデータが含まれる可能性があるため、入力を無差別にログへ記録することは避けるべき」だとされています。

リアルタイム共同編集と、それが必要としたテーブル

共同編集は、競合しない複製データ型である Yjs の上に、同期プロバイダーの抽象化を重ねて作られています。コアは既定で HTTP ポーリングのプロバイダーを出荷します。どのホスティングでも動くという理由で WebSocket より優先されたもので、プラグインはフィルターでトランスポートを差し替えられます。

問題はマージのアルゴリズムではありませんでした。同期データがどこに置かれるかでした。当初の実装はそれを投稿メタに永続化していました。WordPress では自明な選択であり、毎秒何度も変化するデータにとっては誤った選択です。

投稿メタへの書き込みはキャッシュの無効化を引き起こします。エディターを開いているあいだ同期データは絶えず書き込まれるので、書き込みのたびにその投稿のキャッシュ済みクエリが消えます。実際には、1人がページを編集しているだけで、セッションのあいだじゅうサイトの永続オブジェクトキャッシュを流し続けることがありました。

これは投稿メタについての良い一般教訓です。投稿メタは、ぶら下がっているコンテンツのキャッシュのライフサイクルに結び付いたキーバリューストアであり、投稿が変わったときに変わる属性には適しています。高頻度で変わる状態を置くための作業領域ではありません。

計測された修正と、その決定

貢献者は8つのホスティング環境でストレージ戦略をテストしました。パフォーマンス分析は、トランジェントに支えられた専用テーブルが既存の実装よりおよそ52%速く、素の専用テーブルがおよそ37%速いと結論しました。永続オブジェクトキャッシュがある場合、トランジェントを使う2つの戦略はどちらも、ディスパッチあたり1回のデータベースクエリまで落ちました。

選ばれたのはトランジェント付きのカスタムテーブルでした。そして同じ日に、この機能は引き抜かれました。

削除の告知は「表面積、競合状態、サーバー負荷、メモリ効率、そしてファズテストで見つかった再発するバグへの懸念」を挙げ、この決定は「利用者に安定して信頼できる WordPress 7.0 リリースを届けるために」下されたとしています。

現在の位置づけ

7.1 でも出荷されませんでした。7.1 のフィールドガイドは、リアルタイム共同編集について「WordPress 7.1 のサイクル中に広範なテストとフィードバックを受けたが、最終リリースでは有効化されていない」と述べています。

ブロック単位のコメントを残すための、関連するが別の機能である Notes は出荷され、7.1 でリッチテキスト書式と @ メンションが加わって改善されました。クライアントが WordPress で Google ドキュメント風の同時編集を求めたとき、今日の正直な答えは、Notes がレビューのワークフローを担い、同時入力は依然としてコアにない、というものです。

管理画面の変更と、そこから生まれる問い合わせ

問い合わせを生む変更が2つあり、どちらもバグではありません。

Ctrl+K または Cmd+K の Command Palette は、覚えてしまえば実に速いのですが、Ctrl+K は多くのエディターでリンク挿入のキーボードショートカットです。リンク挿入が壊れたと報告するユーザーが出ます。壊れてはいません。どのハンドラーが勝つかは、フォーカスの文脈が決めます。

より大きいのは刷新されたダッシュボードです。スタッフがスクリーンショットで訓練されていたクライアントは、その教材が古くなります。特定のクラスや DOM 構造を前提に管理画面へマークアップを差し込んでいたプラグインは、表示が崩れることがあります。これは機能ではなく見た目の問題ですが、アップデート当日に、すべてのサイトで、すべてのユーザーに現れます。だからこそ、開発者ではない人々にとっては、リリースで最も目につく部分になります。

何かをアップデートする前に、新しいスクリーンショットを添えた短い書面の案内のために、クライアント1社あたり1時間を見込んでおいてください。同じ説明をメールで15回繰り返すより安く済みます。

本当に効いてくる互換性の問題

バージョン番号は破壊的なリリースを思わせます。PHP の要件はそうではありません。PHP サポートの明確化が示すとおり、WordPress 7.0 以降サポートされる PHP の最低バージョンは 7.4 であり、推奨される最低バージョンは 8.3 のままです。PHP 7.2 と 7.3 のサポートは、このリリースで打ち切られました。

この明確化はまた、新しい PHP バージョンに付いていた古いベータという表示を廃止し、WordPress 6.9 と 7.0 における PHP 8.5 の完全なサポートを記録しています。

要点は、サポートされることと妥当であることのあいだの隔たりです。PHP 7.4 は2022年11月にサポート終了を迎えているので、最低ラインをかろうじて満たすだけのサイトは、4年近くセキュリティ修正を受けていないインタープリターで動いていることになります。2026年になってもホスティングが 7.4 のままなら、WordPress のバージョンはあなたにとって最も急ぐべき問題ではありません。

実際の破損は、予測できるパターンをたどります。放棄されたプラグインが最初に壊れます。とりわけ管理画面の DOM やエディターの iframe を操作するものです。管理画面のスタイルをハードコードしたカスタムテーマは、見た目が崩れます。自前の React バンドルを同梱するページビルダーはエディターの白画面の常習的な原因であり、同時に、たいてい最も早く修正を出します。

具体的なアップデート手順

ステージングを用意します。 本番をデータベースごと、インデックスされずメールも送らない環境へ複製します。以下は本番で試す価値のあるものではありません。

基準を記録します。 PHP のバージョン、プラグインとテーマの一覧とそれぞれのバージョン、そして現在の WordPress のバージョンを控えます。クライアントが毎日使う管理画面を2つか3つ、スクリーンショットに残します。

まず WordPress だけを更新します。 プラグインとテーマには触れず、フロントエンド、投稿エディター、サイトエディター、WooCommerce があればその決済、そして独自の管理画面を順に歩きます。ここでの失敗はコアか、互換性のない拡張に属します。それをプラグインの更新と切り分けることが、この順番で作業する理由そのものです。

次にプラグインを小さなバッチで更新します。 バッチのあいだで再テストすれば、不具合が起きたときの容疑者リストが短くなります。

ページを目で見るのではなく、エラーログを確認します。 非推奨の呼び出しから出る PHP の通知は必ずしも画面に現れず、何か月も静かにログを埋め続けます。

Connectors 画面は空のままにします。 AI プロバイダーを設定しない状態でアップデートを出し、有効化は独自の承認を伴う、別個の意図的な変更として扱ってください。周辺の統制についてはWordPress セキュリティ強化チェックリストが、その後に何を計測すべきかについてはパフォーマンス監査ガイドが扱っています。

ガバナンス、コネクターに何を許すのか

ここに、アビリティの層が生み出し、どのプラグイン作者もあなたの代わりに答えられない問いがあります。サードパーティのプラグインは、顧客レコードを読む、ユーザーを書き出す、公開済みのコンテンツを編集するといったアビリティを登録でき、レジストリにアクセスできるモデルはそれを呼び出せます。権限コールバックは権限チェックなので、モデルはサインインしている人の権限で動きます。

その人が管理者なら、モデルは管理者にできることをできます。それは設計上の欠陥ではなく、文書どおりに設計が働いているだけです。ただしそれは、どのコネクターがサイトに存在するかという判断が、IT の好みではなくデータ保護上の判断であることを意味します。

CMS の中身が単なるマーケティングの文章であることは、めったにありません。コメント、フォームの送信、注文の記録、ユーザープロフィールは個人データであり、それらを外部のモデルへ送ることは、正当化できなければならない処理行為です。ICO のAI とデータ保護に関するガイダンスは、設計段階からのデータ保護を示すことや、ガバナンスを用途に見合った規模に保つことを含め、説明責任と透明性への期待を示しています。

クライアントのサイトにとっての実務上の最低限は、短い書面の方針です。どのコネクターを許すのか、誰が追加してよいのか、どのアビリティを REST で公開するのか、そしてプロバイダーとのあいだで保持期間をどう定めるのか。誰かがキーを貼り付ける前に書いてください。あとからでは、それは方針ではなくインシデント報告になります。

次に控えているもの

WordPress 7.1 は 2026年8月19日に到着し、グローバルスタイルのレスポンシブな設定、エディターをまたいで残る管理バー、まともなメディア編集モーダル、Playlist と Tabs のブロック、そしてすでに触れた Notes の改善をもたらしました。レガシーなメタボックスを登録するサイトも含めて、投稿エディターの iframe 化も完了しています。古いプラグインを露呈させる可能性が最も高い変更は、これです。

WordPress 7.2 は 2026年最後のメジャーリリースとして計画されています。7.2 のリリースページは、最終リリースを 2026年12月8日から10日の枠に置き、ベータは10月下旬からとしています。この日程は出荷済みではなく計画であり、このプロジェクトは今年すでに、メジャーリリースの日付を1度動かしています。

共同編集は将来のリリースの明らかな候補であり続けますが、すでに2回逃しており、誰もクライアントに日付を約束すべきではありません。

商業的に何が変わるのか

クライアントとの会話が3つ変わり、そのうち AI についてのものは1つだけです。

1つ目はアップデートの会話です。WordPress 7.0 と 7.1 は、ステージングでの検証を含む管理アップデートとして料金を取る価値があります。iframe 化されたエディターと管理画面の再設計が、古い拡張を実際に浮かび上がらせるからです。書面のテスト計画を添えた定額パッケージとして売るほうが、保守契約に飲み込ませて午後6時に壊れたページビルダーを見つけるより、誠実で利益も出ます。

2つ目はガバナンスです。コネクターの方針、アビリティのレビュー、資格情報の取り扱いは、2026年5月以前には存在しなかった課金可能な助言業務であり、社内のマーケティングチームより制作会社に向いています。

3つ目は構築の仕事です。AI Client は、サイトに AI 機能を作り込む作業の退屈な半分を取り除きます。配管の価格を下げ、何を作る価値があるかを知っていることの価値を上げるのです。それを独自開発と比べて検討しているなら、WordPress とカスタム開発の比較が線の引かれる場所を、WordPress 開発者の料金についての記事がその作業にいくらかかるべきかを扱っています。

Mecanik は、コアのバージョンアップ、コネクターのガバナンス、AI 機能の開発をWordPress 開発およびAI 統合のサービスの一部として引き受けています。見えてくるパターンは一貫しています。アップデートそのものは定型の作業であり、高くつく驚きは、3年間誰もレビューしていなかった拡張から出てきます。



よくある質問

WordPress 7.0 はいつ公開され、なぜ遅れたのですか? WordPress 7.0「Armstrong」は 2026年5月20日に公開されました。当初のスケジュールにあった4月9日から6週間後です。遅延はリアルタイム共同編集の実装に関するテストのフィードバックへ対応するためで、開発サイクルはリリース候補に到達したあとベータへ戻りました。共同編集は最終的に 2026年5月8日にリリースから削除されました。

WordPress 7.0 は私のコンテンツを AI プロバイダーへ送りますか? 送りません。コアは AI Client を出荷しますが、AI プロバイダーもモデルも API キーも同梱していません。管理者がプロバイダープラグインをインストールし、設定から Connectors で有効な資格情報を保存するまで、何もどこへも送られません。それまで AI Client は、費用も通信も発生しない休眠中のライブラリです。

Abilities API は何のためのものですか? プラグインが、JSON Schema による入出力、権限コールバック、実行コールバックを備えた名前付きの機能単位を宣言できるレジストリです。AI モデルや Command Palette を含むほかのソフトウェアが、サイトにできることを列挙して呼び出せます。PHP 側は WordPress 6.9 で、JavaScript 側は 7.0 で出荷されました。

WordPress 7.0 はどの PHP バージョンを必要としますか? サポートされる最低バージョンは WordPress 7.0 以降 PHP 7.4 で、このリリースで PHP 7.2 と 7.3 のサポートが打ち切られました。推奨される最低バージョンは PHP 8.3 のままです。PHP 7.4 は2022年11月にサポート終了を迎えているため、最低ラインだけを満たすことはサポートのないインタープリターで動かすことを意味します。実質的な要件は 8.3 以上だと考えてください。

リアルタイム共同編集はもう使えますか? コアでは使えません。競合状態、サーバー負荷、メモリ効率への懸念から、公開の12日前に WordPress 7.0 から削除され、WordPress 7.1 でも有効化されていません。ブロック単位のコメントとメンションを可能にする別機能の Notes は出荷済みで、同時入力ではなくレビューのワークフローを担います。