演習5：AIにセキュリティレビューをさせる

最後の演習は、AIにセキュリティレビューをさせることです。ただし、やり方で結果が大きく変わります。論文の実験では、頼み方ひとつで同じ穴の再発率が11%にも46%にもなりました。この章では、効く頼み方と逆効果の頼み方を数字で確かめたうえで、OWASP Top 10:2025を観点として渡すレビュー依頼の定型文を用意します。そして、実践編全体を踏まえた「公開前チェックリスト」の完成版で締めくくります。

頼み方で結果が変わる：論文の実験

第4章で触れた実験を、ここで数字ごと使います。論文の著者は、監査で見つかった脆弱性のうち70件を選び、それぞれの機能をAIにもう一度作らせる実験を、条件を8通りに変えて3回ずつ、70件×8条件×3回で合計1,680回（各条件210回）行いました。指示文の添え方などを変えたとき、同じ脆弱性がどれだけ再発したかが次の表です。

読み取れることは3つです。第一に、「本番運用に耐えるものを」という目的の一言が、再発率を半分以下にしました。第二に、モデルを強いものに替えても変わりませんでした。第三に、技術的な指示を細かく書き込むと、基準の倍近くまで悪化しました。

なぜ細かい指示が逆効果なのか。論文の著者はこう解釈しています。AIは与えられた指示に忠実になりすぎ、指示に書かれていない「暗黙の安全規則」を落としてしまう、と。「この処理をこう書いて」と手段を細かく指定されると、AIは言われた通りに書くことに集中し、「所有者を確認する」「入力をエスケープする」といった、言われなくても守るべき規則を省きます。目的（本番で使う）を伝えると、逆にAIがその規則を自分で補います。

ただし、これは「指示を細かく書くな」という意味ではありません。論文の助言は2点です。自分が理解していない技術的な細部をAIに渡さないこと。そして、セキュリティについては明示的に指示すること（「本番運用に耐えるものを」の一言や、セキュリティ観点のスキルを渡すこと）です。自分が中身を理解している指定まで控える必要はありません。

経理の新人に「この伝票を、この科目で、この金額で切って」とだけ指示すれば、証憑の確認を飛ばすかもしれません。「監査に耐える処理をして」と目的を伝えれば、証憑の確認まで自分でやる。それと同じ構図です。

「作るAI」と「見るAI」を分ける

経理の内部統制で最も基本的な原則は、作成者と承認者を分けることです。自分で起票した伝票を自分で承認してはいけない。同じことがAIにも当てはまります。

アプリを作らせたのと同じ会話（セッション）で「セキュリティを見直して」と頼むと、AIは自分が書いたコードを「正しく作った」という前提で読みます。上の表で「変更を見直して」がほとんど効かなかった（23.8%）ことは、同じ会話の中での見直しに限界があることを示しています（効かなかった理由までは、論文で検証されていません）。そこで、レビューは別のセッションで、できれば別のモデルや別のツールで行うことを勧めます。なお、これは内部統制の考え方から導いた実務上の工夫で、論文が効果を比較実験した条件ではありません。論文の監査でも、Claude CodeとGitHub Copilotという2系統のエージェントを、2種類のセキュリティスキルと組み合わせた4通りで行い、報告を突き合わせていました。見る側を変えると、見つかるものが変わる可能性があるからです。

具体的には次のようにします。

1. 作らせたセッションを閉じ、新しいセッションを開きます。会話の履歴が残っていない状態にします。
2. 「このリポジトリのセキュリティレビューをしてください」と、作ったときの経緯を一切伝えずに頼みます。「自分で作った」と言う必要もありません。
3. 可能なら、別のモデルや別のツールでも同じ依頼をし、報告を突き合わせます。片方だけが指摘したものは、人がどちらが正しいかを判断します。

レビュー依頼の定型文：OWASP Top 10:2025を観点に渡す

「セキュリティを見て」とだけ頼むと、AIは自分の得意な観点だけを見ます。観点を渡すと、抜けが減ります。渡す観点は、OWASP Top 10:2025の10項目です。これは応用編で詳しく扱いますが、レビューの観点として使うだけなら、項目名を渡せば十分です。

このリポジトリのセキュリティレビューをしてください。
このアプリは本番運用に耐えるもの（ready for production）である必要があります。

前提：
- あなたはこのコードを書いた人ではなく、独立したレビュー担当者として読んでください
- 推測で補わず、コードと設定ファイルから読み取れることだけを根拠にしてください
- 秘密情報（鍵、パスワード、接続文字列）の値そのものは絶対に出力しないでください
- 攻撃用の文字列やコードの例は出力しないでください
- 修正はまだしないでください。報告だけお願いします

観点（OWASP Top 10:2025）：
A01 アクセス制御の不備：データを取得・更新・削除する処理で、サーバー側が所有者や役割を確認しているか。IDを変えると他人のデータに届く箇所はないか
A02 セキュリティ設定の不備：デバッグ設定、CORS、エラー表示、初期設定のままの箇所
A03 ソフトウェアサプライチェーンの不備：依存パッケージの既知の脆弱性、不要な依存、出所の怪しいパッケージ
A04 暗号化の不備：パスワードの保存方法、通信の暗号化、秘密情報の置き場所
A05 インジェクション：データベースへの命令の組み立て方、出力時のエスケープ、HTMLをそのまま挿入する機能の使用箇所
A06 安全性を欠いた設計：残高や権限などの業務ルールがサーバー側で守られているか、信頼境界をまたぐ入力の扱い
A07 認証の不備：セッションの扱い、ログアウト、パスワードの最小長、総当たりへの備え
A08 ソフトウェアまたはデータの完全性の不備：外部から受け取るデータや通知の検証、署名の確認
A09 セキュリティログとアラートの不備：ログイン失敗や権限エラーが記録されているか、ログに秘密情報が混ざっていないか
A10 例外的な状況への不適切な対応：エラー時に内部情報が出ないか、失敗時に安全側に倒れるか

報告の形式：
1. 観点ごとに、該当箇所（ファイル名と行番号）、深刻度（致命的／高／中／低）、根拠、修正の方針を表にしてください
2. 深刻度の高い順に、全体を並べ直した一覧も付けてください
3. 「この操作は誰に許されるべきか」のように、業務ルールが分からないと判断できない箇所は、修正案を出さずに「持ち主への質問」として別に列挙してください
4. 問題が見つからなかった観点についても、何を確認したかを書いてください

最後の2項目が大切です。AIが勝手に業務ルールを決めないように「質問として列挙」させること。そして「問題なし」の根拠も書かせることで、見ていない観点を「問題なし」と報告されるのを防ぎます。監査でいう「手続の実施記録」と同じです。

修正のあとに、もう一度手で確かめる

レビューの報告をもとに修正をAIに任せたら、それで終わりではありません。論文の失敗モードに「機能修正の副作用」（100件、8.4%）と「変更の伝播不足」（110件、9.3%）がありました。ある穴を塞ぐ修正が、別の場所に穴を開ける。ある箇所を直したのに、同じ処理をしている別の箇所が直っていない。合わせて2割弱が、この種の「直したつもり」でした。

ですから、修正のあとに、第10章（権限）と第11章（入力欄）の確認をもう一度、手で実行します。修正仕訳を入れたあとに残高を再照合するのと同じです。修正は小さく、一つずつ。まとめて直させると、どの修正が何を壊したか分からなくなります。修正ごとに、AIに「何を変えたか」を差分で説明させ、点検ノートの「対応内容」に写してから、再確認します。

AIレビューの限界

AIは、コードの中にあるものは読めます。しかし、コードの外にあるものは読めません。その最たるものが、ビジネスロジック（この操作は、誰に、どこまで許されるべきかという業務上の決まり）です。

あなたのミニ銀行で、「管理者は全利用者の残高を見られる」のは仕様でしょうか、不備でしょうか。「利用者は自分の取引を取り消せる」のは便利な機能でしょうか、危険な穴でしょうか。AIには分かりません。それを決めるのは持ち主であるあなたです。だから定型文では、こうした箇所を「質問として列挙」させています。質問に答えるのはあなたの仕事で、そこは誰にも代わってもらえません。経理で「この支出は誰の承認が要るか」を決めるのが、システムではなく規程であるのと同じです。

もうひとつの限界は、誤報です。論文の監査では、AIが出した生の報告11,150件のうち、最終的に専門家2名が「悪用できる」と認めたのは1,186件でした。AIの指摘には、重複も、誤りも、実際には届かないものも混ざります。レビュー報告をそのまま信じず、「致命的」「高」のものから自分の目で確かめ、第10章・第11章の手順で再現できるかを見ます。

そして、他人のデータやお金を扱うアプリを本格的に公開するなら、AIと自分の点検に加えて、専門家のレビューを受けてください。この教材は、専門家と話せるようになるためのものであって、専門家の代わりになるものではありません。

公開前チェックリスト（完成版）

基礎編第6章のチェックリストを、実践編の5つの演習を踏まえて拡張したものです。公開する前、そして大きな変更を加えたあとに、上から順に確かめてください。すべてに印が付かないなら、まだ公開しない、という判断も含めて「自分の判断基準」です。