Agentforceの権限セットとは？AIエージェントに渡す範囲の決め方

Agentforceは有効にすれば現場がすぐ使えるようになるといわれますが、管理者の画面で問題なく動いていたエージェントが、営業へ公開したとたん「機能が出てこない」と言われる場面は少なくありません。権限セットとは、Salesforceで利用者に機能やデータへのアクセスを渡すためのまとまりで、Agentforceを使うにもこの割り当てが要ります。 なお、Agentforceの機能名と提供状況は更新が続くため、本記事は2026年9月時点の情報にもとづいています。

そこで本記事では、AIエージェントに渡す範囲を決める基準から、権限で起きる症状、実行時にどの立場で動かすかの観点、公開前の確認までを解説します。

なお、AIへ一任してよい行為と人が承認する場面の線引きはEinstein Trust Layerの記事、有効化と最初の1体を作る手順はAgentforceの使い方の記事で扱っています。本記事では、誰にどの権限を割り当て、実行時にどの立場で動かすかの設計に絞って解説します。

この記事を書いた人

本田正憲

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

Agentforceの権限セットでAIエージェントに渡す範囲を決める3つの基準

業務用洗剤を製造するメーカーでは、従業員230名のうち営業が19名、情報システム部が3名という体制で、Sales Cloudを5年運用してきました。この企業は説明のための架空の設定であり、実在の企業ではありません。この会社は2か月前にAIエージェントを有効にし、情報システム部の担当者が自分のアカウントで動作を確かめてから営業19名へ一斉に公開しています。当初の目的は「営業からの社内問い合わせを減らすこと」でした。そこでここでは、この会社を例に、Agentforceの権限セットでAIエージェントに渡す範囲を決める3つの基準を整理します。

渡す範囲は機能の一覧から決める作業にはなりません。AIエージェントに渡す範囲は、その担当者が業務で見てよい情報と、実行してよい操作に合わせて決めます。

基準①担当者が業務で見てよい情報の範囲

1つ目は「担当者が業務で見てよい情報の範囲」です。AIエージェントは、依頼を受けたときにSalesforceのレコードやナレッジを参照して回答を組み立てます。参照できる範囲は、実行する利用者に渡された権限で決まります。

なぜこの基準が先に来るかというと、エージェントに渡す範囲を担当者の業務より広げると、その担当者が普段は見られない情報が回答として届くからです。画面では開けないレコードの内容が、会話の形で読めてしまう状態になります。

先ほどの業務用洗剤のメーカーでは、営業19名のうち5名が特定の量販店を担当しています。この5名は他の担当者の商談を画面では開けない設定でした。ところが公開の直後、担当外の取引先について聞いた質問に、別の担当者の商談の内容が含まれた回答が返っています。情報システム部が確認したところ、公開時に渡した権限が画面の設定より広い範囲を含んでいました。

権限を渡す前に、その担当者が画面で開けるレコードの範囲を確かめましょう。画面で開けないものは、回答にも出てはいけません。

基準②実行後に取り消せる操作の範囲

2つ目に挙げるのは、実行後に取り消せる操作の範囲です。エージェントに配線された操作のうち、レコードを検索する、内容を要約するといったものは、実行しても記録が変わりません。レコードを更新する、メールを送るといった操作は、取り消しに人の作業が要ります。

この違いを権限の設計に持ち込むと、渡してよい範囲の線が引きやすくなります。取り消せる操作は広く渡しても影響が小さく、絞り込む対象は取り消せない操作だけに寄せられます。

この会社では、営業向けのエージェントに商談レコードの更新を配線する案が出ていました。情報システム部の担当者は、更新の操作を渡す対象を営業課長2名に限定し、営業19名には検索と要約だけを渡す設計にしています。更新が必要な場面では、営業が課長へ依頼する運用に変えました。

取り消せない操作から先に、渡す相手を役職や担当範囲で絞り込みましょう。この線引きができた時点で、取り消せる操作を誰まで広げるかも決まります。

基準③記録を残す必要がある操作の範囲

3つ目は「記録を残す必要がある操作の範囲」です。監査や社内の規程で、誰がいつ何をしたかを説明する必要がある操作があります。金額に関わる更新、契約に関わる情報の参照、外部への送信が代表的なものにあたります。

記録が要る操作を渡すときは、その記録が実際に残る設計かどうかを先に確かめます。エージェント経由で実行された操作が、担当者が画面で実行した場合と同じように記録されるかは、実行の仕組みによって変わるためです。

先ほどのメーカーでは、価格に関わる情報の参照について、四半期ごとに監査の対象になる決まりがありました。情報システム部の担当者は、価格の参照を含む権限を渡す前に、参照の記録が残る形かどうかを確認しています。確認が終わるまでの1か月、この権限は誰にも渡していません。

記録が要る操作を洗い出したら、記録が残ることを確かめてから渡しましょう。あとから残す設定へ変えても、それまでの実行は記録されません。

AIエージェントの権限で起きる3つの症状

ここまで挙げた3つの基準を踏まえずに公開すると、現場からの申告は「使えない」「答えが違う」という形で届きます。原因が権限にあると分かるまでに時間がかかるのは、症状が権限の問題として見えないためです。実際にこの業務用洗剤のメーカーでも、最初の2週間は指示文の不備を疑っていました。そこでここでは、AIエージェントの権限で起きる3つの症状を整理します。

症状は機能の不具合として報告されます。公開した直後の申告が「使えない」「人によって答えが違う」に集中しているなら、疑うべきは権限の割り当てです。

症状①利用者に割り当てが完了していない

1つ目は「利用者に割り当てが完了していない」という症状です。管理者のアカウントでは、権限を明示的に渡していなくてもエージェントが表示される場合があります。そのため、検証を終えた時点では問題が見えません。

見えない理由は、管理者が持つ権限の広さにあります。検証している本人には、割り当ての工程が残っていること自体が分かりません。公開して初めて、対象の担当者の画面に何も出ないという形で表面化します。

この会社では、営業19名へ公開した初日に11名から「画面に出てこない」という連絡が入りました。情報システム部の担当者が確認したところ、権限セットの割り当てが完了していたのは8名だけです。残りの11名は、割り当ての操作を途中まで進めた状態で保存されていませんでした。

公開の前に、対象の担当者のうち1名を選んで実際にログインを確かめましょう。選ぶのは割り当てをまとめて処理した後半の担当者で、保存の抜けは操作を続けた終わりのほうに残ります。

※参考記事はこちら

症状②担当者ごとに回答の中身が変わる

2つ目に挙げるのは、担当者ごとに回答の中身が変わる症状です。同じ質問をしても、聞いた人によって返ってくる内容が違います。片方には具体的な数値が返り、もう片方には「情報が見つかりません」と返るような差になります。

この差が生まれるのは、エージェントが依頼した担当者の権限で参照するためです。参照できる範囲が違えば、回答の材料も変わります。仕組みとしては正しい動作ですが、利用者からは不具合に見えます。

先ほどのメーカーでは、公開の翌月に「同じ質問なのに人によって答えが違う」という申告が23件ありました。内訳を見ると、量販店の担当5名と、それ以外の担当14名のあいだで回答が分かれています。情報システム部の担当者は、この差が権限の設計どおりであることを説明する資料を作り、営業へ配りました。

差が出ること自体は設計の結果です。利用者へ先に伝えておけば、申告として上がってきません。

症状③想定していない情報まで回答に出る

3つ目は「想定していない情報まで回答に出る」という症状です。基準①で触れた、画面では開けないレコードの内容が回答に含まれる状態がこれにあたります。

この症状が最も見つけにくいのは、エラーにならないためです。聞いた担当者にとっては、欲しい情報が返ってきただけの体験になります。問題として認識されるのは、その情報を社外へ伝えたあとか、別の担当者が偶然気づいたときに限られます。

この会社で見つかったのは3件で、そのうち1件は他部署が管理する商談の金額でした。営業が「この取引先の過去の取引額を教えて」と聞いた回答に、担当外の商談が含まれています。営業側からの申告はなく、情報システム部の担当者が抜き取りで回答を確認していて気づきました。

回答が正しく返ることは、範囲が正しいことを意味しません。公開の後も、しばらくは回答の中身を人が確かめる必要があります。

AIエージェントが使う権限の4つの種類

ここまで挙げた3つの症状の原因が権限にあると分かっても、どこを直せばよいかは権限の種類が整理できていなければ決まりません。Agentforceで使う権限は1種類にとどまりません。役割の違う複数のものが重なっています。そこでここでは、AIエージェントが使う権限の4つの種類を整理します。

種類を分けて考えないと、直す場所が特定できません。AIエージェントの権限は、製品を有効にするもの、設定を作るもの、実行時に使うもの、対話するものの4つに分かれます。

種類①製品を有効にするためのライセンス

1つ目は「製品を有効にするためのライセンス」です。組織でAgentforceを使えるようにするために必要な、契約に紐づくものにあたります。これがなければ、そもそも設定の画面が現れません。

ライセンスは組織に対して付与され、そのうえで利用者へ割り当てる形になります。契約した数を超えて割り当てることはできないため、誰に渡すかを決める作業が発生します。

なお、権限セットや権限セットライセンスの正式な名称と構成は、組織のエディションと提供状況にあわせて変わります。名称を覚えるより役割で押さえておくほうが早く、実際の名称はSalesforceの設定画面にある権限セットの一覧で確認してください。公式の学習教材でも、管理者が権限セットを作成し、そこへ対象のエージェントを追加してから利用者へ割り当てる流れで説明されています。※参考記事はこちら日本語のヘルプは機械翻訳のため、画面の表示を基準にするのが確実です。

この業務用洗剤のメーカーでは、契約した数が営業19名と情報システム部3名の合計に対して足りていました。ただし、将来的にカスタマーサポートの4名へも広げる計画があり、その時点で追加の契約が必要になると情報システム部の担当者は見込んでいます。

費用の考え方と課金の型は、Agentforceの料金の記事で整理しています。契約の数が足りるかどうかは、割り当てを設計する前に確かめてください。

種類②設定を作る担当者に渡す権限

2つ目に挙げるのは、エージェントを設定する担当者に渡す権限です。エージェントを作る、指示文を書く、操作を配線するといった作業を行うための範囲になります。

この権限は、利用する担当者に渡す権限とは別のものです。設定を作れることと、作ったエージェントを使えることは、別の割り当てで決まります。混同すると、作った本人が使えない、あるいは利用者が設定を触れてしまう状態が生まれます。

先ほどの会社では、情報システム部の3名のうち2名に設定の権限を渡しています。3人目は運用の確認だけを担当するため、設定を変更できる範囲は渡していません。この分け方は、誰が設定を変えたかを追えるようにするためでもあります。

設定を作れる人は、必要な人数に絞りましょう。人数が増えるほど、変更の経緯が追いにくくなります。

種類③エージェントが実行時に使う権限

3つ目は「エージェントが実行時に使う権限」です。エージェントが操作を実行するとき、どの立場の権限で動くかを決めるものにあたります。依頼した担当者の権限で動く場合と、あらかじめ決めた実行者の権限で動く場合があります。

この違いは、回答に出る情報の範囲を直接決めます。症状②で挙げた「担当者ごとに回答の中身が変わる」は、依頼した担当者の権限で動く設計から生まれるものです。

この会社の営業向けエージェントは、依頼した担当者の権限で動く設計にしていました。量販店の担当5名とそれ以外で回答が分かれたのは、この設計の結果です。情報システム部の担当者は、設計を変えずに、差が出る理由を営業へ説明する判断をしています。

実行時にどの立場で動くかは、次の章で観点ごとに整理します。ここでは、種類として別に存在することを押さえてください。

種類④利用者が対話するために要る権限

4つ目は「利用者が対話するために要る権限」です。エージェントの画面を開き、依頼を入力し、回答を受け取るための範囲になります。症状①の「割り当てが完了していない」は、この種類が渡っていない状態です。

対話するための権限は、参照できるデータの範囲とは別に管理されます。データを見られる担当者でも、この割り当てがなければエージェントの画面が現れません。逆に、この割り当てがあっても、データの範囲が狭ければ回答は返りません。

先ほどのメーカーで11名の画面にエージェントが出なかったのは、この種類の割り当てが保存されていなかったためです。情報システム部の担当者は、割り当てが完了した人数を一覧で数える手順を、公開の工程に追加しています。

4つの種類のうち、どれが欠けているかで症状が変わります。申告を受けたら、まず種類を切り分けてください。

AIエージェントの実行時の権限を決める3つの観点

前章で挙げた4つの種類のうち、設計の判断が最も分かれるのが3つ目の実行時の権限です。どの立場で動かすかによって、同じエージェントでも返る内容が変わってしまいます。AIへ任せてよい行為の線引きはEinstein Trust Layerの記事で扱っているため、ここで取り上げるのはその行為を実行するときの権限の主体です。そこでここでは、AIエージェントの実行時の権限を決める3つの観点を整理します。

どちらが正しいという話ではありません。実行時の権限は、回答の内容を担当者ごとに変えるべき業務かどうかで選びます。

観点①依頼した担当者の見える範囲に合わせる

1つ目は「依頼した担当者の見える範囲に合わせる」という観点です。エージェントが依頼した本人の権限で参照するため、画面で開ける情報だけが回答に使われます。営業のように担当先が分かれている業務では、この設計が自然になります。

利点は、権限の設計を二重に持たなくてよいことです。画面の設定を直せば、エージェントの回答の範囲も同時に変わります。管理する対象が1つで済みます。

この業務用洗剤のメーカーは、営業向けのエージェントをこの設計にしています。量販店の担当5名が聞いた場合と、それ以外の14名が聞いた場合で回答が分かれるのは想定どおりでした。情報システム部の担当者は、この差を不具合として直す方法は採らず、営業へ説明する資料を作る対応を選んでいます。

担当先で情報が分かれている業務なら、この観点を最初に検討しましょう。管理の手間が最も小さくなります。

Trailheadの学習教材でも、社内向けのエージェントは依頼した担当者としてログインし、その担当者の権限や組織のセキュリティ設定に従って範囲が決まると説明されています。

※参考記事はこちら

観点②固定の実行者の範囲に合わせる

2つ目に挙げるのは、あらかじめ決めた実行者の権限に合わせる観点です。誰が依頼しても同じ範囲を参照するため、回答の内容が利用者によって変わりません。社内規程や製品仕様のように、全員が同じ答えを得るべき業務に向きます。

この設計では、実行者に渡す権限が回答の範囲を決めます。実行者の権限を広く取ると、依頼した本人が本来見られない情報まで回答に出るため、範囲を絞る作業が別に必要になります。

先ほどの会社では、社内の申請手続きを案内するエージェントを検討していました。総務の規程は全員が同じ内容を見てよいため、固定の実行者で動かす案が出ています。情報システム部の担当者は、この実行者に渡す権限を規程のナレッジだけに限定する設計案をまとめました。

業務ごとに、答えが1つに定まるべきか、担当先で変わってよいかを先に仕分けましょう。仕分けの単位はエージェントごとで、1体のなかで両方を満たす設計は取れません。

固定の実行者に合わせる設計は、Salesforceの学習教材でも、エージェントが専用のSalesforceユーザーとして動くという形で説明されています。そのユーザーへ渡す権限が回答の範囲を決めるという考え方と対応しています。

※参考記事はこちら

観点③外部の利用者に開く範囲を絞る

3つ目は「外部の利用者に開く範囲を絞る」という観点です。顧客や取引先がエージェントと直接やり取りする場合、社内の利用者とは前提が変わります。社内向けに設計した範囲をそのまま開くと、社内限りの情報が社外へ届きます。

外部へ開く場合は、参照できるデータを社外向けの文書に限定するところから設計します。社内の担当者が読むことを想定した注意事項や、他社の事例を含む記録は、参照の対象から外す必要があります。

この会社では、将来的に取引先向けの問い合わせ窓口をエージェントに任せる構想がありました。情報システム部の担当者は、社内向けと同じエージェントを流用する案を採らず、別のエージェントとして作る前提で検討を進めています。

外部向けの設計は、社内向けを開く形では作れません。詳しくはAgentforce Service Agentの記事で整理しています。

AIエージェントへ権限を渡す前に整える4つの設定

ここまで整理した実行時の観点が決まっても、参照の元になるデータ側の設定が整っていなければ、渡した権限は意図した範囲になりません。権限セットは既存の共有ルールの上に重なる形で効くため、下にあるものを先に確かめる必要があります。そこでここでは、AIエージェントへ権限を渡す前に整える4つの設定を整理します。

権限セットだけを見て範囲は決まりません。渡す権限の範囲は、既存の共有ルールと項目レベルの設定を確かめてから決めます。

設定①対象のデータの共有ルールを確認する

最初に確認するのは、対象のオブジェクトの共有ルールです。誰がどのレコードを見られるかは、組織全体の既定値と共有ルールの組み合わせで決まっています。この設定はAgentforceを入れる前から存在しており、エージェントの回答もここに従います。

確認する理由は、共有ルールが想定と違っている場合があるためです。運用のなかで例外的に広げた設定が残っていると、エージェント経由でその広さが表に出ます。CRMの外にあるデータまで参照させる場合は、Data 360の側にも同じ確認が要ります。

先ほどの業務用洗剤のメーカーで、担当外の商談が回答に含まれた原因はここにありました。3年前に営業会議の資料を作るために設定した共有ルールが、対象を絞らないまま残っています。情報システム部の担当者は、エージェントの権限を直す前に、この共有ルールを見直しました。

エージェントの範囲を疑う前に、共有ルールの一覧を開きましょう。画面での見え方と一致していない設定が見つかります。

設定②項目単位の参照可否をそろえる

共有ルールを確かめたら、次に見るのは項目ごとの参照の可否です。レコード全体は開けても、特定の項目だけ見られない設定が残っていることがあります。原価や仕入先のように、部署によって見せる範囲を変えている項目が該当します。

項目の設定がそろっていないと、回答に含まれる内容が予測しにくくなります。同じレコードを参照しても、読める項目が違えば要約の中身が変わるためです。

この会社では、商談の原価に関する項目を営業課長2名だけが参照できる設定にしていました。営業19名が同じ商談について聞いたとき、課長2名の回答にだけ原価が含まれます。情報システム部の担当者は、この差が意図したものであることを確認したうえで、設定を維持しています。

項目の設定は、レコードの設定とは別に確かめる必要があります。両方を見ないと、範囲は決まりません。

設定③参照させたい文書の公開範囲を決める

3つ目は「参照させたい文書の公開範囲を決める」という設定です。エージェントに社内の文書を参照させる場合、その文書がどの利用者に開かれているかが回答の範囲を決めます。

文書側の設計は、レコードの権限とは別の考え方になります。誰が読んでよい文書かを整理してから、参照の対象に含めるかどうかを判断します。

先ほどの会社は、製品の仕様書と社内の運用手順書を参照の対象にしていました。運用手順書には協力会社との取り決めが含まれており、営業へ開いてよいかの判断が保留になっています。情報システム部の担当者は、判断がつくまでこの文書を対象から外しました。

参照させる文書の選び方と分け方は、Agentforce RAGの記事でも整理しています。文書側の範囲は、権限セットでは制御しきれません。

設定④外部の利用者向けの範囲を分ける

4つ目は「外部の利用者向けの範囲を分ける」設定です。社外の利用者がエージェントに触れる可能性がある場合、社内向けとは別の範囲をあらかじめ用意します。

分けておく理由は、あとから分ける作業が難しいためです。1つの設計を社内外で共有していると、片方だけを絞る変更が他方に影響します。

この業務用洗剤のメーカーは、取引先向けの窓口を将来的に検討しているため、社内向けの設計を作る段階で外部向けの範囲を別に定義しています。いまは使っていない設定ですが、必要になった時点で作り始めるより手戻りが小さいと判断したためです。

外部へ開く予定があるなら、社内向けを作る段階で別に用意しましょう。予定がないなら、この設定は不要です。

AIエージェントの権限で事故を防ぐ3つの確認

ここまで整えた4つの設定を反映しても、公開の前に確かめる工程を飛ばすと、症状③で挙げた想定外の情報が出る状態は見つかりません。管理者の画面で確かめるだけでは、担当者に何が見えるかが分からないためです。確かめる対象は、割り当てが済んでいる件数と、返ってくる回答の中身の両方になります。そこでここでは、AIエージェントの権限で事故を防ぐ3つの確認を整理します。

確認は管理者のアカウントでは成立しません。公開前の確認は、実際に使う担当者と同じ権限の状態で行います。

確認①割り当ての一覧を人ごとに見る

最初の確認は、権限セットの割り当てが対象の人数ぶん完了しているかを、一覧で見る作業です。割り当ての操作は1名ずつ行うため、途中で保存されていないものが残ります。

一覧で見る理由は、操作した本人の記憶では抜けが分からないためです。19名に割り当てたつもりでも、実際に完了しているのが8名という状態は起こります。

この会社が公開の初日に11名から連絡を受けたのは、この確認をしていなかったためです。情報システム部の担当者は、その後の公開では割り当ての完了人数を一覧で数え、対象の名簿と突き合わせる手順を追加しました。2回目以降の公開で、この症状は出ていません。

割り当てが終わったら、完了した人数を数えて名簿と照合しましょう。照合に使う名簿を人事の在籍一覧から作れば、公開の対象から外れていた担当者も同時に見つかります。

確認②同じ依頼を権限の違う2名で試す

2つ目に挙げるのは、同じ依頼を権限の違う2名で試す確認です。管理者と一般の担当者、担当先が違う2名というように、範囲の異なる利用者で同じ質問を投げて回答を比べます。

比べる目的は、差が設計どおりかを確かめることです。差が出ないほうが問題になる場合もあり、担当先で分かれるはずの回答が全員同じなら、権限が広すぎる可能性があります。

先ほどのメーカーは、公開の前に営業6名へ限定して2週間動かしました。この6名には量販店の担当2名とそれ以外の4名を含めており、同じ質問での回答の差を情報システム部の担当者が確かめています。小さく始めたい場合は、この対象を絞ったスモールスタートが、範囲の設計を確かめる進め方になります。

比べる2名は、範囲が最も違う組み合わせを選びましょう。差が出るはずの場所で差が出るかを見ます。確かめた記録を残す仕組みは、テストセンターの記事で整理しています。

確認③公開前に外部向けの範囲を確かめる

3つ目は「公開前に外部向けの範囲を確かめる」確認です。社外の利用者が触れる経路がある場合、その経路で何が返るかを実際に試します。

社内の利用者で確かめても、この確認は代替できません。外部の利用者には別の権限が適用されるため、参照できる範囲が変わります。

この会社は取引先向けの窓口をまだ公開していないため、この確認は実施していません。ただし、公開する段階では社内の確認とは別に工程を置く前提で計画しています。社内向けの公開で起きた3件の事例を踏まえ、外部向けはより慎重に進める判断を情報システム部の担当者は示しました。

外部へ開く経路があるなら、社内の確認とは別の工程として置きましょう。AIエージェント全体のリスクと対策の設計は、Agentforceのセキュリティで整理しています。

AIエージェントの権限を運用する4つの手順

ここまで挙げた3つの確認を終えて公開すれば、あとは日々の運用に移ります。とはいえ、権限は一度決めれば固定されるものにはなりません。担当者の異動、業務の追加、新しいエージェントの公開のたびに、割り当ての状態は変わります。そこでここでは、AIエージェントの権限を運用する4つの手順を整理します。

運用は申請が来たときに対応する形では続きません。権限の運用は、渡す窓口を1つに決め、追加した理由を記録することから始めます。

手順①権限を渡す申請の窓口を1つにする

最初に決めるのは、権限を渡してほしいという依頼の受け口です。複数の担当者がそれぞれ対応していると、誰が何を渡したかの全体が分からなくなります。

窓口を1つにする理由は、記録を1か所に集めるためです。渡した権限の一覧が分散していると、四半期ごとの見直しで漏れが出ます。

先ほどの業務用洗剤のメーカーでは、情報システム部の3名がそれぞれ営業から直接依頼を受けていました。誰がどの権限を渡したかを後から追えず、公開の2か月後に一度整理する作業が発生しています。現在は1名を窓口に決め、依頼を受けた記録を残す運用に変えました。

窓口を決めたら、その窓口を通さない依頼は受けないと社内へ伝えましょう。例外を作ると、記録が抜けます。

手順②追加した権限の理由を記録する

窓口が決まったら、次は渡した権限の理由を残します。誰に、どの権限を、いつ、何のために渡したかを1行で記録します。

理由が要るのは、見直しのときに判断できるようにするためです。理由が残っていなければ、外してよい権限かどうかを本人に聞き直すことになります。外部のシステムをまたぐ操作を配線している場合は、Agentforce MCPの記事で扱っている境界の設計もあわせて記録してください。

この会社の記録には、権限を渡した日付と依頼者と業務上の理由を書く欄があります。公開の2か月後に整理したとき、理由が書かれていない割り当てが7件ありました。情報システム部の担当者は、この7件について依頼者へ確認し、3件を外しています。

記録の欄は、あとから埋められません。渡すその場で書く運用にしてください。

手順③担当者が替わるたびに割り当てを見直す

3つ目は「担当者が替わるたびに割り当てを見直す」手順です。異動や退職のたびに、その人へ渡していた権限を外し、後任へ渡す作業が発生します。

見直しの起点になるのは、人事の情報です。情報システム部が異動を知る経路がなければ、権限は前任のまま残ります。

先ほどのメーカーでは、月初に人事から異動の一覧を受け取る運用にしました。担当替えのあった営業について、割り当てを確認して更新します。運用を始めてからの2か月で、対象になったのは4名でした。いずれも担当する取引先が替わったケースにあたり、前任の範囲を外す作業と後任へ渡す作業を同じ日にまとめています。

異動の情報がどこから来るかを、先に決めましょう。経路がなければ、この手順は動きません。

手順④四半期ごとに不要な権限を外す

最後の手順は、四半期ごとに割り当ての一覧を見直し、不要になった権限を外す作業です。業務が変わっても、渡した権限は自動では減りません。

外す判断の材料は、手順②で残した理由です。理由に書かれた業務が続いているかを確かめ、終わっていれば外します。続いているかどうかが判断できないものは、依頼者へ確認する対象として一覧に分けておきましょう。

この会社は、公開から2か月の時点で1回目の見直しを行い、19名分の割り当てをすべて確認しました。理由が不明だった7件のうち3件を外し、残る4件は業務が続いていることを確認して維持しています。所要は情報システム部の2名で3時間ほどでした。

以上が、AIエージェントの権限を運用する4つの手順でした。

AIエージェントの権限設計でつまずく3つの落とし穴

ここまで示した運用の手順を飛ばして進めた場合、起きる失敗には決まった形があります。この業務用洗剤のメーカーが公開の初日に11名から連絡を受けたのも、そのうちの1つに当たったためです。そこでここでは、AIエージェントの権限設計でつまずく3つの落とし穴を整理します。

失敗の多くは、検証する立場を間違えたことから生まれます。管理者のアカウントで検証を終えた時点では、権限の設計が正しいかどうかは何も分かっていません。

落とし穴①管理者の権限のまま検証を終える

1つ目は「管理者の権限のまま検証を終える」という落とし穴です。設定を作った担当者がそのまま動作を確かめると、すべての情報が見える状態で結果を判断することになります。

管理者の画面では、割り当てが済んでいなくてもエージェントが表示される場合があります。参照できる範囲も広いため、担当者に返る回答とは中身が違い、検証が通ったという判断は公開後に覆ってしまいます。

この会社では、情報システム部の担当者が自分のアカウントで2週間かけて確かめてから公開しました。結果として、初日に11名から「画面に出てこない」という連絡が入り、さらに担当外の商談が回答に含まれる事例が3件見つかっています。検証にかけた2週間は、権限の観点では何も確かめていなかったことになります。

検証は、実際に使う担当者と同じ権限のアカウントで行いましょう。管理者で確かめた結果は、公開の判断材料になりません。

落とし穴②足りない権限を都度追加していく

2つ目に挙げるのは、足りない権限を都度追加していく落とし穴です。「これが見られない」という申告を受けるたびに権限を足すと、その場は解決します。

この対処が問題になるのは、足した権限が積み上がるためです。半年後には、誰がどの範囲を持っているかを説明できない状態になります。監査で根拠を求められたときに、割り当ての理由を答えられません。

先ほどのメーカーで理由の分からない割り当てが7件見つかったのは、この積み上がりです。公開から2か月のあいだに、情報システム部の3名がそれぞれ申告に対応していました。整理に要した時間より、その場しのぎの対応にかけた時間の合計のほうが長かったと担当者は振り返っています。

申告を受けたら、足す前に理由を記録しましょう。記録が残っていれば、あとで外せます。

落とし穴③外部向けの範囲を後回しにする

3つ目は「外部向けの範囲を後回しにする」という落とし穴です。社内向けに公開する段階では、社外の利用者は関係ありません。そのため、外部向けの設計は必要になってから考えるという判断になります。

後回しにした結果として起きるのは、社内向けに作った設計をそのまま開く進め方です。参照の対象も指示文も社内の担当者を前提にしているため、社外へ出せない情報を1件ずつ外す作業が発生し、作り直したほうが早い場面も出てきます。

この会社は取引先向けの窓口を検討していますが、社内向けの設計を開く案は採っていません。情報システム部の担当者は、社内向けを作る段階で外部向けの範囲を別に定義しており、必要になった時点で使える形にしています。

外部へ開く予定があるかどうかを、設計の最初に確かめましょう。予定があるなら、その時点で別の範囲を用意します。

AIエージェントの権限が適切かを測る3つの指標

ここまで示した3つの落とし穴を避けて運用が始まったあと、次に必要になるのは権限の状態の説明です。権限の設計が適切かどうかは、担当者の感覚では説明できません。経営層や監査の担当者へ示すには、四半期ごとに数えられる形にしておく必要があります。そこでここでは、AIエージェントの権限が適切かを測る3つの指標を整理します。

利用回数を見ても、権限の状態は分かりません。権限の設計は、権限が理由で失敗した依頼の件数で測ります。

指標①権限が理由で失敗した依頼の件数

1つ目は「権限が理由で失敗した依頼の件数」です。参照できる範囲が足りずに回答を返せなかった依頼を数えます。件数が多ければ、渡した範囲が業務に足りていません。

測り方は、実行の記録から権限に関わる失敗を抽出するだけです。件数の推移を見れば、割り当ての見直しが効いたかどうかが分かります。

当初の目的は「営業からの社内問い合わせを減らすこと」でしたが、この業務用洗剤のメーカーでは公開の直後、権限が理由で失敗した依頼が週34件ありました。割り当てを見直した2か月後には週2件まで減っています。残る2件は、実際に見せる必要のない情報を求めた依頼でした。

まず現状の件数を出しましょう。0件を目指す指標にはなりません。範囲の外を求めた依頼は、失敗して正しい状態です。

指標②割り当てを見直した人数の割合

2つ目に挙げるのは、割り当てを見直した人数の割合です。対象の利用者のうち、直近の期間に割り当てを確認した人数がどれだけかを見ます。

この指標が役に立つのは、見直しの運用が動いているかを示すためです。件数の指標だけを見ていると、申告が来ない範囲は放置され、誰も使っていない権限が渡されたまま残ります。

この会社は、公開から2か月の時点で営業19名すべての割り当てを確認しました。整備の前は確認した人数が0名で、渡したあとに誰も見返していない状態です。四半期ごとの見直しを続けることで、この割合を100%に保つ運用にしています。

対象の人数と確認した人数を、四半期ごとに並べましょう。割合が下がっていれば、見直しの手順が止まっています。

指標③想定外の情報が出た報告の件数

3つ目は「想定外の情報が出た報告の件数」です。回答に含まれるべきでない情報が出たという報告を数えます。件数が0件でも安心はできず、報告が上がる仕組みがあるかどうかを合わせて見る必要があります。

この指標を続けて見る理由は、症状③で挙げたとおり、利用者からは申告として上がりにくいためです。抜き取りで回答を確認する運用とあわせて数えます。

先ほどのメーカーでは、公開の直後に3件が見つかりました。うち1件は他部署が管理する商談の金額で、営業からの申告ではありません。情報システム部の抜き取りで発見したものです。共有ルールを見直した2か月後は0件です。

稼働後の精度と定着を継続して測る仕組みは、Agentforce Observabilityの記事で整理しています。ここで挙げた3つの指標とあわせて設計してもらえると嬉しいです。

AIエージェントの権限設計に外部支援を使う4つの判断軸

ここまで挙げた3つの指標まで決まれば、社内で運用を続ける形は整います。とはいえ、情報システム部が3名という体制で、共有ルールの見直しから四半期の棚卸しまでを続けられるかは別の問題です。では、外部の支援を検討するとき、何を見て選べばよいのでしょうか。それは、支援会社によって契約に入る工程が違うからです。どの工程まで任せられるのかを、着手する前に確かめておく必要があります。そこでここでは、AIエージェントの権限設計に外部支援を使うときの4つの判断軸を整理します。

支援会社の実績数だけでは、自社に合うかどうかは判断できません。権限の設計を任せる相手は、既存の共有ルールを一緒に見るところから入れるかどうかで選びます。

判断軸①既存の共有設定から見てもらえるか

1つ目は「既存の共有設定から見てもらえるか」という判断軸です。権限セットの割り当てだけを請け負う支援と、その下にある共有ルールから確かめる支援では、結果が変わります。

見分け方は、提案の段階で何を確認すると書かれているかです。権限セットの設計だけが工程に入っている場合、既存の共有ルールに残った例外は見つかりません。

この業務用洗剤のメーカーで担当外の商談が回答に出た原因は、3年前に作られた共有ルールでした。権限セットだけを見ていれば、この設定には届きません。運用のなかで積み上がった例外は、Agentforceを入れる前から存在しています。

ツール設定ではなく業務設計から入ってほしい場合は、既存の共有ルールの確認が提案に含まれているかが判断材料になります。

判断軸②公開後の見直しに付き合えるか

2つ目に挙げるのは、公開後の見直しに付き合えるかどうかです。権限の設計は公開した時点では終わりません。異動や業務の追加のたびに、割り当ての状態は変わります。

構築までを請け負う契約と、四半期の棚卸しまで含む契約では、費用の考え方も期間も違います。契約の範囲がどこで切れるのかを、着手前に確認しておく必要があります。

この会社が公開の2か月後に行った整理では、理由の分からない割り当てが7件見つかりました。この作業を誰が担うのかを決めていなければ、情報システム部の3名へそのまま戻ります。棚卸しの対象が19名でこの分量なら、対象が増えたときに社内だけで担い続けるのは難しいでしょう。

定着まで伴走してほしい場合は、四半期ごとの棚卸しが契約の範囲に入っているかが判断材料になります。

判断軸③営業の見える範囲を理解しているか

3つ目は「営業の見える範囲を理解しているか」という判断軸です。どこまで見せてよいかの判断には、その会社の営業がどう分担しているかの理解が要ります。

支援する側が営業の業務を知らなければ、共有ルールの例外が意図的なものか放置されたものかを判別できません。担当先で分けている会社と、全員が全件を見る会社では、正しい設計が違います。

先ほどのメーカーでは、量販店の担当5名とそれ以外で範囲を分ける判断に、営業課長2名が同席しました。情報システム部の3名だけでは、どこまでを分けるべきかが決まらなかったためです。

社内の判断を必要とする工程がどこかを、着手前に洗い出しておきましょう。外部に任せられる範囲は、そこで決まります。

ソリューション営業に特化した支援がほしい場合は、商談の進め方に沿って見える範囲を決められるかを確認してください。

判断軸④設計の確認だけを頼めるか

4つ目は「設計の確認だけを頼めるか」という判断軸です。割り当ての案を自社で作れるなら、外部に必要なのは案の確認だけという場合があります。

構築まで一括で請け負う形しか用意していない支援会社では、この頼み方ができません。工程を切り出して依頼できるかどうかは、着手前に確認しておく項目にあたります。

この会社も、権限セットの作成と割り当ては情報システム部の3名で進められる見通しでした。判断に迷ったのは、実行時の権限を依頼者に合わせるか固定の実行者に合わせるかという1点だけです。

自社で構築するので設計レビュー・アドバイザリーだけ頼みたい場合は、工程を切り出した依頼を受けているかを確認しましょう。支援会社の選び方の全体像は、Agentforce導入支援会社で7つの見極め方として整理しています。

【一問一答】Agentforceの権限セットに関するよくある質問

ここまで、渡す範囲を決める基準から外部支援の判断軸までを整理してきました。実際に設定を進める段階では、割り当ての対象や実行時の扱いといった細かい点で判断に迷う場面が出てきます。とくに多いのは、誰に割り当てるのか、割り当てたのに動かないときにどこを見るのか、外部の利用者にはどう渡すのかという3つです。いずれも設定の画面を眺めているだけでは答えが出ず、共有ルールや業務の分担まで戻って考える必要があります。そこで最後に、権限セットについてよく寄せられる質問を5つ取り上げます。

質問①権限セットはどの利用者に割り当てますか？

エージェントを使う担当者と、エージェントを設定する担当者の両方に割り当てが要ります。この2つは別の権限で、片方だけでは目的を果たせません。この記事で例に挙げた業務用洗剤のメーカーでは、営業19名と情報システム部3名を分けて数え、設定の権限は情報システム部の3名のうち2名に渡しています。名称と構成はエディションと提供状況によって変わるため、実際の名称は設定画面にある権限セットの一覧で確認してください。

質問②権限セットを割り当てても動かないのはなぜですか？

割り当てが保存されていない場合と、参照するデータ側の設定が足りていない場合があります。このメーカーでは、公開の初日に11名から「画面にエージェントが出ない」と連絡が入り、原因は割り当ての保存漏れでした。最初の2週間は指示文の不備を疑っていたため、切り分けに時間がかかっています。前者は割り当ての一覧を人数で数えれば分かり、後者は共有ルールと項目単位の設定を確認してください。

質問③エージェントが実行時に使う権限は誰のものですか？

設計によって変わります。依頼した担当者の権限で動かす場合と、あらかじめ決めた実行者の権限で動かす場合の2通りです。担当先で見える範囲が分かれる業務では前者、全員が同じ答えを得るべき業務では後者が向きます。このメーカーでは営業19名のうち5名が特定の量販店を担当しており、公開の翌月に「同じ質問なのに人によって答えが違う」という申告が23件ありました。どちらで動かすかを決めていなかったことが原因です。

質問④外部の利用者へ権限を渡すことはできますか？

社外の利用者向けの経路を用意する形になります。社内向けに作った設計をそのまま開く進め方は勧めません。参照の対象も指示文も社内の担当者を前提にしているためです。このメーカーで担当外の商談が回答に出た原因も、3年前に作られた共有ルールでした。社内向けでも前提が古くなるため、外部へ開く予定があるなら、社内向けを作る段階で別の範囲を定義しておいてください。

質問⑤権限セットの見直しはどの頻度で行いますか？

四半期ごとの棚卸しと、担当者が替わったときの都度の見直しを組み合わせます。四半期の棚卸しでは、渡した理由に書かれた業務が続いているかを確認します。このメーカーでは理由の分からない割り当てが7件見つかっており、棚卸しをしなければ積み上がり続けます。都度の見直しは、人事から異動の情報を受け取る経路を先に決めておかなければ動きません。

Agentforceの権限セットの設計は、担当者が業務で見てよい範囲に合わせて決まる

権限セットで最初に決めるのは、機能をどこまで開くかではありません。ここまで見てきたとおり、その担当者が業務で見てよい情報と、実行してよい操作の範囲です。本記事では、渡す範囲を決める3つの基準から、権限で起きる症状、権限の4つの種類、実行時の3つの観点、渡す前に整える設定、事故を防ぐ確認、運用の4つの手順、つまずく落とし穴、測る3つの指標、外部支援の判断軸までを、一連の流れとして整理してきました。

例に挙げた業務用洗剤のメーカーは、管理者のアカウントで検証を終えて公開した状態から、担当者と同じ権限で確かめる進め方へ変え、権限が理由で失敗した依頼を週34件から週2件へ、回答の中身が人によって違うという申告を月23件から月1件へ変えています。見直しにかけた期間は3週間で、情報システム部2名の工数は計28時間でした。追加のライセンス費用は発生していません。設定を見直すだけで変わる範囲が、まだ残っている企業も多いのではないでしょうか。

合同会社クロスコムでは、ソリューション営業の業務プロセスに特化したAgentforceの導入・定着支援を行っています。1ユースケース×3ヶ月のスモールスタートプランから対応しており、無料相談も受け付けていますので、Agentforce導入・定着支援までお気軽にご相談ください。本記事で紹介した内容を、ぜひ自社の権限の設計に合わせて活用し、少しでもお役に立てれば幸いです。