12月16日、Martin Alderson氏が「AI agents are starting to eat SaaS」と題したブログ記事を公開し、海外で話題を呼んでいる。この記事では、AIエージェントがSaaS市場の需要構造とビジネスモデルを侵食しつつある状況と、その経済的・技術的な帰結について詳しく紹介されている。以下に、その内容を紹介する。
「ソフトウェアが世界を食べた」の次に来るもの
過去15年ほど、「ソフトウェアが世界を食べる」というフレーズで象徴されるように、あらゆる産業がSaaSを中心としたソフトウェアに飲み込まれてきた。小売、メディア、金融など、多くの業界でSaaSツールが乱立し、その集合としては数兆ドル規模の価値が積み上がっている。
筆者が前回の記事で論じたのは、「AIコーディングエージェントによってソフトウェアのコストが90%下がったのではないか」という、供給側の変化であった。今回はその延長として、「その前提が本当に成り立つなら、SaaSツールに対する需要側はどう変わるのか」という、二次・三次効果に焦点を当てている。
結論として筆者は、「ソフトウェアが世界を食べたが、次はエージェントがSaaSを食べる」と表現している。
見え始めているシグナル
「まずSaaSを探す」が消えつつある
最初のシグナルは、特に「シンプルな」SaaSへの需要が静かに蒸発しつつあることだと筆者は述べる。
かつてなら「この作業をやりたい → フリーミアムか有料のSaaSを探す」という流れだったタスクの多くが、いまは「エージェントに数分で作ってもらう」方向に切り替わっている。しかもその変化に、自分自身もしばらく気づかなかったという。
- 社内ダッシュボードが欲しければ、外部サービスを検討するのではなく、自分でさっと作ってしまう。
- 動画の再エンコードが必要なら、外部の変換SaaSを使わずに、Claude Code に ffmpeg の堅牢なラッパーを書かせれば済む。
その方が、ファイルを外部サービスに送る帯域・速度・料金・APIの学習コストなど、多くの負担を回避できる。
ここでは「SaaSを使わない」という選択が、コストだけでなく思考のシンプルさという観点でも勝ち始めている。
デザインツールやプレゼンツールも侵食対象になる
さらに、この傾向は「純粋なソフトウェア開発」から少し外れた領域では一層顕著であるという。
- Gemini 3 にUI/UXのモックやワイヤーフレームを数分で作らせれば、別のデザインSaaSを探したりテンプレートを漁ったりする必要がない。
- プレゼン資料を作りたいときも、専用のスライドプラットフォームに頼らず、Markdownで書いた内容をClaude Codeに渡し、きれいにデザインされたPDFとして出力させればよい。
こうした作業は、これまで多数のSaaSが狙ってきた「簡単で便利」な領域だったが、エージェントにとっても「簡単で自動化しやすい」領域であるがゆえに、真っ先に置き換えが進んでいる。
エンタープライズSaaSの更新見直し
もう一つ重要な変化として、エンタープライズ向けSaaSの更新提案に対する態度変化が挙げられている。
SaaSベンダーXが、例年通り二桁％の値上げを含む更新見積を出してきたとき、これまでは「まあそんなものだ」と受け止められていた。しかし最近では、社内のチームが本気でこう自問し始めている。
「この金額を払う必要が本当にあるのか？
エージェントを使って、自分たちで必要なものを構築できないか？」
1年前なら、これはせいぜい「仮に考えてみるだけ」の問いで済み、「やはり無理だ」という結論に落ち着いただろう。だが今は、実際に選択肢として検討するに値する現実的な案になりつつある。
「自社専用ツール」で失われるものと得られるもの
多くのSaaSには、実際には使われていない多数の機能が含まれている。プロダクトエンジニアリングの複雑さのかなりの部分は、この「誰かにとっては必要だが他の多くの顧客には不要な機能」を同居させながら、全体を破綻させないようにすることに由来する。
しかし、自社で1社専用の内製ツールを作る場合、顧客は自分たちだけであり、不要な機能を抱え込む必要はない。プロダクトロードマップも自分たちだけで決定できる。SaaSプラットフォームとの比較で言えば、
- 機能の複雑さを抑えられる
- 必要な改善に自分たちのペースで着手できる
という利点がある。エージェントの存在によって、こうした「自社専用ツール」を作るハードルが下がったことが、SaaSへの需要を静かに削り始めている、というのが筆者の観測である。
「メンテナンスは誰がやるのか？」という正当な異議
当然ながら、すぐに出てくる反論がある。
「内製アプリを増やしたら、誰がそれをメンテナンスするのか？」
バグ修正、スケーリング、セキュリティパッチなどの問題は、エージェントが登場しても消えるわけではない。ここに対して筆者は、いくつかの観点から整理している。
SaaS側のメンテナンスも決して理想的ではない
まず前提として、多くのSaaSは決して「完璧にメンテナンスされている」とは言いがたい、と筆者は指摘する。むしろ高額なものほど品質が悪いケースも少なくないという。
また、セキュリティリスクという観点では、「外部の第三者サービス自体に、自社の内部データへアクセスさせる必要がある」という構造が問題になる。もし自社ツールとして構築し、既存のVPNやアクセスコントロールの裏側にすべて閉じ込めることができれば、攻撃対象領域（attack surface）をかなり縮小できる。
エージェントがメンテナンスコストそのものを下げる
次に、エージェントがメンテナンス作業のコストを大幅に下げる点が挙げられる。たとえば、サポートの切れたライブラリから、サポート状況の良い別のライブラリに乗り換えるような、これまで最も厄介だった作業は、特に静的型付き言語のエコシステムにおいて、エージェントの助けを借りればかなり容易になる。
また、「社内ツールを1人のエンジニアだけが理解していて、その人が退職すると何もわからなくなる」というバス係数の問題も、エージェントの存在で緩和される。エージェントは退職しないし、よく設計された AGENTS.md のようなドキュメントがあれば、将来別の人間にもコードベースの全体像を説明できる。
SaaSのメンテナンスが引き起こす問題もある
SaaS側に依存しているがゆえに発生するメンテナンス問題もある。
筆者が最近聞いた例として、あるSaaSベンダーが既存のAPIエンドポイントを非推奨とし、新しいAPIセットに移行すると決めたケースが挙げられている。新APIは旧APIと完全な互換性を持っておらず、利用企業にとっては、重要なシステムを全面的に改修・テスト・リリースし直す必要が生じた。
このように、「SaaSを使っているからメンテナンスから解放される」というわけではなく、ベンダー側の都合による大規模なメンテナンスイベントに巻き込まれるリスクも存在する。
技術力のある組織ほど発想が変わる
筆者は、中小企業でソフトウェアの知見がほとんどない組織が、明日からSaaSを捨ててすべてを内製するようになるとは考えていない。
しかし、ある程度の技術的な理解と開発能力を持つ組織では、SaaSの調達やベンダーのライフサイクルを、これまで以上にクリティカルに検証するようになるだろうと見ている。
SaaSビジネスモデルへの経済的インパクト
SaaS企業の評価額（バリュエーション）は、ざっくり言えば次の2つの前提に支えられている。
- 高い顧客成長率（新規顧客の獲得が速いこと）
- 高いNRR（Net Revenue Retention、ネット売上継続率。しばしば100%超）
エージェントの浸透は、この両方に影響を与え得る。
新規需要の減少
すでに、一部のツールやアプリのセグメントでは、新規顧客からの需要が減少し始めている。これは、SaaS企業にとっては新規顧客の獲得コスト（営業・マーケ予算）の増大につながる。
より致命的なのはNRRの悪化
ただし、筆者がより深刻だとみなしているのは、NRRの低下である。
NRRは、既存顧客の売上が時間とともにどう変化しているかを表す指標であり、
- 100%なら、既存顧客群からの売上が変わっていない
- 100%未満なら、売上減少や解約が起きている
- 100%以上なら、席数追加や上位プランへのアップグレードにより、既存顧客からの売上が伸びている
ことを意味する。
理想的なSaaS企業の多くは、このNRRが100%を大きく上回っている。企業が成長すればユーザー数が増え、より高価なプランや追加機能を購入してくれる。その増分は、既存顧客との関係性の上に乗るため、営業・マーケに大きな追加投資をせずとも得られる、非常に利益率の高い売上である。
しかしエージェントが選択肢に入ると、こうした「拡大分」が狙われる。
- 次の料金ティアに上がらないように、機能の一部を自社の内製プラットフォームに移す
- SaaSからデータだけAPI経由で取り込み、社内のダッシュボードや分析基盤を立てて、ユーザーライセンスの大半を削減する
といった動きが起きると、NRRは確実に下振れする。高NRRを前提にしたバリュエーションを持つSaaS企業ほど、この変化の影響を強く受ける可能性がある。
それでもSaaSに残る「堀」
とはいえ、全てのSaaSが同じように「エージェントに食べられる」わけではない。筆者は、依然として強いモート（堀）を持つ領域も明確に整理している。
高い可用性とSLAが求められる領域
まず挙げられるのは、非常に高い稼働率とSLAが求められるサービスだ。いわゆる「4ナイン（99.9999%稼働）」「5ナイン（99.99999%稼働）」を満たすシステムを作るのは難しく、高可用性アーキテクチャの設計・運用には高度な専門知識が要る。
決済処理などのコアインフラはその典型であり、Stripeのようなサービスは、少なくとも現時点ではエージェントで容易に代替できるものではないと筆者は見ている。
超高ボリュームのシステムやデータレイク
トランザクション量の多いシステムや巨大なデータレイクも同様である。巨大なデータセットや高頻度トランザクションを扱うクラスターを構築・運用するのは容易ではなく、多くの組織にとっては手の届かない専門領域であり続ける。
ネットワーク効果とエコシステム
強いネットワーク効果を持つソフトウェア、特に組織外の人々ともコラボレーションするようなツールも、内製化が難しい。
Slackのようなサービスはその代表例であり、単にチャットアプリを立てれば代替できるものではない。豊富な連携機能やプラグインマーケットプレイスを備えた製品も、同様に強い優位性を持つ。
独自データセット・規制・コンプライアンス
独自のプロプライエタリなデータセットを持つ企業も引き続き価値が高い。金融データや営業インテリジェンスなどはその例であり、エージェントはむしろこうしたデータを活用することで、これらのサービスへのロックインを強める可能性がある。
加えて、多くの業界では規制やコンプライアンス要件が厳然として存在する。これらを満たす仕組みを一から構築するのは容易ではなく、ここもSaaSが強みを維持しやすい領域である。
SRE/DevOpsの需要増加
一方で、エージェントが生成した内製アプリ群を運用するためには、そのスキルを持つ人材が必要になる。
- SREやDevOpsに関わるプロダクトや人材の需要は、むしろ増加する
- 企業内には、こうした新しいアプリ群の運用だけを担当する専門チームが生まれるかもしれない
もちろん、その分のコストは発生するが、既存のSRE/DevOps機能で吸収したり、新たな人員・インフラが必要な場合でも、多数のアプリに跨って費用を平準化できる、と筆者は見ている。
もっとも危険にさらされるSaaSはどれか
筆者が「本当に危ない」と考えているのは、バックオフィス系のツール群である。具体的には、
- 本質的にはCRUDロジックに過ぎない
- 顧客自身のデータの上に、簡易なダッシュボードや分析画面を載せただけ
といったタイプのSaaSだ。
こうしたツールは、顧客側のワークフローや要望に「微妙に合わない」ことから、しばしば摩擦の源になる。エージェントに対して、既存システムの構造や現在の痛点をきちんとドキュメント化して渡せば、「不満な部分を取り除いたクローン」を作らせるのは比較的容易である。
つまり、エージェントにとって最も作りやすく、顧客にとっては最も置き換えたい種類のSaaSが、もっとも早くリスクにさらされることになる。
結局、何が変わり、何が残るのか
SaaSそのものが死んだわけではない。大きな技術的シフトのたびにそうであるように、勝者と敗者が入れ替わるだけである。
ただし、明確なモートや独自の知識を持たないSaaSにとって、これからのハードルは確実に上がる。筆者自身も、
- 今は「エージェントには複雑なDBクラスターの運用は無理だろう」と仮定しているが、
- それすらもそう遠くない将来に崩れるかもしれない
と見ており、エージェントがバリューチェーンの上流へどれくらいの速さで到達するかを見極めるのは難しいと述べている。
すべての企業が一斉にSaaS支出を代替できるわけでもないだろう。むしろ、
- 強い内部技術力を持つ企業
- そうでない企業
の間で、さらなる分断が進む可能性が高い。前者はエージェントと内製ツールを活用してコストと柔軟性で有利に立ち、後者はSaaSプロバイダが失った売上を補う対象として、より高い料金に晒されるかもしれない。
最後に筆者は、SaaSプロダクト側に突きつけられる現実を、次のようにまとめている。
もしあなたのプロダクトが、請求システムの上に薄くかぶせたSQLラッパーに過ぎないのだとしたら、
いまや競合は無数にいる。
それは市場の他社ではなく、「金曜の午後に少し時間が空いた、顧客企業のエンジニアとそのエージェント」なのだ。
詳細はAI agents are starting to eat SaaSを参照していただきたい。
