AI生成コードのセキュリティ｜確認点と人の役割
AIが書いたコードは、動くかどうかだけでなく、安全かどうかも確かめる必要があります。この記事では、AI生成コードのセキュリティで起きやすい問題と、開発の中で確認したい7つのポイントを整理します。あわせて、自動チェックで守れる範囲と、人が担うべき役割も説明します。
AI生成コードのセキュリティで、何が問題になるのか
AIコーディングツールは、指示に沿って動くコードを短時間で書いてくれます。ただし、「動く」ことと「安全である」ことは別の話です。AIが生成したコードを、そのまま本番環境に載せてよいとは言えません。
AIは「書かれていない要件」を知らない
AIは、与えられた指示と読み込んだコードの範囲で判断します。「ログインした本人だけが、自分の注文履歴を見られるようにする」という要件が指示に入っていなければ、その確認処理が抜けたコードが出てくることがあります。人が書く場合も同じ抜けは起きますが、AIは出力が速く量も多いため、確認すべきコードの量が一気に増えます。
もっともらしく見えるコードの危うさ
AIが書くコードは、構文も整っていて、コメントも丁寧なことが多くあります。読んだ人が「正しそうだ」と感じやすいのも、注意したい点です。見た目の整い方と安全性は関係がありません。レビューする側は、見た目に引きずられずに、確認の観点を決めて見ていく必要があります。
脆弱性（ぜいじゃくせい）とは
脆弱性とは、攻撃者に悪用されかねないプログラムの欠陥のことです。Webアプリケーションの代表的なリスクは、OWASP（オワスプ）という非営利の国際コミュニティが「OWASP Top 10」としてまとめています。日本では、IPA（情報処理推進機構）が「安全なウェブサイトの作り方」という資料を公開しています。次の章の確認ポイントは、こうした公的・業界団体の整理とも重なる内容です。
開発で確認したい7つのポイント
AIが書いたコードを確認するときに、見落としやすい点を7つに分けて説明します。
1. 入力値の検証とインジェクション
ユーザーが入力した値を、そのままデータベースの命令や画面表示に使うと、攻撃の入口になります。代表的なものが、データベースを不正に操作されるSQLインジェクションと、画面に不正なスクリプトを埋め込まれるクロスサイトスクリプティング（XSS）です。
確認したいのは、次のような点です。
- 入力値を文字列連結でSQL文に組み立てていないか（プレースホルダなどの安全な方法を使っているか）
- 画面に表示する値を、適切にエスケープ（無害化）しているか
- ファイルのアップロードで、種類・サイズ・保存先を制限しているか
2. 認証と認可
認証は「誰であるか」の確認、認可は「その人に何を許すか」の確認です。AI生成コードでは、画面側の制御だけで済ませて、サーバー側の権限チェックが抜けている例が起こり得ます。
OWASP Top 10の2021年版では、アクセス制御の不備が最上位に挙げられています。AIが書いたコードでも、次の点は人の目で確かめます。
- URLのIDを書き換えるだけで、他人のデータが見られないか
- 管理者向けの機能を、一般ユーザーが直接呼び出せないか
- パスワードを、適切な方法でハッシュ化して保存しているか
- セッションやトークンの有効期限が設定されているか
3. 秘密情報の扱い
APIキー、データベースのパスワード、トークンなどの秘密情報が、ソースコードに直接書き込まれてしまうことがあります。動作確認のための仮の値を、そのまま残してしまう場合もあります。
- 秘密情報を、コードではなく環境変数や専用の管理の仕組みで扱っているか
- 秘密情報が、Gitなどの履歴やログに残っていないか
- AIに読み込ませるコードや資料に、秘密情報が含まれていないか
最後の点は、コードの安全性だけでなく、AIツールの使い方の問題でもあります。どの情報をAIに渡してよいかは、開発前にルールとして決めておきます。
4. 依存ライブラリの安全性
AIは、必要な機能を実現するために外部のライブラリ（既存の部品）を使うコードを書きます。このとき、次のような問題が起こり得ます。
- 古く、既知の脆弱性があるバージョンを指定している
- 保守が止まっているライブラリを選んでいる
- 実在しないパッケージ名を提案する
3つ目は、AIが存在しない名前をそれらしく出力する現象に関係します。同じ名前の悪意あるパッケージが公開されていると、気づかずに取り込む危険があると指摘されています。新しい依存関係が追加されたら、名前・提供元・更新状況・ライセンスを人が確認する流れにしておくと安心です。
5. エラー処理とログ
エラーが起きたときの扱いも、見落とされやすい部分です。
- エラーメッセージに、内部の構造やSQL文、ファイルの場所がそのまま表示されていないか
- ログに、パスワードや個人情報が書き出されていないか
- 異常な操作や認証の失敗が、あとから追えるように記録されているか
動作確認のために入れたデバッグ用の出力が、本番に残ってしまうこともあります。
6. データの保護
個人情報や取引情報を扱うシステムでは、データを守る設計が欠かせません。
- 通信が暗号化（HTTPS）されているか
- 保存する情報は、事業に必要な範囲に絞られているか
- 暗号化やハッシュ化に、古く安全でない方式を使っていないか
- データの削除や退会時の扱いが決まっているか
どのデータをどこまで保存するかは、コードの前に「事業としてどう扱うか」を決める問題です。AIに任せきりにせず、人が先に方針を決めておきます。
7. AI機能そのもののリスク
自社のサービスにAI機能を組み込む場合は、コードの安全性とは別のリスクも出てきます。たとえば、ユーザーが入力した文章でAIの指示を書き換えようとするプロンプトインジェクションです。OWASPは、LLM（大規模言語モデル）を使うアプリケーション向けのリスクを「OWASP Top 10 for LLM Applications」としてまとめています。
AIに社内データを参照させる機能や、AIが外部の操作を実行する機能を作る場合は、AIに渡す権限を最小限にします。また、AIの出力をそのまま実行しない設計にします。AIエージェントの権限をOS側で制限する動きについては、MXCが正式版に、AIエージェントの権限をOSで制限でも取り上げています。AIが実サイトで想定外の操作をしたという報告もあり、Claudeが実サイトで想定外の操作、Anthropicが報告で整理しています。
仕組みで守る：自動チェックと開発工程
7つの観点を、人がすべて目で確認するのは現実的ではありません。そこで、仕組みで確認できる部分は機械に任せます。
自動チェックでできること
代表的な仕組みには、次のようなものがあります。
- 静的解析（SAST）：プログラムを実行せずに、コードの書き方から危険な箇所を見つける
- 依存関係のスキャン：使っているライブラリに、既知の脆弱性がないかを調べる
- シークレットスキャン：コードや履歴に、秘密情報が紛れ込んでいないかを調べる
- 自動テスト：認証や権限など、守りたい動作を繰り返し確認する
これらを、コードを変更するたびに自動で動かす仕組み（CI）に組み込んでおけば、AIが書いたコードも、人が書いたコードも、同じ基準で確認できます。
自動チェックだけでは足りない部分
一方で、機械が見つけにくいものもあります。たとえば「この画面で、他の取引先のデータが見えてはいけない」といった業務上のルールは、そのシステムの意図を知る人でなければ判断できません。自動チェックは「よくある欠陥」を見つけるのが得意で、「このサービスで守るべきこと」の確認は人の役割になります。
開発工程に確認を組み込む
セキュリティは、完成後にまとめて確認するより、工程ごとに確認するほうが修正の手間が小さくなります。
- 要件定義：扱うデータの種類と、守る対象を決める
- 設計：認証・認可・データの流れを整理する
- 実装：自動チェックを通し、AIの出力をレビューする
- テスト：権限やエラーなど、攻撃されやすい動作を試す
- 公開前：設定や秘密情報の最終確認をする
米国のNIST（国立標準技術研究所）は、安全なソフトウェア開発の枠組み（SP 800-218）を公開しています。生成AIを使う開発向けの追加の指針（SP 800-218A）もあります。確認項目を整理するときの参考になります。
人が担う役割
AIを使う開発で、人が担う役割は「何を作るかを決めること」と「品質の最終判断」だと、私たちは考えています。セキュリティでは、次の3つに分けて整理できます。
守るべきものを決める
何を守るのか、どこまで守るのかは、AIではなく事業側が決めます。個人情報を扱うのか、決済に関わるのか、取引先ごとのデータを分けて扱うのか。この前提が変わると、必要な対策の水準も変わります。
確認の基準を決める
どの観点で、どこまで確認するのかを、あらかじめ決めておきます。前の章の7つのポイントのように、確認項目を一覧にしておくと、担当者が変わっても確認の質をそろえやすくなります。
最終判断をする
自動チェックの結果とレビューの内容を見て、公開してよいかを判断するのは人です。指摘が残っている場合に、どのリスクを受け入れて、どれを直すのかを決めるのも人の仕事です。品質に人の確認が必要な理由は、AI開発でも品質には人の確認が必要な理由でも詳しく書いています。AIと人の役割分担の全体像は、AI駆動開発とは｜AIと人の役割分担と発注側の要点が参考になります。
新規事業で気をつけたいこと：プロトタイプと本番の間
新規事業では、まず小さく作って確かめる進め方が有効です。この進め方は、新規事業の開発は小さく作って確かめる投資判断の進め方でも整理しています。ただし、セキュリティの面では、検証用のプロトタイプと、実際のお客様が使う本番のシステムを分けて考える必要があります。
検証用のプロトタイプで考えること
事業の仮説を確かめるためのプロトタイプでは、機能の確認が中心になります。それでも、次の点は最初から決めておきます。
- 本物の個人情報や取引データを使わず、ダミーのデータで確かめる
- 試してもらう相手を限定し、公開範囲を絞る
- 秘密情報を、コードに直接書かない
プロトタイプと、MVPやモックとの違いは、プロトタイプとMVP・モックの違いを整理で説明しています。
本番に進む前に追加したい確認
実際のお客様のデータを扱う段階では、確認のレベルを上げます。認証・権限・データ保護の確認、依存ライブラリの点検、公開前の設定確認などです。プロトタイプのコードをそのまま本番に使うのか、作り直すのかも、この時点で判断します。MVPで何を先に作り、何を後回しにするかは、MVP開発の機能の絞り方が参考になります。
稟議や発注の場で確認したいこと
外部の開発会社にAI駆動開発を依頼する場合は、AIの使い方とセキュリティの確認方法を事前に聞いておくと安心です。
- AIが書いたコードを、誰がどの基準でレビューするのか
- 自動チェックを、開発のどの段階で実行するのか
- 顧客データや秘密情報を、AIにどう扱わせているのか
- 公開後の脆弱性の修正は、誰がどう対応するのか
依頼前の確認事項は、AI受託開発に依頼する前に確かめたい6つのことにもまとめています。メリットと注意点を俯瞰したい場合は、AI駆動開発のメリットとデメリットも合わせて参考になります。
まとめ
AIが書いたコードのセキュリティについて、要点は次の通りです。
- AIは動くコードを速く書けるが、安全性や「書かれていない要件」までは保証しない
- 入力検証、認証・認可、秘密情報、依存ライブラリ、エラー処理、データ保護、AI機能のリスクの7点を、確認の基本にする
- 静的解析や依存関係のスキャンなどの自動チェックを工程に組み込み、人が書いたコードと同じ基準で確認する
- 守るべきものを決めること、確認の基準を決めること、公開の最終判断をすることは、人が担う
- 新規事業では、検証用のプロトタイプと本番を分けて考え、本番の前に確認のレベルを上げる
AI駆動開発は、開発のスピードを上げる一方で、確認の仕組みと人の判断がいっそう大切になる進め方です。AIの出力を信じ切るのではなく、確認の観点を決めて確かめる姿勢が、事業の信頼を守ることにつながります。
私たちJustFitは、構想をもとに約1ヶ月で動くプロトタイプを開発し、実物を見てから契約を判断していただく受託開発サービスです。独自の開発基盤「LAF」では、複数の専門AIが工程ごとに役割を分けて開発を進めます。何を作るかの決定と品質の最終判断は人が担い、設計やレビューではLEGAREAの経験と品質基準にもとづいて提案・チェックします。新規事業のシステムをどう作り、どう確かめるかを考える際は、JustFitのサービス紹介もご覧ください。