Salesforceは水曜日、創業27年の歴史の中で最も野心的なアーキテクチャ変革を発表し、「Headless 360」を導入しました。これは、プラットフォーム上のあらゆる機能をAPI、MCPツール、またはCLIコマンドとして公開し、AIエージェントがブラウザを開くことなくシステム全体を稼働できるようにする、包括的な取り組みです。
この発表は、同社の年次TDX開発者会議がサンフランシスコで開催された場で行われました。発表と同時に、100以上の新しいツールとスキルが、開発者がすぐに利用できる形で提供されます。これは、企業向けソフトウェアに漂う存在論的な問いへの決定的な回答でもあります。つまり、AIエージェントが推論し、計画し、実行できる世界において、企業はグラフィカルなインターフェースを備えたCRMを、依然として必要とするのか？という問いです。
Salesforceの答えは「ノー」—そして、それがまさにポイントです。
「当社は2年半前に決断しました。『AIエージェントのためにSalesforceを作り直す』と。」「UIの裏に能力を埋もれさせるのではなく、公開して、プラットフォーム全体をどこからでもプログラム可能でアクセス可能にするのです」と同社は発表で述べました。
タイミングは偶然とは言い難いものです。Salesforceは、企業向けソフトウェアの歴史の中でも最も荒れた時期の一つを乗り切ろうとしている局面にあります。すなわち、業界全体での売りが広がり、iShares Expanded Tech-Software Sector ETF は9月の高値からおよそ28%下落しています。下落を後押ししているのは、こうした恐れです。特にAnthropicやOpenAIなどの大規模言語モデル（LLM）が、従来のSaaSのビジネスモデルを時代遅れにしてしまうかもしれない、という懸念です。
Jayesh Govindarjan（SalesforceのEVPで、Headless 360構想の主要な設計者の一人）は、この発表はマーケティング理論に根ざしたものではなく、何千ものエンタープライズ顧客に対してエージェントを導入して得た、勝ち取った実地の教訓に基づくものだと説明しました。
「私たちの顧客それぞれに対して、こちらのスタックであろうと他社のスタックであろうと、あらゆるスタック上でエージェント型システムを構築するという、そのライフサイクルの問題が明らかになりました」とGovindarjanはVentureBeatの独占インタビューで語りました。「彼らが直面している課題は、まさにソフトウェア開発の課題です。どうやってエージェントを作るのか？それが第一歩にすぎません。」
100以上の新しいツールにより、コーディングエージェントが初めてSalesforceプラットフォームへ完全にアクセス可能に
Salesforce Headless 360は、3つの柱に基づいています。これらは合わせて、企業向けプラットフォームがエージェント時代にどのように見えるべきかを再定義しようとする同社の試みを表しています。
最初の柱は「望む形で構築できる」です。60以上の新しいMCP（Model Context Protocol）ツールと、30以上の事前設定済みコーディングスキルを提供します。Claude Code、Cursor、Codex、Windsurfのような外部のコーディングエージェントは、データ、ワークフロー、ビジネスロジックを含む顧客のSalesforce組織全体に対して、完全なライブアクセスが可能になります。開発者は、もはやSalesforce自身のIDEの中で作業する必要がありません。どの端末からでもAIコーディングエージェントを指示して、Salesforceアプリケーションの構築、デプロイ、管理ができます。
同社のネイティブ開発環境であるAgentforce Vibes 2.0には、Anthropic agent SDKとOpenAI agents SDKの両方をサポートする、「オープン・エージェント・ハーネス」と同社が呼ぶ仕組みが現在含まれています。キーノートで示されたように、開発者はタスクに応じてClaude CodeとOpenAIエージェントのどちらを選ぶことができ、選択したエージェントに基づいてハーネスが利用可能な機能を動的に調整します。この環境にはさらに、Claude SonnetやGPT-5を含むマルチモデル対応に加え、最初から組織の完全な把握（org awareness）が組み込まれています。
大きな技術的追加として、Salesforceプラットフォーム上でのネイティブReact対応が挙げられます。キーノートのデモでは、発表者はSalesforce固有のLightningフレームワークではなくReactを使って、完全に機能するパートナー向けサービスアプリケーションを構築し、GraphQLによって組織のメタデータに接続しました。そのうえで、プラットフォームのセキュリティに関する基本要素をすべて継承しています。これにより、ビジュアル層を完全にコントロールしたい開発者にとって、フロントエンドの表現力は劇的に広がります。
2つ目の柱である「どのサーフェスにもデプロイできる」は、新しいAgentforce Experience Layerを中心に据えています。これは、エージェントが「何をするか」と「どのように見えるか」を切り分け、Slack、モバイルアプリ、Microsoft Teams、ChatGPT、Claude、Gemini、そしてMCPアプリに対応するあらゆるクライアント上にリッチなインタラクティブ・コンポーネントをネイティブにレンダリングします。キーノートでは、発表者が体験（エクスペリエンス）を一度定義して、サーフェス固有のコードを書かずに6つの異なるサーフェスへ展開する様子が示されました。哲学の転換は重要です。顧客をSalesforceのUIに引き込むのではなく、企業が、顧客がすでに使っているどのワークスペースにも、ブランド化されたインタラクティブなエージェント体験を押し出すのです。
3つ目の柱である「大規模で信頼できるエージェントを構築する」は、テスト、評価、実験、観測、オーケストレーションにまたがる、まったく新しい一連のライフサイクル管理ツール群を導入します。エージェントの振る舞いを決定論的に定義するための同社新しいドメイン固有言語であるAgent Scriptは、現在一般提供が開始され、オープンソースとして公開されています。新しいTesting Center では、デプロイ前にロジック上の穴やポリシー違反が可視化されます。カスタムのスコアリング評価（Custom Scoring Evals）により、企業は自社の特定のユースケースにおいて「良い」とは何かを定義できます。そして新しいA/Bテスト用APIにより、複数のエージェント版を実運用のトラフィックに同時に適用して実行することが可能になります。
なぜエンタープライズ顧客は自社のAIエージェントを壊し続けてしまったのか — そしてSalesforceはそれにどう対応してツールを再設計したのか
おそらく最も技術的に重要で、かつ率直なVentureBeatのGovindarjanへのインタビューの一節は、エンタープライズAIの中核にある根本的なエンジニアリング上の緊張、つまり「エージェントは確率的なシステムだが、企業は決定論的な結果を求める」という問題を扱っていました。
Govindarjanは、初期のAgentforceの顧客が、"途方もない努力によって、"エージェントを本番環境に投入したあと、痛ましい現実に直面したと説明した。彼は「『このエージェントに変更を加えるのが怖かった。なぜなら、システム全体が脆いからだ』という状態でした」と述べた。「1回変更すると、それが100%の確率で確実に動くのか分からない。行っていたテストはすべてやり直しになります。」
この脆さの問題が、Agent Scriptの創出につながった。Govindarjanはそれを「プログラミング言語にある決定性と、LLMが提供する確率的システムに内在する柔軟性を、とりまとめるプログラミング言語だ」と説明した。同言語は、状態機械を定義する単一のフラットファイルとして機能する。つまり、バージョン管理・監査が可能で、エージェントのふるまいを統制する。企業はその機械の中で、どのステップが明示的なビジネスロジックに従う必要があるのか、またどのステップがLLMの能力を使って自由に推論してよいのかを指定する。
今週、SalesforceはオープンソースとしてAgent Scriptを公開し、Govindarjanは、ドキュメントがきれいなためClaude Codeはすでにネイティブにそれを生成できると指摘した。こうしたアプローチは、業界の別の場所で勢いを増している「vibe coding（雰囲気コーディング）」の動きとは、はっきり対照的だ。ウォール・ストリート・ジャーナルが最近報じたところによると、いくつかの企業は、CRMの置き換えを丸ごとvibe-codeしようと試みているという。これは、SalesforceのHeadless 360が、最もエージェントに適した基盤として自社のプラットフォームを提供することで、直接的に解決しているトレンドでもある。
Govindarjanは、ツール群をSalesforce自身の社内での実践の産物だと語った。「顧客を成功させるために、私たちはこれらのツールが必要でした。その後、私たちのFDEがそれを必要とするようになりました。私たちはそれらを硬くして、そして顧客に渡したのです」と、彼はVentureBeatに語った。言い換えれば、Salesforceは自社の痛みをプロダクト化したのだ。
Salesforceが「すべての企業が必要になる」と言う、競合する2つのAIエージェント・アーキテクチャの中身
Govindarjanは、企業において立ち上がってきている、根本的に異なる2つのエージェント型アーキテクチャのあいだに、示唆に富む対比を示した。1つは顧客向けのやり取り用で、もう1つは彼が「Ralph Wiggumループ」と呼んだものに関連づけたものだ。
顧客向けエージェント──つまり、販売やサービスのためにエンド顧客とやり取りする目的で導入されるもの──には、きわめて厳密な決定的制御が求められる。「顧客がこれらのエージェントを自社の顧客の前に置くことを受け入れる前に、特定のパラダイム──ある種のブランドとしてのルールセット──に従っていることを確かめたいのです」とGovindarjanはVentureBeatに語った。Agent Scriptは、これらを静的グラフとしてエンコードする。つまり、各ステップの中にLLM推論が埋め込まれた、定義済みの手順（ファネル）である。
これに対して、Ralph Wiggumループはスペクトラムの反対側を表す。実行時に展開される動的グラフであり、エージェントは直前のステップで学んだ内容に基づいて次のステップを自律的に決める。その結果、行き止まりの経路は殺され、新しい経路が生み出され、タスクが完了するまで続く。Govindarjanによれば、このアーキテクチャは主に、従業員向けのシナリオで見られる。つまり、コーディングエージェントを使う開発者、深い調査ループを回す営業担当者、キャンペーン資料を生成するマーケターなどで、出荷される前に専門の人間が出力をレビューする。
「Ralph Wiggumループは、従業員向けにはとても良い。なぜなら従業員は本質的に“何か”の専門家だからです」とGovindarjanは説明した。「開発者は開発の専門家で、営業担当者は営業の専門家です。」
重要な技術的洞察は、両方のアーキテクチャが同じ基盤プラットフォームと同じグラフエンジン上で動くという点だ。「これは動的グラフです。これは静的グラフです。すべてその下ではグラフです」と彼は言った。厳密に制御された顧客とのやり取りから、自由形式の自律ループまでをまたぐ、この統一されたランタイムは、Salesforceにとって最も重要な技術的賭けであり、企業がエージェントのモダリティごとに別々のプラットフォームを維持する手間を省く可能性がある。
SalesforceはMCPに賭けつつ、あらゆる主要AIモデルとツールにエコシステムを開放する
TDXにおけるSalesforceの「オープンさ」への取り組みは印象的だった。このプラットフォームは現在、OpenAI、Anthropic、Google Gemini、MetaのLLaMA、Mistral AIモデルと統合している。オープンなエージェント活用機能はサードパーティのエージェントSDKをサポートする。MCPツールは、どのようなコーディング環境でも動作する。そして新しいAgentExchangeマーケットプレイスが、Google、Docusign、Notionを含むパートナーから提供される、10,000のSalesforceアプリ、2,600以上のSlackアプリ、1,000以上のAgentforceのエージェント／ツール／MCPサーバーを統合する。さらに新たな5,000万ドルのAgentExchange Builders Initiativeが裏付けとして用意されている。
それでもGovindarjanは、MCPそのものについて驚くほど率直な評価を示した。MCPはAnthropicが作ったプロトコルで、エージェントとツールの通信における事実上の標準になりつつある。
「率直に言うと、MCPが標準であり続けるかはまったく確信がありません」と彼はVentureBeatに語った。「MCPがプロトコルとして登場したとき、多くのエンジニアは、それが実は、きちんと書かれたCLIの上に乗っかっているだけだと感じました。今もそうです。『CLIで十分じゃないか、むしろそれ以上に良いのでは』と言う人もたくさんいます。」
彼の考え方は、現実的な柔軟性だ。「私たちはどちらか一方に固執しているわけではありません。最良のものを使うだけで、しかも多くの場合は3つすべてを提供するでしょう。APIも提供しますし、CLIも提供しますし、MCPも提供します。」この“ヘッジ”が、Headless 360の命名にも表れている。つまり、単一のプロトコルに賭けるのではなく、Salesforceは3つのアクセスパターンすべてにわたってあらゆる能力を公開し、プロトコルの変化に対して自社を隔離しているのだ。
基調講演のデモで大きく取り上げられたEngineは、オープンなエコシステムのアプローチに関する現実的な裏付けを提供した。同社はAgentforceを使ってカスタマーサービスのエージェントであるAvaを12日で構築し、現在では顧客ケースの50%を自律的に処理している。Engineは、顧客向けと従業員向けの機能にまたがって5つのエージェントを稼働しており、インフラの中核にはData 360があり、主要な作業スペースにはSlackが使われている。「CSATは上がり、提供コストは下がります。顧客はより満足しています。より早く回答を届けられています。ではトレードオフは？ トレードオフはありません」と、基調講演中にEngineの幹部は語った。
これらすべてを支えているのは、Salesforceがどのように課金するかの変化だ。同社は、Agentforceのための座席課金から、消費ベースの価格設定へ移行している。この移行についてGovindarjanは「私たちにとってのビジネスモデルの変更であり、イノベーションです」と説明した。これは、エージェントが人間の代わりに仕事をするようになると、ユーザー単位で課金してももはや意味がない、という暗黙の認識でもある。
Salesforceは古いモデルを守っているのではありません——それを解体し、これから来るものに賭けているのです
ガウンダラジャンは、会社の進化を建築の観点で捉えました。Salesforceは、自社のプラットフォームを4つの層で構成しています。文脈のためのシステム（Data 360）、仕事のためのシステム（Customer 360アプリ）、代理（エージェンシー）のためのシステム（Agentforce）、そしてエンゲージメントのためのシステム（Slackやその他の画面/サーフェス）です。ヘッドレス360は、プログラム可能なエンドポイントを通じて、あらゆる層をそれぞれ開きます。
「今日見ていただいたもの、そして今私たちがやっていることは、MCPツールで、すべての層を本当に一つひとつ開放しているということです。必要とされるエージェント型の体験を作りにいくためにね」と、ガウンダラジャンはVentureBeatに語りました。「会社が自分自身を変革しているのを、あなたも目にしていると思います。」
その変革が成功するかどうかは、何千もの顧客導入にまたがる実行力、MCPや関連プロトコルにおける持続力、そして根本的な問い——AIエージェントがますますゼロから新しいシステムを構築できるようになるとき、既存のエンタープライズ・プラットフォームは十分な速さで動いて関連性を保てるのか——への答えにかかっています。ソフトウェア業界の弱気相場、業界全体にのしかかる財務的な圧力、さらにLLMの改善が目を見張るほどの速さで進んでいることが、結果としてこれをエンタープライズ技術における最大級のリスクを伴う賭けの一つに押し上げてしまっています。
しかし、Salesforceの窮地には皮肉が織り込まれています。ヘッドレス360がそれを明確にしています。従来のソフトウェアを置き換えようとして脅威となるまさにそのAI能力が、今やSalesforceが自社を作り直すために利用しているのと同じ能力なのです。理屈の上ではCRMを置き換えられたかもしれないあらゆるコーディング・エージェントが、ヘッドレス360によって、1つの上に積み重なっていくコーディング・エージェントになっています。同社は「エージェントがゲームを変えない」と主張しているのではありません。「エージェントはゲームを変える」と言っているのです。ただし、その主張の中で同社が言いたいのは、長年にわたって蓄積されたエンタープライズのデータ、業務フロー、信頼の層、そして組織に根づいた論理が、空白のプロンプトからは生成できない“何か”を同社にもたらしている、という点です。
3月にCNBCの『Mad Money』でベニオフが宣言した通り、「ソフトウェア業界は、まだ生きていて、元気で、成長している」。ヘッドレス360は、その正しさを証明するために同社が行う最も力強い試みです——Salesforceを有名にしたまさにそのプラットフォームの壁を取り壊し、世界中のあらゆるエージェントに“正面玄関”から入ってくるよう招いていることで。
Salesforceの共同創業者であるパーカー・ハリスは、先月彼が投げかけた問いの中で、この賭けを最も端的に言い表しました。「なぜ、あなたはもう一度Salesforceにログインする必要があるのでしょうか？」
ヘッドレス360が設計通りに機能するなら、答えはこうです。ログインする必要はないはずです。そしてSalesforceは、まさにそれこそが、あなたが支払い続ける理由になるのだ、と賭けているのです。
