AI生成コードは、そのまま納品物として扱うのではなく、未確認の実装案として人がレビューする必要があります。生成速度は大きな利点ですが、案件固有の仕様、WordPressの作法、安全性、将来の保守性は、出力されたコードだけでは保証されません。
最初に仕様との一致を確認する
コードが動くことと、依頼された仕様を満たすことは別です。対象ページ、入力項目、権限、例外時の表示、スマートフォン動作、既存プラグインとの役割分担を確認します。AIが前提を補って実装している場合は、その前提が案件と一致しているかを洗い出します。
入力・保存・出力を分けて確認する
WordPress公式は、入力値を信頼せず、用途に応じて検証またはサニタイズし、表示時には文脈に合ったエスケープを行う考え方を示しています。テキスト、URL、HTML、属性、SQLでは必要な処理が異なります。
- 許可する値を限定できる場合は検証する
- 保存前に用途に合ったサニタイズ関数を使う
- HTML本文は許可する要素を限定する
- URL、属性、本文を出力直前に適切にエスケープする
- 独自SQLではWordPress APIとprepareを利用する
権限とリクエストの正当性を確認する
管理画面の保存処理では、nonceだけでなく、操作するユーザーが対象投稿や設定を変更できるかも確認します。nonceはリクエストの意図を確認する仕組みであり、権限管理の代わりではありません。AJAXやREST APIを追加する場合も、認証、権限、入力値、エラー応答を個別に確認します。
保守性と責任の所在を確認する
短いコードでも、変数名、関数の責務、フックの優先順位、依存関係、コメント、エラー処理が不明確だと、次の担当者が修正しにくくなります。WordPress Coding Standardsに沿って整理し、なぜその実装にしたかを記録します。OWASPも、AI支援による変更を人がレビューし、承認者と責任を明確にすることを案内しています。
実際の環境でテストする
構文検査だけで終わらせず、ローカルまたはステージングで正常系と異常系を確認します。PHPエラー、ブラウザのJavaScriptエラー、権限の違うユーザー、空入力、長文、複数回操作、キャッシュ、モバイル表示などを対象にします。既存機能に影響する変更では、変更箇所以外の主要ページも確認します。
依存関係と変更差分を確認する
AIが提案したライブラリや外部サービスを追加する場合は、公式配布元、更新状況、ライセンス、既存環境との重複を確認します。変更前後の差分を小さく保ち、依頼範囲外のファイルや設定が変わっていないかも確認します。プロンプトや回答ではなく、最終的に採用したコードとテスト結果を変更履歴として残すことで、将来の修正時に判断しやすくなります。
AI活用＋人の確認を制作フローにする
AIを使うかどうかより、どの工程に使い、誰が何を確認したかが重要です。GreenCodingでは、調査や反復実装の補助にAIを活用し、仕様適合、安全性、表示、操作、保守性は人が確認します。詳しくはGreenCodingの制作体制をご覧ください。