WordPress俯瞰講座

AIネイティブ化するWordPress(7.0) ― 道具として使う、任せない

AIネイティブ化するWordPress(7.0) ― 道具として使う、任せない

結論

WordPress 7.0「Armstrong」でAIはコアの一部になった。だからこそ向き合い方は二択ではない。「様子見」でも「丸投げ」でもなく、戻せる作業(可逆)はAIを道具として使い、戻せない作業(不可逆)は自分の手で行う。この一本の線を引けるかどうかが、これからの制作・運営の安全率を決める。AIは賢い助手だが、もっともらしい誤り(ハルシネーション)を出す前提の道具であり、最終判断は常に人間が担保する。

この記事はこんな人へ

  • WordPress 7.0でAIがコアに入ったと聞き、何が変わったのか整理したい人
  • AIを業務に取り入れたいが、どこまで任せていいか線引きできずにいる人
  • 逆に「AIに任せすぎ」が怖くて、つい全部様子見にしている人
  • ログ解析やトラブル対応にAIを使いたい中級〜上級の制作者・運営者
  • 顧客サイトを預かる立場で、AI利用の判断基準を社内で共有したい人

よくある認識(近視眼モデル)

  • 「AIはまだ様子見。枯れてから使えばいい」→ コアに入った機能を放置すると、運用全体の効率で差がつく
  • 「AIに任せれば作業が全部速くなる」→ 速くなるのは一部。不可逆な作業を任せると取り返しがつかない
  • 「7.0にしたら勝手にAIが動き出すのでは」→ 接続(Connectors)を設定しない限り外部AIは動かない。主導権は運営者側にある
  • 「AIの出力は正しいはず」→ ハルシネーションは仕様。検証なしの採用は事故のもと
  • 「機密情報もAIに渡して大丈夫だろう」→ ここが最大の落とし穴。渡す情報の中身を選ぶ意識が要る

俯瞰で見る:WordPress 7.0で何が変わったか

  • WordPress 7.0「Armstrong」が2026年5月20日にリリース。AIをWordPress全体に取り込む起点と位置づけられている。
  • AIクライアント(AI Client)がコアに搭載。プラグインやテーマが各社のAIモデルを共通の枠組み経由で利用できる。
  • 接続は「設定 > 連携(Connectors)」画面で一元管理。Anthropic・Google・OpenAI など複数のAIサービスへの接続を中央で認証・管理できる。
  • AIはあくまで「能力」を呼び出す土台。タイトル生成・抜粋作成・代替テキスト提案などはAI連携プラグインで拡張される。
  • 重要な前提として、AIはハルシネーション(もっともらしい誤り)を出すものであり、出力は人が検証することが運用の大原則。

出典:WordPress News「WordPress 7.0 Armstrong」

設定>連携からAIクライアント(コア内蔵)を介してAnthropic・Google・OpenAI等に接続
図の読み方:AIは外付け機能ではなく、7.0でプラットフォームの前提になりました。

道具として使う/任せてはいけない

AIをコアで使えるようになった今こそ、作業ごとに役割を切り分ける。判断の核は「失敗したとき元に戻せるか」だ。

作業AIの使い方判断
debug.log・エラーログの読解要約・原因候補の列挙を依頼し、切り分けの初動に使う使ってよい(必ず人が裏取り)
文章・抜粋・タイトルの下書きたたき台を生成し、人が事実と表現を確認して仕上げる使ってよい(検証必須)
コードの修正案・リファクタ提案案を出させ、ステージングで動作確認してから採用使ってよい(検証・テスト必須)
設定値・関数の調べもの調査の取っかかりに。公式ドキュメントで最終確認使ってよい(一次情報で裏取り)
データベースの直接操作(SQL実行)任せない。シリアライズデータ破損のリスク任せない
本番環境のファイル削除・上書き任せない。取り返しがつかない任せない
無検証の改ざん・マルウェア復旧任せない。被害範囲の誤判断は二次被害に任せない

線引きの基準はシンプルだ。戻せる作業はAIを道具として使い、戻せない作業はAIに最終操作をさせない。

具体シナリオ① DB操作を丸投げしてシリアライズデータが壊れた(不可逆の失敗)

何をした:サイトURL変更にともなう一括置換を、AIに「データベースを直接書き換える手順」ごと任せ、生成されたSQLを本番でそのまま実行した。

結果:WordPressはウィジェット設定やプラグインのオプションを「シリアライズ化された文字列」として保存している。文字数情報を含む形式のため、単純な文字列置換を行うと長さの整合が崩れ、データが読めなくなる。表示崩れと設定喪失が複数箇所で発生し、バックアップがなければ復旧困難な状態に陥った。

俯瞰の教訓:DBの直接書き換えは典型的な「不可逆」作業だ。シリアライズを正しく扱うには専用ツール(WP-CLIの search-replace など)が要る。AIに手順を聞くのは可だが、本番での実行は人がバックアップを取った上で行う。

具体シナリオ② 大量のログをAIに要約させ、原因切り分けの初動を短縮(可逆・適切な活用)

何をした:表示が断続的に重くなる不具合で、数万行のdebug.logとサーバーのエラーログをAIに渡し(機密は除去)、「繰り返し出ているエラーの種類と発生時刻の傾向」を要約させた。

結果:特定プラグインのDeprecated警告とメモリ関連の警告が同時刻帯に集中していることが浮かび上がり、人の目で全行を追うより早く「当たり」を付けられた。最終的な原因特定と修正は、AIが示した候補を人が一次情報で確認しながら進めた。

俯瞰の教訓:ログの要約は読んでも何も壊れない可逆な作業であり、AIの得意分野だ。ただし要約は「仮説の入口」にすぎず、結論ではない。可逆な領域で初動を速め、判断は人が持つ。

AIに任せる/任せないの線引き(可逆/不可逆)
図の読み方:左(可逆)は道具として使ってよい領域、右(不可逆)はAIに任せてはいけない領域です。

判断軸チェック:その作業、AIに任せていい?

  • 戻せる(可逆)作業か? → 読む・要約する・下書きする・調べる、なら道具として使ってOK。ただし出力は検証する
  • 戻せない(不可逆)作業か? → 消す・上書きする・DBを直接書き換える、なら自分の手で。実行前に必ずバックアップ
  • 検証を自分で担保できるか? → 出力の正否を自分で判断できないなら、その作業はまだAIに任せる段階ではない
  • 渡す情報に機密・個人情報が含まれていないか? → 含むなら、除去・マスキングしてからにする
判断フロー:その操作が可逆なら道具として使う、不可逆なら人が手を動かす
図の読み方:分かれ目は「戻せるかどうか」。不可逆ならAIに任せないのが鉄則です。

では、どう向き合うか(3つの判断軸)

  1. 可逆か不可逆か、で線を引く:戻せる作業はAIを積極的に使う。戻せない作業(DB直接操作、本番の削除・上書き、改ざん復旧)はAIに最終操作をさせず、バックアップを取った上で人が行う。迷ったら不可逆側に倒して扱う。
  2. 人が検証を担保できるかを確認する:AIはハルシネーションを出す前提の道具。出力の正否を自分で判断できる作業に限って任せる。AIは答えではなく仮説を出す相手だと捉える。
  3. AIに渡す情報に機密・個人情報を含めない:ログやコードにはAPIキー、DB接続情報、顧客の個人情報、認証トークンが紛れ込むことがある。外部AIに渡す前に除去・マスキングする。接続するサービスの利用規約とデータの取り扱いも事前に確認する。

次に読む・関連記事

まとめ

WordPress 7.0でAIはコアの道具になった。だが道具が強力になるほど、使い手の線引きが結果を分ける。様子見も丸投げも、判断を放棄している点では同じだ。可逆な作業はAIで速め、不可逆な作業は人が手綱を握る。検証を担保し、機密は渡さない。任せるのではなく、使う。主導権は、これからも人間の側にある。

参考にした公式情報

情報確認日:2026年5月29日