<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=139163818022217&amp;ev=PageView&amp;noscript=1"> <img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=271598307802760&amp;ev=PageView&amp;noscript=1">

AIシステムにおける「安全」の意味を捉え直す

 公開日:2026.09.04  Box Japan

AIの進化に対応するため、セキュリティプログラムをどのように進化させる必要があるのか。私はこのことについて、多くの時間を費やして考えてきました。そして考えれば考えるほど、ある1つの問いに意識が向かうようになりました。

AIシステムにおいて、「安全」とは実際に何を意味するのでしょうか?

Heather2_CroppedBox 最高情報セキュリティ責任者(CISO)
ヘザー・セイラン(Heather Ceylan)

過去20年の大半において、ソフトウェアにおける「安全」は絶対的な状態ではありませんでした。しかし、判断の拠り所となる明確なモデルはありました。

  • 明確に定義された境界
  • 強固なIDおよびアクセス制御
  • 既知の障害モード
  • リスクを許容範囲内に抑えるための多層防御

AIはこのモデルを変えます。基本原則が不要になるからではありません。完全には制御できないインプットに基づいて、振る舞いを動的に生成するシステムを導入するようになったからです。さらに、こうしたシステムは回答を生成するだけではありません。情報を検索し、ツールを使用し、他のシステムとやり取りして、ユーザーに代わってアクションを実行するようになっています。

「回答するAI」から「行動するAI」への移行は、セキュリティ上の課題を大きく変えます。不適切なアウトプットだけであれば問題は限定的です。しかし、機密コンテンツや特権ツール、後続のアクションに結び付いた誤った意思決定は、影響範囲がまったく異なるものになり得ます。

この移行は新たなリスクをもたらし、さらに重要なこととして、コントロールプレーンを変化させます。境界は曖昧になり、振る舞いの予測可能性は低下し、ID、意図、アクションのつながりが崩れ始めます。

それに伴い、現在のセキュリティモデルも機能しなくなります。決定論的なシステム向けに設計されたセキュリティ手法を、非決定論的なシステム、さらには自らの解釈に基づいて行動できるシステムに適用しているからです。その結果、既存のコントロールにはきれいに当てはまらない、新たな種類のリスクが生まれています。

前進するためには、実際に何が変化しているのか、そしてそれを実際の運用でどのように測定し、保護するのかを、より正確に捉える必要があります。

AIシステムで何が変わるのか?

AIシステムを効果的に保護するには、何が異なるのかを正確に把握する必要があります。大まかな違いだけでなく、リスクが実際にどのように顕在化するかまで理解しなければなりません。実務上、重要となる変化は3つあります。

1. インプットがコントロールプレーンの一部になる

従来のシステムでは、インプットは検証する対象でした。AIシステムでは、インプットが実行時の振る舞いを形作ります。プロンプト、検索されたドキュメント、システム指示、ツールのアウトプット、AIエージェントのメモリは、単にシステム内を流れるデータではありません。システムが次に何をするかに直接影響します。つまり、これらはデータプレーンだけでなく、コントロールプレーンの一部なのです。プロンプトインジェクションが単なるインプット検証の問題ではないのは、このためです。プロンプトインジェクションは、システムの振る舞いを乗っ取る手段になります。

これによって変わること:

  • 検索されたコンテンツやアウトプットを含む、すべてのインプットを信頼できないものとして扱う必要がある
  • インプットを許可するかどうかだけでなく、そのインプットをどのように解釈し、どう行動に移すかについても制御が必要になる
  • テストの重点が、妥当性の検証から敵対的な操作への耐性評価へと移る

2. AIシステムはユーザーが意図した以上の権限で行動する可能性がある

従来のモデル:
ユーザー → アクション → 権限チェック

AIシステム:
ユーザー → AIモデル → システムID → アクション

AIシステムでは、AIモデルが意図を解釈し、多くの場合、共有されたIDや過剰な権限を持つIDを使用してアクションが実行されます。そのため、ユーザーに許可されていること、ユーザーが意図したこと、システムが実際に行うことの間にギャップが生じます。IDは依然として重要ですが、それだけでは十分ではありません。意図の検証と組み合わせ、認証時だけでなく、アクションの実行時点で適用する必要があります。

これによって変わること:

  • 認可は、セッション開始時だけでなく、アクションの実行時点で行う必要がある
  • AIのアクションは、必要最小限の権限に限定する必要がある
  • AIによるアクションに共有サービスアカウントを使用することは、リスクの高いパターンになる
  • 「ユーザーに代わって行動する」ことを明示し、範囲を限定し、監査可能にする必要がある
  • IDだけでなく、意図も検証する必要がある

3. 振る舞いは確率的で、障害は予測できない

従来のシステムは、一貫した形で障害が発生する傾向があります。AIシステムはそうではありません。ほとんどの場合は正しく動作していても、発生頻度が低く、再現が難しく、ひとたび発生すると大きな影響を及ぼす形で失敗することがあります。リスクは一定のシグナルとして現れるのではなく、外れ値として現れます。

これによって変わること:

  • もはや「これは安全か?」と問うのではない
  • 「敵対的な条件下で、どの程度の頻度で失敗するのか?」「失敗した場合の影響はどの程度か?」と問う
  • セキュリティの重点が、継続的な評価、実行時の監視、検知と封じ込めへと移る

こうした変化は、プロンプトインジェクション、データ漏えい、意図しないアクションなど、現在多くの企業が直面している問題の根底にあります。そして、より大きな結論を示しています。AIシステムの保護は、新たなコントロールを追加するだけの問題ではありません。振る舞いを生成し、その振る舞いに基づいて行動できるシステムにおいて、「安全」が実際に何を意味するのかを再定義することなのです。セキュリティプログラムは、ここから進化していく必要があります。

AIシステムにおける「安全」とは?

コントロールプレーンが変化したのであれば、「安全」の定義もそれに合わせて変える必要があります。アクセスを保護し、脆弱性を減らし、制御を適用するという従来の定義は、今も必要です。しかし、それだけでは十分ではありません。

より実用的な捉え方は、次のとおりです。AIシステムが安全であるとは、操作に耐え、振る舞いに対する制約を適用し、障害を可視化できる状態であり、アクションの実行時点でIDと意図が常に一致していることです。

この定義は、実際に検討し、測定できる4つの要素に分けられます。

1. 操作に対する耐性がある

最初に問うべきなのは、モデルが「安全」かどうかではなく、システムが操作され得るかどうかです。

AIシステムは、インプットに対して非常に敏感です。プロンプト、検索されたドキュメント、メモリ、ツールのアウトプットは、単にシステム内を流れるデータではなく、システムが次に何をするかを積極的に形作ります。つまり、攻撃者は従来型の脆弱性を悪用する必要はありません。適切なインプットに、適切な方法で影響を与えるだけでよいのです。

プロンプトインジェクションが非常に効果的なのは、このためです。システムを破壊するのではなく、別の方向へ誘導します。実際には、明確な攻撃というよりも、振る舞いのドリフトとして現れます。システムは、表面的には妥当に見える形で、徐々に本来意図された振る舞いから外れていきます。これが検知を難しくする理由の1つです。

したがって、「いくつかのプロンプトでテストし、問題なく見えた」というだけでは十分ではありません。持続的な敵対的圧力の下で、システムがどのように振る舞うのかを把握する必要があります。どの程度簡単に誘導できるのか?どのインプットが高リスクのアクションに実際に影響するのか?そして、振る舞いが誤った方向へ動き始めたことを、どれほど迅速に検知できるのかを確認しなければなりません。

自社のシステムを積極的に操作しようと試みていなければ、そのシステムがどの程度の耐性を備えているのかを本当の意味では把握できません。

2. 振る舞いが制約されている

現在のAIセキュリティの多くは、依然としてモデルが「正しいことをする」ことに依存しています。これは制御ではありません。AIモデルはたいていの場合、指示に従うことが得意です。しかし、セキュリティが破綻するのは、まさにその「たいていの場合」から外れたときです。エッジケースでは、AIモデルが予測不能な振る舞いをする可能性が最も高くなります。

より重要な問いは、AIモデルが誤った場合でも、システムが実際には何を実行できるのかということです。AIモデルがAPIの呼び出し、機密データへアクセスして、ユーザーに代わるアクションの実行を決定した場合、何がその境界を強制するのでしょうか。そこには実際の制御があるのでしょうか?それとも、よく書かれたプロンプトがあるだけなのでしょうか?

堅牢なAIシステムでは、意思決定と強制を分離します。AIモデルには解釈と提案を任せる一方で、実際に何が起こり得るかについては、厳格な制約を設けます。

  • 呼び出すことのできるツール
  • アクセスできるデータ
  • 追加のチェックを必要とするアクション

こうした制約があれば、不適切なモデルアウトプットを限定的な問題にとどめられます。制約がなければ、インシデントに発展する可能性があります。したがって、実務上のテストは単純です。AIモデルが誤った振る舞いをした場合、実際にどの程度の損害を引き起こし得るのかです。

3. 障害を可視化できる

AIシステムへの移行で特に難しい点の1つは、障害が障害らしく見えないことです。システムがクラッシュしたり、エラーを返したりするわけではありません。一見もっともらしいものの、実際には誤っている、安全ではない、あるいはポリシーに違反する内容を生成します。

そのため、従来のセキュリティ監視だけでは不十分です。システムの健全性を見るだけでなく、システムの振る舞いを理解しようとしなければなりません。意思決定がどのように行われたかを把握できる必要があります。

  • AIモデルが受け取ったインプット
  • 含まれていたコンテキスト
  • それらがどのようにアウトプットへ変換されたか
  • その後、どのようなアクションが実行されたか

もう1つの課題は、検知です。多くの問題はユーザーから報告されず、報告されたとしても再現が困難です。そのため、問題を能動的に特定できる必要があります。こうした問題は、システムが誤用されたり、操作されたりしていることを示す振る舞いのパターンとして現れます。多くのセキュリティチームは、まだこの進化の初期段階にあります。ログは存在していても、調査を支援できる形で構造化されていません。監視は存在していても、振る舞いではなく稼働状況に焦点を当てています。

システムがどのように振る舞っているかを確認できなければ、そのセキュリティについて意味のある主張をすることは困難です。

4. IDと意図が一貫して適用される

ここに、AIシステムがもたらす、より見えにくいものの深刻なリスクの1つがあります。従来のシステムでは、IDとアクションは密接に結び付いています。ユーザーが認証を行い、アクションを試みると、システムがその実行を許可されているかどうかを判断します。

AIシステムでは、その間にもう1つのステップが加わります。ユーザーがインプットし、AIモデルがそのインプットを解釈した後、システムがアクションを実行します。その際、多くの場合、ユーザー本人とは異なるIDが使用されます。

ここでずれが生じ始めます。AIモデルは意図を誤解したり、操作されて別の意味に解釈したりする可能性があります。さらに、共有されたIDや過剰な権限を持つIDでアクションが実行されると、ユーザーが実際には意図していないことや、許可されるべきでないことをシステムが行う経路が生まれます。

ユーザーが誰であるかを把握するだけでは十分ではありません。ユーザーが実際に何を意図したのかも検証し、システムがその境界内で行動するようにしなければなりません。実務上は、次のことを意味します。

  • AIによるアクションでは、共有された過度に広範なIDを避ける
  • アクションが実行される時点で認可を適用する
  • 高リスクの操作には、確認、追加認証、またはその両方を導入して、意図的に手順を追加する
  • ユーザー入力 → AIモデルによる解釈 → アクションという一連の流れを追跡できるようにする

ID、意図、アクションの整合性が失われると、セキュリティが長年依存してきた中核的なコントロールメカニズムの1つを失うことになります。そして、そこから小さな問題が実際のインシデントへと発展します。

セキュリティプログラムはどう進化すべきか?

これら4つの特性を真剣に捉えるなら、既存のプログラムにいくつかの新しい制御を追加するだけでは不十分です。制御が実際に存在する場所そのものを変える必要があります。

1. 振る舞いのためのコントロールプレーンが必要

多くの組織では、「このシステムには、実際に何をすることが許可されているのか?」という基本的な問いに、明確かつ明示的に答える方法がありません。

現在、振る舞いは通常、暗黙的に定義されています。プロンプト、システム指示、アプリケーションロジック、AIモデルが提供するガードレールに分散して存在しています。ほとんどの場合は機能しますが、IDやアクセスポリシーを監査するのと同じように、明確に定義し、適用し、監査できるものではありません。AIモデルが誤る、あるいは操作される可能性を前提にした瞬間、これが問題になります。

不足しているのは、振る舞いのための明示的なコントロールプレーンです。許可されるアクションと許可されないアクションを明確に定義し、さらに重要なこととして、AIモデルの外部に強制ポイントを設ける必要があります。AIモデルは提案や解釈を行えますが、何が起こるかを決める最終的な権限を持つべきではありません。このように考え始めると、問いは「このシステムは何にアクセスできるか?」から「このシステムは実際に何を実行できるのか?」へと変わります。後者の方が、こうした環境のリスクを検討するうえで、より有用な問いです。

2. アクションの実行時点でIDが有効に機能しなければならない

AIシステムにおいてもIDは不要になりません。しかし、誤った扱いをしてしまう可能性は格段に高くなります。

現在よく見られるのは、ユーザーがシステムとやり取りし、AIモデルがリクエストを解釈した後、広範な権限を持つシステムレベルのIDを使用してアクションが実行されるパターンです。表面的には、依然としてユーザーが制御しているように見えます。しかし実際には、意図を再解釈し、ユーザー本人よりも強い権限でアクションを実行できるレイヤが加わっています。

ここで、IDはコントロールとしての有効性を失い始めます。ID自体は存在していても、実行されるアクションと密接に結び付いていないからです。これを修正するには、ユーザーの認証時だけでなく、実際にアクションが行われる時点でIDを適用しなければなりません。そのためには、可能な限りユーザー単位または厳密に委任されたIDを使用し、AIによるアクションでは共有サービスアカウントを避け、リスクの高い操作には追加のチェックを導入する必要があります。

重要なアクションはすべて、特定のユーザー、そのユーザーが依頼した内容、システムがその依頼をどのように解釈したかまで追跡できる必要があります。この連鎖が途切れれば、IDは期待されるレベルのコントロールを提供できなくなります。

3. ユーザーを認証するだけでなく、意図を検証する必要がある

IDが正しく機能していても、すぐに明らかになる別のギャップがあります。システムが、ユーザーの実際の意図に基づいて行動していない可能性があることです。

AIシステムは、インプットとアクションの間に翻訳レイヤを追加します。AIモデルは自然言語を受け取り、それを解釈し、振る舞いへと変換します。この翻訳は本質的に不完全です。システムはユーザーの意図を解釈しなければなりませんが、必ずしも正しく理解できるとは限りません。わずかにずれることもあれば、想定外のコンテキストに影響されることもあり、完全に操作されてしまうこともあります。その結果、技術的には認可されているものの、依然として誤っている、あるいは安全ではないアクションが実行されるという、新たな障害モードが生まれます。

この問題に対処するには、コントロールモデルに何らかの意図検証を導入する必要があります。実務上は、システムに何が許可されるかをより構造化し、完全に自由度の高い実行から、明確なパラメータを持つ定義済みのアクションへ移行することを意味します。また、機密性の高い操作には、確認、追加認証、またはその両方を加え、ユーザーが依頼した内容とシステムが実行しようとしている内容を比較できるようにする必要があります。

この段階では、アクションが許可されているかどうかだけを問うのではありません。そのアクションがユーザーの意図を正確に反映しているかどうかも問うことになります。これは、異なるものの同じように重要な問いです。

4. セキュリティは実行時へ移行する

もう1つ、すぐに明らかになる変化は、こうしたシステムが導入後も静的なままではないことです。新しいプロンプト、新しいデータ、新しい連携、場合によっては基盤モデルの変更など、利用方法に応じて進化します。

こうした変化は、事前に完全に予測することが難しい形で振る舞いに影響します。つまり、ある一時点での評価だけではもはや十分ではありません。意味のあるリスクの多くは、実際の利用下にある本番環境で初めて顕在化します。そのため、セキュリティは実行時へと近づいていきます。

システムが設計どおりにどのように振る舞うはずかだけではなく、実際にどのように振る舞っているかを把握する必要があります。振る舞いがドリフトし始めたことを検知し、その原因が操作、誤用、あるいは大規模な利用で顕在化したエッジケースなのかを判断しなければなりません。また、すべてを停止する以外の対応方法も必要です。実務上、これは継続的な評価に近いものになります。振る舞いを監視し、パターンを特定し、時間をかけてコントロールを強化していきます。

5. システムの障害の発生形態を反映した指標が必要

より実務的な課題の1つは、既存のセキュリティ指標の多くが、こうした変化を十分に捉えられないことです。

強固な基礎、つまり確実なパッチ適用、適切なアクセス制御、問題のない監査結果があっても、AIシステムが操作されたり、安全ではない振る舞いへと誘導されたりする可能性は残ります。これらの指標は、別の種類のリスクを測定するために設計されているからです。

代わりに必要なのは、こうしたシステムが実際にどのように失敗するかを反映した指標です。意図した振る舞いからどの程度の頻度で逸脱させられるのか、敵対的な条件下でガードレールがどの程度有効に機能するのか、ポリシーに違反するアウトプットやアクションがどの程度の頻度で発生するのか、そして、そうした問題をどれほど迅速に検知し、対処できるのかといった指標が含まれます。

これらは明確な二値指標ではなく、確率的かつ方向性を示す指標になる傾向があります。しかし、従来の指標よりも、リスクへのエクスポージャをはるかに正確に示します。

セキュリティの転換点

視点を広げると、これは単に新たなリスクや新たな制御の問題ではありません。何を保護しようとしているのか、その対象が変化しているのです。

長い間、セキュリティはシステムの保護とアクセスの制御を基盤としてきました。このモデルは今も重要であり、なくなることはありません。しかし、システムが比較的予測可能な形で振る舞うことを前提としています。

AIは、その前提を崩し始めています。

私たちは今、インプットを解釈し、意思決定を行い、アクションを実行するシステムを導入しています。しかも多くの場合、事前に完全には列挙できないコンテキストやシグナルに基づいています。リスクは、誰かが本来アクセスすべきでない情報にアクセスすることだけではありません。アクセス制御が技術的には設計どおりに機能していても、システムが実行すべきでないことを実行する可能性があります。

Boxでは、AIが情報を理解する段階から、その情報に基づいて行動する段階へと移行するなかで、コンテンツをどのように保護すべきかを検討する際、この変化が重要な要素となっています。AIモデルやAIエージェントは変化していきます。しかし、それらがどのコンテンツにアクセスできるか、そのコンテンツに対して何を行えるか、そしてアクションをどのようにガバナンスするかを制御する仕組みは、持続的に機能する必要があります。

私が繰り返し立ち返るのは、「安全」という概念には、実際の条件下でシステムがどのように振る舞うかを含めなければならないということです。システムが操作され得るか、アクションが意味のある形で制約されているか、IDと意図が整合し続けているか、そして振る舞いがドリフトし始めたときに、それを把握して対応できるかを考慮する必要があります。

これは、多くのセキュリティプログラムが想定していた基準よりも高いものです。しかし同時に、私たちが現在構築しているシステム、そして今後その保護に責任を負うことになるシステムを、より正確に反映した基準でもあります。

関連リンク

このブログは Box, Inc 公式ブログ(https://blog.box.com/)2025年8月17日付投稿の翻訳です。
著者: Heather Ceylan, Chief Information Security Officer at Box
原文リンク: https://blog.box.com/rethinking-what-secure-means-ai-systems
わかる!エージェント型ワークフローで業務を自動化する方法

RECENT POST「AIリサーチ」の最新記事


AIリサーチ

Gemini 3.7 Flashを実際の企業ナレッジワークで検証

AIリサーチ

テストすべきはAIモデルではなく、サンドボックスだった

AIリサーチ

エージェンティックガードレール: AIガバナンスの次なる段階は「制御」

AIリサーチ

AI活用のために始めるべきメタデータ整備