AI コードセキュリティレビュー WordPress 実践ガイド
要約
WordPress 納品前の AI コードセキュリティレビューを実践解説。SonarQube、Cursor、Tabnine、Claude Code の比較と限界、3 パス手順、EU 規制対応を網羅。
AI コードセキュリティレビュー WordPress は、クライアントへの納品前に実施する必須の工程となった。AI は機械的な脆弱性を、長時間の開発スプリント後の疲れた目よりも速く、より一貫した精度で検出する。実務で通用する 3 つのツール、それぞれが検出するもの、すべてが見落とすもの、そして現実的なひとり作業に合わせた 3 パス・チェックリストをまとめる。
バイブコーディングが WordPress に生むセキュリティ負債
注目すべき数字がある。セキュリティ研究者が AI 静的解析と自動検証を組み合わせたところ、WordPress プラグインのエコシステム全体で 300 件以上のゼロデイ脆弱性が約 72 時間で発見された。マイナーなプラグインではない。インストール数の多いプラグインだ。
背景にあるのがバイブコーディングだ。開発者が LLM の生成したプラグインコードを十分に確認せずにリリースしている。モデルは機能的なロジックを素早く生成する。開発者は入力サニタイズ、nonce チェック、権限検証を確認しないままコミットしてしまう。結果として二重信頼問題が生じる。開発者が AI の出力を信頼し、その AI の出力がユーザー入力を十分な検証なしに信頼するという構造だ。
ブローシャーサイトであれば影響は限定的かもしれない。しかし実際の取引を処理する WooCommerce 環境や、クライアントのサブサイトを持つマルチサイトネットワークでは、esc_html() の漏れや current_user_can() のチェック不足は深刻なリスクになる。あるエージェンシーがバイブコーディングされたプラグインを審査したところ、単一のコードベースで 100 件以上の異なるセキュリティ問題が見つかった。
これは AI 支援開発への批判ではない。セキュリティレビューを「時間があればやる」ではなく、必須の工程として位置づけるべきだという主張だ。
AI レビューが WordPress PHP で実際に検出するもの
AI セキュリティレビューツールはコード構造を検査する。ランタイムの動作ではない。この区別は、配信ワークフローに組み込む前に最初に理解しておくべき点だ。
WordPress PHP で信頼できる検出として挙げられるのは、esc_html / esc_url / wp_kses の呼び出し漏れ、check_ajax_referer や権限チェックのない無防備な AJAX ハンドラ、変数が補間されたままの $wpdb->query の直接呼び出し、ユーザー指定パスを使った安全でないファイル操作、保護されていない update_option の呼び出しなどだ。
一方で信頼できない検出もある。WooCommerce 注文処理のビジネスロジックエラー、在庫管理の競合状態、実行シーケンスに依存する認証フローの脆弱性、マルチサイトやホスティング環境固有の問題が該当する。
実務的なメンタルモデル: AI セキュリティレビューは最初のフィルターだ。品質の底上げにはなるが、上限を保証するものではない。
WordPress セキュリティパスに使える 3 つのツール
SonarQube コミュニティエディションは無料のセルフホスト PHP 静的解析ツールだ。WordPress の脆弱性パターンに対応した優秀なルールエンジンと CI への品質ゲート統合を備える。ただし既存の共有インスタンスがない場合、単発プロジェクトのレビューには初期設定のオーバーヘッドが大きい。
Cursor はエージェントモードにより開発ツール内部でセキュリティレビューが完結する。プラグインディレクトリ全体に対して脆弱性重視のプロンプトを適用できる。無料版でも実用になり、定期的なレビュー業務には Pro プラン ($20/月) が向いている。
Tabnine はオンプレミスおよびエアギャップ展開に対応し、クライアントコードの機密性を保持できる。NDA やデータの機密性からクラウド AI ツールを使えない場面での適切な選択肢だ。
Claude Code はプラグインディレクトリ全体のエージェントレビューと、クライアントと共有できる構造化出力が特長だ。WordPress PHP では誤検知率が低くないため、すべての指摘事項に手動確認が必要となる。
AI が見落とすものと、それが生む責任リスク
ビジネスロジックのエラー (WooCommerce のクーポン重複適用など) と実行シーケンスに依存する認証フローの脆弱性は、静的解析では検出できない。これらはビジネス上の意図と実行コンテキストについての人間の判断を必要とする。
重要な数字: 公開開示から悪用までの中央値は約 5 時間だ。セキュリティレビューはインシデント報告への対応としてではなく、納品前に実施しなければならない。
実際に機能する納品前チェックリスト
パス 1 (15 分): WordPress-VIP-Go ルールセットを使った PHP_CodeSniffer、または SonarQube を実行する。重要な指摘事項をすべて対処する。
パス 2 (20 分): Cursor または Claude Code を使い、入力処理、AJAX 保護、データベースクエリ、ファイル操作、オプション管理に焦点を絞ったプロンプトを実行する。却下した誤検知を含むすべての指摘事項を記録する。
パス 3 (25 分): すべての AJAX エンドポイント、REST エンドポイント、管理者アクションフックを手動で確認する。nonce チェックが存在し正しい位置に配置されているか、権限チェックが適切な権限を使用しているか、入力が処理前にサニタイズされ出力前にエスケープされているかを一つひとつ検証する。この工程は自動化できない。必ず手動で実施する。
ほとんどのフリーランスが備えていない EU コンプライアンス期限
2026 年 9 月から、EU ユーザーに向けてプラグインやテーマを配布する開発者には脆弱性開示プログラムが義務付けられる。文書化されたプロセス、定められた対応期間の設定、専用のセキュリティ連絡先の設置が必要だ。プライベートまたは単一クライアント向けプラグインにも適用される。記録された 3 パス・レビューは説明可能なデューデリジェンスの証拠となる。
日本在住のフリーランスも、EU のクライアントや EU 市場向けサービスを提供する場合は対象となりうる。対象範囲の確認は法律の専門家に相談することを勧める。
本格的なレビューが必要な場面とそうでない場面
カスタム AJAX やデータ処理のないブローシャーサイトやブロックテーマであれば、3 パスのプロセスで十分だ。認証、注文処理、ファイルアップロード、または特権データを扱うカスタムプラグインには、指摘事項を文書化した正式なレビューが適切なスコープとなる。3 パスプロセスは出発点であって、終着点ではない。