AIエージェントのセキュリティ対策｜企業導入で確認すべき権限・データ・承認設計

「AIエージェントにCRMを接続したいが、顧客情報まで自由に読ませてよいのか」「営業メールを作るところまでは便利だが、そのまま送信まで任せてもよいのか」「情報を漏らさないようにプロンプトへ書けば、安全対策になるのか」。

AIエージェントをPoCから本番業務へ移そうとすると、こうしたセキュリティ上の判断が避けられなくなります。

結論から言えば、AIエージェントのセキュリティは、AIに「安全に動いて」と指示するだけでは不十分です。

AIが誤った判断をする可能性を前提に、アクセスできるデータ、利用できるツール、実行できる操作を制限し、重要な変更には人の承認を置き、問題発生時には追跡・停止できる状態を作ることが重要です。

インティメート・マージャーが関わってきたAI活用に関する情報でも、AIを「提案」だけでなく「実行」へ広げるには、データの整備だけでなく、AIの判断根拠を現場が確認できる監査可能な状態や、責任設計が重要という示唆が整理されています。

この記事では、AIエージェントのセキュリティを「権限」「データ」「実行」「承認」「監査」「停止」の6つに分け、企業が本番導入前に確認したいポイントを整理します。

AIエージェントのセキュリティは、通常の生成AIと何が違うのか

通常の生成AI利用では、人が質問し、AIが文章や回答を返し、人がその回答を利用する形が中心です。

一方、AIエージェントは、許可された外部サービスや業務システムを利用しながら、複数の工程を進められます。

つまり、AIエージェントのリスクは「AIが間違った回答をするか」だけではありません。

その間違った判断を使って、何を実行できてしまうかまで考える必要があります。

企業が確認したいAI agentの主なセキュリティリスク

プロンプトインジェクションによる意図しない指示

プロンプトインジェクションとは、AIに入力される文章などへ悪意ある指示を混ぜ、元の指示とは異なる動作をさせようとする攻撃手法です。

利用者本人が攻撃文を直接入力するケースだけでなく、AIエージェントが読み込んだWebページ、メール、文書などの中に指示が含まれるケースも考える必要があります。

営業リサーチを行うAIエージェントを例にすると、企業サイトや外部資料は「調査対象のデータ」であって、そこに書かれている文章をエージェントへの命令として扱うべきではありません。

過剰な権限による誤実行

営業メールの下書きだけに必要なAIエージェントへ、メール送信、削除、CRM更新まで許可していれば、必要以上の権限を持っている状態です。

問題はAIそのものより、「本来必要のない操作まで可能にした設計」にあります。

不要なデータへのアクセス

マーケティング分析用のAIエージェントが、経営層だけが見るべき原価情報、人事情報、別部署の顧客情報まで閲覧できる必要はありません。

一つのデータ基盤へつながっているからといって、すべてをAIへ開放する必要はありません。

AIエージェントによる情報漏洩

情報漏洩は、入力時だけに起こるわけではありません。

• 本来不要なデータをAIが読み取る
• 生成結果へ内部情報が混ざる
• 外部ツールへ必要以上の情報を渡す
• ログへ機密情報を過剰に残す
• 過去の文脈やメモリを別業務で利用する

といった経路も想定します。

情報漏洩そのものの整理については、既存記事「プライバシーの新たな火種：AIエージェントの情報漏洩リスク」で詳しく扱い、本記事ではその先にある権限・実行管理を中心に考えます。

共有アカウントによって責任主体が分からなくなる

複数のAIエージェントが同じ認証情報や同じ権限で動いていると、問題発生時に「どのエージェントが何を実行したのか」を確認しにくくなります。

企業利用では、人のユーザー管理と同じように、エージェントについても識別可能な状態を検討することが重要です。

監査できないブラックボックス化

結果だけが業務システムへ反映され、「なぜ変更されたのか」「何を根拠に判断したのか」「人が承認したのか」が分からない状態では、問題発生後の原因確認が難しくなります。

プロジェクト内のAI活用情報でも、誰も停止条件を知らない、承認フローが曖昧、判断理由を説明できないといったブラックボックス化を避けることが重要な論点として整理されています。

対策の基本は「AIを信用しない」のではなく「必要以上に権限を与えない」こと

AIエージェントのセキュリティ対策では、モデルの精度だけを高めても十分ではありません。

重要なのは、モデルが意図しない判断をした場合でも、被害の範囲を制限できる構造です。

そのためには、次の6つを分けて設計します。

1. 誰として動くか
2. 何を読めるか
3. どのツールを使えるか
4. 何を書き換えられるか
5. どこで人が承認するか
6. 問題時にどう追跡・停止するか

対策1｜AIエージェント専用のIDと権限を設計する

最初に確認したいのが、「そのAIエージェントは誰の権限で動くのか」です。

人の管理者アカウントや、用途の広い共有アカウントをそのまま利用すると、AIエージェントが業務上必要のない処理まで実行できる可能性があります。

最小権限から始める

最小権限とは、業務を実行するために必要な最低限の権限だけを付与する考え方です。

例えば、商談準備を支援するAIエージェントであれば、最初は次のように設計できます。

読み取りと書き込みを分ける

「データを見る必要がある」ことと、「データを変更する必要がある」ことは別です。

まず読み取り専用で運用し、本当に必要な工程だけ書き込み権限を追加するほうが、影響範囲を管理しやすくなります。

エージェントごとに役割を分ける

複数のAIエージェントを利用する場合も、すべてに同じ権限を与えるのではなく、役割ごとに分けます。

• 調査エージェント：読み取りのみ
• 分析エージェント：指定データの読み取り
• 下書きエージェント：文章生成のみ
• 実行エージェント：承認された処理のみ実行

マルチエージェント化するほど、役割だけでなく権限の分離も重要になります。

対策2｜AIへ渡すデータを「全部つなぐ」前提にしない

AIエージェントの性能を高めたいと考えると、「できるだけ多くの社内データを接続したほうがよい」と考えやすくなります。

しかし、AIへ渡すデータは量ではなく目的から決める必要があります。

まず、自社の情報を運用上の区分へ分けます。

ここでの区分は法的な情報分類そのものではありません。実際の分類基準は、自社の情報管理規程や法務・セキュリティ部門の判断に合わせて設定する必要があります。

取得できるデータと、取得してよいデータを分ける

技術的には参照できても、その業務には不要というケースがあります。

例えば企業リサーチ用のAIエージェントなら、過去の商談内容は必要でも、同じデータベースに入っている全顧客の情報は必要ないかもしれません。

データ接続時には、「このデータがないと目的を達成できないか」を一つずつ確認します。

対策3｜プロンプトだけをセキュリティ対策にしない

「個人情報を出力しないでください」「100万円を超える処理を行わないでください」といった指示をシステムプロンプトへ書くこと自体は、AIの振る舞いを整えるうえで意味があります。

しかし、重要な業務ルールをプロンプトだけへ依存させないことが重要です。

例えば「一定額を超える処理は禁止する」という重要なルールなら、AIが判断した後に、別のシステム側でも条件を確認して拒否できる設計を検討します。

同様に、利用できるツール、送信先、書き込み対象なども、AI自身の判断だけに任せず、システム側の許可ルールを組み合わせます。

対策4｜人の承認は「AIが苦手か」ではなく「失敗時の影響」で置く

Human-in-the-Loopとは、AIの処理フローの途中に人間の確認・判断を組み込む考え方です。

すべての処理を人が確認すると、自動化の効果が失われます。

一方、すべてを自動化すると、誤判断がそのまま実行へ進む可能性があります。

承認ポイントは、AIの精度だけではなく、失敗したときに元へ戻せるか、外部へ影響するかで考えます。

承認画面で「何を承認するのか」が分かる状態にする

単に「承認しますか？」と表示されても、判断材料がなければ形だけの承認になります。

重要な処理では、少なくとも次の情報を確認できるようにします。

• 何を実行しようとしているか
• 対象は誰・何か
• どのデータを根拠にしたか
• どのシステムが変更されるか
• 変更前と変更後はどうなるか

対策5｜AIエージェントのツール利用にも制限を置く

AIエージェントは、業務を実行するために外部ツールやAPIを利用する場合があります。

このとき、「便利そうだから多くのツールを使える状態にする」のではなく、利用目的に必要なものだけに限定します。

• 不要になったツールは外す
• 利用できる機能を限定する
• 読み取りと変更系の機能を分ける
• 外部への送信先を制限する
• 異常な処理回数や金額を制限する

業務ルールが明確な部分は、AIの推論ではなく固定ルールで制御することも重要です。

対策6｜コード実行や外部処理は隔離を検討する

AIエージェントの中には、処理を行うためにコードを生成・実行できるものもあります。

このような機能を本番環境と同じ場所で無制限に動かすと、誤ったコードや意図しない処理が他のシステムへ影響する可能性があります。

コード実行が必要な場合は、利用できるネットワーク、ファイル、CPU・メモリ、実行時間などを限定した隔離環境を検討します。

「AIだから特別」というより、信頼できないコードを本番環境で直接動かさないという従来のセキュリティ原則を、AIエージェントにも適用する考え方です。

対策7｜操作ログは「何が起きたか」を再現できるようにする

AIエージェントが本番業務を実行するなら、結果だけを見るのではなく、操作経路を確認できる状態が重要になります。

例えば次のような項目を記録対象として検討します。

• 実行日時
• 利用者
• 実行したAIエージェント
• 利用したツール
• 参照したデータソース
• 実行した操作
• 人による承認の有無
• 処理結果
• エラー・停止理由

ただし、ログへすべての入力データをそのまま保存すると、ログ自体が新たな機密情報の保管場所になる場合があります。

監査に必要な情報と、保存する必要のない機密情報を分けることも重要です。

対策8｜「止められること」を本番要件にする

AIエージェントの安全設計では、正しく動くことだけでなく、異常時に止められることも重要です。

例えば次の状況を想定します。

• 通常とは異なる大量処理が始まった
• 想定していないシステムへアクセスした
• 機密情報を含む出力が発生した
• 同じエラーを繰り返している
• 人が設定していない操作を実行しようとした

問題発生時には、エージェント停止、認証情報の無効化、外部連携の停止などを行える状態を事前に確認します。

「何か起きたら担当者が考える」ではなく、誰が、どの基準で、どの操作を止めるのかを決めておくことが重要です。

PoCと本番ではAIエージェントのセキュリティ要件が変わる

PoCで「正常に動いた」ことは、本番環境で安全に動かせることと同じではありません。

本番移行前には、実際に利用するデータ、権限、外部接続、利用人数を前提に再評価します。

BtoBマーケティングで考えるセキュリティ設計例

営業リサーチAIエージェント

企業情報、過去接点、商談履歴などをまとめるケースです。

• 参照企業を営業担当範囲へ限定する
• CRMは読み取りから開始する
• 個人情報を不要に出力しない
• 外部Webの文章を命令として扱わない対策を検討する
• 最終的な営業判断は担当者が行う

営業メール作成・送信AIエージェント

文章作成とメール送信は、同じ業務に見えてリスクが異なります。

最初は下書き作成までをAIとし、送信は営業担当者が確認する設計から始める方法があります。

マーケティング分析AIエージェント

分析用データに、経営情報や他部署の機密情報が混在していないかを確認します。

分析に必要な指標だけをまとめた専用データセットやダッシュボードへ接続する方法も考えられます。

コンテンツ制作AIエージェント

社内資料を参照して記事やメールを生成する場合、非公開戦略、顧客情報、未公開情報などが外部向け文章へ混ざらないようにします。

外部公開前には編集者や担当者による確認工程を残します。

2026年8月時点で企業が押さえておきたい考え方

2026年に入り、AIエージェントのセキュリティは「AIモデルの安全性」だけではなく、エージェントのID、権限、監査、プロンプトインジェクション、外部システムへの実行権限を含むテーマとして整理されるようになっています。

特に本番環境へ接続し、AIがデータベース更新や外部操作を行う場合には、プロンプトによる指示だけではなく、モデルの外側に強制的な制御を持たせる考え方が重要です。

また、日本では2026年3月31日に「AI事業者ガイドライン第1.2版」が取りまとめられており、AI活用においてはリスクの大きさに応じて対策レベルを変えるリスクベースの考え方が示されています。

企業がAIエージェントを利用するときも、すべての業務へ同じセキュリティルールを適用するのではなく、扱うデータと実行による影響に応じて対策を設計することが現実的です。

AIエージェントのセキュリティ実務チェックリスト

まとめ｜AIエージェントの安全性は「賢さ」ではなく「権限の境界」で作る

AIエージェントのセキュリティで重要なのは、「AIが絶対に間違えない状態」を作ることではありません。

AIが間違えたり、悪意ある入力の影響を受けたりした場合でも、重大なデータやシステムまで自由に操作できない状態を作ることが重要です。

そのためには、AIへ何を指示するかだけでなく、何を読めるか、何を変更できるか、どこで人が確認するか、実行後に誰が追跡できるかを整理する必要があります。

AI活用を進めたい一方、「セキュリティを考えると何もつなげられない」と感じる場合もあるかもしれません。

しかし、すべてを許可するか、すべてを禁止するかの二択ではありません。

対象業務を分解し、低リスクな読み取りから始め、必要に応じて権限を追加する。影響の大きい処理には人の承認を置く。問題時には止められる状態を用意する。

このように段階的に境界を設計することで、AIエージェントの利便性とリスク管理を両立しやすくなります。

FAQ｜AIエージェントのセキュリティに関するよくある質問

AIエージェントにはどのようなセキュリティリスクがありますか？

情報漏洩、過剰な権限、プロンプトインジェクション、意図しないツール実行、誤ったデータ変更、監査できない状態などが考えられます。AIの出力だけでなく、接続しているデータやシステムまで含めて評価することが重要です。

AIエージェントと生成AIでは情報漏洩リスクが違いますか？

AIエージェントは外部データや業務システムと接続し、複数工程を処理するケースがあるため、漏洩経路が増える可能性があります。入力情報だけでなく、検索対象、メモリ、ログ、外部ツール、生成結果まで確認します。

プロンプトに禁止事項を書けばセキュリティ対策になりますか？

振る舞いを整える手段にはなりますが、重要なセキュリティ制御をプロンプトだけへ依存しないほうが安全です。権限制御、入力・出力検査、実行上限、人の承認などを組み合わせて考えます。

AIエージェントにはどの程度の権限を与えるべきですか？

対象業務に必要な最小限から始めるのが基本です。例えば情報収集だけなら読み取り権限に限定し、変更や外部送信は必要性を確認して段階的に追加します。

AIエージェントに人の承認は必要ですか？

すべての処理に必要とは限りません。顧客への外部送信、重要データの変更、金銭、契約、削除など、失敗時の影響が大きい処理ほど人の承認を残すことを検討します。

AIエージェントの操作ログには何を残すべきですか？

実行日時、利用者、エージェント、利用ツール、操作内容、承認、結果、エラーなどが候補です。一方でログへ機密情報を過剰保存しないよう、監査に必要な情報を整理する必要があります。

AIエージェントのセキュリティ対策はどこから始めればよいですか？

まず一つの業務を選び、利用データ、必要権限、外部への影響、人の承認箇所を書き出します。その後、読み取り専用など影響の小さい範囲からPoCを始めると整理しやすくなります。