生成AIにコードを書かせる開発が広がるなかで、「AIが書いたコードに脆弱性が混ざっていないか」という不安を持つ担当者は少なくありません。実際、AIは学習したコードの傾向を再現するため、安全でない書き方もそのまま出力することがあります。
一方で、AIを使わない開発に脆弱性がないわけではありません。問われるのは、混入しうる欠陥を、どの工程で、誰が、どう見つけるかという設計です。
この記事では、AI駆動開発を検討している、あるいは外部に開発を委託しているBtoB企業の担当者に向けて、AIが関わる開発で起きやすい脆弱性の種類、発注側が確認すべきこと、検証の進め方を整理します。
AI開発で脆弱性が混入する3つの経路
AIが関わる開発では、脆弱性の入り口が従来より増えます。まず、どこから混入するのかを分けて捉えます。
| 経路 | 何が起きるか | 気づきにくさ |
|---|---|---|
| 生成されたコード自体 | 入力値の検証漏れ、権限確認の欠落、古い暗号方式の使用など、安全でない書き方がそのまま出力される | 動作はするため、テストが通ってしまうことがある |
| 提案された依存ライブラリ | 古いバージョンや、保守が止まったライブラリが提案される。実在しない名前が提案されることもある | 名前が妥当に見えるため、確認せず導入されやすい |
| AIを組み込んだ機能そのもの | 利用者の入力でAIの動作を乗っ取られる、学習・参照データから機密情報が引き出される | 従来のテスト項目に存在しないため、見落とされやすい |
最初の2つは「AIを開発の道具として使う」場合の話です。3つ目は「AIを製品の機能として組み込む」場合に固有の論点で、性質が大きく異なります。自社の案件がどちらなのかを最初に区別してください。
AIが書いたコードで起きやすい欠陥
生成AIは、学習したコードに多く現れる書き方を再現します。そのため、広く出回っている不適切な実装も再現されることがあります。実務で確認する機会が多いのは次のような点です。
- 入力値の検証が不足している（文字数、型、想定外の値の扱い）
- データベース操作で、値を文字列として直接つなげている
- 画面に出力する値のエスケープが抜けている
- 処理の実行前に、その利用者に権限があるかを確認していない
- エラー時に、内部の構造が分かる情報をそのまま返している
- 認証情報や接続先がコードに直接書かれている
いずれも従来の開発でも起こる欠陥です。AI特有なのは、短時間で大量のコードが生まれるため、同じ欠陥が複数箇所に広がりやすいことです。1箇所の見落としが、横展開されたコピーの数だけ残ります。
依存ライブラリに関する注意点
AIは、存在しないライブラリ名を、もっともらしい形で提案することがあります。攻撃者がその名前を先回りして登録し、悪意あるコードを配布する手口が報告されています。提案されたライブラリは、名前が妥当に見えても、公式の配布元と更新状況を必ず確認してください。
AIを組み込んだ機能で特に注意する点
自社の製品やサービスにAIを組み込む場合、従来のWebアプリケーションにはなかった論点が加わります。
| 論点 | 想定される問題 | 対応の方向 |
|---|---|---|
| 利用者の入力による動作の変更 | 入力文に指示を紛れ込ませ、本来の制約を外させる | AIの出力を信頼せず、実行する処理の側で権限と範囲を制限する |
| 参照データからの情報漏れ | 社内文書を参照する仕組みで、権限のない情報まで回答に含まれる | 検索の段階で利用者の権限に応じて対象を絞る |
| 出力をそのまま処理に渡す | AIの出力をコードやコマンドとして実行し、意図しない動作を招く | 出力は必ず検証を通す。自動実行の範囲を限定する |
| 外部サービスへの送信内容 | 入力された情報が、意図せず外部のAIサービスへ送られる | 送信前の除去ルールと、学習利用の有無を契約で確認する |
これらは、コードの書き方を直すだけでは防げません。機能の設計段階で、AIに何を任せ、何を任せないかを決める必要があります。
発注側が開発会社に確認すべきこと
開発を外部に委託する場合、「AIを使っています」という説明だけでは、品質を判断できません。次の観点で確認すると、実態を把握しやすくなります。
| 確認すること | 望ましい回答 | 注意したい回答 |
|---|---|---|
| AIを使う工程と、人が担う工程 | 工程ごとに役割が分かれており、レビューの担当が決まっている | 「全部AIでやります」「適宜確認します」 |
| 生成コードのレビュー方法 | 観点が定義され、セキュリティの確認項目が含まれる | 「動作確認はします」のみ |
| 自動検査の仕組み | 静的解析や依存ライブラリの脆弱性検査を、継続的に実施している | 検査の仕組みに触れない |
| 依存ライブラリの扱い | 導入前に配布元と更新状況を確認する手順がある | 「提案されたものを使います」 |
| 入力した情報の扱い | どのツールへ何を入力するか、学習利用の有無が説明できる | 使っているツール名を答えられない、契約条件を把握していない |
| 納品後の脆弱性対応 | 対応範囲と期間、費用の扱いが契約で決まっている | 納品で終わり、以降は都度見積もり |
検証の進め方
脆弱性の確認は、開発の最後にまとめて行うより、工程ごとに分けたほうが手戻りを抑えられます。
- 要件の段階：扱う情報の種類と、守るべき範囲を決める。AIを機能として組み込む場合は、任せる範囲と人が承認する箇所をここで決める。
- 実装の段階：静的解析と依存ライブラリの検査を、コードの変更ごとに自動で走らせる。
- レビューの段階：人が確認する観点を定義しておく。特に権限確認、入力値の検証、出力のエスケープは、AI生成コードで抜けやすい。
- 受け入れの段階：合意した基準を満たしているかを確認する。基準は検証を始める前に決めておく。
- 公開後：依存ライブラリの新たな脆弱性情報を継続して確認し、更新の体制を決めておく。
自動検査は有効ですが、万能ではありません。権限設計の誤りや業務ロジックの抜けは、機械的な検査では見つかりません。自動検査と人のレビューは併用するものです。
よくある質問
Q. AIを使わなければ安全ですか？
いいえ。脆弱性は従来の開発でも発生します。AIの利用で変わるのは、生まれるコードの量と速度、そして依存ライブラリの選定経路です。確認の仕組みがあるかどうかが、安全性を左右します。
Q. 自動検査ツールを入れれば十分ですか？
不十分です。静的解析は既知のパターンを検出しますが、権限設計の誤りや業務上の判断ミスは検出できません。人によるレビューの観点を別に定義してください。
Q. 社内に専門知識がない場合はどうすればよいですか？
まず、委託先に確認する項目を決めるところから始められます。本記事の確認表は、専門知識がなくても使える形にしています。そのうえで、受け入れ時の検証を第三者に依頼する選択肢もあります。
まとめ
- 脆弱性の混入経路は「生成コード」「依存ライブラリ」「AIを組み込んだ機能」の3つに分けて捉える
- AIを道具として使う場合と、製品の機能として組み込む場合では、必要な対策が異なる
- AI生成コードでは、権限確認・入力値の検証・出力のエスケープが抜けやすい
- 同じ欠陥が複数箇所へ広がりやすいため、1箇所の見落としの影響が大きい
- 委託先には、工程ごとの役割分担、レビュー方法、自動検査、情報の扱い、納品後の対応を確認する
- 自動検査と人のレビューは併用する。どちらか一方では防げない
開発のご相談は無料相談から
ハイ・ヴァーチュ・ラボは、AI駆動開発・システムインテグレーション・マーケティングを一気通貫で提供するテクノロジーパートナーです。プロジェクトの立ち上げから収益化まで、すべての工程を網羅しています。
「AIを使った開発を検討しているが、品質の担保が不安」「既存システムの脆弱性を確認したい」という方は、まずはご相談ください。現在の状況と目的を伺いながら、確認すべき範囲と進め方を整理します。