組織のあらゆる従業員が、複雑なワークフローを自動化・調整・最適化するためにAIの可能性を活用しています。その一部はIT部門が審査・承認したツールを通じて行われますが、多くは個人アカウントやブラウザ拡張機能を通じて行われており、セキュリティ部門は誰一人としてそれを目にしたことも、承認したこともありません。
AIリスクを最小化するための従来型のセキュリティ手法は、まず利用されているAIツールを可視化することです。CASBでアクセスを制御し、DLPルールを組み合わせ、利用状況を追跡する——これは決して悪いセキュリティモデルではありません(実際、SaaSの乱立を制御する手法として何年も機能してきました)。しかしAIに関しては、その限界が見えてきています。
なぜCASBとDLPはAIに対して不十分なのか
アプリ、ファイル、あるいは構造化されたデータフィールドに閉じ込めておける従来のSaaSリスクとは異なり、AIリスクはまったく別物です。それはプロンプトの中に姿を現し、AIモデルが生成する応答の中にも現れます。そして組織が最も恐れるシナリオでは、悪意あるプロンプトによって自律型エージェントが取る行動の中にも現れます。
残念ながら、これらのシナリオはいずれも、CASBやDLPが検査対象として設計してきたものと綺麗に一致するとは限りません。
CASBが問うのは、ユーザーが特定のアプリケーション(AIツールを含む)へのアクセスを許可されているかどうかであり、多くの場合、そのアプリ内でユーザーが何をできるかも制御します。しかしAIに関しては、会話の背後にある「意味」を考慮することも重要です。従来型のCASB制御では、AIとの会話が持つ意味的・累積的な文脈を十分な深さで評価できない場合があります。
ここにこそ、埋めるべきギャップがあります。
AIにおいては「中身」がものを言います。プロンプトは一見無害に見えても、その言い回し・文脈・目的を深く掘り下げると、リスクをはらんでいることがあります。AIの場合、露出は必ずしも会話の中でアカウント番号やAPIキーを貼り付けるといった形で起きるとは限りません。ユーザーは複数のプロンプトにまたがって、無自覚のうちに機密情報を共有してしまうことがあります。それらは間接的に説明されるだけかもしれませんが、モデルが意味を読み取るには十分な場合があります。
数日後に成立予定のベンダー契約に関する情報や、障害インシデントレポートの要約を共有する場面を想像してください。どちらのケースでも、DLPルールに合致しなくても、この情報共有には実際のビジネスリスクが伴います。
CASBにも同様の限界があります。ユーザーはアプリにアクセスできる——しかしリスクは、そのユーザーが入力するプロンプトの中に、後になって現れることがあるのです。
このシナリオは、セキュリティチームを板挟みの状況に追い込みます。CASBの締め付けを強めれば、ユーザーは誰の目にも触れない未管理のアプリへと流れていくかもしれません。一方でDLPが緩すぎれば、機密データの流出を許す門戸を開けたままにすることになります。
セキュリティは「インタラクション」を検査すべき
制御は、露出が実際に発生する場所——つまり人間とAIモデルとのやり取りの内部——で機能すべきです。それはつまり、何が問われているのか、モデルがそれに対して何を生成したのか、エージェントがどのツールを呼び出したのか、どのデータを取得・送信したのか、そしてその結果としての行動が許可されているのかどうかを、詳細に見ていくということです。AIサービスそのものへのアクセスを許可するか拒否するかを決めるだけでは不十分なのです。
この違いが重要である理由を示す、いくつかのシナリオを見てみましょう。
- 公開用ブログの構成案をAIに考えさせるのは、ごく日常的な作業です。しかし、未発表製品に言及したマーケティング向けコピーを作成させる場合は、機密情報が危険にさらされます。
- ソフトウェア開発者がAIツールに一般的な質問をする場合のリスクは低いといえます。しかし、独自のロジックを含む依頼となると話は別です。実在する顧客の問題に紐づく質問であれば、事態はさらに悪化しかねません。この情報が共有されたものであれ、出力として生成されたものであれ、いずれにせよ安全なAI利用の範囲には収まりません。
- エージェント型ワークフローに関して言えば、エージェントが承認済みのナレッジベースを取得すること自体にリスクはありませんが、制限付きの社内文書を外部に転送することには明らかにリスクがあります。
- すでに公開されている文書を要約することのリスクは低い一方、部分的な文脈から機密情報を再構築することにはリスクがあります。
- 取得したコンテンツをデータとして扱うのは想定内の挙動です。しかし、指示が巧妙に埋め込まれ、エージェントがそれを取り込んで従ってしまう場合、プロンプトインジェクションは深刻なリスクとなります。モデルはデータと指示を確実に区別できないためです。
- エージェントやセッションの認証は基本的な制御にすぎません。しかし、低リスクに見えた依頼が突如として高リスクな行動へと変わることがあるため、それだけでは不十分です。だからこそセキュリティ部門には、何を許可すべきかを判断するためのAI異常検知が必要になります。
アクセスの遮断ではなく、ガバナンスの拡張を
デフォルトで拒否するという方針は、長期的には成り立ちません。アクセスを一律に遮断すれば、書類上は安全に見えるかもしれませんが、従業員には締め切りがあります。結果として利用は個人アカウントや未管理の拡張機能へとシフトし、それらはそもそもCASBの監視対象として設定されてすらいません。このシナリオはシャドーAIの一層の浸透を招きます。
AIリスクの低減は、CASB・DLP・インタラクションレベルの検査のどれか一つを選ぶという話ではありません。三つとも重要であり、同じ問題の異なる層を解決するものです。
AIリスク管理において最善の一歩を踏み出すということは、次のことを意味します。
- プロンプトインジェクションやエージェントの誤用を、後回しにできる例外的なケースとしてではなく、今この瞬間から現実の日常的なリスクとして扱うこと。
- CASBとDLPを活用し、利用中のSaaS・AIアプリを可視化し、アクセスを統制し、既知の機密パターンを検知し、コンプライアンス報告を支えること。
- プロンプトの意味内容、応答が持つ機密性の度合い、そしてエージェントの行動が承認されたものかどうかを掘り下げて検査する、インタラクションレイヤーを追加すること。
- 目標を「安全であると証明されるまでAIを封じ込めること」に置くのではなく、機密データとエージェントの挙動を明確な境界内に保ちながら、従業員がAIを導入し試行錯誤できる余地を与えること。
AIにおいて「このユーザーはこのツールを開けるか?」という問いは、的外れです。正しい問いは、この特定のプロンプトが安全かどうか、応答が安全かどうか、そしてこの行動が承認されたものかどうかです。従業員がAIを生産的に活用しつつ、機密データ・知的財産・エージェントの挙動を、安全なAI利用のために定められた境界内に保てるよう、これらの問いに答えることを軸に戦略を構築してください。
