AI駆動開発のセキュリティ課題とは？企業が最初に整備すべき3つの対策

 AI駆動開発とは、コード生成やテスト、設計検討などの開発工程にAIやAIエージェントを組み込む手法です。開発を効率化できる一方、利用ルールの曖昧さ、AIエージェントの意図しない操作、レビューが追い付かないことによる確認漏れといった新たなセキュリティ課題も生じます。本記事では、企業が優先して整備すべき3つの対策を解説します。 

AI駆動開発のメリットと、セキュリティへの影響

AI駆動開発では、作業の効率だけでなく、人が確認する範囲も変わります。ここでは、開発現場にどのような変化があるのかを紹介します。

設計・実装・検証を効率化し、試行錯誤に時間を使う

AI駆動開発のメリットは、実装の時間を短縮できるだけでなく、設計や仕様を早い段階で試せることです。設計案をコードにして動作を確かめ、問題があれば修正する。この往復にかかる手間が減れば、1つの案を実装するだけで手いっぱいだった開発でも、別の方法を比較する余地が生まれます。開発チームは、手を動かす作業が減った分を、要件の抜けや設計上の懸念を確かめる時間に充てられます。

AIエージェントを使えば、コードの修正、テストの実行、結果を踏まえた再修正までを一連の作業として任せることも可能です。開発者が工程ごとに次の作業を指示する手間を減らせます。

AIに任せる仕事が増えると、セキュリティの確認も変わる

AI駆動開発では、AIが生成したコードだけでなく、AIが作業する環境も確認の対象になります。従来の開発でも権限管理やコードレビューは必要でした。しかし、人が都度判断していた作業をAIエージェントに任せる場合は、参照してよい情報、実行できる操作、人の承認が必要な場面をあらかじめ決め、設定に反映する必要があります。

そのため、AIエージェントには開発者が持つ権限をそのまま渡すのではなく、任せる作業に必要な範囲へ絞ることが重要です。

AI駆動開発で注意すべきセキュリティ課題

AI駆動開発への関心が高まる一方、実際に使う中で見えてくる課題もあります。ここでは、開発現場でどのような問題が起こり得るのか、具体例を挙げて説明します。

AIを使ってよい範囲と利用条件が曖昧なままになっている

AIツールの利用を許可するだけでは、現場が迷わず使える状態にはなりません。機密情報を含むソースコードを入力してよいか、外部連携機能を有効にしてよいかなど、実際の作業では個別の判断が発生します。情報の保存先や学習への利用、ログの扱いは、ツールの契約や設定によって異なります。これらを踏まえた利用条件が決まっていなければ、同じツールでもチームごとに判断が分かれます。

また、利用開始時に条件を確認していても、機能の追加や設定変更によって、扱うデータや外部接続の範囲が変わる場合があります。どのような変更時に利用条件を再確認するかが決まっていなければ、当初は想定していなかった使い方を見落とすおそれがあります。通常の利用条件から外れる場合についても、確認すべき事項や、例外を認める条件を整理しておく必要があります。

AIエージェントが意図しない操作や外部接続を行うおそれがある

AIエージェントは、指示や作業状況を誤って解釈し、依頼した範囲を超えて操作するおそれがあります。例えば、コードの一部を修正するつもりが、関連する設定まで変更したり、調査に不要なデータを取得したりする場合があります。また、参照した文書などに埋め込まれた不正な指示によってAIエージェントが誘導される「プロンプトインジェクション」のリスクもあります。悪意ある攻撃だけでなく、通常の作業でも意図しない動作が起こり得る点に注意が必要です。

意図しない動作の影響は、エージェントが使える権限や接続先によって変わります。修正案の作成にとどまる場合と、本番環境の変更まで可能な場合では、同じ判断の誤りでも影響は異なります。AIと外部ツールやデータをつなぐMCP（Model Context Protocol）などを利用する場合も、連携先で使える権限が広ければ、不要な情報の取得や外部送信につながるおそれがあります。

コードはできても、品質と安全性の確認が追い付かない

AIが生成したコードやテストが増えると、人によるレビューが開発のボトルネックになり得ます。実装が短時間で終わっても、担当者が変更内容を読み、妥当性を確かめるには時間がかかります。既存の人数と手順では確認が追い付かず、レビュー待ちや確認漏れが生じるおそれがあります。実装の時間を短縮できても、開発全体にかかる時間が同じように減るとは限りません。

また、レビューを急いで済ませれば、認可の漏れや入力検証の不備などを見落とすおそれがあります。こうした問題は、コードが動くことを確かめるだけでは見つけにくいものです。開発者やレビュー担当者の負担を増やして対応するにも限界があるため、AIによる生成の量と速さに合わせて、従来の確認方法を見直す必要があります。

企業は何から整備すべきか

AIの利用範囲や利用条件の曖昧さ、意図しない操作、レビューの負担に対して、企業はどのように対応すればよいのでしょうか。ここでは、対策の考え方と具体的な整備の進め方を紹介します。

組織共通の考え方と、ツール別の使い方をガイドラインにまとめる

AIツールやAIエージェントを組織で利用するにあたり、リスクに対する共通の考え方と、具体的なツールの使い方をガイドラインにまとめます。「機密情報を適切に扱う」といった方針だけでは、利用者はどの情報を入力してよいか、どの機能を使ってよいか判断できません。

一方、設定手順だけを示しても、その設定が必要な理由や、想定外の場面での判断基準は伝わりません。このため、「組織共通のリスクガイドライン」と「ツール別ガイドライン」に分けて整備します。

組織共通のリスクガイドラインでは、利用者が知っておくべきリスクと、利用を認める条件を整理します。情報漏洩や意図しない操作などのリスクを説明し、扱ってよい情報、AIに任せる範囲、判断に迷った場合の相談先を示します。利用者だけでなく、承認や管理を担う部門も同じ基準で判断できる内容にします。

ツール別ガイドラインでは、共通の考え方を実際の設定や手順に落とし込みます。対象のツールを明示し、データの保存・学習利用、権限、外部接続、操作の承認などについて、推奨する設定と確認方法をまとめます。ツールの機能や設定項目は更新されるため、ガイドラインも定期的に見直します。

特に、新機能の追加や権限・データの扱いに関わる変更があった場合は、定期見直しを待たずに影響を確認し、必要に応じて設定とガイドラインを更新します。

AIエージェントは指示だけに頼らず、権限と接続先を絞って動かす

AIエージェントの動作は、指示と実行環境の制御を組み合わせて管理します。指示ファイルには役割、禁止事項、判断できる範囲、参照情報の扱いを記載します。ただし、指示が常に守られるとは限りません。ファイルや認証情報へのアクセス、外部接続を必要な範囲に絞り、AIが判断を誤っても影響を抑えられるようにします。

組織のルールを動作に反映するため、指示ファイルやスキル、ツール設定、実行前後のチェックを組み合わせたハーネスを整備します。既存の開発規約やセキュリティ要件を基に、設計・コーディング・テストで参照するルールや、定型作業の手順を具体化します。

その際、文章で伝える事項と、設定で制限する事項を分けます。例えば、MCPの連携先は、提供元、要求する権限、送信するデータを確認して登録し、許可した操作だけを使えるようにします。整備後は実際の作業で試し、指示や設定が意図どおりに働くかを確かめます。

実行環境では、ハーネスの指示や設定だけでは防ぎきれない動作に備えます。サンドボックスによる隔離や、外部への通信の接続先制限・監視などが対策の例です。本番環境への書き込み、データの削除・上書きといった破壊的な操作は、実行基盤側で禁止するか、人の承認が必要な経路に分けます。監視で異常に気付くだけでなく、不要な操作や通信を制限できる構成にします。

実行の記録は、問題が起きたときに原因を調べられるように残します。利用したツールや設定のバージョン、実行した操作、接続先、実行結果を記録し、変更や承認の記録と紐付けます。また、ログに含まれる情報に応じて、閲覧権限と保存期間も定めます。

自動検査とAIの分析を使い分け、人が判断すべき変更を確かめる

AIが生成したコードの量と開発の速さに対応するには、人がすべての変更を確認する従来の方法を見直す必要があります。決まった基準で判定できる項目は自動検査に任せ、検査結果の整理や修正案の検討にはAIを使います。そのうえで、設計の妥当性や業務への影響など、人の判断が必要な変更にレビューの時間を充てます。

自動検査は既存のCI/CDに組み込み、変更を取り込む前に満たすべき条件を決めます。コードの静的解析、依存ライブラリの脆弱性確認、秘密情報の混入検知、テストなどが対象です。コードだけでなく、構成ファイルやインフラ設定、ライブラリのライセンスも、変更内容に応じて確認します。AIが「問題なし」と回答しても、必須検査で不合格となった変更をそのまま通さない仕組みにします。

AIは、検査結果を読み解き、レビューに必要な情報を整理するために使います。差分の要約、変更が影響する箇所の調査、修正案の作成などを任せれば、担当者が調査や読み込みにかける手間を減らせます。ただし、AIの説明だけで採用を決めず、参照したコードや検査結果を確認できるようにします。

自動検査・AI・人の役割分担

人のレビューは、変更の大きさではなく、影響に応じて行います。数行の修正でも、認可や個人情報の扱い、外部公開の範囲を変える場合は、詳しい確認が必要です。AIが生成したテストも、実装と同じ誤った前提で作られていないか、要件に照らして確かめます。変更内容、検査結果、未確認事項をそろえ、誰が何を根拠に承認したかを記録します。

検査やAIの分析が止まった場合も、確認を省いて処理を進めないようにします。必須検査が未実行なら保留し、手動確認へ切り替える条件や例外の承認者、適用期限をあらかじめ決めておきます。導入後は、レビュー待ちや差戻しの理由を確認し、自動検査やAIに任せる範囲を調整します。

まとめ

弊社では、AI駆動開発のセキュリティ対策として、以下の4つの支援メニューを提供しています。本記事で紹介した利用ルールやハーネス、開発プロセスの整備に加え、脆弱性対応へのAI導入も支援します。今後も支援内容を拡充する予定です。

• AIエージェント利用に関するガイドライン整備支援
• セキュアなAIエージェントハーネスの整備・内製化支援
• AI組込型 セキュア開発プロセス設計構築支援
• 脆弱性トリアージ AI自動化支援

各メニューの詳細は、サービスページをご覧ください。自社の利用ルールや開発プロセスの整備についてお困りの方も、同ページからお気軽にご相談ください。

AI駆動開発向けセキュリティ支援サービス | NRIセキュア

• また、AI駆動開発のセキュリティ対策に関するセミナーを開催します。ご興味のある方は、下記セミナーページからお申し込みください。

•