はじめに
Agentforceのエージェントアクションを実装していると、動作確認は管理者権限で行うことが多いと思います。
ただ本番投入後に一般ユーザーから「情報が取得できない」という問い合わせが来て、慌てて原因を追うことになったケースがありました。
実はこれ、Agentforce特有の不具合ではなく、Salesforceのオブジェクト権限・組織の共有設定・共有ルールという、レコードアクセス制御の基本に原因があることがほとんどです。
本記事では、実装者目線で権限まわりの切り分け手順と、Flowアクションを組み合わせる際に見落としやすいポイントを整理します。
Agentforceが「動く人によって結果が変わる」しくみ
まず押さえておきたいのが、社内向けのAgentforce(Employee Agent)は、ログインしているユーザー本人の権限で動く、という点です。
要するに、Agentforceは魔法使いではなく、ログイン中の本人の代わりに社内データベースを検索してきてくれる「すごく物分かりのいい代理人」のようなものです。代理人である以上、本人が見られない情報は、代理人にも見せてもらえません。
Salesforce公式ヘルプでも、社内従業員向けのAgentforceエージェント(Employee Agent)は「ログインしているユーザーの実行コンテキストで動作し、そのユーザーのプロファイル・権限セット・共有ルール/ロールによってエージェントの動作とレスポンスが決まる」と説明されています。管理者は通常かなり強い権限を持っているので何でも取得できますが、一般ユーザーは自分が本来アクセスできる範囲のレコードしか見られません。ここがズレの正体です。
なお、エージェントのアクションがFlowを呼び出している場合は、Flow自体の実行コンテキスト(ユーザーコンテキストかシステムコンテキストか)も重なって影響します。この点は後ほど「つまずきポイント」で触れます。
つまり、管理者では動いて一般ユーザーだと止まるのは、たいていバグではなく「そのユーザーが本来アクセスできないデータを読みに行っている」が正解、という理解でOKです!
権限・共有設定を切り分ける実践ステップ
原因の見当がついたところで、実際に何を順番に確認すればいいかを見ていきます。Salesforce公式のレコードアクセストラブルシューティング手順を、Agentforceの文脈に合わせて並べ直しました。
- オブジェクト権限を確認する:設定の「ユーザー」から対象ユーザーを開き、「概要の表示」をクリックします。「オブジェクト権限」タブで、Agentforceが読みに行くオブジェクト(取引先、ケースなど)に参照権限があるか確認しましょう。ここが不足していれば、権限セットで必要な権限を追加します。権限が正しければ、次は「レコードアクセス」の問題です。(※ここにスクリーンショット追加予定)
- 組織の共有設定(OWD)を確認する:設定のクイック検索で「共有設定」を開き、対象オブジェクトの「デフォルトの内部アクセス」を見ます。ここが「非公開」や「公開/参照のみ」になっていると、レコード所有者とその上位ロールのユーザーしか参照できません。(※ここにスクリーンショット追加予定)
- 該当レコードの共有階層を見る:実際にAgentforceが取得しようとしたレコードの詳細画面を開き、アクションメニューから共有状況を確認します。誰が・どの仕組みでそのレコードにアクセスできているかが一覧できるので、一般ユーザーがそこに含まれていなければ、そこが原因です。(※ここにスクリーンショット追加予定)
- ロール階層と所有者の関係を確認する:そのユーザーが、レコード所有者と同じロールか、階層上でより上位のロールにいるかを確認します。
- 公開グループの所属を確認する:共有ルールの多くは公開グループ単位で設定されているので、対象ユーザーが想定しているグループに入っているか確認します。
- 共有ルールを確認・追加する:組織の共有設定の例外を、特定の公開グループやロールに対して自動的に作る仕組みです。既存のルールの対象条件がズレていないか、あるいは新しくルールを追加する必要がないかを確認します。
- それでも解決しない場合:キュー、取引先・商談・ケースの営業チーム、Territory(商圏)、Apexによるプログラム共有、制限ルールなど、他の仕組みが絡んでいる可能性があります。手順6までで解決しなければ、このあたりも疑ってみてください。
正直、共有階層の画面を初めて開いたときは情報量の多さに「うわ、これは大変そう…」と身構えたのですが、実際に触ってみると「このユーザーはこの公開グループ経由でアクセスしている」とちゃんと教えてくれるので、慣れると原因特定の一番の近道になります。
つまり、①オブジェクト権限→②組織の共有設定→③ロール階層・共有ルール→④その他の仕組み、の順に上から機械的に潰していけばOKという理解で大丈夫です!
ここは注意!つまずきポイント
実務でハマりやすいポイントを、3つ紹介します。
1つ目は、エージェントアクションがFlowを呼び出している場合です。Flow自体にも「ユーザーコンテキスト」と「システムコンテキスト」という実行方法の区別があり、システムコンテキストで動くFlowを使っていると、Agentforce側のユーザー権限チェックを素通りして全データにアクセスできてしまうことがあります。実務で使うなら、Flowの実行コンテキストはとくに見落としやすいので注意しておいた方が良さそうです。意図せず情報が広く見えすぎていないか、Flow側の実行コンテキストもあわせて確認してください。
2つ目は、社外向けのAgentforce(Service Agent)と混同しないことです。Service Agentは基本的に専用の「エージェントユーザー」の権限で動くため、本記事で扱った「ログインユーザー本人の権限で動く」という前提がそのまま当てはまりません。今回の切り分け手順は、あくまで社内向けのEmployee Agentを想定しています。
3つ目は、費用面です。Agentforce Employee Agentは、Enterprise・Performance・Unlimited・Developerエディションでアドオンとして提供される機能として案内されており、基本ライセンスに標準で含まれていない可能性があります。この記事では2026年9月時点で確認できた情報をもとにしていますので、実際の契約内容・最新の料金体系は必ず公式情報でご確認くださいね!
なお、社内向けAgentforce(Employee Agent)の日本語UI上の正式な表示名は、今回の調査時点では公式ドキュメントで確認できませんでした。英語表記のまま案内していますので、実際の画面では表記が異なる可能性がある点はご了承ください。
まとめ
今回の内容を振り返ります。
- Agentforce(Employee Agent)は、管理者ではなくログイン中の本人の権限で動く
- 管理者だけ動いて一般ユーザーで止まる場合、多くはバグではなく権限・共有設定の問題
- 切り分けは「①オブジェクト権限→②組織の共有設定→③ロール階層・共有ルール→④その他の仕組み」の順が近道
- Flowを呼ぶアクションはFlow側の実行コンテキストもあわせてチェックする
権限まわりは奥が深いテーマですが、切り分ける順番さえ知っていれば、意外と怖くありません。一緒に少しずつ慣れていきましょう!