AI駆動開発 2026年10月18日

AIエージェントに「するな」は通じない——NVIDIAが設計原則で示した、本当の防衛線の置き場所

AIエージェントに「顧客情報を外部に送るな」と書いたプロンプトがある。それで安心しているなら、設計の出発点が間違っている。

NVIDIAが2026年9月21日（米国時間）に公開したブログ記事「AI Security Is an Engineering Problem – How to Solve It at Every Layer of the Agent Stack」の要点を一言で言うなら、これだ。

防衛線はプロンプトではなく、実行環境に置け。

AIエージェントへの「禁止指示」は防衛にならない

なぜプロンプトによる禁止が防御にならないのか。構造の問題だ。

LLMへの指示は、実行を強制的に制約するコードではない。次のトークン生成に影響を与える「確率の入力」にすぎない。「外部に送るな」という指示は、その通りに振る舞う確率を上げる。しかし確率を1.0にする手段は存在しない。

NVIDIAはこの現実を正面から受け入れ、「AIエージェントが誤った判断をする可能性を前提とした」セキュリティ設計を提唱している。誤判断を「例外」として扱うのではなく、「誤判断が起きても被害が広がらない構造」を作ることが、議論の出発点になる。

NVIDIAが示した具体的な攻撃シナリオ

NVIDIAが例示したのは、顧客情報を更新するAIエージェントのケースだ。

このエージェントが業務中に添付文書を読み取り、その中に埋め込まれた悪意ある指示——いわゆる「プロンプトインジェクション」——に従って、顧客情報を許可されていない外部の送信先に送ろうとしたとする。

ここでNVIDIAが指摘するのは二点だ。

一つ目は「止められる構造があったか」という問いだ。エージェントが不正な指示に従ってしまったとしても、ネットワークポリシーによってデータの送信を遮断できる必要がある。

二つ目は「記録があるか」という問いだ。エージェントがどのツールを使用し、どこにデータを送ろうとしたのか、アクセス許可の判定とその結果をログに残すことが重要だという。

そして根本的な問いがある。「顧客情報を更新する権限」と「顧客情報を外部に送信する権限」は、なぜ同一視されるのか。更新できるからといって、送信できる必要はない。この権限の粒度を曖昧にしていることが、攻撃の成立を許している。

セキュリティ設計の5原則

NVIDIAは具体的な設計原則として5点を挙げている。

各エージェントに追跡可能なIDを与え、認証情報は割り当てたタスクに必要な範囲に限る
アクセスできる情報、変更できるシステム、承認が必要な行動をポリシーで明確にする
ポリシーの範囲内であっても、影響の大きい行動と権限の変更には人間の承認を求める
エージェントが使うツール、スキル、依存関係の出どころと完全性を検証する
ツール呼び出し、認可の判断、結果を保護された記録として残し、アクセスの取り消しとインシデントの封じ込めの手順を明確にする

これを実現する技術例として挙げられたのが、オープンソースの実行環境「NVIDIA OpenShell」だ。AIエージェントをサンドボックス環境で実行し、データ・ネットワーク・システムリソースへのアクセスを制御する。重要な点は、「AIエージェント自身が変更できない場所でポリシーを適用する」という設計にある。制約をエージェントの外側に置くことで、エージェントが賢くなっても制約が破られにくい構造になる。

「導入前テスト」だけでは足りない——何を検証すべきか

NVIDIAはもう一点、見落とされがちな話をしている。テストの対象が間違っている、という指摘だ。

AIエージェントの本番導入前に、少なくとも以下の状況を想定したテストが必要だという。

AIエージェントが、許可された範囲を超えて認証情報を取得しようとした場合
機密情報を許可されていない送信先に送ろうとした場合
自らのアクセス権限を変更しようとした場合
監視の仕組みに干渉しようとした場合

多くの現場でのテストは「期待する動作をするか」の確認に終わる。しかし本来は「やってはいけないことを試みたとき、実際に止まるか」を検証しなければ意味がない。NVIDIAはさらに、テスト結果を評価して本番導入の可否を判断する責任者を明確にし、問題が見つかった場合には修正につなげることまでを求めている。

責任者の不在は、テストの形骸化に直結する。

ここからは見方の話——構造が示す業界の方向性

ここからは自分なりの解釈を加える。

NVIDIAのこの記事が面白いのは、「AIをより賢くすることでセキュリティを高める」という方向性を採っていない点だ。むしろ逆で、「どれだけ賢くなっても誤る前提で設計する」という立場を明確にしている。これはGoogleのAI Control Roadmapや、Postmanが発表したAPIキーをエージェントに渡さない新アプローチと同じ思想的系譜にある。

つまり業界のある部分は、「信頼できるAIを作る」から「信頼の有無に依存しないシステムを作る」へと、設計思想の重心を移しつつある。

これは単なるセキュリティの話ではない。AIエージェントを「制御対象」として正式にシステム設計の中に位置づける、という構造転換の話だ。

同種のニュースを見るときに使える判断軸を一つ渡しておくと、「これはプロンプトで制御する話か、実行環境で制御する話か」を区別することだ。新しいAIエージェントツールやセキュリティ製品が出てきたとき、その安全機能が「賢いプロンプト設計」に依存しているなら、それは防衛線ではなく期待値の設定にすぎない。防衛線が実行層にあるかどうかを確認する習慣を持つだけで、製品評価の解像度がかなり上がる。

実務的な示唆と次の論点

AIエージェントを業務に組み込もうとしている組織——特に社内DX推進チームやSaaS開発チーム——に向けて、今すぐ問い直すべきことを3点に絞る。

1. エージェントの「権限マップ」が存在するか
どのエージェントが何にアクセスでき、何はできないのかを文書化しているか。「プロンプトに書いてある」は権限マップではない。

2. 人間の承認が必要なアクションを定義しているか
NVIDIAは「ポリシーの範囲内であっても、影響の大きい行動には人間の承認を求める」と言っている。「どのアクションが影響大か」を事前に決めていない組織は多い。ここを曖昧にしたまま運用を始めると、問題が起きてから「あれは止めるべきだった」という後付け判断になる。

3. 「止まるかどうか」のテストを誰もやっていないか
期待動作の確認と、禁止動作の阻止確認は別物だ。後者を専担でやる人間が社内にいるか、あるいは外部に依頼する体制があるかを確認してほしい。

次に問題になる論点として気になるのは、MCPサーバーや外部ツール連携が増える中での「権限の合成問題」だ。個々のエージェントの権限を絞っても、ツールを接続するたびに実質的な権限が広がっていく。ツールの数が増えるほど権限マップは複雑になり、どこかに想定外の経路が生まれる。NVIDIAが「依存関係の出どころと完全性を検証せよ」と言っているのも、この問題を意識してのことだろう。ただ、これを実際にどうスケールさせるかの答えは、まだ業界として出ていない。