ClaudeからSalesforce組織をブラウザなしで操作してみた

こんにちは、エンジニアの片山です。

2026年4月のTDXで発表された Headless 360 によって、Salesforceの機能がAPI・MCPツール・CLIコマンドとして公開され、「Our API is the UI（APIこそがUI）」という言葉が現実のものになりました。これまでSalesforceといえば、ブラウザでLightningにログインし、タブを切り替えながらクリックで操作するもの、というのが当たり前でした。Headless 360は、その業務ロジック・データ・ワークフロー・権限・ガバナンスを、Salesforceの画面を開かずに外から呼び出せるようにする、という構想です。

ここで重要なのは、「Headless（ヘッドレス）」という名前のとおり、特定の画面（ヘッド）に縛られないという点です。Salesforceはもはや「Lightningという決まったUIとセット」ではなく、どの入り口から触ってもよい状態を目指しています。

Salesforceが想定している標準的な絵姿は、Agentforceで作ったエージェントをSlackなどのサーフェス（ユーザーが触れる入り口となる画面やアプリ）に出す形です。ただ、それを試すにはAgentforceやSlackのライセンスが必要で、気軽に手を動かすには少しハードルがあります。そこで今回は、その「UIに縛られない」という発想を、より身近な Claude Code で再現してみることにしました。ブラウザを一切開かずに、手元のターミナルからSalesforce組織をどこまで触れるのか試します。

言い換えると、本記事は「Salesforceが描く未来（Agentforce＋Slack）の縮小版を、開発者が無料の環境で先取りして体験してみる」試みです。

検証はすべて無料の Developer Edition組織 で完結し、追加課金は発生しません。読者の方も同じ手順でそのまま追試できる構成にしています。

前提環境

今回の検証は以下の環境で行いました。

Node.js 20以上（npx 用、MCPサーバの起動に必須）
Salesforce CLI（sf コマンド）
Claude Code（利用にはClaudeの有料プラン、またはConsoleアカウントが必要です）
検証用の Developer Edition 組織（無料で取得できます）

今回使うのは、Salesforceが提供するローカルの DX MCP Server（@salesforce/mcp）です。これは開発者向けのMCPサーバで、Salesforce CLIの認証情報をそのまま利用するため、External Client App（OAuth）の作成が不要で、セットアップがシンプルなのが特徴です。

セットアップ

手順は大きく2ステップだけです。

1. 組織をCLIで認証する

操作したい組織をSalesforce CLIで認証します。ブラウザが一度立ち上がってログインを求められますが、これは「認証の初回だけ」の話で、以降の操作はターミナルから行えます。

sf org login web --alias my-dev-org --set-default

--set-default を付けて既定組織にしておくと、このあとの設定で DEFAULT_TARGET_ORG として参照できます。認証できたか確認します。

sf org list

2. `.mcp.json` を作成する

作業ディレクトリの直下に .mcp.json を作成し、DX MCP Serverの設定を記述します。

{
  "mcpServers": {
    "Salesforce DX": {
      "command": "npx",
      "args": ["-y", "@salesforce/mcp",
               "--orgs", "DEFAULT_TARGET_ORG",
               "--toolsets", "orgs,data,testing",
               "--allow-non-ga-tools"]
    }
  }
}

最初の動作確認では、--toolsets を orgs,data,testing の3つに絞りました。DX MCPサーバには多くのツールが含まれているため、all で全部有効化するとLLMのコンテキストを圧迫します。使うツールセットだけを指定するのがよいです。

起動して接続を確認する

作業ディレクトリでClaude Codeを起動し、/mcp コマンドでMCPサーバの状態を確認します。

claude

/mcp

ここで Salesforce DX が ✔ connected になっていれば成功です。

動かしてみる

業務担当の目線です。Lightningにログインして検索条件を組んだり、レポートビルダーを操作したりせず、ターミナルに自然言語で聞くだけ、という体験を試します。

「取引先（Account）を作成日の新しい順に10件、名前と作成日で見せて」とお願いすると、Claudeが裏でSOQLを生成し、run_soql_query で実行して結果を返してくれました。SOQLを自分で書かなくても、欲しいデータを言葉で頼むだけで取得できます。

さらに「その結果を業種ごとに件数を集計して要約して」と続けると、照会結果をそのまま集計・要約してくれます。レポートビルダーを開かずに、対話の流れで分析まで進められるのが新鮮でした。

なお、ここで動かしているのはあくまで開発者向けのセットアップ（Node・CLI・Claude Code）です。業務ユーザーが実際にこの体験を得るには、後述する別の構成が必要になります。本節は「業務ユーザーが将来得られる体験を、開発者が手元で再現してみせている」という位置づけです。

また、「Edge Communications の商談レコードを更新して」とお願いすると、ターミナルのBashが呼ばれて、実際に組織のデータが書き換わりました。

ここで強調しておきたいのは、更新できたのは、認証したユーザーにそのオブジェクトの編集権限があったから だという点です。次のセキュリティの節で触れますが、Claudeが何でも勝手にできるわけではなく、あくまでユーザーの権限の範囲で動いています。

一方で、エージェントが更新・削除まで実行できるということは、意図しない変更のリスクもあるということです。実行前に内容を確認してから走らせる運用（human in the loop）を前提にし、まずは検証組織で試す、本番では権限を絞る、といった配慮は欠かせません。

分析・提案までできた ― Agentforceとの境界線

試していて気づいたのは、商談を多角的に照会し、状況を整理し、優先順位つきで「次の一手」まで提案する、という分析・判断支援のレベルでは、Claude Codeでも驚くほどのことができる点でした。たとえば「この商談に対して次にするべき行動を考えて」とお願いすると、複数のSOQLで商談・関連タスク・同じ取引先の他商談まで集めたうえで、状況を表で整理し、推奨アクションを優先順位つきで返してくれました。

「考える」部分だけ見れば、Agentforceと遜色ない——むしろClaudeの推論力が活きる場面もあります。しかも実行できる範囲も、思っていたより広いものでした。「この商談の担当者にメールを送って」とお願いしたところ、ClaudeはApex（匿名実行）経由でメールまで送ってしまいました。つまりApexを介せば、照会や更新どころか、メール送信のような業務アクションにも手が届きます。

では本当の違いはどこにあるのか。手を動かしてみて、はっきりしたのは次の2点でした。

ひとつは 自律性 です。今回のClaude Codeは、こちらが言葉で頼んだときだけ動く対話型です。一方Agentforceは、たとえば「新しいケースが作成されたら、内容を自動で分類して一次回答を返す」のように、人が頼まなくてもイベントを起点に自分で動く運用を組めます。誰も「考えて」と打たなくても回り続ける、という点が決定的に違います。

もうひとつは 全社で安全に使うための運用とガバナンス です。今回Claudeが動いたのは、開発者である私のCLI認証情報の上で、しかも匿名Apexという「開発者の万能キー」を使ってのことでした。強力な反面、業務ユーザー一人ひとりの権限でスコープを絞る、許可する業務アクションを定義する、実行を監査ログに残す、といった統制はかかっていません。Agentforceは、各業務ユーザーが自分の権限のままSlackなどから使い、許可された業務アクションだけを、ガバナンスと監査のもとで実行できるように設計されています。つまり違いは「技術的に何ができるか」よりも、「誰が・どんな統制のもとで・全社規模で安全に使えるか」にある、というのが実感です。

逆に言えば、頭脳はClaudeにもAgentforceにも差し替えられ、土台のSalesforceは共通——これこそHeadless 360が描く世界そのものだと、手を動かして実感しました。

セキュリティ・ガバナンスの所感

触っていて安心できたのは、Claudeが組織のデータに直接つながっているわけではない という点です。今回のローカルDXサーバはCLIで認証したユーザーの権限の範囲で動き、オブジェクト権限・項目レベルセキュリティ・共有ルールはあくまでSalesforce側で効きます。つまり、エージェントがアクセスできるのは「そのユーザーが本来見られる・編集できるデータ」だけです。

前節でレコード更新ができたのも、認証ユーザーに編集権限があったからこそで、権限のないオブジェクトはそもそも操作できません。「エージェントがデータだけでなく権限とガバナンスも継承する」というHeadless 360の核心を、手元で確認できたのは大きな収穫でした。長年かけて作り込んだ権限設計が、アクセス経路を増やしても引き続き効く、という安心感があります。そして、この安心感はローカルで開発者が触る場面に限った話ではありません。業務ユーザーが将来Slackなどから（ホスト型のMCPサーバやAgentforce経由で）使う場面でも、オブジェクト権限・項目レベルセキュリティ・共有ルールがプラットフォーム側で効く、という土台は共通です。つまり、入り口が開発者のターミナルであれ業務ユーザーのSlackであれ、エージェントは結局「そのユーザーが本来できること」しかできない。権限とガバナンスが入り口に依存せず一貫して効く——これはHeadless 360のように触れる経路を増やしていくうえで、最も重要な安心材料だと感じました。

まとめ

ブラウザを一切開かずに、SOQLによる照会から更新まで、ターミナルから完結できることが確認できました。

そして今回いちばん実感したのは、Headless 360の本質は「UIに縛られないこと」 だという点です。今回はたまたまClaude Codeという入り口を選びましたが、同じ仕組みの上で、入り口はSlackやTeams、各種チャット、自社で作ったReactアプリなど、いろいろに差し替えられます。Headless 360の柱のひとつ「どのサーフェスにも展開できる」は、まさにこの考え方です。エージェント（頭脳）と、それを表示する場所（サーフェス）を分離する、という発想です。

UIに縛られないということは、エンジニアの仕事も「特定画面の作り込み」から「どの入り口にも対応できる土台（データ・ロジック・権限）の設計」へと重心が移っていく、ということでもあります。

そして今回いちばん腹落ちしたのは、入り口（UI）も頭脳（AI）も差し替えられる時代になっても、Salesforceはなくならない、それどころか、長年ビジネスの標準スキーマを磨き続けてきたSalesforceプラットフォームにデータがあることは、とてつもないメリットだ、ということです。ClaudeであれAgentforceであれ、どのエージェントが操作しようと、その足場になるのはデータモデル・業務ロジック・権限・ガバナンスといった、Salesforceに積み上げられた土台です。Headless 360は「Salesforceがあらゆる入り口の共通基盤になる」話なのだと感じました。画面で操作する場所から、すべてのエージェントが拠り所にするプラットフォームへ——Salesforceの価値はむしろこれから増していくはずです。