サマリー
AIエージェントは単なるチャットボットではなく、人間の細かい指示を待たずに自律的に動作し、連携しているツールを実行し、時には他のエージェントと連携してタスクを完了します。このような高度な自律性は業務に変革をもたらす力を持っていますが、新しいリスクも生んでいます。本記事ではAIエージェントの自律性が生み出す新たなリスクを低減しコントロールするために何が必要か考察し、NVIDIA OpenShell™とTrendAI Vision One™を組み合わせた実践的な対策について検証結果をもとにお伝えします。
AIエージェントが生む新たなリスク
AIエージェントは個人利用に留まらず、企業システムへの導入も急速に進んでいます。本記事を読まれている皆様の中にも、AIエージェントを実際に利用している方や、導入を検討している方がいらっしゃるのではないでしょうか。実際、PwC Japanグループによる調査では、AIエージェントについて理解しており、導入済み/導入を進めている/導入を検討中の日本企業の割合は71%という結果が出ており、多くの企業でAIエージェントの導入検討が加速している状況です。
（参考文献）
生成AIに関する実態調査2026 春 6カ国比較―AI変革は選択肢から生存条件へ 変わりゆく世界に日本企業は追いつけるのか― | PwC Japanグループ
AIエージェントを利用する中で考慮しなければならないのが、AIエージェントの持つセキュリティリスクです。実際に、プロンプトインジェクションを悪用してAIに機密情報を漏えいさせる攻撃や、エージェントに過剰な権限が与えられたことで不適切な操作が実行される事例が報告されています※1。また2026年7月には、OpenAI社の評価環境で動作していたAIエージェント群が想定された制約を回避し、外部システムへの侵入に至った事例も公開されるなど、AIエージェント特有のリスクが現実のものとなっています※2。
（参考文献）
※1 OWASP GenAI Exploit Round-up Report Q1 2026 - OWASP Gen AI Security Project
※2 Hugging Face のインシデントと今後の道筋 | OpenAI
このようなリスクは、OWASP Top 10 for Agentic Applications 2026でも整理されています。AIエージェントは自然言語を入力として利用すること、自律的に判断すること、長期的な記憶を持つこと、複数のエージェントやツールと連携することが要因で、従来のアプリケーションとは異なるセキュリティリスクを抱えています。
（参考文献）
OWASP Top 10 for Agentic Applications for 2026 - OWASP Gen AI Security Project
AIエージェントのリスクをコントロールするためには
このように、AIエージェントは従来の決定論的に動作が定義される業務システムとは異なるリスクを抱えています。重要なのは、これらのリスクを理由に活用を止めるのではなく、適切な統制のもとで安全に活用することです。では、どのようにAIエージェントのリスクを低減し、組織として統制していけばよいのでしょうか。その指針の一つとして、PwC Japanグループは当社との共同レポートである「自律するAIの時代：AIエージェントのサイバーリスクと実践的ガバナンス」にて「AI統制保証水準（AI-CAL）」を提唱しています。このAI-CALはAIエージェントの自律レベルに応じて、本番導入に必要となる統制要件を整理したフレームワークです。このAI-CALをどのように実現していくのか、見ていきましょう。
（参考文献）
PwCコンサルティング、TrendAI™共同レポート「自律するAIの時代：AIエージェントのサイバーリスクと実践的ガバナンス」 | トレンドマイクロ
導入するAIエージェントの自律レベルと対応するAI-CALを理解する
AI-CALを実現していくための最初のステップは、自社で導入しようとしているAIエージェントの自律レベルを理解することです。同レポートでは、実行主体/ツール利用/計画生成/状態保持/マルチエージェント/人間関与の観点で自律レベルを整理しています。自律レベルに応じて発生するリスクやとるべき対策も異なるため、このような統一された基準でAIエージェントの自律性を整理することが重要です。
導入するAIエージェントの自律レベルを理解した後、その自律レベルのAIエージェントを導入するために必要な統制水準を理解します。同レポートにおいては、AIエージェントの自律レベル（L1~5）に対してAI-CAL(1~4)が定義されています。AI-CALに関するより詳細な情報についてはぜひレポートをお読みください。
AI-CALを実現するための統制を実装する
導入するAIエージェントの自律レベルと、それに対応するAI-CALを理解した後は、その水準を満たすための統制を実装していきます。そこで重要なのが「予防的統制」「検知的統制」「対応的統制」の3つの観点を総合して考慮することです。
例えば、アクセス可能なシステムや利用できるツールを制限することは予防的統制にあたります。一方で、AIエージェントが想定外の行動を取った場合には、その挙動を継続的に観測し異常を検知できなければなりません。これは検知的統制にあたります。また、検知した結果に基づいてAIエージェントを停止・隔離し、被害の拡大を防ぐことは対応的統制にあたります。つまり、AIエージェントの安全な運用には「防ぐ」「見つける」「止める」の3つの仕組みが求められるということです。
では、これらの統制を実際にどのように実装できるのでしょうか。本記事では、NVIDIA の技術とTrendAI Vision One™を組み合わせることで、これらの統制をどのように実現できるのかを検証します。
AIエージェントの安全な導入に関する検証
本記事ではAIエージェントのリスクを抑えるために必要な「予防的統制」「検知的統制」「対応的統制」の具体的な実装を検証するためにAIエージェント環境を作成し、NVIDIA OpenShellとTrendAI Vision One™を活用した対策を適用しました。そして、AI-CAL2~3で求められている要件の内、特に「行動・ツール」「思考」「観測性」「制御性」を想定し、4つの脅威シナリオに対して有効性を確認しました。今回の検証環境の詳細を下記に示します。
AIエージェントの安全な導入の第一歩 NVIDIA OpenShellを用いた予防的統制
NVIDIA OpenShellとは
NVIDIA OpenShell（以下OpenShell）とは、AIエージェントを隔離実行するためのサンドボックス型ランタイムです。サンドボックスとは、外部への影響を絞り込んだ隔離された実行環境を指します。特徴は、宣言的なポリシー（YAML形式の設定ファイル）によって、サンドボックスごとにアクセスできるネットワーク上の宛先や実行できるツールをホワイトリスト形式で制御できることです。このOpenShellを利用することにより、例えば部門ごとの利用目的に応じてAIエージェントが実行できる操作やアクセス先を制限するといったガバナンスを効かせることができます。
（参考文献）
NVIDIA OpenShell で自律的かつ自己進化するエージェントをより安全に実行 - NVIDIA 技術ブログ
OpenShellを利用した実践的なAIエージェントのガバナンス 「部門ごとにエージェントを分け、権限を絞る」
今回の検証では、下記図に示すように部門ごとにAIエージェントを分け、それぞれのAIエージェントをOpenShellサンドボックスに閉じ込めることで権限を制限しました。
各部門のAIエージェントの用途と与えられた権限について以下の表に示します。
検証シナリオ0: ポリシーでAIエージェントを制御し、未承認の宛先にはアクセスできない
上記の設定を実施した状態で、検証を行いOpenShellの予防的統制が効いているか確認しました。AI Agent Cに対してアクセス許可を実施していない宛先であるhttps://wrs41.winshipway.comへアクセスし内容を取得することを依頼しました。依頼を行ったところ、図8にある通り「指示された宛先にはアクセスできません」と回答がありました。
OpenShellのダッシュボードであるTerminal UIを見ると依頼した宛先へのアクセスがブロックされていました。
※OpenShellでは、許可されていない宛先へのネットワークアクセスが発生した場合、図9のように該当する通信先がネットワークルールの Pending Rule として記録されます。
同じ設定で、AIエージェント Cがアクセス可能なGitHub上のページにアクセスし、内容を取得することを依頼したところ、想定通りAIエージェントCは依頼された内容を取得できました。
このようにOpenShellの宣言的ポリシーによって予防的な統制を実装することで、AIエージェントが利用できるツールやアクセスできる宛先を制限できます。
TrendAI Vision One™を組み合わせた対策
上述のOpenShellを用いた予防的な対策でAIエージェントのリスクをある程度低減できます。ただ、すでにお気づきの方もいらっしゃると思いますが、許可された宛先であっても脅威が混入する可能性があります。特にAIエージェントにおいては自然言語により巧妙に作られた指示文が許可されたチャネルから入り想定外の挙動を引き出す例があります。このようなリスクに対して必要なのは予防的な統制だけでなく、脅威の侵入やAIエージェントの想定外の挙動を検知する検知的統制と、それらをもとにAIエージェントの稼働を止めリスクの発生を抑える対応的統制です。これらをどのようにTrendAI Vision One™で実現していくのかご説明します。
実際の検証結果のご説明に入る前に、今回利用したTrendAI Vision One™ソリューションのご説明と、TrendAI Vision One™ソリューションを組み合わせた場合の構成についてご説明します。
TrendAI Vision One™とは
TrendAI Vision One™は弊社が提供するAI時代のセキュリティプラットフォームであり、AIの利用と開発を保護、AIアプリケーションやAIエージェントを構成するさまざまなレイヤに対して、円滑なガバナンスと脅威対策を提供します。本記事では、TrendAI Vision One™の中の４つのモジュールを利用しました。
- TrendAI Vision One™ AI Guard（以下、AI Guard）：AIエージェントへの入出力を監視し、プロンプトインジェクションなどの攻撃をリアルタイムに検知・遮断します（予防的＋検知的）。本検証においては NVIDIA NeMo™ Guardrails に統合することによりAI GuardをAIエージェントに組み込みました。
- TrendAI Vision One™ Container Security（以下、Container Security）：コンテナクラスタで構成される AIエージェントを、ビルド、デプロイ、ランタイムに至るまで一貫して保護します。本検証では特にコンテナのランタイム環境における検知対応機能を活用しました。
- TrendAI Vision One™ Agentic SIEM（以下、Agentic SIEM）：TrendAI Vision One™製品のログとサードパーティ製品のログを収集し分析やアラート発報を行います。本検証ではTrendAI Vision One™製品と、OpenShellのログを集約するために利用しました。
- TrendAI Vision One™ Code Security（以下、Code Security）：連携したGitHubリポジトリをスキャンし、シークレットの混入などを検出します。リポジトリ自身のCI/CDパイプライン（GitHub Actions）に組み込むことによりシークレットや脆弱性の混入をリアルタイムで検知することが可能です。
本検証で構築した構成
本検証ではTrendAI Vision One™のセキュリティソリューションを下記のように実装しました。
まず、Container SecurityをKubernetes環境に統合しOpenShellによって作成されたAIエージェント用サンドボックスの挙動を監視し、不審な挙動が検知された場合に隔離や停止等の対応ができるようにしました。続いて、AI Guardを用いAIエージェントの入出力に対するガードレールを実装しました。この実装においてはNVIDIA NeMo Guardrailsの技術を用いAI GuardによりAIエージェントの入出力を検査できるようにルーティングを行いました。また、 Agentic SIEMにOpenShellのイベントログをHTTP Event Collectionで連携することによりAIエージェントに関するログの保管と監視を実装しました。最後にAIエージェントCが連携しているGitHubと Code Securityを連携することにより、AIエージェントCがアップロードするコードの自動スキャンを行えるようにしました。これらすべてのログやイベントはTrendAI Vision One™で統合管理することができ、AIエージェント環境全体を統合管理することができます。では、実際にどのようなことができるのか、具体的なユースケースを見ていきましょう。
NVIDIA NeMo とは
NVIDIA NeMoは、NVIDIAが提供する AIエージェントの学習や最適化、およびガバナンスを加速するための機能を備えた、AIエージェントを統括的に開発するためのオープンライブラリ群です。
NVIDIA NeMo Guardrailsとは
NVIDIA NeMo Guardrails （以下NeMo Guardrails）は、生成AIやAIエージェントに対してガードレールを実装するためのオープンソースフレームワークです。AIエージェントへの入力や出力、ツール実行前後の処理を定義し、安全性やコンプライアンス要件に沿った制御を実装できます。本検証ではNeMo Guardrailsを利用してAIエージェントCへの入出力をAI Guardへルーティングし、プロンプトインジェクションなどの脅威を検査できるようにしました。
（参考文献）
Overview | NVIDIA NeMo Guardrails Library Developer Guide
Trend Micro Vision One AI Application Security | NVIDIA NeMo Guardrails Library Developer Guide
検証シナリオ1: 過剰な権限が与えられたAIエージェントCによって不正ファイルがダウンロードされる(直接プロンプトインジェクション)
AIエージェントには、不正な指示文を入力することで悪意のある行動を行ってしまうというリスクがあります。このリスクを引き起こす脅威を直接的プロンプトインジェクションと呼びます。今回はこのシナリオを再現するために、AIエージェントCにGitHub上の不正なファイルをダウンロードさせるために細工した指示文を入力しました。
TrendAI Vision One™による対策が実装されていない場合
何も対策を行っていない状態では下記のように不正な指示に従い、不正なファイルをダウンロードしてしまいます。
※今回はeicarファイルのダウンロードという無害なテストファイルのダウンロードですが、同様の手法を用いることによりほかの不正ファイルや、その他の不正操作の実行を引き起こす可能性があります。
実際に、AI Agent Cが稼働しているサンドボックス内に不正なファイルがダウンロードされていました。今回はサンドボックス環境のみにファイルがダウンロードされましたが、AIエージェント経由で別のユーザや別の環境に拡散する可能性があります。
TrendAI Vision One™による対策が実装されている場合
このような脅威に対してはNVIDIA NeMo Guardrails × AI GuardでAIエージェントへの入力を検査することで対策可能です。NVIDIA NeMo GuardrailsによりAIエージェントに対する入力は一度AI Guardの検査を受けるようにルーティングされるため、下記の通りAIエージェントへの入力にプロンプトインジェクションが含まれているとAI Guardが検知し、ブロックします。不正な指示をAIエージェントが受け付ける前にブロックすることができ、後続のAIエージェントによる不正ファイルの取得を防ぐことができます。また、TrendAI Vision One™にてプロンプトインジェクションがブロックされたことを確認することが可能です。
検証シナリオ2: 過剰な権限が与えられたAI Agent Cによって不正ファイルがダウンロードされる（間接プロンプトインジェクション）
プロンプトインジェクションには直接的プロンプトインジェクションに加えて、間接的プロンプトインジェクションというものがあります。この手法の特徴は、AIエージェントに直接不正な指示を与えるのではなく、AIエージェントが参照するドキュメントやWebサイトに不正な指示文を埋め込んでおき、AIエージェントが業務上の処理の一環として不正な指示文を含むドキュメントを読み込んでしまうことで発生する点です。
TrendAI Vision One™による対策が実装されていない場合
本検証ではAIエージェントCが連携されているGitHubレポジトリ上の「Weekly Build Report」に不正な指示文を埋め込みました。この状態でAIエージェントに対してビルドレポートを要約する指示文を送ります。するとAIエージェントはビルドレポートの要約をせずに、ビルドレポートに埋め込まれた指示文に従い不正なファイルを取得してしまいました。
TrendAI Vision One™による対策が実装されている場合
このような事象が発生した場合でもTrendAI Vision One™を利用していれば対策が可能です。TrendAI Vision One™ Container SecurityでAIエージェントが稼働しているサンドボックスを監視しているため、AIエージェントの不正な操作にすぐに気づくことができるからです。下記は実際に本イベントを検知しTrendAI Vision One™にて発生したアラートの詳細です。Container SecurityではAIエージェントが実行したコマンドを観測することができるため、発生した事象の早期検知と早期解明や、検知した内容をもとにAIエージェントの実行環境を隔離/終了することにより被害の拡大を防ぐことが可能です。
また、AIエージェントが取得した不正ファイルについても検知することが可能です。
検証シナリオ3: シークレットの含まれたファイルがAI Agent CによってGitHubアップロードされる
AIエージェントにとっては許可された連携先に対する許可されたアクションであっても、その内容によってはセキュリティリスクを伴う場合があります。例えば、AIエージェントが情報のアップロードを許可されているチャネルに、本来はそのチャネルにアップロードするべきでない秘密レベルの情報がアップロードされる場合です。
TrendAI Vision One™による対策が実装されていない場合
本検証では、シークレットの含まれたコードのアップロードを再現するため「デバッグ調査のため」と称し機密情報が含まれたファイルをGitHubにアップロードするコマンドの実行を依頼しました。このような依頼方法の場合、AIエージェントはファイルの中身に機密情報が含まれているかを確認せずにユーザから指示されたコマンドを実行してしまいました。
TrendAI Vision One™による対策が実装されている場合
このような事象が発生した場合でもTrendAI Vision One™を用いていれば対策が可能です。Code SecurityでAIエージェントと連携しているGitHub環境を保護することによりAIエージェントがファイルをアップロードするタイミングで自動的に内容をスキャンし、シークレット等が含まれていないかの検知や、シークレットが含まれていた場合アップロードをブロックするといった制御を実現できます。
また、それらのログをAgentic SIEMと連携していれば、前後の事象解明や後続の影響が出ていないか、ほかに不審な挙動が見られないかをAgentic SIEMのログクエリ画面であるXDR Data Explorerで調査可能です。例えば、Container Securityにより観測されたAIエージェントのコマンド実行履歴や、OpenShellによって観測されたAIエージェントによるGitHubへのファイルのPush履歴を後追いで調査することが可能です。シークレットが含まれている可能性が高いファイルが操作された場合はContainer Securityの検知ロジックによりタグ付けされるため、機密情報の流出などの影響のあるイベントを早期に検知することができます。
検証のまとめ
本検証では、NVIDIA のオープンソースソフトウェアとTrendAI Vision One™を組み合わせることで、AIエージェントの統制に必要な「予防的統制」「検知的統制」「対応的統制」を実装しました。0～3の4つの検証シナリオを通じて確認できたのは、AIエージェントのリスクを単一の技術だけで完全に防ぐことは難しく、複数の統制を組み合わせることが重要であるという点です。OpenShellによる予防的統制は重要な第一歩ですが、それだけでは許可済みチャネル経由の攻撃や想定外の挙動を完全に防ぐことはできません。そのため、TrendAI Vision One™による監視・検知・対応の仕組みを組み合わせることで、多層的な統制を実現することが重要です。今回の検証環境における各コンポーネントの役割分担を整理すると、図22のようになります。
AIエージェントを恐れなく活用するために
本記事では、AIエージェントの統制に関する考え方であるAI-CALを紹介するとともに、NVIDIA OpenShell、NVIDIA NeMo Guardrails、TrendAI Vision One™を組み合わせた実践的な対策をご紹介しました。AIエージェントが業務に浸透していくこれからの時代において、求められるのはAIエージェントを恐れて利用を控えることではなく、適切な予防・検知・対応の仕組みを整えたうえで活用することです。本記事で紹介した考え方や検証結果が、安全なAIエージェント活用を進める際の一助となれば幸いです。