AIエージェントのセキュリティ：エンタープライズ向けプラットフォーム選定ガイド

従来のアプリケーションセキュリティは、固定的なロジック経路をたどる決定論的なシステムのために作られました。AIエージェントのセキュリティは、それとは根本的に異なる課題です。

AIエージェントは環境を認識し、複数ステップのアクションを計画し、アウトプットを生成します——そのすべてを自律的に行います。これらの各段階は独立した攻撃対象領域であり、そのいずれか一つに隙があれば、ワークフロー全体が侵害されかねません。

最も優れたソリューションは3つのサーフェス・セキュリティモデルを実装し、データサーフェス・アクションサーフェス・アウトプットサーフェスを防御するとともに、3つすべてにわたってプロンプトインジェクション対策とハルシネーション対策の仕組みを備えています。

たとえばDevRevのComputerは、権限を考慮したAI（permission-aware AI）によるデータアクセス、Safe Actions機能群、統合されたアウトプットガードレールを備えて設計されており、後付け制御によるボルトオン税（bolt-on tax）を低減します。

もしAIエージェントは安全なのかと疑問に思っているなら、答えは「安全にできる」です——ただし、プラットフォームのアーキテクチャ、ガバナンス、運用上の制御が一体となって機能していることが条件です。

本記事では、各サーフェスの内訳、7項目のチェックリスト、そしてボルトオン税を避ける方法を読み解いていきます。

AIエージェントのセキュリティは、従来のソフトウェアセキュリティとどう違うのか？

エージェント型AI（agentic AI）のセキュリティは、LLMセキュリティを名前だけ変えたものにすぎないのではないか——そう問うのは当然です。答えは「ノー」であり、その違いはインフラを選ぶうえで重要です。

• 従来のソフトウェアセキュリティはデータを保護するために作られました。誰がファイルを読み、データベースに問い合わせ、APIにアクセスできるか、という観点です。
• LLMのセキュリティは、その対象をアウトプットにまで拡張しました。モデルが有害なことを言ったり、機微な内容を漏らしたり、プロンプトインジェクションによって危険なテキストを生成するよう操作されたりするのを防ぐ、という観点です。
• AIエージェントのセキュリティは、それら2つの懸念に加えて、第3の、根本的に異なる次元、すなわちアクションをカバーしなければなりません。
• エージェントは質問に答えるだけではありません——APIを呼び出し、データベースに書き込み、メールを送信し、ワークフローを起動し、複数の連携システムをまたいで意思決定を行います。しかも、各ステップを人間が確認しないまま行うことが少なくありません。

つまり攻撃対象領域は、1件のレコードや1つの応答ではありません。それは「結果（アウトカム）」です。AIエージェントへの攻撃が成功すると、1行のデータが漏れるのではなく、あなたの代わりに一連のアクションが実行されてしまうのです。

従来のソフトウェア、LLMによるQ&A、AIエージェントの主な違い：

なぜAIエージェントのセキュリティには専用のフレームワークが必要なのか？

なぜなら、エージェントは1回のプロンプトインジェクションの成功を、機微なレコードを読み取り、取引を実行し、結果を公開する——しかもすべて人間を介さずに行う——マルチステップ攻撃へと変えてしまえるからです。この組み合わせは、新たなリスクカテゴリーを生み出します：

• エージェントチェーンを通じた権限昇格、
• denial-of-wallet（資金枯渇）型の金銭的悪用、そして
• アクションがサービス間に波及することで生じる連鎖的障害。

本記事はセキュリティ評価に焦点を当てています。AIエージェントとは何かについては解説記事を、最適なAIエージェントビルダーの比較についてはまとめ記事をご覧ください。

3つのサーフェス・セキュリティモデル——AIエージェントのセキュリティを評価するためのフレームワーク

すべてのAIエージェント基盤は、3つの異なる攻撃対象領域を防御しなければなりません。データサーフェス（エージェントが何を見られるか）、アクションサーフェス（エージェントが何をできるか）、アウトプットサーフェス（エージェントが何を言うか）です。これらが一体となって、本記事の軸となるフレームワーク「3つのサーフェス・セキュリティモデル」を形づくります。これらは、あらゆるベンダー評価やエンタープライズAIセキュリティの議論における主要な視点であるべきです。

3つのサーフェス・セキュリティモデル：

なぜこのフレームワークがエンタープライズにとって重要なのか？

多くのベンダーは1つのサーフェス（強力なデータ制御など）をうまく防御したり、アウトプットの整合性に注力したりしています。しかし、3つすべてにわたって一貫した保護を保証できるのは、プラットフォームレベルのアーキテクチャだけです。

これこそが、あらゆるAIエージェント・セキュリティ基盤を見分ける試金石です。各サーフェスを独立して防御しているのか、それとも1つの隙を塞げば自動的に他も塞がるのか。アーキテクチャ優先のプラットフォームは後者を実現します。後付け型のプラットフォームでは、各サーフェスを個別の構成上の課題として管理する必要があり、継続的なコストと複雑さが伴います。

ベンダーを評価する際は、こう問いましょう。最も弱いサーフェスはどれか、そしてその弱さはアーキテクチャ上のものか、それとも単に設定で対処できるものか。アーキテクチャ上の弱さ（例：後付けのアウトプットフィルターや、能力チェックのない外部アクションアダプター）は、ボルトオン税を招きます。

ボルトオン税——なぜ後付けのAIエージェント・セキュリティは失敗するのか？

すべてのAIプラットフォームは、早い段階でアーキテクチャ上の選択を迫られます。AIエージェントのセキュリティを組み込むのか、それとも顧客に後付けで構成させるのか。この選択が、導入期間を通じて誰が運用負荷を背負うかを決定づけます。

ボルトオン税とは、後者を選んだ場合に生じる継続的なコストです。それは、保守が必要な設定ファイル、レビューが追いつかないほど膨れ上がる例外リスト、モデル更新のたびに壊れるカスタムガードレール、そして毎四半期セキュリティチームの時間を奪う手動の監査プロセスとして現れます。

こうした作業は何ら新たな能力を生み出しません——アーキテクチャ優先のプラットフォームなら標準で提供される最低水準を、ただ維持しているにすぎないのです。

対照的に、RBAC、セマンティックなアウトプットチェック、監査証跡がプラットフォームに本来備わっていれば、安全なAI導入は長期的にはより低コストになります。

出典：LinkedIn、2026年

このクエリ実行時の適用モデルは、ゼロトラスト・アーキテクチャの原則「決して信頼せず、常に検証する」と合致します。

エンタープライズのAIエージェント・ガバナンスにおいては、IDプロバイダーや既存システムから権限を継承し、処理パイプライン内でAIガードレールを適用し、監査証跡を標準で出力するプラットフォームを探しましょう。それにより、負担はセキュリティチームからベンダー側へと移り、コンプライアンス上の摩擦も減ります（例外が減り、SOC 2 Type IIの証跡がクリーンになり、GDPR対応の処理も簡素になります）。

権限を考慮したAIは、エージェントが何を見られるかをどう制御するのか？

データサーフェスはAIエージェント・セキュリティの土台です。エージェントが行動したり応答したりする前に、まず「読み取り」が行われます。そして、何を読み取ることが許されているかが、その後に続くすべての影響範囲（ブラストレディウス）を決定づけます。

多くのプラットフォームは、取り込み（インジェスト）時に権限を処理します。データはアクセスメタデータが付与された状態でシステムに入り、管理者がその上に検索ルールを構成します。問題は、それらのルールがソースシステムではなくAIプラットフォーム側に存在することです。ルールは実態とずれていきます。リアルタイムの役割変更を反映しません。そして、ID構成が変わるたびに継続的な保守が必要になります。

権限を考慮したAI（permission-aware AI）は、異なるアプローチを取ります。AIレイヤー内でアクセス制御を作り直すのではなく、ソースシステム——IDプロバイダー、CRM、チケッティング基盤——から権限を継承し、クエリ実行のたびに毎回それを適用します。

同じ質問をした2人のユーザーが異なる回答を得るのは、エージェントが各ユーザーにすでに閲覧を許可されているデータしか表示しないためです。これは、取り込みレイヤーではなく検索レイヤーで適用されるロールベースアクセス制御（RBAC）です。

この実務上の違いが最も効いてくるのは、マルチテナント環境や部門横断的な環境です。クエリ実行時の適用がなければ、広範な取り込みアクセスを持つエージェントは、AIデータ漏えい対策の単一障害点となります。設定を誤ったルール1つで、チーム・役割・顧客アカウントをまたいでデータが露出してしまうのです。クエリ実行時に適用すれば、権限の境界はユーザーとともに移動し、ルールの保守は不要になります。

データレジデンシー（保管場所）は、データサーフェス防御のもう一つの次元であり、エンタープライズの調達チームがコンプライアンス問題になるまで軽視しがちな点です。エージェントのメモリはどこに存在するのか？どの法域でクエリが処理されるのか？

AIのチームメイトであるComputerは、Computer Memoryをデータサーフェスのコントロールプレーンとして利用します。ユーザーのアイデンティティは既存システムから流れ込み、RBACとフィールドレベルのルールがクエリ実行時に適用され、許可されたスニペットだけがエージェントのコンテキストに取り込まれます。

AIエージェントが行動しようとするとき、Safe Actionsフレームワークは何をするのか？

アクションサーフェスこそが、AIエージェントをそれ以前のあらゆるエンタープライズソフトウェアと隔てるものです。間違ったことを言うチャットボットはサポート上の問題です。しかし、間違ったことを「する」エージェント——メールを送る、レコードを書き換える、ワークフローを起動する、APIを呼び出す——は運用上の問題です。その影響範囲は、まずい応答ではなく、現実世界の結果なのです。

なぜアクションサーフェスには専用の防御モデルが必要なのか？

アクションサーフェスを防御するには、4つの特性が一体となって機能する必要があります：

• すべてのアクションは、標準でAIエージェントの監査証跡を生成しなければなりません。これは任意のロギング連携としてではなく、すべての実行のアーキテクチャ上のアウトプットとして行われるべきです。
• リスクの高いアクションは、実行後ではなく実行前に、人間が介在するチェックポイント（human-in-the-loop）へエスカレーションされなければなりません。
• 実行されたアクションは、下流システムが許す範囲で取り消し可能（リバーシブル）でなければなりません。
• 何を高リスクとみなすかは、ワークフローごとに設定できなければなりません——財務ワークフローでの大量データエクスポートは、サンドボックス環境での同じアクションとは異なるリスクを伴います。

リスク階層型の実行：アーキテクチャによって安全に、運用では柔軟に

すべてのエージェントのアクションに人間の承認を求めると、自律性と引き換えに脆さを抱え込むことになります——エージェントは高価なフォーム入力係に成り下がってしまいます。正しいモデルはリスク階層型です：

3つの階層すべてが、自動的に監査証跡へ記録されます。ロールバック用のフックは、下流システムが取り消しをサポートするあらゆる階層で利用できます。

ComputerのSafe Actionsフレームワークはこれをどう実装しているか

ComputerのSafe Actionsフレームワークは、リスク階層型の実行をネイティブに実装しています。しきい値はワークフローごとに設定でき、すべてのエージェントに一律に適用されるグローバル設定ではありません。複雑なマルチステップのワークフローには、Agent Studio for Computerがワークフローレベルのガバナンスツールを提供します。アクションのシーケンスを検査し、エスカレーションルールを設定し、ロールバックの挙動をエージェント単位（連携単位ではなく）で定義できます。

Computerにおける human-in-the-loop の仕組みは、フォールバックではなく、意図的に設計されたアーキテクチャ上の制御です。カスタマーサービスの自動化ワークフローでは、設定したしきい値を超える返金は実行前に人間のレビュアーへ回され、その間もエージェントは並行して他のタスクを処理し続けます。これこそが、エンタープライズ規模における安全なAI導入の姿です。運用に逆らうのではなく、運用とともにスケールするエンタープライズAIガバナンスです。

アウトプットサーフェス——エージェントが何を言うかを守るAIガードレール

アウトプットサーフェスとは、エージェントが外部に発する応答——テキスト、レポート、コード、メール、メッセージ——です。多くのAIガードレールはここに焦点を当てています。

なぜアウトプットサーフェスの防御が重要なのか？

アウトプットサーフェスの防御には、3つのアーキテクチャ層が必要です：

これらの層が一体となって、OWASP LLM Top 10（プロンプトインジェクションを含む）の主要な脅威を緩和します。

AIガードレールは各層でどう機能するか：3層のアウトプット防御スタック

• グラウンデッド検索（Grounded retrieval）：エージェントのコンテキストを、監査済みで権限フィルタリングされたソースに限定します。これにより、もっともらしい捏造ではなく、信頼できるデータに基づいた回答が得られます。
• セマンティックなアウトプットチェック：小規模なバリデーターモデルが、送信前にエージェントの応答を事実整合性・ポリシー違反・危険なパターンの観点から検査します。
• コンテンツフィルタリング：決定論的なルールとマスキングポリシーがPIIを除去し、不適切表現をブロックし、応答の分離を徹底することで、マルチテナント環境でもアウトプットを安全に保ちます。

エンタープライズのコンプライアンス——2026年のAIエージェント導入で重要となる認証は？

2026年において、5つの認証がエンタープライズの基準を形づくります：

• SOC 2 Type II——セキュリティ・可用性・機密性に関する信頼と統制の必須要件。
• ISO 27001——インフラの厳格さとISMS（情報セキュリティマネジメントシステム）の成熟度。
• GDPR／データレジデンシー——EUでの事業運営や国境を越えるデータ取り扱いに必須。
• HIPAA——ヘルスケア関連のワークロードやPHI（保護対象保健情報）の取り扱いに必須。
• 新興のAI固有標準——AIエージェントのコンプライアンスとエンタープライズAIガバナンスのための、ISO 42001およびNIST AI RMF（2024〜2026年の新基準）への準拠。

AIエージェントをどう守るか——7項目の評価チェックリスト

このチェックリストを使って、エンタープライズに対応できるAIエージェント基盤と、設定作業の多い代替案とを見分けましょう。これらの基準は、3つのサーフェス・セキュリティモデル、ボルトオン税、そしてコンプライアンスに対応しています。

1. アーキテクチャによる、権限を考慮したデータアクセス

プラットフォームがクエリ実行時に（取り込み時だけでなく）アクセス制御を適用するため、エージェントは呼び出し元に閲覧が許可されたものだけを取得します。

欠けている場合の危険信号： データが1つのコーパスにまとめられ、アウトプット時にしかフィルタリングされない。

（Computer：Computer Memoryによる権限を考慮したAI。アイデンティティとRBACにスコープされる。）

2. フィールドレベルおよびマルチテナントの分離

RBACがオブジェクト・行・フィールドの各レベルのアクセスにまで及び、強力なテナント分離とデータレジデンシーの選択肢を備えている。

欠けている場合の危険信号： フィールドレベルの制御がない、またはリージョンをまたぐデータ漏えいがある。

（Computer：フィールドレベルのアクセス制御と、米国／EUリージョンにまたがるデータレジデンシー。）

3. 標準の監査証跡を備えた安全なアクション

すべてのエージェントのアクションが、アイデンティティ・プロンプト・アクションパラメータ・結果・承認とともに標準で記録される。

欠けている場合の危険信号： アクションが追跡できない、またはログを手動で集約する必要がある。

（Computer：Safe Actionsフレームワーク。監査証跡を標準で生成。）

4. 設定可能な human-in-the-loop とロールバック

リスクのしきい値を設定でき、高リスクのアクションは人間へエスカレーションされ、ロールバックがサポートされている。

欠けている場合の危険信号： すべてのアクションを事前承認しなければならない（脆い）、または human-in-the-loop を設定できない。

（Computer：エスカレーションポリシーと監査ビューのためのAgent Studio。）

5. 組み込みのアウトプットガードレール（グラウンデッド検索＋バリデーター）

応答が検証済みのソースに基づき、配信前にセマンティックチェックを通過する。

欠けている場合の危険信号： PIIやハルシネーションに対するバリデーターモデルやコンテンツフィルタリングがない。

（Computer：アウトプットガードレールのための、グラウンデッド検索＋バリデーターモデルのパイプライン。）

6. SOC 2（AI対応）＋ISO 27001＋AI固有フレームワークへの準拠

SOC 2 Type II、ISO 27001、GDPR／HIPAA対応に加え、AIエージェントのコンプライアンスとエンタープライズAIガバナンスのためのISO 42001およびNIST AI RMFへの準拠。EU AI Actの下では、顧客の意思決定を扱う自律型サポートエージェントは高リスクシステムに該当し得るため、文書化されたフレームワーク準拠は譲れない要件となります。

欠けている場合の危険信号： AI固有フレームワークへのロードマップがない。

（Computer：SOC 2 Type II、ISO 27001:2022、GDPR。BAAの下でHIPAA対象サービスを提供。ISO 42001／NIST AI RMFへの準拠は進行中。）

7. 低いボルトオン税——月あたり削減できる工数を測定できること

セキュリティが後付けではなくアーキテクチャに組み込まれており、セキュリティチームが設定・例外対応・監査に費やす時間を削減できる。欠けている場合の危険信号： カスタムアダプター、スクリプト、手動監査への依存が大きい。（Computer：権限はIdP／Salesforce／Jiraから流れ込み、ガードレールはパイプラインに組み込まれ、監査証跡は標準で生成される。）

DevRevのComputerは、AIエージェントのセキュリティにどう取り組んでいるのか？

Computerのアーキテクチャは、3つのサーフェス・セキュリティモデルに1対1で対応しています。各サーフェスには、設定によってではなく設計によってAIエージェントのセキュリティを適用する、専用の機能が備わっています。

コンプライアンスとデータ保護

• SOC 2 Type II、ISO 27001:2022、GDPR。BAAの下でHIPAA対象サービスを提供
• 保管時のAES-256暗号化、転送時のTLS 1.2/1.3
• 顧客管理型の暗号鍵
• マルチリージョンのデータレジデンシー（米国、EU）

この設計は、ボルトオン税を低減することでエンタープライズAIガバナンスを支えます。権限は既存システムから流れ込み、ガードレールはパイプラインに組み込まれ、監査証跡は標準で生成されます。Computerは、後付け制御を備えたチャットボットとしてではなく、AIエージェント・セキュリティのための単一のアーキテクチャとして構築されました。

認証やセキュリティ体制の詳細については、DevRevのセキュリティ認証をご覧ください。

本番環境で実証された、フィンテック水準のAIエージェント・セキュリティ

エンタープライズAI基盤が本格的なセキュリティレビューを通過したことを示す最も強いシグナルは、認証ページではありません。それは、金融サービスにおける本番稼働の実績です。

BILLはなぜSalesforce AgentforceではなくComputerを選んだのか

BILLは、数十万社の取引を処理する時価総額16億ドルのフィンテック企業です。そのセキュリティ基準は机上のものではありません。あらゆるAI導入は、本番環境に触れる前に、SOC 2の精査、暗号化標準のレビュー、データレジデンシーの検証、そして完全な監査証跡要件をクリアしなければなりません。

BILLはSalesforce上で稼働しながら、ComputerをSalesforce Agentforceと並べて評価しました。Computerはアウトプットの品質で勝り、BILLの完全なセキュリティレビューを含めて3か月未満で本番稼働に到達しました。

AIエージェントのセキュリティは、後付けではなく組み込みであるべきではないか？

あなたのセキュリティチームが、安全性をプラットフォームに後から設定する必要はないはずです。

エンタープライズAIセキュリティは、セキュリティチームの仕事を難しくするのではなく、楽にするべきです。組み込みであることが、その違いを生みます。

Computerは3つのサーフェス——権限を考慮したデータアクセス、安全なアクション、アウトプットガードレール——を設計段階から組み込んで構築されました。だからこそ、ガバナンスは設定ではなくアーキテクチャによってもたらされます。

Agent Studioのガバナンスを実際に体験する、または

BILLのセキュリティ事例を読む