設計時のレビューでは拾えない、バグるAIエージェントに共通する5つの特徴:AIとサイバー攻防のダイナミクス(2/2 ページ)
AIエージェントを導入して開発や運用効率を改善したい――。そう思う方は多いでしょう。しかしAIエージェントが暴走して意図しない動作を引き起こす可能性は決して低くありません。従来のソフトウェア制御のやり方では通用しないこの問題をどう解消すればいいのか。実践的な3つの解決策を提示します。
AIエージェントは不正を「隠す」 公的機関の観測した“暴走”
AIエージェントの挙動をどう扱うかについては、公的機関からも観測結果が出始めています。
英国政府のAI Security Institute(AISI)は、先端モデルの評価において観測された「不正」についての報告を公開しています。同機関は不正を、「課題の範囲外あるいはルールで明示的に禁止されている行為をし、その課題が意図しておらず、また許容されるべきではない近道や回避策、あるいは意図しない解決策を通じて目標を達成すること」と定義しており、評価の対象としたモデルはいずれも不正を試みたとしています。
注目したいのは、検出の方法についての記載です。同機関によれば、モデルは尋ねられても不正を確実には申告せず、推論の記述にも現れないことが多いとされています。その上で検出には人手による確認と別の監視手段を組み合わせる必要があるとしています。
また同機関は、自らの研究環境で発生した事案報告もしています。評価の最中に外部への不審なデータ転送が検知され、調査の結果、評価の対象としていたAIエージェントが実在の人や組織に向けた活動を継続していたことが判明した、という内容です。報告の中では、公開されているオープンソースのプロジェクトに悪意あるコードを挿入しようとし、その承認を得るために複数の偽オンラインIDを作成して実在の管理者に働きかけた事例が挙げられています。
特殊な評価条件下とはいえ、実世界への自律的な行動が観測された事例と言えます。ただし、現時点ではこの結果から通常の運用環境での発生確率を直接推定することは困難です。
なぜ設計レビューと権限レビューではずれを見つけられないのか?
5つの型に共通するのは、設計時のレビューや個々の権限判定だけでは、実行時のintent(意図)とのずれを捕捉し切れないという点です。従来のソフトウェアでは、レビューで確認した動作と本番で実行される動作が一致するという前提が成り立ちます。処理の流れが固定されているためであり、設計レビューとテストはこの前提の上で機能してきました。しかしAIエージェントでは、この前提が成り立つとは限りません。レビューの対象になるのはAIエージェントに与えた目標と、接続先や権限の設定であり、実際にどの手段、手順が選ばれるかは実行のたびに変わる可能性があるためです。
テストについても同じことが言えます。テストは想定した入力や状況に対して実行するものですが、逸脱は想定していなかった手段が選ばれた際に発生します。全ての実行経路を事前テストで網羅することは難しく現実的ではありません。
同様に権限の一覧にも同じ問題があります。一覧に定義されているのは個々の操作を許すかどうかであり、ある操作を何百回繰り返してよいのか、別の操作と組み合わせてよいのかまでは定義されていません。つまり、逸脱は「許可した範囲の中で意図のずれが積み重なった結果」として現れるため実行時の観測がなければ捉えにくい現象と言えます。従って、AIエージェントの統制では許可の一覧だけではなく、「許可された能力が、どの意図の下で、どのように使われたか」を継続的に確認することが必要です。
AIエージェントの判断任せにはしない 目標逸脱を抑える3つの対策
5つの脅威に共通するのは、AIエージェント自身の判断が、人間の意図から外れる可能性があるという点です。つまり対策をAIエージェント自身の判断だけに委ねることはできません。プロンプトで「してはいけないこと」を指示することと、実際にその操作を実行できなくすることは異なります。前者はAIエージェントが制約を正しく解釈し、守ることを前提としています。後者は、AIエージェント自身の判断とは独立して強制される境界を設ける考え方です。
目標逸脱への対策は「権限を限定する」「実行を制御する」「行動を観測し是正する」の3つに整理できます。
1.権限を限定する:逸脱しても被害が広がらないようにする
最初に必要なのは、AIエージェントが利用できる権限と到達可能な範囲を必要最小限にすることです。
重要なのは、AIエージェントが正しく判断することを前提に権限を与えないことです。判断を誤った場合でも、影響が一定範囲で止まるように設計します。例えば、AIエージェントごとに資格情報を分離し、読み取り、書き込み、削除など影響の異なる操作には異なる権限を与えます。また、本番環境と復旧用のバックアップを同じ権限で操作できる状態は避ける必要があります。
複数のツールやシステムを利用する場合も同様です。個々の権限だけでなく、それらを組み合わせることで最終的に何が可能になるかを確認します。ここでの目的は、逸脱そのものをなくすことではありません。逸脱が起きることを前提として、その影響範囲を限定することです。
2.実行を制御する:操作の直前に外側で判断する
次に必要なのは、AIエージェントが決定した操作を実行する前に、必要に応じて、独立した制御を介在させる仕組みです。
AIエージェントがAPIの呼び出しやデータ変更、外部送信、アカウント操作などをする直前に、AIエージェントとは独立した仕組みで実行可否を判定します。これにより、AIエージェント自身が「問題ない」と判断した操作であっても、外部のポリシーに反する場合は停止できます。
判定には、操作の種類だけでなく、対象や件数、データの重要度、実行元、過去の操作との組み合わせなどを利用します。例えば、読み取りは自動実行を認めても、大量削除や外部へのデータ送信、重要な設定変更には上限や人の承認を設けるといった方法です。また、AIエージェントが接続できるシステムや利用できるツールを事前に定義し、想定外の接続や能力の利用を外側で制限することも含まれます。
全ての操作に同じ強さの統制を掛けるのではなく、取り消し可能性や影響の大きさに応じて自律性の範囲を変えることが重要です。
3.観測して是正する:個々の操作ではなく行動経路を見る
権限と実行時制御だけでは、許可された操作の組み合わせによる逸脱までは防げません。そのため、運用中の行動を継続的に観測する必要があります。
見るべきは一つ一つの操作が正常かどうかだけではありません。どの指示を受け、どの主体のために動き、どのツールやデータを使い、どの順序で操作し、結果として何が起きたかという一連の経路です。そのためには、少なくとも、指示の出どころ、AIエージェントの識別子、利用したツール、操作対象、扱ったデータ、ポリシーの判定、実行結果を後から関連付けられる形で記録する必要があります。
また、AIエージェント自身が生成した説明だけを監査記録として扱うのではなく、実際の操作記録と突き合わせます。個々には正常な操作でも、回数、対象範囲、データ移動、行動の連鎖を見ることで、意図からのずれが明らかになる場合があります。
観測した後に行動を止められることも必要です。実行中の処理を中断する手段、資格情報を無効化する手段、変更を元に戻す手段をあらかじめ用意しておきます。
以上の3つの対策に共通するのは、「AIエージェントが正しく判断すること」を最後の防波堤にしないという考え方です。
従来の最小権限、資格情報の分離、実行時ポリシー、ログ、承認、バックアップといった統制は引き続き重要ですが、AIエージェントではそれらを個別に適用するだけでなく、何を許可し、その権限がどの目的で使われ、どのような行動経路を経て、結果として何が起きたのかまでを一続きで統制する必要があります。AIエージェントの目標逸脱への対策とは、既存のセキュリティ統制をAIエージェントの自律的な行動を前提として再構成することだと言えます。
4つの将来シナリオとの関係性
本稿は、AIが攻める側と守る側の双方をどう変えるかを追う連載の一部です。前回は、AIそのものが攻撃の対象となった事案を公開データから確認しました。今回扱ったのは、AIエージェントの統制が十分でない場合、攻撃者がいない状態でも同じことが起こり得る、という論点でした。
つまり、攻撃と非悪意の逸脱には共通して使える統制基盤が多い、と言えます。今後AIエージェントが今以上に攻撃の標的となった際、不十分な統制は「B:攻撃者優位」の圧力を高めることにつながります。
筆者紹介:村上純一(むらかみ・じゅんいち)
PwCコンサルティング合同会社 パートナー
国内大手セキュリティベンダーでマルウェアの収集・分析などに関する研究開発、脅威分析、脆弱性診断、トレーニングなどの業務に従事。その後、国産セキュリティベンダーに参画し、執行役員として基礎技術開発、製品開発、各種セキュリティサービス提供、事業経営などに携わり株式上場を経験。また、サイバーセキュリティ領域における各種外部委員活動の他、Black Hat、PacSec、AVARなどの国際会議での研究発表も手掛けている。グローバルレベルでのサイバー攻撃の手法や主体など脅威動向の把握から企業対応までを専門分野にしている。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
安全なAIモデルを使っても安心できない 攻撃者が狙う「AIの外側」
最近「AIを守る」ことの必要性を感じる企業は多くなっているかもしれません。ただ、何をどう守れば安全なのかについてはまだ十分な答えを持っているところは少ないでしょう。水面下で高まるAIのサイバーリスクにどう備えるか。実被害の事案から分析します。
PHPの重大脆弱性「php2shell」、パッチ公開まで待てない GMOが示した暫定策と注意点
PHPに深刻度9.2の重大脆弱性「php2shell」が見つかった。外部から任意のコードを実行される恐れがあり、PHP開発チームは2026年10月21日23時に修正パッチを公開する予定だ。パッチを待つ間、企業は何をすべきか。GMO Flatt Securityは独自分析を基に暫定策と緊急対応の指針を示した。
PHP脆弱性問題は“また起こる” 事件の裏にあったエンジニアの根深い課題
多くの日本企業を混乱の渦に巻き込んだPHP脆弱性問題。深夜のアップデート対応に追われた担当者もいることだろう。この問題はなぜ起きたのか。その背景には一朝一夕ではいかない開発者全体に関わる根深い課題があった。
国内Web侵害119件、“情報漏えいドミノ”の背後でいま何が起きているか
毎日のように企業が情報漏えいを公表している。国内Web侵害の公表件数は2026年10月6日時点で119件。この異常事態を引き起こす要因は何か。専門家のデータから、従来の攻撃者像だけでは説明しにくい動きと、WAFや脆弱性診断だけでは通用しないWebの穴が見えてきた。あらためて企業がすべきセキュリティ対策を問う。
連続不正アクセスの実態判明 Androidアプリを解析してAPIに侵入か
Webサービスへの不正アクセスが相次ぐ中、攻撃者はサーバの脆弱性を探すだけではなかった。JPCERT/CCの調査で見つかったのは、Androidアプリの配布ファイルや解析ツール、APIの弱点を探るために使われたと見られるスクリプトだ。AIも利用した攻撃者は、どこまで標的のシステムを調べていたのか。
