Agentforceの7つの業務別エージェントから考える、権限設計

Salesforceは2026年9月11日、営業、顧客対応、社内サービスなど、業務別に設計された7種類のAIエージェントを紹介しました。

Casey、Paige、Carter、Marshall、Piper、Fin、Hunterという名称が与えられています。

私たちがこの発表で注目したのは、機能の多さそのものよりも、業務別に設計されたエージェントを導入するとき、企業側が何を決める必要があるかという点です。

本稿では、7種類のエージェントの構成と、導入企業が検討することになる権限設計の論点を中心に扱います。

AI Skillsやマルチエージェント連携など、プラットフォーム全体の機能は対象にしていません。

発表の中身：業務別に設計された7種類のエージェント

Salesforceが紹介した7種類は、得意とする業務領域や、主な利用チャネルが示されています。

• Casey（カスタマーサービス）：音声・SMS・WhatsApp・ウェブチャットを横断し、よくある質問や返品、アカウント管理に対応
• Paige（IT・HR対応）：Slackや社内ポータル経由の従業員からのリクエストに対応
• Carter（ショッピング支援）：商品の比較・発見からチャット内での購入手続きまでを担当
• Marshall（サプライチェーン）：一連のバックオフィス業務をつなぎ、手作業を自動化して監査証跡を残す
• Piper（インバウンドリード対応）：ウェブサイトやメールで接点を持った見込み客に対応し、商談につながる可能性を見極め、次の接点へつなぐ
• Fin（カスタマーエクスペリエンス）：複雑な顧客対応ワークフローを、チャネルを横断して解決
• Hunter（アウトバウンド営業）：見込み客の調査・優先順位づけから連絡、商談の進行支援、提案書の準備まで、営業担当者と協働して継続的に取り組む

このうちCasey、Paige、Carter、Marshall、Piper、Finは一般提供中で、Hunterはパイロット中、2026年11月に一般提供が予定されています（いずれも2026年9月11日時点のSalesforceの発表による）。

Salesforceは、各エージェントを自社の業務に合わせて調整でき、独自の名前を付けることもできると説明しています。

今回の発表では、各業務に対応したエージェントから導入を始め、企業ごとの仕事に合わせて調整していく構成が示されています。

長期タスクを支える仕組みと導入事例

Salesforceの説明によれば、数週間単位で続くタスクは、3つの仕組みで支えられているとされています。

セッションをまたいで文脈と進捗を保持する「メモリ」、計画を時間をかけて実行し続ける「持続的な実行」、利用者個々のフィードバックに応じて挙動を調整する「動的な方向づけ」です。

この長期実行の基盤（long-horizon runtime）を最初に採用するエージェントはHunterだと説明されており、7種類すべてが同じ基盤で動くという説明ではありません。

Finについては、顧客対応業務の運用・改善を支援する「Operator」と、顧客体験向けに訓練された専用モデル群「Fin Apex」を組み合わせたものだとされています。

Salesforceが紹介する導入事例としては、Anthropicにおいて、Finが見た会話のうち79%が自律的に解決されているという数値、小売企業Hibbettにおいて、主要な購買プロセス（core shopper journeys）の90%をHibbett AIが担っているという数値が挙げられています。

これらはSalesforceが自社の顧客事例として紹介している数値であり、私たちが独自に検証した実測値ではありません。

また、こうした数値は導入の効果を示すものであって、権限設計の妥当性を裏づけるものではありません。

導入企業の業務内容や運用体制によって、同じ機能でも結果は変わり得る点には留意が必要です。

Salesforceが説明する制御の仕組み

権限設計を論じる前に、製品側にどのような制御の仕組みがあるかを確認しておきます。

Salesforceは今回の発表で、各エージェントは顧客企業の業務ルール・権限・セキュリティの範囲内で動作すると説明しています。

あわせて、エージェントの挙動を記述するオープンソースの言語「Agent Script」を使うことで、AIの推論と、あらかじめ定めた決定論的なルールを組み合わせ、判断や操作を細かく制御できるとしています。

さらにSalesforceの公式ヘルプは、Agentforceのセキュリティを「共有責任モデル」として整理しています。

そこでは、基盤とAIの信頼層を提供するのはSalesforce側の責任、最小権限の原則に沿ったプロファイル・権限セット・項目レベルセキュリティの設定、扱うトピックや実行できるアクションを制限するガードレールの構築、そして継続的な監視・監査は顧客側の責任、と説明されています。

つまり、導入企業の課題は、統制の仕組みをすべて一から作ることではありません。

用意された機能や既存の権限設定が、自社で任せたい業務に合っているかを確認し、必要な条件を具体化することです。

担当業務と、実際に与える権限を対応させる

ここから先は私たちの見方になります。

MIFがこの発表から考えるのは、エージェントの数そのものよりも、任せる業務と、参照できる情報・実行できる操作を対応させる必要があるということです。

一つのエージェントに複数の業務を任せる場合でも、操作ごとの権限や承認条件は分けて考える必要があります。

一方、業務別にエージェントを分けることは、それぞれに必要な権限を限定するための整理にも使えます。

つまり、業務別に分けること自体が、負担増でも安全性の保証でもありません。

どのように分け、どのように接続するかが論点です。

ここで注意したいのは、担当業務の名称から、そのエージェントが実際に参照できる情報の範囲まで決まるわけではないという点です。

例えば、人事に関する問い合わせにエージェントを使う場合でも、就業規則などの共通情報を案内するのか、本人に限定した個別情報の照会まで任せるのかで、必要なアクセス範囲は変わります。

顧客対応でも、注文状況の照会は情報を参照する操作ですが、返金や交換の実行は取引そのものを変更する操作であり、後から取り消しにくくなります。

実際のアクセス範囲は、担当領域の名前ではなく、実行するユーザーの権限や、許可されたアクションの設定によって決まります。

共通のルールは再利用し、業務固有の条件と、複数のエージェントやシステムで分担する場合の引き継ぎを確認する。

設計すべきなのは、名前の数ではなく、実際の業務の流れです。

これは、AI導入をソフトウェアの機能選定だけで終わらせず、業務と権限の設計まで確認する、という私たちがこれまでの記事でも取り上げてきた考え方の延長線上にあります。

AI導入では、モデルの性能だけでなく、業務上の役割、権限、承認、運用まで具体化する必要があるとMIFは考えています。

導入前に整理しておきたい4つの項目

業務別のエージェントを社内に入れる場合、私たちは次の4項目を、対象業務ごとに整理することを勧めています。

以下は正しい設定値を示すものではなく、自社の業務に置き換えて考えるための叩き台・あくまで一例です。

適用される法令・契約・社内規程を前提に、業務の影響とリスクに応じて具体化してください。

検討項目	具体的に決めること
データへのアクセス範囲	誰の権限で、どの情報を参照・更新できるか。利用者や対象データによって制限を変える必要があるか
実行できる操作と承認条件	どの操作を自律実行でき、どの条件で事前承認が必要か。その条件をどの仕組みで適用するか
引き継ぎ・停止の条件と担当者	どの状況で人へ引き継ぐか。誰が対応し、必要なときに停止・再開を判断するか
記録と確認方法	依頼、参照情報、承認、実行操作、結果をどう追跡するか。誰が確認し、記録の閲覧範囲や保管期間をどう決めるか

この表は、特定の製品の設定項目を書き写したものではなく、業務を整理するための枠組みとして用意しています。

まずは導入対象の業務を絞って整理し、共通化できるルールと、その業務に固有の条件を分けます。

そのうえで、表で決めた内容を実際の権限設定、接続先の制約、承認フローに対応づけ、許可されない操作が実際に拒否されることまで確認します。

なお、承認条件については、製品側にも手がかりがあります。

Hunterの公式製品ページでは、顧客に届く操作（アウトリーチや提案の送信）は、実行前に営業担当者の承認を必須にできると説明されています。

自社で必要な承認の位置が、こうした設定で表現できるかを確認するところから始められます。

実務上の留意点：名前は権限を決めない

名前や担当領域が分かりやすく示されていても、それだけで実際のアクセス範囲や実行権限が分かるわけではありません。

前述のとおり、Salesforceは各エージェントに企業独自の名前を付けられるとしています。

社内で名前が定着した後も、そのエージェントがどこまでの情報を参照でき、どの操作を人の承認なしに実行できるのかは、別途確認する必要があります。

「Caseyに任せている」「Marshallが処理した」という言い方に慣れてしまうと、権限の線引きを済ませたつもりになりやすい、というのが私たちの見方です。

また、問題が起きたときに、どのエージェントが、どの設定と参照情報のもとで、何を実行したかを追えるようにしておくことが重要です。

複数のエージェントやシステムが一つの業務を分担する場合には、個別の記録だけでなく、引き継ぎを含む処理全体を追えるようにします。

まとめ

業務別のエージェントは、AIに任せる仕事を整理する出発点になります。

ただし、担当業務の名称だけでは、自社で必要なアクセス範囲や承認条件まで決まるわけではありません。

MIFが重視するのは、エージェントの数ではなく、任せる業務と、参照できる情報・実行できる操作・人へ引き継ぐ条件・確認可能な記録を対応づけることです。

共通部分には既存のルールを生かし、業務固有の条件と、分担する場合の引き継ぎを確認します。

導入を検討する際は、まず対象業務について本稿の4項目を整理し、その内容が実際の権限設定や承認フローに反映されているかを確かめるところから始めます。

AI導入をソフトウェアの機能選定だけで終わらせず、業務上の役割と権限まで具体化する。

私たちは今回の発表を、その必要性を考える材料として捉えています。

情報確認について

本記事は2026年9月確認時点で、2026年9月11日発表のSalesforce公式ニュースルーム記事を主要な参照元とし、補足としてSalesforce公式ヘルプのAgentforceセキュリティに関する解説（共有責任モデル）およびアウトバウンド営業エージェントの公式製品ページを参照して作成しています。

各エージェントの提供状況（一般提供・パイロット中）や提供時期の予定、製品の機能・設定項目は変更される可能性があります。

導入検討にあたっては、Salesforceの最新の公式情報をご確認ください。

なお本記事は、公表されている製品情報との照合にもとづくものであり、私たちが実機で動作や安全性を検証した結果ではありません。

権限設計についての見方および4項目の整理は、私たちMIFの見解です。