最も困難なAIセキュリティ課題がモデルの外側に現れる

この 2026 OWASP Top 10 for LLM Applications は、実運用AIの成熟度を示す重要な視点を提供します。これは、業界がサンドボックスを超えて、実世界での統合の複雑さに取り組んでいるという重要な転換を捉えています。

LLM をエンタープライズツールやワークフローに接続すると、脅威の表面は根本的に変化します。権限やリソース利用に関わるリスクは格段に抑制が難しくなります。同時に、出力処理の不適切さといった脆弱性が表面から後退しているのは、解決されたからではなく、他の問題が前面に押し上げられたためです。

OWASP Top 10 のランキングはこの変遷を反映しています。”Excessive Agency” は6位から3位に上昇し、”Unbounded Consumption” は6位に上がりました。対照的に “Improper Output Handling” は10位に低下しました。

これは出力処理のリスクを軽減するものではありません。LLM の応答が厳格な検証なしにシェルやデータベースに届くと、従来のインジェクション脆弱性が依然として残ります。しかし、パラダイムは変わりました。エージェント型システムでは、モデルの応答は最終目的地ではなく、権限を伴う入力となります。モデルが認証情報を保持したり API とやり取りしたりする場合、その出力は異なるシステム間でアクションを引き起こすベクターとして機能します。

セキュリティ課題はもはや単にモデルを評価することに留まらず、推論後に何が起こるかの境界を定義することにあります。アーキテクチャは、幻覚的な出力がテキストに留まるのか、あるいは不正なデータベース変更として具現化するのかを決定します。

ランキングは被害に従う

OWASP は 7,714 件のインシデントを活用し、そのうち 75% がコミュニティ合意に基づき、25% が実証的インシデントデータに基づいています。この証拠ベースにより、優先順位の実質的な再編成が迫られました。

“Excessive Agency” が上昇したのは、実運用環境の現実が理論に追いついたためです。組織は必要なコントロールプレーンを整備する速度よりも、自治機能の展開を加速させています。重要な脆弱性は、モデルが提供する回答そのものだけでなく、その回答が実行される認可コンテキストにあります。

“Improper Output Handling” は依然として懸念事項ですが、DevOps チームはスキーマ検証やパラメータ化クエリを通じて下流のシンクを保護する能力を成熟させました。これらは確立されたアプリケーションセキュリティの実践です。

しかし、Agency は別種の問題です。ツール呼び出しは構造的には有効でも、文脈上は不正になることがあります。モデルが承認された関数を不適切なタスクに使用したり、誤ったリソースを対象にしたりする可能性があります。静的なサニタイズでは意図を判断できません。これには、モデルが単独で実行すべきでない、洗練された文脈認識型の認可が必要です。

すべてのツールを公開された機能として扱う

多くのチームはツール定義を単なる統合配管とみなしています。これは非常に笑える根本的な誤りです。すべてのツール、コネクタ、API エンドポイントは AI アプリケーションの影響範囲を拡大します。

メールボックスを要約するエージェントを考えてみてください。実装が書き込みや削除機能を含む広範なコネクタを使用すると、最初のプロンプトが処理される前に過剰な機能を導入してしまいます。

最小特権の原則を適用しなければなりません：

• インターフェースを絞る：汎用コネクタではなく、読み取り専用ツールをエージェントに提供する。
• スコープ付きコンテキスト：ユーザーの OAuth スコープ付き ID でリクエストを実行する。
• Policy Enforcement Points (PEP)：モデルと下流システム間の必須ミドルウェアとして認可ロジックを実装する。すべてのアクションは実行前にポリシーで検証されなければならない。
• Human-in-the-loop (HITL)：取り消しが困難または重大な影響を持つ操作には明示的な承認を要求する。

このアプローチはデリバリーパイプラインの転換を必要とします。レビュー工程はモデルに留まらず、ツールスキーマ、サービスアイデンティティ、権限スコープの変更も対象としなければなりません。モデルの更新は無害に見えても、コネクタの認可コンテキストの変更は致命的な脆弱性を生む可能性があります。

可視性は譲れません。特定のツール実行、認可されたアイデンティティ、対象システムへの変更結果をすべて記録する必要があります。この証跡はインシデント対応に不可欠であり、実行中のプロセスを中断し、インシデント後に監査ログを再構築することを可能にします。

すべての自律実行にはハードストップが必要

「Unbounded Consumption」は、リクエスト量がリソースリスクの指標として不十分であるため急増しました。短く簡潔なプロンプト一つで、再帰的かつリソース集中的なツール呼び出しの連鎖を引き起こす可能性があります。エージェントが完了するまでメーターは止まりません。

実行速度が人間の対応を上回る場合、単純なアラートでは不十分です。エージェントの制御外にある決定的なハードリミットが必要です。トークン使用量、経過時間、再帰深度、累積運用コストに対して厳格な上限を設定します。実行がこれらのパラメータを超えた場合、システムは実行を終了またはスロットルしなければなりません。

運用範囲にも同様の厳格さが求められます。エージェントが変更できるレコードの最大数を決定し、タスク伝搬の境界を定義してください。もしアーキテクチャに決定的な「停止」メカニズムが欠如している場合、実質的に権限を委譲したものの、その範囲を定めていないことになります。

間違った答えに備える

システム工学は長らく、信頼性の低いコンポーネントを保護するためにレジリエントなアーキテクチャに依存してきました。コンポーネントの故障やネットワークの不安定さを前提とし、その前提からセキュリティが導かれます。完璧さの錯覚からではありません。LLM も同様のアーキテクチャ的規律が必要です。

完璧なモデル整合性を前提にしたセキュリティ戦略を構築しないでください。善意の誤解であれ悪意のある悪用であれ、失敗を想定してください。エージェントの機能は絶対に必要最低限に抑え、すべての下流呼び出しに対して厳格なユーザー認可コンテキストを維持します。重要なのは、ポリシーの実施はモデル外に存在し、プロンプトインジェクションや推論エラーが制御を回避できないようにすることです。

現在、プロンプトインジェクションは脆弱性というよりも物理法則に近いものと見なしています。常に潜んでいるのです。実際、モデル自体がセキュリティ上重要な質問に対して有効な判断者になることはできません。私が構築中の実際のエージェントプロジェクトでは、約 100 件の自動化された「レッドチーム」テストを実施しています。すべて合格させるようにしていますが、これはモデル外にハードコントロールを構築することで実現しています。モデル単体での合格/不合格率を確認すると、最も古くて弱いモデルは 17% の失敗率、最新で最大のモデルは 2% の失敗率です。大きな進歩に思えますが、失敗が機密データの漏洩につながる状況で 98% で十分でしょうか？決して十分ではありません。

高インパクトな操作は観測可能で、監査可能で、理想的には可逆的である必要があります。すべての自律実行には、モデルの手の届かない不変のガードレールが求められます。

2026 年のランキングは、AI の失敗が実質的な影響へと移行する地点を明らかにしています。モデルがミスを引き起こすことはあっても、被害範囲はアーキテクチャが決定します。実運用の AI において、最も重要なセキュリティ作業は推論後のパイプラインで行われます。