Einstein Trust Layerとは？AIに一任する範囲と人が承認する場面の設計

攻撃者がシステムへ侵入してから次のシステムへ移動を始めるまでの時間は、2025年の平均で29分、最も速い事例では27秒でした。

※参考記事はこちら

この速度でリスクが動くなかで、Agentforceを導入したいものの、情報システム部門と法務の承認が下りず、検討が止まったままになっている企業も少なくありません。Einstein Trust Layerとは、Agentforceが外部のLLMとやり取りするデータを、送信前のマスキングから応答の採点、記録の保存まで各工程で保護する仕組みのことです。

ただし、この記事で先に決めるのは機能の設定ではありません。AIエージェントへ一任する範囲と、人が承認する場面の境界です。本記事は2026年8月時点で公式ドキュメントから確認できた内容にもとづいて整理しています。

この記事を書いた人

本田正憲

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

AIエージェントの社内承認が止まる3つの状況

本記事で例に取り上げるのは、人材紹介と人材派遣を手がける中堅企業（従業員約500名・IT部門4名・Salesforce導入済み）が、登録者と取引先の双方から月およそ1,200件寄せられる問い合わせの一次対応を、AIエージェントに任せようとして社内の承認が下りずに止まったケースです。事業部門は早く進めたいのに、情報システム部門と法務へ説明するたびに検討が最初からやり直しになる状態に置かれている担当者は、少なくないのではないでしょうか。承認が止まっている企業に共通しているのは、AIエージェントへどこまで任せるのかという範囲が、社内の言葉で決まっていない状態です。そこでここでは、AIエージェントの社内承認が止まる3つの状況を整理していきます。

状況①外部のAIへデータを渡す懸念が解けない

1つ目は「外部のAIへデータを渡す懸念が解けない」です。情報システム部門と法務が確かめたいのは、AIエージェントが便利かどうかという点ではありません。求職者の氏名や職務経歴が、どの経路で社外へ出て、誰が見られる状態になるのかという1点にあります。

なぜなら、これまでの社内システムでは、データが社外へ出る経路は業務委託契約を結んだ相手だけに限られており、経路を数え上げることができたからです。AIエージェントは外部のLLMへ問い合わせの内容を送るため、経路の数え方が変わります。

この人材サービスの企業では、問い合わせ対応で外部へデータが出る経路が3つあることを、最初の説明では洗い出せていませんでした。法務からは「何件のうち何件が社外へ出るのか」と聞かれ、事業部門の担当者はその場で答えられず、検討がそこで止まっています。

経路を数えられない状態のまま説明を続けても、承認する側は判断材料を持てません。まず数えるところから始めましょう。

状況②自動実行させてよい範囲が決まっていない

2つ目は「自動実行させてよい範囲が決まっていない」です。AIエージェントは、回答を返すだけでなく、レコードを更新したりメールを送ったりする操作まで実行できます。この操作のどこまでを任せるのかが決まっていないと、審査する側は最悪の場合を想定して判断せざるをえません。

先ほどの人材サービスの企業では、当初の説明資料に「問い合わせの一次対応を自動化する」とだけ書かれていました。情報システム部門はこの一文から、登録者のレコードを書き換える操作まで含まれるのかどうかを読み取れず、含まれる前提で懸念を挙げています。事業部門としては回答を返すだけのつもりだったため、前提がそろわないまま2回の会議が終わりました。

つまり、範囲を書かなかったことで、審査する側が最も広い範囲を想定したのです。任せる操作を動詞の単位まで書き出すと、この行き違いは起きにくくなります。

状況③事故が起きたときに誰が説明するのか不明

3つ目は「事故が起きたときに誰が説明するのか不明」です。承認する側が最後に確認するのは、想定外の回答が登録者へ届いたときに、誰がどの記録を見て、何を説明するのかという段取りになります。

そもそも、なぜここが問われるのかという話ですが、人が一件ずつ書いたわけではないAIエージェントの回答は、あとから経緯をたどる手段が用意されていなければ、説明できる人が社内にいなくなるからです。

この企業でも、経営層から「取引先に説明を求められたら誰が答えるのか」と問われ、事業部門も情報システム部門も即答できませんでした。理由は、記録が残るかどうかという点にはありません。その記録を誰が定期的に見るのかが決まっていなかったからです。

説明できる人を先に決めておけば、記録の設計もそこから逆算できるようになります。

情シスと法務がAIエージェントに投げる3つの問い

前章では、AIエージェントの社内承認が止まる3つの状況を整理しました。ここで役に立つのが、審査する側が実際に投げてくる問いをあらかじめ並べておくことです。問いの形が分かっていれば、答えを用意してから会議に臨めます。情報システム部門と法務が確かめたいのは、AIエージェントの便利さより先に、データが通る経路と、その内容を見られる人の範囲です。そこでここでは、情報システム部門と法務がAIエージェントに投げる3つの問いを整理します。

AIエージェントの稟議には、立場の違う4者が関わります。BtoBの購買で意思決定に関与するグループは、DMU（Decision Making Unit：意思決定グループ）と呼ばれます。その6つの役割区分のうち、本記事に関与するのは次の4者です。

問い①顧客のデータはどの経路で社外へ出るのか

1つ目は「顧客のデータはどの経路で社外へ出るのか」です。この問いに答えるには、経路の本数と、それぞれで社外へ出る項目を書き出す必要があります。

Einstein Trust Layerでは、外部のLLMへプロンプトを送る前に、氏名やクレジットカード番号といった情報を検出して伏せ字に置き換えます。検出はパターンの照合と機械学習を組み合わせて行われるため、決まった書式を持たない氏名や企業名も対象になります。

※参考記事はこちら

この人材サービスの企業では、経路を3つに整理し、そのうち登録者の氏名が含まれるのは1つだけだと示しました。法務が確認したかったのは、経路をゼロにできるかどうかという点ではありません。どの経路に何が乗るのかが把握されているかどうかであり、この整理のあとは経路に関する指摘が出なくなりました。

経路の本数と、それぞれに乗る項目まで書き出せていれば、最初の問いには答えられます。

問い②渡したデータが学習に使われることはないのか

2つ目は「渡したデータが学習に使われることはないのか」です。法務がここで確かめているのは、送信したデータが提供元の側にどこまで残るのかという保存の範囲です。学習に使われた時点で、自社が削除を求めても取り戻せない状態になります。

Salesforceは外部のLLM提供元との間でゼロデータ保持の方針を維持しており、送信したデータが提供元の側に残らない形が取られています。ここで説明すべきなのは、方針が存在するという事実より先に、その方針が自社の使い方にも適用されるという点です。

先ほどの人材サービスの企業でも、法務から「契約書のどこに書いてあるのか」と質問が出ました。事業部門の担当者が公式ドキュメントの該当箇所を印刷して添付したところ、その場で確認が終わっています。口頭の説明では2週間かかっていた確認が、出典を添えるだけで1回の会議に収まりました。

一方で、社内規程の側に生成AIの取り扱いを定めた条項がなければ、この説明だけでは足りません。規程の改定が必要かどうかも、あわせて確認しておきましょう。

問い③想定外の動作をしたとき誰が気づけるのか

3つ目は「想定外の動作をしたとき誰が気づけるのか」です。IPAの「情報セキュリティ10大脅威 2026」では、組織向けの3位に「AIの利用をめぐるサイバーリスク」が初めて選出されました。審査する側がこの問いを投げるのは、社外でも同種の懸念が共有されているからです。

※参考記事はこちら

Einstein Trust Layerは、応答を採点した結果と、伏せ字にする前のやり取りを、時刻の情報とあわせて記録します。ただし、記録が残ることと、誰かが気づくことは別です。稼働の記録をどの頻度で誰が見るかは、記録の機能とは別に決めておく必要があります。

この企業では、月1回・約2時間のレビューを情報システム部門の2名で担当すると決めました。経営層が承認に踏み切ったのは、この担当者名が資料に入ったタイミングです。

記録の項目をどれだけ細かく設計しても、見る人が決まっていなければ、想定外の動作は誰にも気づかれません。

AIエージェントの稟議が下りない3つの原因

ここまで審査する側の問いを見てきましたが、そもそもなぜ、これらの問いに答えられない状態が生まれるのでしょうか。それは、社内の権限設計も点検の手順も、人が操作することを前提に作られてきたからです。そこでここでは、AIエージェントの稟議が下りない3つの原因を整理していきます。

原因①人の操作を前提に権限を設計してきたから

社内の権限設計は、これまで人が画面を操作することを前提に組み立てられてきました。従来のシステムでは、担当者に与えた権限の範囲が、そのまま操作できる範囲だったのです。

AIエージェントの場合は、動作するときの権限を専用のユーザーに持たせるため、誰の権限で動いているのかを別に定義しなければなりません。この定義がないと、情報システム部門は「管理者と同じ権限で動くのではないか」と想定します。

この人材サービスの企業では、当初エージェントが参照するオブジェクトが18種類ありました。営業支援で使っている項目をそのまま引き継いだためです。情報システム部門からの指摘を受けて6種類まで絞り込んだところ、権限の説明が1枚の資料に収まるようになりました。

参照するオブジェクトが10種類を超えたら、任せる業務を分けることを検討しましょう。1体のエージェントに複数の業務を持たせている兆候になります。

原因②外部のLLMへ渡る経路を把握できていないから

次に多いのは、外部のLLMへデータが渡る経路を、事業部門の側が把握できていない状態です。導入を進める担当者にとって、経路はAgentforceの内部で処理される部分であり、意識せずに設計を進められてしまいます。

先ほどの人材サービスの企業でも、経路の洗い出しに取りかかったのは、法務から質問が出た後でした。会議の場で答えられなかったため、次の会議まで3週間空いています。

逆にいえば、経路の一覧を最初の資料に入れておけば、この3週間は発生しませんでした。設計の初期に手間をかけるほど、審査の往復は減ります。

原因③点検表にAI特有の攻撃の項目がないから

最後の原因は、社内のセキュリティ点検表の側にあります。多くの企業の点検表は、外部からの不正アクセスや脆弱性を対象に作られており、指示文に細工をして目的を書き換える攻撃を確かめる項目がありません。

OWASPが2025年12月9日に公開した「OWASP Top 10 for Agentic Applications 2026」では、エージェントの目標を乗っ取る攻撃が最初の項目として挙げられています。点検表を更新する際は、この一覧を出発点にできます。

※参考記事はこちら

脅威の分類をどう自社の構成へ当てはめるかは、AIエージェントのセキュリティリスクの側で整理していますので、点検表を作り直す段階ではそちらもあわせて確認してもらえると進めやすくなります。

AIエージェントに一任してよい業務の3つの条件

前章では稟議が下りない原因を整理しましたが、原因が分かっても、任せる範囲が決まらなければ資料は書けません。ここから先は、境界を引くための判断基準に入ります。一任してよい業務かどうかの判定は、その結果を取り消せるかどうかで決まります。そこでここでは、AIエージェントに一任してよい業務の3つの条件を整理します。

条件①誤った結果を取り消せること

1つ目は「誤った結果を取り消せること」です。回答が間違っていた場合に、担当者があとから訂正できる業務であれば、一次対応をAIエージェントへ任せても被害は限定されます。

たとえば、この人材サービスの企業では、就業規則の説明や書類の提出先の案内を一任の対象にしました。誤った案内をしても、担当者が正しい内容を送り直せば済むためです。

一方で、応募の受付を締め切ったと誤って回答した場合は、登録者が別の求人へ移ってしまい、訂正しても元に戻りません。同じ「案内」でも、取り消せるかどうかで扱いが分かれます。

判定に迷ったら、誤った場合に何をすれば元に戻るかを1文で書いてみましょう。書けなければ、一任の対象から外す業務です。

条件②金銭と契約に影響しないこと

2つ目は「金銭と契約に影響しないこと」です。金額や契約条件に触れる回答は、そのまま合意の内容として受け取られる可能性があるため、一任の対象から外します。

なぜなら、提示した条件を後から訂正する場合、相手方との交渉が必要になり、担当者の作業だけでは完結しないからです。取り消しの可否という条件①とは、必要になる手続きの重さが違います。

この企業の場合、派遣料金の目安を聞かれる問い合わせが月におよそ80件ありました。これらは金額に触れるため、エージェントは料金表の所在だけを案内し、金額は担当者が回答する形に分けています。

金額に触れない案内までであれば、条件②を理由に一任の対象から外す必要はありません。

条件③顧客ごとの値を回答に含まないこと

3つ目は「顧客ごとの値を回答に含まないこと」です。全員に共通する制度の説明であれば、誤りがあっても影響は説明の内容にとどまりますが、特定の登録者の給与額や契約期間を回答に含めると、宛先を誤ったときに個人データの開示にあたります。

先ほどの人材サービスの企業では、この条件を加えたことで一任の対象が月1,200件のうち約4割まで絞り込まれました。当初は7割を想定していたため、事業部門にとっては期待を下回る数字です。それでも法務が承認に転じたのは、絞り込みの理由が条件の形で書かれていたからでした。

範囲が狭くなること自体は失敗ではありません。承認を得て動き始めるほうが、広い範囲のまま止まり続けるより早く成果につながります。

AIエージェントの実行前に承認を挟む3つの場面

ここまで一任してよい業務の条件を整理してきましたが、条件から外れた業務のすべてを人が担当するわけではありません。実行の直前に承認を挟めば、AIエージェントに準備までを任せられます。承認を挟むのは、AIエージェントの実行結果が社外へ出る直前です。そこでここでは、実行前に承認を挟む3つの場面を整理していきます。

場面①見積りの内容を顧客へ提示するとき

1つ目は「見積りの内容を顧客へ提示するとき」です。派遣料金や紹介手数料の見積りは、AIエージェントが過去の条件から案を作るところまでは任せられますが、提示は担当者の承認を経る必要があります。

この人材サービスの企業では、取引先から条件の照会が入ると、エージェントが過去の類似案件を検索して条件の案を作り、担当者へ通知する形にしました。担当者は案を確認して送信するだけになり、1件あたりの作業時間が短くなっています。

このように、作成と提示を分ければ、金額に触れる業務でもAIエージェントの担当範囲を作れます。

場面②顧客へメールを送信するとき

2つ目は「顧客へメールを送信するとき」です。社外へ届く文面は、いったん送信すると取り消せないため、承認の対象になります。

ただし、すべてのメールを承認の対象にすると、担当者の確認作業が増えて運用が続きません。この企業でも、承認を挟むかどうかで事業部門と情報システム部門の判断が分かれました。事業部門は受付の完了通知まで承認を挟むと処理が滞ると主張し、情報システム部門は社外へ出るものはすべて確認すべきだという立場でした。

最終的には、文面が定型で登録者ごとの値を含まない受付通知だけを条件付き自動とし、それ以外は事前承認としています。判断を分けたのは、条件③と同じく、文面に登録者ごとの値が入るかどうかという基準でした。

場面③レコードを更新して後続の業務が動くとき

3つ目は「レコードを更新して後続の業務が動くとき」です。レコードの更新は社内で完結しますが、更新をきっかけに自動処理が動く場合は、影響が社外へ広がります。

たとえば、この企業では登録者のステータスを「就業中」に変更すると、翌日に取引先へ稼働開始の連絡が自動で送られる設定がありました。エージェントがステータスを更新できるようにすると、誤った更新がそのまま社外への連絡につながります。

そこで、後続の自動処理が設定されている項目を一覧にし、その項目の更新だけを事後確認の対象に切り替えました。一覧に含まれない項目は、そのままエージェントへ任せています。

社内で完結する操作かどうかは、更新した項目の先で自動処理が動くかどうかで判断できます。

AIエージェントに任せない3つの業務

前章では承認を挟む場面を整理しましたが、承認を挟んでも扱いきれない業務があります。準備の段階からAIエージェントに関与させないほうがよい領域です。そこでここでは、AIエージェントに任せない3つの業務を整理します。

業務①安全に関わる不具合の判断

1つ目は「安全に関わる不具合の判断」です。就業先での事故やハラスメントの申告など、人の安全に関わる連絡は、内容の判定を人が行う必要があります。

なぜなら、緊急度の判定を誤った場合、対応の遅れが取り返しのつかない結果につながるからです。誤りを訂正する手段がないという点で、条件①の判定からも外れます。

この人材サービスの企業では、申告を受け付ける窓口をAIエージェントの対象から完全に外し、専用のフォームへ誘導する形にしました。エージェントが担うのは、該当しそうな問い合わせを検知して窓口の連絡先を案内するところまでです。

エージェントが判定にまで踏み込んでいないかは、回答文に緊急度や該当の可否を示す表現が入っていないかで点検します。

業務②法令の解釈を伴う個人データの取り扱い

2つ目は「法令の解釈を伴う個人データの取り扱い」です。登録者から自分のデータの開示や削除を求められた場合、応じる範囲は法令の解釈を含む判断になります。

この企業でも、削除の依頼にどこまで応じるかは、契約期間中の記録保存の義務との兼ね合いで個別に判断していました。過去の対応をそのまま当てはめられないため、エージェントが参照できる形の基準が社内に存在しません。

基準が文書になっていない段階では、エージェントの精度を上げても同じ判断は再現できません。

業務③社内に一次情報がない領域の回答

3つ目は「社内に一次情報がない領域の回答」です。エージェントは社内のナレッジを根拠に回答するため、根拠となる文書が社内にない領域では、確からしい文章を作ることしかできません。

先ほどの人材サービスの企業では、取引先の業界動向に関する質問がこれに該当しました。社内に該当する文書がなく、参照できるのは営業担当者が個別に集めた情報だけだったためです。

回答の精度を上げる方向で解決しようとせず、対象から外す判断も必要になります。参照するナレッジを整理する段階で、どの領域に一次情報があるのかを確認しておきましょう。

AIエージェントの一任と承認の境界を決める3つのステップ

ここまで一任・承認・除外の3区分を整理してきましたが、実際の業務をこの3つに振り分けるには順番があります。順番を誤ると、機能の設定から入ってしまい、業務の側の判断が後回しになりがちです。AIエージェントの導入では、ツールの設定ではなく業務設計から入ってほしい場合ほど、この順番が重要になります。境界は機能の設定より先に、業務の側の言葉で決めておく必要があります。そこでここでは、境界を決める3つのステップを整理していきます。

ステップ①取り消せる業務かどうかで仕分ける

まず取りかかるのは、問い合わせの種類を洗い出し、取り消せるかどうかで仕分ける作業です。この段階では機能の話をせず、業務の名前と件数だけを並べます。

この人材サービスの企業では、月1,200件の問い合わせを17種類に分類し、そこから一任・承認・除外へ振り分けました。作業に立ち会ったのは事業部門の担当者と法務の担当者で、情報システム部門は参加していません。設定の話が出ると議論が機能へ移ってしまうためです。

つまずきやすいのは、区分の基準が言葉になっていない状態で仕分けを始めてしまう場合です。条件①から③を先に紙に書き出してから始めると、判断のぶれが減ります。

ステップ②承認を挟む場面をフローに組み込む

仕分けが終わったら、次は承認を挟む場面を業務フローへ組み込みます。ここで決めるのは、誰が承認するのか、承認しないまま滞留した場合にどうするのかという2点です。

この企業では、承認者を決める段階で作業が1週間止まりました。見積りの承認は営業のマネージャー、社外メールの承認は担当者本人という案が出たものの、担当者本人の承認では確認の意味がないという指摘が情報システム部門から入ったためです。最終的に、社外メールは同じチームの別の担当者が確認する形に落ち着きました。

承認者が決まらないまま設定へ進むと、稼働後に誰も確認しない承認が残ります。

ステップ③稼働前に線引きどおり動くか確かめる

最後に、決めた線引きどおりにAIエージェントが動くかを、稼働前に確かめます。除外したはずの業務に回答してしまわないか、承認を挟むはずの操作が自動で実行されないかを、実際の問い合わせ文で試します。

この人材サービスの企業では、設計から検証までに6週間かかりました。検証の過程で、除外したはずの個人データの削除依頼に、エージェントが一般的な手続きを案内してしまう動作が見つかっています。指示文を修正して再度確認し、案内せずに担当者へ引き継ぐ動作に変えました。

検証の進め方は、テストセンターの側で扱っていますので、件数を確保して確かめる段階ではそちらを参照してください。以上が、AIエージェントの一任と承認の境界を決める3つのステップでした。

Einstein Trust Layerの4つの保護

前章までで、業務の側の境界を決める手順を整理してきました。ここでようやく、その境界を支える仕組みの話に入ります。Einstein Trust Layerには多くの構成要素がありますが、稟議の場で説明を求められるのは、そのうちの4つに集約されます。Einstein Trust Layerが守るのはデータが通る経路であり、AIエージェントに任せる範囲ではありません。そこでここでは、説明が必要になる4つの保護を整理します。

保護①送信前に個人情報を伏せるデータマスキング

1つ目は「送信前に個人情報を伏せるデータマスキング」です。外部のLLMへプロンプトを送る前に、氏名やクレジットカード番号などを検出し、伏せ字に置き換えたうえで送信します。

検出には、決まった書式を照合する方法と、機械学習による判別が組み合わせて使われます。氏名や企業名のように書式を持たない情報も対象になるのは、この組み合わせによるものです。応答が戻ってきた段階で伏せ字は元の値へ戻されるため、担当者が読む回答は通常どおりの内容になります。

法務へ説明する際は、何が伏せられるかよりも、伏せた状態で送られるという処理の順番を示すほうが伝わります。

保護②外部にデータを残さないゼロデータ保持

2つ目は「外部にデータを残さないゼロデータ保持」です。ゼロデータ保持は、Agentforceが送信したプロンプトと応答を、外部のLLM提供元の側に保存させない取り決めです。

この人材サービスの企業では、法務が最も時間をかけて確認したのがこの項目でした。求職者のデータが提供元の学習に使われないという点が、社内規程の個人データの取り扱い条項に直接関わるためです。

ただし、提供元に残らないことと、自社側に記録が残らないことは別です。監査証跡として記録された内容の保存期間と、閲覧できる担当者の範囲は、自社の側で決める必要があります。

保護③想定外の出力を防ぐプロンプトディフェンス

3つ目は「想定外の出力を防ぐプロンプトディフェンス」です。外部のLLMへ送るプロンプトに、守るべき条件をあらかじめ書き加えることで、指示に細工をして目的を書き換える攻撃に備えます。

※参考記事はこちら

ここで注意したいのは、細工を見つけ出して遮断する検査の仕組みではないという点です。あくまでLLMへ渡す指示の側に条件を足す仕組みであり、すべての細工を止められるわけではありません。

この違いを説明せずに「対策済み」とだけ伝えると、稟議の後半で認識の食い違いが表面化します。

保護④応答を5カテゴリで採点する有害性検出

4つ目は「応答を5カテゴリで採点する有害性検出」です。LLMから戻ってきた応答を、暴力・性的表現・不適切な言葉遣い・憎悪・身体的な内容の5つのカテゴリで採点し、0から1の範囲でスコアを付けます。1に近いほど有害と判定された内容になります。

※参考記事はこちら

採点の対象は表現であり、書かれている内容が事実として正しいかどうかは判定されません。回答の正確さは、参照するナレッジの設計で担保する領域です。

保護の対象となる機能の全体像はAgentforceの機能で確認できます。また、OWASPが挙げる脅威の分類と、これらの保護がどう対応するのかを整理したい場合は、セキュリティ対策設計の側で扱っています。

Agentforce Gatewayポリシーの3つの制御

前章では、データが通る経路を守る4つの保護を整理しました。一方で、AIエージェントが社外のシステムへ接続する場合は、経路の保護とは別に、接続を制御する必要があります。そこでここでは、Agentforce Gatewayポリシーの3つの制御を整理していきます。

制御①エージェント単位でポリシーを適用する

1つ目は「エージェント単位でポリシーを適用する」です。Agentforce Gatewayポリシーは個別に作成し、どのエージェントへ適用するかを選ぶ形で運用します。

※参考記事はこちら

エージェントごとに適用先を分けられるため、業務の性質に応じて接続できる範囲を変えられます。登録者の対応を担うエージェントと、社内の問い合わせを担うエージェントでは、必要な接続先が異なるためです。

複数の業務を1体のエージェントに持たせていると、この分け方ができません。エージェントを業務単位で分けておくことが、ポリシー設計の前提になります。

制御②どの接続先に保護を適用するかを決める

2つ目は「どの接続先に保護を適用するかを決める」です。ポリシーは接続に対して適用と解除ができるため、社外システムとの接続ごとに保護の要否を判断できます。

この人材サービスの企業では、稼働の時点で社外システムとの接続はありませんでした。それでも情報システム部門が確認したのは、今後外部システムとの接続を追加する際に、追加のたびに承認が必要になるかどうかという運用の設計です。

接続を追加するたびに稟議をやり直す形にすると、運用が続きません。最初の承認の段階で、追加時の手順まで決めておきましょう。

制御③ポリシーが重なるときの既定の適用順序

3つ目は「ポリシーが重なるときの既定の適用順序」です。複数のポリシーが同じ接続に適用される場合の実行順序は、Agentforce Gateway側で既定として定められています。

公式ドキュメントで確認できるのは、既定の順序が定められているという点までです。順序を利用者が変更できるかどうか、どのポリシーが先に評価されるのかについては、2026年8月時点では公開情報から確認できませんでした。

説明の場では、確認できていない点を確認できていないと伝えるほうが、後の食い違いを防げます。Einsteinとの違いを含めて仕組みの詳細を確かめたい場合は、そちらもあわせて参照してください。

Einstein Trust Layerの3つの限界

ここまで保護と制御の仕組みを整理してきましたが、これらを設定すれば事故が起きなくなるわけではありません。稟議で信頼を得るには、防げない範囲も同じ資料に書いておく必要があります。保護の仕組みは事故が起きる確率を下げるものであり、確率をゼロにする仕組みではありません。そこでここでは、Einstein Trust Layerの3つの限界を整理します。

限界①マスキングは検出できた項目にしか効かない

1つ目は「マスキングは検出できた項目にしか効かない」です。データマスキングは、パターンの照合と機械学習で個人情報を検出しますが、検出されなかった情報はそのまま送信されます。

この人材サービスの企業では、登録者の職務経歴に含まれる過去の勤務先名が、社名として検出されずに送られる可能性を情報システム部門が指摘しました。対策としたのは、検出の精度を上げることではありません。エージェントが参照するナレッジを1,800件から320件へ絞り、職務経歴を参照対象から外しました。

検出できない項目が1つでも残る前提に立つなら、参照させる範囲を絞るほうが確実な対策になります。

限界②有害性検出は精度100%を前提にできない

2つ目は「有害性検出は精度100%を前提にできない」です。応答は5つのカテゴリで採点されますが、スコアは確率的な判定であり、判定を誤る場合があります。

また、回答の内容が誤っていても、表現が穏当であればスコアは低く出ます。出力の揺れをどこまで抑えられるかはモデル選択と推論制御の側の設計課題です。

有害性検出が止められるのは表現の側までであり、回答の正確さを保証する仕組みではありません。

限界③監査証跡は残すだけでは検知につながらない

3つ目は「監査証跡は残すだけでは検知につながらない」です。プロンプト、伏せ字にする前の応答、有害性のスコア、収集したフィードバックが時刻の情報とともに記録されますが、記録されること自体は異常の検知を意味しません。

※参考記事はこちら

先ほどの人材サービスの企業でも、稼働後の最初の1か月は記録を誰も開いていませんでした。稼働直後は問い合わせへの対応が優先され、記録を見る作業が後回しになったためです。翌月からは、承認時に決めていた月1回のレビューを予定表へ登録し、担当者2名の時間を先に確保したことで、確認が続くようになりました。

レビューの予定が入っていない状態では、記録する項目を増やしても異常は見つかりません。

AIエージェントの境界が守られているかを測る3つの指標

前章では防げない範囲を整理しましたが、防げない範囲があるからこそ、決めた境界が守られているかを継続して確かめる必要があります。稟議の場でも、稼働後に何を見るのかを問われます。境界が守られているかどうかは、割合と件数の3つの数字で毎月確かめられます。そこでここでは、AIエージェントの境界が守られているかを測る3つの指標を整理していきます。

指標①人の承認を経た実行の割合

1つ目は「人の承認を経た実行の割合」です。承認を挟むと決めた操作のうち、実際に承認を経て実行された件数の割合を、月ごとに数えます。

この割合が100%を下回っていれば、承認の設定が漏れている操作があることになります。この人材サービスの企業では、稼働2か月目のレビューで割合が98%となり、確認したところ承認の設定が漏れていた操作が2件見つかりました。いずれも稼働直前に追加した操作で、承認の設定を入れ忘れたものです。

目標は100%に置き、1回でも下回った月は、原因を特定してから翌月の運用に入ります。

指標②顧客へ届く前に止まった応答の件数

2つ目は「顧客へ届く前に止まった応答の件数」です。有害性検出のスコアによって顧客へ届かなかった応答の件数を数えます。

この件数は少ないほどよいというものではありません。件数が急に増えた月は、参照しているナレッジに不適切な表現を含む文書が追加された可能性があり、逆にゼロが続く場合は検出の設定が有効になっていない可能性があります。どちらの方向でも、変化があった月に確認するという使い方をします。

指標③レビューで見つかった設定の不備の件数

3つ目は「レビューで見つかった設定の不備の件数」です。月1回のレビューで見つかった、設計と実際の設定のずれの件数を記録します。

この企業では、稼働から3か月のあいだに設定漏れが2件、社内規程と設定の食い違いが1件見つかりました。規程の食い違いは、法務が個人データの保存期間を改定したにもかかわらず、エージェントが参照するナレッジ側の記載が古いままだったものです。レビューの手順に、規程の改定履歴と設定を突き合わせる作業を加えたことで、以降は同種のずれが出ていません。

記録を見る作業は、レビューの担当者2名で毎月およそ2時間、年間ではおよそ24時間で収まっています。件数がゼロで続く場合は、レビューの観点が不足していないかを疑いましょう。

AIエージェントの境界設計を自社で進める3つの条件

ここまで指標の設計まで整理してきましたが、これらを自社だけで進められるかどうかは、社内の体制によって変わります。まずは自社で進められる側の条件から確認しましょう。そこでここでは、AIエージェントの境界設計を自社で進める3つの条件を整理します。

条件①権限セットを組み替えられる管理者がいること

1つ目は「権限セットを組み替えられる管理者がいること」です。境界の設計は、最終的にはエージェントが動作するユーザーの権限をどう絞るかという作業に落ちます。

この作業には、既存の権限セットの構成を理解し、業務への影響を判断しながら組み替えられる担当者が必要です。求められる知識の水準としては、Agentforceスペシャリスト資格の出題範囲がひとつの目安になります。

この人材サービスの企業では、IT部門4名のうち1名がSalesforceの管理を4年担当しており、権限の組み替えは自社で対応できました。

条件②データ取り扱い方針が文書になっていること

2つ目は「データ取り扱い方針が文書になっていること」です。どのデータを外部へ渡してよいかという判断は、案件ごとに考えるものではありません。既存の方針へ照らして決めます。

方針が文書になっていない場合、判断のたびに法務へ確認することになり、設計が進みません。IT部門の人数が少ない体制でどう進めるかについては、中小企業向けのAgentforce導入ガイドでも扱っていますので、体制の面で不安がある場合はあわせて確認してもらえると考え方が整理しやすくなります。

方針が1本もない場合は、外部へ渡してよいデータの範囲だけを先に1枚にまとめると、設計に着手できます。

条件③設計者以外がレビューする手順があること

3つ目は「設計者以外がレビューする手順があること」です。境界を設計した担当者が自分で点検すると、設計時に想定しなかった観点は点検でも抜けます。

この企業では、設計を担当した1名とは別に、IT部門の別の担当者がレビューを担当する形にしました。設計者が当然と考えていた前提を、別の担当者が質問として出せるためです。

社内でこの2人目を確保できない場合もあるでしょう。自社で構築するので設計レビュー・アドバイザリーだけ頼みたい場合は、設計を外部へ委ねたまま進めずに、点検の観点だけを補う形も取れます。

AIエージェントの境界設計を外部に頼む3つの状況

前章では自社で進める条件を整理しましたが、条件を満たしていない場合や、構成が複雑な場合は、外部の支援を検討する段階になります。そこでここでは、AIエージェントの境界設計を外部に頼む3つの状況を整理していきます。

状況①複数のエージェントが権限を受け渡す構成を組む

1つ目は「複数のエージェントが権限を受け渡す構成を組む」です。エージェントが別のエージェントを呼び出す構成では、どの権限で動作しているのかが呼び出しの経路によって変わります。

1体のエージェントであれば権限の一覧を作れば把握できますが、受け渡しが発生すると、組み合わせの数だけ確認すべき経路が増えます。設計の経験がない状態で組むと、想定していない経路が残る可能性があります。

構成が2体以上になる段階で、設計の妥当性を外部に確認してもらう判断を検討しましょう。

状況②個人データの取り扱い方針がまだ決まっていない

2つ目は「個人データの取り扱い方針がまだ決まっていない」です。方針が決まっていない状態では、条件②を満たしていないため、設計の前提が揃っていません。

この場合に有効なのは、方針が必要になる範囲を狭めることです。全社の方針が固まるのを待つ必要はありません。小さく始めたい場合、1ユースケースに絞って必要な方針だけを先に決めれば、全社の方針を待たずに動き始められます。費用の見通しを先に押さえたい場合は料金と、稟議で通す効果の測り方をあわせて確認してもらえると、稟議の資料が組み立てやすくなるでしょう。

範囲を狭めて始める判断は、外部の支援があるほうが決めやすい領域です。

状況③OWASPの10項目を自社構成に当てはめられない

3つ目は「OWASPの10項目を自社構成に当てはめられない」です。脅威の一覧は公開されていますが、自社の構成でどの項目が該当するのかを判定するには、構成の読み解きが必要になります。

該当する項目を数えるところまでを外部に依頼し、その結果をもとに社内で対策の優先順位を決める進め方であれば、依頼する範囲を限定できます。導入支援会社の選び方でも触れているとおり、依頼する範囲を先に決めておくほど、見積りの比較がしやすくなります。

当社では、ソリューション営業に特化したAgentforceの導入・定着支援を行っています。設定を終えた段階で支援を打ち切らず、決めた境界どおりに運用が続くところまでを支援の範囲に含めます。定着まで伴走してほしい場合は、Agentforce導入・定着支援で無料相談も受け付けていますので、あわせてご覧ください。

【一問一答】Einstein Trust Layerに関するよくある質問

ここまでEinstein Trust Layerを前提にした境界の設計を整理してきましたが、稟議の場では細かい確認事項も出てきます。最後に、実際によく聞かれる質問を整理します。

質問①Einstein Trust Layerを通したデータはSalesforceの外に出るのか

外部のLLMへ問い合わせる処理では、プロンプトがSalesforceの外へ送信されます。ただし、氏名やクレジットカード番号などは送信前に検出のうえ伏せ字へ置き換えられ、元の値へ戻るのは応答がSalesforce側に返ってからです。

質問②Einstein Trust Layerは社内データの学習利用を防げるのか

送信したプロンプトと応答は、Salesforceと外部のLLM提供元との間で結ばれたゼロデータ保持の取り決めによって、提供元の側には保存されません。法務へ説明する際は、この方針が記載された公式ドキュメントの該当箇所を添えると、確認が1回で終わります。

質問③Einstein Trust Layerに追加のライセンス費用はかかるのか

2026年8月時点で公開されている価格情報では、Einstein Trust Layerが単体の課金項目として案内されているのを確認できませんでした。Agentforceの課金は利用量や会話の単位で設計されているため、費用の見積りはAgentforce料金・ライセンスの考え方に沿って組み立ててください。

質問④Agentforce Gatewayポリシーでは何を制御できるのか

公式ドキュメントで確認できるのは、ポリシーを作成してエージェント単位で適用できること、接続への保護を適用・解除できること、複数のポリシーが重なるときの実行順序が既定で定められていることの3点です。順序を利用者が変更できるかどうかは、公開情報からは確認できませんでした。

質問⑤AIエージェントのセキュリティ設計はIT担当なしで進められるか

権限セットの組み替えが必要になるため、Salesforceの管理を担当できる人が社内に1名は必要です。ただし、境界を決める作業は業務側の判断であり、設計の妥当性を確認する部分だけを外部に頼む形であれば、少人数の体制でも進められます。

AIエージェントのガバナンスはEinstein Trust Layerの設定より先に一任と承認の境界を決めることから始まる

Einstein Trust Layerは、Agentforceが外部のLLMとやり取りするデータを各工程で保護する仕組みです。ただし、この仕組みが守るのはデータが通る経路であり、AIエージェントにどこまで任せるかという判断までは代わりに決めてくれません。稟議が止まる企業の多くは、機能の説明を厚くする方向で資料を作り直していますが、審査する側が確かめたいのは任せる範囲のほうです。

例に挙げた人材サービスの企業も、参照するオブジェクトを18種類から6種類へ絞り、一任の対象を月1,200件のうち約4割まで限定したことで、承認を得て動き始めることができました。当初に想定していた7割には届いていません。それでも、絞り込んだ理由を条件の形で説明できたことが、法務と経営層の判断を変えています。

自社の業務をどの区分に振り分けるかは、業務の内容を知っている人にしか決められません。境界の引き方から一緒に検討したい場合は、Agentforce導入・定着支援で無料相談も受け付けていますので、お気軽にご相談ください。本記事で整理した3つの区分を、まずは自社の問い合わせに当てはめてみてはいかがでしょうか。少しでもお役に立てれば幸いです。