投稿者 global-ai-media 
AIによる攻撃やAIシステム自体の脆弱性を突いたインシデントが急増しています。2024年には2,377万件ものシークレット（機密情報）が流出したというデータも報告されました。本稿では、NISTやISOといった従来のセキュリティフレームワークではカバーしきれないAI特有のリスクと、日本企業がとるべき現実的な対策について解説します。
「伝統的なセキュリティ」と「AIセキュリティ」の決定的なギャップ
多くの日本企業は、情報セキュリティの基準としてISO 27001（ISMS）やNIST（米国国立標準技術研究所）のサイバーセキュリティフレームワーク、あるいはCISベンチマークなどを採用しています。これらはネットワーク防御、アクセス制御、マルウェア対策といった従来のITインフラを守る上では現在も極めて有効です。
しかし、最新の調査報告によると、2024年だけでAI駆動型の攻撃により2,377万件もの「シークレット（APIキー、認証トークン、パスワードなど）」が流出したとされています。この事実は、既存のフレームワークだけではAI特有の脅威を防ぎきれないことを如実に示しています。
従来のセキュリティは「システムへの不正侵入を防ぐ」ことが主眼でしたが、AI（特に生成AIやLLM）のセキュリティは、「正当なアクセス権を持つユーザーが、AIを騙して不適切な出力を引き出す（プロンプトインジェクション）」や「学習データに含まれる機密情報を推論によって復元する」といった、全く異なるベクトルの攻撃に対処する必要があります。
なぜAI開発・活用において「シークレット」が流出するのか
AI開発や活用の現場で機密情報が流出する背景には、大きく分けて2つのパターンがあります。
一つは、AIを用いた開発支援ツール（GitHub Copilotなど）の利用に伴うリスクです。エンジニアが生成AIを用いてコードを書く際、ハードコードされたAPIキーや認証情報が含まれたままリポジトリにコミットされてしまうケースや、逆に機密コードをパブリックなLLMに入力してしまうケースです。
もう一つは、攻撃者がAIツールを悪用して脆弱性スキャンを自動化・高度化させている点です。これにより、公開されているコードや設定ファイルの中に紛れ込んだシークレット情報が、人間が手作業で探すよりもはるかに高速かつ大量に収集されてしまいます。
日本の開発現場でも、納期短縮のプレッシャーからセキュリティチェックが疎かになり、AIが生成したコードをそのまま本番環境にデプロイしてしまう事例が散見されます。これは単なるヒューマンエラーではなく、開発プロセスの構造的な課題と言えます。
日本企業が直面する「認証・規格」の落とし穴
日本企業、特に大企業や金融機関においては「ISMSを取得しているから安全」「社内規定で承認されたSaaSしか使っていない」という認識が強い傾向にあります。しかし、ここには大きな落とし穴があります。
一般的なISMSの審査基準は、AIモデルの挙動や、LLM（大規模言語モデル）に対する敵対的攻撃を詳細にはカバーしていません。例えば、「社内チャットボットが、従業員の給与データを学習してしまい、誰でも質問すれば回答してしまう」という事態は、従来のアクセス制御の考え方だけでは防ぐのが難しいのです。
また、日本特有の「現場の判断によるシャドーAI」の問題もあります。業務効率化を急ぐあまり、現場部門が情報システム部門の許可を得ずに無料の翻訳AIや要約ツールに顧客データを入力してしまうケースです。これらは従来のファイアウォールやエンドポイントセキュリティでは検知しにくい「業務プロセス上のリスク」です。
AI特化型のガバナンスへの転換
こうした状況に対応するためには、既存のフレームワークに加えて、AIに特化した新しい基準を取り入れる必要があります。例えば、NISTは従来のフレームワークとは別に「AI RMF（AI Risk Management Framework）」を策定しており、OWASP（Webアプリケーションセキュリティのコミュニティ）も「OWASP Top 10 for LLM」を公開しています。
また、国際規格として「ISO/IEC 42001（AIマネジメントシステム）」も登場しており、日本国内でもこれを取得・準拠しようとする動きが出始めています。これらは、AIシステムの透明性、説明可能性、そして学習データの管理に焦点を当てています。
日本企業のAI活用への示唆
今回の2,377万件という流出件数は、対岸の火事ではありません。日本企業がこのリスクに対応しつつ、AIの恩恵を享受するために意識すべき点は以下の3点です。
1. 既存のセキュリティ基準への過信を捨てる
ISMSやPマークを持っていることと、AIセキュリティが担保されていることはイコールではありません。AI特有のリスク（プロンプトインジェクション、データ汚染、モデル盗用など）を評価項目に追加し、セキュリティガイドラインを「AI対応版」へアップデートする必要があります。
2. 「禁止」ではなく「安全な利用環境」の提供
リスクを恐れてAI利用を一律禁止にすると、従業員は個人のスマホなどで隠れてAIを使う「シャドーAI」に走り、かえってリスクが高まります。安全なサンドボックス環境（入力データが学習に使われない契約の法人向けプランなど）を会社として提供し、監視下で使わせることが現実的な解です。
3. 開発プロセスへの自動スキャンの導入
AIが生成したコードにAPIキーなどのシークレットが含まれていないか、コミット前に自動検知する「シークレットスキャン」の導入は必須です。人間によるコードレビューには限界があるため、AIが生み出すリスクは、ツールによる自動化で防ぐのが鉄則です。
AIは強力な武器ですが、その防御には従来の「城壁」だけでなく、モデル内部の振る舞いやデータの流れを見る新しい視点が必要です。経営層と現場がこのギャップを理解し、組織的な対策を講じることが急務です。