AIエージェントのセキュリティリスク総まとめ：導入前に知っておきたい脅威と対策 • vonxai blog

AIエージェントは、チャットで回答するだけのAIとは異なり、外部ツールを呼び出し、ファイルを読み書きし、コードを変更し、APIを実行し、場合によっては業務フローそのものを自律的に進める存在になりつつあります。

これは大きな生産性向上の可能性を持つ一方で、従来のWebアプリケーションやAPIとは違う種類のセキュリティリスクを生みます。特に重要なのは、AIエージェントでは「入力」「推論」「ツール実行」「外部連携」「出力」の境界が曖昧になりやすいことです。

本記事では、これまでvonxai blogで取り上げてきたAIエージェント、MCP、プロンプトインジェクション、AIコーディング、サプライチェーンに関する記事を横断しながら、導入前に押さえるべきリスクと対策を整理します。

AIエージェントのセキュリティはなぜ難しいのか

AIエージェントの難しさは、単に「AIが間違える」ことではありません。問題は、AIが外部システムに接続され、判断と実行の一部を担うようになることで、攻撃者にとっての入口と影響範囲が広がる点にあります。

従来のシステムでは、ユーザー入力はフォームやAPIパラメータとして扱われ、バックエンド側で検証されることが多くありました。しかしAIエージェントでは、自然言語、Webページ、メール、ドキュメント、ツール説明、ログ、検索結果など、さまざまな情報が「指示」として解釈される可能性があります。

この構造を理解するには、AIエージェントをレイヤーごとに捉える考え方が役立ちます。MAESTROフレームワークは、基盤モデルからエージェント、アプリケーション、エコシステムまでを分けて脅威を整理するための枠組みです。詳しくは AIエージェントのセキュリティ、どう対応する？ MAESTROフレームワーク解説で解説しています。

主要リスク1：プロンプトインジェクション

AIエージェントの代表的なリスクが、プロンプトインジェクションです。これは、攻撃者がAIへの指示に紛れ込む形で、元の開発者指示や運用ルールを上書きしようとする攻撃です。

特に厄介なのは、攻撃文がユーザー入力だけでなく、Webページ、外部ドキュメント、チャット履歴、プラグインの説明文、検索結果などに埋め込まれる可能性がある点です。AIエージェントが外部情報を読みに行くほど、間接プロンプトインジェクションのリスクは高まります。

たとえばWebサイトにAIチャットボットを導入し、問い合わせ対応や資料検索を任せる場合、外部ページやプラグイン連携を通じて意図しない指示が混入する可能性があります。この問題は WebサイトのAIチャットボット導入は危険？プラグインに潜むプロンプトインジェクションの脆弱性と対策で具体的に扱っています。

また、攻撃事例を整理した記事としては AI開発に潜む新たな脅威とは？プロンプトインジェクション3つの事例から学ぶセキュリティ対策も参考になります。

対策の基本は、AIに与える情報をすべて同じ信頼度で扱わないことです。

システム指示、社内データ、外部Webページ、ユーザー入力を明確に分離する
外部コンテンツを「命令」ではなく「参照情報」として扱う
ツール実行前に、操作内容と影響範囲を検証する
高リスク操作には人間の承認を挟む
機密情報や認証情報をAIの文脈に不用意に入れない

主要リスク2：MCPと外部ツール連携

Model Context Protocol（MCP）は、AIアプリケーションが外部ツールやデータソースと連携するための重要な仕組みとして注目されています。AIエージェントが開発環境、データベース、業務システム、クラウドサービスへ接続しやすくなる一方で、ツール連携そのものが攻撃対象になります。

MCPを安全に使うには、従来のAPIセキュリティだけでは不十分です。ツール説明文の改ざん、過剰な権限付与、意図しないデータアクセス、連鎖的なツール呼び出しなど、AIエージェント特有の脅威を考える必要があります。

MCPの基本構造と多層防御については、 AI連携プロトコル「MCP」の安全な使い方：企業が知るべきリスクと多層防御策で詳しく解説しています。

また、Function CallingとMCPのアーキテクチャ差が脆弱性にどう影響するかは、 LLMのセキュリティ、アーキテクチャが鍵？Function CallingとMCPの脆弱性比較から学ぶ実践的対策で取り上げています。

MCP導入時の確認ポイントは次の通りです。

観点	確認すべきこと
権限	ツールごとに最小権限になっているか
認証	接続先ごとに認証・認可が分離されているか
入出力	ツール入力と出力をスキーマで検証しているか
監査	どのツールがいつ何を実行したか記録しているか
承認	削除、送信、支払い、権限変更などに承認を挟んでいるか
分離	開発環境、検証環境、本番環境が分離されているか

主要リスク3：権限の与えすぎ

AIエージェントは、権限を与えるほど便利になります。ファイルにアクセスできる、GitHubにPRを出せる、クラウドにデプロイできる、社内データベースを検索できる、メールを送れる。こうした能力は業務効率を高めますが、同時に被害範囲を広げます。

AIエージェントのセキュリティで重要なのは、「AIが何を知っているか」だけでなく「AIが何を実行できるか」です。情報漏洩だけでなく、誤操作、意図しない変更、権限昇格、外部送信、破壊的操作まで考える必要があります。

ユーザーがAIエージェントにどこまでデータや権限を渡すのかという心理と行動については、ユーザーはAIエージェントにどこまで個人情報を渡すのか？データ共有における心理と行動パターンで整理しています。

実務では、次のような設計が現実的です。

読み取り権限と書き込み権限を分ける
本番操作はデフォルトで禁止する
破壊的操作には明示的な確認を必須にする
一時的な権限付与を使う
実行ログを監査できる形で残す
AIが参照できるデータ範囲を業務単位で限定する

主要リスク4：AIコーディングとセキュリティ負債

AIコーディングエージェントは、開発速度を上げる一方で、レビューしづらい変更、意図しない破壊的変更、依存関係の追加、脆弱なコード生成などを引き起こす可能性があります。

AIが生成したコードは「それっぽく動く」ことがあります。しかし、セキュリティ、保守性、運用性、責任範囲まで含めて安全とは限りません。特に大規模なコードベースでは、AIが局所的な正しさを優先し、システム全体の制約を見落とすことがあります。

この観点は、 LLMエージェントは開発者の新たな「セキュリティ負債」か？最新調査が示すリスクと可能性で詳しく扱っています。

また、AIエージェントによる破壊的変更の実態については AIエージェントは破壊的変更を減らす？人間との比較調査から見えた実態が参考になります。

AIコーディングを安全に使うには、プロンプトの工夫だけでなく、リポジトリ側に文脈を整えることが重要です。AGENTS.mdやルールファイルを使って、設計方針、テスト方針、禁止事項、セキュリティ要件をAIに伝えるアプローチについては、 AGENTS.mdは本当に役立つのか？AIコーディングエージェントにおけるコンテキストファイルの効果を検証やみんなの「AGENTS.md」の内容・メンテナンス状況を実態調査してみたで紹介しています。

主要リスク5：AIサプライチェーン

AIシステムのサプライチェーンは、通常のソフトウェアより複雑です。モデル、データセット、プロンプト、ベクトルDB、外部ツール、プラグイン、MCPサーバー、依存パッケージ、生成コードなど、信頼すべき対象が増えます。

特にAIコード生成では、存在しないパッケージ名をAIが提案し、それを攻撃者が実際に登録することで、開発者を悪意ある依存関係へ誘導するようなリスクがあります。AIがもっともらしい依存関係を出すほど、サプライチェーン攻撃の入口が増えます。

この問題は、 7割が虚偽？AIコード生成が破壊するサプライチェーンセキュリティで取り上げています。

AI・MLサプライチェーン全体の脅威については、国家サイバー統括室が署名したガイダンスに学ぶ、AI・MLサプライチェーンの脅威と対策も参考になります。

対策としては、次のような基本動作が重要です。

AIが提案したパッケージ名をそのまま採用しない
依存関係のメンテナンス状況と配布元を確認する
lockfile、SBOM、署名、脆弱性スキャンを活用する
生成コードの外部通信や認証情報の扱いをレビューする
AIが追加した依存関係をPRレビューで明示する

主要リスク6：エージェントによる攻撃能力の向上

AIエージェントは防御だけでなく、攻撃側にも使われます。脆弱性調査、ペイロード生成、フィッシング、権限探索、攻撃手順の自動化など、攻撃者の作業を補助する可能性があります。

AIエージェントが自律的に脆弱性を探索・攻撃できるのかという評価については、 AIエージェントは自律的にサイバー攻撃を行えるか？脆弱性エクスプロイト能力の最新評価で解説しています。

また、攻撃者がLLMを使ってコードを隠蔽するようなサプライチェーン攻撃については、 LLMを悪用した新たなサプライチェーン攻撃？「シェイプシフティング」によるコード隠蔽の脅威とはが参考になります。

企業側は「AIを導入するかどうか」だけでなく、「攻撃者もAIを使う前提で防御できているか」を考える必要があります。

導入前チェックリスト

AIエージェントやAIチャットボットを導入する前に、まず次の項目を確認してください。

領域	チェック項目
目的	AIに任せる業務と任せない業務を分けている
データ	AIが参照できる情報と入力禁止情報を定義している
権限	読み取り、書き込み、削除、外部送信の権限を分けている
ツール	接続する外部ツールとAPIの一覧を管理している
MCP	MCPサーバーやプラグインの信頼性を確認している
実行	高リスク操作に人間の承認を挟んでいる
ログ	ツール実行ログとAIの判断過程を追跡できる
レビュー	AI生成物を公開・納品する前の確認フローがある
事故対応	誤送信、情報漏洩、誤回答時の対応手順がある
教育	利用者に入力禁止情報と確認ルールを共有している

まず取り組むべき対策

すべての対策を一度に実装する必要はありません。初期段階では、次の5つから始めるのが現実的です。

入力禁止情報を決める 顧客情報、契約情報、認証情報、未公開の営業情報など、AIに入れてはいけない情報を明文化します。
権限を最小化する AIエージェントに最初から広い権限を与えず、読み取り専用から始めます。書き込みや外部送信は段階的に解放します。
ツール実行を監査する どのAIが、どのツールを、いつ、どの入力で実行したかを記録します。
高リスク操作に承認を挟む 削除、送信、支払い、権限変更、本番反映などはAI単独で完結させない設計にします。
公開前レビューを仕組みにする AIが作成した文章、コード、設定、顧客向け回答をそのまま公開・納品しないためのチェックリストを作ります。

AIエージェントは「便利な自動化」ではなく「権限を持つ実行主体」として扱う

AIエージェントの導入で失敗しやすいのは、チャットAIの延長として軽く扱ってしまうことです。外部ツールや社内データに接続した瞬間、AIエージェントは単なる文章生成ツールではなく、権限を持つ実行主体になります。

そのため、重要なのは「AIを使うか使わないか」ではなく、どこまで任せ、どこで止め、どのログを残し、誰が最終責任を持つかを設計することです。

AIエージェントの価値は、業務を自動化できることにあります。しかし安全に使うには、自動化の前に境界線が必要です。権限、データ、ツール、承認、監査を設計してはじめて、AIエージェントは実務で使える存在になります。

AIエージェントやAIチャットボットの導入、MCP連携、AIコーディング環境のセキュリティ設計にお困りですか？弊社のサービスでは、開発チームがAIを安全に活用するための設計・導入・運用支援を提供しています。ぜひお気軽にご相談ください。

関連記事: