大規模環境でAIを安全に導入するための実践的教訓

私が企業向けAIセキュリティの取り組みに携わり始めた当初、最大の課題は技術的なものになるだろうと考えていました。プロンプトインジェクション、モデルセキュリティ、ベクトルデータベース、あるいは最新のLLM脆弱性の議論に多くの時間を費やすことになるだろうと想定していたのです。

しかし、それは間違っていました。少なくとも、正確ではありませんでした。

もちろん技術自体は重要です。ですが、複数の企業向けAI導入プロジェクトに関わる中で分かったのは、最も厄介なセキュリティ問題はモデル自体からはほとんど生じないということです。それらは、AIが実際のビジネスプロセスの一部として組み込まれたときに表面化します。

AIアシスタントは単に質問に答えるだけの存在ではありません。ひとつのワークフローの中で、Salesforceから顧客レコードを取得し、ServiceNowでチケットを開き、Microsoft 365経由で更新を送信する、といったことを、誰かが要約を読み終える前にやってのける場合もあります。人間がまだ気づかないうちにAIが判断を下すケースも増えており、この変化が脅威モデルそのものを変えてしまいます。従来のアプリケーションセキュリティは、ソフトウェアが決定論的なコードを実行することを前提としています。しかしAIシステムはそうではありません。推論し、適応し、事前に完全には予測できない出力を生成します。つまり、これまで長年頼ってきた統制は依然として必要ではあるものの、もはやそれだけでは十分ではないということです。

ここから述べるのは、アーキテクチャレビューの場で私が繰り返し立ち返ることになった論点です。見出しを賑わせるモデルの脆弱性ではなく、エージェントがすでに稼働し始めた後に表面化する、目立たない失敗の数々です。

アイデンティティはあくまで出発点にすぎない

私が最初に驚かされたのは、多くの組織が認証にばかり注目し、実行時の振る舞いを見落としているという点でした。企業のAIプロジェクトの多くは、「AIはSharePointにアクセスできるか」「ServiceNowに接続できるか」「GitLabに接続できるか」「Outlookやワードといったマイクロソフト365のツールを読み取れるか」といった問いから始まります。これらは重要な問いではありますが、もっと重要なのは次の問いです。特定の種類のアクセス(例えば読み取り専用アクセス)が付与された後、AIには何をすることが許されるべきなのか、という点です。

アイデンティティはエージェントが「誰であるか」に答えます。認可はエージェントが「何にアクセスできるか」に答えます。しかし、そのAIが特定の行動を実行してよいかどうかには、どちらも答えていません。前述の例で言えば、あくまで読み取り専用アクセスが実行されているにすぎないのです。

「何ができるか」という問いと、「何を防ぐべきか」という問いは、しばしば異なるチームによって、異なるタイミングで検討されがちです。AIが何にアクセスできるかにだけ注目するセキュリティレビューは、そのアクセスが存在する状態で何を行うことが許されているのかという、より本質的な問いを見落とす傾向があります。私はこの2つの問いをひとつの設計課題として扱うようになりました。なぜなら、この両者の間に生じるあらゆるギャップは、最終的にはインシデントとして表面化するからです。

あるアーキテクチャレビューで、この問題が具体的な形で立ち現れたことを覚えています。ある社員が、Microsoft 365とSharePoint上に構築された社内アシスタントに複数のインシデントレポートの要約を依頼しました。その推論の過程で、アシスタントはリンク先のサイトにある権限管理者向けの機密文書を発見し、それも要約に含めた方が有用だろうと自ら判断したのです。技術的には何も失敗していませんでした。認証情報は有効で、権限も正しく設定されていました。それでも、この結果はビジネス上の意図に反するものでした。この瞬間、その場にいた全員の議論の枠組みが変わりました。私たちの脅威モデルは、外部からの侵入者を想定して構築されたものであり、権限を持つシステムが少し親切すぎる行動を取ることは想定していなかったのだと気づかされたのです。このギャップを埋めるには、入口の認証情報だけでなく、文脈に応じて振る舞いを評価する統制を設計する必要がありました。それ以来、私は実行時のガバナンスこそが、企業向けAIにおける最も重要なセキュリティ課題のひとつだと考えるようになりました。

OWASP GenAI Security ProjectやNIST AI Risk Management Frameworkといった組織も、AIのリスクは認証・認可の範囲をはるかに超え、監視、ガバナンス、実行全体を通じた継続的な監督にまで及ぶと強調しています。エージェント型AIのアイデンティティに関するCSOonlineの報道も同じ趣旨を指摘しています。既存の統制はAIエージェント向けに設計されたものではなく、組織が自律型エージェントに対して迅速に権限を付与・制限・取り消す必要がある(場合によってはひとつのワークフローの中で複数回にわたって)状況においては、静的な認証情報や常時付与された権限ではもはや不十分だというのです。

最大の失敗は、サイバー攻撃のようには見えないことがほとんど

セキュリティ専門家が自然と目を向けるのは、プロンプトインジェクション、データポイズニング、認証情報の窃取、モデルの操作といった悪意ある活動です。これらの攻撃が重要であることは間違いありません。しかし、私がより頻繁に目にしてきたのは、正当なAIの振る舞いが引き起こす失敗です。財務、人事、顧客対応、あるいはリスク管理部門のAIアシスタントが、「より良い」回答を提供しようとするあまり、必要以上の文書を取得してしまう。自律型ワークフローが、承認されていた1つの動作の代わりに5つの動作を実行してしまう。ユーザーの本来の意図がすでに満たされているにもかかわらず、AIエージェントが処理を続けてしまう。これらはいずれも従来型の攻撃とは似ても似つかないものですが、コンプライアンス違反やプライバシー問題、業務上の混乱を引き起こしかねません。

これがなぜそれほど危険なのかを経営層に理解してもらうのに、一貫して役立ってきた思考モデルがあります。私は彼らに、AIをソフトウェアとして捉えるのをやめ、代わりに何千人もの新しいデジタル従業員、すなわちAIエージェントを雇い入れるようなものだと考えてほしいと伝えています。従業員は一人ひとりが研修を受け、限定的なアクセス権を与えられ、監視され、監査され、監督下に置かれます。AIエージェントにも同様の扱いがふさわしいのです。

私が関わったある導入案件では、複数の専門特化型AIエージェントが連携して、ひとつの業務タスクを完遂していました。あるエージェントはServiceNowでチケット履歴を照会し、別のエージェントはSharePoint上の文書を分析し、3番目のエージェントは提案を起草し、4番目のエージェントはJiraに更新内容を書き込みます。個々のエージェントが持つ権限は、読み取り専用や書き込みなど、比較的限定的なものでした。しかし、それらが集まると強力な自律型ワークフローとなります。この経験は、重要な教訓を裏付けるものでした。セキュリティはもはや個々のAIコンポーネントだけに焦点を当てていては不十分で、自律的な意思決定の連鎖全体を統制する必要があるということです。MITRE ATLASフレームワークは、敵対的なAI技術について考えるうえで優れた枠組みですが、同じくらい重要なのは、正常な自律的振る舞いが意図せずビジネスリスクを生み出しうるということを理解しておくことです。

私がこれまで見た中で最も示唆に富む事例は、あるエージェントが別のエージェントに処理を委任するケースです。あるレビューでは、フロントラインのサポートエージェントがSalesforceに対して厳密に読み取り専用のアクセス権しか持っていませんでした。しかしそのエージェントは、ServiceNowと請求プラットフォームに書き込み権限を持つ第二のエージェントにタスクを引き渡すことができました。最初のエージェントが自身の権限範囲内で顧客の問題を解決できなかった場合、それは静かにリクエストを第二のエージェントへと回し、そのエージェントがケースを更新して返金処理を発行していたのです。ハッキングされたわけではありません。認証情報は有効で、委任は技術的には許可された行為でした。それでも、読み取り専用のエージェントが、本来決して実行することを意図されていなかった書き込み行為を、事実上行っていたことになります。これこそが、単なるアシスタントとエージェントを分かつ決定的な違いです。アシスタントは回答するだけですが、エージェントは他のエージェントを動員します。そして、その権限のエスカレーション経路そのものが脆弱性なのです。

だからこそ私たちは、アーキテクチャレビューの場で問いの立て方を変えるようになりました。「AIはこれを行うことができるか」ではなく、「AIはまだこれを行うべきなのか」と問うようにしたのです。この微妙な視点の転換は、多くの設計上の判断を変えました。エージェントが自然に「いつ止まるべきか」を理解しているだろうという前提に頼るのではなく、停止条件、スコープチェック、確認プロンプトをあらかじめ組み込むよう、各チームを後押ししたのです。あるレビューでは、エージェントが読み取り専用のステップから書き込み動作へと踏み込む際に、人間による確認を必須とするだけで、それまで議論していたリスクの高い経路の大部分を排除できました。

自律性より先に、まずガバナンスから始める

私が繰り返し目にしてきたパターンのひとつは、組織が自律性そのものに興奮するあまり、それを統治する準備が整うよりずっと前に導入を進めてしまうというものです。誰もがAIエージェントを欲しがりますが、実行時のポリシー適用に初期投資を行う組織はごくわずかです。この順序は逆転させるべきです。私の経験では、企業向けAIプログラムを成功させている組織は、自動化を拡大する前にいくつかの基盤を整えています。エージェントが越えてはならない明確なビジネス上の境界線、すべてのエージェントに対する最小権限のアクセス、そして機密・制限対象のデータやシステム(本番データ・システムを含む)に触れるあらゆる段階での人間による承認です。こうした基盤が整って初めて、自律的な意思決定の幅を広げることに意味が出てきます。私はこの順序を省略しようとするチームを何度も見てきましたが、結果はほぼ決まって同じです。有望だったパイロット導入が、AIが何をしたのか、なぜそうしたのかを誰も自信を持って説明できないという理由で、頓挫してしまうのです。

この基盤の大きな部分を占めるのが可視性です。従来の監査ログは行動の記録にとどまりますが、AIシステムには推論の過程も記録する必要があります。AIエージェントがチケットを作成したり、設定を変更したり、メールを送信したりした際には、調査担当者がなぜその判断に至ったのかを理解できなければなりません。これは、大規模言語モデルが生成するすべてのトークンを記録するという意味ではありません。私の経験では、次の3点を記録することの方がはるかに価値があります。すなわち、元となった業務上の要求、エージェントが触れたシステム、そしてその過程で下された判断です。これらの記録は、調査、コンプライアンスレビュー、業務上のトラブルシューティングの際に非常に貴重なものとなり、組織が信頼を築く一助にもなります。重要な判断がどのように下されたのかを説明できるとき、経営層はAIの導入に対してはるかに安心感を持てるようになります。GoogleのSecure AI Frameworkのようなアプローチも、同じ考え方を裏付けています。AIセキュリティは、測定可能で、可観測性があり、端から端まで説明責任を果たせるものでなければならないのです。

私が今なお目にする誤解のひとつは、AIセキュリティはイノベーションを制約するために存在する、というものです。しかし実際には、企業向けAIの導入で最も速いスピードを実現している組織ほど、ガバナンスに最も積極的に投資している傾向があります。なぜなら、経営層は確信を持てるようになり、開発者はより速く動けるようになり、事業部門はより広くAIを取り入れられるようになるからです。うまく設計されたセキュリティこそが、そのスピードを可能にするのです。

振り返ってみると、最も価値のある教訓はプロンプトエンジニアリングやモデルの選定、あるいはエージェントフレームワークに関するものではありませんでした。安全なAIは、ひとつの完璧な統制によって実現されるものではなく、自律型システムをビジネス上の意図と整合させ続けるための、何百もの小さなエンジニアリング上の判断の積み重ねによって実現されるということです。私たちがアシスタントから完全に自律的なエージェントへと移行していく中で、この区別はますます重要になっていきます。私が、AIを大規模に展開するうえで信頼できると考えるチームとは、最も賢いモデルを持つチームではありません。エージェントが取ったあらゆる行動について、なぜそれを行ったのか、そしてどこで止まるべきだったのかを説明できるチームなのです。