AIが触ったWordPressを出す前に。セキュリティで人が決めること
WordPressのセキュリティ、PHPの古典的な穴、AIを使った攻撃とAIが書いたコードの穴。三つは別ジャンルに見えますが、発注側が止まる場所は同じです。「動いた」「テストが通った」だけでは、出してよいと言い切れない。株式会社ワンオブゼムが主柱にしているのは、誰が引き受けるのかを実装前に決める仕事です。この記事は、AIが触ったWordPress／PHPを本番に出す前に、人が決めておくセキュリティの合格条件だけを扱います。攻撃の手順は書きません。プラグインの設定手順や「WordPressをやめたい」方向の比較も扱いません。
いま起きていること（公開レポートの範囲）
WordPress本体より、第三者プラグイン側の脆弱性報告が増えている、という整理は、セキュリティベンダーの年次レポートで繰り返し出ています。例として Patchstack の State of WordPress Security 2025 は、2024年にエコシステムで見つかった新規脆弱性の大半がプラグイン側であったこと、優先度の高いものも増えていること、そして生成AIが次の四点に効くと書いています。
- AIが書いたコードが、新しい脆弱性を持ち込む
- 脆弱性の発見が速くなる
- 見つかったあと、悪用までの時間が短くなる
- これまで優先度が低かった穴も、悪用しやすくなる
数字の細部はレポート本体を正とします。ここで使うのは、「プラグインと生成コードの品質が、本番判断の中心になる」という構図だけです。
三つを、発注側の言葉に翻訳する
| テーマ | 現場で起きること | 先に決めること（合格条件の一部） |
|---|---|---|
| WordPressのセキュリティ | 本体より、入れたプラグイン・テーマ・mu-plugins の更新遅れと設定ミスで止まる | 本番に載せる拡張の一覧、更新責任者、捨てる拡張の基準 |
| PHPのセキュリティ問題 | 入力の扱い、権限チェック、古い書き方（例: 信頼できない入力のデシリアライズ）が残る | 人が必ず読む場所（外部入力・権限・ファイル操作）と、テストで見る場所の分け方 |
| 近年のAIペネトレーション問題 | 攻撃側も防御側もAIを使う。生成コードの穴の発見と悪用が速くなる、という報告が増えている | 「AIが書いた／直した差分」のレビュー範囲と、出してよいサインの残し方 |
エンジニア向けのチェックリストは、すでに多く出ています。足りないのは、情シスや事業側が「今日、出してよい」と言い切るための合格条件です。
WordPress：拡張の一覧が、最初の合格条件になる
AIでテーマやプラグインの断片を足すと、動く画面は早く出ます。同時に、依存する拡張の数が増え、どれが本番に残っているかが曖昧になります。
実装前に、次を文書にします。
- 本番に載せるプラグイン・テーマ・独自コードの一覧（用途を一文）
- 更新と監視の担当（社内か委託か）
- 使わない拡張を捨てる基準（最終更新からの期間、代替の有無）
- 管理画面とデプロイ権限を持つ人の範囲
一覧が無い状態で「セキュリティ対策をした」と言っても、何に対する対策かが残りません。当社のサイトも WordPress をヘッドレスで使っていますが、公開面に出す前に、どのAPIとどの役割で触るかを先に決めています。個別の製品比較や移行提案は、この記事の範囲外です。
PHP：古典的な穴は、AIが書くほど見えにくくなる
PHPの問題の多くは新しい概念ではありません。入力を信じすぎる、権限を後回しにする、ファイルやシリアライズを雑に扱う。AIは、動くコードを短時間で出します。動くことと、入力境界が正しいことは別です。
発注側が先に決めるのは、次の切り方です。
- 必ず人が読む：外部から来る入力、ログイン・権限、ファイルの読み書き、決済や個人情報に触れる処理
- テストで見る：内部の整形、表示の細部など、合格条件で決めたテストが担保する範囲
- 今は読まない：今日の差分では触らないと明示した場所
この分け方は、AI生成コードのレビュー範囲と同じ型です。セキュリティだけ別の会議にすると、読む場所が二重になり、どちらも浅くなります。
公開されている事例では、WordPressプラグインにおける PHP Object Injection のように、信頼できない入力の扱いが起点になる報告があります。ここでは再現手順は書きません。発注側が取るのは、「外部入力と権限の境界を、実装前の合格条件に含めたか」です。
AIペネトレーション：攻撃が速くなる前提で、サインを残す
近年「AIペネトレーション」と呼ばれる話には、少なくとも二つが混ざります。
| 意味 | 中身 | 発注側の扱い |
|---|---|---|
| 攻撃側のAI利用 | 脆弱性の探索、悪用コードの下書き、フィッシング文面の量産などが速くなる、という報告 | 「見つかってから直す」だけに依存しない。出す前の合格条件を厚くする |
| 生成コード由来の穴 | AIが書いたプラグインやパッチに、権限・入力処理の抜けが残る | AIが触った差分を、レビュー範囲の「必ず読む」に入れる |
どちらも、ツール名の話ではありません。止まるのは「誰が、何を根拠に、出してよいと言ったか」です。合格の物差しと、合格のサインが無いリリースは、セキュリティ会議を開いても判断が残りません。
実装前に決める、セキュリティの合格条件（雛形は出さない）
案件ごとに書き方が違います。ここでは、決まっていないと止まる項目だけを並べます。
- 本番に残す WordPress 拡張の一覧と、捨てる基準
- 外部入力・権限・ファイル操作を「必ず読む」に含めたか
- AIが書いた／直した差分の扱い（必ず読む／テストで見る）
- 個人情報・決済・管理権限に触れる変更の承認者
- 出したあとの更新担当と、緊急停止の連絡先
- 今日のリリースで「出してよい」と言い切った人の記録（対象・根拠・判断）
チェックリストのPDFや、設定画面の手順書は、この記事では出しません。A-2（公開できる雛形の本数）が正典で空のあいだ、手順の本体は案件ごとに書き起こします。
やらないこと（この記事の外）
- 攻撃の再現手順、悪用コード、検証用ペイロード
- 特定ベンダーの「入れれば安心」という断定
- 費用・期間短縮を軸にした WordPress からの乗り換え提案
- 社内の生成AI利用規程（従業員がChatGPTに何を貼ってよいか）との混同。開発案件の線引きとは別です
開発を頼まなくても、合格条件だけを先に切れる
実装を当社が持たない案件でも、拡張一覧の切り方、レビュー範囲、合格のサインの残し方だけをお受けできます。内製や既存のWordPress運用の途中からでも同じです。考え方はAboutに、相談はお問い合わせにあります。
よくある質問
WordPressは危ないから止めた方がよい、という話ですか
いいえ。この記事は乗り換え比較ではありません。AIが触った拡張や独自コードを、誰の責任で出すかを先に決める話です。
PHPのバージョンを上げれば足りますか
バージョンは必要条件になり得ますが、十分条件ではありません。外部入力と権限の境界が合格条件に入っているかが残ります。
AIペネトレーションテストを頼めば足りるのですか
外部の診断は有用です。それでも、出す直前のサイン（誰が、何を根拠に出してよいと言ったか）は発注側に残ります。診断結果を、合格条件のどの項目に対応させるかを先に決めてください。
プラグインを最新にすればセキュリティは終わりですか
更新は必要です。終わりではありません。本番に残す拡張の一覧と、AIが足したコードのレビュー範囲が無いと、更新対象そのものが曖昧なまま残ります。
エンジニア向けの脆弱性診断レポートと同じですか
違います。診断レポートは技術的な所見です。この記事が扱うのは、発注側が本番に出す判断の物差しです。
雛形はもらえますか
この記事では出していません。案件ごとに、止まっている場所から書き起こします。
ヘッドレスWordPressでも同じですか
公開面の作りは違っても、拡張・権限・生成コードの境界は残ります。合格条件の型は同じです。
「テストが通った」をセキュリティの根拠にしてよいですか
いいえ。テストが実装の写し鏡になっていると、通ることと出してよいは一致しません。セキュリティ項目は、人が先に持った合格条件側に置きます。
