SalesforceのSummer '26がマルチエージェントオーケストレーションを6月15日にリリース。エージェント間の引き継ぎが始まる前に行うSales Ops監査

6月15日まであと2週間です。Sales Operations（Sales Ops）チームにとって最も重要な機能は、新しいダッシュボードでも、より高精度なforecastでもありません。新たなガバナンス上の課題です。

SalesforceのSummer '26リリースは2026年6月15日に一般提供（GA）が開始されます。Sales Opsにとっての注目点は、Agentforce内のマルチエージェントオーケストレーションです。複数のエージェントを連携させ、収益プロセス全体を通じて互いに作業を引き継ぐことができる機能です。Slack First Salesと組み合わせることで、営業担当者がすでに使い慣れているSlack内でCRMのコンテキストを会話形式で参照できるようになります。このリリースは、AIを活用した収益プロセスのガバナンスのあり方を根本から変えるものです。

この変化は小さなものではありません。単一エージェントの展開では、ガバナンス作業は1つのエージェントに集中していました。読み取り権限、書き込み権限、トリガー条件、エラー状態の管理です。マルチエージェントオーケストレーションでは、エージェント同士が作業を引き継ぐようになり、その引き継ぎのたびに、人間が気づかないままpipelineが漏れたり、ループしたり、意図から外れたりするリスクが生じます。SalesforceのState of Sales 2026データによると、これがいかに重要かは規模を見れば明らかです。2027年までにAIエージェントを活用する予定の営業担当者は約9割に上り、AIエージェントによってリサーチ時間が34%削減されると見込まれています。多くのエージェントが多くの商談に関与することになります。6月15日までに引き継ぎグラフの設計を誤ると、後半は幽霊リードの解消に追われることになります。

6月15日に実際に提供される機能

重要なポイント

• Summer '26のGA開始日: 2026年6月15日（出典: Salesforce Newsroom）
• 2027年までにAIエージェントを活用する予定の営業担当者: 約9割（出典: Salesforce State of Sales 2026）
• AIエージェントによるリサーチ時間の削減見込み: 34%（出典: Salesforce State of Sales 2026）

マルチエージェントオーケストレーションが中心的な変更点です。個々のAgentforceエージェントを連携させ、あるエージェントのアウトプットが次のエージェントのインプットになる仕組みです。リサーチエージェントが見込み客のインテリジェンスを完成させ、その情報をアウトリーチエージェントに引き継ぎます。アウトリーチエージェントはエンゲージメントをスコアリングし、クオリフィケーションエージェントに引き継ぎます。クオリフィケーションエージェントがステージの判断を行い、CRM更新エージェントに引き継ぎます。CRM更新エージェントはフィールドを書き込み、フォーキャストエージェントに引き継ぎます。1つの商談に5つのエージェントが関与し、中間ステップには人間が介在しません。

Slack First Salesも同時に提供されます。CRMデータがSlackのスレッド内に会話形式で表示されるため、営業担当者はSlackを離れることなく商談の対応ができます。エージェントはそれらのやり取りの結果を自動的にSalesforceに書き戻します。すでにSlackを日常的に使っているチームにとっては、本当に実用的な機能です。しかし、ここでも別のガバナンス上の問題が生じます。営業担当者のSlack返信がエージェントによるSalesforceへの書き込みをトリガーした場合、監査証跡の責任は誰が負うのでしょうか。

Summer '26の残りの機能には、Einstein、Data Cloud、各業界向けクラウドのアップデートが含まれます。本記事はオーケストレーション層とSlackの引き継ぎに限定して取り上げます。Summer '26のカスタマーエンゲージメントエージェントのアップデートは、CROレベルの評価として別途取り上げています。

マルチエージェントオーケストレーションがSales Opsの業務を変える理由

オーケストレーション以前は、Agentforceのガバナンスチェックリストは1行のようなものでした。1つのエージェント、その読み取り権限、書き込み権限、トリガー条件、エラー状態です。

オーケストレーション導入後、その1行はグラフになります。そして、このグラフが新たなガバナンスの対象になります。

5つのエージェントによる収益ワークフローが実際にどのように動くかを考えてみてください。リサーチエージェントは外部データソースを照会し、見込み客インテリジェンスオブジェクトを作成します。信頼度スコアが設定値を超えると、アウトリーチエージェントをトリガーします。アウトリーチエージェントはメッセージシーケンスを生成し、エンゲージメントステータスフィールドを書き込みます。見込み客が特定のタッチポイント数に達すると、クオリフィケーションエージェントをトリガーします。クオリフィケーションエージェントはステージ基準を評価し、商談ステージフィールドを書き込みます。基準を満たすと、CRM更新エージェントをトリガーします。CRM更新エージェントは商談レコード全体の商談フィールドを書き込みます。週末にフォーキャストエージェントをトリガーします。フォーキャストエージェントはコミットカテゴリを更新します。

5つのエージェントにまたがる8つの明確な引き継ぎイベントがあり、それぞれが異なるCRMオブジェクトとフィールドに触れています。引き継ぎの1つでも誤作動すれば、下流のレコードが誤った状態になります。そして、中間ステップを承認する人間がいないため、誰かがレポートで気づく前に、誤ったデータが積み重なっていきます。

これがSales Opsの役割が「1つのエージェントを設定する」から「引き継ぎグラフを管理する」へと変わる理由です。収益プロセスのガバナンスは、今やこのグラフに宿っています。6月15日までに意図的に設計しなければ、デフォルトの動作がそのまま稼働し、お客様の特定のデータ環境においてSalesforceの標準トリガー条件が生み出す結果をそのまま引き継ぐことになります。

AIによるSales Opsのガバナンスと監査証跡がより広範なAI Sales Opsスタック全体にどのように機能するかについては、そのフレームワークがここでも直接適用されます。オーケストレーションは監査証跡の要件をより複雑にこそすれ、シンプルにはしません。

Sales Opsが防ぐべき3つの引き継ぎ失敗パターン

ファントム引き継ぎ

ファントム引き継ぎとは、エージェントAが作業を引き渡したとマークしたにもかかわらず、エージェントBがそれを処理しない状態です。リードは2つのエージェントキューの間で止まった状態に置かれます。どちらのエージェントもエラーを出さず、アラートも発生しません。商談が進まなくなるだけです。

これはキューベースのシステムで最も一般的な失敗パターンであり、マルチエージェントオーケストレーションはその新しいバリエーションをもたらします。監査のチェックポイント: グラフ内の各引き継ぎについて、受信エージェントからの明示的な受領イベントが存在することを確認してください。発信元エージェントの「送信済み」ステータスだけでは不十分です。受領を確認できなければ、引き継ぎが完了したことを確認できません。

ループトラップ

ループトラップとは、エージェントBが前進条件を満たさず、作業をエージェントAに戻してしまう状態です。エージェントAは再評価を行い、自身の終了条件を満たせず、エージェントBに戻します。タイムアウトが発動するか、人間がキューを調べるまで、リードは2つのエージェントの間を行き来し続けます。

具体的な例として、MEDDICスコアが一定の閾値を超えた場合にのみ商談を進めるクオリフィケーションエージェントと、クオリフィケーションが不完全なデータを返すたびに再実行されるリサーチエージェントの組み合わせがあります。リサーチエージェントがクオリフィケーションエージェントの必要なデータを見つけられない場合、ループが発生します。監査のチェックポイント: すべての引き継ぎパスに「前進不可」の出口を定義してください。最大リトライ回数、フォールバック状態（人間によるレビューキューなど）、またはレポートに表示される明示的なエラー状態のいずれかが必要です。

権限ドリフト

権限ドリフトは最も気づきにくく、最も危険なパターンです。オーケストレーション層がエージェントごとのフィールド権限を強制しないため、エージェントが本来管理すべきでないフィールドに書き込んでしまう状態です。

発生のメカニズムはこうです。CRM更新エージェントは商談金額とクローズ日を書き込むよう設計されています。しかし、オーケストレーションの設定時に、フィールドごとにスコープを設定するより一度に設定する方が楽だという理由で、広範な書き込みアクセス権が付与されます。下流のクオリフィケーションエージェントが同じフィールドに矛盾を発見し、修正を書き込みます。その結果、2つのエージェントが異なるロジックで同じ商談フィールドに書き込みを行い、フィールド履歴には人間が意図的に行ったのではない一連の更新が記録されます。

監査のチェックポイント: オーケストレーショングラフ内の各エージェントに、書き込み可能なフィールドのスコープを文書化してください。そのスコープは設定上の慣習としてではなく、権限レベルで強制される必要があります。現在のAgentforce設定がエージェントごとのオブジェクト権限を強制しているか、それともオーケストレーション層がorg全体のエージェント権限セットを継承しているかを今すぐ確認してください。

引き継ぎトリプレットフレームワーク

オーケストレーショングラフ内のエージェント間の引き継ぎごとに、3つの事項を文書化してください。これが引き継ぎトリプレットです。

トリガー条件。 エージェントAがエージェントBに作業を引き継ぐ原因となる具体的なイベント、フィールド値、または閾値は何ですか? 「リードスコアが75を超えたとき」はトリガー条件です。「エージェントが準備できたと判断したとき」は条件ではありません。

フィールド書き込み権限。 引き継ぎ前にエージェントAが書き込み可能なCRMフィールドはどれですか? 引き継ぎ後にエージェントBが書き込み可能なフィールドはどれですか? これらのリストは重複してはなりません。重複する場合は、どちらのエージェントが優先されるかを決定し、明示的に文書化してください。

ロールバックパス。 引き継ぎを受けたエージェントBがエラーを起こした場合、レコードはどうなりますか? エージェントAの最後の書き込みは残りますか? 商談はエージェントAが設定したステージに留まりますか? エラーが人間によるレビューのためのキューに表示されるか、それともサイレントにログに記録されるかを確認してください。

例を挙げましょう。標準的なAgentforceワークフローにおけるクオリフィケーションエージェントとCRM更新エージェント間の引き継ぎです。

• トリガー条件: クオリフィケーションエージェントがステージを「SQL」（Sales Qualified Lead）に設定し、MEDDICスコアが80以上
• フィールド書き込み権限: クオリフィケーションエージェントはStage、MEDDICスコアフィールドのみ書き込み可。CRM更新エージェントはAmount、クローズ日、Forecast Categoryフィールドのみ書き込み可。重複なし。
• ロールバックパス: CRM更新エージェントがエラーを起こした場合、StageとMEDDICスコアフィールドはクオリフィケーションエージェントの最後の値を保持。エラーイベントがSalesforceのSales Opsレビューキューに通知される。商談は「エージェントエラー、手動レビュー要」ステータスでフラグが立てられる。

ロールバックパスがなければ、CRM更新エージェントのエラーにより、商談はクローズ日も金額も、何か問題が起きたというシグナルもないままSQL ステージに永遠に留まります。その商談はpipelineカバレッジレポートに表示され、forecast数値を膨らませ、最終的に3週間後のpipelineレビューで商談が失速した理由を不思議に思うマネージャーに発見されることになります。

エージェント主導のステージ進行に対応するためにpipelineステージ設計を再構築しているチームは、6月15日前にpipelineステージ設計フレームワークを見直すことをお勧めします。エージェントの終了条件は、営業担当者とマネージャーがすでに信頼しているステージロジックと一致している必要があります。

Slack First Sales: もう1つの監査対象

Slack First Salesは、Slackを経由する営業担当者からエージェントへの書き込みパスという、第2の引き継ぎカテゴリを生み出します。営業担当者がSlackの商談通知に返信し、エージェントがその返信を解釈してSalesforceに書き戻す場合、6月15日までに3つの問いに答える必要があります。

• フィールド書き込みの責任者は誰か? エージェントがSlackの返信に基づいて商談レコードに書き込んだ場合、その書き込みはエージェントのプロフィール下に表示されるのか、それとも営業担当者のプロフィール下に表示されるのか? これは監査ログおよびコミッション申請における帰属確認において重要です。
• 権限の境界はどこにあるか? Slackのやり取りからSalesforceに書き込むエージェントは、オーケストレーショングラフ内の他のエージェントと同じフィールド書き込みスコープの強制が必要です。Slackからトリガーされるパスが、直接設定されたエージェントと同じ権限モデルを通るか、別のより制限の少ないパスを通るかを確認してください。
• やり取りはログに記録されているか? Slackメッセージはデフォルトではセールスフォースのアクティビティレコードではありません。営業担当者のSlack返信がエージェントによるステージ変更の書き込みの根拠になる場合、そのSlackメッセージがその変更の証跡となります。6月15日前にSlackからSalesforceへのアクティビティ同期が稼働していることを確認してください。そうしなければ、人間が読み取れる根拠が紐付いていないCRM書き込みが発生します。

エージェント主導の書き込みを踏まえてCRMデータモデル設計を検討しているチームにとって、営業担当者ではなくエージェントが主要な商談フィールドの主たる書き込み者になる場合、フィールドオーナーシップの問題はより重要になります。

6月15日前に確認すべき5つの問い

今週中にカレンダーにこの5つの問いをブロックしてください。2時間確保し、Agentforceの設定を開いて、1つずつ確認してください。

1. 現在のAgentforce設定において、エージェント間のすべての引き継ぎを文書化したリストはありますか? なければ、今すぐマッピングしてください。名前のついていないものは監査できません。
2. 各引き継ぎについて、トリガー条件を正確に述べることができますか? 曖昧なトリガーは一貫性のない動作を生み出します。答えに「だいたい」「準備ができたと思われるとき」という言葉が含まれる場合は、定義を厳密にしてください。
3. 各エージェントに書き込み可能なフィールドのスコープが文書化されており、そのスコープが権限レベルで強制されていますか? 設定上の慣習は変化します。権限による強制は変化しません。
4. 各引き継ぎに、エラー状態に対するロールバックパスが定義されていますか? 各引き継ぎの失敗シナリオを検討してください。受信エージェントがエラーを起こした場合、レコードはどのような状態になりますか? その状態は手動介入なしに回復可能ですか?**
5. Slack First Salesのやり取りについて: SlackからSalesforceへのアクティビティ同期は稼働しており、どのSlackからトリガーされた書き込みがエージェントのプロフィール下に表示され、どれが営業担当者のプロフィール下に表示されるかを確認しましたか? 6月15日の後ではなく、前にテストのやり取りを実施してください。

AIによるリードスコアリングの失敗パターンに取り組んできたチームは、ここでも同じパターンを認識するでしょう。失敗の原因は通常AIモデルそのものではなく、モデルが書き込める内容とアウトプットを誰がレビューするかをめぐるガバナンス層にあります。オーケストレーションはこのリスク領域を大幅に拡大させます。

今週すべきこと

Summer '26が稼働するまで約13日間あります。6月15日までに最も重要なことをまとめます。

グラフをマッピングする。 Agentforce org内のすべてのエージェントをリストアップし、それらの間の引き継ぎ接続を図示してください。これがステップゼロです。これなしには監査の何も進みません。

各接続に引き継ぎトリプレットを適用する。 グラフ内の各引き継ぎについて、トリガー条件、両側のフィールド書き込み権限、ロールバックパスを文書化してください。3列、引き継ぎごとに1行。最もよく使われる商談フィールドに触れる引き継ぎから始めてください。Stage、Amount、クローズ日、Forecast Categoryです。

フィールド書き込みスコープを権限レベルで強制する。 現在の管理者の文書化されていない意図を将来の管理者が踏襲することを前提とした設定上の慣習に頼らないでください。エージェントAがAmountフィールドを書き込むべきでない場合は、その権限を明示的に削除してください。

エラーキューを設定する。 エージェントのエラーがどこに表示され、誰がレビューするかを決定してください。現在、エージェントエラー用のSales Opsレビューキューがない場合は、pipelineデータでファントム引き継ぎに気づいてからではなく、6月15日前に構築してください。

Slack First Salesのテストを実施する。 org全体で稼働させる前に、Slackのやり取りを手動でトリガーし、フィールド書き込みがSalesforceに正しく表示されることを確認し、アクティビティログを検証し、書き込みに表示されるプロフィール名を確認してください。

人間主導のプロセスでpipelineデータを清潔に保つpipelineの衛生管理プラクティスは、エージェント主導のプロセスでは2倍重要になります。エージェントは不良データに言い訳をしません。規模を拡大して増幅させるだけです。6月15日までにガバナンスを正しく整備すれば、オーケストレーション層は真に収益オペレーションの資産となります。この監査を怠れば、夏はインシデント対応に費やすことになります。

---

FAQ

初日からマルチエージェントオーケストレーションを無効化する必要がありますか?

必ずしもそうではありません。しかし、6月15日が稼働する前に、org内のどのエージェントが互いに作業を引き継ぐよう設定されているかを正確に把握する必要があります。今日その問いに答えられない場合、保守的なアプローチとして、引き継ぎトリプレット監査を完了するまで、最も重要な商談フィールド（Stage、Amount、クローズ日）に対するオーケストレーションを無効化することを検討してください。各引き継ぎを適切に文書化し、段階的に再有効化できます。

マルチエージェントオーケストレーションとSalesforce Flowの違いは何ですか?

Salesforce Flowは、お客様が記述した明示的なロジックに基づいて事前定義されたステップを実行する設定済みの自動化です。マルチエージェントオーケストレーションは異なります。エージェントがいつ引き継ぐか、何を渡すかについて、推論に基づく意思決定を行います。Flowは決定論的ですが、オーケストレーションされたエージェントはそうではありません。だからこそ引き継ぎトリプレットが重要なのです。Flowのロジックを読めば自動化の動作を理解できますが、エージェントが何を引き渡すと判断したかはロジックを読んでも分かりません。エージェントの動作が意図と一致していることを確認するには、文書化されたトリガー条件が必要です。

Slack First SalesはどこでAudit Logに記録されますか?

デフォルトでは、SlackメッセージはSalesforceのアクティビティレコードではありません。営業担当者のSlack返信がエージェントによるSalesforceへの書き込みをトリガーした場合、その書き込みはレコードのフィールド履歴に表示されます。ただし、それを引き起こしたSlackメッセージは自動的に関連アクティビティとして表示されません。関連レコードのアクティビティとしてSlackのやり取りをログに記録するよう、SlackからSalesforceへのアクティビティ同期を有効化して設定する必要があります。6月15日前にこれが稼働していることを確認しなければ、人間が読み取れる根拠のないフィールド履歴エントリが発生します。