SaaSの生存を採点する（Part 1）：エージェント型AIが迫る三つの経路

※本記事は「ジェンセンの丁寧な警告——ソフトウェア産業を待つ「VAR化」」の続編にあたります。先にそちらをお読みいただくと、本稿の前提がより明確になります。

VAR化テーゼの要点

前稿「ジェンセンの丁寧な警告——ソフトウェア産業を待つ「VAR化」」で、我々はエージェント型AIがソフトウェア産業に何をもたらすのかについて、構造的なテーゼを提示しました。全文は上記リンクからお読みいただけますが、本稿を読み進めるうえで必要な範囲に圧縮すると、以下のようになります。

「AIトークンのVAR」という予告

出発点となる挑発は、ジェンセン・ファン氏による一見安心させるような主張です。ソフトウェア企業は「AIトークンの付加価値再販業者（VAR）」になるだろう、と。安心できる言葉に聞こえます——VARやSI（システムインテグレーター）がPER10〜15倍、EV/売上高0.5〜1.5倍で取引される一方、SaaSが歴史的にEV/売上高15〜20倍を確保してきたことに気づくまでは。文字どおりに受け取るなら、ジェンセン氏は産業全体に対する90%超のバリュエーション圧縮を、丁寧な言葉で予告したことになります。

その機構を、我々はVAR化と呼んでいます。AI以前のバリューチェーンにおいて、ソフトウェアベンダーは脳でした。標準化された製品、極端に高い営業レバレッジ、ほぼゼロの限界費用。一方VARとSIは手足であり、標準化されたソフトウェアでは届かない約10%のユースケース——コーナーケース、追加された複雑性、製品が届かないラストワンマイル——に対して、低マージンで労働集約的な統合作業を担っていました。いま、基盤モデルラボがその脳を奪いました。ソフトウェアベンダーに残されるのは調整の層であり、それは設定、手取り足取りのサポート、関係性の管理へと着実に外側へ押し出されていきます。まさにVARがかつて占めていた低マージン領域です。

「構築は安くなったが保守は高いままだ」という旧来の防衛線も崩れます。AIエージェントは、保守という作業の中身そのものである退屈で仕様が明確な仕事において、まさに卓越しているからです。

ハーネス・フライホイールという企業レベルの機構

産業全体のテーゼの下には、企業レベルの機構が横たわっています。ハーネス・フライホイールです。モデルラボはまずハーネス（モデルを実際に働かせるための周辺の仕組み一式）を設計し、次世代モデルをそこへ向けて訓練します。したがってラボは、次のリリースがどの製品的な回避策を不要にするのかを常に把握しています。アプリ企業は逆方向に働きます。現行モデルの弱点を外側から探り、その弱点を埋めるスキャフォールドを構築し、そして次のリリースがそのスキャフォールドのどれだけを無価値にしたのかを——他の全員と同じ瞬間に——知ることになります。一方は設計であり、他方は考古学です。そして考古学者は恒久的に遅れます。

そこから導かれる投資家向けの選別ルールが、「大脳はあなたの機能を吸収できるのか、それとも必要としているだけなのか」という問いです。最も曝露が大きいのは水平型のワークフロー・ラッパーと座席課金に依存する事業であり、エージェントはシートを買いません。一時的に保護されるのは真のシステム・オブ・レコードですが、それは債券的なキャッシュフローであって成長の物語ではありません。罠を逃れうるのは、本物のモデル層レバレッジを持つAIネイティブ企業だけです。

前稿が描いたのは行き先でした。本稿が扱うのは経路です。どの銘柄がどのバケットに、どの順序で、どの価格で辿り着くのか。そして、それに対して何ができるのか。

三つの経路

VAR化はSaaSを作り変える力を特定しました。次に問うべきは、その力が企業ごとにどう作用するかです。我々は2025年8月に、エージェント型への移行が取りうる三つの経路を整理しました。1年が経ち、証拠が揃ってきたことで、それぞれに重み付けができるようになっています。三つの経路はVAR化テーゼを置き換えるものではなく、拡張するものです。前稿で述べた圧力に、どの企業と顧客セグメントが屈し、どれが逃れるのか——その具体的な道筋を辿ります。

経路1：完全な内製置き換え

経路1では、社内のソフトウェア開発チームが自前のCRM、人事、チケッティングといったシステムを構築し、Claudeのようなエージェント型インターフェースを経験層として被せます。これはSaaSの100%置き換えにあたります。大幅なコスト削減——複数のSaaSアプリケーションにそれぞれ年間10万ドルを支払っている企業なら、内製化によって年50万ドル以上を削減しうる——を超えて、より重要な利点は実用性です。企業は自社固有の要求により適したシステムを構築でき、既製品ベンダーよりもはるかに速く新しい要件に応えられます。

企業の複雑性という障壁

しかし企業は膨大な複雑性を抱えています。経験層（UI）と保存層でSaaSを置き換えれば済むという単純な話ではありません。企業は数多くのセキュリティ認証とコンプライアンス認証を必要としますが、これは顧客データをSaaSベンダーが管理してくれる場合には、はるかに頭痛の種になりにくいものです。加えて広範なレポーティング要件が社内チームに降りかかります。

複雑性が低いぶん、中小企業のほうがSaaSベンダーを完全に置き換えるのは相対的に容易でしょう。ただしそこでは、中小企業が一般に開発人材——少なくともバックエンドシステムを理解し、エージェント型システムをつなぎ合わせられる人員——を保有しているのか、という問いが立ちます。フロントエンドをバイブコーディングすることと、システム全体を滑らかに動かすためのバックエンド要件をすべて処理することは、エージェントの支援があってもなお大きく異なります。すべてのシステムを社内で運用するには相応の人的チームとトークン予算が依然として必要であり、それは元のSaaSサブスクリプションよりも総コストが高くつく可能性さえあります——少なくとも現時点では。

障壁は固定ではなく浸食されていく

とはいえ、これらの制約が劇的に緩和されていくというのが趨勢です。将来のモデルが、複雑なコードベースに対する信頼できるエンジニアリング、自律的なバックエンド作業と保守、そして目的からほぼ人手を介さずに本番稼働するシステムまで到達する能力を解放するなら——あるいは単にそれらを大幅に簡単かつ安価にするだけでも——経路1のハードルは大きく下がります。AI進歩の速度は、近くで追っていない人ほど驚かされる性質のものです。ここでは前向きな視点が欠かせません。

こうした理由から、我々は経路1が近い将来に広く普及する可能性は低いと考えています。しかし障壁は固定されているのではなく浸食されつつあり、その浸食の速度は多くの人が想定しているより速いかもしれません。前稿で論じたとおり、「構築は安いが保守は高い」という伝統的な防衛線は崩壊しつつあります。エージェントは、保守という作業の中身そのものである退屈で仕様の明確な仕事にこそ卓越しているからです。

中国という先例

すでに経路1が常態となっている大きな経済圏が一つあります。中国です。中国企業はSaaSを意味のある規模で採用しませんでした。SaaSを西側で合理的なものにしていたトレードオフが、そもそも中国では成立しなかったからです。エンジニアリング人材は潤沢かつ安価であり、最大の顧客は自社のワークフローに合わせて構築されたシステムを望みました。内製したほうが単純に得だったのです。

これはSaaS投資家にとって居心地の悪い含意を持ちます。この産業の並外れた経済性は、西側市場に固有の二つの条件——中堅の買い手が豊富に存在することと、開発者が不足していること——の上に成り立っていたのかもしれない、ということです。エージェントはいま、その開発者不足を世界中で同時に取り除きつつあります。西側のエンタープライズソフトウェアが、その逆ではなく、中国型のパターンへ向かう可能性が浮上します。第一の条件も同じく重要です。中国にはSaaSの中核顧客である中堅企業がほとんど存在せず、これは「買う」という判断が市場の中位層で最も強固に保たれるという、我々の以前の指摘を補強します。

「中国に世界的なソフト企業がない」という反論

明白な反論は、もし社内構築がそれほどうまくいくのなら中国には世界水準のエンタープライズソフトウェアが存在するはずだが、実際には存在しない、というものです。このアプローチが生んだのは重複した労力、ばらつく品質、そして輸出可能なチャンピオン企業の不在でした。

しかしこれらの欠点は、モデルではなく人間の労働から来ています。安価なエンジニアであっても複利では積み上がりません。各社の独自スタックは行き止まりであり、その教訓は一つの組織の内側に閉じ込められます。エージェントは違います。使用によって改善し、ほぼゼロの限界費用で組織間を移転します。したがってカスタマイズは残り、重複は残りません。経路1の障害は今日においては現実のものですが、それらはコストの問題であり——そして中国は、そのコストが下がったときに何が起きるのかを示しています。

経路2：ヘッドレスの道

経路2では、企業はOpenClawやClaudeのようなエージェント層を使って、既存のSaaSアプリケーションすべてとやり取りします。これはおおむね50%のSaaS置き換えと見ることができます。経験層は完全に置き換えられる一方、機能・ワークフロー・データはSaaSベンダーの手元に残ります。

ヘッドレスという言葉が企業向けSaaSに届いた

ソフトウェア産業は長らく、独自のUIを持たずに動くシステムを指して「ヘッドレス」という言葉を使ってきました。ヘッドレスブラウザ、ヘッドレスCMS、ヘッドレスコマース。新しいのは、それがエンタープライズSaaSに到達したことです。セールスフォース（CRM）、サービスナウ（NOW）、マンデー・ドット・コム（MNDY）といった既存企業は、これが自らの帰結でありうることを受け入れ、従来のUIを不要とし、すべてのワークフローをサードパーティのエージェント型インターフェース経由で指示できるヘッドレス版を提供し始めています。

論理は単純です。エージェントは従来型のUIとうまく働きません。マウスを操作し、ダッシュボードを辿り、ボタンを押すようには設計されていないからです。ヘッドレスはその摩擦を取り除き、エージェントが基盤機能と直接やり取りできるようにします。トークンを大量に消費するツール呼び出し（ブラウザ操作、コンピュータ操作、マウス制御）を回避できるため、作業はより速く、より低コストで完了します。大手既存企業から既にヘッドレス版が出てきていること自体が、これがエージェント型AI下でのSaaSの最も一般的な進化形であることを示しています——我々が昨年予測したとおりに。

ヘッドレスが既存企業の地位を守らない二つの理由

二つの留保が、ヘッドレスによって既存企業の地位が確保されることを妨げます。いずれもVAR化の枠組みから直接導かれます。

第一に、機能の50%を保持することは、価値の50%を保持することを意味しません。経験層は顧客との関係、日々の習慣、そして座席を担っていました——そしてエージェントは座席を買いません。したがって既存企業は、機能スタックの半分を保持しながら、経済性の半分よりはるかに少ない部分しか保持できないことになります。機能面での50%置き換えが、前稿で述べたはるかに大きなバリュエーション圧縮と完全に整合するのは、このためです。

第二に、50%はスナップショットであって終着点ではありません。前稿で論じたとおり、新しいモデルがリリースされるたびに、かつてソフトウェアベンダーの領分だった機能、ワークフロー、あるいは製品まるごとが吸収されていきます。大脳は、手足が自分のものだと思っていた領域へ拡大し続けます。ヘッドレスは今日の線がどこにあるかを定義するだけで、その線が動くことを止める働きは何一つ持ちません。

経路3：既存企業自身がエージェント層になる

経路3では、SaaSの既存企業が自らエージェント型インターフェースになろうと試みます。現実的に成功の見込みがあるのは、最良で、最も革新的で、最も動きの速い既存企業だけであり、現状ではほとんど誰もこれを成し遂げられそうにないように見えます。

オーケストレーションという第二の機会

とはいえ、最近のトークノミクスへの再注目は、既存企業に第二の機会を与えたかもしれません。オーケストレーション——具体的には、ワークフローとタスクを最も適した基盤モデルへ振り分け、モデル間で性能を比較し、コストと品質を継続的に最適化すること——には相応の価値がありうるからです。

その汎用版は既に存在します。Arena AI、OpenRouter、OpenCodeは、あるユースケースに対してモデルを比較・切り替え・自動選択することを可能にしますし、BasetenやFireworksのようなプラットフォームはさらに踏み込んで、RLによる事後学習によってモデルを固有の要件に適合させられるようにしています。SaaSの既存企業は、これらの能力をドメイン特化のルーティング、評価、継続的改善の層へと専門化させるうえで有利な位置にあります。彼らは純粋なモデル企業やエージェント企業よりもドメインとワークフローを深く理解しており、したがって汎用インフラの上に乗る垂直特化の最適化プラットフォームを構築できます。

単一ドメインという根本的な限界

根本的な限界として残るのは、大半の既存企業が、企業の使うSaaS全体の幅に比べて狭いドメインしか担当していないという点です。スケーラビリティと使い勝手の観点から、企業が理想とするのは、人事、チケッティング、営業、業務調整といった一般的なドメインすべてを横断して仕事を完了できる単一のエージェント型インターフェースです。利用者はそのインターフェースに、複数部門にまたがるエージェントを立ち上げさせる必要があり、その一部はどのSaaSベンダー1社の守備範囲にも収まりません。たとえばセールスフォースのエージェント層であっても、サービスナウやマンデー・ドット・コム、アドビ（ADBE）の基盤機能に接続する必要が生じます。主要な既存企業がそれぞれ自分こそがエージェント層だと主張し始めれば、結果は混沌としかねず、誰が勝つのかも判然としません。

(出典: Convequity)

経路の重み付け

整理すると、経路1は経験層・機能層・データ層のすべてを置き換えるもの、経路2は経験層を置き換え（ヘッドレス化）、ワークフロー・機能・データの各層は——少なくとも当初は——SaaSベンダーに残るもの、経路3はSaaSの既存企業が自らのエージェント層を開発し支配するものです。現時点では経路2が最も可能性の高い近未来の進化形に見えます。実際には企業ごとに異なる経路へ着地することになり、どの経路に至るかが、その企業がどのVAR化バケットに属するかを大きく決めます。

経路2は終着点ではなく出発点です。ひとたび経験層が明け渡されると、ワークフローと機能の層そのものが係争地になります。大脳が下方向へどこまで拡大するのかは、アクセス、ガバナンス、ドメイン知識、コストをめぐる、SaaS既存企業・モデル企業・企業顧客の三者間の力学次第です。

規制の厚い領域では経路3もありうる

ERP（SAP）のような高度に規制された領域では、経路3が依然として現れる可能性があります。経路1は社内チームには負担が重すぎます。セキュリティ認証、監査要件、データレジデンシー規則、継続的なコンプライアンス作業の総量は、エージェントの支援があっても大半の企業が自前で管理するには多すぎるのです。（中国では、まさにこれらの業務を担う専門のコンプライアンスソフトウェアベンダーが並行産業として育ちましたが、それらの企業が洗練されたテクノロジー企業であることは稀で、まず規制の専門家です。西側で同等の負担が生じれば、それはほぼすべて企業自身に降りかかります。）

一方、純粋な経路2は高度に規制されたデータをサードパーティのエージェント型インターフェースに開くことになり、リスクが高すぎます。こうしたケースにおける最良の結末は、エージェント型の経験層と基盤の配管の両方を保有する、能力ある既存企業です。システム・オブ・レコードとしての深さ、コンプライアンス要件、データの重力は時間を買ってくれます。決定的な問いは、その猶予期間を使って自前のエージェント層を構築し保有し——成長の物語を維持できるのか、それとも保護が浸食されるまで単に地代を回収し、VAR化の既定路線である債券的なキャッシュフロー像へ落ち着くのか、です。薄く、規制の軽いデータの堀しか持たない既存企業には、そもそもこの選択肢すらないと考えられます。

ヘッドレスの道でも圧力は強まる

ヘッドレスの経路を辿ったとしても、圧力は強まっています。セールスフォースのような大手既存企業のヘッドレス提供物よりも、よりクリーンで安価な解を届けられるヘッドレスネイティブのスタートアップが既に現れつつあります。経験層が剥ぎ取られると、残された配管はまさにこの種のコモディティ化に対してより無防備になります——これも同じVAR化の力の、別の現れ方です。

コモディティ化の問いと「逆情報パラドックス」

経路2の下で最も重要な未解決の問いは、知性がコモディティ化するのかです。もしコモディティ化するのであれば——絶対的なフロンティアにおいてではなく、任意のドメイン内における大半の作業について——SaaSの既存企業は差別化された価値をより多く保持できるはずです。彼らはワークフローの知識、データ、そして極めて固有性が高く基盤モデルが保有していない業務上の機微を握っています。エージェント層はどれも似たようなものになり、希少な資産は生の知性ではなくドメイン知識になります。

ハーネス・フライホイールが反論する

しかし前稿で述べたハーネス・フライホイールは、そこに寄りかかることに反対します。セールスフォースやサービスナウなどがヘッドレス化し、サードパーティのモデルが顧客のデータとワークフローに触れることを許すとき、彼らはまさにそのドメイン知識がラボへ漏れ出す経路そのものを開いているからです。ユーザーのプロンプトと日々の業務の流れを通じて、モデルは既存企業のドメイン——あるいは企業顧客のドメイン——へ踏み込むのに十分なだけを学習しうるのです。我々はClaudeとFigmaの間で、この力学の初期形を既に目にしていますし、歴史にも先例があります——マイクロソフト（MSFT）とWordPress、マイクロソフトとLotus。ヘッドレスが必要とするアクセスは、それが守ろうとした優位性を浸食するアクセスと同一のものなのです。

サティア・ナデラ氏が最近提唱した逆情報パラドックスは、同じ論点を企業側から述べたものです。このパラドックスは、企業が自社独自のカスタムワークフローをサードパーティのAIツールに投入すると、競争優位を失うリスクを負う、というものです。そうすることで企業は事実上二度支払うことになります。一度目は自らの組織的知識を体現するシステムを構築ないし購入するために、二度目はその同じ知識が外部モデルの訓練や改良に使われ、後にそのシステムを再現ないし置換しうる形になることによって。

ガバナンスという具体的な論点

ここでガバナンスの問題が具体的になります。企業がAIを自社データへ安全に接続するには——セキュアに、プライバシーを最優先に、従業員がAIに何を依頼してよく何を依頼してはならないかを適切に統制し、独自の組織的知識を境界の内側に留めたうえで——それを正しく実行できる企業が必要です。我々が2023年から述べているとおり、現時点でこの役割を要求水準で果たせる位置にいるのはPalantir（PLTR）だけです。これは大脳が吸収するのではなく必要とする機能であり、まさにその点がVAR化の下でこの機能を持続的なものにしています。

ヘッドレスは安定した終着点なのか

三つの経路をまとめると、本稿の中心にある構造的な問いが浮かび上がります。ヘッドレスという均衡は、SaaSが落ち着く場所なのか、それとも通過するだけの段階なのか。

今日の経路1を非現実的にしているコンプライアンス、レポーティング、バックエンドの負担は、エージェントが保守作業を吸収するにつれて浸食されていきます。既存企業にとって経路2を持続可能にするはずの知識の封じ込めは、AI主権がナデラ氏の枠組みの上だけでなく実務として達成可能かどうかに依存します。そして経路3は、縮小しつつある少数の既存企業にとってのみ可能性として残ります。

我々のベースケースは依然として経路2が近未来の支配的な進化形というものです。しかしVAR化の力が意味するのは、50%という線が動き続けるということです。投資家が価格に織り込むべきなのは、その線がいま置かれている場所ではなく、向かっている先です。

次回のPart 2では、この構造変化が価格決定力とマージンにどう作用するのか、そして誰が受益者になるのかを整理したうえで、上場SaaS 22社を採点したVAR耐性スコアカードの結果をご紹介します。