ソフトウェアはヘッドレス化に向かうのか？

• Salesforceがヘッドレス製品の投入を通じて、価値の中心はUIではなくデータ層にあると賭けに出たことで、エージェント時代のSaaSの防御力はどこに残るのかという問いが浮上している
• SaaS時代のSystem of Recordの堀は、UIを通じて形成されたユーザー習慣だったが、エージェントがDBに直接読み書きする構造ではこの優位性が弱まる
• 防御力は下方向ではデータモデル、権限、ワークフローロジック、コンプライアンスへ、上方向ではネットワーク、独自データの生成、現実世界での実行能力へと移りつつある
• 次世代のAIネイティブなSystem of Recordには、エージェントフレンドリーなデータモデル、エージェント単位の権限管理、実行ループのクローズという新たな基準が必要
• 最も有望な次世代事業は、単なるデータ保存を超えて現実世界での実行と多者間調整にまで拡張する形である

---

Salesforceのヘッドレス発表が投げかけた問い

• Salesforceは先月、API開放とヘッドレス製品の投入を発表し、エージェント時代の価値はUIではなくデータ層にあるという賭けに出た
  • 技術的に新しく変わったものはほとんどない — ヘッドレス製品として売り出しているAPIは数年前から存在しており、典型的なSalesforce流のマーケティングローンチである
  • 核心となるアイデアは、エージェントが人間向けUIを経由せずにSystem of Recordのデータへ直接アクセスする構造だということ
• UIを取り払ってDBだけが残るなら、Postgres + よく設計されたスキーマ + APIと何が違うのかという本質的な問いが生じる
  • 既存のSystem of Recordを支えてきた要素がそのまま有効なのか、それとも新しい基準が必要なのかを検討する必要がある

UIこそが製品だったSaaS時代

• System of Recordは、特定ドメインにおける権威ある単一の真実の供給源(source of truth)である
  • CRMは売上のSystem of Record、HRISは人事のSystem of Record、ERPは資金のSystem of Recordだ
  • 単なる保存場所ではなく、組織全体が共有する現実を提供することが本当の力だった
• 過去20年間、Salesforceが売ってきたのは営業リーダーがチームを運営する方法そのものだった
  • ダッシュボード、パイプラインビュー、予測ツール、アクティビティフィードが実際の販売対象であり、ビジネスモデルはユーザーシート(seat)販売に基づいていた
  • その下にあるDBは中核ではあるが副次的な存在だった
• UIがスティッキネスを生み出していた
  • データ衛生を強制し、共通語彙(Lead, Opportunity, Account)を作り、営業担当が本来入力しないデータを入力させた
  • 多くの営業リーダーが転職時にSalesforceを持ち込む理由は、UIが優れているからではなく、**体に染みついた操作習慣(muscle memory)**にある
• エージェントがこのモデルを覆し始めている
  • UIを経由せずデータへ直接read/writeできる
  • SAPの周辺でもAIフレンドリーなエコシステムが急速に広がっている
  • コンピュータ利用エージェントが、人間由来の要因(嗜好、訓練、非文書化コンテキスト)を時間とともに無力化していく

従来のSystem of Recordのスティッキネス評価基準

• 人がソフトウェアとどう相互作用し、何を好むかに基づく要因

• どれだけ頻繁に使われるか

  • CRMはGTMチームが毎日使うため、基幹インフラになる
  • その上に積み上がった業務ルーチン、手に馴染んだ操作、何年もかけて固まった管理ケイデンスが最も移しにくい要素だった
  • 移行すべき対象としてすら認識されないことが多い

• Write-onlyか、Read-writeか

  • スティッキネスの高いSystem of Recordはread-write型である
  • CRMは絶えず読まれる — すべての通話記録、ステージ更新、タスク作成が双方向の流れだ
  • ライブな運用データを扱うため安全な切り替え時点がない → 一度導入すると離れにくい
  • 一方でATS(応募者追跡システム)はwrite-onlyに近い — 採用終了後にデータを見返すことはほとんどない

• 非文書化SOPがどれだけ多いか

  • ビジネス上の重要なコンテキストはWikiではなくワークフロールールにエンコードされている
  • 営業の例: 10万ドル超のエンタープライズ案件にはVP承認が必要、EMEA案件ではプライバシーレビューが必須、戦略的ロゴへの割引は四半期末に限り財務を迂回できる
  • こうしたコンテキストが、適時処理されるか取りこぼされるかの差を生む
  • 移行とは、あらゆる自動化をリバースエンジニアリングするか、組織の記憶を丸ごと失うことを意味する

• 内部・外部依存関係の規模

  • 下流の内部システムや、外部監査人・会計士・規制当局による直接アクセスの必要性
  • 両方向の接続性が高いほど、移行時に解くべき結び目が増える

• コンプライアンスの重要度

  • 給与計算、ERP、HRデータには、法的に防御可能な単一の真実の供給源、厳格な管理者アクセス制御、監査人・規制当局の直接関与が不可欠
  • 非常にスティッキーである
  • 反対側にあるのが営業データやZendeskのようなカスタマーサポートツールで、継続性とコンテキストは重要だが規制上の露出はない

• System of Recordごとの切り替えコスト比較

  • ATSは採用という境界が明確なワークフローツールで、統合範囲が狭くユーザーも少ない
  • ERPはその正反対 — 元帳そのものが監査証跡であり、会計士・監査人・規制当局が直接の利害関係者となる
  • ATSの置き換えは痛みを伴うが耐えられる、CRMの置き換えは開心術(open-heart surgery)、ERPの置き換えはマラソン中の患者に対する開心術だ

• 伝統的に弱かった堀の要素

  • 独自データ — CRMは豊富なデータを持っていたが、顧客横断のインサイト生成への取り組みは乏しかった (Salesforce Einsteinなど一部の試みにとどまる)
  • ネットワーク効果 — 聖杯のように語られてきたが、System of Recordでは歴史的に弱かった

UIが消え、エージェントが到来すると何が残るのか

• エージェントにブラウザは不要 — API、コンテキスト、指示、行動能力さえあればよい

• それを可能にしている変化は2つある

  • LLMの推論能力向上: エージェントがコンテキスト読解、計画立案、ツール選択、実行、結果確認までを人間の介入なしにこなせる
  • MCPによるツールアクセスの標準化: エージェントが外部機能を共通インターフェースで呼び出せる
  • コンピュータ利用エージェントは、適切なコンテキストさえあればAPIなしでも既存SWインターフェースを探索できる

• ソフトウェア購入者の3つの道筋

  • 既存システム + エージェント: 既存SaaS大手のCLI/APIを使い、ネイティブエージェント製品(Salesforce Agentforce, SAP Joule)を使うか自前のエージェントを構築する — ただしAPIが完全で実用的であり、ヘッドレス移行が運用上シンプルであることが前提
  • 独自のSystem of Record構築(DIY): 独自のデータモデル、運用ロジック、権限・監査・統合、自前のエージェントを一から構築する (サードパーティツールの活用は可能)
  • AIネイティブな代替製品を購入: 機械可読性を前提にゼロから作られた新世代ソフトウェアで、エージェントオーケストレーションが第一級機能として組み込まれ、ヘッドレス対応できる

• 従来の評価基準で生き残るもの

  • 人間行動ベースの要素(利用頻度、read vs read-write) → 利用習慣とともに消えていく
  • エージェントは利用習慣の堀を壊すが、運用ロジックとコンテキストの堀は壊さない
  • むしろエージェントが安全に動くには、明示的なルール・権限・プロセス定義が必要になるため、さらに重要になる

• 短期的には非文書化SOPが依然として重要

  • ワークフロールールにエンコードされた組織ロジックは、エージェントが正しく動作するための核心である
  • きれいにエクスポートできない (特に人間が一部プロセスに残る場合)
  • ただしコンテキストの捕捉が容易になり、エージェントが労働を代替するほど徐々に重要性は薄れていく

• 接続性(connectivity)は依然として難しく、さらに拡大する

  • 人間について回ることよりも、分断された機能やソフトウェア間の接続性維持が中心になる
  • CRMエージェントは、営業・請求・カスタマーサクセスの間でデータとコンテキストを縫い合わせなければならない
  • 外部の複数組織のエージェントが取引するノードになれば、依存関係はさらに深くなる
  • 既存大手 + エージェントの組み合わせでも、DIY DB + エージェントの組み合わせでも、多様な下位ソフトウェアを横断するのは難しい

• コンプライアンスデータは依然として重要

  • 規制・法的リスクに関わるデータには、単一の信頼できるデータソースが必要
  • 給与計算や会計データを自前で構築・維持する可能性は低い
  • 完全エージェント世界における最も難しい未解決問題は、どのエージェントが、誰の代理として、何を、どのような監査可能性のもとで権限付与されるのかという点だ
  • エージェント間相互作用のアイデンティティと権限の層となるSystem of Recordは、信頼アーキテクチャを強制するため構造的に置き換えにくい

AIネイティブスタートアップの新たな防御力要素

• System of Record再現の難しさ

  • 短期的には、System of Record由来データの抽出と再現のしやすさが核心になる
  • 既存SaaS大手はAPIを使いづらくしたり、ゲートを設けたり、不完全にしたり、採算が合わない形にしたりして難しくする
  • 抽出ツール、とりわけコンピュータ利用エージェントの進化で、それは徐々に容易になっている
  • 同時に、メール・電話・音声エージェント・社内文書からより豊かなデータを再構成する新興企業も現れている
  • AIはSystem of Recordの最初の80%を再現するコストを下げるが、残り20%(例外処理、承認、コンプライアンス、エッジケースのワークフロー)こそが、本物の代替製品とwedgeを分けるポイントになる

• 意味のある独自データを持っているか

  • 防御可能なデータとは、importしたデータではなく、製品が固有に生み出したデータである
  • データのwalled garden — 独占的であったり、規制対象であったり、継続的更新が必要なデータ
  • 権威性が高く完全なデータに投資したソフトウェア提供者は、汎用提供者に対して優位を得る
  • 内部生成の行動ベースデータ: 観測された行動、応答率、タイミングパターン、プロセス結果、ベンチマーク、例外パターン、エージェント性能トラッキング
  • データこそがコンテキスト(data is the context)

• アクション層を持っているか

  • 以前は記録保存だけで十分だったが、新しい時代にはエージェントが行動する
  • 防御力は、行動 → 結果の捕捉 → フィードバック → 意思決定改善のクローズドループ製品へ移っている
  • ERPの例: 支出承認、給与計算トリガー、請求書精算、通知送信など
  • ループを閉じる製品は観測ではなく実行の中に位置する → 独自データを生み、使うほど改善し、ワークフローを壊さずには外せない

• 現実世界での実行要素

  • 完全自動化されない現実世界のオペレーションとの接続性を持つビジネスモデル
  • DoorDashのような運用ネットワークの事例 — 歴史的にはSystem of Recordではないが示唆に富む
  • サービス、フルフィルメント、物流、現場オペレーション、決済によってループを閉じるソフトウェアは、純粋なSaaSとは異なる種類の防御力を持つ
  • 単なる記録保存やレコメンドではなく、人を派遣し、物を動かし、サービスを完了する
  • ビルダーにとっては、ソフトウェアがますます意思決定しエージェントが調整役を担う一方で、ラストマイルでは現実世界での実行が必要な市場に機会がある — 例: 現場サービスと結びついたバーティカルソフトウェア

• ネットワーク効果

  • これまでSystem of Recordではソフトウェアが主に社内向けだったため弱かった
  • 多者間ワークフローに埋め込まれると、ネットワーク効果ははるかに重要になる可能性がある
  • 買い手-売り手、雇用主-被雇用者、企業-監査人、ベンダー-顧客、payer-providerなどの反復的相互作用を媒介する場合、参加者の増加がネットワーク価値の増加につながる
  • 実装の形
    • 共有ワークフロー調整 — 双方が取引・コンテキスト交換・例外解決を行う場所になる
    • ベンチマーキング・インテリジェンス — ネットワークパターンに基づく規範・異常・推奨を提供する
    • 信頼・標準化 — 承認・ハンドオフ・コンプライアンス・決済の共通レールになれば、単なるDBではなく市場調整インフラの一部になる

• 購入者の技術力

  • 誰もが理論上はエージェントを作れる時代でも、実際の能力には大きなばらつきがある
  • バーティカルなエンドマーケットや、社内エンジニアリング資源が乏しい機能部門の買い手は、自前のDB・ワークフローロジック・エージェントスタック・ガバナンスを構築、維持、改善できる可能性が低い
  • コストも重要だ — DIYはライセンス費用を減らせても、その分が実装・保守・内部複雑性のコストに転嫁される
  • オペレーションは複雑なのに技術的には十分にサービスされていないカテゴリーに機会がある — 製造、建設バックオフィス、産業・現場サービスのワークフロー、会計

そのほかの必須要件(table stakes)

• 新しいデータモデル(オントロジー)

  • 「DIY DB」という発想は、オブジェクトモデル自体の価値を過小評価しがちだ
  • 従来のソフトウェアは、ダッシュボード、レポート、人間のワークフローを捉えるために作られてきた → Opportunity, Ticket, Candidateなど
  • エージェント向けスキーマは、推論、行動、状態追跡、例外処理、委任、システム間調整を捉える必要がある
  • ネイティブなオブジェクトモデルは、task, intent, thread, policy, outcomeのような形へ変化する

• エージェント権限管理

  • 人間だけでなくエージェント管理のための権限体系が必要
  • 誰が、どのエージェントを通じて、どのポリシーの下で、どの承認・監査証跡・ロールバック・例外処理を伴って何をできるのかを定義しなければならない

• コストの文脈

  • エージェントやDBの構築・維持コスト、APIアクセス費用など
  • データ再現の難しさや依存関係の数ともつながる問題だ

結論 — System of Recordの進化の方向

• 既存SaaS大手がヘッドレス化へ向かうのは、データ層が価値の源泉として残るという暗黙の賭けである
• 金融サービスのようにコンプライアンスと深く結びついたカテゴリーでは、この賭けは当面有効であり、ヘッドレス移行もより先の未来になる
• ビルダーの立場から見ると、ヘッドレス化する既存大手と競争する機会の構造は変わる
• 次世代のSystem of Recordは、単なる記録保存庫ではなく、コンテキストを捉え、作業を開始し、データの足跡(data exhaust)を記録するエージェントフレンドリーな形になる
• 最も興味深いビジネスは、現実世界での実行へ拡張 — 現場人員、物流提供者、サービスチーム、物理資産を調整したり、多者の間に位置したりする形である
• 旧世界のビジネスモデルと従来のSystem of Recordの中核(データ)を混ぜつつ、データは背景に位置する構造