2026.11.01
AIセキュア開発で守る生成AI時代の開発現場
IT関連
AIセキュア開発は、生成AIで開発速度を高めながら、コード・データ・権限に生じる新しい攻撃面を管理する取り組みです。便利な提案をそのまま採用するだけでは、安全なリリースは実現できません。
AIコーディング支援や自律型エージェントは、実装からテスト、修正案の作成までを加速します。一方で、不適切な入力値処理、漏えいしたシークレット、脆弱な依存関係が短時間で本番環境へ入り込む可能性もあります。
本記事では、AI利用ルール、エージェントの実行環境、DevSecOps、脆弱性トリアージ、監査と復旧までを順に整理します。開発・セキュリティ・法務・経営が同じ基準で判断できる実務的な設計を目指します。
AIセキュア開発で最初に管理すべきリスク
生成コードはレビュー前提で扱う
結論として、AIが生成したコードは信頼できる部品ではなくレビュー対象として扱うべきです。もっともらしい実装でも、例外処理や境界値、認可判定が省略されている場合があり、動作確認だけでは問題を見逃します。
特に確認したいのは、入力値の検証、SQLやコマンドの組み立て、認証後の認可、エラーメッセージです。機能要件を満たすコードと、攻撃に耐えるコードは同義ではないため、レビュー観点を分けて残すことが重要です。
実務では、プルリクエストに「AI支援の利用有無」と確認済み項目を記録します。人間のレビュアーが変更理由と影響範囲を説明できる状態にすれば、AIの提案を活かしつつ責任の所在を曖昧にしません。
- 入力値・出力値の境界条件をテストする
- 認証と認可を別々に確認する
- 例外時に機密情報を返さない
AIに渡す情報を分類する
結論として、プロンプトへ入力できる情報はデータ分類ごとに許可する必要があります。ソースコード、顧客情報、認証情報、障害ログを同じ基準で扱うと、外部サービスへの意図しない送信が起こり得ます。
最低限、公開可能、社内限定、機密、最重要機密のように区分し、AIツールごとの利用可否を定めます。顧客識別子、アクセストークン、秘密鍵、未公表の脆弱性情報は、原則として入力禁止にする判断が安全です。
さらに、プロンプト、応答、添付ファイルの保存先と保持期間を確認します。モデル学習への利用可否、管理者によるログ閲覧権限、国外移転の有無を契約条件と照合し、例外利用には承認記録を残します。
- 秘密鍵とトークンは入力しない
- ログの保存場所と保持期間を確認する
- 例外利用は承認者と期限を記録する
AIそのものへの攻撃を想定する
結論として、AI機能を製品へ組み込む場合は、通常のWeb脆弱性に加えてプロンプトインジェクションを脅威モデルへ入れます。悪意ある文書やWebページの指示によって、エージェントの行動が誘導される可能性があります。
対策は、ユーザー入力とシステム指示を論理的に分離し、モデル出力を命令として無条件に実行しないことです。外部データを参照するRAG構成でも、取得文書を信頼済み命令として扱わない設計が欠かせません。
学習データ汚染や敵対的入力も、精度だけでなく安全性に影響します。モデル更新時は通常テストに加え、権限逸脱、情報抽出、不正操作を試すレッドチーム評価を行い、合格基準を文書化します。
- モデル出力を直接実行しない
- 外部文書を命令として扱わない
- 更新ごとに安全性を再評価する
AIセキュア開発の利用ルールと責任分担
利用ガイドラインは現場の判断を支える
結論として、利用ルールは禁止事項の列挙ではなく、現場が迷わず判断するための基準です。AIエージェント利用に関するガイドライン整備支援のように、対象業務、入力可能な情報、承認が必要な操作を具体化します。
ルールには、利用できるモデルと契約プラン、許可されたリポジトリ、レビュー必須の変更種別を含めます。実装支援だけでなく、設計書の要約やテスト案の作成など、用途ごとにリスクと許容範囲を整理すると運用しやすくなります。
例外をゼロにするより、例外申請の窓口、承認者、有効期限、見直し条件を定める方が実効性は高まります。緊急対応時にも記録を残すことで、後からの監査や原因分析に必要な証跡を確保できます。
- 用途別に許可範囲を定義する
- 例外の期限と承認者を明確にする
- ルール改定の責任者を置く
役割分担で承認の抜け漏れを防ぐ
結論として、AI利用の安全性は開発部門だけでは完結しません。開発者は実装とレビュー、セキュリティ担当は脅威分析、法務は契約・知的財産、経営はリスク受容と予算判断を担う形が現実的です。
たとえばAIエージェントにデプロイ権限を与える場合、開発責任者の必要性判断だけでは不十分です。権限設計、監査ログ、ロールバック手順をセキュリティ担当と確認し、事業影響を管理者が承認する流れを作ります。
RACIのような責任分担表を用いると、実行者、最終責任者、相談先、通知先が見えます。チケットに承認記録を連携させれば、属人的な口頭確認に依存せず、変更の追跡性も高められます。
- 開発者は変更内容を説明する
- セキュリティ担当は統制を確認する
- 経営者は許容リスクを承認する
来歴管理で説明可能性を確保する
結論として、AI支援で作られた成果物は、誰が何を根拠に変更したかを追えるようにします。コードの出所、利用モデル、主要プロンプト、レビュー履歴を変更記録へ結び付けることが出発点です。
依存ライブラリについてはSBOMを生成し、名称、バージョン、ライセンス、取得元を管理します。AIが提案したパッケージを安易に追加すると、既知の脆弱性やライセンス条件を見落とし、後の調査範囲が広がります。
署名付きコミット、保護ブランチ、変更チケットの紐付けを組み合わせると、改変検知と監査の両方に役立ちます。成果物の来歴をCI/CDで自動収集し、手作業の記録漏れを減らす設計が有効です。
- モデルとプロンプトの利用記録を残す
- SBOMで依存関係を可視化する
- コミットと承認チケットを結び付ける
AIセキュア開発を支えるエージェント実行環境
最小権限とサンドボックスを基本にする
結論として、AIエージェントには必要最小限の権限だけを、短い有効期間で付与します。読み取り専用のコード解析と、本番環境を変更するデプロイ操作を同じ資格情報で行わせる設計は避けるべきです。
セキュアなAIエージェントハーネスの整備・内製化支援では、ツール呼び出し、認証、ネットワーク接続、ログ取得を一元管理します。エージェントを隔離したサンドボックスで動かせば、誤操作や悪意ある指示の影響範囲を限定できます。
シークレットはソースコードやプロンプトに埋め込まず、専用のシークレット管理機構から実行時に取得します。権限昇格や外部送信を検知できる監査ログを残し、異常時は即座にトークンを無効化できるようにします。
- 実行権限は用途別に分離する
- 資格情報は短期化して保管する
- ネットワーク送信先を制限する
自動変更には承認ゲートを置く
結論として、エージェントがコード変更やデプロイを行う場合、重要操作の前に人間による承認ゲートを設けます。自動化の目的は承認をなくすことではなく、判断に必要な情報を短時間で揃えることです。
小規模チームでは、AIが作成したプルリクエストを担当者がレビューしてからマージする方式が始めやすいでしょう。運用が成熟した後も、本番設定、権限変更、データ削除は別承認にすることが重要です。
変更後はカナリア運用で限定的にリリースし、エラー率や不審なアクセスを監視します。異常が出たときに即時ロールバックできるよう、デプロイ手順と復旧責任者を事前に明文化しておきます。
- 本番変更は二者承認にする
- 段階的リリースで影響を限定する
- ロールバックを定期的に演習する
外部公開資産を継続監視する
結論として、守るべき対象はリポジトリだけではありません。公開API、クラウドストレージ、コンテナイメージ、DNS設定など、攻撃者から見える資産を継続的に把握することが必要です。
脅威インテリジェンスと外部公開アセットの監視を組み合わせると、新たな脆弱性が自社環境に関係するかを早く判断できます。AIは大量の通知を要約できますが、影響判定の根拠は人間が確認します。
2026年10月には、IDCフロンティアがランサムウェアで495社に影響を与え、ヤマト運輸で約526万件の情報が流出しました。外部委託先や接続先を含む監視と、連絡網の整備が不可欠です。
- 公開資産の棚卸しを継続する
- 委託先を含めて影響範囲を確認する
- 通知の優先度を人間が検証する
AIセキュア開発をCI/CDと検査へ組み込む方法
検査は開発工程ごとに自動化する
結論として、セキュリティ検査はリリース直前だけでなく、要件・設計からCI/CDまで継続して実施します。AI組込型 セキュア開発プロセス設計構築支援の考え方は、手戻りを小さくしながら安全性を組み込む点にあります。
コミット時には秘密情報の検出とSAST、ビルド時にはSCA、テスト環境ではDASTを実行します。各ツールの結果を一か所に集約すると、同じ問題の重複通知を減らし、修正担当者へ適切に割り当てられます。
ただし、検査ツールの導入だけで安全になるわけではありません。ブロックすべき重大度、期限内に直すべき問題、例外を認める条件を決め、パイプラインの判定基準としてコード化する必要があります。
- SASTでコードの欠陥を検出する
- SCAで依存関係を確認する
- DASTで稼働時の挙動を検証する
検出結果は影響度でトリアージする
結論として、検出件数の多さではなく、悪用可能性と事業影響で修正順を決めます。脆弱性トリアージ AI自動化支援は、通知の要約や関連情報の収集を速め、人間の判断を支援する用途に適しています。
優先順位では、外部公開の有無、攻撃経路、権限、機密データへの到達可能性、代替策を確認します。CVSSだけで機械的に処理せず、自社の利用実態と資産価値を加えた判断を行うことが重要です。
2026年1〜9月には454件で前年同期比+49%という状況も踏まえ、未対応の通知を放置しない運用が求められます。担当、期限、対応方針、例外理由をチケットに残し、経営層へ定期的に報告します。
- 外部公開と悪用可能性を先に見る
- 担当者と修正期限を必ず割り当てる
- 例外は根拠と期限を残す
修正後の再確認までを完了条件にする
結論として、AIが提案した修正パッチは、適用後の再スキャンと回帰テストを通るまで完了ではありません。修正で別の認可不備や性能劣化を生むことがあるため、原因と影響範囲の両方を検証します。
再現用テストを追加すれば、同じ脆弱性が将来の変更で戻ることを防げます。重大な問題では、ユニットテスト、統合テスト、動的検査、手動レビューを組み合わせ、攻撃シナリオが成立しないことを確認します。
品質・セキュリティ検証への配分を後回しにしないことが重要です。セキュリティ予算の不足を認識する企業は63.2%で、「1〜5%未満」が最多という状況でも、修正確認の工程を削る判断はリスクを増やします。
- 修正内容を再スキャンする
- 脆弱性の再発テストを追加する
- 例外後も期限で再評価する
導入を定着させる監査とインシデント対応
小さく始めて統制を広げる
結論として、全社一斉導入よりも、限定したリポジトリと用途で検証を始める方が成功しやすい方法です。まずはAI支援によるコード作成、レビュー、脆弱性要約など、権限の弱い作業から対象を選びます。
検証期間中は、レビュー時間、検出件数、修正までの時間、誤検知、開発者の負担を記録します。AIの利用有無ではなく、品質と安全性が改善したかを測ることで、次の投資判断を客観化できます。
ALION株式会社のように国境を超える専属チームで開発を進める体制では、時差や委託範囲を踏まえた承認設計も必要です。共通のチケット、ソース管理、監査ログを使い、確認プロセスを標準化します。
- 対象リポジトリを限定して始める
- 改善指標を導入前から記録する
- 委託先を含めた承認経路を作る
監査記録を運用改善に生かす
結論として、監査ログは問題発生後の追跡だけでなく、日常の統制改善に使うべきです。誰がどのモデルを利用し、どのツールが何の権限で実行されたかを、変更単位で確認できる状態を整えます。
ログには、AIへの入力そのものを無制限に保存するのではなく、機密性に配慮した要約や参照IDを用います。閲覧権限、改ざん防止、保持期間を定め、個人情報や営業秘密を二次的に漏えいさせない設計が必要です。
定期レビューでは、例外申請の増加、失効しない権限、未修正の高リスク問題を確認します。監査結果を開発者の評価だけに使わず、ルールやツール設定を改善する材料として共有することが大切です。
- 操作と権限の対応を記録する
- ログ自体の機密性も保護する
- 例外と未対応事項を定期点検する
事故時は停止・保全・説明を並行する
結論として、AI関連の事故では、影響拡大の停止、証跡保全、関係者への説明を並行して進めます。疑わしいエージェントや連携機能を止め、アクセスキーやトークンを無効化し、変更履歴とログを保全します。
次に、漏えい範囲、実行された操作、影響を受けた顧客やシステムを確認します。モデルの誤作動なのか、プロンプトインジェクションなのか、資格情報の流出なのかを切り分け、復旧前に根本原因を検証します。
顧客や経営層への説明では、判明した事実、未確定事項、実施済みの封じ込め、次回報告時刻を区別します。事前に連絡先と判断基準を含む対応計画を演習しておけば、緊急時の混乱を小さくできます。
- AI機能と資格情報を速やかに停止する
- ログと変更履歴を改ざん前に保全する
- 事実と推測を分けて報告する
まとめ
AIセキュア開発は、AIを禁止するための活動ではありません。生成コードとエージェントの能力を活用しながら、入力データ、最小権限、検査、承認、証跡、復旧を一つの開発プロセスとして設計する取り組みです。
要点
- AI生成コードは必ず人間がセキュリティ観点でレビューする
- AIエージェントはサンドボックスと最小権限で運用する
- SAST・SCA・DASTをCI/CDに組み込み、修正後も再確認する
- 例外申請、監査記録、事故対応までを運用設計に含める
- 小規模な検証から始め、効果指標で適用範囲を広げる
まずは、現在利用しているAIツール、入力している情報、付与している権限を棚卸ししてください。そのうえで、重要リポジトリを一つ選び、利用ルールとCI/CD検査、承認ゲートを試験導入することが安全な定着への近道です。
よくある質問
Q1. AIセキュア開発とは何ですか？
生成AIやAIエージェントを開発に使う際、生成コード、入力データ、権限、依存関係、CI/CD、監査を一体で管理し、安全に開発・運用する取り組みです。
Q2. AI生成コードは利用しても安全ですか？
利用は可能ですが、そのまま本番投入することは安全ではありません。入力値処理、認証・認可、秘密情報、依存関係を人間がレビューし、テストとスキャンで確認してください。
Q3. AIエージェントに本番デプロイを任せてもよいですか？
無制限に任せるべきではありません。最小権限、隔離環境、承認ゲート、段階的リリース、ロールバックを組み合わせ、重要操作には人間の承認を残すことが基本です。
Q4. 最初に導入すべき対策は何ですか？
AI利用ルールの策定、入力情報の分類、秘密情報検出、SAST・SCAのCI組み込み、AI生成コードのレビュー記録から始めると、比較的短期間で統制の基盤を作れます。
Q5. SBOMはAIセキュア開発でなぜ必要ですか？
AIが提案したライブラリを含め、ソフトウェアを構成する部品とバージョンを追跡するためです。脆弱性やライセンス問題が判明した際に、影響範囲を迅速に特定できます。
参考文献・出典
PR TIMESのご利用について 資料をダウンロード # NRIセキュア、AI駆動開発のセキュリティ対策を支援するサービスを提供開始 ## AIエージェント利用のルール整備から開発プロセスの設計、脆弱性対応までを包括的に支援 NRIセキュアテクノロジーズ…
prtimes.jp
   [![Google Cloud…
docs.cloud.google.com