AIエージェントに顧客データを渡す前に。Salesforceに学ぶセキュリティの3層

「顧客データを、外部のAIに渡して大丈夫なのか」。 AIエージェント導入のご相談で、ほぼ必ず出てくる問いです。 答えは、AIそのものより手前の権限設計と運用で決まります。

AIのセキュリティは「1本の木」で考える

Salesforceは、AIのセキュリティを1本の木にたとえて説明しています。 このたとえは、Salesforce以外のAI導入にもそのまま当てはまります。

• 枝葉：Slackやチャット画面、エージェントの応答など、ユーザーが触れる部分
• 幹：すべてのやり取りが通る関所。Salesforceでは Einstein Trust Layer がこれにあたります
• 根：ID・認証、権限、項目レベルセキュリティ、監査ログ、暗号化といった基盤

AIのリスクというと、つい枝葉（AIが何を答えたか）に目が向きます。 しかし、見た目が元気な木でも、根が弱ければ強風で倒れます。 事故の多くは、根と幹の設計が甘いところから起きます。

幹：Trust Layer はプロンプトをどう守っているか

Einstein Trust Layer は、ユーザーと大規模言語モデル（LLM）の間に入る仕組みです。 AIへの依頼（プロンプト）は、LLMに届くまでに次の処理を通ります。

• 安全なデータ取得：プロンプトに差し込むデータには、操作しているユーザーの権限がそのまま適用されます。普段見られないデータは、AI経由でも取得されません
• データマスキング：氏名や住所、カード番号などを、意味を表すプレースホルダーに置き換えてから送信します
• プロンプト防御：巧妙な指示でAIに想定外の動作をさせる「プロンプトインジェクション」を防ぐための指示を、自動で付け加えます

LLMから回答が返ってくるときにも、守りが入ります。

• データ保持ゼロ：外部のLLMプロバイダーには、プロンプトも回答も保存させない契約になっています。自社データが他社のモデルの学習に使われることはありません
• 有害コンテンツの検出：回答の有害性を、暴力・性的・冒涜・憎悪・身体の5カテゴリでスコアリングします
• 監査履歴：プロンプト、修正前の回答、スコア、フィードバックを、タイムスタンプ付きで記録します

ただし、Trust Layer があれば全部守られる、というわけではありません。

たとえば、LLMへのデータマスキングは現在エージェントでは無効になっています。 サービス返信や作業概要といった埋め込み型の生成AI機能では使えますが、 エージェントで同じ保護を前提にすると、設計を誤ります。 どの機能で、どの保護が効いているのか。機能ごとに確認することが出発点です。

根：権限設計がいちばん効く

AIエージェントは、Slack、Teams、自社アプリ、MCP経由の外部AIツールなど、 これまでになかった入口からデータにアクセスします。 ここで押さえておきたい原則が2つあります。

1つ目は「オープンアクセスであって、オープンバイパスではない」です。 入口がどこであっても、通常の画面から操作するときと同じ認証と権限チェックを通します。 Salesforce Hosted MCP Server も、専用のOAuthスコープとPKCE付きの認証を使い、 参照専用のサーバー、範囲を絞った名前付きクエリ、特定のApexアクションだけを公開する、 といった形で、エージェントにできることを細かく制御できます。

2つ目は最小権限です。 ある銀行では、サービスエージェントに「ケースの状況と優先度を返す参照操作」だけを公開し、 支払い関連の項目は最初から対象外にしました。 こうしておけば、エージェントが悪意ある指示を受け取っても、機密データには届きません。

• データを変更しないユースケースは、参照専用から始める
• 返すのは、タスクに必要なオブジェクト・項目・レコードだけにする
• 漠然とした広いリクエストではなく、的を絞ったクエリにする
• 更新権限は、参照専用の設計をテストして承認されてから追加する

影響度で「人間の確認」の入れ方を変える

すべての操作に承認を挟むと、エージェントを入れた意味がなくなります。 逆に、すべてを自動にするのは危険です。 私たちは、操作の影響度で3段階に分けて設計しています。

• 影響度・低：範囲が限定的で取り消せる操作は自動で実行する（例：残高の照会）
• 影響度・中：AIが変更案を出し、人間が確認して実行する（例：請求への異議申し立て）
• 影響度・高：正式な承認フローに回し、上長の承認を必須にする（例：利用限度額の大幅な引き上げ）

本番の前に、監視とインシデント対応を決めておく

権限を絞っても、リスクはゼロになりません。 エージェントの処理は「Teams → 自社アプリ → エージェント → Salesforce」のように複数のシステムをまたぐため、 どのシステムがどのログを持ち、誰が見られて、何日保存されるのかを、 リリース前に文書化しておく必要があります。

インシデントが起きたときの流れも、事前に決めておきます。

• トリアージ：何が起きているのかを把握する。機密データが危ないなら、情報が揃うのを待たずに動く
• 封じ込め：ツールの無効化やアクセス権の取り消しで、被害を止める
• 調査：ログが消える前に証拠を保全し、時系列を整理する
• 修復と復旧：過剰な権限を直し、最小限の機能から段階的に再開する
• 教訓：誰かを責めず、再発防止策を決める。改善策を検証して初めて完了とする

まとめ：導入前に確認したい5つのこと

• AIに渡すデータは、ユーザーの権限の範囲内に収まっているか
• 外部のLLMに対して、データを保持させない取り決めはあるか
• エージェントの権限は、参照専用・最小限から始めているか
• 影響の大きい操作に、人間の承認を組み込んでいるか
• ログの所在とインシデント対応の手順が、本番稼働の前に決まっているか

AIのセキュリティは、壁を高くして使わせないことではありません。 根（権限）を張り、幹（Trust Layer）を通し、そのうえで枝葉（活用シーン）を伸ばしていく。 この順番を守るだけで、AIエージェント導入の安全性は大きく変わります。