a16z：エージェントがUIを必要としなくなれば、ソフトウェア企業はなぜまだ数百億ドルもの価値があるのか？
TechFlow厳選深潮セレクト
a16z：エージェントがUIを必要としなくなれば、ソフトウェア企業はなぜまだ数百億ドルもの価値があるのか？
ソフトウェアはその「頭」を失いつつあるのでしょうか？a16zが警告：AIエージェント時代には、ラッピングされたデータベースでは不十分です。
Web3業界の深掘り報道に専念し潮流を洞察著者：Seema Amble
編集・翻訳：TechFlow
TechFlow解説：Salesforceは「ヘッドレス製品」の提供を発表しましたが、その実態はAPIを再パッケージングしただけにすぎません。しかし、この動きはより本質的な問いを浮かび上がらせます——エージェントがUIを介さず直接APIを呼び出す時代において、従来型SaaS企業が残すものは単なるデータベースと一連の業務ロジックのみとなるでしょう。それならば、なぜそれらは依然として数百億ドルもの企業価値を持つのでしょうか？a16zは、AI時代におけるシステム・オブ・レコード（SoR）の「モアトゥー（護城河）」の再構築を分析しました。UIによるユーザー定着力は消失し、長年培われた「筋肉記憶」も無意味になりますが、代わりにコンプライアンス要件、他システムとの接続性、そして文書化されていない運用上の暗黙知（Tacit Knowledge）が、むしろより重要になっていくのです。
ソフトウェアは、本当に「頭部」を失いつつあるのか？
先月、SalesforceはAPIの全面開放とヘッドレス製品の提供を発表しました。これは、エージェント主導の時代において、同社の価値はUIではなくデータ層にあるという明確な戦略的賭けです。これは非常に賢い再ポジショニングと言えるでしょう。（ただし技術的には特に新規性がない点にも注目すべきです。つまり、現在「ヘッドレス製品」としてマーケティングされているAPIは、すでに長年にわたり存在していたものです。言い換えれば、これは典型的なSalesforce流のマーケティング発表に過ぎません。）この新製品の背後にある理念は、エージェントが人間向けに設計されたUIを経由せず、直接システム・オブ・レコード内のデータにアクセスできるようになることです。
この発表は、さらに興味深い問いを引き起こします。「UIを剥ぎ取り、データベースをそのまま公開した場合、実際に残るのは何でしょうか？」それは、単なるPostgreSQLデータベース＋精巧に設計されたスキーマ＋APIと、どこが違うのでしょうか？システム・オブ・レコードの耐久性を支えてきた伝統的な要因は、今でも有効なのでしょうか？それとも、まったく新しい評価基準が登場しているのでしょうか？SaaS時代において、システム・オブ・レコードが防御力を備えていたのは、人間がUIという「界面」の中に生きているからでした。しかしエージェント時代には、この優位性は急速に弱まります。防御性の中心は、下位レイヤーではデータモデル・権限管理・ワークフロー・コンプライアンスへ、上位レイヤーではネットワーク効果・独自データ生成・現実世界での実行能力へと、それぞれ移動しています。
ソフトウェアが「頭部」を失ったとき、その防御性はどこへ向かうのでしょうか？
かつてUIこそが製品そのものだった
システム・オブ・レコードとは、特定の業務領域におけるデータの「唯一の真実の源」です。顧客関係、従業員記録、財務取引など、各ドメインの公式バージョンがここに格納され、他のツールが読み書きするための基盤となります。CRMは収益に関するシステム・オブ・レコードであり、HRISは人事に関するシステム・オブ・レコード、ERPは資金に関するシステム・オブ・レコードです。これらの強みは、単にデータを保存することだけではなく、組織全体の運営が依拠する「共有された現実」を形成することにあります。
過去20年間、Salesforceが販売してきたのは、「営業マネージャーがチームを管理する方法」でした。ダッシュボード、パイプラインビュー、予測ツール、アクティビティストリーム——これらこそが、ユーザーが実際に購入していたものでした。そのビジネスモデルは、ユーザーごとにライセンス（シート）を販売し、これらの機能へのアクセス権を提供することに基づいていました。裏側のデータベースは確かに不可欠ですが、あくまで付随的な存在でした。
つまり、UIこそが「定着力（Sticky-ness）」を生んでいたのです。UIはデータ規範を強制し、共通語彙（リード、商談、顧客など）を創出し、何千人もの営業担当者に本来なら入力しないようなデータを継続的に入力させました。UIは、データの一貫性を維持するためのメカニズムでした。この製品はあまりにも定着力が強く、多くの営業マネージャーが転職先でもSalesforceを持ち込むほどでした。それはUIが使いやすいからではなく、単に「筋肉記憶」になっていたからです。
エージェントは、こうしたパターンを根本から揺るがし始めています。エージェントはUIを経由せず、直接データベースを読み書きできるため、UIを完全に回避する新たなツールや迂回手段が次々と登場しています（Salesforceだけではありません。最近、SAPを取り巻くAI対応エコシステムの成長についても当社は記事を書いています）。コンピュータ操作型エージェント（Computer-Using Agent）は、従来の人間レベルの要素——たとえば個人の好み、トレーニング、文書化されていない文脈——を、時間とともに陳腐化させつつあります。言い換えれば、長期にわたって信頼されるシステム・オブ・レコードとなるために必要な条件は、まさに進化しつつあるのです。
歴史的評価指標
エージェント時代が何を変えるかを問う前に、まずそもそもシステム・オブ・レコードの定着力を支えてきた要因を正確に明らかにする必要があります。初期の評価項目は、主に人間がソフトウェアとどうインタラクションし、どのような好みを持つのかに焦点を当てていました。つまり、ソフトウェアの定着力は、UI、習慣、人間のワークフロー、埋め込まれたプロセスによって大きく左右されていたのです。
アクセス頻度はどの程度か？CRMは、GTMチームをはじめとする多数のユーザーにより毎日利用されます。このような高頻度の利用は、それをキーファンデーション・インフラストラクチャへと位置づけ、その上に構築された人間層——儀式、筋肉記憶、長年にわたって築かれてきたマネジメント・リズム——は、移行が極めて困難です。なぜなら、それらが「移行すべきもの」として認識すらされていないからです。
読み込み専用か、読み書き両用か？定着力のあるシステム・オブ・レコードは、必ず読み書き両用型です。たとえばCRMは、単なるアーカイブではなく、常に読み込まれています。通話記録、ステージ更新、タスク作成——すべての操作は誰かが入力しており（その人物は、自分が何をしているかを意識しています）。この双方向の流れがあるため、代替ソリューションは単なる履歴データのエクスポートではなく、リアルタイムの業務データを処理しなければなりません。安全な切り替えタイミングは存在しないため、一度導入された企業は、あるベンダーに留まる傾向があります。一方、採用管理システム（ATS）は読み書き両用ではなく、採用が完了した後はデータにアクセスする理由がほとんどありません。
内部および外部の依存性はどれほどか？核心的な問いは、「このシステム・オブ・レコードに、どれだけ多くの内部システム・チームのワークフロー・外部の関係者が依存しているか？」です。内部接続性とは、他のソフトウェアやワークフローといった下流のシステムとの連携を指します。外部接続性とは、監査人・会計士・規制当局など、データに直接アクセスする必要がある外部当事者（例：ERP）を意味します。いずれの次元においても、接続性が高ければ高いほど、移行時に解除しなければならない要素が多くなります。
コンプライアンス観点でデータはどれほど重要か？ここでの核心的な問いは単純です：「このシステムはコンプライアンス上、必須か？」給与計算・ERP・人事データなどのコンプライアンス・クリティカルなシステムは、法的に立証可能な「真実の源」、厳格な管理者アクセス制御、そして移行時における監査人・規制当局の直接関与を必要とします。これにより、これらのシステムの定着力は顕著に高まります。一方、営業データやZendeskのようなカスタマーサポートツールは、連続性や文脈の保持は重要ですが、データの移動やアクセス権限の変更に伴う規制リスクは存在しません。
すべてのシステム・オブ・レコードが同じ切り替えコストを持つわけではありません。CRMと採用管理システム（ATS）を、上記の同一の次元で評価すると、その差は明確です。ATSは「採用」という限定されたプロセスのためのワークフローツールです。候補者が採用または不採用となった時点で、そのレコードは基本的に「一度だけ書き込まれる」ものになります。統合範囲も狭く、ユーザー層も小規模かつ集中しています。
ERPは正反対の極端に位置します：帳簿そのものが監査の足跡であり、あなたの会計士・監査人・規制当局が、いかなる移行においても直接の関係者となります。ATSの変更は痛みを伴いますが、許容可能です。CRMの変更は開胸手術に相当します。そしてERPの変更は、患者がマラソンを走っている最中に開胸手術を行うことに等しいのです。
従来、システム・オブ・レコードは、独自データやネットワーク効果といった「モアトゥー（護城河）創造者」を活用していませんでした。ワークフローそのものが十分なモアトゥーを生み出していたからです。むしろ、消費者向けビジネスではツールとネットワークを一体化させてきましたが、歴史的にシステム・オブ・レコード・ソフトウェアはそうしてきませんでした。
独自データ（Proprietary Data） —— 多くのシステム・オブ・レコードは顧客データを収集しますが、それらのデータを実質的に処理することはほとんど行っておらず（契約上もできないことが多い）、たとえCRMが豊富なデータセットを保有していても、顧客横断的なインサイトを生成するために集約・活用したことは、ほとんどありません（SalesforceのEinsteinなど、いくつかの試みはありました）。
ネットワーク効果（Network Effects） —— 聖杯とされるべきネットワーク効果。CRMは、ソフトウェア販売者が買い手を見つけやすくなることで価値が高まります。データと同様に、歴史的なシステム・オブ・レコードにとってネットワーク効果は、せいぜい「弱い」にすぎませんでした。
では、UIが消滅し——エージェントが到来したとき、残るのは何か？
エージェントにはブラウザは不要です。必要なのはAPI、コンテキスト、指示、そして実行能力です。この規模での実現を可能にしたのは2つの要因です。第一に、LLMが推論能力において十分に高度になったこと。そのため、エージェントは現在、コンテキストを読み取り、計画を立て、ツールを選択し、操作を実行し、出力を検証するまでを、ほとんどのタスクにおいて人間の介入なしに行えるようになりました。第二に、MCP（Model Context Protocol）がツールへのアクセスを標準化し、エージェントが外部機能を呼び出すための汎用インターフェースを提供したことです。MCP対応のエージェントは、ブラウザを介さず、ミリ秒単位で人間ユーザーの作業を大規模に実行できます。適切なコンテキストがあれば、コンピュータ操作型エージェントは、APIさえ不要で既存のソフトウェアUIをナビゲートすることも可能です。
単純に見ると、ソフトウェア購入者は現在、以下の3つの道を選べます：
1）既存システム＋エージェント：既存ベンダーのCLIおよびAPIを利用する——自社のネイティブ・エージェント製品（SalesforceのAgentforce、SAPのJouleなど）を通じてもよいし、それらの上に自社でエージェントを構築してもよい。（現時点では、APIが完全に利用可能かどうか、あるいはヘッドレス化が表面的に見えるほど簡単でないかどうかは、一旦置いておきます。）
2）完全なDIYシステム・オブ・レコード：独自のデータモデル・業務ロジック・権限管理・監査ログ・統合機能などをゼロから構築し、さらに自社のエージェント（サードパーティのエージェント構築ツールやデータベースツールを活用する可能性あり）も開発する。
3）AIネイティブな代替製品の購入：エージェント時代のためにゼロから設計された、機械可読性を前提とした新世代ソフトウェアを購入する。エージェントのオーケストレーションを「追加機能」ではなく、コア機能として設計されており、ヘッドレスであることも可能です。
では、旧来の評価指標は、今も有効なのでしょうか？人間の行動や好みに起因する要素——たとえばアクセス頻度や「読み込み専用か／読み書き両用か」など——は、人間の筋肉記憶に関係するため、ほぼ消滅します。エージェントは、筋肉記憶を「モアトゥー」として殺してしまうかもしれませんが、代わりに「業務ロジック」と「文脈」は、むしろより重要なモアトゥーになります。なぜなら、エージェントが安全に動作するには、明確なルール・権限・プロセス定義が必要だからです。
未記録のSOP（標準作業手順）は短期的には依然として重要です。あなたのワークフロールールにコーディングされた組織の暗黙知こそが、エージェントがあなたに代わって正しく動作するために必要なものなのです。そして、これは再構築が最も困難な部分でもあります。特に、プロセスの一部がまだ人間の関与を必要としている場合、これをきれいにエクスポートすることはできません。ただし、コンテキストの把握は、エージェントがより多くの労働を代替することで、次第に容易になり、またその重要性は相対的に低下していきます。
接続性は、依然として切り離しが難しく、さらに広範囲に及ぶようになっています。接続性の評価基準は変化しています。もはや「人間のペースに合わせること」ではなく、「伝統的に孤立していた機能やソフトウェア間の接続性を維持すること」が焦点になります。CRMエージェントは、営業・請求・カスタマーサクセスのデータと文脈を統合的に組み立てる必要があります。もしプラットフォームが、複数の外部組織（バイヤー・セラー・パートナーなど）のエージェントが取引を行うノードでもあるならば、依存性はさらに深まります。既存ベンダーのエージェントは、多様な基盤ソフトウェアのプリミティブを横断して動作する際に大きな困難に直面します。同様に、DIYデータベースと一連のエージェントでも同様の課題があります。
コンプライアンス・クリティカルなデータは、依然として重要です。監査当局や法的・規制リスクを伴うデータには、単一の信頼できるデータソースが必要です。顧客が既存の製品を信頼している限り、切り替える可能性は低くなります。給与・会計データを例に挙げると、エージェントがこれらのデータにアクセスしたいと考えることはあっても、自社で構築・維持するのは極めて現実的ではありません。完全にエージェント主導の世界において、最も解決が難しい課題の一つは、「どのエージェントが誰に代わって何を実行する権限を持ち、その操作はどの程度監査可能か？」という問題です。エージェント間の相互作用におけるアイデンティティと権限を管理するシステム・オブ・レコードは、それが保持するデータではなく、むしろ実装する「信頼アーキテクチャ」によって、真に代替不可能な構造的役割を果たします。
将来を見据えると、AIネイティブなスタートアップの防御力を高める上で、次第に重要になっていく一連の要素があります：
システム・オブ・レコードの再構築はどれほど困難か？ —— データの重要性は、いくつかの形で高まっています。まず短期的には、システム・オブ・レコードの基盤データを抽出・再構築する難易度です。AIは、多くのツールを通じてこれを容易にしようとしています。短期的には、既存ベンダーは、APIを意図的に使いにくく・制限付き・不完全・あるいは経済的に非魅力的なものにすることで、これを難しくしようとします（そもそもAPIを提供するかどうかも含む）。しかし、抽出ツールの性能が向上し、特にコンピュータ操作型エージェントの精度が高まれば、これはますます容易になります。同時に、新興企業はメール・電話・音声エージェントおよび社内文書から、より豊かなデータセットを再構築しようとしています。AIは、システム・オブ・レコードの再構築コストの最初の80％を削減しています。残りの20％——例外ケース、承認フロー、コンプライアンス要件、エッジケースのワークフロー——こそが、単なる「便利な楔」ではなく、真の代替ソリューションと区別される決定的なポイントです。
有意義な独自データは存在するか？
第二に、データそのものがより興味深いものになっています。防衛可能なデータとは、あなたがインポートしたデータではなく、あなたの製品が独自に促進・生成するデータです。いわゆる「データの囲い込み（Walled Garden）」——専有性・規制対象・継続的な更新を要するデータのことです。権威的かつ完全なデータの収集に投資するソフトウェアベンダーは、汎用ベンダーやこうしたデータを持たない競合に対して優位性を有します。データを巡るもう一つの次元は、その生成が内部で行われる行為に依存する場合です。最高のビジネスは、単に他所から入力されたデータを保存するだけではなく、プロセスへの参加を通じて新たなデータ副産物を生み出します。これには、観察された行動・応答率・時間パターン・プロセス結果・ベンチマーク・異常パターン・エージェントのパフォーマンストラジェクトリなどが含まれます。鍵となるのは、データが今や「文脈そのもの」であるということです。
アクション層（実行層）を備えているか？
旧来の世界では、単に記録を保存しておくだけで十分でした。新世界では、エージェントが積極的に行動を起こします。防衛性は、アクション→結果のキャプチャ→フィードバックによる将来の意思決定の改善という「閉ループ」で動作する製品へと移行していくでしょう。ERPの場合、それは支出の承認・給与の発行・請求書の照合・通知の送信などです。この閉ループを完遂する製品は、単なる観察ではなく「実行の内部」に位置するため、より防衛的です。それらは独自のデータを生成し、使用とともに向上し、ワークフローを破壊せずに撤去することが極めて困難になります。ここでいう価値は、収集される文脈の量や処理されるエッジケースの数が増えるにつれ、当然ながら高まっていきます。
現実世界における実行要素を備えているか？
ビジネスモデルが、完全には自動化されない現実世界の運用と結びついているかどうかです。顕著な例はDoorDashのような運用ネットワークを構築した企業で、歴史的にはレコードシステムではありませんでしたが、ここでは非常に示唆的です。より広く言えば、サービス・履行・物流・現場運用・決済にまで及ぶソフトウェア事業は、純粋なSaaSとは異なる防衛性を有しています。これらの企業は、単に記録を保存したり行動を推奨したりするだけでなく、人員を派遣し、貨物を輸送し、サービスを完了させます。
開発者にとって、これはソフトウェアが判断を下し、エージェントが調整を行うことが増える中で、最後の「一マイル（Last Mile）」が依然として現実世界で実行される必要がある市場にチャンスが存在することを意味します。たとえば、現場サービスに関連する垂直特化型ソフトウェアなどが該当します。
ネットワーク効果はあるか？
歴史的に、大多数のレコードシステムのネットワーク効果は弱かったのは、ソフトウェアが主に内部で使われていたからです。しかし、エージェントの世界では、システムが多者間のワークフローに埋め込まれている場合、ネットワーク効果はより重要になる可能性があります。もしシステムが、バイヤーとセラー、雇用主と従業員、企業と監査人、サプライヤーと顧客、支払者と提供者といった双方の間で繰り返し行われるやりとりを仲介するなら、参加者が一人増えるごとに、ネットワークは次の参加者にとってより有用なものになります。
その一つの方法は、共有ワークフローの調整を通じてです。製品が、取引・文脈の交換・異常の解決のための両当事者の「場」になることです。二つ目は、ベンチマークとインテリジェンスを通じてです。システムは、ネットワーク内で観測されたパターンに基づき、標準値・異常・提案を提示することができます（これは前述のデータの観点とも連動します）。三つ目は、信頼と標準化を通じてです。取引当事者が、承認・引継ぎ・コンプライアンス・支払いなどのために、同じトラックを依存し始めると、製品は単なるデータベースではなく、市場そのものの調整インフラの一部となり、置き換えが極めて困難になります。
購入者の技術的能力はどの程度か？
理論的には誰でも自社のエージェントを構築できる世界においても、実際の購入者の構築能力には大きなギャップが存在します。特に、縦断的（垂直）市場や、歴史的に強い内部エンジニアリング資源を持たない職能部門の購入者において、自社のデータベース・ワークフローロジック・エージェントスタック・ガバナンス層を構築・維持・継続的に改善する可能性は依然として低いままです。コストも重要です：理論的にはDIYによりソフトウェアライセンス費用は削減可能ですが、実際には導入・維持・内部の複雑性への支出へと移行します。つまり、運用が複雑であるにもかかわらず技術支援が不足している分野——製造業・建設業のバックオフィス・工業・現場サービスのワークフロー・会計など——に、真に意義ある機会が存在します。
その他にも、ソフトウェアの基本要件となる重要な要素がいくつかあります。たとえば、オントロジー（概念体系）も変化する必要があります。「DIYデータベース」思考は、オブジェクトモデル自体が持つ価値を過小評価しがちです。既存のソフトウェアは、ダッシュボード・レポート・人間の視点で構築され、ワークフローを捉えるように設計されています。これには「商談」「チケット」「候補者」などが含まれます。一方、エージェント向けのモデルは、推論・行動・状態追跡・異常処理・委任・他システム間の調整を捉える必要があります。ネイティブなオブジェクトモデルは、「タスク」「インテント（意図）」「スレッド」「ポリシー」「結果」などへと変化していくかもしれません。
同様に、権限管理も、人間だけでなくエージェントを管理できるよう更新する必要があります。これは以下を含みます：誰が何を、どのエージェントを介して、どのようなポリシーの下で実行できるか、どのような承認が必要か、どのような監査ログが記録されるか、またロールバック／異常処理はどのように行われるか。
もちろん、これらすべてはコストという文脈の中で考えなければなりません（たとえば、エージェント／データベースの構築・維持コスト、APIアクセスコストなど）。これは、再構築の難易度や依存関係の数といった問いへと、再び帰結します。
では、私たちは今、どこに立っているのでしょうか？
既存ベンダーがヘッドレス化へと舵を切る中、彼らは「データ層が今後も価値の源泉であり続ける」という暗黙の賭けをしています。金融サービスなど、コンプライアンス規制が厳しい分野では、この賭けはしばらくの間成立する可能性があり、ヘッドレス化自体もまだ遠い未来かもしれません。ソフトウェア開発者にとっては、既存ベンダーのヘッドレス化への移行に競合しながら、持続可能なソフトウェアを構築する機会が変化しています。次世代のシステム・オブ・レコードは、すでにその姿を変え始めています：単に人間の業務を記録するためのデータ保管庫ではなく、エージェント性を備えたもの——文脈を捉え、業務を開始し、データの副産物を記録するものです。さらに、最も興味深いビジネスは、現場スタッフ・物流プロバイダー・サービスチーム・物理資産の調整や、多者間の仲介という、現実世界への実行を延長させたものになります。それらは旧来のビジネスモデルを混在させつつ、従来のレコードシステムの核であった「データ」を、背景に退けていくでしょう。
本稿の議論に貴重な思想的貢献をしてくださった@astrange氏に、心より感謝いたします！
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
a16z
