AI生成コードのセキュリティ、「動いたから納品」をやめる社内ルール──人が確かめる5つの観点、実在しないパッケージの確認、記録の型

この記事は、AI生成コードのセキュリティを、制作会社の社内ルールとして人が確かめる仕組みを扱います。

「AIが書いたので、たぶん大丈夫です」

問い合わせフォームの改修を、若手のエンジニアが半日で仕上げました。
コードの大半は、AIのコーディング支援が書いたものです。

画面で動作を確かめ、そのまま本番に反映しました。
ところが、入力値の扱いや、エラーのときに何が表示されるかを確かめた人は、誰もいませんでした。

AIを使ったこと自体が、問題なのではありません。
「動いた」ことと「安全である」ことを、誰も分けて確かめていなかったことが、問題なのです。

AI生成コードのレビューとは、AIが書いた部分を「人が書いたコードと同じ基準」で確かめ、確かめた記録を残す社内の手順である

黒字化の外科医です。AIで速くなった実装を、事故にしないためのレビューのルールを解剖します。

ルールが必要な理由は、三つあります。

第一に、AIは、安全でないコードや実在しない部品を提案することがあるから。
OWASPの「Top 10 for LLM Applications 2025」は、9番目の「Misinformation」の中で、モデルが安全でない、あるいは存在しないコードのライブラリを提案するリスクを挙げています。あわせて、出力を確かめずに信頼しすぎること（過信）の危うさと、人による確認を対策として示しています。

第二に、AIに関わるリスクが、組織の重要な脅威として扱われ始めたから。
IPAの「情報セキュリティ10大脅威 2026」組織編では、「AIの利用をめぐるサイバーリスク」が3位に初めて選ばれました。

第三に、顧客から見れば、誰が書いたかは関係ないから。
納品したのは制作会社です。AIが書いた部分も、自社のコードとして説明できなければなりません。

今すぐ試せる：AI生成コードのレビュー観点を洗い出すプロンプト

私はWeb制作会社の技術責任者です。AIのコーディング支援で書いたコードを、社内でレビューするための観点を作ってください。
（顧客名、ID、パスワード、APIキーなどの秘密情報は入力しません）

【前提】
・案件の種類（コーポレートサイト、フォーム、会員機能、ECなど）：〔　〕
・使っている言語とフレームワーク：〔　〕
・AIに書かせた範囲：〔例：フォームの入力チェック、管理画面の一覧〕
・レビューにかけられる時間：〔　〕

1. この範囲で、セキュリティ上とくに確かめるべき点を、優先順に挙げる。
2. 各点について「確かめ方」と「合格の目安」を書く。
3. 新しく追加された外部のパッケージを、人が確かめる手順を書く。
攻撃の手順は書かず、確かめる観点だけを書くこと。

AIにレビュー観点を出させても、最終の判断は人が行います。観点の抜けは、次の工場の5観点と照らし合わせてください。

レビュー工場：変更の重さ、5つの観点、記録の型

変更の重さで、レビューの深さを変える

【重い】ログイン、権限、決済、個人情報の保存、ファイルのアップロード
→ 書いた人以外の2人目が、5観点すべてを確認。本番反映は責任者の承認後

【中くらい】フォームの入力、データベースへの読み書き、外部サービスとの連携
→ 書いた人以外の1人が、5観点を確認

【軽い】見た目の調整、静的なページの追加
→ 書いた人が5観点の該当部分を自己確認し、記録だけ残す

AIを使ったかどうかで、深さを変えないのが要点です。変更の重さで決めておけば、「AIを使ったと言いにくい」空気も生まれません。

人が確かめる5つの観点

□ 1. 入力値の扱い
　利用者の入力を、データベースや画面にそのまま渡していないか

□ 2. ログインと権限
　ログインしていない人、権限のない人が、その処理を使えないか

□ 3. 秘密情報の混入
　APIキー、パスワード、接続先の情報が、コードに直接書かれていないか

□ 4. 追加されたパッケージ
　そのパッケージが実在し、公式の配布元のもので、保守が続いているか
　（名前が似た別物でないかを、公式のページで確かめる）

□ 5. エラーとログ
　エラーのときに、内部の情報（ファイルの場所、設定の値など）を画面に出していないか

照らし合わせる基準には、IPAの「安全なウェブサイトの作り方」（改訂第7版）が使えます。ウェブサイトの開発者・運営者向けの資料で、11種類の脆弱性と対策、チェックリストが付いています。

1の観点は、SQLインジェクション対策とXSS対策で詳しく扱っています。

お客様のサイトにAIの機能を組み込むとき

□ AIの出力を、確かめずに画面・データベース・別の処理へ渡していないか
□ AIに渡す情報に、ほかの利用者の個人情報や社内の秘密が混ざらないか

OWASPの同じ一覧は、5番目に「Improper Output Handling」（出力の不適切な取り扱い）、2番目に「Sensitive Information Disclosure」（機微な情報の開示）を挙げています。AIの出力は、利用者の入力と同じく「確かめてから使うもの」として扱います。

レビューの記録の型

案件名：〔　〕　変更の重さ：重い／中くらい／軽い
AIに書かせた範囲：〔　〕
書いた人：〔　〕　確認した人：〔　〕　確認日：〔　〕
5観点の結果：1〔〇／×〕2〔　〕3〔　〕4〔　〕5〔　〕
追加したパッケージと確認した配布元：〔　〕
指摘と修正：〔　〕

見積もりに、レビューの時間を残す（例）

AIを使う前の実装：10時間（例）
AIを使った実装：4時間 ＋ レビュー：2時間 ＝ 6時間
減った時間：10時間 − 6時間 ＝ 4時間

レビューの2時間まで削ると、速さの代わりに事故の可能性を顧客に渡すことになります。AIで減った工数を価格にどう返すかは、こちらで扱っています。

▶ Web制作のAI時代の単価は「減った工数の何割を価格に返すか」で決める──成果物と範囲で値付けする手順、価値の根拠の示し方、還元率の計算例

構造的なリスク

逆説を指摘しておきます。

AIで実装が速くなるほど、レビューの量が追いつかなくなります。
一日に何本も変更が上がると、確認する人がいちばんの渋滞になります。

だから、全部を同じ深さで見ようとしないでください。
重い変更に人の時間を集め、軽い変更は記録だけにする。この割り切りが、ルールを続けられるかどうかを決めます。

よくあるQ&A

Q. AIに、レビューもさせればよいのではないか？

観点の洗い出しや、見落としの候補探しには役立ちます。ただし合否の判断と記録は、人が行ってください。OWASPも、人による確認を対策として挙げています。

Q. 外注先がAIを使っているかどうか、どう確かめるか？

使ったかどうかより、納品物に5観点の記録を付けてもらう形にします。記録の型を、発注のときに渡してください。

Q. 顧客の情報を、AIのコーディング支援に入れてよいか？

預かった情報の線引きは、AIの情報漏えい対策で扱っています。秘密情報の扱いは、同じ考え方で決めてください。

最後に

AIが書いたコードは、速く手に入る下書きです。安全かどうかは、人が確かめるまで分かりません。

変更の重さでレビューの深さを決め、5つの観点と記録を残した会社だけが、AIの速さを事故なしで顧客に届けられるのです。

コードに秘密情報を書かない仕組みと、漏れたときの初動は、こちらにまとめました。

▶ APIキーの漏洩対策、制作会社は「書かない仕組み」と「漏れたら止める初動」──Git・.envの置き方、シークレットスキャン、鍵の無効化と再発行

これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。

#Web制作会社 #AI生成コード #コードレビュー #生成AI #セキュリティ対策 #OWASP #制作会社経営 #中小企業 #品質管理 #Web開発