AIエージェントが企業データを漏らす5つの経路｜経理AXで守るべき設計原則

なぜ今このリスクが議論されているのか

AIエージェントは『社内データを読み込んで判断する』『外部APIに問い合わせる』『複数のシステムをまたいで処理する』という性質上、設計を誤ると機密データを意図せず外部や非権限者に渡してしまう可能性があります。2026年に入ってから、海外の研究機関やセキュリティベンダーがこのリスクを定量的に示すレポートを相次いで公開しており、エンタープライズAI導入の論点として急速に重要度が上がっています。

経理・人事・契約管理のように、漏洩した時のインパクトが大きい領域では、AIエージェントを入れる『ついで』にセキュリティ設計を見直すべきタイミングに来ています。

漏洩が起きる5つの経路

AIエージェントの実装現場で実際に観測される、または研究で報告されている漏洩経路を5つ整理します。

経路1 — 外部APIへのプロンプト送信

最も基本的かつ見落としやすい経路です。AIエージェントが処理する内容が、そのままLLMベンダーのAPIに送られます。社内文書・顧客情報・契約条項・財務データを含めたまま外部APIを叩くと、データはベンダーのサーバを経由します。多くのベンダーは『学習に使わない』と明示していますが、社内ポリシーで外部送信そのものがNGの場合は別の設計が必要です。

経路2 — Tool useで他システムから無権限データを引いてくる

エージェントが社内DBや他SaaSのAPIを呼び出せる構成にすると、ユーザーが本来見られない情報をエージェント経由で取得してしまうケースがあります。たとえば一般社員からの問い合わせに対して、エージェントが裏側で経営層しか閲覧できない財務データを参照して回答に混ぜてしまう、といった事例です。Tool use の権限境界をエージェント側で制御しないと発生します。

経路3 — 永続メモリへの不適切な保存

Claude Managed AgentsやOpenAIの永続メモリ機能を使うと、エージェントは過去のやり取りを記憶し続けます。これは便利な反面、機密データが意図せずメモリに長期保存され、別のセッションで別ユーザーに対する応答に紛れ込むリスクがあります。メモリに何を残すかのポリシー設計が必要です。

経路4 — プロンプトインジェクション経由の情報引き出し

外部から取り込んだ文書（メール本文、添付PDF、ウェブページ）に悪意ある指示が埋め込まれていて、エージェントがその指示に従って『裏側のデータベースから情報を取り出して送信する』ような挙動を引き起こすケースです。エージェントが『取り込んだ文書の内容』と『システム指示』を区別できる設計になっていないと発生します。

経路5 — ログ・キャッシュへの機密情報残存

エージェントの動作ログ、APIゲートウェイのキャッシュ、デバッグ用のトレースに機密データがそのまま記録されてしまうケースです。運用初期は監査・デバッグのために多めに記録しがちですが、その情報が長期保管され、後から別のチームに共有される過程で漏洩につながることがあります。

経理AXで採用している防御設計の原則

弊社が経理AX案件で導入時に必ず議論する、防御設計の5原則を共有します。

原則	具体的な対応	対応する漏洩経路
データ最小化	エージェントに渡す情報を業務遂行に必要な最小限に絞る	経路1・2
権限境界の明示	Tool use できるAPIごとに、ユーザー権限と紐付けたアクセス制御を入れる	経路2
メモリ保存ポリシー	永続メモリには『何を残し、何を残さないか』の明文ルールを置く	経路3
指示と内容の分離	外部から取り込んだ文書を『データ』として扱い、指示として実行しない	経路4
ログマスキング	機密情報はログに残さない or 取得時にマスキング処理を挟む	経路5

5原則のうち、もっとも見落とされやすいのが『データ最小化』です。エージェントの精度を上げたい一心で社内データを丸ごと渡したくなりますが、業務に不要なデータは最初から渡さないのが、漏洩リスクを下げる最も確実な方法です。

オンプレミスを選択肢に入れる

経理データ、人事データ、契約書類のように『そもそも外部APIに送りたくない』データを扱う業務では、オンプレミスや閉域クラウドで動く生成AI環境が現実的な選択肢になります。Claude SecurityやOpenAIのEnterprise契約ではガバナンス機能が強化されていますが、それでも『社外にデータを出すかどうか』はビジネス上の判断として残ります。

オンプレミスは高コストと思われがちですが、業務範囲を絞った導入なら、専用GPUサーバー1〜2台と運用設計で十分動くケースが多くなっています。データの所在が社内に閉じている安心感が、現場の心理的抵抗を一気に解消する効果も大きいです。

導入前に経営層と握っておくべき3つの問い

AIエージェント導入の意思決定をする前に、経営層と以下の3点を明確にしておくと、後のトラブルが大幅に減ります。

1. 漏洩が起きた時、誰がどの責任を負うか — エージェントの設計者、運用者、利用部門のそれぞれの責任範囲を文書化しておく
2. 機密度別にデータの扱いを切り分けているか — 全データを同じ扱いにせず、機密度の高いデータだけはオンプレミスや閉域クラウドで処理する設計を組む
3. インシデント発生時の通報・公表フローが決まっているか — 漏洩を疑う事象が起きた時に誰に何分以内に通報するか、社外公表の判断基準は何かを事前に決める

はてなベースが現場で見えていること

見えていること1 — 漏洩リスクは『運用フェーズで顕在化する』

PoCや初期導入の段階では使う人が限られているためリスクが見えにくく、運用が広がってから問題が顕在化します。導入時にセキュリティ設計をしっかり仕込んでおかないと、後から差し込むコストは数倍になります。

見えていること2 — 『誰が責任を取るか』を握れていない案件は止まる

漏洩リスクの議論を経営層と握れていない案件は、本格運用に入る直前で必ず止まります。設計担当・運用担当・経営層の責任範囲を最初に明文化しておくと、運用フェーズへの移行が滞らずに進みます。

見えていること3 — オンプレミスは中堅企業でも現実解になっている

数年前まで『オンプレミスのAIは大企業向け』という認識が一般的でしたが、業務範囲を絞れば中堅企業（売上数十〜数百億円規模）でも現実的に運用できる事例が増えました。経理・人事・契約管理など機密度の高い業務では、オンプレミス選択肢の検討を導入初期から組み込むのが推奨されます。

まとめ

• AIエージェントが企業データを漏らす経路は外部API送信／Tool useの無権限参照／永続メモリの蓄積／プロンプトインジェクション／ログ残存の5つ
• 防御の基本5原則はデータ最小化／権限境界の明示／メモリ保存ポリシー／指示と内容の分離／ログマスキング
• 経理・人事・契約管理など機密度の高い業務では、オンプレミス／閉域クラウド構成を最初から選択肢に入れる
• 導入前に責任範囲・機密度別設計・インシデント対応フローを経営層と握る
• セキュリティ設計は導入時に仕込まないと、運用フェーズでのコストが数倍になる