a16z: UIが製品でなくなった時、ソフトウェアの縄張りは何になりますか？

この記事を読むのに必要な時間は 46 分

データ、権限、ビジネスロジック、および実行能力

Editor's Note: Over the past two decades, the moat of SaaS has largely been built on top of the UI. Dashboards, fields, approval processes, and user habits, not only as the operational interface but also shape the organization's way of working and data order. When AI can directly read data, call tools, execute processes, and the stickiness formed by human muscle memory begins to weaken, the UI is no longer necessarily the core interface of enterprise software.

This does not mean that the record system is losing value, but its defensiveness is shifting: from UI and usage habits to data models, permission systems, compliance responsibilities, business logic, execution loops, and multi-party collaboration networks. The future of truly formidable software may no longer be just a database recording human work but an action system that can capture context, initiate tasks, coordinate intelligent agents, and continuously generate new data during execution.

As software moves towards headless, the core issue of enterprise software also changes: the value is no longer just about who owns the data, but about who can organize actions around the data.

The following is the original text:

Last month, Salesforce announced that it would open its API and launch a headless product. Essentially, this means that Salesforce is betting that in the Agent era, its core value no longer primarily comes from the UI but from the data layer. This is a rather smart repositioning.

However, it should also be noted that from a technical perspective, this release does not seem to bring about much substantive change. The API now rebranded as a "headless product" by Salesforce has largely existed for years. In other words, this is more like a typical Salesforce-style marketing release.

The core idea of this new product is that Agents can directly access data in the record system without having to interact through a UI designed for humans. The role of the traditional UI is to help human users track processes, manage tasks, and drive workflows forward; but after the Agent intervention, the necessity of this UI layer begins to diminish.

What is truly worth discussing in this release is not just what new product Salesforce has launched, but the deeper question it raises: if you strip away the UI, only open the underlying database, what is left of a record system? How much difference is there between it and a Postgres database, a well-designed data schema, and a set of APIs?

さらに言えば、記録システムに耐久性を持たせてきた古典的要素は、まだ有効なのでしょうか？それとも、新たな競争基準が登場しているのでしょうか？

SaaS時代において、記録システムが要塞を持つ理由は、ヒトのユーザーが長期間そのインターフェイスに暮らしていたからです。インターフェイスには操作習慣や組織プロセス、データの蓄積が内包されており、それにより移行コストが高くなっています。しかし、エージェント時代において、この利点は弱体化しています。本当の防御を備えたレベルは、一方ではデータモデル、権限システム、ワークフローロジック、コンプライアンス能力に沈殿しつつあり、他方ではネットワーク効果、独自のデータ生成能力、現実世界での実行能力に移行しています。

ソフトウェアがヘッドレスに向かうとき、要塞はどこに移るのでしょうか？

UIはかつて製品そのものでした

システムオブレコード（System of Record、SoR）とは、ある種のビジネスデータの権威ある事実元であり、顧客関係、従業員記録、財務取引などの「公式バージョン」が存在する場所であり、他のツールがデータを読み取り、データを書き戻す核となるシステムです。CRMは収益関連データの記録システムであり、HRISは人事関連データの記録システムであり、ERPは資金および財務関連データの記録システムです。

これらのシステムの強さは、データを格納しているからだけでなく、それらが組織全体の運用に依存する「実バージョン」として最終的になる点にあります。

過去20年間、Salesforceが顧客に提供しているのは、実際には営業責任者がチームを管理するのを支援するセットでした。ダッシュボード、セールスパイプラインビュー、予測ツール、ダイナミックフィードは、真に購入された製品です。そのビジネスモデルは、ユーザーに席を販売することに基づいており、これらの席が本質的に提供するのは上記の機能へのアクセス権限です。基盤となるデータベースは重要ですが、製品体験では、それはむしろ暗黙のインフラのようになっています。

つまり、ユーザーの粘着性を真に駆動しているのはUIです。

UIはデータの規範を制約し、共通言語を形成しました：リード、チャンス、顧客口座。これにより、何千ものセールスリードが、もともと入力することを望まなかったデータを継続的に入力するようになりました。過去には、UIこそがデータの整合性と可用性を維持していたメカニズムでした。Salesforceが非常に強力な粘着性を持つのは、多くの営業責任者が転職後もSalesforceを新会社に持ち込み続ける理由は、そのインターフェイスがどれほど優れているかではなく、既に筋肉の記憶となっているからです。

しかし、Agent はこのパターンを変革し始めています。これらはもはや UI を介してソフトウェアとやり取りする必要がなく、直接基礎データを読み書きすることができます。これにより、従来のインターフェースをバイパスする新しいツールや代替ソリューションが生まれました。Salesforce が唯一の例ではありません：最近では、SAP 周辺でも、より AI 呼び出しに適したエコシステムが育まれつつあります。

同時に、コンピューターを操作できる Agent によって、選好、トレーニング、非文書化されたコンテキストなど、従来の人間の側面の要因が時間とともにますます重要ではなくなっています。つまり、持続的な記録システムとしての要件が変化しているということです。

過去の評価基準

Agent の時代に何が変わるのかを議論する前に、記録システムが粘着性を持つのは過去に何かがあったからかという問いについて、より正確に考えてみる必要があります。

最初の数要因は、主に人間がソフトウェアをどのように使用しているか、および人間自身の好みに関連しています。ソフトウェアが置き換えられにくい理由の多くは、UI、使用習慣、人間のワークフロー、そして組織プロセスに組み込まれた制度的配置に大きく依存しています。

第一に、そのアクセス頻度はどの程度ですか？

たとえば、CRM は GTM チームや他の多くの関連部門によって毎日使用されています。このような高頻度の使用こそが、これを重要なインフラストラクチャにしています。そしてこの上に築かれた人間の層—たとえばチームミーティングや操作習慣、マネジメントのリズムなど、組織の慣性に数年かけて組み込まれた部分—が移行が最も困難である場合が多いという点にあります。なぜなら、それを「移行が必要なもの」として認識されることさえまれだからです。

第二に、それは書き込み専用なのですか、読み書きの両方を行っていますか？

本当に粘性のある記録システムは、通常、読み書きの双方向システムです。CRM の場合、それは単なるアーカイブ用の書き込みシステムではなく、継続的に読み取られています。すべての通話記録、各ステージの更新、各タスクの作成は、ユーザーが入力したものであり、通常はそのデータがどのように使用されるかについても関心があります。

この双方向のフローは、どんな代替品もリアルタイムの業務データをキャッチアップできるようにしなければならず、過去のデータのエクスポートだけでは済まされません。移行プロセスでは、ほぼ安全な切り替え時点が存在しません。そのため、企業が一度オンラインになると、しばしば長期間にわたり元のベンダー体系に留まります。

これに対して、応募者追跡システム（ATS）は通常、「書き込み専用」システムにより近いです。応募者が採用または拒否された後、企業がこれらのデータを再度使用する理由は比較的限られています。

第三に、いくつかの未文書化の SOP が存在していますか？

真の鍵となるビジネスコンテキストは、しばしばどんなウィキにも書かれておらず、管理者やシステム統合業者が何年にもわたり構築してきたワークフロールールに蓄積されています。

例として、セールスシステムを挙げると、これらの文書化されていないコンテキストには、次のようなものが含まれる可能性があります：企業向けの取引が10万ドルを超える場合、VP の承認が必要です。EMEA 地域の取引はプライバシーレビューが必要です。戦略的顧客の割引は四半期末にのみ財務承認をバイパスできます。

これらのコンテキストは、通常、あることがタイムリーに推進されるか、重要なプロセスを遵守しながら完了されるかどうかを決定します。システムを移行するということは、各自動化されたルールを再び分解する必要があることを意味します。そうでない場合、企業は組織の一部のメモリを直接失う可能性があります。

第四に、内部または外部の依存関係がどれだけ複雑か？

核心的な問題は次のとおりです：内部システム、チームプロセス、または外部ステークホルダーがこのレコードシステムにどれだけ依存しているか？

内部の連結性は、下流のソフトウェアやワークフローがそれに依存している割合を示します。一方、外部の連結性は、監査人、会計士、規制当局などの外部主体がデータに直接アクセスする必要があるかどうかを示します。ERP がその典型例です。

内部でも外部でも、接続性が高ければ高いほど、移行時に分解して再構築する必要がある関係が複雑になります。

第五に、コンプライアンスの観点からデータの重要性はどれくらいか？

ここでの中心的な問題は非常に単純です：このシステムがコンプライアンス上重要かどうかですか？

給与システム、ERP、人事データなどのようなコンプライアンスに関連する重要なシステムは、法的に正当な事実のソースを提供し、厳格な管理者権限制御を持っている必要があります。どんな移行でも、監査人や規制当局が直接介入する可能性があります。これにより、これらのシステムの粘着性は著しく強化されます。

セールスデータや Zendesk のようなカスタマーサポートツールは、異なる立場にあります。企業はもちろん継続性とコンテキストに関心を持っていますが、データが移行されたりアクセス権限が与えられたりした場合、通常、直ちに規制上のリスクが引き起こされることはありません。

すべてのレコードシステムが同じ切り替えコストを持っているわけではありません。CRM と ATS を同じ範疇で比較した場合、その差は非常に明白です。

ATS は、採用プロセスを中心に展開された、限られたワークフローツールの一種です。候補者が採用されるか拒否されると、関連記録のほとんどは一度だけ書き込まれたデータになります。その統合範囲は狭く、ユーザー層もより小規模で集中しています。

ERP はもう一つの極端にあります。総勘定元帳自体が監査トレイルであり、会計士、監査人、規制当局が移行プロセスで直接関係することになります。

ATS の置き換えは痛みを伴いますが、まだ耐えられる範囲です。CRM の置き換えは開胸手術を行うようなものです。そして、ERP の置き換えは、患者がマラソンを走る間に開胸手術を行うようなものです。

従来、記録システムは、プロプライエタリデータやネットワーク効果などの競争上の利点を十分に活用していませんでした。一般に、ワークフロー自体でさえ壁を形成するのに十分でした。道具をネットワークに結び付けることが、主に消費者ビジネスにとってより一般的であり、歴史的には SoR がこの道をたどることはありませんでした。

プロプライエタリデータ。多くの記録システムは、多くの顧客データを蓄積していますが、そのデータを本格的に活用することはありませんでした。さらに、多くの場合、契約条項がそのような活動を許可していませんでした。そのため、CRM は豊富なデータセットを持っているにもかかわらず、様々な顧客のデータを集約し、顧客全体の洞察を生成することが理論的には可能でしたが、それを実質的な意味で行ったことはありませんでした。もちろん、Salesforce の Einstein などの製品は一部の試みを行ってきました。

ネットワーク効果。記録システムにとって、最も理想的な競争上の利点はネットワーク効果でした。たとえば、CRM はソフトウェアベンダーがバイヤーを見つけるのに役立つため、より価値のあるものになります。しかし、データと同様に、歴史的に記録システムのネットワーク効果は非常に弱いか、ほとんど存在しないとさえ言えます。

UI が消失した場合、Agent が登場した後、ソフトウェアには何が残りますか？

Agent はブラウザを必要としません。それに必要なのは API、コンテキスト、命令、およびアクションを実行する能力です。これが規模化される要因となったのは、LLM が十分な推論能力を持っており、そのために Agent が今日、コンテキストを読み取り、計画を立て、ツールを選択し、アクションを実行し、結果をフィードバックできるようになったためです。そして、MCP がツールへのアクセス方法を標準化し、Agent が外部機能を呼び出すための一連の一般的なインターフェイスを提供したためです。

MCP アクセス権を持つ Agent は、ミリ秒単位で過去に人間のユーザーがプラットフォームで行っていた操作を大規模に実行することができ、ブラウザは必要ありません。適切なコンテキストがあれば、コンピュータを操作できる Agent は、API を使用する必要がなく既存のソフトウェアインターフェースを直接使用できることさえあります。

簡単に言えば、ソフトウェアバイヤーには現在、3つの選択肢があります：

第一に、既存のシステムを引き続き使用し、それに Agent を組み込むことがあります。
既存のシステムの CLI および API を使用することで、ベンダー固有の Agent 製品（Salesforce の Agentforce、SAP の Jouleなど）を使用したり、独自に Agent を構築したりできます。もちろん、ここでは API が完全で利用可能であり、「ヘッドレス化」が実際の運用にもたらす複雑さを一旦無視しています。

第二に、完全自前のレコードシステム。

企業はゼロから自社のデータモデル、運用ロジック、権限システム、監査トレイル、システム統合、および独自のエージェントスタックを構築できます。この経路はおそらく、サードパーティのエージェント開発ツールやデータベースツールを活用することになるでしょう。

第三に、AIネイティブの代替品を購入する。

企業は、エージェント時代のために設計された新世代のソフトウェアを購入することもできます。このタイプの製品は、機械が読み取れることを重視し、エージェントの編成を第一級の機能とし、AI機能を古いシステムにパッチワークするのではなく、ヘッドレスである場合があります。

それでは、旧来の評価基準のうち、何が残されるのでしょうか？

人間の行動と好みに基づく要因は徐々に弱まっていくでしょう。たとえば、アクセス頻度、読み書き両方向の属性など、人間の筋肉記憶に関連する指標が該当します。エージェントはおそらく、「筋肉記憶」を城壁とする価値を弱めるかもしれませんが、運用ロジックやビジネスコンテキストの城壁を排除することはありません。ある意味では、エージェントはこれらのロジックをより重要にし、タスクを安全に実行するために明確なルール、権限、およびプロセス定義に依存する必要があるからです。

文書化されていないSOPは、一時的に重要です。

ワークフロールールに沈殿している組織内の制度的論理は、エージェントがタスクを正しく実行するために必要なものです。同時に、これは再構築が最も難しい部分でもあります。少なくとも現時点では、特に一部のプロセスには人間の関与が引き続き必要な状況では、これを綺麗にエクスポートすることはまだできません。ただし、コンテキストを捉えることはますます容易になっています。エージェントがより多くの人間労働を代替するにつれ、この要素の重要性も徐々に低下していくでしょう。

接続性はまだ解体が難しく、より深いレベルに広がります。

接続性の意味が変わりつつあります。それはもはや人間の作業を補完するためだけのものではなく、伝統的に互いに分断されていた機能とソフトウェアの間の接続を維持することが求められています。

CRMエージェントは、販売、請求、顧客成功など、異なるステージのデータとコンテキストをつなぎ合わせる必要があります。あなたのプラットフォームが複数の外部組織間の取引のノードとなっている場合、例えば、買い手、売り手、パートナーがすべてここで相互作用を完了する場合、依存関係はさらに深まります。

既存のベンダーがエージェントを重ねる場合、異なる基本オブジェクトとロジックの下でのスムーズな連携は難しいかもしれません。企業が自前のデータベースと一連のエージェントだけに頼っている場合も、同様の問題に直面することになります。

コンプライアンスに関する重要なデータは依然重要です。

規制当局、規制リスク、または法的リスクに関連するデータについては、信頼性のある単一のデータファクトソースが引き続き必要とされます。顧客が既存の製品を信頼している場合、彼らがシステムを切り替える可能性は低くなります。

給与と会計データを例に取ると、エージェントは実際にそのデータにアクセスする必要があるかもしれませんが、企業は通常、そのようなシステムを内部で構築して長期間維持することを選択することはまれです。

完全にエージェント化された世界において、最も難しい問題の一つは、どのエージェントが何を許可されているのか、誰を代表して行動しているのか、そしてこれらの行動がどのように監査されるのかです。レコードシステムがエージェント間の相互作用の身元と権限のレイヤーとなることができれば、真に置換困難な構造を持つようになります。ここでの壁は、データをどのように保持しているかだけでなく、どのような信頼構造を実行しているかです。

将来を考えると、AIネイティブのスタートアップ企業にとって、新しい一連の要素がますます重要になり、それが彼らの守備力を決定するでしょう。

第一に、このレコードシステムを再構築するのは実際にどれほど難しいのか？

データは、さらにいくつかのレベルでより重要になります。

まずは、短期的には、レコードシステムのベースデータを抽出し、再構築する難易度が重要です。AIはこれを容易にし、多くのツールがこのような移行や再構築を支援しています。

短期的には、既存のベンダーは、これを困難にする可能性があります。彼らはAPIを使いにくくしたり、制限を加えたり、不完全にしたり、経済的に見合わなくしたり、APIを提供しないことさえあります。しかし、抽出ツールの進歩と、特にコンピューターを操作できるエージェントの能力向上に伴い、データの再構築はますます容易になります。

同時に、新しい会社は、メール、電話、音声エージェント、社内ドキュメントからより豊かなデータセットを再構築しています。AIは、レコードシステムの再構築にかかる前半80%のコストを削減しています。使用可能なエントリポイントと本当の代替品を区別するのは、残りの20%です：例外状況、承認プロセス、コンプライアンス要件、およびエッジケースでのワークフロー。

第二に、本当に意味のある専有データを所有しているかどうかはどうか？

次に、データ自体がより価値あるものになります。

本当に防御的なデータとは、インポートしたデータではなく、製品が独自に生成させたデータです。私たちは常に「データガーデンウォール」を言います：これらのデータは専有的であるか、規制によって制約されているか、継続的な更新が必要かのいずれかです。権威ある、かつ包括的なデータの収集に多くのリソースを投入するソフトウェアサプライヤーは、一般的なサプライヤーやこのようなデータを持たない競合他社に比べて明らかな優位性を持つでしょう。

データにはもう一つ重要な方向があります：それが製品内で行われたアクションに依存しているかどうかです。

最高の企業は、他所からのデータ入力のみを保管するのではありません。彼らは自らがプロセス内にあり、新しいデータトレイルを持続的に生成するために存在します。例えば、観察された行動、応答率、時間パターン、プロセス結果、業界基準、異常パターン、およびエージェントの実行トレースなどです。

重要なのは：データは今やコンテキストそのものです。

第三に、アクションレイヤーを持っているかどうか？

旧世界では、記録の保管そのものが十分でした。しかし新しい世界では、エージェントは直接行動を起こし、防御は、クローズドループを形成できる製品に向かうかもしれません：行動を起こし、結果をキャプチャし、フィードバックを活用して将来の意思決定を最適化します。

ERPの場合、これには支出の承認、給与の支払いトリガー、請求書の照合、通知の送信などが含まれるかもしれません。クローズドループを形成できる製品は、実行プロセスに埋め込まれており、観察レベルにとどまらず、より防御的です。それらはユニークなデータを生成し、使用するにつれて継続的に改善され、一旦削除されるとワークフローが破壊される可能性があるため、より置き換えが難しくなります。

もちろん、コンテキストが蓄積され、エッジケースがより適切に処理されるにつれて、ここでの価値もさらに向上するでしょう。

第四に、現実世界の実行要素が含まれているかどうか？

一部のビジネスモデルは、実際の運用と連動していますが、これらの要素は完全に自動化されることはありません。最も明白な例は、DoorDashなどの運用ネットワークを持つ企業です。これらは過去には記録システムに属していなかったかもしれませんが、ここで非常に示唆に富んでいます。

より一般的に言うと、サービス、フルフィルメント、物流、現地運用、または支払い手続きにソフトウェアのクローズドループを拡張できる企業は、純粋なSaaSと異なる種類の防御性を持っています。これらの企業は記録を保管するだけでなく、アクションを推奨するだけではありません；彼らは人員を派遣し、商品を移動し、または具体的なサービスを提供します。

起業家にとって、これはソフトウェアが意思決定をする能力と、エージェントがプロセスを調整する能力が向上する一方で、最後のマイルで現実世界の実行が依然として必要であるということを意味します。たとえば、現地サービスに関連付けられた縦断ソフトウェアは、典型的な方向性です。

第五に、ネットワーク効果が存在するかどうか？

歴史的に、ほとんどの記録システムのネットワーク効果は弱かったです。なぜなら、それらは主に内部ソフトウェアだったからです。しかし、エージェントの時代には、システムが多数のワークフローに組み込まれている場合、ネットワーク効果がはるかに重要になるかもしれません。

システムが複数者間の繰り返しインタラクションを調停する場合、例えばバイヤーとセラー、雇用主と従業員、企業と公認会計士、サプライヤーと顧客、支払い側とサービス提供側のような場合、参加者を増やすたびにこのネットワークは次の参加者にとってより多くの価値を提供する可能性があります。

その一つの方法は、ワークフロー共有による協調です：製品はプロセスの両側が取引し、コンテキストを交換し、例外を処理する場となります。

もう一つの方法は、基準と知能です：システムはネットワークで観察されたパターンに基づいて、業界の標準、例外状況、行動提案を示すことができ、これは前述のデータ価値と相互補強します。

三つ目の方法は、信頼と標準化です：取引相手が承認、引き継ぎ、コンプライアンス、または支払いを完了するために同じレールに依存し始めると、この製品はもはや単なるデータベースではなく、市場そのものの協調インフラとなり、そのため置き換えがより困難になります。

六つ目は、買い手の技術力がどれだけ強いかです？

誰でも基本的理論上は自己のエージェントを構築できる世界において、異なる買い手が実際に持つ構築能力は非常に異なります。特に、垂直業界や過去に強力な内部エンジニアリングリソースを持っていなかった機能型買い手においては、彼らが自社でデータベース、ワークフローロジック、エージェントスタック、およびガバナンス層を構築、維持、および継続的に改善する確率は依然として非常に低いです。

ここではコストも同様に重要です。DIYは理論的にはソフトウェアライセンス料を減らす可能性がありますが、支出は実装、保守、および内部の複雑さに移されることがしばしばあります。

つまり、運用が複雑でありながら技術供給が不足しているカテゴリには、まだ実際の機会が存在します。例えば、製造業、建設業のバックエンド、産業プロセス、現場サービスワークフロー、および会計などの分野です。

さらに、いくつかの要因が同様に重要であり、徐々にソフトウェアの基本的な閾値となります。

たとえば、オントロジーが変わらなければなりません。多くの「自己構築データベース」の概念は、オブジェクトモデル自体が持つ価値を過小評価しています。既存のソフトウェアはダッシュボード、レポート、および人間のユーザーのために構築されており、商談、ワークオーダー、候補者などのオブジェクトをキャプチャしています。

しかし、エージェント時代のスキーマは推論、アクション、状態追跡、例外処理、タスク委任、およびシステム間の協調をキャプチャする必要があります。ネイティブのオブジェクトモデルは、商談、ワークオーダー、候補者ではなく、タスク、意図、スレッド、ポリシー、または結果といったものになるかもしれません。

同様に、アクセス権システムも更新する必要があります。それはもはや人間のユーザーを管理するだけでなく、エージェントを管理する必要があります。これには次のようなことが含まれます：誰が何を、どのエージェントを介して、どのような方針で、どのような承認が必要で、どのような監査トレイルを残し、およびどのようにロールバックと例外処理を行うか。

もちろん、これらすべてはコストの問題にかかわっており、エージェントとデータベースの構築および維持にかかる費用、APIアクセスコストの高さがどれくらいかなどが問われます。これは幾つかの中心的な問題に再び立ち返ります：データの再構築の難しさ、依存関係の数、およびシステムがどれだけ深く組み込まれているか。

では、結論は何でしょうか？