AIが生成したコードには厄介な特徴がある。一見すると正しく動作しているように見えることだ。

　コンパイルに成功し、テストを通過したとしても、それだけで安全とは限らない。例えば、AIが顧客情報をデータベースから取得するサービスを生成し、期待通りに動作していたとしても、そのサービスが顧客データ全体にアクセスできる設計になっていれば、過剰な権限を持つ可能性がある。

　クルム氏は、AIが生成したコードについて、生成されたこと自体ではなく「結果を信頼できるかどうか」を確認することが重要だと述べる。

　クルム氏によると、確認すべきなのは「コードが期待通りの結果を返すか」だけではない。過剰な権限が付与されていないか、機密情報が外部へ流出する可能性はないか、認証に失敗した場合に安全な状態へ移行できるかといった点も検証する必要がある。

　クルム氏は、技術的に正常に動いているように見えても、それが安全なシステムであることを意味するわけではないと指摘する。実際の利用環境でも期待した処理をし、かつ安全に振る舞うかどうかまで確認する必要があるという。

原則2．セキュリティ確認を開発の最後に回さない

　従来、セキュリティレビューを開発工程の終盤に実施する組織もあった。例えば、実装やテストを終え、コードの変更内容をバージョン管理システムに記録した後でセキュリティレビューを実施する、といった進め方だ。しかしクルム氏によると、AIが数秒でコードを生成する環境では、開発の最後にまとめてセキュリティ確認を実施する方法がボトルネックになりやすい。

　クルム氏は、従来のようにセキュリティレビューを開発の最後のチェック項目として扱う方法は、AI支援開発ではさらに機能しにくくなると説明する。問題を早い段階で発見するほど、修正に必要なコストも抑えやすいためだ。

　そこで重要になるのが「シフトレフト」だ。セキュリティ確認を開発工程の前段階へ移し、コードを作成している途中から継続して検証する。

　具体的には、静的コード解析、ペネトレーションテスト、コードに埋め込まれたシークレットの検出、ポリシーやコンプライアンスの確認などだ。これらをコード生成後にまとめて実施するのではなく、開発プロセスそのものに組み込むことが重要だとクルム氏は強調する。

　AIによってコード生成を高速化するのであれば、それに合わせてセキュリティ検証も開発フローの中で実施できる体制が必要になる。

原則3．生成コードだけでなく「依存先」も調べる

　AIが生成するのはソースコードだけではない。新しいパッケージやライブラリ、外部サービス、システム連携などを利用するコードを生成する場合もある。

　開発者がAIの生成したソースコードだけをレビューすると、その裏側で追加された依存関係を見落とす可能性がある。クルム氏は、AIはコードと同時にさまざまな依存関係も持ち込むと指摘する。新しい依存関係は機能を増やす一方で、それぞれが新たなリスクにもなり得る。

　そのため、AIが追加した依存関係についても、生成コードと同じ水準で確認する必要がある。

　クルム氏は、確認項目としてパッケージの信頼性、既知の脆弱（ぜいじゃく）性、ライセンス、ソースの完全性、組織内の標準への適合状況などを挙げる。AI支援開発では、依存関係の検証も安全なコード生成の一部として扱う必要があるという。

　AIコーディングツールを全社展開する場合、情シスやセキュリティ担当者は「どのAIツールを利用できるか」だけでなく、AIが生成コード内でどの外部ライブラリやサービスを利用してよいのかというルールも検討する必要がある。

原則4．コードではなく「要求が正しいか」も確認する

　セキュリティに関する問題は、プログラムの書き方だけに起因しているわけではない。そもそもの要求や前提が間違っている場合もある。

　例えば「誰がデータにアクセスできるのか」「どの操作まで許可するのか」「どの情報を保護する必要があるのか」といった条件が曖昧なままAIにコードを生成させれば、技術的には正しくても、企業のセキュリティポリシーに反するシステムができる可能性がある。

　クルム氏は、深刻なセキュリティ問題の中には、コーディングの品質ではなく「誤った前提」によって生じるものもあると指摘する。例えば財務データを正しく処理するワークフローをAIが生成しても、本来は閲覧できない利用者にデータを公開する設計なら、安全とは言えない。

　この場合、問題はコードの実装方法というより、AIに何を実現させようとしたのかという「意図」にある。クルム氏は、AIが高度なコードを高速に生成できるようになるほど、開発者には生成結果を検証する責任が増すと説明する。確認対象はコード品質だけではなく、AIが「正しい問題を、正しい方法で解決したかどうか」にまで広がるという。

原則5．リリース後も継続して検証する

　セキュリティ確認はリリース時に終わるものではない。

　AI支援開発ではコードや構成の変更が継続的に発生する。そのためセキュリティ検証も、「開発→テスト→デプロイ→監視→改善」という一連の工程で継続して実施する必要がある。

　クルム氏は、AI支援開発が継続的に変化を生み出す以上、セキュリティ検証も継続的に実施しなければならないと強調する。リリース後も含め、開発ライフサイクル全体で安全性を確保する必要があるという。

　具体的には、脆弱性の検出、依存関係の監視とパッチ適用、ポリシーの検証と適用、変更内容の確認などが対象になる。

　クルム氏は、一度セキュリティチェックに合格したかどうかではなく、その後も安全な状態を維持できているかが重要だと説明する。ソフトウェアが変化し続ける以上、セキュリティもそれに合わせて変化する「継続的な活動」にする必要があるという。

AIエージェント時代は「コード単体」の確認では足りない

　この問題は、AIエージェントの活用が進むほど複雑になる。

　AIエージェントは複数のサービスやコードリポジトリ、開発パイプライン、設定をまたぎ、複数工程の処理を実行する。その場合、個々のファイルだけをレビューしても、システム全体の安全性を把握できない可能性がある。

　クルム氏は、AIがよりエージェント的に動作するようになれば、個々のファイルを見るだけでは十分ではなく、ワークフロー全体を理解する必要があると指摘する。セキュリティ上の難しい問題は、単一の関数の中ではなく、複数のシステムを接続した結果として生じる場合があるためだ。

　その対策としてクルム氏は、AIエージェントが何を実行してよいのかを定めるガードレール、実行主体を追跡するためのID、操作可能な範囲を制限するアクセス制御、監視、人による確認を挙げる。

　適切な監督や制御がなければ、AIエージェントは生産性を高める手段ではなく、リスクを増幅させる存在になり得るとクルム氏は警告する。

　生成AIによって開発できるコードの量が増えれば、機能だけでなくシステムの複雑性も増す。そこでクルム氏は、セキュリティ対策をリリース直前の確認作業や、コンプライアンス対応のための形式的なチェックとして位置付けるのではなく、日常の開発ワークフローに継続的な検証として組み込む必要があると説明する。

　クルム氏の説明からは、情報システム部門や開発部門に求められるのは、AI生成コードを最後にまとめてレビューする体制ではないことが分かる。AIがコードを生成する速度に合わせて、要求定義や設計の段階からリリース後まで、安全性を継続的に確認できる仕組みを開発プロセスそのものに組み込むことだ。

本稿は、IBM Technologyが2026年9月14日に公開したHow Developers Secure AI-Generated Code：5 Security Best Practicesを基に作成しました。