wp-guard

WP Guard

WordPress のコードをリリースする前に、生成または変更されたコードをレビューします。最初の実装パスの後に、ガードパスとして以下のルールを適用してください。細部にこだわりすぎず、鋭いレビューを行ってください。脆弱性を招くもの、翻訳を壊すもの、サーバーに過剰な負荷をかけるものを指摘し、WPCS のツールで対応できる見た目だけの好みは無視してください。

これらのルールがあるのは、AI エージェントが WordPress コードで体系的な失敗を繰り返すためです。リクエストデータをそのまま echo する、nonce も権限チェックもない AJAX ハンドラー、文字列補間で組み立てた SQL、ユーザー向け文字列にハードコードされた英語、100 万件の投稿があるサイトでの posts_per_page => -1、そしてコアにすでにある API を独自に作り直すことなどです。これらはデモでは問題ないように見えても、本番環境では失敗します。

このスキルの使い方

ガードパスモード（推奨）：WordPress コードの生成または編集後、diff または対象ファイルにルールを適用し、納品前にセルフチェックを実行します。ユーザーに提示する前に違反を修正してください。

ライブモード（明示的な指定がある場合）：ユーザーが WordPress コードを書く前にこのスキルを呼び出した場合、コードを書きながら同じルールを適用し、納品前にセルフチェックを実行します。

レビューモード（ユーザーが WordPress コードのレビュー、監査、評価を依頼した場合）：対象ファイルについて references/review-checklist.md を確認し、構造化された指摘レポートを作成します。依頼がない限り、レビューモードではコードを編集しないでください。

両方をインストールしている場合は、このスキルと clean-code-guard を併用してください。clean-code-guard は一般的なコード品質を担当し、wp-guard は WordPress のレイヤーを担当します。

まずプロジェクトに合わせる

1. プロジェクトのエージェント向け指示（CLAUDE.md、AGENTS.md）、phpcs.xml／WPCS 設定、composer.json を確認します。競合する場合はプロジェクトの規約を優先します。
2. 確立されたプレフィックス（関数、オプション、メタキー、ハンドル）と、サポートする最小の WP／PHP バージョンを特定します。両方に合わせてください。
3. コンテキストを確認します。WooCommerce API が使われている場合、このスキルがインストールされていれば woo-guard も適用します。インストールされていない場合は、WooCommerce の開発者向けドキュメントにある HPOS、CRUD、チェックアウトのルールを適用します。多言語サイト（WPML／Polylang／マルチサイト）の場合、i18n ルールは助言ではなく必須です。
4. コードを書く前に、隣接するファイルを 1 つ読みます。以下のセキュリティルールに違反する場合を除き、そのファイルのエラー処理、フック登録のスタイル、エスケープの習慣に合わせてください。以下のセキュリティルールは必ず守ってください。

ルール

セキュリティ — 必ず修正し、例外はありません

1. 出力直前に、すべてをエスケープします。 HTML 出力に渡るすべての変数には、コンテキストに合った関数を使います。esc_html()、esc_attr()、esc_url()、またはリッチコンテンツ用の wp_kses()／wp_kses_post() を使います。インライン JS に渡すデータには、wp_json_encode() と wp_add_inline_script() を使います。esc_js() はレガシーな方法で、インライン属性内のシングルクォート文字列に限って使用します。エスケープは保存時ではなく、出力時に行います。esc_* でラップせずに echo $anything; を使うと、レビュー不合格です。

2. 早い段階でサニタイズし、まずスラッシュを解除します。 リクエストデータ（$_POST、$_GET、$_REQUEST、$_SERVER）を未加工のままロジックに渡してはいけません。まず wp_unslash() を使い、その後、型に合ったサニタイザー（sanitize_text_field()、sanitize_key()、absint()、sanitize_email()、など）を使います。サニタイズはエスケープではありません。一方を行っても、もう一方を省略する理由にはなりません。

3. 状態を変更するすべての処理で、利用者の身元と意図を確認します。 フォームハンドラー、AJAX エンドポイント、REST ルートで何かを変更する場合は、権限チェック（current_user_can()）と nonce（check_admin_referer()、check_ajax_referer()、または REST nonce 処理）の両方が必要です。nonce は認可の代わりにはなりません。書き込みを行う REST ルートで permission_callback に __return_true を指定すると、レビュー不合格です。

4. 変数を含むすべてのクエリで $wpdb->prepare() を使います。 補間や連結ではなく、プレースホルダー（%s、%d、%f、および WP ≥ 6.2 の識別子には %i）を使います。WP_Query、メタ API、オプション API でクエリを表現できる場合は、生の SQL よりそちらを優先してください。

コア API の規律

5. プラットフォームを活用し、独自に作り直さないでください。 外部への HTTP 通信には wp_remote_get()／wp_remote_post() を使い、curl は使わないでください。アセットには wp_enqueue_script()／wp_enqueue_style() を使い、<script>／<style> タグを出力しないでください。スケジュールには WP-Cron または Action Scheduler を使ってください。リダイレクトには wp_safe_redirect() を使い、その後に exit を実行してください。ファイルの書き込みには WP_Filesystem を使ってください。単純な永続データには、カスタムテーブルではなくオプション／トランジェントを使ってください。

6. すべてのフックと関数が存在することを確認してください。 add_action()、add_filter() の実行や、コア／プラグイン関数の呼び出しの前に、サポート対象バージョンで存在することを確認してください。ソースコードまたはプロジェクトにインストールされているコードを読んでください。WordPress では存在しないフックを使っても、エラーも動作もなく、何も起こりません。また、フックを適切なタイミングで使ってください。フロントエンドのコードは admin_init では読み込まれず、クエリは init が想定する前に実行されません。

7. 公開する名前にはすべてプレフィックスを付けるか、名前空間を使ってください。 関数、クラス、オプション、トランジェント、メタキー、スクリプトハンドル、AJAX アクション、REST 名前空間など、すべてにプロジェクトのプレフィックスを付けてください。一般的な名前（get_settings、data、api_key）は、次に有効化されるプラグインとの衝突を招きます。

8. 直接アクセスを防止してください。 処理を行うすべての PHP ファイルの先頭に、ABSPATH チェック（またはプロジェクトで定められた同等の規約）を記述してください。

国際化

9. ユーザーに表示する文字列はすべて翻訳可能にしてください。 コンテキストに合ったラッパー（__()、_e()、_x()、_n()、またはエスケープを組み合わせた esc_html__()、esc_attr__()）を使い、プラグインのスラッグと一致するテキストドメインをリテラルで指定してください。変数や定数は使わないでください。すべてのプレースホルダーに翻訳者向けコメントを付け、複数形には _n() を使ってください（単数形／複数形をハードコードして sprintf で選ぶ方法は使わないでください）。文字列の連結で文を組み立てないでください。日付と数値には date_i18n()／wp_date() と number_format_i18n() を使ってください。詳細と JS の国際化については、references/i18n.md を参照してください。

パフォーマンス

10. クエリの規律を守ってください。 posts_per_page => -1 と query_posts() は絶対に使わないでください。ID だけが必要な場合は 'fields' => 'ids' を使い、ページネーションをしない場合は 'no_found_rows' => true を使ってください。また、一度に準備できるもの（メタ／タームキャッシュ）をループ内でクエリしないでください。詳細は references/performance.md を参照してください。

11. 負荷の高い処理はキャッシュし、アセットは使う場所でのみ読み込んでください。 外部呼び出しや負荷の高い計算は、意図した TTL を設定してトランジェントまたはオブジェクトキャッシュ経由で実行してください。サイズが大きい、または読み取り頻度が低いオプションは、autoload => false を指定して登録してください。スクリプトとスタイルは、使用する画面でのみエンキューしてください。

提出前のセルフチェック

1. diff を echo、print、<?= で grep してください。出力するすべての変数が、コンテキストに適した関数でエスケープされていますか？
2. $_POST、$_GET、$_REQUEST を grep してください。スラッシュが除去されていますか？ サニタイズされていますか？ nonce が検証されていますか？ 権限が確認されていますか？
3. $wpdb-> を grep してください。すべての変数にプレースホルダーが使われていますか？
4. 国際化用ラッパーの外にユーザー向け文字列はありませんか？ リテラルではないテキストドメインはありませんか？
5. 存在を確認していないフックや関数はありませんか？
6. 範囲に上限のないクエリ、キャッシュされていない外部呼び出し、無条件のエンキューはありませんか？
7. 追加した公開名にはすべてプロジェクトのプレフィックスが付いていますか？
8. 正当化できない警告なしで、WPCS（WordPress-Extra + WordPress-Security）に準拠できますか？

どれか一つでも答えが誤っている場合は、ユーザーに提示する前に修正してください。

報告形式（レビュー時）

**Rule N violation** in `path/file.php:<line or function>`
- What: <one sentence>
- Risk: <XSS / SQLi / CSRF / broken i18n / scaling — one phrase>
- Fix: <one sentence>

ファイルごとにまとめ、セキュリティ上の指摘から記載してください。問題のないファイルには触れないでください。

重要度の目安

• 必ず修正： ルール 1〜4 — 悪用されるおそれがあります（XSS、SQLi、CSRF、権限昇格）。
• 修正を推奨： ルール 5〜9 — 競合、気づきにくい失敗、翻訳できないリリースにつながります。
• 注意事項： ルール 10〜11 — コードがトラフィックに耐えられるかを左右します。すべてのリクエストで実行されるコードでは、対応必須です。

参考資料

• references/security.md — エスケープ／サニタイズ関数の表、nonce のライフサイクル、REST の権限、$wpdb->prepare の詳細、ファイルアップロード
• references/i18n.md — ラッパーの選択、テキストドメインのルール、複数形、翻訳者向けコメント、JS 翻訳、RTL、多言語プラグイン特有の注意点
• references/performance.md — WP_Query のフラグ、transient とオブジェクトキャッシュの比較、autoload の適切な管理、アセットの読み込み、cron、スケーリング時の落とし穴
• references/review-checklist.md — レビューモードでの体系的な確認手順
• references/sources.md — ハンドブックと調査用 URL。出典を引用する場合にのみ参照してください

このスキルで対応しないこと

• PHPCS、PHPStan、Plugin Check の実行 — 機械的な検証にはプロジェクトのツールを使用してください。このスキルは、その上位にある判断レイヤーです。
• プラグインのアーキテクチャやビジネスロジックの決定 — WordPress コードのリリース方法を保護するものであり、コードが何をするかを決めるものではありません。
• clean-code-guard や test-guard の置き換え — 一般的なコード品質とテスト品質は、引き続きそれぞれの管轄です。