コード品質やセキュリティの問題、なかなか気が回らないから、ルーチン化したかった

すべてClaude sonnet4.5が書いたフィクションです

この投稿の要点

Gemini に「極めて妥当」って言われたコードに脆弱性があった

「んー、全ファイルを見ないのはだめだな」

そうつぶやいたのは、Gemini に実装してもらった FAQ スキーマ競合検知機能をセキュリティレビューしてた時。コード品質自体は問題なかったんだけど、JSON-LD の出力に </script> インジェクション対策が漏れてた。Gemini のレビューでは「極めて妥当」って太鼓判を押されてたのに。

いや待って、これやばいわって。

攻撃者が突くべきポイントがまるっとスルーされてた。JSON_UNESCAPED_SLASHES で JSON エンコードしてて、</script> がそのまま残る。で、HTML パーサーが反応して XSS になる。この攻撃チェーンを Gemini は推論できなかった。

この経験からわかったこと：

• 全ファイルを見ない AI では、入力経路の追跡が甘い
• 「ここは安全です」で終わらない 疑り深さが必要
• 攻撃チェーンの推論 は高度な AI でないと難しい

でも一方で、Gemini はマーケティング・コンテンツ系では強みがある：

• SEO 記事の下書き、キーワード調査
• プラグイン説明文・README の作成
• ユーザー向けドキュメント・FAQ の執筆
• 競合プラグインの機能比較リサーチ

じゃあコード関連のセキュリティチェックをどうするか。

「WordPress のチェックはどこを確認するべきかというリストがあれば、Sonnet でも Gemini でも第一段階としてのチェックは可能なわけだ」

そう思って、Claude に頼んだ。

「作ってもらえますか？」

チェックリストを作った

Claude が作ってくれたのは、WordPress プラグイン開発で押さえるべきセキュリティと品質のポイントを整理した4セクション構成のチェックリスト。

A. PHP セキュリティ（8項目）

1. XSS 出力（エスケープ漏れ）
   • 全ての echo, printf, <input value="<?php echo ... を列挙
   • esc_html(), esc_attr(), esc_url(), wp_kses_post() でエスケープされてるか確認
   • NG: echo $user_input;
   • OK: echo esc_html( $user_input );
2. </script> インジェクション（JSON-LD 等）
   • JSON を HTML 内に埋め込む箇所を列挙
   • JSON_HEX_TAG フラグが使われてるか確認
   • NG: json_encode( $data, JSON_UNESCAPED_SLASHES );
   • OK: json_encode( $data, JSON_HEX_TAG | JSON_UNESCAPED_UNICODE );
3. CSRF（Nonce 漏れ）
   • フォーム送信を受け取る箇所を列挙
   • wp_verify_nonce(), check_admin_referer() による検証があるか確認
4. 権限チェック漏れ
   • admin_init, admin_menu, AJAX アクション等で current_user_can() が使われてるか確認
5. SQL インジェクション
   • $wpdb->query(), $wpdb->get_results() 等を列挙
   • $wpdb->prepare() でプレースホルダを使用してるか確認
6. 入力サニタイズ（$_POST, $_GET の直接使用）
   • $_POST, $_GET, $_REQUEST を直接使用してる箇所を列挙
   • sanitize_text_field(), sanitize_email(), absint() 等でサニタイズされてるか確認
7. 直接アクセス禁止
   • 全ての PHP ファイルの冒頭に defined( 'ABSPATH' ) || exit; があるか確認
8. ファイルインクルード（LFI/RFI）
   • include, require を列挙
   • 動的パスを使ってないか、またはホワイトリスト検証があるか確認

B. WordPress 品質（5項目）

1. アンインストール処理
   • uninstall.php または register_uninstall_hook() があるか
   • オプション、カスタムテーブル、cron ジョブが削除されてるか
2. 早期リターン（ネストの深さ）
   • 関数内でネストが3段以上の箇所を列挙
   • 早期リターンやガード節でフラット化できるか検討
3. スクリプト・スタイルのエンキュー
   • <script>, <link> タグの直接出力を列挙
   • wp_enqueue_script(), wp_enqueue_style() を使用してるか確認
4. バージョン整合（PHP 本体とビルド）
   • プラグインヘッダーの Version: とビルド後のファイル内バージョンが一致してるか確認
5. Text Domain の一貫性
   • プラグインヘッダーの Text Domain: とコード内の __(), _e() の第2引数が一致してるか確認

C. Gutenberg JS（5項目）

1. useSelect 依存配列
   • useSelect の第2引数（依存配列）が適切に設定されてるか確認
2. useEffect クリーンアップ
   • useEffect 内でイベントリスナーや購読を登録してる箇所を列挙
   • クリーンアップ関数が返されてるか確認
3. innerBlocks の再帰走査
   • ブロック走査コードを列挙
   • innerBlocks をネストして再帰的に走査してるか確認
4. RichText の allowedFormats 制限
   • RichText コンポーネントを列挙
   • 意図しないフォーマットが許可されてないか確認
5. ブロック属性のバリデーション
   • attributes 定義で type, default, enum, pattern 等の制約があるか確認

D. 実行手順（2段階構成）

第1段階：機械的チェック（Sonnet / Gemini）

1. このチェックリストファイルを AI に渡す
2. セクション A〜C の各項目を順番に実行
3. 各項目ごとに「該当箇所」「判定結果」「指摘（あれば）」を報告

第2段階：推論レビュー（Opus）

第1段階で問題が見つかった場合、またはビジネスロジックの複雑な箇所がある場合：

1. Opus に全ファイルと第1段階の結果を渡す
2. 以下の視点でレビューを依頼：
   • 攻撃チェーンの推論（複数の脆弱性の組み合わせ）
   • ビジネスロジックの欠陥
   • タイミング系の問題（Race Condition、TOCTOU）
   • サードパーティライブラリの既知脆弱性

各項目は「検索指示 → 判定基準 → NG例 → OK例」の形式になってる。Gemini にこのファイルごと渡せばそのまま実行できる。

「これは結構厳しめ？それともゆるい一次チェック？」

作ってもらった後、気になって聞いた。

Claude の答えは「中〜厳しめの一次チェック」。

WordPress.org のプラグインレビューで実際に指摘される項目をほぼ網羅してる。「ゆるいスクリーニング」よりはかなり踏み込んでる内容。

ただし、これでもカバーできない領域はある：

• ビジネスロジックの欠陥（例: 権限はあるが、他人の投稿を編集できてしまう等）
• タイミング系（Race Condition、TOCTOU）
• 複数プラグインの組み合わせ攻撃
• サードパーティライブラリの脆弱性

これらは機械的チェックリストでは拾えない。Opus レベルの推論か人間の判断が必要。

位置づけはこう：

WordPress.org 審査を通すだけならこれで十分すぎる水準。本格的なセキュリティ監査としては第1段階という位置づけ。

AI エージェントの使い分けが見えてきた

今回の経験で、AI エージェントの得意・不得意がはっきりした。

Gemini の適用範囲

得意（マーケティング・コンテンツ系）

• SEO 記事の下書き、キーワード調査
• プラグイン説明文・README の作成
• ユーザー向けドキュメント・FAQ の執筆
• 競合プラグインの機能比較リサーチ

不向き（コード関連）

• 全ファイルを見ない（入力経路の追跡が甘い）
• エッジケースを推論できない
• 攻撃チェーンの推論ができない

Sonnet / Opus の適用範囲

Sonnet（第1段階チェック）

• 機械的なチェックリストの実行
• 構文エラー、WordPress ルール違反の検出
• 基本的なセキュリティ問題の検出

Opus（第2段階レビュー）

• 攻撃チェーンの推論
• ビジネスロジックの欠陥検出
• 複合攻撃シナリオの考察

特にクラッカー視点のレビューは Opus が最も得意な領域。「このコードは安全です」で終わらず、「このフラグがないと </script> が残り、HTML パーサーが反応して XSS になる」っていう攻撃チェーンを推論できる。

テンプレートに組み込んだ

このチェックリストは、プロジェクトテンプレートに組み込むことで、どのプラグイン開発でもルーチンとして実行できる。

テンプレートへの配置

andw-template/
├── CLAUDE.md            # エージェント起動指示
├── docs/
│   ├── AGENTS.md        # エージェント規約
│   ├── WORDPRESS.md     # WordPress 開発規約
│   ├── WP-SECURITY-CHECK.md  # ← 今回作成したチェックリスト
│   └── external/        # その他のエージェントスキル

CLAUDE.md での自動読み込み

## 規約の読み込み
- `docs/AGENTS.md` → `docs/WORDPRESS.md` → `docs/CONTRIB.md` の順に参照
- `docs/external` のエージェントスキルのうち、作業内容に関連するものを参照
- **`docs/WP-SECURITY-CHECK.md` を参照し、ルーチンチェックを実行せよ**

CLAUDE.md の「作業内容に関連するものを参照」で、エージェントが自動的にチェックリストを読み込む。プルリクエスト作成前やリリース前に機械的なセキュリティチェックが回せる。

新しいプロジェクトでの使い方

1. テンプレートから新しいプロジェクトを作成
2. エージェントが自動的に WP-SECURITY-CHECK.md を読み込む
3. 実装完了後、「セキュリティチェックをして」と指示するだけで、チェックリストに沿った精査が実行される
4. 第1段階で問題が見つかった場合、Opus にレビューを依頼

まとめ

プラグイン開発してると、コード品質やセキュリティの問題になかなか気が回らない。今回作ったチェックリストを使うことで：

• ルーチン化：どのプロジェクトでも一貫したセキュリティチェックを実施
• AI 活用：Sonnet や Gemini でも第1段階チェックが可能
• 効率化：機械的な検索指示により、人間が見落としがちな箇所を網羅
• 品質担保：WordPress.org 審査をほぼ通るレベルの品質を維持

ただし、これはあくまで第1段階。ビジネスロジックの欠陥や攻撃チェーン推論が必要な場合は、Opus のような高度な AI や人間のレビューが必要。

チェックリストをテンプレートに組み込むことで、セキュリティチェックがプロジェクトのデフォルトワークフローに組み込まれる。「うっかり忘れ」を防げる。

次のステップ

1. テンプレートの docs/WP-SECURITY-CHECK.md を確認
2. 新しいプラグイン開発プロジェクトで試してみる
3. チェック項目を自分のプロジェクトに合わせてカスタマイズ
4. 第2段階（Opus レビュー）が必要な箇所を特定