単発回答から継続実行へAgentforce長期タスクの本番化設計

要約
Salesforce Agentforceが長期実行やマルチエージェント連携へ広がりました。単発回答で終わらせず、完了条件や途中承認、引き継ぎ、成果KPIまで設計して本番運用へ進める考え方を解説します。
SalesforceのAgentforceは、問い合わせに答えるAIエージェントから、複数週間に及ぶ業務を継続して進める基盤へ広がろうとしています。前回の記事「Salesforceの職種別エージェントが変える業務自動化」では職種別エージェントの方向性を扱いました。今回は、その先にある本番運用の設計を見ていきます。
この記事の対象読者
- Salesforceを業務基盤にしている企業
- 営業や顧客対応を自動化したい企業
- 部門横断の業務プロセスを改善したい組織
- AIエージェントの本番運用を検討する企業
- 人とAIの役割分担を決めたい企業
Agentforceが広げた業務の射程

Salesforceは2026年9月17日、サービス、人事、IT、営業などに対応する専門エージェント群の拡充を発表しました。海外報道によると、今回の対象には職種別のエージェントに加え、長期実行や複数エージェントの連携を支える機能が含まれます。
発表された機能には、Agent Script、AI Skills、Agent Optimizerがあります。複数週間に及ぶ業務を扱う長期実行ランタイムも含まれ、単発の問い合わせ回答から継続的な業務プロセスへ対象を広げる位置付けです。
- 長期実行ランタイム、メモリや永続実行を扱い、業務の途中で指示を変えられる仕組み
- 職種別エージェント、サービス、人事、IT、営業などの業務領域に対応する専門エージェント群
- マルチエージェント連携、複数のエージェントが業務の異なる部分を受け持つ構成
- Agent Script・AI Skills・Agent Optimizer、エージェントの処理や能力、改善を支える機能

長期タスクを業務に落とす設計
完了条件から設計を始める

長期実行を業務へ組み込むときは、エージェントに何を答えさせるかではなく、何を完了させるかを先に定めましょう。たとえば案件対応なら、情報収集、社内確認、顧客への連絡、記録更新のどこまでを1つの業務単位とするかを決めます。
業務の途中には、価格変更や契約条件の確定など、人の判断が必要な場面が残るものです。承認前と承認後でエージェントの権限を分け、判断待ちの状態を記録できるようにします。
- 完了条件、記録更新や顧客通知など、終了とみなす状態を定義する
- 途中承認、価格、契約、対外連絡など、人が確認する境界を置く
- 引き継ぎ条件、情報不足や例外が起きた際の担当者と渡す情報を決める
- 再開条件、承認や追加情報の取得後に、どの状態から処理を再開するかを決める
- 成果KPI、処理時間、完了率、差し戻し件数など業務の結果を測る
職種別エージェントの適用範囲の決め方
職種別エージェントの適用範囲も、職種名だけで決めないことが大切です。営業エージェントなら、提案書の作成までなのか、承認依頼までなのか、顧客送付までなのかを業務の状態で区切るべきでしょう。
マルチエージェントの責任分界

連携が増えるほど責任の所在が曖昧になる
複数のエージェントを連携させる場合は、処理を分担するほど責任の所在が見えにくくなりがちです。顧客情報を確認するエージェントと、提案内容を作るエージェントが別なら、どの情報を誰が保証するかを事前に決めておく必要があるでしょう。
責任分界は、担当する業務、参照できる情報、実行できる操作、異常時の引き継ぎ先の4点で整理できます。連携の前にこの境界を一覧化すると、障害時に原因を追いやすい。
- 担当業務、各エージェントが開始から終了まで受け持つ範囲
- 参照情報、参照可能なデータと、参照してはいけないデータ
- 実行操作、更新、通知、承認依頼など許可するアクション
- 引き継ぎ先、例外や判断待ちが発生した際に対応する人やチーム
回答精度と業務完了率は分けて評価する

本番運用では、エージェント同士が正しく連携したかだけでなく、業務が最後まで完了したかを確認します。回答精度を測る評価と、業務の完了率や処理時間を測る評価は分けて持つ設計です。
本番化で先に決める運用境界

私たちが見てきた範囲では、AIエージェントの導入検討は回答例の確認から始まりやすい傾向があります。長期タスクへ広げる段階では、業務の途中にある承認と例外処理が設計の中心になるでしょう。
最初から全社の業務を対象にせず、複数の担当者やシステムをまたぐ1つの業務プロセスを選ぶ進め方が考えられます。そこで自律実行の範囲を段階的に広げ、KPIが変わるかを確認したい。
自社で設計を始めると、業務の完了条件が担当者ごとに違う、途中承認の責任者が決まらない、複数エージェントの引き継ぎ情報を定義できない、といった詰まりが起きます。これは機能選定だけでは解消しにくい論点です。
- まずは業務の開始条件と完了条件を文章にする
- 人の承認が必要な状態と、自動実行できる状態を分ける
- 例外時に渡す情報と引き継ぎ先を決める
- 回答品質と業務成果のKPIを別々に記録する
- 結果を見て自動化の範囲を一段階ずつ広げる

自社で進める際の障壁と支援
- 業務の現状を整理し、例外を含む処理の流れを確認する
- エージェントごとの権限と責任分界を要件に落とし込む
- 本番展開後の運用担当者と、内製化する範囲を決める
外部の支援を使う場合は、ツールの提案を先に受けるのではなく、現場の業務と既存システムを確認してから要件を固められるかを見ましょう。BinxAI株式会社のみっちゃくんは、提案の前に現場へ入り、課題の整理と現状の診断を済ませてから要件を固めます。
見積は一式ではなく、要件を整理したうえで詳細な提示が基本です。契約後に要件が動いた場合も、決めた範囲の中で優先順位を入れ替えながら進めます。企画、課題整理、要件整理から開発まで同じ担当が受け持ち、内製化と社内定着まで支援します。
- 課題の整理と現状の診断
- 要件定義と設計
- 開発と本番環境への展開
- 運用の引き継ぎと内製化の支援
- 担当者向けの研修

よくある質問
Agentforceの長期実行とは?
複数週間に及ぶ業務を、状態やメモリを保持しながら継続して実行する考え方です。途中で指示を変更できる点も、単発回答との違いとして発表されています。
職種別エージェントはどこまで任せるべきですか?
職種名ではなく、業務の状態で範囲を区切るのが基本です。顧客への送付や契約条件の確定など、影響が大きい操作には承認を置き、記録更新などから段階的に任せるのが現実的でしょう。
途中承認はどの業務に置きますか?
価格、契約、対外連絡、個人情報の扱いなど、判断の結果が顧客や会社へ直接影響する箇所が対象です。承認待ちの状態と、再開時に必要な情報も合わせて定義します。
マルチエージェントで最初に決めることは?
各エージェントの担当業務、参照情報、実行操作、異常時の引き継ぎ先です。処理の速さより先に責任分界を決めると、障害や誤処理が起きた際の確認先が明確になります。
本番運用では何をKPIにしますか?
回答の正確さだけでなく、業務の完了率、処理時間、差し戻し件数、承認待ちの滞留なども候補になります。業務の目的に合わせ、導入前後で比較できる指標を選びましょう。
Agentforceの長期実行は、AIエージェントを回答担当から業務の実行担当へ広げる動きです。日本企業が本番化を進めるには、完了条件、途中承認、引き継ぎ、責任分界、成果KPIを1つの業務プロセスに落とし込み、段階的に自動化の範囲を広げることが出発点になります。
本記事の情報は2026年9月19日時点の公開情報に基づきます。Agentforceの機能や提供条件は変更される可能性があるため、導入や契約の前に各社へ確認してください。本記事は特定の成果を保証するものではありません。
この記事の分類
同じ分類の記事をまとめて読めます。
次に読む記事

Salesforceの職種別エージェントが変える業務自動化
Salesforceが示した職種別AIエージェントは、質問に答えるチャットボットから業務を継続実行する仕組みへ広がっています。提供範囲、長期タスク、KPI、権限管理、有人引き継ぎを導入前にどう設計するかを整理します。

販売AIを小売に導入する前に決めるべき承認範囲とKPIの考え方
Anthropicが発表したClaude for Commerce Agentsは、買い物客への提案と店舗側の販促準備をAIが担う構想を示しました。小売企業が導入前に決めるべき承認範囲、データ接続、段階導入、KPIの考え方を整理します。

PhoneLLM Alpha 1で電話対応AIは安くなるか
PhoneLLM Alpha 1の公開で広がる音声AIの選択肢を、LLM単価だけで判断してはいけません。音声認識、回線、応答速度、有人引き継ぎ、日本語の聞き取りまで含めた費用対効果の測り方を整理します。















