はじめに
AgentforceエージェントをMCPサーバー経由で外部から呼び出したくて、External Client Appの設定から実際に手を動かしてみました。
ドキュメントを読んだだけでは分かりにくかった、OAuthまわりの設定項目とツール公開の実装パターンを、手順ベースでまとめます。
接続アプリケーションとの違いでうっかりハマったので、そのあたりも記録しておきます。コーディングエージェントだけでなく、業務エージェントからAgentforceを呼びたいエンジニアの参考になれば。
Headless 360って結局何なの?
Headless 360は、Summer '26でSalesforceが打ち出した大きなテーマです。ヘッドレスというのは、要するに「画面という頭を持たない」という意味の言葉。SalesforceのほぼすべてをAPIやMCPツール、CLIコマンドから使えるようにする取り組みです。
ここで出てくるMCP(Model Context Protocol)というカタカナ用語も、最初は身構えると思います。Excelでいうと、外部ソフトからマクロを呼び出すための共通の呼び出し窓口を作るようなもの、と考えると分かりやすいです。ClaudeやChatGPT、Cursorといった外部のAIツールが、この窓口を通じてSalesforceの機能を呼び出せるようになります。
Salesforceが用意する標準MCPサーバー(SObject操作やData 360クエリなど)は、すでにGA(一般提供)です。今回の記事のテーマである「Agentforceエージェントをツールとして公開する」仕組みは、管理者が構成するカスタムMCPサーバーの中で使います。
出典:The Salesforce Developer's Guide to the Summer '26 Release
Headless 360は、Salesforceの機能を外の世界に開く土台だと思っておけば十分です。
Agentforceエージェントを外部ツールから呼べるようにする設定手順
ここからが本題です。実務でつまずきやすいのは、まさにこの設定部分だと思います。
外部のAIクライアントをSalesforceにつなぐには、最初に1回だけ「外部クライアントアプリケーション」という認証用の窓口を作る必要があります。組織全体で1回すればよい作業です。OAuth認証は、鍵そのものを渡さずに合鍵だけを発行するようなイメージだと捉えてください。
- Setupの「クイック検索」ボックスに「外部クライアント」と入力し、「外部クライアントアプリケーション マネージャー」を開く
- 「新規 外部クライアントアプリケーション」をクリックする
- 「基本情報」欄を入力する
- 「API (OAuth 設定の有効化)」セクションを開き、「OAuth を有効化」にチェックを入れる
- 「Callback URL」に接続するクライアントごとのURLを入力する。Claudeの場合は
https://claude.ai/api/mcp/auth_callback
- 「OAuth 範囲」で「Salesforce でホストされている MCP サーバーにアクセス (mcp_api)
」と「いつでも要求を実行 (refresh_token, offline_access)
」を追加する
- 「セキュリティ」欄で「指名ユーザーの JSON Web トークン (JWT) ベースのアクセストークンを発行」と「サポートされる認証フローに Proof Key for Code Exchange (PKCE) 拡張を要求」にチェックを入れる。それ以外のセキュリティ項目にはチェックを入れない
- 「作成」をクリックする
- 反映まで最大30分ほど待ってから、「設定」→「コンシューマー鍵と秘密」から値を控える
私も最初にこの画面を開いたときは、項目の多さに「うわ、難しそう…」と思いました。でも「認証まわりを一度だけ固める作業」と割り切ってしまえば、意外とシンプルです。
この作業にはシステム管理者相当の権限が必要です。権限が足りない場合は、情報システム部門に相談してください。
窓口ができたら、次は「設定」の「インテグレーション＞APIカタログ」配下にある「MCP サーバー」からカスタムサーバーを作成します。
公開したいAgentforceエージェントを選び、ツール名と説明文を設定して公開する、という流れです。
MCPサーバーを作成し
既存エージェントを追加する
認証の窓口を1回作って、カスタムサーバーでエージェントをツール化する。この2段階だと覚えておけば大丈夫です。
実装パターン:エージェントをツール化するときのコツ
ここは実務で差が出るポイントです。1つのAgentforceエージェントが複数の役割を持っている場合、役割ごとに別々のツールとして公開するのがコツです。
たとえば「商談のスケジュール調整」と「案件クローズ予測」を両方できる営業エージェントがあるとします。裏側の実体は同じエージェントでも、「商談日程調整ツール」「案件クローズ予測ツール」という2つの名前で公開します。
外部のAIアシスタントは、ツールの名前と説明文だけを見てどれを使うか判断します。「営業エージェント」という漠然とした名前より、用途がはっきり分かる名前の方が選ばれやすくなるからです。
実務で使うなら、ここはちょっと注意しておいた方が良さそうです。エージェントの指示や機能を後から変更したときは、MCPツール側の説明文も一緒に更新してください。放置すると、外部アシスタントが古い説明文をもとに、見当違いのタイミングでツールを呼んでしまうことがあります。
エージェントやプロンプトの実行は、呼び出した本人のユーザー権限で行われます。共有ルールや項目レベルセキュリティ、Einstein Trust Layerのガードレールも、通常のログインユーザーと同じように効きます。
ツールは役割ごとに名前を分けて公開する。これが基本ルールです。
ここは注意!つまずきポイント
実務で最初につまずきやすいのは、接続アプリケーションではなく外部クライアントアプリケーションを使う点です。今までのSalesforce開発で接続アプリケーションに慣れている人ほど、ここで手が止まります。MCPクライアントの接続に接続アプリケーションは使えないので、注意してください。
もう1つ、外部クライアントアプリケーションを作成しても、すぐには使えません。反映まで最大30分ほどかかるので、「あれ、動かない」と焦らず少し待ってみてください。
そして正直に書いておきたいのが費用面です。Hosted MCPサーバーやAgentforceエージェントのツール化にあたって、追加のアドオン購入が必要かどうかは、今回調査した公式ソースの範囲では明記を確認できませんでした。エディションや契約によって条件が変わる可能性があるため、実際に導入する前には、必ず担当の営業担当者や最新の公式ヘルプで確認してください。
まとめ
- Headless 360は、Salesforceの機能を画面を介さずAPIやMCPツール、CLIから使えるようにする取り組み
- Agentforceエージェントを外部から呼ぶには、カスタムMCPサーバーの中でツールとして公開する
- 事前準備として外部クライアントアプリケーションを1回作成し、OAuth認証の窓口を用意する必要がある
- 1つのエージェントに複数の役割がある場合は、役割ごとにツール名を分けて公開するのがコツ
- 追加費用の有無やエディション条件は、必ず最新の公式情報や営業担当者に確認する
Headless 360はまだ動き出したばかりの領域なので、これから先も情報はどんどん更新されていくはずです。一緒に少しずつ慣れていきましょう!
AI×資格学習の情報をnoteで発信しています。
→ note