WordPress 7.0のAI機能とは？｜更新前に決める触らせ方

「ワードプレスを7.0に上げたら、AIが勝手に記事を書き換えるようになるのではないか」「管理画面にAIの接続先を入れる欄ができたと聞いたが、誰がどの会社の鍵を入れてよいのか決まっていない」。オウンドメディアの担当者や情報システムの担当者から、こうした不安が聞かれます。更新の前に立ち止まって考えるのは、正しい順番です。事実から確かめると、2026年5月20日に公開されたワードプレス7.0は、AIの機能そのものではなく、外部のAI事業者につなぐための共通の土台をコアに持ちました。つまり、これは記事を書くAIが入った更新ではありません。本当は、一つの鍵を登録すると、サイトの中のどのプラグインからもAIを呼べるようになる更新です。この記事では、7.0で何が入り何が見送られたのか、なぜ更新前に触らせ方を決める必要があるのか、そして鍵・権限・送る情報・費用・検証の順に何を決めるかを整理します。

ワードプレス7.0は、いつ何が変わった更新か

ワードプレス7.0は、公式サイトの告知によれば2026年5月20日に公開されました。当初は4月9日の公開が予定されていましたが、同時編集の機能のためのデータの保存の仕組みを作り直すために延期され、改めて5月20日に日程が組み直されました。更新の告知では、800人を超える貢献者が関わったと紹介されています。

延期の理由になった同時編集は、結局7.0には入りませんでした。公開の12日前にあたる5月8日に、共同創業者のマット・マレンウェッグ氏が、今のやり方はコアに入れるほど頑丈だと言い切れないとして見送りを決めています。複数の人が同時に触ったとき、回線が遅いとき、サーバーが混んでいるときの動きに不安が残ったと説明されています。同時編集は、開発用のプラグインで引き続き試せる扱いです。

このほか、管理画面の見た目の刷新や、キーボードで操作を呼び出せる検索窓などが入りました。一方で、タブやスライダーなど予定されていた一部のブロックも見送られています。AIの話だけが目立ちがちですが、7.0は管理画面と編集画面の両方が変わる大きな更新であり、AIの取り決めも他の変更点と一緒に検証する必要があります。

コアに入ったのは「AIの機能」ではなく「つなぐ土台」

7.0でコアに入ったAI関連の部品は三つです。一つめはAIクライアントと呼ばれる、プラグインがAIに指示を送り、結果を受け取るための共通の呼び出し口です。開発者向けの説明では、提供元を選ばない作りで、プラグインは「どの会社のAIを使うか」を気にせずに「何をしたいか」だけを書けばよいとされています。

二つめは、外部のAI事業者との接続を管理する仕組みと画面です。管理画面の「設定」の中に「コネクタ」という項目ができ、アンソロピック、グーグル、オープンエーアイの三社が標準の接続先として並びます。三つめは、プラグインが「自分はこんな操作ができる」とサイトに申告するためのアビリティと呼ばれる仕組みで、AIや自動化の道具がサイトの機能を共通の形で扱えるようにするものです。

大切なのは、開発者向けの説明が、コア自体は利用者向けのAI機能を持たないと明言している点です。記事の下書きを作る、タイトルを提案する、といった機能は、コアではなくプラグインが担います。公式の告知では、別に用意された任意のAIプラグインを入れると、画像の生成や編集、タイトルや抜粋の作成、代替テキストの提案ができると紹介されています。つまり、更新しただけでは記事は一文字も書き換わらないのです。

アビリティの仕組みには、管理画面の中で使う部品も用意され、キーボードから呼び出す検索窓とつながっています。解説記事の中には、プラグインだけでなく外部のAIエージェントがサイトを読んだり操作したりする共通の方法になると紹介するものもあります。そうなれば、どの操作を外から呼ばせてよいかも、いずれ取り決めの対象になります。

課題：鍵を一つ入れると、どのプラグインからもAIを呼べる

更新しただけでは何も起きない、というのは安心材料に見えます。しかし、ここに運用上の落とし穴があります。コネクタの画面に一度鍵を入れると、その鍵はサイト全体の設定として扱われます。開発者向けの説明には、サイトの設定なので、すべてのプラグインがその鍵を使えるという趣旨の一文があります。

これまでは、AIを使うプラグインはそれぞれ自分の設定画面を持ち、鍵もプラグインごとに入れるのが普通でした。どのプラグインがAIを使っているかは、鍵を入れた設定画面を見れば分かりました。7.0の仕組みでは、鍵は一か所にまとまる代わりに、どのプラグインがその鍵でAIを呼んでいるかが、設定画面からは見えにくくなるという逆の面が出てきます。

オウンドメディアのサイトには、入力フォーム、検索、画像の最適化、翻訳など、多くのプラグインが入っています。それらが更新で共通の呼び出し口に対応すれば、鍵が入っているだけで、担当者の知らないところでAIへの送信が始まるおそれがあります。鍵を入れる前に、呼ばせてよいプラグインを決めておくことが、この更新で最初に必要になる取り決めです。

原因1：鍵の置き場所が三つあり、優先の順番が決まっている

接続の仕組みの説明によれば、鍵は三つの場所から読み込まれます。サーバーの環境変数、サイトの設定ファイルに書く定数、そして管理画面から入れてデータベースに保存する方法です。読み込みの順番もこの並びで、環境変数が最優先、データベースが最後とされています。

この順番を知らないと、混乱が起きます。たとえば情報システムの担当者がサーバーの環境変数に会社の鍵を設定したあと、編集部の担当者が管理画面から自分の鍵を入れても、実際に使われるのは環境変数の鍵のほうです。逆に、情報システムが何も設定していなければ、管理画面に入れた個人の鍵がそのままサイト全体で使われます。

どこに鍵を置くかは、誰が鍵を管理するかと同じ意味を持ちます。サーバーの設定を触れるのは情報システムや制作会社で、管理画面を触れるのは管理者の権限を持つ編集部の人です。鍵の置き場所を一つに決め、他の置き場所は使わないと決めることで、どの鍵が使われているかを誰でも説明できる状態にしておきます。

環境変数に鍵を置く方法には、検証環境と本番で別の鍵を使い分けやすいという利点もあります。データベースに鍵を入れると、本番を検証環境に複製したときに本番の鍵もそのまま付いていきます。サーバーごとに環境変数を設定しておけば、検証環境では上限の小さい検証用の鍵、本番では本番の鍵と自然に分かれます。

原因2：データベースに入れた鍵は暗号化されていない

管理画面から入れた鍵について、接続の仕組みの説明は、データベースに保存された鍵は暗号化されず、画面上で伏せ字になるだけだと書いています。暗号化は別の課題として検討中とされ、7.0の時点では入っていません。画面で見えないことと、守られていることは別の話です。

データベースの中身は、バックアップのファイル、検証環境への複製、制作会社への引き渡しなど、さまざまな経路でサイトの外に出ます。データベースを丸ごと複製した検証環境があれば、そこにも同じ鍵が入ります。鍵が漏れると、他人がその鍵で有料のAIを呼び出せ、請求は鍵の持ち主に届きます。

暗号化の検討は、開発の課題として公開の場で進められています。今後の版で保存の仕方が変わる可能性はありますが、変わったかどうかは版の告知や開発者向けの説明を読まなければ分かりません。今の時点では「データベースの鍵は守られていない」前提で決まりを作り、版が上がるたびに開発者向けの説明を確かめて、決まりを緩めてよいかを見直します。

このため、会社の鍵はデータベースではなく、サーバーの環境変数か設定ファイルに置くのが基本です。どうしても管理画面から入れる場合は、使える金額に上限を付けた専用の鍵を事業者の管理画面で発行し、他の用途と使い回さないようにします。鍵の発行と失効の手順は、エージェントに鍵を渡す話と共通する部分が多いので、社内の鍵の管理の決まりに合わせてください。

原因3：送られる情報と、費用が生まれる場所が見えにくい

共通の呼び出し口を通じてAI事業者に送られるのは、プラグインが組み立てた指示文、設定、そして添付されたファイルです。記事の要約を作るプラグインなら記事の本文が、画像の説明を作るプラグインなら画像そのものが送られます。下書きの段階の原稿や、公開前の新製品の情報も、プラグインが対象にすれば送られます。

費用はワードプレスの側ではなく、鍵を発行したAI事業者の側で、使った量に応じて発生します。開発者向けの説明の読者からは、使用量の上限や使った量を見る画面を求める声が出ていましたが、7.0の時点ではそうした機能はコアに入っていません。どのプラグインがどれだけ使ったかは、ワードプレスの画面からは分からないと考えておく必要があります。

送られた原稿がAI事業者の側でどう扱われるか、学習に使われるかどうかは、鍵を発行した契約の条件で決まります。法人向けの契約で学習に使わない設定になっているか、保存期間はどれくらいかを、鍵を発行する前に確かめます。個人の契約で発行した鍵を会社のサイトに入れると、会社の原稿が個人の契約の条件で扱われることになるため、避けてください。

対策1：どの事業者の鍵を、誰が、どこに入れるかを決める

ここから、更新の前に決めることを順に見ていきます。最初は鍵です。まず、どのAI事業者を使うかを決めます。すでに社内で法人契約のある事業者があれば、そこに揃えるのが自然です。複数の事業者の鍵を並べて入れると、どのプラグインがどの事業者を使っているかが分かりにくくなるため、最初は一社に絞ることを勧めます。

次に、鍵を発行する人と入れる人を決めます。発行は、AI事業者の法人契約を管理している情報システムの担当者が行い、入れる場所はサーバーの環境変数か設定ファイルにします。編集部の管理者には、コネクタの画面に自分で鍵を入れないことを決まりとして伝えます。制作会社に保守を任せている場合は、契約の中で鍵の扱いを誰が持つかを書き足しておきます。

鍵には、使える金額の上限と有効期限を付けます。上限は事業者の管理画面で設定し、月の途中で上限に近づいたら通知が届くようにします。担当者の異動や制作会社の交代のときに鍵を入れ替える手順も、この段階で書いておきます。

鍵ごとに、発行日、発行した人、置き場所、上限金額、有効期限、使ってよいサイトを一行にまとめた台帳を作ります。オウンドメディアが複数ある会社では、サイトごとに鍵を分けておくと、どのサイトでどれだけ使ったかを事業者の管理画面で見分けやすくなります。台帳は情報システムが持ち、編集部の責任者も見られる場所に置きます。

対策2：プラグインにAIを呼ばせてよいかを一覧で決める

鍵を入れる前に、サイトに入っているプラグインを一覧にし、それぞれがAIを呼ぶ機能を持つか、持つなら何を送るかを確かめます。プラグインの更新情報や説明のページに、共通の呼び出し口に対応したと書かれているかを見ます。対応をうたうプラグインは、今後の更新で増えていくはずなので、一覧は一度作って終わりではなく、プラグインの更新のたびに見直すものです。

一覧には、プラグインごとに「呼ばせてよい」「呼ばせない」「検証してから決める」の三つのどれかを書きます。呼ばせない場合は、プラグインの設定でAIの機能を切れるかを確かめ、切れなければそのプラグインを使い続けるかどうかも検討します。判断の材料として、送られる情報の種類と、呼ばれる頻度を書き添えておきます。

この一覧の下読みには、生成AIが役に立ちます。プラグインの説明文や更新履歴を読み込ませ、AIに関する記述がある箇所を抜き出させ、根拠の文を添えて示させます。ただし、呼ばせてよいかの判断はAIに決めさせず、情報システムと編集部の責任者が決めるようにします。

対策3：編集者の権限ごとに、AIの機能を開けるかを決める

ワードプレスには、管理者、編集者、投稿者、寄稿者といった権限の区分があります。開発者向けの説明では、管理者以外の利用者からのAIの呼び出しをまとめて止める差し込み口が例として示されています。つまり、権限ごとにAIを使わせるかどうかを分ける手段は用意されているものの、既定で分かれているわけではありません。

オウンドメディアでは、社外のライターに寄稿者の権限を渡していることがよくあります。寄稿者が下書きの画面でAIの機能を使えると、社外の人が会社の鍵でAIを呼び、その費用は会社が払うことになります。社外の人に使わせるかどうか、使わせるなら何の機能までかを、権限の区分ごとに決めておきます。

権限ごとに止める設定は、プラグインの設定や、制作会社による小さな追加の処理で実現することになります。どの方法で止めるかは技術の話ですが、誰に使わせるかを決めるのは運用の話です。編集部が「権限ごとの使ってよい機能」を表にし、情報システムや制作会社がその表のとおりに設定する、という役割の分け方にします。

表の一例を挙げます。管理者は鍵と接続の設定を見るだけでAIの機能は使わない、編集者はタイトルと抜粋の候補づくりまで、投稿者は代替テキストの候補づくりまで、社外のライターが多い寄稿者には使わせない、という分け方です。最初は狭く開けて、使い方が固まってから広げるほうが、あとから閉じるより摩擦が少なくて済みます。

対策4：社外秘の下書きと未公開の情報を送らない線を引く

オウンドメディアの下書きには、公開前の新製品、提携の予定、顧客の事例の未承認の原稿など、社外に出してはいけない情報が含まれることがあります。AIの機能を持つプラグインは、下書きの段階でも本文を送ることがあります。公開前の原稿を送ってよいかは、鍵を発行した契約の条件と、社内の情報の区分で決まります。

線の引き方は、原稿の種類で分けるのが分かりやすい方法です。たとえば、一般的な解説記事の下書きは送ってよい、顧客の名前が出る事例の原稿は顧客の承認が出るまで送らない、発表前の製品情報は送らない、といった形です。この区分を、編集部の執筆の決まりに書き足しておきます。

送らない原稿を守る方法も決めます。ワードプレスの画面の中で、特定の下書きだけAIの機能を止めるのは難しいことが多いため、送らない原稿はワードプレスに入れる前の段階で、別の場所で書き進めるのが現実的です。送ってよい原稿だけがワードプレスの下書きに入る流れにしておけば、プラグインが何を送っても、社外秘は外に出ません。

対策5：費用の上限と、使った量の見方を決める

費用は鍵を発行したAI事業者の側で発生するため、上限も事業者の管理画面で掛けます。ワードプレスの側に使用量の集計の画面が無い以上、使った量を見るのは事業者の管理画面の請求と使用量の欄になります。月に一度、情報システムの担当者がこの欄を見て、編集部に共有する流れを決めておきます。

使った量が急に増えたときに、どのプラグインが原因かを突き止められるようにしておくことも大切です。プラグインごとに別の鍵を発行できれば切り分けは簡単ですが、7.0の仕組みでは鍵がサイト全体で一つになりやすいため、使った量が増えた日と、プラグインを更新した日や入れた日を突き合わせて見当を付けることになります。

このため、プラグインの更新と追加の記録を残しておきます。いつ、どのプラグインを、どの版に上げたか、を一行ずつ書くだけで十分です。費用の増え方とこの記録を並べて見れば、急な増加の原因をたどりやすくなります。

事業者によっては、組織の中を用途ごとの区画に分け、区画ごとに鍵と上限を持てる管理画面を用意している場合があります。そうした仕組みがあれば、ワードプレス専用の区画を作り、他の業務のAIの利用と、サイトからの利用を分けて見るようにします。どんな分け方ができるかは事業者ごとに違うため、鍵を発行する前に管理画面で確かめてください。

他の変更点との兼ね合いも一緒に確かめる

7.0は、AIの土台のほかにも運用に響く変更を含んでいます。まず、サーバーのプログラム言語の最低の版が7.4に上がり、7.2と7.3の環境では6.9に留まり、安全のための更新だけが届く扱いになると案内されています。古いサーバーで動かしているサイトは、AIの取り決めより先に、そもそも7.0に上げられるかを確かめる必要があります。

管理画面の見た目が変わり、キーボードから操作を呼び出せる検索窓が加わったことで、編集部の手順書の画面の写真が古くなります。ブロックを作る仕組みにも変更があり、制作会社が独自に作ったブロックやテーマが影響を受けないかの確認も要ります。これらは、AIの機能を試すのと同じ検証環境でまとめて確かめるのが効率的です。

同時編集は7.0に入らなかったものの、今後の版で入る可能性があります。入れば、複数の人が同じ下書きを同時に触るようになり、AIの機能を持つプラグインの動きとの兼ね合いも変わります。次の大きな版が出るたびに、今回の取り決めを見直す前提で、決まりに見直しの時期を書いておきます。

取り決めが間に合わないときに、更新を急がないという判断もありえます。ワードプレスは直前の版にも当面は安全のための更新を届けるのが通例ですが、期間は公式の案内で確かめる必要があります。反対に、取り決めがそろうまで鍵を入れないまま7.0を使うという進め方もあります。AIの土台は鍵が無ければ動かないため、更新そのものと取り決めを切り離して進められます。

検証環境で確かめる手順

本番のサイトを上げる前に、検証環境で7.0を動かして確かめます。検証環境は、テスト用のサイトが検索に出てしまわないように、認証で閉じておくことが前提です。確かめる順番は次のとおりです。

検証が終わったら、結果を一枚にまとめ、本番の更新の日取りを決めます。本番では、更新を先に行い、鍵は一覧と権限の設定が整ってから最後に入れる順番にします。鍵を入れる日を更新の日と分けておくと、問題が起きたときに、更新のせいかAIのせいかを切り分けやすくなります。

検証の結果には、確かめた日、確かめた版、確かめた人、見つかった問題と対応を書き残します。プラグインが共通の呼び出し口に対応する更新を出したときは、この記録の続きに同じ手順の結果を足していけば、どの時点で何が変わったかを後から追えます。

AIに任せるのは下書きと候補まで、公開の判断は人が持つ

AIの機能を開けたあとの使い方も決めておきます。公式の告知で紹介されているAIプラグインの機能は、タイトルや抜粋の作成、代替テキストの提案、画像の生成や編集です。どれも、人が選んだり直したりする前の候補として使うのが基本です。AIが作ったタイトルや抜粋をそのまま公開せず、編集者が読んで決めます。

代替テキストの提案は、画像の説明を書く手間を減らしますが、画像の中の数字や固有名詞を誤って読むことがあります。記事の要約の下書きも、元の記事にない言い回しや、条件を落とした言い切りが混ざることがあります。AIに作らせたものには、どの段落や画像を元にしたかを書かせ、人が確認する範囲を、公開の手順に書き込んでおくようにします。

記事の事実確認と、公開してよいかの判断は、AIに判断させない領域です。数字の出典、社名や製品名の正しさ、法令や公式の仕様の時点は、編集者が原典に当たって確かめます。AIの機能が増えるほど、公開ボタンを押す人の責任は重くなります。

• 更新と同時に、編集部の管理者が個人の契約の鍵をコネクタの画面に入れる
• プラグインの一覧を作らないまま鍵を入れ、どこから呼ばれているか分からなくなる
• 寄稿者の権限を持つ社外のライターに、会社の鍵でAIを使わせてしまう
• 発表前の製品情報を含む下書きを、AIの機能を持つプラグインの入ったサイトに置く
• AIが作ったタイトルや代替テキストを、編集者が読まずに公開する

更新前の確認項目一覧

ここまでの内容を、更新の前に埋める表にまとめます。決める人の欄は一例です。自社の体制に合わせて書き換えてください。

項目	決めること	決める人の例
更新できるか	サーバーのプログラム言語の版が7.4以上か、独自のブロックやテーマが動くか	情報システム・制作会社
使う事業者	どのAI事業者を使うか。最初は一社に絞るか	情報システム
鍵の置き場所	環境変数か設定ファイルか。管理画面からは入れないか	情報システム
鍵の条件	法人契約か、学習に使わない設定か、上限金額と有効期限	情報システム
呼ばせるプラグイン	プラグインごとに、呼ばせる・呼ばせない・検証してから	情報システム・編集部の責任者
権限ごとの利用	管理者・編集者・投稿者・寄稿者のどこまで使わせるか	編集部の責任者
送らない原稿	事例の未承認の原稿、発表前の情報などの区分	編集部の責任者・法務
費用の見方	誰が月に一度、事業者の管理画面の使用量を見るか	情報システム
検証の手順	検証環境の閉じ方、検証用の鍵、確かめる画面	情報システム・制作会社
見直しの時期	次の大きな版、プラグインの追加や更新のとき	編集部の責任者

• ワードプレスの側で外部のAIとつなぐ別の規格に対応しているかは、公式の告知の範囲では確かめられませんでした
• コネクタの画面を触れる権限の正確な名前は公式の説明に明記がなく、管理者の権限が前提と読めます。自社の環境で確かめてください

まとめ

ワードプレス7.0は、当初の4月9日から延期され、2026年5月20日に公開されました。コアに入ったのは、提供元を選ばないAIの呼び出し口、外部のAI事業者との接続を管理する画面、プラグインが操作を申告する仕組みで、コア自体は利用者向けのAI機能を持ちません。同時編集は公開直前に見送られました。一方で、鍵はサイト全体の設定としてすべてのプラグインが使え、データベースに保存した鍵は暗号化されず、使った量を見る画面もコアにはありません。だからこそ、更新の前に、どの事業者の鍵を誰がどこに入れるか、どのプラグインに呼ばせるか、どの権限まで使わせるか、どの原稿を送らないか、費用の上限をどこで掛けるかを決め、検証環境で確かめてから本番に入れます。AIに任せるのは下書き・要約・代替テキストの候補までで、公開の判断と事実確認は人が持ちます。まずはサイトに入っているプラグインを一覧にし、AIを呼ぶ機能を持つものに印を付けるところから始めてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。