つくれる外部CAIO
結論：「更新しておけば大丈夫」の前提が、2026年に崩れました
先に結論です。
- 攻撃する側がAIで速くなった。 脆弱性が公開されてから悪用されるまでの時間は、中央値で約5時間と報告されています。「週1回まとめて更新」では間に合いません。
- WordPress本体にAIが入った。 2026年5月のWordPress 7.0で、AIプロバイダーとの接続やAIエージェントからの操作の仕組みが本体に入りました。便利になったぶん、APIキーと権限という新しい管理対象が増えています。
- 自分たちもAIでコードを書くようになった。 ChatGPTやClaudeが書いたスニペットやプラグインを、そのまま本番に入れていませんか。
なので、2026年10月時点で見るべきは「更新しているか」だけではありません。「更新が間に合わない前提で守れているか」「AIに渡した権限を把握しているか」の2点が加わりました。
この記事では、中小企業でWordPressサイトを持っている社長・担当者向けに、確認ポイントを10個に絞って整理します。
まず今日やること（5分）
10項目を読む前に、管理画面を開いて次の3つだけ確認してください。
- ダッシュボード → 更新 で、WordPress本体のバージョンを確認する（2026年10月13日時点の最新は 7.1.3）
- プラグイン一覧 で「更新があります」の表示が残っていないか、停止中のまま放置しているプラグインがないかを見る
- ユーザー一覧 で、権限が「管理者」になっている人数を数える（退職者・元制作会社のアカウントが残っていないか）
1つでも引っかかったら、この記事の該当項目から手をつけてください。
あなたのサイトはどのタイプ？（優先順位の分岐）
10項目すべてを一度にやる必要はありません。状況によって優先順位が変わります。
| あなたの状況 | 最優先で見る項目 | 理由 |
|---|---|---|
| A. 制作会社に作ってもらい、その後はほぼ触っていない | ①②⑤⑩ | 「誰が更新しているのか」が曖昧なサイトが一番危ない |
| B. 社内の担当者が更新・運用している | ①②③④⑨ | 更新の速度と、更新が間に合わないときの備えが論点 |
| C. AI機能・AIエージェント連携を使い始めた／AIでコードを書いている | ⑥⑦⑧＋上記 | 新しく増えた攻撃面を把握できているかが論点 |
2026年に何が起きたか（背景を1分で）
確認項目の前に、なぜ「AI時代」と言うのかを時系列で押さえておきます。
| 時期 | 出来事 |
|---|---|
| 2026年1月 | IPA「情報セキュリティ10大脅威 2026」組織編で、「AIの利用をめぐるサイバーリスク」が初選出で3位 |
| 2026年5月20日 | WordPress 7.0リリース。AIクライアント、Abilities API、AIプロバイダー接続画面（Connectors）が本体に入る |
| 2026年7月17日 | WordPress 7.0.2。認証なしで遠隔からコード実行できる脆弱性の組み合わせ（通称「wp2shell」）を修正。発見にはAIモデルが使われたと報告されている |
| 2026年7月21〜22日 | 米CISAが「悪用が確認された脆弱性」に登録。IPAも緊急の注意喚起を公開 |
| 2026年8月6日 | WordPress 7.0.3で12件の脆弱性を修正。AI系のセキュリティ企業からの報告が目立つ |
| 2026年9月22日 | WordPress 7.1.2。特定のテーマ・サーバー条件で遠隔コード実行につながる重大な脆弱性（CVE-2026-87902）を修正。4.7系まで遡って修正版を配布 |
| 2026年10月6日 | WordPress 7.1.3（保守・セキュリティリリース） |
もう一つの数字として、セキュリティ企業Patchstackの2026年版レポートでは、2025年に報告されたWordPress関連の脆弱性は1万1,334件（前年比42%増）、そのうち91%がプラグイン、46%は公開時点で修正版がなかったとされています。
ポイントは、「見つける速度」はAIで上がったのに、「直す速度」は人手のままだということです。プラグインの多くは個人や少人数が無償で保守しているため、修正が追いつかないケースが増えています。
確認ポイント10選
① WordPress本体：自動更新が「本当に効いているか」を目で確認する
確認すること
- 管理画面で現在のバージョンを確認する（7.1系なら7.1.3以上）
- 7.1に上げられない事情がある場合も、自分が使っているブランチの最新セキュリティリリースになっているか
- 自動更新を有効にしているなら、「有効になっている」ではなく「実際に上がっている」かを見る
なぜ今これが重要か
wp2shellのときWordPress.orgは強制の自動更新を行いましたが、IPAの注意喚起では「環境によっては更新されていない、または失敗している可能性がある」として、管理画面での目視確認と手動更新を求めています。自動更新は「保険」であって「確認の代わり」ではありません。
よくある落とし穴
サーバーのPHPが古いと、そもそもWordPress 7系の更新が提示されません（7系の最低要件はPHP 7.4、推奨は8.3以上）。この場合、サイトは6.9系に取り残されたまま、気づかれないことがあります。→ ⑨も確認してください。
② プラグイン：「数を減らす」が最強の対策
確認すること
- 停止中のプラグインは削除する（停止しているだけではファイルはサーバーに残ります）
- 最終更新が1年以上前のプラグイン、WordPress.orgで配布停止になっているプラグインを洗い出す
- 「同じ機能を2つ入れている」「誰が何のために入れたかわからない」ものを整理する
なぜ今これが重要か
脆弱性の大半はプラグインです。そして約半数は、公開された時点でまだ修正版がありません。つまり更新では防げない時間帯があるということです。プラグインが10個あれば10個分、その時間帯を抱えます。
使っていないプラグインを消すのは、コストゼロで攻撃面を減らせる唯一の対策です。
③ 「更新が間に合わない5時間」をWAFで埋める
確認すること
- サイトの前にWAF（Webアプリケーションファイアウォール）が入っているか
- レンタルサーバー付属のWAF（エックスサーバー等）が有効になっているか
- Cloudflare等のCDN経由ならWAFルールが有効か
- 脆弱性の公開から修正までを「仮想パッチ」で塞ぐサービスを使うかどうか検討したか
なぜ今これが重要か
公開から悪用まで約5時間。人が気づいて、検証して、更新するには短すぎます。WAFは「更新するまでの時間を稼ぐ」役割です。
実際、wp2shellではWizが「すぐに更新できない場合は、WAFで該当のエンドポイントをブロックする」ことを暫定策として挙げていました。
正直な注意点
WAFは万能ではありません。Patchstackは、脆弱性を突く攻撃の多くがホスティング側の一般的な防御をすり抜けていると指摘しています。WAFは「更新の代わり」ではなく、「更新までの時間稼ぎ」として位置づけてください。
④ 外から見える入口（REST API・ログイン画面）を絞る
確認すること
/wp-json/wp/v2/usersにブラウザでアクセスして、ユーザー名（ログインID）が丸見えになっていないか- 使っていないなら
xmlrpc.phpを無効化しているか - ログイン画面（
/wp-login.php）にログイン試行回数の制限、またはIP制限・追加認証がかかっているか
なぜ今これが重要か
wp2shellの攻撃では、侵入後に管理者ユーザーの列挙（REST API経由）や、設定ファイル（wp-config.php）の読み取りが試みられたと報告されています。入口の情報が見えているほど、攻撃の自動化はしやすくなります。
REST APIはブロックエディタやAI連携でも使われるため、全部止めるのではなく「匿名で見えなくてよいものを隠す」のが現実的です。
⑤ 管理者アカウント：人数・二要素認証・「元関係者」
確認すること
- 「管理者」権限の人数は必要最小限か（記事を書くだけの人は「編集者」「投稿者」で足ります）
- 退職者、契約が終わった制作会社・外注先のアカウントが残っていないか
- 管理者全員に二要素認証（またはパスキー）がかかっているか
- 共有アカウント（
adminを複数人で使い回し）になっていないか
なぜ今これが重要か
AIで作られたフィッシングメールは、日本語の不自然さで見抜くことがほぼできなくなりました。IPAの10大脅威でも「ビジネスメール詐欺」が10位に入っています。パスワードを盗まれる前提で、盗まれても入れない仕組み（二要素認証）と、入られても被害が小さい権限設計の両方が必要です。
⑥ 【AI機能】AIプロバイダーのAPIキー：上限・通知・使い分け
ここからの3項目は、WordPress 7.0以降でAI機能を使っている、またはAI系プラグインを入れているサイト向けです。
確認すること
- OpenAI・Anthropic・Google等のAPIキーを、どこに・いくつ登録しているか把握しているか
- AIプロバイダー側の管理画面で、月の利用上限（ハードリミット）を設定しているか
- 上限の50%・80%で通知が来るようにしているか
- サイトごと・用途ごとにキーを分けているか（1本のキーを全社で使い回していないか）
なぜ今これが重要か
WordPress 7.0では、管理者が一度AIプロバイダーと接続すると、その接続を使う各プラグインがサイト全体の接続を共有する設計になっています。指摘されている注意点は次のとおりです。
- 本体側に「プラグインごとの予算上限」や「利用回数の制限」はない
- AI呼び出しはサイト内部の正常な処理に見えるため、WAFやマルウェアスキャンで検知しにくい
- 少しずつ不正に使われると、請求書が来るまで気づかない
盗まれたAPIキーは、そのまま「他人のお金で使えるAI」です。攻撃者にとって換金性の高い資産になっています。
今すぐできること：AIプロバイダー側で上限と通知を設定する。これが最も効果の大きい対策です。使用量に心当たりのない増加があれば、キーを再発行（ローテーション）してください。
⑦ 【AI機能】AIエージェントにどこまで「書き込み」を許しているか
確認すること
- Abilities API（サイトの機能をAIから呼び出せる形で登録する仕組み）に、どのプラグインが何を登録しているか
- MCP（AIエージェントとサイトをつなぐ仕組み）経由で、Claude Code・Cursor・Codex等のAIツールからサイトを操作させているか
- 操作させている場合、AI専用のユーザーを作り、必要最小限の権限にしているか
- AI用に発行した「アプリケーションパスワード」を一覧で把握し、使っていないものを失効させているか
なぜ今これが重要か
WordPress 7.0以降、AIエージェントがサイトを「読む」だけでなく「書く（投稿・更新・設定変更）」ことが公式に可能になりました。開発者コミュニティでも、AIの書き込み権限については懸念の声が出ています。
考え方はシンプルで、AIエージェントは「新しく入った外部スタッフ」と同じ扱いにすることです。いきなり管理者権限は渡さない。何ができるかを決めてから渡す。終わったら権限を外す。
判断の分岐
- 下書き作成・誤字チェック程度 → 「投稿者」相当の権限で足りる
- 公開・更新まで任せたい → まずステージング（検証用サイト）で試し、本番は人が最終確認する運用にする
- プラグインの追加・設定変更まで任せたい → 中小企業では現時点では推奨しません
⑧ 【AI機能】AIが書いたコードを、そのまま本番に入れていないか
確認すること
- ChatGPTやClaudeに書かせたコードを
functions.phpやコードスニペット系プラグインに貼り付けていないか - AIで作った自作プラグインがある場合、公開前に次の3点を確認したか
- 出力するデータをエスケープしているか（
esc_html()等） - フォーム送信にnonce（不正リクエスト防止のトークン）のチェックがあるか
- 実行前にユーザー権限のチェック（
current_user_can()）があるか - AIの出力（チャットボットの回答等）をそのままページに表示していないか
なぜ今これが重要か
AIはそれらしく動くコードを速く書いてくれますが、上の3点のような「動作には関係ないが安全には必須の処理」を省きがちです。あるプラグイン開発者は、AIで作った自作プラグインを公開前に点検したところ35件の不具合（うち重大3件）が見つかったと書いています。
もう一つ見落としやすいのが、AIの回答そのものも「外から来た信用できないデータ」として扱うことです。AIの出力をエスケープせずに表示すると、そこから不正なスクリプトが埋め込まれる可能性があります。
現実的な落としどころ
コードを書けない担当者に「レビューしろ」と言っても無理があります。最低限、「AIが書いたコードは、本番に入れる前に別のAIにセキュリティ観点でレビューさせ、指摘が出たら人間（または外部）に確認する」という2段構えにしてください。AIに書かせること自体は問題ではありません。書かせっぱなしが問題です。
⑨ サーバー・テーマ・バックアップ：「戻せるか」まで確認する
確認すること
- サーバーのPHPバージョン（8.3以上推奨）
wp-config.phpにdefine('DISALLOW_FILE_EDIT', true);を入れて、管理画面からのテーマ・プラグイン編集を無効にしているか- 使っていないテーマを削除しているか
- バックアップを取っているだけでなく、実際に復元できることを一度試したか
なぜ今これが重要か
9月に修正されたCVE-2026-87902は、「特定のテーマ構成」×「特定のサーバー設定」が重なったときに遠隔コード実行につながるものでした。WordPress本体だけでなく、テーマやサーバー設定も攻撃の条件になります。
また、侵入されたサイトでは不正なプラグインやWebシェル（遠隔操作用の裏口）が設置された事例が報告されています。ここまで来ると「掃除」より「きれいな状態から戻す」ほうが確実です。そのとき、戻せないバックアップは無いのと同じです。
⑩ 「誰が見るのか」を決める：委託先との責任分界と点検サイクル
確認すること
- WordPressの更新・点検の担当者が名前で決まっているか
- 制作会社・保守会社と契約している場合、「どこまでが先方の責任か」が契約書に書かれているか
- 本体の更新は？ プラグインは？ 緊急の脆弱性が出たときの対応時間は？
- 月1回など、定期点検の日が決まっているか
- AI機能を追加するとき、誰の承認で入れるかが決まっているか
なぜ今これが重要か
IPAの10大脅威 2026（組織編）では、「サプライチェーンや委託先を狙った攻撃」が2位です。そして中小企業のWordPressで一番多い問題は、技術ではなく「誰も見ていない」ことです。
「制作会社がやってくれていると思っていた」「契約は制作までで、保守は含まれていなかった」は、被害が出てから判明する典型パターンです。
NIST（米国立標準技術研究所）のサイバーセキュリティフレームワーク2.0でも、2024年の改訂で「統治（Govern）」、つまり役割・責任・方針を決めることが新たな柱として加わりました。技術的な対策は、誰かが継続して見る前提があって初めて機能します。
点検サイクルの目安
| 頻度 | やること |
|---|---|
| 毎日（自動） | 自動更新・WAF・バックアップが動いていること |
| 重大な脆弱性の報道時（即日） | バージョン確認、必要なら手動更新 |
| 月1回 | ①〜⑤の確認、AIのAPI利用額の確認（⑥） |
| 四半期に1回 | プラグイン・アカウントの棚卸し（②⑤）、AI権限の見直し（⑦）、バックアップ復元テスト（⑨） |
10項目のまとめ（チェックリスト）
| # | 確認ポイント | 一言で | 優先タイプ |
|---|---|---|---|
| ① | WordPress本体 | 自動更新を「目で」確認 | A・B・C |
| ② | プラグイン | 消せるものは消す | A・B・C |
| ③ | WAF | 更新までの時間を稼ぐ | B |
| ④ | 外から見える入口 | ユーザー名・ログイン画面を隠す | B |
| ⑤ | 管理者アカウント | 人数・二要素認証・元関係者 | A・B |
| ⑥ | AIのAPIキー | 上限と通知を設定 | C |
| ⑦ | AIエージェントの権限 | 「新しい外部スタッフ」扱い | C |
| ⑧ | AIが書いたコード | 書かせっぱなしにしない | C |
| ⑨ | サーバー・テーマ・バックアップ | 「戻せるか」まで確認 | B |
| ⑩ | 責任分界と点検サイクル | 誰が見るかを名前で決める | A・B・C |
この記事の限界について
正直に書いておきます。
- この記事は2026年10月13日時点の情報です。WordPressは数週間単位でセキュリティリリースが出ています。バージョン番号は必ず公式サイトで最新を確認してください。
- 10項目はすべての対策を網羅したものではありません。ECサイトや会員サイトなど個人情報を多く扱うサイトは、専門のセキュリティ診断を受けることをおすすめします。
- 数値の一部はセキュリティ企業のレポートや報道によるもので、集計方法によって変わります。
当社グループも複数のWordPressサイトを運用しており、この記事の項目は自社でも点検しているものです。
よくある質問
Q. 小さな会社のコーポレートサイトでも狙われますか？
狙われます。攻撃の大半は特定の会社を狙ったものではなく、脆弱なバージョンやプラグインを自動で探して片っ端から攻撃するものです。会社の規模やアクセス数は関係ありません。
Q. 自動更新をオンにしていれば十分ですか？
十分ではありません。自動更新が失敗しているケースがあること、脆弱性の約半数は公開時点で修正版がないこと、の2つの理由からです。自動更新に加えて、管理画面での目視確認（①）とWAF（③）を組み合わせてください。
Q. WordPress 7系のAI機能は使わないほうが安全ですか？
使わないのが一番安全なのは事実ですが、それでは業務効率化の機会も失います。使うなら、APIキーの利用上限（⑥）とAIエージェントの権限（⑦）を先に決めてから有効にしてください。「決めてから使う」が原則です。
Q. AIでプラグインやコードを作るのはやめたほうがいいですか？
やめる必要はありません。問題は「AIが書いたこと」ではなく「誰も確認せずに本番に入れること」です。⑧の3点（エスケープ・nonce・権限チェック）を確認する仕組みを作ってください。
Q. 制作会社に任せているので、自社でやることはありますか？
あります。契約書で「保守の範囲」と「緊急時の対応時間」を確認すること（⑩）と、管理者アカウントの棚卸し（⑤）は、委託していても自社で把握しておくべき項目です。
社内に「判断できる人」がいない場合は
ここまで読んで、「項目はわかったけど、うちでは誰が判断するのか」と思った方も多いと思います。それ自体が、⑩で書いた一番大きなリスクです。
株式会社JPWでは、中小企業の社長の隣で、AI導入とその周辺のIT判断を一緒に行う外部CAIO（AI責任者）サービスを提供しています。WordPressのAI機能を入れるかどうか、AIエージェントにどこまで任せるか、といった「技術と経営の間の判断」もご相談の範囲です。
詳しくはこちら：外部CAIOとは？ 中小企業が「AIの責任者」を社外に置くという選択肢
参考資料
- IPA「WordPressの脆弱性対策について（CVE-2026-60137、CVE-2026-63030）」2026年7月22日 https://www.ipa.go.jp/security/security-alert/2026/alert20260722.html
- IPA「情報セキュリティ10大脅威 2026」 https://www.ipa.go.jp/security/10threats/10threats2026.html
- WordPress.org News - Releases https://wordpress.org/news/category/releases/
- Wiz「Exploitation in the Wild of wp2shell」 https://www.wiz.io/blog/wp2shell-cve-2026-63030-cve-2026-60137
- Patchstack「State of WordPress Security in 2026」 https://patchstack.com/whitepaper/state-of-wordpress-security-in-2026/
- Patchstack「WordPress 7.0.3 Released: 12 Vulnerabilities Found and Fixed」 https://patchstack.com/articles/wordpress-7-0-3-released-12-vulnerabilities-found-and-fixed/
- Cyber Security Agency of Singapore「Active Exploitation of High-Severity Vulnerability in WordPress」(AL-2026-128) https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-128/
- NIST「Cybersecurity Framework (CSF) 2.0」 https://www.nist.gov/cyberframework