AI暴走とサイバー攻撃を防ぐ企業の安全設計と監視運用実務対策

AI安全対策が経営課題に変わる背景

生成AIは文章作成ツールから、社内データを検索し、コードを書き、SaaSを操作し、業務を実行する基盤へ変わりました。便利さの中心にあるのは、モデル単体ではなく、データ、API、権限、ワークフローをつなぐシステムです。

そのため「AIの暴走」は、SF的な自我の問題ではありません。曖昧な指示、過剰な権限、汚染された外部情報、監視不足が重なり、AIが想定外の操作を実行する業務事故として捉えるべきです。企業が今すぐ整えるべきなのは、AIを止める議論ではなく、AIを安全に動かす設計と運用です。

暴走を防ぐAIガバナンスと棚卸し

暴走を業務事故として定義する視点

AIリスク管理の出発点は、モデルの性能比較ではなく「そのAIが何に接続され、何を実行できるか」の把握です。NISTのAI Risk Management Frameworkは、AIを設計、開発、利用、評価のライフサイクル全体で管理する考え方を示しています。企業実務では、これをAI台帳、リスク分類、承認フロー、監査証跡に落とす必要があります。

特に注意すべきなのは、生成AIが推論結果を返すだけの段階を越え、エージェントとして外部ツールを使う場合です。NCSCは2026年8月20日に公開したエージェントAIのリスク整理で、サンドボックス、能動的な監視、緊急停止を実務対策として示しました。つまり、AIの安全性は「モデルが賢いか」ではなく「失敗したときに被害範囲を限定できるか」で決まります。

まず経営層は、AIを3分類で棚卸しすべきです。第1は、文章要約や翻訳など業務支援型です。第2は、社内文書検索や顧客対応などデータ参照型です。第3は、チケット起票、メール送信、コード実行、発注処理など操作実行型です。第3分類は、従来の情報システムより事故時の速度が速く、権限管理と監視の優先度を一段上げる必要があります。

シャドーAIを減らす利用台帳

Verizonの2026年版DBIRは、従業員による未承認AI利用が前年の15%から45%へ拡大したと指摘しています。これは単なる利用ルール違反ではありません。顧客情報、設計資料、契約書、ソースコードが、企業の管理外にあるAIサービスへ入力されるデータ漏洩リスクです。

禁止だけではシャドーAIは減りません。現場がAIを使う理由は、検索、要約、議事録、コード補完などの生産性にあります。企業は承認済みAI環境を用意し、機密データの入力可否、ログ保存、学習利用の有無、保管地域、委託先、削除手順を台帳化する必要があります。利用部門には「何を使ってはいけないか」だけでなく、「どの用途なら安全に使えるか」を示すべきです。

AI台帳には、モデル名、提供者、用途、接続データ、実行権限、責任者、評価日、利用停止条件を記録します。SaaS契約と同じ扱いでは不十分です。AIはモデル更新により挙動が変わり、RAGの参照データ追加で出力傾向も変わります。契約時の審査だけでなく、運用中の再評価を前提にします。

データ境界と委託先を含む責任分界

AIシステムでは、データが従来のコードに近い役割を持ちます。GoogleのSAIFは、AI開発をデータ、インフラ、モデル、アプリケーションの領域で捉え、全体に統制をかける考え方を示しています。企業が守るべき対象は、モデルの出力だけでなく、学習データ、埋め込み、ベクトルDB、プロンプト、ログ、APIキーまで広がります。

委託先管理も変わります。AIベンダーがモデルを提供し、別のSaaSがエージェント実行環境を持ち、さらに外部プラグインが業務システムへ接続する構成では、事故時の責任分界が曖昧になりやすいです。契約では、入力データの利用範囲、再学習への利用可否、障害時の通知期限、ログ提供、脆弱性開示、モデル変更時の通知を確認します。

EUのAI Actは2026年8月2日から主要規定と透明性義務の適用が進み、汎用AIモデルの提供者には2025年8月から義務が適用されています。日本企業でも、欧州向けサービスや欧州拠点でAIを使う場合は無関係ではありません。ISO/IEC 42001のようなAIマネジメントシステム標準を参照し、社内規程を国際的な説明責任に耐える形へ整えることが重要です。

攻撃を前提にした技術統制と監視

プロンプト注入とRAG汚染への備え

AIへの攻撃は、脆弱なサーバーに侵入するだけではありません。攻撃者は、Webページ、メール、PDF、チケット、カレンダー招待、社内Wikiなどに悪意ある指示を埋め込み、AIに読み込ませることで、機密情報の出力や不正なツール実行を誘導します。これは間接プロンプト注入と呼ばれ、RAGを使う企業ほど注意が必要です。

OWASPのLLMアプリケーション向けTop 10は、プロンプト注入、機密情報漏洩、サプライチェーン、データとモデルのポイズニング、過剰な権限などを主要リスクとして整理しています。AISIも2025年にRAGを対象としたAIレッドチーミング手法を改訂し、2026年には既知攻撃と影響の資料を更新しました。日本企業にとっても、RAGの安全性評価は実証実験の段階を越え、運用前チェック項目になっています。

対策は、入力をすべて信用しないことから始まります。外部文書を取り込む場合は、データソースの信頼度、更新者、更新履歴、アクセス権を管理します。検索結果をモデルに渡す前に、機密区分と権限を照合し、ユーザーが本来見られない文書をRAGが参照しないようにします。出力側でも、個人情報、認証情報、契約情報、未公開コードが含まれる場合に警告や遮断を行います。

エージェント権限を狭める実装原則

AIエージェントの危険性は、推論ミスそのものより、ミスが実行権限と結びつく点にあります。メール送信、DB更新、クラウド操作、コード実行を任せるなら、AI用の固有IDを発行し、人間のアカウントを共有させないことが基本です。NCSCは、エージェントに独自のアイデンティティを持たせ、短寿命の認証情報と最小権限を使うことを重視しています。

実装では、タスク単位で権限を分けます。請求書を読むAIに支払い実行権限を与えない、問い合わせ分類AIに顧客データの一括ダウンロードを許さない、コード修正AIに本番デプロイ権限を与えない、といった分離が必要です。人間なら常識で止まる操作でも、AIは目標達成の一部として実行し得ます。

サンドボックスは必須です。ネットワークは原則拒否し、必要なAPIだけ許可します。ファイルシステム、環境変数、APIキー、SSHキー、ブラウザーセッションをAIが自由に読める設計は避けます。高リスク用途では、推論基盤、エージェント実行環境、業務システムを分離し、通信はプロキシ経由で記録します。

また、AIの出力を下流システムへ渡す前に検証します。SQL、シェルコマンド、HTML、コード、設定ファイルをAIが生成する場合、従来の入力検証と同じく、構文チェック、許可リスト、静的解析、差分レビューを行います。AIが作ったコードであっても、責任は開発組織に残ります。

監視ログと停止手段の標準装備

攻撃者の速度は上がっています。CrowdStrikeの2026年版Global Threat Reportは、AIに支援された敵対者の活動が前年比で89%増え、eCrimeの平均ブレイクアウト時間が29分、最短では27秒だったとしています。Verizonの2026年DBIRでも、侵害の31%が脆弱性悪用から始まり、脆弱性発見から悪用までの時間が短縮している点が強調されています。

AI環境の監視では、通常のEDRやSIEMだけでは足りません。誰が、どのAIに、どのデータを渡し、どのツールを実行し、どの外部サービスへ通信したかを追える必要があります。プロンプト、参照文書ID、ツール呼び出し、承認者、実行結果、拒否理由を保存し、改ざんされにくい形で保管します。

監視対象には、AIが生成した大量リクエスト、許可外ドメインへの接続、通常業務では使わないAPI呼び出し、深夜の自動実行、短時間での権限試行を含めます。モデルの会話ログだけを見ても、事故の全体像は分かりません。ネットワーク、ID、SaaS監査ログ、クラウド監査ログを横断して相関分析できる状態が必要です。

緊急停止も設計段階で用意します。停止ボタンはUI上の「実行停止」だけでは不十分です。エージェント実行基盤の停止、ネットワーク遮断、認証情報の失効、キューの停止、外部APIの無効化、ベクトルDBの参照停止まで含めます。AI事故対応訓練では、モデルの不正出力だけでなく、誤送信、過剰発注、機密データ外部送信、RAG汚染、APIキー漏洩を想定します。

エージェントAI普及で広がる運用リスク

AI対策で最も危険なのは、生成AIを特殊な新技術として隔離しすぎることです。AIエージェントは、ID、クラウド、SaaS、データ基盤、ソフトウェアサプライチェーンの上で動きます。したがって、基本的なサイバー衛生が弱い企業ほど、AI導入でリスクが増幅します。

NISTのCybersecurity Framework 2.0は、従来の識別、防御、検知、対応、復旧に加え、ガバナンスを明示しました。AI時代の企業にも同じ発想が必要です。AIの利用可否を現場任せにせず、リスク許容度、責任者、評価基準、予算、事故報告を経営レベルで決めます。

IBMの2026年版Cost of a Data Breach Reportは、データ侵害の世界平均コストを499万ドルとし、AI駆動型攻撃の増加も示しています。一方で、セキュリティにAIと自動化を広く使う組織は、使わない組織より大きなコスト削減効果があるとしています。つまり、AIは攻撃側だけの武器ではありません。脆弱性検知、アラート整理、設定不備の発見、インシデント初動の高速化にも使えます。

ただし、防御AIにも統制が必要です。SOCでAIを使う場合も、誤検知で業務を止める、重要アラートを要約で落とす、攻撃者にログを汚染されるといったリスクがあります。AIが判断を支援し、人間が重大アクションを承認する設計から始め、高リスク操作は段階的に自動化するのが現実的です。

経営者が今期予算で優先すべき対策

企業が今すぐ着手すべき対策は、AI専門部署だけで完結しません。第1に、全社AI台帳を作り、未承認利用を減らします。第2に、AIエージェントの権限をタスク単位で分け、固有ID、短寿命認証情報、サンドボックスを標準にします。第3に、RAG、プロンプト注入、サプライチェーンを対象にレッドチーム評価を行います。

第4に、AIログをSOCとインシデント対応に接続します。第5に、取締役会へ報告する指標を決めます。承認済みAI数、未承認利用検知数、高リスクAI数、レッドチーム未解消項目、重大インシデント訓練の結果を見れば、AIリスクは抽象論から管理可能な経営指標へ変わります。

AIの安全対策は、導入を遅らせるブレーキではありません。安全に接続し、狭く権限を与え、継続的に監視し、すぐ止められる企業ほど、AIを深く使えます。競争力の差は、モデル選定だけでなく、安全設計を事業スピードに組み込めるかで決まります。

参考資料:

• AI Risk Management Framework | NIST
• Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations | NIST CSRC
• NIST Releases Version 2.0 of Landmark Cybersecurity Framework | NIST
• Guidelines for secure AI system development | NCSC
• Managing the cyber risk of agentic AI | NCSC
• The AI shift in cyber risk: why leaders must act now | NCSC
• DHS CISA Releases Roadmap for Artificial Intelligence | GovDelivery
• Joint Guidance on Deploying AI Systems Securely | GovDelivery
• OWASP Top 10 for Large Language Model Applications | OWASP
• MITRE ATLAS
• Google Secure AI Framework
• Vulnerability exploitation top breach entry point, 2026 DBIR finds | Verizon
• Cost of a Data Breach Report 2026 | IBM
• ISO/IEC 42001:2023 AI management systems | ISO
• AIセーフティに関するレッドチーミング手法ガイド | Japan AISI