AIが生成したコードを見たとき「このコード、本当に大丈夫？」と不安になった経験はありませんか？
自分用に作る分には「とりあえず動けばいい」で済みますが、商品として販売する場合は、そういう訳にはいきません。
従来は専門のエンジニアに頼るしかなかったコードチェックでしたが、生成AIの進化により、自力でのコーディング経験が浅い（もしくは無い）非エンジニア職の方にも、実施することが可能になりました。
同じく非エンジニア職であるWebディレクターさんなど、外部のエンジニアにアウトソーシングしている方にも役立つよう、外部エンジニアさんとのやり取りのコツも記載しましたので、ぜひご活用ください。
1. コードレビューとは
納品されたプログラムに対して、次のような観点で問題がないかを確認する作業です：
- バグの有無
- セキュリティリスクの存在
- 将来的な修正・運用のしやすさ
AI活用により可能になること
- 炎上リスクの早期察知
- 発注者としての品質管理責任の履行
- 緊急トラブル時のコスト削減
- 業務委託先との信頼関係強化
2. コードレビューで確認すべき5つの観点
セキュリティリスクの検出
- フォームからの情報漏洩や改ざん
- 管理画面の総当たりログイン攻撃
- セッションの乗っ取りやCookieの盗用
実例：
- 顧客の個人情報がすべて流出
- サイトに「このサイトはハッキングされました」と表示
- 検索結果に「危険なサイト」として警告表示
パフォーマンス・効率性の評価
- 表示速度が遅い（10秒以上）
- データベース処理が重くアクセス集中に弱い
- モバイル端末での読み込みエラー
エラー発生時の対応
悪い例：「Error 500: Internal Server Error」
→ 利用者は何が起きたか分からず困惑
良い例：「現在アクセスが集中しています。しばらくして再度お試しください」
→ 状況説明と信頼感を両立将来の修正・追加のしやすさ（保守性）
- コメントや説明がなく意図が分からない
- 命名規則が統一されていない
- 小さな改修に高額な費用が発生
仕様通りに作られているか（契約履行チェック）
- 発注通りの機能が実装されているか
- 余計な機能が含まれていないか（リスク要因）
- データ形式や操作性が仕様書通りか
3. AI活用コードレビューの実践フロー
AIツール比較（2025年7月最新情報）
| ツール名 | 月額料金（目安） | 特長 | 推奨用途 |
|---|---|---|---|
| ChatGPT Plus | 約3,000円（20USD） | 分かりやすい表現・柔軟な対話・壁打ち力 | 初心者向け、軽微なレビュー、説明生成 |
| Claude Pro | 約3,000円（20USD） | 長文処理・構造理解が強い。セキュリティ観点に強い | 重要機能の深堀分析（ログイン・決済） |
| Gemini Advanced | 2,900円（税込） | Google連携・大量ファイル解析が得意 | ページ数が多い大規模サイトの一括確認 |
プロンプト精度を高める3つのテクニック
役割を与える（ロールプレイ）
あなたはセキュリティ専門家です。以下のログイン処理コードを分析し、脆弱性がないか確認してください。出力形式を指定する
以下の形式で問題点を整理してください：
【ファイル名】【該当箇所】【問題の概要】【推奨される修正案】背景・制約を与える
このサイトはWordPressで構築されています。XSSとSQLインジェクションの脆弱性がないか確認してください。
※個人情報はDB保存禁止という制約があります。4. AIツールの使い分けと実例
ChatGPT Plus：初心者向け・説明重視
用途：全体把握、初期レビュー、ドキュメント化、発注者向け説明文作成
実例プロンプト：
このECサイトのコードにセキュリティ上の問題がないか確認してください。ChatGPTの回答例：
Claude Pro：構造理解・長文解析・セキュリティ分析向け
用途：ログイン・決済処理／データ設計構造の安全性評価
実例プロンプト：
この会員制サイトのログイン機能をセキュリティ観点から確認してください。Claudeの回答例：
- セッション固定化未対策 → セッションハイジャック懸念
- ログイン試行回数制限が未実装
- CSRFトークンの非使用 → 対策コード例付きで提案
Gemini Advanced：大規模解析・Googleサービス連携向け
用途：20ページ以上のサイト／複数HTMLファイルの一括レビュー
実例プロンプト：
このWebサイト一式（20ファイル）を解析し、全体の品質・統一性・セキュリティをチェックしてください。Geminiの回答例：
- フォーム処理でサニタイズが不完全
- 管理画面の認証方式が簡易（Basic認証のみ）
- フォルダ構成やファイル命名に不統一あり
5. 言語別レビューとプロンプトテンプレート
PHP（WordPress含む）
主なチェックポイント：
- プラグインの更新状況と出所（信頼性）
- ファイルアップロード機能の制御（拡張子フィルタ・サイズ上限）
- メールフォームがスパム送信の踏み台になっていないか
プロンプト例：
このWordPressサイトについて以下の観点で確認してください。
【懸念点】
- プラグインやテーマのセキュリティ
- フォーム機能がスパム送信に使われないか
- ファイルアップロード機能の安全性Python（データ分析・AIバックエンド系）
主なチェックポイント：
- API連携時の例外処理（Timeout、接続失敗）
- ファイル処理のセキュリティ対策（拡張子、内容検査）
- メモリ処理負荷（特にPandas・NumPy使用時）
プロンプト例：
このPythonアプリケーションについて以下をチェックしてください。
【懸念点】
- データ処理時のメモリやエラー制御
- ファイルアップロード機能の制限
- 外部API連携の安定性と例外処理SQL（データベース操作）
主なチェックポイント：
- SQLインジェクション耐性（プリペアドステートメントの使用）
- JOINやWHEREの最適化
- トランザクションとバックアップ方針の有無
プロンプト例：
このSQLクエリのセキュリティとパフォーマンスをチェックしてください。
【懸念点】
- SQLインジェクションのリスク
- 重複・無駄なJOINの存在
- WHERE句の条件最適化用語説明
パスワードのハッシュ化とは？
パスワードを直接保存せず、不可逆な形式（ハッシュ）に変換して保存するセキュリティ対策。
※ハッシュ化とは、ものすごく簡単に言うと、暗号化技術の進化系のようなものです
（実際には仕組みも目的も異なりますが、セキュリティ強化の中で発展してきた技術です）
なぜ必要か？
- 平文（そのままの文字列）保存だと、漏洩時に即パスワードが判明する
- ハッシュ化していれば、元の文字列を復元するのが困難
よく使われるハッシュ関数：
bcrypt（推奨）argon2PBKDF2など
セキュリティ上のポイント：
- 単なるMD5やSHA1は脆弱（解析されやすい）
- ソルト（乱数）を組み合わせて使うことで強度を高める
- ハッシュ値をそのままログ等に出力しない
セッションハイジャックとは？
ログイン状態を不正に乗っ取られる攻撃手法のこと。
ユーザーのセッションID（認証トークン）を盗み取り、本人になりすましてシステムにアクセスします。
被害例：
- 管理者画面への不正ログイン
- なりすまし操作によるデータ改ざん
原因となる例：
- セッションIDがURLに含まれている
- HTTPS未使用で通信内容が盗聴される
- セッション固定化対策が未実装
対策：
- セッションIDの再生成（ログイン時・権限変更時）
- HTTPS常時化
- Cookie属性に
HttpOnlyやSecureを設定
CSRFトークンとは？
外部サイト経由の不正な操作（CSRF攻撃）を防ぐためのセキュリティ対策。
「Cross Site Request Forgery（クロスサイト・リクエスト・フォージェリ）」の略です。
攻撃イメージ：
ログイン状態のユーザーが、悪意ある外部サイトを開くと、
勝手に「削除」や「送信」といった操作がサーバーに送られてしまう。
対策としてのトークン：
- 正規フォームに使い捨ての乱数トークンを埋め込む
- 送信時に一致しているかサーバーで検証する
- 不一致ならリクエストを拒否
導入が特に重要な場面：
- 会員情報の変更
- 決済・キャンセル操作
- アカウント削除などの重要処理
サニタイズ（sanitization）とは？
Web入力内容を安全な形式に変換する処理のこと。
主に、JavaScriptやHTMLタグなどが意図せず実行されるのを防ぐために行います。
危険な例
<script>alert('XSS')</script>のような入力が、ページにそのまま出力されると、
スクリプトが実行されてしまう（XSS発生）
サニタイズ処理の目的：
- 上記のような危険な文字列を、無害な表記に変換すること
→ 例：「<」 →「<」，「>」 →「>」
代表的な対象：
- ユーザーが入力する「フォームの値」
- URLパラメータ
- 管理画面から保存された記事本文やコメント欄の内容
誤解しやすい注意点：
- サニタイズは「入力時」か「出力時」に行うべきかを、開発チームと明確に合意しておくこと
- 「バリデーション（妥当性検証）」とは異なる役割であり、併用が必要
対策の位置づけ：
- サニタイズは、下記の XSS の対策としても使用される手法
- AIレビュー時には、フォーム・表示部分の出力内容に対して適用されているかを重点チェックする
クロスサイトスクリプティング（XSS）とは？
悪意あるスクリプトがWebページ上で実行されてしまう脆弱性。
ユーザーが入力した内容が、そのままページに反映されていると起きます。
危険な例：
- フォームやURLパラメータにJavaScriptコードを埋め込まれ、
それがWebページ上で自動的に実行されてしまう。 - 例）
<script>alert('乗っ取り');</script>というコードが、
管理画面やユーザー画面にそのまま表示される。
被害例：
- Cookie情報（ログイン状態）を盗まれる
- 偽の入力フォームが表示され、情報を抜き取られる
- 管理者アカウントのなりすまし
対策：
- 入力内容の「無害化（サニタイズ）」
→ たとえば<script>を<script>に変換 - JavaScriptを意図しない形で出力しないように制御する
SQLインジェクションとは？
データベースへの命令文（SQL）に、悪意ある内容を混入される脆弱性。
フォーム入力などから直接SQL文を作成していると起きやすい。
危険な例：
- ログイン画面に
OR 1=1 --と入力されると、
認証処理がすり抜けて不正ログインが成功してしまう。 - 例）
SELECT * FROM users WHERE id = '入力値';
→ 入力値が1 OR 1=1の場合、全ユーザー情報を取得できてしまう
被害例：
- 個人情報や顧客データの漏洩
- 不正ログイン／アカウント乗っ取り
- データの削除や改ざん
対策：
- 「プレースホルダー」や「プリペアドステートメント」など、
SQLを安全に組み立てる手法を使う（開発側の責任） - 入力内容をチェック・制限する
6. スタイルガイド遵守と静的解析の併用
スタイルガイドとは？
スタイルガイドは、「コードの読みやすさと保守性」を高めるための書き方ルール集です。
技術仕様（HTMLタグの意味など）を定める W3C とは異なり、「どう書くか」を定めるのがスタイルガイドです。
言語別スタイルガイド例
| 言語 | スタイルガイド名 | 主な特徴 |
|---|---|---|
| HTML/CSS | Google HTML/CSS Style Guide | 属性順やクラス名命名ルールなどを定義 |
| JavaScript | Airbnb JavaScript Style Guide | 関数定義や変数スコープのルールが明確 |
| PHP | PSR-12（PHP-FIG） | ファイル構成・命名・インデントの標準 |
| Python | PEP8 | 行長・空白・命名などを詳細に規定 |
| SQL | SQL Style Guide（Simon Holywell） | SELECT句の整形や予約語の大文字化 |
AIでのスタイルチェック用プロンプト
このコードがスタイルガイド（例：PEP8、PSR-12、Airbnb）に沿っているか確認してください。
【確認したいこと】
- 構文ルール違反の有無
- 保守性や読みやすさを損ねている点
- 修正例とその理由（分かりやすく）静的解析ツールとの併用
静的解析とは？
- コードを実行せずにルール違反やバグの可能性をチェックするツール
- 例：ESLint（JS）、PHP_CodeSniffer（PHP）、Flake8（Python）
AIレビューとの違いと使い分け
| 項目 | 静的解析ツール | AIレビュー |
|---|---|---|
| 目的 | ルール違反・構文ミスの検出 | 意図・意味・セキュリティの文脈評価 |
| 対象 | スタイル・命名・空白・改行 | 設計思想・業務要件との整合性 |
| 精度 | 高速・安定（ルールベース） | 柔軟・文脈的（生成ベース） |
最適なワークフロー
- 一次チェック：静的解析でフォーマットや構文を自動チェック
- 二次レビュー：AIでセキュリティ・構造・ビジネス要件との整合性を評価
7. 業務委託先との対話と品質管理
発注依頼時に明記すべきコード品質関連情報
納品後に品質トラブルを防ぐためには、発注段階で以下の内容を明文化しておくことが重要です。
業務委託先と合意済であることを、AIレビュー時の評価軸にもできます。
発注書への記載例：
■ コーディング方針・品質ルールについて
以下の項目を遵守のうえ、実装をお願いいたします。
1. 使用するコーディングスタイルガイド名
- 例）PSR-12（PHP）、PEP8（Python）、Airbnb JavaScript Style Guide 等
- 独自のスタイルガイドがある場合は、資料を添付してください
2. 静的解析ツールの利用有無（使用する場合はルール定義ファイルも記載）
- 例）PHP_CodeSniffer（ruleset.xml）、ESLint（.eslintrc）
3. セキュリティ要件
- クロスサイトスクリプティング（XSS）、SQLインジェクション対策
- 認証方式、パスワード管理方式（例：ハッシュ化）、CSRF対策 等
4. コメント・ドキュメントの方針
- 関数・処理単位でのコメント記載／README整備 等
5. 機密情報の取り扱い
- APIキーや個人情報のハードコーディング禁止
- ダミー値や環境変数使用を必須とする場合は明記
6. その他
- 納品形式（ディレクトリ構成・ファイル命名規則）
- AIによるレビュー実施を前提とする旨（オプション）AIの指摘を伝えるときの注意点
鵜呑みにせず深掘りする
この指摘の根拠は何ですか？
この問題を放置するとどんなリスクがありますか？告発ではなく相談ベースに
- NG：「AIが危険と言ってました」
- OK：「XSSの可能性があるとの指摘があり、サニタイズの有無を確認させてください」
合意済みの基準を根拠にする
私たちが採用している『PSR-12』の観点から見ると、命名規則に若干のズレがあるようです。
保守性向上のため、このガイドに沿って統一できませんか？8. AIコードレビューの限界と注意点
ハルシネーション（もっともらしい嘘）
- AIは時に誤情報を出力します
- 常に「これは本当か？」と人間側で再確認することが必要です
全体像を理解していない
- AIは与えられたコード片しか見ていません
- サイト全体の設計や事業要件は考慮していません
機密情報の取り扱いに注意
- APIキー・パスワード・個人情報といった機密情報を直接AIに送信しないこと
- レビューを依頼するときは、該当箇所を
xxxxや[SECRET_KEY]のようなダミーデータに置き換える（マスキングする）こと - もしくは、法人向けセキュリティプラン（Business／Enterprise等）を検討すること
まとめ：AIレビューで実現する「発注者品質」の時代へ
- コードレビューは「エンジニアにお任せ」から「クライアントの窓口であるWebディレクター」にも手が届く存在へ
- AIツールとプロンプト設計を活用すれば、非エンジニアでも品質確認が可能
- レビューの目的はあくまで「より良いWebを一緒に作るため」であることを忘れず、業務委託先との信頼関係を土台に、建設的な改善を進めていきましょう
