脅威からフレームワークへ──Agentic AI時代の7つの能力領域、あなたの企業はどの成熟度にあるか
7つの能力領域と3段階の成熟度モデル：従来とは異なる防御の考え方へ
前回の記事を読み、「脅威ごとに対策製品を導入すれば十分ではないか」と考えた方もいるかもしれません。しかし、その発想はいったん立ち止まって見直す必要があります。
脆弱性を一つずつ塞いでいくという考え方は、攻撃の多くが人手で行われていた時代には一定の効果がありました。しかし、攻撃者自身がAIエージェントを活用するようになった現在では、新たな攻撃手法が生まれるスピードは、従来のセキュリティ対策だけでは追いつけない水準に達しつつあります。
本稿で取り上げるのは、新たな脅威ごとに対策を追加することではありません。Agentic AI時代に求められる、新しい防御の考え方です。
Zero Trustという考え方は、1994年にStephen Paul Marshがスターリング大学（University of Stirling）の博士論文で体系的に提唱したことに始まります。その後、2020年には米国国立標準技術研究所（NIST）がSP 800-207を公開し、Zero Trust Architectureの具体的な指針を示しました。
Anthropicは『Zero Trust for AI Agents』において、この考え方をAgentic AIという新たな攻撃領域へ適用し、実装レベルまで落とし込んだ7つの能力領域を提示しています。
3段階の成熟一つの原則、三つの基本原則度は、選択肢ではなく成長プロセス
Zero Trustの考え方は、一言で言えば次のとおりです。
「何も信頼せず、すべてのアクセスを検証し、侵害はすでに発生していることを前提とする。」
これを具体化すると、次の三つの基本原則になります。
- 常に検証する（Never Trust, Always Verify）：すべてのアクセス要求は、認証と認可を経る必要があります。企業ネットワーク内部からのアクセスであるという理由だけで、特別な信頼を与えることはありません。
- 侵害を前提とする（Assume Breach）：システムは、侵入や不正利用が発生することを前提として設計します。重要なのは侵入そのものを完全に防ぐことではなく、侵害が発生した場合でも、攻撃者が及ぼせる範囲や影響を最小限に抑えることです。
- 最小権限（Least Privilege）：業務遂行に必要な最小限のアクセス権限だけを付与します。万が一、認証情報やAIエージェントが悪用された場合でも、被害を限定的な範囲にとどめることを目的とします。
しかし、これらの原則以上に重要なのが、一つの判断基準です。
その対策は、攻撃を「不可能」にするものなのか。
それとも、単に攻撃を「面倒」にしているだけなのか。
踏み台サーバーの追加、レート制限、標準とは異なる通信ポートの利用など、「攻撃の手間を増やす」ことを目的とした対策は、一回あたりの攻撃コストが限りなくゼロに近い自動化された攻撃者に対しては、防御効果が大きく低下します。
一方、本当に有効なセキュリティ制御には共通する特徴があります。
- ハードウェアに紐づいた認証情報
- 有効期限を持つトークン
- 暗号技術に基づくID
- そもそも到達できないネットワーク経路
これらはいずれも、攻撃者の行動そのものを制限する仕組みです。
この考え方は、これから紹介する7つの能力領域すべてに共通する判断基準となります。
3段階の成熟度は、選択肢ではなく成長プロセス
Anthropicは、各能力領域をFoundation、Enterprise、Advancedの3段階の成熟度モデルとして整理しています。EnterpriseはFoundationを土台として構築され、AdvancedはEnterpriseの上にさらに高度な制御を積み重ねる構造です。つまり、この3段階は別々の選択肢ではなく、既存のセキュリティ対策を段階的に強化していく成長プロセスを示しています。
Foundationは、Zero Trustへ移行するための出発点です。Enterpriseは、一定規模以上の企業が目指すべき現実的な到達目標であり、Advancedは、高度な規制産業や重要インフラ、あるいは障害発生時の影響が極めて大きいAIエージェント環境を想定したレベルです。
ここで重要なのは、前回の記事で紹介したように、攻撃スピードそのものが大幅に加速していることです。その結果、Foundationで求められる基準そのものが、以前よりも大きく引き上げられています。
例えば、かつてはAPIキーを定期的にローテーションするだけでも、一定のリスク管理策として受け入れられていました。しかし現在では、それだけでは十分とは言えません。
短い有効期限を持つトークン、暗号技術に基づくID、IDベースの分離、自動化された初動アラートのトリアージ。これらは、もはや高度な追加機能ではなく、Foundationで備えておくべき基本要件になりつつあります。
七つの能力領域は、基盤からガバナンスまでをつなぐ一つの防御チェーン
Agent Identity and Authentication（エージェントのIDと認証）
ID管理は、すべての制御の土台です。検証可能なIDがなければアクセス制御は機能せず、どのAgentが何を実行したのかも追跡できません。成熟度は、暗号技術に裏付けられた永続IDからライフサイクル管理された証明書認証へ、最終的にはHSMとリモートアテステーションを組み合わせたハードウェアバインド型IDへ進みます。
IDを持つだけでは十分ではありません。Agentはサービスへアクセスするたびに、自身の正当性を証明する必要があります。認証も短寿命トークンからmTLS、さらにハードウェアバインド証明書へと高度化します。APIキーのローテーションだけでは、ライブラリから取得可能な認証情報である限り、攻撃者の負担はほとんど変わりません。
Access Control and Privilege Management（アクセス制御と権限管理）
正規の権限を持つAgentで問題になるのは、「誰か」ではなく「何をするか」です。成熟度は、RBACによるデフォルト拒否から、時間・場所・リスクスコアなどを考慮するABACへ、最終的には操作のたびに再評価するリアルタイム認可へ進みます。
OWASPが提唱するLeast Agencyは、最小権限をさらに一歩進めた考え方です。どのツールを使えるかだけでなく、何ができるか、どれだけ頻繁に使えるか、どこで使えるかまで制御対象とします。例えばデータベースツールには検索権限だけを与え、更新や削除は許可しません。
RBACとABACの違いも重要です。RBACは「そのAgentは何者か」という役割だけで権限を決めます。一方ABACは、時間・場所・データの機密度・リスクスコアなど実行時の状況も判断材料に加えます。同じカスタマーサポートAgentでも、通常業務中の顧客検索は許可され、深夜に大量の機密データへアクセスしようとすれば拒否や追加認証が求められます。RBACからABACへの移行とは、「誰か」という静的判断から、「今何をしようとしているか」という動的判断への転換です。
権限モデルが決めるのは「許可するかどうか」ですが、権限管理は「いつまで許可するか」も重要です。静的権限はタスク終了後も残り続け、長期的なリスクになります。動的権限は必要な間だけ一時的に昇格し、終了後すぐに回収されます。さらにJIT/JEAでは、権限付与そのものを実行直前まで遅らせ、必要最小限・最短時間だけ利用を許可します。
最後はリソース境界です。基本はネットワークではなくIDベースで分離し、成熟度が上がるにつれてコンテナサンドボックス、最終的にはハードウェア分離へ進みます。不正入力を扱うAgentにとって、サンドボックス実行は追加機能ではなく標準要件です。
Observability and Auditing（可観測性と監査）
アクセス制御が「何を防げるか」を決めるなら、可観測性は「実際に何が起きたか」を明らかにします。ログはタイムスタンプ付き記録から改ざん耐性を持つ監査ログへ、さらに集中監視基盤へのリアルタイムストリーミングへ発展します。
成熟度より先に整備すべきなのが二つの指標です。一つは異常発生から人が認識するまでの時間を示すDwell Time、もう一つはアラートのうち実際に調査まで至った割合を示すCoverageです。AIによる自動化が最も効果を発揮するのは、この二つの改善です。
もう一つ重要なのがトレーサビリティです。各リクエストへ一意のIDを付与し、その後のすべての処理へ引き継ぐことで、複数Agentにまたがるワークフロー全体を追跡できます。ログが「何が起きたか」を示すなら、トレーサビリティは「なぜそうなったか」を示します。
Behavioral Monitoring and Response（行動監視と対応）
異常を検知するには、まず正常状態を知る必要があります。ベースラインは手作業で定義したルールから始まり、統計的学習、自律的に更新されるベースラインへと進化し、Memory Driftのような緩やかな変化も検知できるようになります。異常検知も閾値ベースから統計モデル、さらにコンテキストを含めた機械学習へ発展します。
異常検知以上に重要なのは、その後の対応速度です。AIが担うべきなのはログ収集、証跡保全、報告書作成などの定型作業であり、封じ込めや公表、顧客対応の判断は人が担います。対応能力も、アラート通知とトリアージAgentによる初期分析から、自動封じ込め、最終的には複数システムを横断するAgentic SOARへと成熟します。自動化の目的は、人の判断を置き換えることではなく、判断までの時間を短縮することです。
もう一つ重要なのがトレーサビリティです。各リクエストへ一意のIDを付与し、その後のすべての処理へ引き継ぐことで、複数Agentにまたがるワークフロー全体を追跡できます。ログが「何が起きたか」を示すなら、トレーサビリティは「なぜそうなったか」を示します。
Input Validation and Output Controls（入力検証と出力制御）
この領域が対処するのは間接プロンプトインジェクションです。入力検証はフォーマットチェックから始まり、エンコードされたペイロードや不審な命令のフィルタリングへ、さらにAI分類器とコンテンツ境界を組み合わせた多層防御へ発展します。自然言語入力は自由形式で予測が難しく、ルールベースだけでは十分に防げません。
一方、出力制御が防ぐのは情報漏えいです。機密情報のパターン検出から、出力内容の意味解析やソーシャルエンジニアリングの検知へ、最終的には高リスクな操作に人の承認を必須とします。入力検証は攻撃を防ぎ、出力制御は情報流出を防ぐものです。どちらか一方だけでは不十分です。
Integrity and Recovery（完全性とリカバリー）
侵害が発生すると、攻撃者はAgentそのものではなく設定や実行環境の改ざんを狙います。成熟度はバージョン管理から電子署名、さらにImmutable Infrastructureへ進みます。設定を修正するのではなく、安全性を確認した新しい環境へ丸ごと置き換え、実行前にはイメージの完全性を検証します。
興味深いのは、リスクを十分に管理できるコンポーネントでは、自動更新のほうが手動承認より安全な場合があることです。更新遅延そのものが攻撃機会になるためです。署名済み更新だけを自動適用し、署名されていない変更は拒否することで、安全性と更新速度を両立できます。
リカバリーも、文書化されたロールバックから自動ロールバック、最終的には自己修復システムへ進化します。既知の正常状態へ確実に戻せない環境では、高度な自動化も十分な効果を発揮できません。
AI Governance Policies（AIガバナンスポリシー）
技術的な制御は、ガバナンスで定義されたルールを実装する手段です。成熟度は利用ポリシーの文書化から、セキュリティ・法務・事業部門を含む全社ガバナンスへ、さらにデプロイプロセスへ組み込まれた自動ポリシーチェックへ進みます。
ここで無視できないのがShadow AIです。従業員が承認されていないLLMやAIツールを利用すると、認証、アクセス制御、監査、データ保護といった仕組みをすべて迂回してしまいます。ガバナンスとはルールを作ることではなく、それを企業全体で守れる仕組みを作ることです。
七つの能力領域は、一つの防御チェーンである
七つの能力領域を見ても、新しい攻撃手法が現れるたびに対策を増やす必要はありません。確認すべきなのは、自社のAgentがこの七つの領域でどの成熟度にあるかです。
ID管理はアクセス制御と責任追跡の前提となり、可観測性は何が起きたかを明らかにし、行動監視は異常を検知します。入力・出力制御は境界で攻撃と情報漏えいを防ぎ、完全性とリカバリーは侵害後の復旧を支えます。そしてAIガバナンスが、そのすべてを継続的に運用する土台になります。どれか一つでも欠ければ、そこが攻撃者の侵入口になります。
次回は、このフレームワークを実装へ落とし込みます。攻撃速度が「日単位」から「時間単位」へ短縮される時代に、企業のセキュリティ運用はどのように変わるべきかを具体的に見ていきます。