AI導入を急ぐあまり見過ごされる8つのセキュリティリスク

多くの企業が生成系AI（Generative AI）から生産性向上を得ようと急ぐ一方で、そのセキュリティ上の影響を見落としているケースが大半だ。画期的なイノベーションに期待するあまり、適切なセキュリティ対策がおざなりにされているのである。

世界経済フォーラム（WEF）がアクセンチュアと共同で実施した調査によれば、企業の63％がAIツールを導入する際にセキュリティ評価を行っておらず、さまざまなリスクを抱え込んでいるという。

このリスクは市販のAIソリューションだけでなく、社内のソフトウェア開発チームと協力して構築した自社専用の実装にも及ぶ。Tricentisの「2025 Quality Transformation Report」によると、開発チームの多くはソフトウェアの品質向上（13％）よりも、納期短縮（45％）に注力している。一方で、同レポートの回答者の3分の1（32％）は、ソフトウェア品質の低下によってセキュリティ侵害やコンプライアンス違反がより頻繁に起こる可能性があると認めている。

実際、セキュリティ侵害や失敗はますます頻繁に発生している。シスコが5月7日に公表した最新版の「Cybersecurity Readiness Index」によれば、86％の組織が過去1年にAI関連のセキュリティインシデントを経験しているという。しかし、そのような組織のうち、自社で包括的なAIセキュリティ評価を行うだけのリソースや専門知識があると考えているのは45％にとどまる。

見過ごされがちなAIのセキュリティリスク

CSOが専門家に聞いたところによると、AIシステムを導入前に十分にテストしないことは、従来のソフトウェアとは大きく異なるさまざまな脆弱性を招くという。以下はその代表的な例である。

■ データ漏えい
AIシステムは大量の機密情報を処理することが多いが、十分なテストが行われていない場合、そのデータがどれほど簡単に流出し得るかを見落としがちだ。セキュリティ対策が不十分なストレージ、過剰に情報を返すAPI、アクセス制御の不備などが原因となる。

「多くのAIシステムは推論の過程でユーザーデータを取り込み、セッションの文脈を保持することがあります」と語るのは、AIセキュリティテストベンダーMindgardのCEO兼共同創業者であるピーター・ギャラガン（Peter Garraghan）博士だ。「データの取り扱いが監査されていない場合、モデルの出力やログの公開、微調整済みデータセットの誤用などを通じて、データ漏えいのリスクが高まります。大規模言語モデル（LLM）のメモリ機能やストリーミング出力モードによって、これらのリスクはさらに深刻化します」

■ モデルレベルの脆弱性
「プロンプトインジェクション」や「ジェイルブレイク」、敵対的なプロンプトチェインといった攻撃手法は、入念なテストがなければ見過ごされやすい。これらの攻撃によって、モデルの出力制約を回避したり、機密データを漏えいさせたり、意図しないタスクを実行させたりする恐れがある。

「この種の攻撃は、モデルのアライメント（安全策）の仕組みや、トークンレベルの推論に依存している点など、モデルの弱点を突いて行われることが多いのです」と、ランカスター大学（英国）講師でもあるギャラガン氏は解説する。

■ モデルの整合性と敵対的攻撃
敵対的な操作や不正な学習データによる「毒付け」に対するテストを行わないままでは、AIモデルがどのように振る舞うかを攻撃者が意のままにコントロールすることが容易になる。特に、ビジネス上の意思決定や機密性の高い業務の自動化をサポートする場合には危険性が高い。

サイバーコンサル企業CyXcelのCOO、ジャノ・ベルムーデス（Jano Bermudes）氏はこう語る。「攻撃者は入力データを操作してAIモデルを騙し、誤った決定を下すよう仕向けることができます。これは回避攻撃やデータ毒付け攻撃を含みます」

■ システミックな統合リスク
AIモデルはAPIやプラグイン、RAG（Retrieval-Augmented Generation）構成などを介して、より大きなアプリケーションのパイプラインに組み込まれることが多い。

「この段階でのテストが不十分だと、モデルの入力・出力の扱いにおけるセキュリティホール、シリアライズされたデータ形式を経由したインジェクション経路、ホスティング環境内での権限昇格といった問題が生じる可能性があります」とギャラガン氏は警鐘を鳴らす。「こうした統合ポイントは、一般的なAppSec（アプリケーションセキュリティ）のワークフローでは見落とされがちです」

■ アクセス制御の不備
AIツールは他のシステムへ接続することが多く、誤った構成によって、意図した以上のアクセス権をユーザーや攻撃者に与えてしまうおそれがある。APIキーが丸見えになっていたり、認証が不十分だったり、ログが不十分で乱用が発見できないといったケースが挙げられる。

■ ランタイムセキュリティの不備
AIシステムは本番環境における運用中にのみ発現する「創発的挙動」を起こすことがある。特に動的な入力条件下や他のサービスとの連携時に顕在化しやすい。

「たとえば、ロジックの破損や文脈のオーバーフロー、出力の反射などといった脆弱性は、本番の運用下や実際のトラフィックをシミュレートしたレッドチーム演習でしか発見できないことがよくあります」とギャラガン氏は説明する。

■ コンプライアンス違反
AIツールが規制要件を満たしているか確認を怠れば、法的措置に直面しかねない。たとえば、AIツールによる無許可のデータ処理や、モデルの大規模運用時に想定外の挙動が起きてシステムダウンを招き、規制違反となる可能性がある。

■ 組織全体へ及ぼす影響
「こうした技術的な脆弱性は、テストされないまま放置されると個別の問題にとどまりません」とギャラガン氏は指摘する。「エンジニアリング領域を超えて、組織全体にまたがるリスクとなって表面化します。運用上の視点から見れば、AIのセキュリティテスト不足による影響は、安全性・セキュリティ・事業の確実性のすべてに直接結びついてくるのです」

コンプライアンス専門企業ISMS.onlineの最高プロダクト責任者（CPO）であるサム・ピーターズ（Sam Peters）氏も、適切なAIセキュリティ評価を行っていない企業では、広範囲にわたる運用への悪影響が見られると指摘する。

「AIシステムを急いで本番運用に移すと、モデルの整合性（毒付けや回避攻撃など）、データプライバシー（学習データ漏えいや機密データの不適切な取り扱い）、ガバナンス上の欠陥（透明性の欠如やアクセス制御の不十分さ）といった３つの主要領域で同じような脆弱性を繰り返し目にすることになります」と同氏は言う。

そしてピーターズ氏は、「これらの問題は単なる仮説ではなく、実際に“野生の脅威”として活用されています」と警告する。

テストか、それともスピードか

AIの導入を急ぎたい現場と、セキュリティを担うCISOとの間には大きな緊張関係が生まれる。しかしアプリケーションセキュリティテスト企業SparrowのCOO、ジェームズ・レイ（James Lei）氏は、「CISOは熱狂的な導入に歯止めをかけて、基本的なセキュリティ対策を導入プロセスに組み込むよう求めるべきだ」とアドバイスする。

「こうしたリスクを低減するには、ハイリスクのソフトウェアと同様にAIツールをテストし、疑似攻撃を試み、誤用シナリオをチェックし、入力と出力のフローを検証するとともに、処理されるデータが適切に保護されていることを確認する必要があります」とレイ氏は指摘する。

これらのリスクに対処するためには、以下のような包括的なテスト戦略の実装が推奨される。

• ペネトレーションテスト：脆弱性を発見するための疑似攻撃
• バイアスや公平性の監査：AIによる意思決定が公平かつ差別的でないことの検証
• コンプライアンス確認：関連する規制や基準への適合性をチェック

「AIの開発ライフサイクルにセキュリティテストを組み込めば、AIの恩恵を得ながら潜在的脅威から組織を守ることができます」とピーターズ氏は強調する。「AIツールを導入する前に、AIシステム固有の脅威モデリングや、敵対的入力を想定したレッドチーム演習、モデルのドリフトやデータ漏えいを厳重にテストすべきです。同時に、AI特有のコントロールをリスクマネジメントとコンプライアンスプログラムに取り入れることも欠かせません」

ピーターズ氏はこう付け加える。「ここで役立つのが、新たに策定されたISO/IEC 42001です。AIを責任ある形で運用するための枠組みを示しており、リスク評価やデータの扱い、セキュリティ管理、継続的なモニタリングなどに関するガイダンスが含まれています」

他の専門家たちもセキュリティテストの必要性を認める一方で、AIベースのシステムにおけるテスト手法は従来と異なるアプローチを取るべきだと主張する。

「通常のソフトウェアテストのように、ニューラルネットワークのコードを眺めるだけでは安全性を評価できません。クリーンで高品質なデータで学習させても、AIが奇妙な動きをすることはあるのです。どこまでテストすれば十分かを判断するのは難しい」と語るのは、クラウドソーシングによるセキュリティ企業Intigritiのチーフハッカーオフィサー（Chief Hacker Officer）であるインティ・デ・セウケレール（Inti De Ceukelaire）氏だ。

AIツールは単純な問題に対して複雑な解を提供することが多く、テスターがツールの想定された用途だけを検証していると、他の潜在的な機能を見落としがちになる。「たとえば翻訳ツールを使って、悪意あるコードが仕込まれたPDFを開かせたり、社内ファイルにアクセスしてそれを社外の人物向けに翻訳させるように仕向けられる可能性があります」とデ・セウケレール氏は例を挙げる。

こうした状況に対処するため、AI専用に設計された「敵対的テストフレームワーク」を導入することを検討すべきだ。

「具体的には、静的なモデル分析、動的なプロンプトのファジング、統合層における攻撃シミュレーション、ランタイムの挙動モニタリングなどが含まれます」とギャラガン氏は説明する。「こうした取り組みは、ソフトウェアのCI/CDパイプラインにDevSecOpsを組み込むのと同様に、AIの導入ライフサイクルに組み込む必要があります」