【2026年8月時点】Agentforce MCPとは？複数システムをまたぐ境界設計と接続方式

Agentforceを社外のシステムとつなぐときは、足りない連携を1つずつ追加していけば、いずれ業務が最後まで終わるようになると考えられがちです。しかし実際には、接続先が増えるほどエージェントがどの処理を選ぶのか読みにくくなり、どこまでを1つのエージェントに持たせるかを決めきれないまま、個別の接続だけが積み上がっていくのではないでしょうか。なお、提供段階や仕様は短い周期で変わるため、本記事は2026年8月12日時点で一次情報を確認できた範囲にもとづいています。

そこで本記事では、Agentforceの責務をどこで切るかという境界の決め方と、MCPをはじめとする4つの外部連携方式の使い分けを、提供段階の確認結果まで含めて解説します。

この記事を書いた人

本田正憲

合同会社クロスコムの代表｜専門商社にて7年間のBtoB営業を経て、マーケティング業界に参入。現在はSalesforce公式コンサルティングパートナーとして、ソリューション営業の業務プロセスに特化したAgentforce導入・定着支援を提供している。

Agentforceだけで業務が完結しない3つの状況

企業が使うSaaS（サービスとしてのソフトウェア）の数は、1組織で3桁に達する水準にあります。Oktaが2025年3月に公開した「Businesses at Work 2025」は、Okta Integration Networkの数千社の匿名化データにおける1組織あたりの平均アプリ数を101と報告していますが、これはOktaの顧客企業における平均であり、日本企業や全業種の平均ではありません。本記事で例に取り上げるのは、産業用資材を扱う中堅商社（従業員約400名・営業60名・情報システム部3名）で、Salesforceの運用を担当している情報システム部の担当者です。そこでここでは、Agentforceだけで業務が完結しない3つの状況を整理します。

※参考記事：okta「Businesses at Work 2025: 10 years of data show how critical security has become」

Agentforce単体で業務が終わらない原因は機能の不足になく、業務に必要なデータと操作が複数のシステムに分かれて置かれていることにあります。

状況①基幹システムのデータを参照できていない

1つ目の状況は、営業が顧客から最も多く聞かれるデータが、Salesforceの外にある基幹システムだけに置かれていることです。商談の履歴や見積はSalesforceに集まっていても、受発注と在庫の数量は別会社製の基幹システムが持ち続けている企業は少なくありません。

なぜこの状況が残るのかというと、基幹システムの入れ替えは受発注の停止を伴い、CRM（顧客関係管理）の整備よりも後回しになりやすいからです。その結果、顧客に最も近い担当者が、最も知りたい数値だけを別の画面で調べる状態が続きます。

たとえば、この産業用資材の商社では、営業向けのエージェントに商談情報の要約と見積書の下書きまでを任せていました。ところが顧客から「その品番はいま何本残っていますか」と聞かれた瞬間、エージェントは在庫の数量を持っておらず、「担当者に確認します」と返すしかありませんでした。営業は基幹システムを操作できる受注管理の担当者へ内線をかけ、回答までに数時間かかっていたのです。

業務が最後まで終わっているかどうかは、エージェントが答えられた件数よりも、担当者が別の人に確認しなければならない項目が残っているかどうかで判断しましょう。Agentforce単体でできることの範囲は、ほか記事「Agentforceの機能一覧｜360・Coworker・Voiceまで主要機能を整理」で整理していますので、先に押さえておくと境界を決めやすくなります。

状況②別部門のAIツールに会話が引き継がれない

2つ目の状況は、別の部門が先に導入したAIツールと、Agentforceの会話が切れてしまうことです。カスタマーサポート部門が自部門の判断で対話型のツールを入れ、営業部門がAgentforceを使っている場合、同じ顧客からの問い合わせが2つの履歴に分かれて残ります。

具体例でいうと、この商社ではカスタマーサポート部門が返品と交換の一次対応を別のAIツールに任せていました。営業が顧客から「先週出した交換の依頼はどうなっていますか」と聞かれても、エージェントはサポート側のやり取りを参照できず、担当者がサポート部門へチャットで確認していたのです。顧客からすれば同じ会社への1件の問い合わせでも、社内では2つの別々のやり取りとして処理されていました。

こうした状態は、片方のツールを解約すれば解決するものではありません。部門ごとに適したツールが違うこと自体は自然であり、問題になっているのは、会話を引き継ぐ経路が用意されていないことです。引き継ぎの経路がないまま両方を使い続けると、顧客が同じ説明を二度求められる場面が増えていきます。

状況③SaaS側の操作だけ人手に戻っている

3つ目は、物流や請求といった特定の業務が部門ごとに契約したSaaSで動いていて、その操作だけが人手に残っている状況です。参照はできても更新はできない、あるいは画面を開くこと自体に別のIDが必要で、エージェントからは操作できません。

この商社の場合、物流部門が独自に契約した配送管理のSaaSで出荷状況を管理していました。営業が納期を聞かれるたびに物流部門へ問い合わせ、担当者がSaaSの画面を開いて伝票番号を調べ、Salesforce側へ手入力で戻すという流れが定着していたのです。1件あたりの作業は短くても、依頼が1日に何十件と積み上がると、物流部門の担当者は本来の配車業務に取りかかれなくなります。

部門が契約したSaaSは情報システム部門の管理対象に入っていないことが多く、連携の相談が持ち込まれることもありません。以上が、Agentforceだけで業務が完結しない3つの状況でした。3つのうち1つでも自社に当てはまるのであれば、連携を1つずつ足す前に、どこまでを1つのエージェントに持たせるかを決める段階にあります。

Agentforceに機能を集約すると起きる3つの問題

ここまで、Agentforceだけでは業務が最後まで終わらない3つの状況を整理してきました。この状況に気づいたとき、多くの担当者が最初に検討するのは、足りない処理をすべてAgentforce側のアクションとして作り込み、1体のエージェントに集約する方法です。そこでここでは、Agentforceに機能を集約したときに起きる3つの問題を整理していきます。

集約を進めるほどエージェントは適切な処理を選べなくなり、設定の変更に他部門の合意が必要になり、失敗したときに止まった場所を特定できなくなります。

問題①アクションが増えるほど選択の精度が落ちる

1つ目の問題は、1体のエージェントに持たせるアクションが増えるほど、依頼に対して適切な処理を選べなくなることです。エージェントは利用者が書いた文章と、各アクションに付けられた説明文を照らし合わせて実行するものを決めるため、似た説明文の選択肢が並ぶほど判断を誤りやすくなります。

たとえば、この商社が在庫照会・出荷状況の確認・返品の受付をすべて1体のエージェントに追加したところ、「あの注文どうなってる」という短い依頼に対して、出荷状況の確認より先に返品の受付が動く場面が出ていました。担当者は説明文を書き直して調整しましたが、片方を直すともう片方が選ばれにくくなり、修正のたびに別の依頼で誤りが出る状態になっていたのです。

1体の中で扱う業務が部門をまたぎ始めたら、追加を止めて分割を検討する段階に入っています。対象を絞ったエージェントの設計例は、ほか記事「Agentforce Service Agentとは？チャットボットとの違いと導入設計を解説【2026年最新】」にて解説していますので、ぜひ参考にしてもらえると嬉しいです。

問題②部門をまたぐと定義の変更に合意が要る

2つ目は、設定を1か所変えるだけで、他部門の合意を取る必要が生じることです。営業・カスタマーサポート・物流の処理が同じエージェントに同居していると、どの説明文がどの部門の業務に影響するのかを、担当者が単独で判断できなくなります。

この商社では実際に、営業から「在庫の回答文が固すぎる」という要望が出たときに、同じ文言をカスタマーサポート部門の対応でも参照していたため、変更の可否を両部門で調整する必要が生じました。営業側の要望は1文の修正でしたが、合意までに2週間かかり、その間はほかの改善も止まっていたのです。

改善の速度は、設定の難易度よりも、変更に同意を求める相手の人数で決まります。週に何度も文言を直したい業務ほど、他部門と共有しないエージェントに切り出しておくほうが、あとの運用は続けやすくなります。

問題③障害時にどこで止まったか切り分けられない

3つ目は、処理が失敗したときに、どこで止まったのかを切り分けられなくなることです。1体のエージェントが複数のシステムを直接呼び出していると、返答が返らない原因が依頼の解釈にあるのか、接続先の応答にあるのかを分けて確認できません。

この商社では、在庫を照会したときに応答が返らない事象が週に数回起きていました。基幹システム側の夜間バッチと処理時間が重なった時間帯だけ発生していたのですが、原因の特定に情報システム部門の担当者が半日を使い、最終的には基幹システムの担当者へ確認して判明したという経緯でした。

原因を追える構造になっているかどうかは、接続先ごとに応答の記録が分かれているかで確認できます。1体に集約するほど記録も1本にまとまり、切り分けにかかる時間は増えていきます。Agentforceに機能を集約したときに起きる問題は、この3つに集約されます。

Agentforceの責務を切る4つの判断基準

前章では、1体のエージェントに機能を集約したときに起きる3つの問題を確認しました。集約に限界があるのであれば、次に決めるべきは、どこまでを自組織のAgentforceに残し、どこから先を外部に任せるかという境界です。そこでここでは、Agentforceの責務を切る4つの判断基準を解説します。

その処理について意思決定・データの権限・応答時間・復旧責任の4つを自組織で引き受けられるかどうかが、境界を決める判断基準になります。

基準①業務の意思決定が同じ部門で完結するか

1つ目は「業務の意思決定が同じ部門で完結するか」です。処理の内容を変えたいと思ったときに、その判断を自部門だけで下せるのであれば、Agentforceの内側に残す価値があります。

なぜこの基準を先頭に置くのかというと、エージェントの説明文や条件は稼働してから何度も直すことになり、直せる速度がそのまま改善の速度になるからです。判断の所在が外にあると、設定を触れても中身を決められません。

この商社を例にとると、商談の要約と次に取るべき行動の提案は、営業企画の担当者だけで文面と条件を決められる業務でした。一方で、返品を受け付けてよいかどうかの判定は、カスタマーサポート部門が定めた基準に従う必要があり、営業側で変えることはできません。前者は内側に残し、後者は外へ渡す候補として扱いました。

判断の所在を確かめるときは、その処理の内容を来週変えたいと言ったとき、誰の承認が要るかを数えてみましょう。承認者が自部門の外に1人でもいる処理は、外へ渡す側の候補になります。

基準②扱うデータの権限を自組織で管理できるか

2つ目に確認するのは、その処理が扱うデータの権限を、自組織で管理できるかどうかです。Salesforce上のデータであれば、参照できる範囲も更新できる範囲も自組織の設定で決められますが、他社製の基幹システムや部門契約のSaaSでは、権限の設計を決めているのは相手側です。

この商社では、在庫の数量は営業全員が見てよいデータでしたが、仕入単価は購買部門の一部だけが見られる設定になっていました。仕入単価の参照可否を決めているのは基幹システム側の権限設計であり、Salesforceの共有ルールを直しても影響しません。そこで、単価を含む問い合わせは基幹システム側の判定に委ね、Agentforce側は結果を受け取るだけにとどめる方針を取ったのです。

権限の管理者が自組織にいない処理を内側に作り込むと、相手側の権限設計が変わるたびに、こちら側の設定も追いかけて直すことになります。参照してよい人の範囲を自組織で決められない処理は、外へ渡す前提で設計しておくほうが安全です。

基準③応答時間の要件を自組織で満たせるか

3つ目の基準は、その処理に求められる応答時間を、自組織の設定だけで満たせるかどうかです。エージェントが外部のシステムを呼ぶ場合、返答までの時間は相手側の処理速度に左右されるため、こちら側の調整だけでは短くできません。

具体例でいうと、この商社の基幹システムは、在庫の照会に数秒で応答する一方、期間を指定した出荷実績の集計になると数十秒かかることがありました。営業が顧客と通話しながら使う場面では、数十秒の待ち時間があると担当者は待たずに電話を切り、結局は従来どおり内線で確認していたのです。

応答時間の要件は業務の場面ごとに変わるため、顧客と話しながら使う処理は短い応答を前提に設計し、集計や一括処理のように待てる処理は別の経路へ回すという分け方が現実的です。相手側の応答時間を測らずに接続を決めると、稼働後に使われない機能が増えていきます。

基準④失敗したときの復旧責任を負えるか

最後の基準は、その処理が失敗したときに、復旧の責任を自組織で負えるかどうかです。参照だけの処理であれば再実行すれば済みますが、受注の登録や出荷指示のように相手側のデータを更新する処理は、途中で失敗すると打ち消す作業が発生します。

この商社では、受注の登録をエージェントから基幹システムへ直接行う案が出ましたが、二重に登録された場合に取り消せるのは基幹システムの運用担当者だけで、情報システム部門では手を出せない状態でした。誤った登録が出荷の指示にまで進むと、実際に商品が動いてしまいます。そこで、登録の操作は人が最終確認する運用に残し、エージェントには下書きの作成までを任せる形に落ち着いたのです。

同じ判断で、出荷指示の登録もエージェントからは行わない運用に残しました。出荷の指示は取り消しても倉庫の作業がすでに始まっていることがあり、戻す作業を情報システム部門だけでは完了できないためです。

取り消せない処理をエージェントに任せるかどうかは、失敗が起きたときに誰が何分で戻せるかを答えられるかで判断しましょう。以上が、Agentforceの責務を切る4つの判断基準でした。

Agentforceの外へ渡す処理の3つの見分け方

ここまでは、内側に残してよい処理の条件を4つの判断基準として整理してきました。実務では、条件に照らして1つずつ選別するよりも、外へ渡す側の特徴を先に見分けるほうが早く進みます。そこでここでは、Agentforceの外へ渡す処理の3つの見分け方を整理していきます。

外へ渡す候補になるのは、運用ルールを他部門が決めている処理・専門知識が別のAIに蓄積されている処理・大量のデータを一括で扱う処理の3つです。

見分け①運用ルールを他部門が握っている処理

1つ目は、運用ルールを他部門が決めている処理です。判定の条件や例外の扱いが他部門の規程で決まっていて、こちらは結果を受け取るだけという処理は、Agentforce側に条件を書き写すべきではありません。

条件を書き写してしまうと、相手側の規程が改定されたときに、こちら側の設定が古いまま動き続けます。しかも改定の連絡は、規程を持つ部門から情報システム部門へは届きにくく、誤った回答が出て初めて気づくことになります。

この商社では、返品の受付可否を判定する条件が、カスタマーサポート部門の運用手順書に書かれていました。当初はその手順をエージェントの説明文に写して判定させる案がありましたが、手順書は四半期ごとに更新されており、写した内容の更新漏れが起きる前提だと判断したのです。最終的に、判定はカスタマーサポート部門側の仕組みに任せ、Agentforceは依頼の受け取りと結果の伝達だけを担う形にしました。

逆に、条件の改定が年に1回程度で、改定の連絡が確実に届く相手であれば、内側に条件を持ったままでも運用は続けられます。

見分け②専門知識が別のAIに蓄積されている処理

2つ目に挙げるのは、その領域の知識がすでに別のAIツールへ蓄積されている処理です。過去のやり取りや判定の履歴が別のツールに積み上がっている場合、同じ知識をAgentforce側に作り直しても、精度が追いつくまでに時間がかかります。

この商社のカスタマーサポート部門では、製品の不具合と交換対応のやり取りが数年分そのツールに蓄積されていました。営業側で同じ回答を再現しようとすると、参照するナレッジを作り直す作業から始めることになり、しかも更新はサポート部門が続けるため、同じ内容の維持が二重になります。

知識の蓄積がどちら側にあるかは、直近半年で内容を更新した回数で確かめられます。更新の回数が相手側のほうが多い領域は、こちらで作り直さず、依頼を渡して回答を受け取る設計にしておくほうが、業務の解決には近づきます。

見分け③大量データを一括で処理する必要がある処理

3つ目は、大量のデータを一括で扱う処理です。対話の中で1件ずつ確認する処理と、数万件のデータをまとめて集計・更新する処理では、必要な仕組みが異なります。

たとえば、この商社では月末に取引先ごとの出荷実績を集計し、翌月の在庫計画に反映する業務がありました。対象は数万行に及び、処理には十数分かかります。この業務を営業向けのエージェントから呼べるようにしたところ、依頼した担当者の画面が長く待ち状態になり、途中で操作をやり直す人が出てしまったのです。

一括処理は、対話の途中では呼ばず、あらかじめ決めた時刻に別の仕組みで実行し、エージェントは結果だけを参照する形に分けましょう。外へ渡す処理を選ぶときは、この3つの見分け方で足ります。

Agentforceの境界設計で起きる3つの失敗

前章までで、内側に残す条件と外へ渡す処理の特徴を整理しました。ただし、境界を決めたあとの運用でつまずく企業は多く、切り分けの作業よりも、切り分けたあとの確認が抜けていることが原因になっています。そこでここでは、Agentforceの境界設計で起きる3つの失敗を整理します。

境界設計の失敗は、外部に渡した処理の結果を誰も確認していないこと、判断が二重になっていること、権限の一覧が更新されていないことから生じます。

失敗①外部に渡した処理の結果を検証していない

1つ目の失敗は、外部に渡した処理が正しい結果を返しているかを、誰も確認していない状態です。エージェントは受け取った結果をそのまま利用者へ伝えるため、相手側が誤った値を返しても、会話の見た目は正常なまま進みます。

この商社では、出荷状況の照会を物流部門のSaaSへ渡したあと、返ってくる日付が現地時間のままだった時期がありました。エージェントは受け取った日付をそのまま伝えていたため、営業は1日ずれた納期を顧客に案内していたのです。誤りに気づいたのは、顧客から着荷日の相違を指摘されたときでした。

この状態は3週間続き、その間に営業が案内した納期は40件ほどにのぼっていました。社内では誰も結果を確認していなかったため、件数を数えられたのも指摘を受けたあとでした。

外部に渡した処理は、渡した時点だけでなく、結果が業務で使われる時点でも確認する必要があります。営業領域で境界を引き損ねやすい業務の具体像は、ほか記事「Agentforce for Sales完全ガイド｜SDR・Sales Coachの使い方と営業活用事例【2026年最新】」もあわせてご確認ください。

失敗②同じ判断を内側と外側の両方に持たせている

2つ目は、同じ判断をAgentforce側と接続先の両方に持たせてしまう失敗です。移行の途中で内側の条件を消し忘れたまま外部の判定を追加すると、2つの判断が並行して動き、どちらの結果が採用されたのかを追えなくなります。

この商社の場合、返品の受付可否について、初期に作った簡易な条件がエージェント側に残ったまま、カスタマーサポート部門側の判定を呼ぶ設定を追加していました。簡易な条件で先に断られる依頼が出てしまい、サポート部門の基準では受け付けられるはずの案件が止まっていたのです。

外から発見しにくい重複であるだけに、接続を追加するときは、追加した機能を確認するだけでなく、同じ判断が内側に残っていないかを必ず点検しましょう。点検の対象は、移行の前から動いていた条件と、移行後に追加した判定の2つです。

失敗③接続先が増えて権限の棚卸しができていない

3つ目の失敗は、接続先が増えるにつれて、どの接続がどの権限で動いているのかを一覧できなくなる状態です。接続を追加するときは目的が明確でも、担当者の異動や業務の変更で使われなくなった接続は、そのまま残り続けます。

この商社では、検証のために作った接続が本番の組織に残っていました。検証時に広めの権限を与えたままだったため、当初の想定より広い範囲のデータを参照できる状態が続いていたのです。使っていない接続だったこともあり、半年以上気づかれませんでした。

接続先の一覧と、それぞれが使う認証情報の管理者は、四半期ごとに確認する運用にしておくと、使われなくなった接続を放置せずに済みます。以上が、Agentforceの境界設計で起きる3つの失敗でした。

Agentforceの連携方式を決める3つの観点

ここまで、境界の決め方と、境界を引き損ねたときに起きる失敗を確認してきました。境界が決まると、次は外部とどうつなぐかという方式の選択に進みますが、方式は名前で選ぶよりも、3つの観点で絞り込むほうが判断を誤りません。そこでここでは、Agentforceの連携方式を決める3つの観点を解説していきます。

連携方式は、相手がエージェントかツールか・接続先の仕様がどれくらい変わるか・実行時の権限をどちら側で担保するかの3つで絞り込めます。

観点①相手がエージェントかツールかで方式が変わる

1つ目の観点は、渡す相手が判断をするエージェントなのか、決められた処理を実行するだけのツールなのかという違いです。相手が判断まで担う場合は、依頼の文面をそのまま渡して結果を受け取る形になり、相手が処理だけを行う場合は、こちら側が引数を決めて呼び出す形になります。

この違いは、失敗したときの調べ方にも影響します。ツールを呼んだ場合は、渡した値と返ってきた値を並べれば原因を追えますが、相手が判断を含む場合は、なぜその結論になったのかを相手側の記録で確認する必要があります。

この商社の例でいうと、基幹システムの在庫照会は品番を渡せば数量が返るだけのツールでした。一方でカスタマーサポート部門のAIツールは、問い合わせの文面から対応方針を決めるところまでを担っています。同じ「外へ渡す」でも、前者は引数の設計、後者は依頼文の書き方が設計の対象になります。

観点②接続先の仕様がどれくらい変わるか

2つ目に見るのは、接続先の仕様がどれくらいの頻度で変わるかです。仕様が固定されている接続先なら、決まった呼び出しを定義しておけば長く使えますが、機能が随時追加される接続先では、追加のたびに定義を作り直す作業が発生します。

この商社では、基幹システムの在庫照会は10年近く仕様が変わっていない一方、物流部門のSaaSは提供元が四半期ごとに機能を追加していました。同じ考え方で両方を接続すると、後者は追加のたびに情報システム部門の作業が発生し、対応が追いつかなくなります。

接続先の変更頻度は、提供元のリリースノートを1年分さかのぼれば把握できます。年に数回以上の追加がある接続先は、追加を前提にした方式を選んでおくほうが、あとの作業量を抑えられます。

観点③実行時の権限をどちら側で担保するか

3つ目の観点は、処理が実行されるときの権限を、Salesforce側と接続先のどちらで担保するかです。Salesforce側で担保する場合は、既存のユーザー権限がそのまま効きますが、接続先で担保する場合は、相手側に登録した認証情報の権限がそのまま実行範囲になります。

ここで注意したいのは、相手側に登録する認証情報を1つにまとめると、誰が依頼しても同じ権限で処理が動くことです。この商社でも、基幹システムへの接続に共通の認証情報を使う案が出ましたが、それでは営業が見られないはずの仕入単価まで返ってしまうため、依頼した人の権限で判定できる経路を優先して検討しました。

権限をどちら側で担保するかは、方式を選んだあとで直すことが難しい項目です。接続を作る前に、依頼した人ごとに結果が変わる必要があるかどうかを確認しておきましょう。連携方式を絞り込むときの観点は、この3つになります。

Agentforce MCPで外部ツールを呼ぶ3ステップ

前章まででは、境界の決め方と方式を絞り込む観点を、機能の名前を出さずに整理してきました。Agentforce MCPとは、Model Context Protocol（モデルコンテキストプロトコル）に対応した外部のMCPサーバーが公開しているツールを、Agentforceのエージェントからアクションとして呼び出す仕組みのことです。 そこでここでは、Agentforce MCPで外部ツールを呼ぶまでの3ステップを、どこで設計判断が入るかという視点で整理します。

Agentforce MCPの導入で決めるのは接続の手順ではなく、どのMCPサーバーを登録し、どのツールまで許可し、追加後に誰が結果を確かめるかという運用の設計です。

ステップ①どのMCPサーバーを登録対象にするかを決める

最初に決めるのは、どのMCPサーバーを登録の対象にするかです。Salesforceは2025年6月23日の公式ブログで、2025年7月リリースにおいてネイティブのMCPクライアントをパイロットとして提供すること、あわせてセキュリティポリシーを適用するためのMCPサーバーレジストリを用意することを説明しています。

登録先を選ぶときは、提供元が誰なのかを先に確認しましょう。外部MCPサーバーには、接続先のシステムの提供元が自ら用意しているものと、第三者が公開しているものが混在します。第三者が公開しているサーバーを登録すると、接続先の仕様が変わったときに、こちら側と接続先のどちらにも問い合わせ先がない状態になりかねません。

この商社の場合、物流部門が契約した配送管理のSaaSは提供元がMCPサーバーを用意していた一方、基幹システムには用意がありませんでした。そこで、配送管理のSaaSは提供元のサーバーを登録対象とし、基幹システムは別の方式で接続する方針に分けたのです。

登録の候補が複数あるときは、接続先の提供元が公開しているサーバーを優先し、第三者製は仕様変更の連絡を受け取れる相手に限って対象にします。

※参考記事はこちら

ステップ②許可するツールの粒度を誰が決めるかを先に置く

次に決めるのは、登録したMCPサーバーが公開しているツールのうち、どこまでをエージェントに使わせるかという範囲と、その範囲を誰が判断するかです。1つのMCPサーバーが複数のツールを公開している場合、参照だけのツールと更新まで行うツールが同じサーバーに含まれることがあります。

サードパーティ製のMCPサーバーは、Agentforce Registryへ登録したうえで、エージェントに使わせるサーバーのツールを許可リストに登録すると公式ヘルプに記載されており、許可はツール単位で行います。認証にはOAuth 2.1のクライアントクレデンシャルフローが用意され、登録内容の編集・削除やリスクスコアの確認も登録の管理に含まれます。ただしリスクスコアが何をどう採点するのかは、2026年8月12日時点で確認できていません。

確認できていない部分がある以上、実務では機能に頼らず、許可の可否を判断する担当を先に決めておくほうが確実です。この商社では、参照のみのツールは情報システム部門の判断で追加してよく、更新を伴うツールは業務部門の管理者の承認を必要とする、という2段階の運用を先に文書化しました。

更新を伴うツールが1つも含まれないサーバーであれば、この2段階の承認までは置かずに進められます。

ステップ③アクションとして追加した後の検証手順を決める

最後に決めるのは、MCPツールをエージェントのアクションとして追加したあとに、誰がどう結果を確かめるかという手順です。追加した直後は動いていても、接続先の仕様変更や権限の変更で、返る値が変わることがあります。

検証の対象は2つに分かれ、1つはエージェントが依頼に対して正しいツールを選べているかで、もう1つは選ばれたツールが返す値が業務で使える内容かどうかです。前者はSalesforce側の設定で改善できますが、後者は接続先の担当者に確認しないと判断できません。

この商社では、配送管理のSaaSのツールを追加した際、営業がよく使う10種類の依頼文を用意し、月に一度その文面で結果を確かめる手順を決めました。手順を決めたのは追加の前で、確認する人も物流部門の担当者と情報システム部門の担当者の2名を指名しています。

以上が、Agentforce MCPで外部ツールを呼ぶまでの3ステップでした。3つの工程のうち、後から変更が難しいのは登録するサーバーの選定で、許可の範囲と検証の頻度は稼働後にも見直せます。

Agentforceを外部から呼び出す3つの経路

ここまでは、Agentforceが外部のツールを呼びに行く向きを扱ってきました。実務ではその逆に、社内の別システムや外部のAIアシスタントからAgentforceを呼び出したい場面も出てきます。そこでここでは、Agentforceを外部から呼び出す3つの経路を整理していきます。

外部から呼び出す経路は、自社アプリから会話を開始するAgent API・チャネルに公開するAgentforce Connections・MCPツールとして公開するホスト型MCPサーバーの3つに分かれます。

経路①REST APIで会話を開始するAgent API

1つ目の経路は「REST APIで会話を開始するAgent API」です。Agent APIは、Agentforceのエージェントに対してREST（Representational State Transfer）形式のAPI（アプリケーションプログラミングインターフェース）でアクセスする仕組みで、公式ドキュメントには、組織内のAIエージェントへメッセージを送ってトピックとアクションを利用するためのAPIだと説明されており、セッションを開始して会話を続ける操作は、公式のTrailheadモジュールで案内されています。

用語で注意したいのは、公式ドキュメントでの表記が「Agent API」である点です。日本語の記事では「Agentforce API」と書かれていることがあるため、社内で仕様を共有するときは公式の表記に合わせておくほうが混乱を避けられます。

この経路が向くのは、自社のポータルサイトや業務アプリの画面に、Agentforceの会話を組み込みたい場合です。この商社でも、取引先向けのポータルに納期照会の会話を載せる案が出ていました。なお、Agent APIの提供段階については、一次情報で記載を確認できていません。

経路②チャネルに公開するAgentforce Connections

2つ目は、エージェントを公開するチャネルを追加するAgentforce Connectionsです。Agentforce Builderで公開先の接続を設定する仕組みで、公式ヘルプにはLightning Experienceとモバイル・Slack・enhanced chat・メッセージング・サービスメール・パートナーテレフォニーが公開先として挙げられています。

APIで組み込む方法と違うのは、こちら側でアプリを作らなくてよいことです。すでに社員が毎日使っているチャネルにエージェントを出せるため、新しい画面を覚えてもらう必要がありません。利用者が増えない原因が画面の切り替えにある場合は、この経路を先に検討する価値があります。

この商社では、営業がSlackで日々のやり取りをしていたため、在庫と納期の照会をSlackから使えるようにする案が検討されました。Slackでの公開手順とできることの範囲は、ほか記事「Agentforce in Slackとは｜できること・導入手順とBox for Agentforceの位置づけ」で詳しく解説しています。なお、Agentforce Connectionsの提供段階も、一次情報では記載を確認できていません。

経路③MCPツールとして公開するホスト型MCPサーバー

3つ目の経路は、Salesforce側が用意するホスト型MCPサーバー（Salesforce Hosted MCP Servers）を通じて、自社のエージェントを外部のAIアシスタントから呼べるようにする方法です。2026年4月29日の公式ブログで、Enterprise Edition以上のすべての組織で使える正式提供に移行したことが発表されています。

AgentforceのエージェントやPrompt BuilderのテンプレートをMCPツールとして公開し、外部のAIアシスタントから呼び出せることも公式ドキュメントに記載されています。

ここで重要な制約が1つあり、MCPツールとして公開できるのは、新しいAgent Script Builderで作成したエージェントだけで、それ以前のビルダーで作ったエージェントはアップグレードが必要だと公式ドキュメントに明記されています。既存のエージェントをそのまま外部へ公開できる前提で計画を立てると、着手の段階で作り直しが発生します。

外部からAgentforceを呼び出す経路は、この3つに整理できます。

※参考記事はこちら

※エージェントをMCPツールとして公開する条件の参考記事はこちら

Agentforceの委譲先を決めるときの3つの設計点

前章では、外部からAgentforceを呼ぶ3つの経路を整理しました。ここまでの経路はいずれも、決められた処理を実行するツールとしてのやり取りが中心でしたが、判断の部分を別のエージェントに任せたい場面もあります。そこでここでは、Agentforceの委譲先を決めるときの3つの設計点を解説します。

判断ごと別のエージェントに任せる場合は、接続の設定よりも、委譲先に付ける説明文と受け渡す変数の指定が動作を左右します。

設計点①委譲先を別のエージェントとして接続する

1つ目の設計点は、委譲先を同じ組織内の別のエージェントとして接続することです。Agentforce Builderでは、Explorerパネルの「+」から「Connect Agent as Subagent (Beta)」を選び、接続したエージェントに委譲の判断で使われる説明文を設定します。

この仕組みはConnected Subagentsと呼ばれ、Multi-Agent Orchestrationとして案内されています。提供段階については、公式ドキュメントに「pilot or beta service」と記載されており、パイロットかベータかは特定されていません。本番の業務を全面的に載せる前提で計画するのであれば、提供段階の変化を確認しながら進める必要があります。

この商社では、返品と交換の判断をカスタマーサポート部門のエージェントに任せ、営業向けのエージェントは依頼の受け渡しだけを担う構成を検討していました。人へ引き継ぐ設計との違いは、ほか記事「Agentforce Service Agentとは？チャットボットとの違いと導入設計を解説【2026年最新】」で扱っているエスカレーションの考え方とあわせて整理すると分かりやすくなります。

設計点②説明文の書き方で振り分け先が決まる

2つ目に決めるのは、委譲先に付ける説明文です。Agent Scriptのconnected_subagentブロックには、name・target・label・description・loading_text・inputsという項目があり、このうちdescriptionが振り分けの判断に使われると公式ドキュメントに記載されています。targetは接続時に自動で入る接続先のURIです。

この記述のとおり、どの依頼をどちらのエージェントへ回すかは、接続の設定よりも説明文の書き方で決まります。説明文が抽象的だと、本来は自分で処理すべき依頼まで委譲先へ渡ってしまい、限定しすぎると、任せたい依頼が手元に残ります。

この商社では、当初「顧客からの問い合わせ対応」という説明文を付けていたため、在庫の照会までカスタマーサポート部門のエージェントへ渡っていました。説明文を「返品・交換の可否判定と手続きの案内」に書き直したところ、振り分けが想定どおりになったのです。

説明文は、任せたい業務だけを名指しし、任せない業務の名前は入れないという書き方にしておきましょう。

※参考記事はこちら

設計点③受け渡す変数を明示的に指定する

3つ目の設計点は、委譲先へ受け渡す変数を明示的に指定することです。connected_subagentブロックのinputsで、どの値を渡すかを指定します。

変数の指定は、渡し忘れよりも渡しすぎのほうが問題になりやすい項目です。会話の内容をまとめて渡してしまうと、委譲先のエージェントが本来必要としない顧客情報まで受け取ることになります。委譲先が別部門の運用であれば、その部門が扱ってよい情報の範囲も別に決まっているはずです。

この商社では、返品の判定に必要なのは注文番号と商品の品番、そして返品の理由だけでした。会話全体を渡す設定から、この3つだけを渡す設定に変更したところ、委譲先が参照する情報の範囲を業務部門の管理者へ説明できるようになったのです。

渡す変数は、委譲先の業務に必要な最小限で指定しましょう。以上が、Agentforceの委譲先を決めるときの3つの設計点でした。

Agentforceの外部連携4方式の使い分け

ここまで、外部のツールを呼ぶ向き・外部から呼ばれる向き・別のエージェントに委譲する場合と、3つの章に分けて手段を整理してきました。実際の設計では、これらを1枚に並べて比べたほうが選びやすくなります。そこでここでは、Agentforceの外部連携4方式の使い分けを整理していきます。

なお「向いている場面」の列は、本記事が設計上の判断として整理したもので、Salesforceが推奨として示している内容ではありません。管理単位のうち、External Servicesの管理単位は一次情報で確認できていないため、未確認と記載しています。

4方式の選択は、呼ぶ相手が誰かと、接続を何の単位で管理したいかで決まります。

使い分け①外部のツール群を呼ぶ場合はMCP

1つ目の使い分けは、外部システムが複数のツールをまとめて公開している場合です。この状況では、接続先の単位で登録してツールを追加していけるMCPが選びやすくなります。

なぜこの状況でMCPが選びやすいのかというと、ツールが追加されるたびに接続の定義を作り直す必要がなく、登録済みのサーバーが公開しているツールから使うものを増やす形で進められるからです。接続先の提供元が機能を頻繁に追加する場合、この差は運用の作業量に直結します。

この商社が例に挙げた配送管理のSaaSは、提供元が四半期ごとに機能を追加していました。出荷状況の照会だけを使う予定でしたが、後から配送予定日の変更や伝票の再発行も使う想定があったため、サーバー単位で登録できる方式のほうが適していると判断したのです。

逆に、使うツールが1つに決まっていて追加の予定がないのであれば、次に挙げる方式のほうが手数は少なくなります。

使い分け②仕様が定まったAPIを叩く場合はExternal Services

2つ目は、呼びたいAPIが1つに決まっていて、その仕様が安定している場合です。Salesforceの公式ブログでは、Spring ’25リリース以降、フローやApexのラッパーを作らずに、External Servicesのオペレーションをそのままエージェントのアクションとして呼べるようになったと説明されています。

この方式が向くのは、相手側のAPIが社内の別システムで、仕様書がすでに整備されているケースです。呼び出しの定義を一度作れば、しばらく手を入れずに使い続けられます。

この商社の基幹システムには、受注と在庫を照会するAPIが以前から用意されており、仕様はここ数年変わっていませんでした。MCPサーバーの提供もなかったため、この経路で接続する方針にしています。なお、External Servicesをエージェントアクションとして使う機能の提供段階と、接続の管理単位については、一次情報で確認できていません。

※参考記事はこちら

使い分け③外部アプリから会話させる場合はAgent API

3つ目は、社外のアプリや自社のポータルから、Agentforceの会話を直接利用させたい場合です。この場合はAgent APIを使い、セッションを開始してメッセージをやり取りする形になります。

ここまでの2つと違うのは、呼ぶ側と呼ばれる側が反対になる点です。MCPとExternal Servicesは、Agentforceが外の処理を呼びに行く方式でしたが、Agent APIは外のアプリがAgentforceを呼びます。設計の中心も、どの処理を許可するかという話から、どの利用者に会話を開かせるかという認証の話に移ります。

この商社が検討していた取引先向けポータルの納期照会もこの方式に当たりますが、取引先の担当者は自社の社員ではないため、誰の権限で会話が動くのかを先に決める必要があり、社内利用の整備を終えてから着手する順番にしています。

使い分け④判断ごと任せる場合はConnected Subagents

4つ目は、処理の実行よりも判断の部分を、同じ組織内の別のエージェントに任せたい場合です。この場合はConnected Subagentsを使い、委譲先のエージェントに説明文と受け渡す変数を設定します。

判断ごと任せる構成が向くのは、その領域の知識と運用ルールが別部門にあり、こちらでは条件を保守できない業務です。逆にいえば、条件が数個で自部門だけで決められる業務であれば、委譲の仕組みを使わずに自分のエージェントで処理するほうが、確認も改善も速く進みます。

ただしConnected Subagentsは、公式ドキュメントの表記どおり2026年8月時点で正式提供前の位置づけにあります。この商社でも、返品の判定を委譲する構成を本番へ全面的に適用せず、限定した対象での検証から始める計画にしました。

外部連携の4方式は、ここまでの条件で選び分けられます。

Agentforceの境界を引き直した後の3つの場面

前章で4方式の使い分けを整理しましたが、方式が決まっただけでは、現場の担当者にとって何が変わるのかが伝わりません。記事の冒頭で挙げた3つの状況が、境界を引き直したあとにどう変わるのかを、業務の流れで確認しておく必要があります。そこでここでは、Agentforceの境界を引き直した後の3つの場面を解説します。

境界を引き直した効果は、エージェントが答えられる項目の多さよりも、担当者が別の人に確認しなくてよくなった項目の数に表れます。

場面①在庫の照会が担当者への確認を挟まずに返る

1つ目の場面は、営業が顧客と話しながら在庫を照会したときに、受注管理の担当者へ確認せずに数量が返るようになった状態です。基幹システムの照会APIをExternal Servicesとして接続し、エージェントのアクションから呼ぶ構成に変えたことで、参照の経路が1本につながりました。

ここで変わったのは、答えが返る速さだけではありません。以前は営業が内線をかけ、受注管理の担当者が画面を開いて調べ、口頭で伝えるという3つの工程を挟み、回答までに数時間かかっていました。この工程がなくなったことで、受注管理の担当者は割り込みの問い合わせに時間を使わずに済むようになったのです。

ただし仕入単価のように、営業が参照してよいかどうかを基幹システム側で判定する項目は、内側に持ってきていません。依頼した営業の権限で判定される経路を保ったまま、参照できる項目だけが返る構成にしています。

ただし、この経路で返せるのは基幹システムが即時に応答できる項目だけで、集計を伴う照会は同じようには返りません。

場面②出荷状況の確認が物流SaaS側で完結する

2つ目は、1日に何十件と積み上がっていた物流部門への問い合わせを挟まずに、納期を聞かれた営業が出荷状況を確認できるようになった場面です。配送管理のSaaSが提供するMCPサーバーを登録し、出荷状況の照会ツールだけを許可すると、営業の依頼はそのままSaaS側の照会へつながるようになりました。

この構成で重要なのは、出荷状況の管理はSaaS側に残していることです。伝票の状態を判断する条件も、更新の手順も物流部門の運用にあり、Agentforce側には条件を持ち込んでいません。物流部門が運用を変えたときに、情報システム部門が設定を追いかけて直す作業も発生しなくなりました。

一方で、配送予定日の変更のように更新を伴うツールは、この段階では許可していません。更新を伴うツールを追加するかどうかは、業務部門の管理者の承認を必要とする運用にしてあり、必要になった時点で改めて判断する形にしています。

場面③CS部門のAIに引き継いだ会話が営業側に残る

3つ目の場面は、返品や交換の依頼をカスタマーサポート部門のエージェントへ委譲しても、そのやり取りの結果が営業側の会話に残るようになった状態です。委譲先を接続し、注文番号と品番、返品の理由の3つだけを渡す設定にしたところ、依頼と結果が1つの会話の中でつながりました。

以前は、営業が顧客から交換の進捗を聞かれるたびにサポート部門へチャットで確認し、顧客は同じ説明を二度求められていました。委譲の構成に変えてからは、営業が自分の会話の履歴で状況を確認できるようになっています。

ただし、この構成に使うConnected Subagentsは2026年8月時点で正式提供前の位置づけにあり、限定した対象での検証から始めています。全社の返品対応をこの構成に載せる判断は、提供段階の変化を確認してから行う計画です。

以上が、Agentforceの境界を引き直した後の3つの場面でした。3つに共通しているのは、担当者が別の人に確認する工程が減った点であり、エージェントが扱える機能が増えた点ではありません。

Agentforce MCP周辺で分かれる3つの提供段階

ここまでの内容は、どの方式を選ぶかという設計の話でした。ただし実際に本番へ載せる判断をするには、その機能がいまどの提供段階にあるのかを分けて確認する必要があります。そこでここでは、Agentforce MCP周辺で分かれる3つの提供段階を、確認できた出典とあわせて整理していきます。

いずれの行も2026年8月12日に確認した内容で、提供段階の記載を確認できなかった機能については、正式提供とも正式提供前とも判断していません。

MCPの提供段階は接続する側と公開される側で別々に進んでおり、正式提供に移行しているのは公開される側のホスト型MCPサーバーです。

段階①外部MCPサーバーへ接続する側は正式提供前

まず、Agentforceが外部のMCPサーバーへ接続する側です。2025年6月23日の公式ブログには、2025年7月リリースでネイティブのMCPクライアントをパイロットとして提供すると明記されています。

その後の段階については、2026年8月12日に検索した範囲では、外部MCPサーバーへの接続が正式提供へ移行したことを示す一次情報を確認できませんでした。パイロットのまま提供が続いているのか、ベータへ移行したのかも、公式の記載としては確かめられていません。

この商社では、外部MCPサーバーへの接続を使う範囲を、配送管理のSaaSの参照系ツールだけに絞りました。正式提供が確認できていない段階では、業務が止まったときに手作業へ戻せる範囲で使うほうが安全だと判断したためです。更新を伴うツールについては、提供段階を確認できた時点で改めて検討するという合意を、物流部門との間で先に取り交わしています。

正式提供前の機能で業務を止めないためには、同じ処理を人が実行する手順書を、接続を作る前に用意しておく必要があります。

段階②ホスト型MCPサーバーは正式提供に移行している

次に、Salesforce側がMCPサーバーを公開する側です。2025年10月9日の公式ブログでベータ提供が案内され、2026年4月29日の公式ブログで、Enterprise Edition以上のすべての組織を対象とした正式提供への移行が発表されています。

標準サーバーにはAgentforce 360 Platform・Tableau Next・Data 360 SQLなどがあり、フローやApexアクションを対象にしたカスタムサーバーも用意されました。2026年6月8日の公式ブログでは、Summer ’26の時点で標準サーバーとカスタムサーバーが正式提供である一方、Salesforce DX MCP ServerとMetadata API Context MCP Serverはベータ、Data 360 MCP Serverは開発者プレビューと、サーバーごとに段階が分かれることも案内されています。

同じ「MCPサーバー」という言葉でも、対象によって提供段階が異なる点は、社内で計画を共有するときに誤解を生みやすい部分です。どのサーバーを使うのかを名前まで特定してから、提供段階を確認しましょう。

※参考記事はこちら

※ベータ提供が案内された時点の参考記事はこちら

段階③Connected Subagentsは正式提供前の位置づけ

3つ目は、別のエージェントへ判断を委譲するConnected Subagentsです。公式ドキュメントには「Multi-Agent Orchestration (connected subagents) is a pilot or beta service」と記載されており、パイロットとベータのどちらであるかは特定されていません。Agentforce Builderの操作画面では接続の項目が「Connect Agent as Subagent (Beta)」と表示され、公式ヘルプの項目名も「Multi-Agent Orchestration (Beta)」です。

日本語の記事のなかには、この機能がすでに正式提供になったと書いているものもあります。ただし公式ドキュメントの記載は2026年8月12日時点で正式提供前を示しており、本記事はその記載に合わせています。名称についても、公式表記はMulti-Agent OrchestrationとConnected Subagentsであり、これ以外の呼び方は一次情報で確認できていません。

正式提供前の機能を業務計画に組み込む場合は、その機能が使えなくなったときの代替手段を決めておきましょう。Agentforce MCP周辺の提供段階は、この3つに分かれています。

Agentforce MCPが向かない3つのケース

前章では、機能ごとに提供段階が分かれている状況を確認しました。接続先が複数あり、使うツールを随時足していく前提の組織であれば、MCPを使う構成は効果が出やすいといえます。逆に接続先が1つで仕様も固定されているのであれば、方式を変える理由は見当たりません。そこでここでは、Agentforce MCPが向かない3つのケースを解説していきます。

MCPが向かないのは、既存の連携が安定している場合・実行する人の権限を絞り切れていない場合・旧ビルダーで作ったエージェントを公開したい場合の3つです。

ケース①既存の連携がすでに安定して動いている

1つ目のケースは、いま動いている連携がすでに安定していて、担当者から不満が出ていない場合です。接続先が1つで、呼び出す処理も決まっており、仕様が何年も変わっていないのであれば、方式を変える理由がありません。

方式の変更には、接続の作り直しだけでなく、権限の再設計と検証の手順づくりが伴います。安定して動いている連携をわざわざ載せ替えると、これらの作業が発生する一方で、担当者の業務は変わりません。

この商社でも、会計システムとの請求データの連携は10年以上同じ仕組みで動いており、担当者からの要望も出ていませんでした。この連携は対象から外し、営業が毎日困っている在庫と出荷の照会だけに範囲を絞っています。連携を広げない判断の考え方は、ほか記事「中小企業のAgentforce導入ガイド｜向く理由・成果の出る業務・費用」をご確認ください。

ケース②実行ユーザーの権限を絞り切れていない

2つ目は、Salesforce側の権限設計がまだ整理されていない場合です。2026年4月29日の公式ブログには、ホスト型MCPサーバー経由のすべてのトランザクションが認証済みユーザーとして実行され、既存のCRUD（作成・参照・更新・削除）・項目レベルセキュリティ・共有ルールがそのまま適用されると記載されています。

この仕組みは、権限が整理されている組織にとっては安心材料になります。一方で、権限が広めに設定されたままの組織では、その広さがそのまま外部からの操作範囲になるという意味でもあります。

この商社では、営業のプロファイルに過去の運用で付いたままの参照権限が残っていました。接続の検討を止めて権限の整理を先に行い、参照できる項目を業務に必要な範囲まで戻してから、接続の設計に戻っています。棚卸しの対象を、外部から呼び出す処理が触れるオブジェクトと項目に絞ったため、整理は10日ほどで終わりました。

権限の整理が終わっていない組織では、接続の方式を検討するよりも、まず参照範囲の棚卸しから着手しましょう。

ケース③旧ビルダーのエージェントを外部に公開したい

3つ目のケースは、以前のビルダーで作ったエージェントを、そのままMCPツールとして外部に公開したい場合です。公式ドキュメントには、MCPツールとして公開できるのは新しいAgent Script Builderで作成したエージェントだけで、それ以前のエージェントはアップグレードが必要だと明記されています。

この制約があるため、すでに稼働しているエージェントを外部のAIアシスタントから呼ばせたい場合、公開の設定を行う前にアップグレードの計画が必要になります。稼働中のエージェントを作り直す作業には、テストと再承認の期間も含まれます。

この商社が営業向けに最初に作ったエージェントも、以前のビルダーで作成したものでした。外部公開は当面の目的ではなかったため、アップグレードは急がず、新しく作るエージェントから新しいビルダーを使う方針にしています。

アップグレードの計画は、テストと再承認の期間を含めて、外部に公開したい時期から逆算して置くことになります。以上が、Agentforce MCPが向かない3つのケースです。

Agentforceの外部連携で発生する3種類のコスト

向かないケースを確認したうえで、それでも接続を増やす判断をするのであれば、次に見ておきたいのが費用がどこに立つかという点です。ライセンスの金額とは別に、接続を増やすことで発生する負担があり、その多くは情報システム部門と業務部門のどちらが持つのかが決まっていません。そこでここでは、Agentforceの外部連携で発生する3種類のコストを整理していきます。

接続を増やすときの費用は、ライセンスよりも権限設計の初期工数・接続先の改修・提供段階が変わったときの作り直しに立ちます。

コスト①接続先ごとに権限を設計する初期工数

1つ目は、接続先ごとに権限を設計する初期工数です。接続を1つ追加するたびに、誰がその処理を実行してよいか、どの項目まで返してよいか、認証情報を誰が管理するかを決める作業が発生します。

この工数は、接続の技術的な作業よりも、関係者との合意に時間がかかる部分です。参照範囲を決めるには業務部門の管理者の判断が要り、認証情報の管理には情報システム部門の運用ルールが関わります。接続の数が増えるほど、この調整は接続先ごとに繰り返されます。

この商社では、配送管理のSaaSへの接続を検討する際、許可するツールの範囲を決める打ち合わせを物流部門と3回行いました。技術的な接続の確認は短時間で終わりましたが、更新を伴うツールをどう扱うかの合意に時間がかかったのです。

初期工数の見積もりは、接続の作業量よりも、判断に関わる部門の数で見ておきましょう。ライセンス費用の内訳は、ほか記事「Agentforce料金・ライセンス完全ガイド｜Flex Credits・従量課金・ユーザーライセンスの違いを解説【2026年最新】」で整理しています。

コスト②基幹システム側で発生する改修の負担

2つ目は、接続される側、つまり基幹システムやSaaS側で発生する負担です。エージェントから呼べるようにするために、相手側でAPIの追加や権限の設定変更が必要になる場合があり、その費用は接続する側の予算に入っていないことがほとんどです。

負担が問題になりやすいのは、基幹システムの保守を外部のベンダーに委託しているケースです。改修の依頼は見積もりから始まり、対応の時期も相手側の開発計画に左右されます。Salesforce側の準備が終わっていても、相手側の対応が数か月先になることは珍しくありません。

この商社の基幹システムには照会APIが用意されていたため大きな改修は不要でしたが、返す項目に仕入単価を含めるかどうかで設定の変更が必要になりました。この変更は保守ベンダーへの依頼となり、費用を情報システム部門と購買部門のどちらが持つかを先に決める必要があったのです。

接続の計画を立てるときは、相手側の改修費用を誰の予算で持つかを、見積もりを取る前に決めておきましょう。

コスト③提供段階が変わったときに発生する作り直し

3つ目は、使っている機能の提供段階が変わったときに発生する作り直しです。正式提供前の機能は、正式提供に移行する過程で仕様や設定項目が変わることがあり、その場合は設定の見直しと再テストが必要になります。

この費用は事前に金額を見積もれない性質のものですが、発生する範囲は先に決められます。正式提供前の機能を使う対象を限定しておけば、変更が生じたときに直す範囲もその対象にとどまります。

この商社では、Connected Subagentsを使う対象を返品と交換の依頼だけに限定しました。仕様が変わったとしても、直すのはこの1業務の設定と手順書だけで済み、営業全体の業務は止まらないという整理です。

正式提供前の機能を使う範囲は、変更が起きたときに直せる分量で区切っておきましょう。外部連携で発生するコストは、この3種類に整理できます。

Agentforceの外部連携で先に決める3つの前提

前章では、接続を増やしたときに費用がどこへ立つかを整理しました。費用の所在が見えてくると、次に必要になるのは、接続を作り始める前に社内で決めておく事項です。決めないまま接続だけを増やすと、あとから許可の可否や認証情報の管理者をさかのぼって整理することになります。そこでここでは、Agentforceの外部連携で先に決める3つの前提を確認していきます。

接続を作る前に決めておきたいのは、許可の範囲を判断する担当・認証情報の管理者・結果を検証する手順の3つです。

前提①許可するツールの範囲を決める担当を置く

1つ目の前提は、どのツールまでエージェントに使わせるかを判断する担当を置くことです。許可できる範囲は、先に触れたAgentforce Registryのツール単位の許可リストで指定できます。ただしリスクスコアの採点方法までは確認できていないため、どこまでを機能に任せられるかは判断できません。

機能で絞れる範囲が確認できていない以上、判断する人を先に決めておく意味は大きくなります。参照だけのツールと更新を伴うツールで承認者を分けておけば、機能の仕様が明らかになったあとも、その運用に当てはめて設定できます。

この商社では、許可の判断を情報システム部門の担当者1名と、業務部門の管理者3名の計4名で行う体制にしました。参照のみのツールは情報システム部門の判断で追加してよく、更新を伴うツールは対象の業務部門の管理者が承認する、という2段階です。

担当を置けているかどうかは、新しいツールを1つ追加したいと言われたときに、誰に相談すればよいかを即答できるかで確かめられます。

前提②接続先ごとの認証情報の管理者を決める

2つ目に決めるのは、接続先ごとの認証情報を誰が管理するかです。2026年4月29日の公式ブログのとおり、ホスト型MCPサーバー経由の処理は認証済みユーザーとして実行されますが、その認証情報を誰が保管し、いつ更新するのかまでは、接続を作る側で決めておく必要があります。

あわせて把握しておきたいのが、Agentforceの実行には利用者が画面上で操作して動かすユーザーコンテキストと、システムが自律的に動かすシステムコンテキストの2つがあり、どちらで動いているかによって実行の主体が変わる点です。夜間の一括処理のようにシステム側が動かす処理では、誰の権限で動くのかを設計時に決めておく必要があります。

この商社では、営業が使う照会は依頼した本人の権限で動く構成にし、夜間に動く集計だけを専用のユーザーで実行する構成に分けました。専用のユーザーの権限は情報システム部門が管理し、四半期ごとに参照範囲を確認する運用にしています。

なお、開発者がIDEからMCPを使う場面は、業務用のエージェントの接続とは管理の対象が別になります。開発側の使い方は、ほか記事「Agentforce Vibesとは｜使い方・料金・対応IDEをわかりやすく整理」をご参照ください。

前提③外部に渡した処理の結果を検証する手順を持つ

3つ目の前提は、外部に渡した処理の結果を、定期的に検証する手順を持つことです。接続を作った直後は担当者が結果を確認しますが、確認を続ける仕組みがないと、数か月後に値が変わっても気づけません。

検証の手順で決めておきたいのは、確認する頻度・使う依頼文・確認する人の3つです。依頼文をあらかじめ決めておけば、確認する人が交代しても同じ基準で比べられます。接続先の仕様変更があったときも、同じ依頼文で結果を比較すれば、変化した箇所を特定できます。

この商社では、営業がよく使う10種類の依頼文を接続先ごとに用意し、月に一度、物流部門と情報システム部門の担当者が結果を確認する手順にしました。確認の記録は同じ場所に残し、値が変わっていた場合は接続先の提供元へ問い合わせる流れまで決めています。

仕様変更に気づくまでの日数は確認の間隔がそのまま上限になるため、月に一度の確認であれば、最長で1か月は誤った値を返し続けることになります。以上が、Agentforceの外部連携で先に決める3つの前提でした。

Agentforceの連携設計を回す3つの役割

ここまで、境界の決め方から接続方式の選び方、提供段階の区別、費用の所在と先に決めておく前提までを整理してきました。ここまでの内容を情報システム部門の担当者が1人で担うことはできず、実際には立場の違う担当が分担して進めることになります。誰がどこを担うのかが決まっていない状態では、境界を決める議論が始まりません。そこでここでは、Agentforceの連携設計を担う3つの役割を整理していきます。

連携設計が進むかどうかは技術力よりも、業務の境界を決める人・接続先の権限を管理する人・提供元と調整する人の3つがそろっているかで決まります。

役割①業務の境界を決める業務側の担当

1つ目は、どこまでを自部門のエージェントに残し、どこから外へ渡すかを決める業務側の担当です。この判断には、業務の手順と例外の扱いを把握していることが求められるため、情報システム部門では代わりに決められません。

この役割が空いていると、接続の検討は技術的な可否の話だけで進み、稼働したあとで業務に合わないことが分かります。業務部門の管理者が最初の打ち合わせから参加しているかどうかで、その後の手戻りの量は大きく変わります。

この商社では、営業企画の課長がこの役割を担いました。どの照会を営業に開放し、どの判定をカスタマーサポート部門へ委ねるかを決め、部長への説明も同じ担当が行っています。判断の記録を1つの資料にまとめていたため、後から加わった担当者も経緯を追えました。

業務側の担当を決めるときは、その業務の例外対応を説明できる人を選びましょう。

役割②接続先の権限を管理する情報システム側の担当

2つ目の役割は、接続先ごとの権限と認証情報を管理する情報システム側の担当です。誰の権限で処理が動くのか、認証情報をどこに保管し、いつ更新するのかを決めて維持します。

この役割で難しいのは、接続を作る作業よりも、作ったあとの管理を続けることです。接続の数が増えるほど、使われていない接続や、検証のまま残っている接続が生まれます。四半期ごとに一覧を確認する運用を担当者に割り当てておかないと、棚卸しは後回しになります。

この商社では、情報システム部門の3名のうち1名がこの役割を専任で担当しました。接続の一覧と認証情報の管理者、参照範囲の3つを1つの表で管理し、四半期ごとに更新しています。担当者に必要な知識の水準を測る目安としては、ほか記事「【2026年最新】Agentforceスペシャリスト資格の試験概要や勉強法」で扱っている資格の出題範囲が参考になります。

役割③外部システムの提供元と調整する担当

3つ目は、基幹システムの保守ベンダーやSaaSの提供元と調整する担当です。相手側の改修が必要になったときの依頼、仕様変更の連絡の受け取り、費用の負担についての交渉を担います。

この役割は社内の3者だけでは完結しません。基幹システムの担当者にとって、AIエージェントからの接続は自分たちの業務に直接の利益がないことも多く、依頼の優先順位は上がりにくくなります。相手側にとっての負担と得られるものを整理して伝えられる担当がいるかどうかで、対応の時期は変わります。

この商社では、基幹システムの運用を長く担当してきた社員がこの役割に就きました。保守ベンダーとの関係も、改修の見積もりの読み方も分かっていたため、返す項目の変更を1か月で反映できています。

以上が、Agentforceの連携設計を担う3つの役割でした。3つの役割を社内でそろえられない場合は、外部の支援を組み合わせる選択もあります。支援会社の選び方は、ほか記事「Agentforce導入支援会社のおすすめ8選｜失敗しない選び方と7つの見極め方【2026年最新】」で整理していますので、あわせてご確認ください。合同会社クロスコムでも、Agentforce導入定着支援サービスとして、境界の決め方から接続先ごとの権限設計までをご相談いただけます。

【一問一答】Agentforce MCPに関するよくある質問

前章までで、Agentforceの境界の決め方から、接続方式の選び分け、社内での役割分担までを一通り整理してきました。設計を進める段階では、エディションの条件や提供段階、権限の効き方といった前提の確認が、あらためて必要になります。とくに提供段階については、日本語の情報のなかに一次情報と食い違うものも見られるため、確認できた範囲を明示しておきます。そこでここでは、Agentforce MCPに関するよくある質問へ一問一答の形式でお答えします。

質問①Agentforce MCPの利用にエディションの条件はあるか

公開する側のホスト型MCPサーバーについては、2026年4月29日の公式ブログに、Enterprise Edition以上のすべての組織で使える正式提供と記載されています。一方で、外部のMCPサーバーへ接続する側のエディション要件は、2026年8月12日時点で一次情報から確認できていません。自社の契約で使えるかどうかは、Salesforceの担当者に直接ご確認ください。

質問②Agentforce MCPは正式提供されているのか

接続の向きによって分かれます。公開する側のホスト型MCPサーバーは2026年4月29日に正式提供へ移行しています。外部のMCPサーバーへ接続する側は、2025年7月リリースの時点でパイロットと案内されており、その後に正式提供へ移行したことを示す一次情報は確認できていません。判断をするエージェントを接続するConnected Subagentsは、公式ドキュメントに「pilot or beta service」と記載されています。

質問③Agentforce MCPで接続したツールに権限は効くか

ホスト型MCPサーバー経由の処理については、すべてのトランザクションが認証済みユーザーとして実行され、既存のCRUD・項目レベルセキュリティ・共有ルールがそのまま適用されると公式ブログに記載されています。あわせて、利用者が操作して動かすユーザーコンテキストと、システムが自律的に動かすシステムコンテキストで実行の主体が変わる点も確認しておきましょう。外部のMCPサーバー側でどう権限が扱われるかは、相手のシステム次第になります。

権限が効くかどうかは、その処理が誰の資格情報で実行されるのかを、接続の向きごとに確認して判断します。

質問④Agentforce MCPの代わりにExternal Servicesを使う場面はあるか

あります。Salesforceの公式ブログでは、Spring ’25リリース以降、フローやApexのラッパーを作らずにExternal Servicesのオペレーションをエージェントのアクションとして呼べると説明されています。呼びたいAPIが1つに決まっていて仕様も安定しているのであれば、こちらのほうが選びやすくなります。なお、この機能の提供段階については一次情報で確認できていません。

質問⑤Agentforce MCPで自社のエージェントを外部に公開できるか

公開できます。ただし公式ドキュメントには、MCPツールとして公開できるのは新しいAgent Script Builderで作成したエージェントだけで、それ以前のビルダーで作ったエージェントはアップグレードが必要だと明記されています。すでに稼働しているエージェントを公開する計画であれば、アップグレードの期間とテストの工数を先に見込んでおきましょう。

質問⑥Connected Subagentsは本番運用に使えるか

公式ドキュメントには「Multi-Agent Orchestration (connected subagents) is a pilot or beta service」と記載され、Agentforce Builderの操作画面でも「Connect Agent as Subagent (Beta)」と表示されます。パイロットとベータのどちらであるかは特定されていないため、正式提供前として扱うのが安全です。全社の業務を載せる前に、限定した対象での検証から始めることをおすすめします。

エージェントの境界を決めてから、外部との接続方式を選ぶ

Agentforceを複数のシステムとつなぐ設計で最初に決めるのは、接続の方式ではありません。その処理について意思決定・データの権限・応答時間・復旧責任の4つを自組織で引き受けられるかを確かめ、どこまでを1つのエージェントに残すかという境界を先に決めることです。境界が決まってはじめて、MCP・External Services・Agent API・Connected Subagentsのどれを使うかという選択に意味が出てきます。

本記事では、境界を決める4つの判断基準と外へ渡す処理の見分け方、4方式の使い分け、そして2026年8月12日時点で確認できた提供段階までを、1つの流れとして整理してきました。例に挙げた商社では、この順番で境界を引き直したことで、回答までに数時間かかっていた在庫照会が営業の手元で完結し、1日に何十件あった物流部門への問い合わせも発生しなくなっています。提供段階は今後も変わるため、正式提供前の機能を使う範囲は、変更が起きたときに直せる分量にとどめておきましょう。

複数のシステムをまたぐ設計は、Salesforceの設定だけで完結せず、業務部門・情報システム部門・接続先の提供元をまたいだ判断が必要になります。どこで境界を切るかを社内だけで決めきれない場合は、BtoBマーケティング無料相談もご利用いただけます。本記事の内容を、自社の接続先の状況に合わせて実践し、少しでもお役に立てれば幸いです。