AIエージェントのセキュリティリスクとAgentforceの対策設計｜OWASP 2026対応の実践ガイド

攻撃者がシステムへ侵入してから次のシステムへ移動を始めるまでの時間は、2025年の平均で29分、最も速い事例では27秒まで短縮されています。攻撃の速度がここまで上がるなかで、AIエージェントの導入を検討していても、セキュリティのリスクをどこから抑えればよいのか判断がつかないまま、検討が止まっている企業も少なくありません。AIエージェントのセキュリティとは、ツールの設定を個別に固める作業ではなく、エージェントがどこまで自律的に実行し、どのデータにアクセスするかを先に決める設計のことです。

※参考記事：CROWDSTRIKE「2026 CrowdStrike Global Threat Report: AI Accelerates Adversaries and Reshapes the Attack Surface」

そこで本記事では、AIエージェントのセキュリティリスクを整理したうえで、AgentforceのEinstein Trust LayerがOWASPの挙げるリスクにどのように対応し、導入時に何を設計すべきかを、コンプライアンス要件や費用まで含めて解説します。

この記事を書いた人

本田正憲

合同会社クロスコムの代表｜専門商社にて7年間のBtoB営業を経て、マーケティング業界に参入。現在はSalesforce公式コンサルティングパートナーとして、ソリューション営業の業務プロセスに特化したAgentforce導入・定着支援を提供している。

AIエージェントのセキュリティが従来のSaaSと根本的に違う3つの理由

本記事で例に取り上げるのは、医療機器の販売・保守を手がける中堅企業（従業員約350名・IT部門3名・Salesforce導入済み）が、月およそ1,200件寄せられる問い合わせの一次対応をAIエージェントに任せるにあたって、セキュリティ設計に取り組んだケースです。そこでここでは、AIエージェントのセキュリティが従来のSaaSと根本的に違う3つの理由を整理します。

AIエージェントのセキュリティが従来のSaaSと違うのは、人間が介在しない自律実行・複数のLLMへのデータ流通・従来の対策が想定しない攻撃という、3つの理由からです。

理由①AIエージェントは自律的に判断・実行するため人間が介在しない操作が発生する

1つ目の理由は、AIエージェントが自律的に判断・実行するため、人間が介在しない操作が発生することです。従来のSaaSが人の操作を起点に権限を設計してきたのに対し、AIエージェントでは、目的だけを与えられたエージェントが、参照するデータと実行するアクションを自分で選びます。

これまでのシステムでは、担当者がボタンを押して初めて処理が動いていました。AIエージェントの場合、人間が介在しない操作は参照だけにとどまらず、レコードの更新や外部への送信にまで及びます。担当者の確認を通らない操作が生まれるため、その範囲をあらかじめ設計しておかないと、想定外の動作を止められません。

たとえば、この医療機器の企業では、顧客対応のエージェントが購入履歴と保守契約を参照し、そのまま返答まで進める設計を検討していました。担当者が内容を確かめる工程がどこにも入っていなかったため、どこまでを自動で進めさせるかを先に決める必要があったのです。

人の確認を挟まずに実行してよい操作かどうかは、誤った場合に取り消せるかどうかで線を引きましょう。

理由②複数のLLMとデータソースにまたがってリクエストが発生してデータが外部に渡る

2つ目の理由は、複数のLLMとデータソースにまたがってリクエストが発生し、データが外部に渡ることです。AIエージェントは一つの依頼に答えるために、社内のデータベースやナレッジを参照し、その内容を含んだプロンプトを外部のLLMへ送ります。

参照するデータソースが増えるほど、外部へ渡る情報の種類も増えていき、顧客情報や機密データが、回答を組み立てる過程でLLMへ渡ることもあります。どの情報が、どの経路で、どのモデルへ渡るのかを把握しておかないと、保護すべき対象を特定できません。経路を数える単位は、エージェントごとよりもデータソースごとに置くほうが、把握しやすくなります。

実際に、この医療機器の企業では、顧客の氏名や購入した機器の型番を含むやり取りが、回答の生成時に外部のLLMへ渡る可能性を洗い出しました。データが自社の管理を離れる経路が3つあると分かり、それぞれに保護をかける前提で設計を始めたのです。

洗い出しの単位は、エージェント1体につき参照先のデータソースを5つ以内に絞ると、経路の管理が現実的になります。

理由③プロンプトインジェクション攻撃など従来の対策が想定しないリスクがある

3つ目の理由は、プロンプトインジェクション攻撃など、従来の対策が想定しないリスクがあることです。プロンプトインジェクションとは、不正な指示を紛れ込ませて、AIの動作を乗っ取る攻撃を指します。従来のセキュリティは、不正アクセスやマルウェアといった既知の脅威を前提に、ネットワークと権限の側で守りを固めてきました。

では、なぜ従来の対策では防ぎきれないのでしょうか。それは、プロンプトインジェクションが狙う対象が、システムの脆弱性ではないからです。狙われるのは、AIへ与える入力の中身になります。

この医療機器の企業の場合は、外部からの問い合わせに不正な指示が紛れ込む可能性を、従来のセキュリティ対策の点検表から外していました。ファイアウォールとアクセス制御の項目はそろっていたものの、AIエージェント特有の攻撃を評価する項目が1つもなかったのです。

逆にいえば、社内の担当者だけが入力するエージェントであれば、この攻撃の経路は限られており、外部からの入力を受けるかどうかで必要な対策の重さは変わります。以上が、AIエージェントのセキュリティが従来のSaaSと違う3つの理由でした。

Agentforce導入で生じる3つのセキュリティリスク

従来と違う3つの理由を押さえると、Agentforceの導入で具体的にどんなリスクが生じるかが見えてきます。これらのリスクは、アプリケーションのセキュリティリスクを整理・公開する非営利団体のOWASPが2025年12月9日に公開した「OWASP Top 10 for Agentic Applications 2026」で、ASI01からASI10までの分類にまとめられました。そこでここでは、Agentforce導入で生じるセキュリティリスクを3つ整理します。

※参考記事はこちら

Agentforce導入で生じる主なリスクは、エージェントの目標乗っ取り・ツールの悪用・権限とアイデンティティの悪用という、OWASPがASI01からASI03に挙げる3つに集約されます。

リスク①プロンプトインジェクションでエージェントが意図しない動作をする

1つ目のリスクは、プロンプトインジェクションによって、エージェントが意図しない動作をすることです。OWASPはこれをASI01「Agent Goal Hijack（エージェントの目標乗っ取り）」としてリストの先頭に置き、10項目のなかでも最初に手を打つべきリスクとして扱っています。

不正な指示を紛れ込ませることで、エージェントを本来の目的から外れた動作へ誘導できます。Adversa AIが2025年に公表した調査では、実際に起きたAIセキュリティインシデントの35%が、単純なプロンプトによって引き起こされていました。専門的な技術がなくても成立するため、発生の頻度も高くなります。

※参考記事はこちら

具体例でいうと、この医療機器の企業では、外部の顧客が入力する問い合わせに悪意ある指示が混ざる場面を想定し、月およそ1,200件の問い合わせすべてが攻撃の経路になりうると整理しました。件数の多さから、最も頻度の高いリスクとして優先的に検討したのです。

対策の優先順位は、そのエージェントが外部からの入力を受け取るかどうかを、最初の判断材料にしましょう。

リスク②ツールの悪用でエージェントが正規の権限内で意図しないアクションを実行する

2つ目のリスクは、ツールの悪用によって、エージェントが正規の権限の範囲内で意図しないアクションを実行することです。OWASPの分類ではASI02「Tool Misuse（ツールの悪用）」にあたり、通常のアクセス制御では見つけにくいリスクになります。なぜ見つけにくいかというと、エージェントは与えられた権限を逸脱せず、その範囲の中で不正に動かされるからです。

エージェントには、業務のために特定のツールやアクションを実行する権限が与えられており、それを悪用されると、正規の操作に見える形で意図しない処理が進みます。権限があること自体は正しくても、その使われ方が問題になります。

先ほどの医療機器の企業を例にとると、保守記録を更新する権限を持つエージェントが、不正な指示によって誤った点検結果を書き込んでしまう場面を懸念していました。権限の逸脱がないため、アクセスログを見ても異常として浮かび上がらない点が問題だったのです。

逆にいえば、参照だけを許して更新のアクションを持たせなければ、このリスクは大きく下がります。

リスク③権限昇格と委任チェーンの操作で機密データへの不正アクセスが発生する

3つ目のリスクは、権限昇格と委任チェーンの操作によって、機密データへの不正アクセスが発生することです。OWASPの分類ではASI03「Identity & Privilege Abuse（アイデンティティと権限の悪用）」にあたり、エージェントが持つ資格情報や権限が、想定を超えた範囲で使われる状態を指します。

複数のエージェントが連携し、権限を受け渡しながら処理を進める構成では、その委任のチェーンが攻撃の対象になります。どのエージェントが、誰の権限で動いているのかを記録しておかないと、到達できた範囲を後から説明できません。

この医療機器の企業では実際に、顧客対応のエージェントと保守手配のエージェントを連携させる構成を検討し、権限の受け渡しが悪用される経路を洗い出しました。医療関連のデータを扱うため、エージェントごとに専用のユーザーを分ける設計へ切り替えたのです。

エージェントを増やすときは、1体につき1つの専用ユーザーを用意し、共有ユーザーでの委任は避けましょう。ここまでが、Agentforce導入で生じる3つのセキュリティリスクです。

AgentforceのEinstein Trust LayerがOWASPのリスクに対応する4つの仕組み

3つのリスクに対して、AgentforceはEinstein Trust Layerで対応します。Einstein Trust Layerとは、AIとやり取りされるデータやプロンプトを各工程で検査し、安全性を確保するSalesforceの信頼基盤のことです。そこでここでは、OWASPのリスクに対応する4つの仕組みを解説します。

Einstein Trust Layerは、動的データマスキング・ゼロデータ保持・プロンプトディフェンスと有害性検出・監査証跡という4つの仕組みで、OWASPのリスクに対応します。

下の表で、OWASPのリスクと、主に対応するEinstein Trust Layerの仕組みの関係を整理します。

仕組み①動的データマスキングで個人情報をLLM送信前に自動マスキングする

1つ目の仕組みは、動的データマスキングによって、個人情報をLLMへの送信前に自動でマスキングすることです。Salesforceでの機能名はデータマスキングで、氏名や住所といったPIIを検出し、LLMへ送る直前にトークンへ置き換えます。

置き換えは、正規表現による検出と、機械学習モデルによる検出を組み合わせて行われ、外部のモデルには伏せ字の状態で渡ったうえで、返ってきた応答の中で元の値に戻されます。この置き換えは、担当者が個別に設定しなくても毎回はたらきます。そのため、保護の有無が担当者の習熟度によって変わることもありません。

たとえば、この医療機器の企業では、顧客の氏名や購入した機器の型番を含むやり取りが、送信の前に自動でマスキングされることを確認しました。外部のLLMに実際の個人情報が渡らない状態を、担当者の設定に頼らず保てたのです。

ただし、マスキングは検出できた項目にはたらく仕組みのため、自由入力の本文へ個人情報を書き込ませない運用も、あわせて必要になります。

※参考記事はこちら

仕組み②ゼロデータ保持でLLMプロバイダーへのデータ保持・学習利用を防ぐ

2つ目の仕組みは、ゼロデータ保持によって、LLMプロバイダー側でのデータの保持や学習利用を防ぐことです。この仕組みは、担当者や管理者の設定に関係なく適用される点に価値があります。なぜ設定によらない適用が重要かというと、保護を個別の設定に委ねると、設定の見落としがそのまま情報の残存につながるからです。

ゼロデータ保持は、SalesforceとLLMプロバイダーとの取り決めと仕組みの両面で、送ったデータが保持・閲覧・学習利用されないことを担保しており、応答を返した時点でプロバイダー側のデータは削除されます。この保護は、Agentforceから外部のモデルを呼び出すすべての経路に適用されます。

実際に、この医療機器の企業では、外部のLLMへ渡ったデータが学習に使われない状態を、社内の情報管理規程に照らして確認しました。強制的に適用される仕組みだったため、規程の要件を運用ルールで補う必要がなかったのです。

自社で追加の対策が要るかどうかは、社内規程が外部への送信を禁じているかどうかまで確認して判断しましょう。

仕組み③有害性検出とプロンプトインジェクション防御をリアルタイムで実行する

3つ目の仕組みは、有害性検出とプロンプトインジェクション防御を、リアルタイムで実行することです。Salesforceでの機能名はプロンプトディフェンスと有害性検出で、前者はLLMへ送るプロンプトにガードレールとなる指示を追加し、後者は生成された応答を顧客へ返す前に検査します。

プロンプトディフェンスは、不正な指示に従わないようにする指示を、システムの側からプロンプトへ付け加えます。有害性検出は、応答の内容をカテゴリごとにスコア付けし、不適切な表現を含む応答を検知する役割です。入力の側と出力の側の両方に、検査の工程が入ります。

この医療機器の企業の場合は、顧客の問い合わせに紛れた不正な指示に対して、エージェントが元の役割から外れないことを、稼働前のテストで確認しました。誤った回答が顧客へ届く前に止まる工程があることを、IT部門の3名で実際に試したのです。

ただし、この検出は100%の精度を前提にできる仕組みではありません。重要な判断を含む応答は、人が確認する工程を残しておきましょう。

仕組み④監査証跡で全プロンプトのトランザクションを記録して追跡できる

4つ目の仕組みは、監査証跡によって、すべてのプロンプトのトランザクションを記録し、追跡できることです。記録はData 360（旧Data Cloud）に保存され、送受信されたプロンプト、マスクされたデータ、有害性のスコア、実行の時刻までが残ります。

権限の範囲内で起きた不正は、アクセス制御では検知できません。記録をたどって、誰の権限で、どのデータを参照し、どのアクションを実行したのかを確認して初めて、異常だと判断できます。

具体例でいうと、この医療機器の企業では、エージェントがどのデータにアクセスし、どんな処理を実行したのかを、監査証跡から追える状態を整えました。記録をSQLで抽出できるため、IT部門が月次で確認する手順を決められたのです。あわせて、記録を残す対象を顧客対応のエージェントに絞り、確認する件数を扱いやすい量にとどめました。

記録は残すだけでは機能しないため、確認の頻度は月1回を最低ラインとして決めておきましょう。以上が、OWASPのリスクに対応する4つの仕組みでした。

※参考記事はこちら

Agentforce導入時に設計すべきセキュリティ設定5選

Einstein Trust Layerは基盤として守りを固めますが、それだけで設計が完結するわけではありません。導入する企業の側で決めるべき設定は、なお残ったままです。そこでここでは、Agentforce導入時に設計すべきセキュリティ設定を、5つ整理します。

導入企業が設計すべきは、最小権限・顧客認証・参照データ範囲・ハンドオフ基準・監査モニタリングという5つの設定です。

設定①エージェントユーザーのアクセス権限を必要最小限に絞る

1つ目の設定は、エージェントユーザーのアクセス権限を、必要最小限に絞ることです。ここでの最小限とは、業務が続く範囲で最も狭い権限を指します。なぜ最も狭い範囲まで絞るかというと、権限昇格やツールの悪用が起きたときに、到達できるデータの範囲がそのまま被害の範囲になるからです。

エージェントには専用のユーザーを用意し、権限セットで参照・更新できるオブジェクトを指定しますが、広い権限を与えるほど、悪用されたときの影響も大きくなります。逆に、業務に必要な範囲だけへ限定しておけば、不正に動かされても、到達できるデータや操作は限られます。

先ほどの医療機器の企業を例にとると、顧客対応のエージェントに、当初は18種類のオブジェクトへの参照・更新を与える設計になっていました。対応に必要な範囲を業務ごとに洗い直した結果、6種類まで絞り込んだのです。

絞り込みの目安として、1つのユースケースで参照するオブジェクトが10種類を超えたら、対象の業務を分けることを検討しましょう。

設定②外部チャネルに展開する場合は顧客認証の確認設計を必須にする

2つ目の設定は、外部チャネルに展開する場合、顧客認証の確認設計を必須にすることです。ここでの確認設計とは、応答している相手が誰であるかを、個人情報を扱う前に確定させる仕組みを指します。

社内で使うエージェントと違い、外部に公開するエージェントは不特定の相手とやり取りするため、認証を経ずに個人情報を扱わせると、なりすましによる情報漏えいにつながります。そこで、認証済みのユーザーだけが到達できる範囲と、誰でも到達できる範囲を分けて設計します。分け方の基準は、回答に顧客ごとの値が入るかどうかに置きます。

この医療機器の企業では実際に、顧客向けのチャネルにエージェントを出す前に、購入履歴と保守契約の照会を認証済みのユーザーだけに限定しました。未認証の相手には、製品の仕様と一般的な使い方の案内までを返す形にしたのです。認証の状態によって参照できるナレッジを切り替えたため、公開チャネルでも保守の問い合わせを受けられました。

認証の要否は、その回答が特定の個人と結びつく情報を含むかどうかで判断しましょう。

設定③エージェントが参照できるデータソースとナレッジの範囲を定義する

3つ目の設定は、エージェントが参照できるデータソースとナレッジの範囲を、明確に定義することです。定義の単位は、データソースごと、ナレッジの記事カテゴリごとに指定します。

参照範囲を定めないまま公開すると、社内向けに書かれた記事の内容が、そのまま回答に使われることがあります。公開してよい情報と、内部にとどめるべき情報を分け、前者だけを参照させる設計にしましょう。範囲の定義が、情報の出しすぎを防ぎます。この定義の段階で、仕入原価や代理店向けの条件のように、顧客へ開示しない前提で書かれた記事は対象から外しておきましょう。

たとえば、この医療機器の企業が社内のナレッジを点検した場面では、1,800件の記事のうち、顧客へ開示できるものは320件でした。エージェントが参照するのはこの320件だけとし、残りは対象から外したのです。除外した記事の多くは、修理単価と代理店向けの案内に関するものでした。

ただし、ナレッジは追加され続けるため、公開範囲の判定を記事の作成手順に組み込んでおきましょう。

設定④ハンドオフのルールと人間が介在すべき判断基準を明文化する

4つ目の設定は、ハンドオフのルールと、人間が介在すべき判断基準を明文化することです。明文化とは、担当者が読んで同じ判断ができる文書として残すことを指します。

すべてをエージェントに任せると、重要な判断まで人間の目を通らずに実行されてしまいます。そこで、金銭や契約が絡む場面では人へ引き継ぐ、といったハンドオフのルールをあらかじめ決めておきます。あわせて、人間が介在すべき基準を明文化しておくことが、想定外の実行を防ぐ備えになります。基準は、担当者ごとの判断に委ねず、エージェントの応答を止める条件として設定に落とし込みます。

この医療機器の企業でも、機器の不具合に関わる問い合わせは必ず人へ引き継ぐルールを定め、引き継ぎの対象を4つの類型として文書に残しました。エージェントが自律実行してよい範囲と、担当者が判断すべき範囲を、稼働の前に切り分けたのです。

引き継ぎの線引きは、判断を誤ったときに顧客の安全や契約に影響するかどうかを基準にしましょう。

設定⑤監査証跡を定期的にレビューするモニタリング体制を整える

5つ目の設定は、監査証跡を定期的にレビューする、モニタリングの体制を整えることです。体制として決めるのは、確認する頻度と担当者になります。

記録が残っていても、誰も確認しなければ問題は放置されたままになります。そこで、想定外のアクセスや、通常より多いアクションの実行がないかを、決めた頻度で確認します。この確認では、誰が、いつ、何を見るのかまで決めておくことが、継続的な監視につながります。確認した結果は、異常がなかった月も記録に残しておくと、後から傾向を比べられます。

たとえば、この医療機器の企業では、IT部門の3名のうち1名が月1回、およそ2時間かけて監査証跡を確認する運用にしました。確認の観点を、権限外へのアクセス試行とアクション実行数の急増の2点に絞ったのです。

レビューは、月1回・2時間程度を初期の目安として組み、異常が見つかった月だけ頻度を上げる形で運用しましょう。以上が、Agentforce導入時に設計すべき5つのセキュリティ設定でした。

Agentforceのセキュリティ設計が対応するコンプライアンス要件

設計すべき5つの設定を押さえたところで、これらの対策がどのコンプライアンス要件に対応するのかを確認しておきましょう。Agentforceのセキュリティ設計は、法令や社内ポリシーへの対応と切り離せません。そこでここでは、対応するコンプライアンス要件を3つ整理します。

Agentforceのセキュリティ設計は、個人情報保護法・GDPR、IPAが挙げるAIリスク、社内ポリシーという3つのコンプライアンス要件に対応します。

対応①個人情報保護法・GDPRへのEinstein Trust Layerの対応範囲

1つ目は、個人情報保護法やGDPRへの対応です。Einstein Trust Layerの動的データマスキングとゼロデータ保持が、これらの法令が求める個人データの保護のうち、外部送信にともなう部分を技術的に担います。GDPR（EU一般データ保護規則）とは、EU圏における個人データの取り扱いを定める規則のことです。

個人情報を外部のLLMへ渡さず、渡った場合も保持されない仕組みは、データ保護の要件に直接応えます。ただし、法令への対応はシステムだけで完結しません。収集と利用の同意設計とあわせて整える必要があります。

実際に、この医療機器の企業では、Einstein Trust Layerが担う範囲と、自社で整えるべき同意管理の範囲を1枚の表に切り分けて確認しました。システムが担う部分と、運用で整える部分の境界を、法務の担当者と共有したのです。

ただし、EU域内の顧客データを扱っていない場合、GDPRへの対応は優先度を下げて構いません。まず自社が扱うデータの所在から確認しましょう。

対応②IPA「情報セキュリティ10大脅威2026」3位のAIリスクへのAgentforceの対処

2つ目は、IPAが公表する脅威への対処です。IPAの「情報セキュリティ10大脅威 2026」では、「AIの利用をめぐるサイバーリスク」が組織向けの3位に初めて選出されました。ランサム攻撃による被害、サプライチェーンや委託先を狙った攻撃に次ぐ順位で、AIエージェントのセキュリティは組織が対応すべき優先度の高い課題になっています。

※参考記事はこちら

では、なぜ順位まで確認する意味があるのでしょうか。それは、公的機関が上位に挙げる脅威が、業種を問わず多くの組織が備えるべき共通のリスクとして扱われるからです。Agentforceでは、プロンプトディフェンスや監査証跡が、この優先度の高いリスクへの具体的な備えになります。

この医療機器の企業の場合は、IPAの順位を社内の説明資料に引用し、AIエージェントのセキュリティ対策の必要性を経営層と共有しました。公的な指標があったことで、稼働の前に設計期間を確保する判断が通ったのです。

社内の合意を取るときは、自社の業種に固有の脅威より先に、公的機関が挙げる共通の脅威から説明する順序にしましょう。

対応③社内のセキュリティポリシーとAgentforceの設定を整合させる方法

3つ目は、社内のセキュリティポリシーとの整合です。Agentforceの権限設計と参照範囲の設定を、自社のセキュリティポリシーやデータガバナンスの方針と、1項目ずつ突き合わせます。

法令や外部の基準に対応していても、自社の既存ポリシーと食い違っていては、運用が続きません。自社が定めるアクセス制御やデータの取り扱いのルールと、エージェントの設定を照らし合わせましょう。両者に矛盾がない状態にすることで、既存のガバナンスの枠組みの中でAIエージェントを運用できます。

具体例でいうと、この医療機器の企業では、自社のデータガバナンスポリシーとAgentforceの設定を一つずつ照合し、食い違う点を洗い出して調整しました。既存のルールとAIエージェントの運用を、矛盾なくそろえたのです。

照合は、ポリシーの条文単位で表に落とし、対応する設定を1対1で書き出す形にすると抜けが減ります。ここまでが、Agentforceのセキュリティ設計が対応する3つのコンプライアンス要件です。

AIエージェントのセキュリティ設計で陥りやすい失敗3選

コンプライアンスへの対応を踏まえても、設計を誤ると対策は機能しません。ここには、いくつか陥りやすい失敗のパターンがあるのです。そこでここでは、AIエージェントのセキュリティ設計で陥りやすい失敗を、3つ整理します。

失敗の多くは、過剰な権限の付与、セキュリティ設定の後回し、ベンダー任せでのポリシー未確認という3つに集約されます。

失敗①エージェントに過剰な権限を付与してデータアクセス範囲が制御できない

1つ目の失敗は、エージェントに過剰な権限を付与し、データアクセスの範囲が制御できなくなることです。動作の検証を優先して広い権限を渡したまま、絞り込みの工程を設けずに進めてしまう形が典型になります。

とりあえず動くように広い権限を渡すと、悪用されたときの影響範囲を説明できなくなってしまいます。権限を絞る作業は後回しにされがちですが、それが制御できないアクセスを生みます。そのため、最初から最小権限で設計することが、被害の範囲を抑える近道になります。稼働後に権限を外す作業は、業務が止まるおそれがあるぶん、判断にも時間がかかります。

先ほどの医療機器の企業でも、当初は検証を急いで、18種類のオブジェクトへの権限を与えかけました。機密性の高い人事データにまで手が届く状態になると気づき、6種類まで絞る設計へ見直したのです。

権限が過剰かどうかは、そのオブジェクトを直近1週間の業務で一度も参照しなかったかどうかを基準に、定期的に見直しましょう。

失敗②セキュリティ設定を後回しにして本番稼働後に問題が発覚する

2つ目の失敗は、セキュリティ設定を後回しにして、本番稼働の後に問題が発覚することです。この失敗は、やり直しの工数が最も大きくなる点で厄介になります。なぜ工数が膨らむかというと、稼働後の設計変更では、すでに残っている会話ログとアクション履歴の扱いまで含めて検証し直す必要があるからです。

機能の実装を先に進め、セキュリティは後で、と考えると、稼働後に想定外のアクセスや漏えいが見つかり、そこから設計をやり直す作業には、初めから組み込む場合より大きな手間がかかります。セキュリティ設計は、稼働の前に組み込むべき工程です。

この医療機器の企業では実際に、稼働前に6週間を確保してセキュリティ設計を固める方針を取りました。顧客の個人情報を扱う以上、後回しにして稼働後に問題が出れば、影響が大きいと判断したからです。

設計に充てる期間は、1ユースケースあたり4〜6週間を目安として、実装のスケジュールへ最初から組み込みましょう。

失敗③ベンダー任せにして自社のデータガバナンスポリシーとの整合性を確認しない

3つ目の失敗は、ベンダー任せにして、自社のデータガバナンスポリシーとの整合性を確認しないことです。ベンダーが提供する標準の設定は、多くの企業に共通する要件を満たすように組まれています。

導入を支援するベンダーに任せきりにすると、自社固有のルールとの食い違いが見過ごされます。標準の設定で安全だと考えると、自社のガバナンスから外れた運用になりかねないところです。自社のポリシーと照らし合わせる確認は、企業側の責任として欠かせません。

たとえば、この医療機器の企業が設計の内容を受け取った場面では、ベンダーの標準設定をそのまま受け入れず、自社のデータガバナンスポリシーと照合する工程を挟みました。医療関連データの保存期間について、標準の設定と社内規程が食い違う点が1件見つかったのです。

逆にいえば、自社のポリシーが文書として整っていなければ、照合ができません。確認の前に、基準となる文書があるかどうかを点検しましょう。以上が、AIエージェントのセキュリティ設計で陥りやすい3つの失敗でした。

Agentforceのセキュリティ対策を自社で設計できる企業の特徴

失敗のパターンを踏まえると、セキュリティ設計を自社で進められる企業と、外部の支援が要る企業に分かれます。まずは、自社で設計できる企業の特徴を整理しましょう。そこでここでは、自社でAgentforceのセキュリティ設計を進められる企業の特徴を、3つ挙げます。

自社で設計できるのは、Salesforce認定の管理者がいて、データガバナンスポリシーが文書化され、IT部門にレビュー体制がある企業です。

特徴①社内にSalesforce認定資格を持つ管理者がいる

1つ目の特徴は、社内にSalesforce認定資格を持つ管理者がいることです。ここで求められるのは、権限セットとプロファイル、共有設定を自分で組み替えられる水準の知識になります。

エージェントの権限や認証の設計は、Salesforceの権限管理の知識を前提とします。この知識を持つ認定資格者が社内にいれば、最小権限の設計やアクセス制御を、自社の手で組み立てられます。あわせて、設定の意図を社内で説明できる状態も保てます。監査や社内のレビューで設定の根拠を問われたとき、外部へ問い合わせずに答えられる点も利点です。

この医療機器の企業でも、IT部門の3名のうち1名がSalesforce認定アドミニストレーターの資格を持っており、権限セットの設計は自社で進めました。外部に頼ったのは設計の妥当性の確認だけで、設定の作業は内製できたのです。

内製できるかどうかは、権限セットとプロファイルの違いを社内で説明できる担当者がいるかどうかで判断しましょう。

特徴②自社のデータガバナンスポリシーが文書化されている

2つ目の特徴は、自社のデータガバナンスポリシーが文書化されていることです。文書化されているとは、どのデータを誰が扱えるか、どこまで外部に出してよいかが、条文として読める状態を指します。

基準が文書になっていれば、Agentforceの設定と1対1で突き合わせられます。基準が担当者の記憶にしかない場合、照合した結果を社内で共有できません。文書があるかどうかが、確認の作業を再現できるかどうかを分けます。この文書があれば、担当者が交代したあとも同じ基準で点検を続けられるため、運用の継続性にも影響します。

たとえば、この医療機器の企業では、医療機器の販売にともなう顧客データの取り扱い規程が、すでに文書として整っていました。この規程があったため、Agentforceの参照範囲の設定と条文を照合する作業を、自社だけで進められたのです。

ただし、文書があっても更新が止まっていれば基準になりません。最終の更新時期もあわせて確認しましょう。

特徴③セキュリティ設計のレビュー体制がIT部門に整っている

3つ目の特徴は、セキュリティ設計のレビュー体制が、IT部門に整っていることです。レビュー体制とは、設計した本人とは別の担当者が設定内容を確認する手順が、決まっている状態を指します。

設計した権限や参照範囲を、IT部門の別の担当者が確認して問題を洗い出します。この確認の手順がある企業は、設計の妥当性を自社で担保できます。監査証跡のモニタリングも、同じ体制の中で担当を決められます。レビューの観点をあらかじめ一覧にしておけば、確認する担当者が変わっても品質を保てます。

実際に、この医療機器の企業では、権限設計を担当した1名とは別の担当者が、設定内容を確認する手順を決めました。第三者の視点を社内で確保できたため、稼働前の見直しで2件の設定漏れを見つけられたのです。

レビューの担当は、設計者以外に最低1名を確保し、確認した内容と日付を記録に残しましょう。ここまでが、Agentforceのセキュリティ対策を自社で設計できる企業の3つの特徴です。

Agentforceのセキュリティ設計に外部支援が必要な企業の特徴

一方で、外部の支援を受けたほうがよい企業もあります。そうした企業が前提の整っていない状態で自社だけで進めると、リスクの見落としが生じます。そこでここでは、Agentforceのセキュリティ設計に外部支援が必要な企業の特徴を、3つ挙げます。

Salesforceの権限設計の経験者がいない、法令対応の方針が未定、AI特有のリスク評価を自社で行えない企業は、外部支援を検討する段階です。

特徴①Salesforceの権限設計の経験者が社内にいない

1つ目の特徴は、Salesforceの権限設計の経験者が、社内にいないことです。権限設計は、どの範囲をどう絞るかの判断を積み重ねる作業で、判断の基準は経験から得られる部分が大きくなります。

経験者が社内にいなければ、最小権限の設計や委任の管理に抜けが出やすくなります。設定は画面から行えても、絞りすぎて業務が止まる、緩めすぎて到達範囲が広がる、といった調整の勘所は判断が難しいところです。この部分は、経験のある外部の支援を受けたほうが安全です。とくに複数のエージェントが権限を受け渡す構成では、判断すべき組み合わせが一気に増えます。

この医療機器の企業の場合は、権限セットの作成は自社でできたものの、複数のエージェントをまたぐ委任の設計には経験がありませんでした。委任の部分だけを外部の支援に任せ、単体のエージェントの設定は自社で進めたのです。

逆にいえば、エージェントが1体で、他のエージェントへ処理を渡さない構成であれば、外部支援なしでも設計できます。

特徴②個人情報保護法・GDPRへの対応方針がまだ定まっていない

2つ目の特徴は、個人情報保護法やGDPRへの対応方針が、まだ定まっていないことです。この段階では、設定より前に決めるべきことが残っています。なぜ設定より前かというと、どのデータをどの同意のもとで扱うかが決まっていなければ、参照範囲もマスキングの対象も決められないからです。

対応方針が定まっていない状態でAgentforceの設定だけを進めると、後から方針が固まった段階で設計をやり直すことになります。方針の整理から必要な段階では、法令とシステムの両面を踏まえた外部の支援が有効です。方針が固まっていれば、マスキングの対象と参照範囲は、その方針から機械的に決まります。

具体例でいうと、この医療機器の企業では、保守記録に含まれる健康関連の情報の扱いについて、社内の方針が定まっていませんでした。この論点だけは外部の支援を受けて整理し、方針が決まってから参照範囲の設定に入ったのです。

支援が必要かどうかは、扱うデータの種類ごとに同意の根拠を説明できるかどうかで判断しましょう。

特徴③AIエージェント特有のリスク評価を自社単独では行えない

3つ目の特徴は、AIエージェント特有のリスク評価を、自社単独では行えないことです。ここでいうリスク評価とは、OWASPが挙げるASI01からASI10の項目を、自社の構成に当てはめて点検する作業を指します。

従来の脆弱性診断やアクセス管理の知識だけでは、AIエージェント特有の攻撃を想定した評価は難しくなります。プロンプトインジェクションや委任チェーンの操作は、既存の点検表に評価の項目が存在しません。この新しい領域の評価には、AIエージェントのセキュリティに知見を持つ支援が役立ちます。

先ほどの医療機器の企業を例にとると、従来のセキュリティ評価は自社で実施できたものの、AI特有の項目は点検表に1つもありませんでした。OWASPの10項目を自社の構成に当てはめる作業から、外部の支援を受けたのです。

評価の出発点は、OWASPの10項目のうち、自社の構成で該当するものが何項目あるかを数えるところから始めましょう。以上が、Agentforceのセキュリティ設計に外部支援が必要な企業の3つの特徴でした。

Agentforceのセキュリティ対策にかかる費用の目安

自社対応か外部支援かの判断を踏まえて、費用の全体像も確認しておきましょう。Agentforceのセキュリティ対策の費用は、大きく分けて3つです。そこでここでは、費用の目安を3つの観点から整理します。

Einstein Trust LayerはAgentforceのライセンスに含まれ、費用は主に設計・構築の外部支援と、監査・モニタリングの運用にかかります。

費用①Einstein Trust LayerはAgentforceのライセンスに含まれている

1つ目に押さえておきたいのは、Einstein Trust Layer自体は、Agentforceのライセンスに含まれていることです。動的データマスキングやゼロデータ保持、有害性検出、監査証跡は、Salesforceのプラットフォームに組み込まれた仕組みとして提供されます。

セキュリティの基盤のために、別の製品を追加で購入する必要はありません。Agentforceの費用は、エージェントの実行回数やアクション単位の従量課金が中心で、基盤の保護はその費用の中に含まれます。

この医療機器の企業では実際に、Einstein Trust Layerが追加費用なしで使えることを確認し、セキュリティ基盤の予算を別に組まない判断をしました。予算の検討を、設計と運用にかかる費用へ集中できたのです。

ただし、監査証跡はData 360（旧Data Cloud）へ保存されるため、記録する範囲と保存の期間は、見積もりの段階で確認しておきましょう。Agentforce全体の料金の考え方については、ほか記事「Agentforce料金・ライセンス完全ガイド」で詳しく解説しています。

費用②セキュリティ設計・構築にかかる外部支援費用の目安

2つ目は、セキュリティ設計・構築にかかる外部支援の費用です。この費用は、支援を受ける範囲と自社の体制によって変わります。

自社で設計できる部分が多ければ外部支援は限られた範囲で済み、権限設計の経験者がいない、リスク評価を自社で行えないといった場合は、支援の範囲が広がります。まず自社でできる範囲を見極め、不足する部分に支援を充てるのが現実的です。

たとえば、この医療機器の企業が支援の範囲を検討した場面では、委任の設計とAI特有のリスク評価の2領域に絞って外部へ依頼しました。権限セットの作成と運用は自社で担う形にして、支援の範囲を狭めたのです。

支援の範囲は、社内に判断できる担当者がいない領域だけに限る、という基準で切り分けましょう。支援会社の選び方は、ほか記事「Agentforce導入支援会社のおすすめ8選」をご参照ください。

費用③監査・モニタリングの継続運用コストの目安

3つ目は、監査やモニタリングの継続運用にかかるコストです。この費用は、監査証跡のレビューをどの頻度で、誰が行うかによって決まる部分です。導入時に一度かかる費用と違い、稼働している限り毎月発生し続けます。

では、なぜ継続的な費用を先に見込んでおく必要があるのでしょうか。それは、レビューの体制を後から組もうとすると、担当者の通常業務へ上乗せする形になり、確認が後回しになりやすいからです。自社のIT部門で担うのか、外部へ委託するのかで、費用の形も変わります。

この医療機器の企業でも、監査証跡のレビューを自社のIT部門で担う体制にし、月1回・約2時間の工数を継続的なコストとして計画に織り込みました。担当者の業務時間に、あらかじめこの2時間を確保したのです。

運用コストは、月2時間程度の工数から見込み、エージェントの数が増えた時点で見直しましょう。ここまでが、Agentforceのセキュリティ対策にかかる費用の3つの観点です。

【一問一答】AIエージェントのセキュリティに関するよくある質問

最後に、AIエージェントのセキュリティについて検索されやすい疑問に、導入判断で気になる点から順にお答えします。

AgentforceはEinstein Trust Layerによって、個人情報のマスキングとゼロデータ保持を標準かつ追加費用なしで備えています。

質問①AgentforceのデータはSalesforceのサーバー外に出るのか

回答を生成する過程で、外部のLLMへデータが渡る場面はあります。ただし、動的データマスキングによって個人情報は送信の前に伏せ字へ置き換えられ、ゼロデータ保持によって外部には保持されません。実際の個人情報がそのまま外部へ流出しない仕組みが、標準ではたらきます。

質問②AgentforceはSOC2・ISO27001などの認証を取得しているのか

Salesforceは、SOC 2やISO 27001をはじめとする各種のセキュリティ認証を取得しています。ただし、対象となるサービスや認証の範囲は製品や時期によって異なるため、自社の要件に関わる認証は、Salesforceのコンプライアンスサイトで最新の取得状況を確認するのが確実です。

※参考記事はこちら

質問③Einstein Trust Layerは追加費用がかかるのか

追加費用はかかりません。動的データマスキング、ゼロデータ保持、有害性検出、監査証跡といったEinstein Trust Layerの仕組みは、Agentforceのライセンスに含まれています。セキュリティの基盤のために、別の製品を追加で購入する必要はありません。

質問④社内情報が外部のAIモデルの学習に使われることはあるのか

ゼロデータ保持によって、LLMプロバイダーがデータを保持したり学習に利用したりすることは防がれており、応答を返した時点でプロバイダー側のデータは削除される仕組みです。この保護はシステムのレベルで強制的に適用されるため、担当者の設定に関係なくはたらきます。

質問⑤IT担当なしで自社対応できるのか

権限設計やAI特有のリスク評価には、一定の知見が求められます。Salesforce認定の管理者やIT部門のレビュー体制がある企業は自社で進められますが、そうした体制がない場合は、権限設計とリスク評価の部分で外部の支援を検討するのが現実的です。

AIエージェントのセキュリティはツールの設定より先にエージェントが自律実行する範囲とデータアクセスの設計から始まる

AIエージェントのセキュリティは、ツールの設定を個別に固めることより先に、エージェントがどこまで自律的に実行し、どのデータにアクセスするかという設計から始まります。本記事では、従来のSaaSと違う理由から、OWASPが挙げるリスク、Einstein Trust Layerの対応、設計すべき設定、コンプライアンス要件までを、一続きで整理してきました。

Einstein Trust Layerが動的データマスキングやゼロデータ保持、プロンプトディフェンスで基盤を固める一方、権限の最小化や顧客認証、ハンドオフの基準といった設計は、導入する企業の側で組み立てる必要があります。今回例に挙げた医療機器の企業も、エージェントに与える権限を18種類から6種類まで絞り、参照するナレッジを1,800件のうち320件に限定したうえで、稼働前の6週間でセキュリティ設計を固めました。

稼働の後は、IT部門が月1回・約2時間のレビューを続けながら、月およそ1,200件の問い合わせの一次対応をエージェントに任せる状態を保っています。Agentforceの機能を先に押さえておきたい場合は、ほか記事「Agentforceの機能一覧」もあわせてご確認ください。本記事の内容が、自社のセキュリティ設計の検討に少しでもお役に立てれば幸いです。

自社のデータやコンプライアンス要件を踏まえてAgentforceのセキュリティ設計を一緒に組み立てたい場合は、Agentforce導入・定着支援サービスにお気軽にご相談ください。1ユースケース×3ヶ月のスモールスタートから対応しています。