Salesforce Headless 360って何をした話？

Salesforceが2026年4月に発表した「Headless 360」は、SaaSの存在意義に対する根本的な問いを含んでいる。

要点は3つ。SalesforceをAPI・MCPツール・CLIとして外部に公開する。AIエージェントがブラウザ（GUI）を経由せずにSalesforceを操作できるようにする。そのために60以上のMCPツールと、Agentforce Experience Layer（AXL）を提供する。

一言で言えば、「Salesforceをユーザーが画面で使うSaaS」から「AIエージェントが裏側から呼び出すインフラ」への転換宣言だ。

これが単なる技術的なアップデートにとどまらない理由は、SaaSのマネタイズモデルの根っこに触れているからだ。

なぜ「アカウント課金」が揺らぐのか

Slack、Salesforce、kintoneに代表される多くのSaaSは「シート課金」を基本としている。ユーザー数×月額、もしくは月間アクティブユーザー数（MAU）ベースの課金だ。

このモデルには暗黙の前提がある。**「人間がUIにログインして使う」**という前提だ。

アクティブユーザーが多いほど収益が上がり、「うちの社員が毎日使っている」という実績が契約更新の根拠にもなる。SaaSベンダーにとって、UIはただの操作画面ではなく、課金を正当化するための「玄関」でもあった。

Headless 360が変えるのは、まさにその玄関の位置だ。

従来: 人 → GUI → Salesforceのデータ
今後: 人 → AIアシスタント → API/MCP → Salesforceのデータ

人間のログイン回数が減る。MAUが下がる。「何人が使っているか」という指標が、価値の代理指標として機能しなくなる。さらに、UIへの依存が下がるということは、乗り換えコストも薄れていくということでもある。

SalesforceはUIの独占を捨てて、何を守るのか

ここが面白いポイントだ。SalesforceがHeadless化によって失うものと、逆に強化されるものは明確に分かれている。

失われやすいもの：

  • ユーザーの最初の接点としてのUI独占（ChatGPT・Claude・Slackがその役割を担い始める）
  • MAUという課金根拠
  • UIの使い勝手がスイッチングコストになるという構造

むしろ強化されるもの：

  • 顧客・案件・権限・業務ステータスの「正本データ」としての地位
  • 承認フロー、SLA管理、ワークフロールールといった業務ロジック
  • 誰が何をできるかを制御するガバナンス機能と監査ログ
  • AIの実行を人間が監視・承認するための「統制画面」としての需要増

UIがなくなるわけではない。ただしその役割が「作業する画面」から「管理・承認する画面」へと変わる。この転換はSaaSベンダーにとって痛みを伴う変化だが、逆に言えばデータと業務ロジックを持っているプレイヤーは生き残れる、ということでもある。

新しい課金軸はどこへ向かうか

Salesforceはすでに複数の課金モデルを並立させている。従来のPer-user（シート課金）に加えて、AIエージェントの会話数・アクション数単位で課金する「Flex Credits」、そして特定のビジネス結果に紐づく成果ベース課金（試験段階）だ。

この方向性は「誰が使うか」から「何が実行されたか」への移行を示している。

同様の変化は他のSaaSにも波及すると予測される。

  • kintone → 登録レコード数 / API呼び出し数
  • freee → 処理した仕訳件数 / 自動化した業務件数
  • Slack → メッセージ数 → AIエージェントの実行件数

課金単位が「人」から「実行」へシフトしていく。これはSaaSベンダーにとって収益予測の難易度が上がることを意味するが、同時に「使われなくても課金される」シート課金の不満を抱えてきたユーザー企業側には、歓迎される変化でもある。

「BigQueryでいいのでは？」という問いが本質をついている

Headless化でAIが直接データを読むなら、ぶっちゃけBigQueryで事足りるのでは？という疑問が当然出てくる。

答えは「用途による」だ。横断分析・集計・機械学習ならBigQueryが向いている。ただ、業務の状態管理・権限制御・承認・ワークフローはSalesforceのような業務SaaSの領域だ。

SalesforceのHeadless化の本質は「データを外に出す」ことではなく、「業務文脈・権限・実行制御ごと外に出す」ことにある。BigQueryはデータを持てる。しかし「この更新は誰が承認するか」「このSLAは何日以内か」という業務ロジックは持っていない。

実用解は「BigQueryで分析し、Salesforceで動かす」という役割分担だ。ここを混同すると、システム設計の判断を誤る。

日本企業はいつ、何から動くべきか

日本での波及は段階的に進むと見ておいた方がいい。

近い将来（現在進行中）： 案件検索・FAQ参照・要約・社内問い合わせ対応など、読み取り中心の活用。更新リスクが低いため、ここから始めるのが現実的だ。

中期： AIが下書きを作成し、人間が確認してから実行する「承認付き更新」。SalesforceのAgent Scriptのような仕組みが鍵になる。

長期： 自社固有の承認フロー・計算・外部連携をエージェントが自律的に呼び出す段階。情シス・開発・権限設計の内製力が必要なため、大手か内製力のある企業が先行するだろう。

実務的な示唆として、今すぐ動けることは2つある。1つは自社のSaaSのAPIとMCP対応状況を棚卸しすること。2つ目は、「AIが実行した操作」を承認・監査できる業務フローを設計し始めること。後者は技術より組織の問題なので、早めに議論を始めた方がいい。

まとめ

Salesforce Headless 360が示す変化を「SaaSの終わり」と読むのは正確ではない。正確には「GUIを独占することで稼げる時代の終わり」だ。

業務データ・権限・実行基盤を持つSaaSは、AIに開放することでエコシステムへの組み込みが深まる。課金モデルはシート数から実行量・成果指標へシフトしていく。UIは消えないが、その役割は根本から変わる。

この変化をどう設計し直すか。SaaSベンダーにとっても、使う側の企業にとっても、今がその問いと向き合うタイミングだ。