Agentforce エージェントは Salesforce の共有設定を回避する？

Agentforce に関するセキュリティの議論は、いつも同じ問いから始まります。エージェントは私たちの共有ルールを回避するのか？ という問いです。手短に答えると いいえ であり、その理由を理解することで、Agentforce がなぜ設計上安全なのか、そして本当のリスクがどこにあるのかの両方が見えてきます。

エージェントはユーザーとして実行され、そのユーザーのアクセスを継承する

Agentforce エージェントは、データに対する独自の魔法のような視界を持っているわけではありません。Salesforce ユーザーとして実行され、エージェントが行うすべてのデータ取得は、そのユーザーの次の要素に照らして検証されます。

オブジェクト権限（プロファイル + 権限セット）
項目レベルセキュリティ
レコードレベルの共有 — OWD、ロール階層、共有ルール、手動共有および暗黙的な共有

実行ユーザーがレコードを見られなければ、エージェントも見られません。Agentforce は、組織の他の部分を統制しているのと同じエンタープライズセキュリティモデル（プロファイル、権限セット、共有、ロールベースのアクセス）の内側で動作します。さらに、「EU の営業エージェントだけがこのワークフローをトリガーできる」といったルールのために、その上に属性ベースのポリシーを重ねることもできます。

Agentforce エージェントは Salesforce の権限を回避しません。すでに存在しているアクセスを、片っ端から積極的に使います。

この 2 番目の文に、すべてが詰まっています。

本当のリスク：回避ではなく、増幅された露出

ここからが気まずい部分です。ほとんどの組織は、誰かが設定した記憶がある以上にはるかにオープンな共有を抱えています。長年積み重なった共有ルール、広範な権限セット、ロール階層によるロールアップ、そして決して削除されなかった「一時的な」手動共有です。

人間が、自分が技術的にアクセスできる範囲の全容に行き当たることは、まずありません。自分が扱うレコードを開き、それ以外は無視します。しかしエージェントは違います。 質問を投げかければ、エージェントは実行ユーザーの手の届く範囲にあるすべて（そのユーザーが見られることを忘れていたデータも含めて）を取得し、結合し、要約します。

つまりエージェントは新たなアクセスを付与するのではありません。すでにあったアクセスを、会話形式で、瞬時に表に出すのです。何年も潜在していた過度に広い共有が、一文のプロンプトで届く距離になります。

エージェントがリスクの計算を変える理由

同じ権限を持つ人間とこれが異なる点は 2 つあります。

速度とスケール。 エージェントはどんな人間よりもはるかに速くレコードを読み取り、組み合わせます。そのため、スコープを誤った権限は即座に、しかも繰り返し悪用されます。
承認チェックポイントの不在。 いったん導入されると、エージェントは人間のレビューのために立ち止まることなく、構成とコンテキストに基づいて動作します。従来のセキュリティモデルが暗黙のうちに頼っていたチェックポイントが取り除かれるのです。

権限モデルが弱くなったわけではありません。それを使う側が、はるかに徹底的になったのです。

導入前にすべきこと

対処法は Agentforce を信用しないことではありません。有効化する前に、そのユーザーが何を見られるのかを把握することです。

アクセスレビューを実施する — エージェントの実行ユーザーについて、オブジェクトレベルとレコードレベルの両方で。問うべきことは、このブログ全体のテーマと同じです。誰が何を、なぜ見られるのかです。手順を追ったプレイブックは、AI エージェント導入前のレコードアクセス監査を参照してください。
ベースラインを引き締める。 OWD はビジネスが許す限り厳格に設定します。アクセスはそこからしか広がりません。
共有ルールと権限セットを整理する。 エージェントがそのまま継承してしまう、広範で古くなった付与を取り除きます。
エージェントに専用の最小権限 ID を与える — 広範な人間用プロファイルではなく、専用 ID と属性ベースのポリシーを用意します。
共有設定を変更するたびに再確認する — アクセスは時間とともにずれていき、エージェントが届く範囲も同様に変化します。

エージェントが何を見られるかを、平易な言葉で把握する

ステップ 1 と 5 が難所です。CRUD、項目レベルセキュリティ、そして 6 つの共有メカニズムにまたがるユーザーの真の実効アクセスを再構築し、組織の変化に合わせて最新の状態に保ち続ける必要があります。

それこそが AgentForceAccess の役割です。あるユーザー（あるいはエージェントの実行ユーザー）が実際に何を見られるのかを平易な言葉で尋ねれば、すべての付与をたどり、その背後にあるメカニズムを根拠として示します。これは、導入前に「エージェントのスコープは正しいはずだ」を「正しいと分かっている」へと変える、まさにそのアクセスレビューです。

よくある質問

Agentforce エージェントは共有ルールを無視して管理者として実行されるのですか？

いいえ。エージェントは特定の Salesforce ユーザーとして実行され、そのユーザーのプロファイル、権限セット、項目レベルセキュリティ、レコード共有モデルに拘束されます。そのユーザーが見られないレコードは、エージェントも見られません。ただし実行ユーザーが過剰な権限を持っていれば、エージェントはその過剰権限を継承します。

権限を尊重するのに、なぜ AI のアクセスがセキュリティリスクと見なされるのですか？

ほとんどの組織が、誰もが認識している以上にオープンな共有を積み重ねてきているからです。人間が技術的にアクセスできるすべてのレコードに偶然たどり着くことはまずありませんが、エージェントは求めに応じて喜んでそれらを取得・要約します。エージェントは新たなアクセスを生み出すのではなく、すでに存在していたアクセスを露出させるのです。

エージェントを導入する前に行うべき最も重要なことは何ですか？

エージェントの実行ユーザーが実際に何を見られるのかを、オブジェクト単位でもレコードレベルでも監査することです。組織の共有設定（OWD）、共有ルール、権限セットを引き締め、そのユーザー（ひいてはエージェント）が必要なアクセスのみを持つようにしてから導入してください。

エージェントを実行するユーザーよりも狭いアクセス権をエージェントに与えられますか？

はい。広範な人間用プロファイルを使い回すのではなく、エージェント専用の最小権限ユーザーまたは権限セット構成を用意し、その上に属性ベースのポリシーを重ねてください。エージェントはそのタスクに必要な最小限のアクセスのみを持つべきです。