15 ポイント 投稿者 flowkater 2026-03-27 | 2件のコメント | WhatsAppで共有

1. SaaSは死んだという主張の背景

  • 最近、Claude Code、Copilot、Codex のようなAIコーディングツールが急速に進化する中で、「いまやソフトウェアは数行のプロンプトで作れるのだから、SaaSはもう終わりではないか」という主張に勢いがついている。
  • 実際、リード・ホフマンは、Claude Code に関する1つのツイートだけでSaaS株が5%下落するほど、市場がこのナラティブに敏感に反応したと指摘している。
  • ただし彼は、ここで市場が 現象を過大解釈している と見ている。AIがソフトウェアの生産方式を大きく揺さぶっているのは事実だが、それがすぐにSaaS業界全体の死を意味するわけではないということだ。
  • つまり出発点は「AIは脅威ではない」ではなく、「脅威の方向を読み違えている」 という批判に近い。
  • 彼の問題意識は明確だ。いま崩れているのはSaaSそのものではなく、過去20年間通用してきたSaaSの古いプレイブックだということだ。

2. 古いSaaSの堀(Moat)の弱体化

  • ホフマンは、過去にSaaS企業が高いマージンを享受できた理由について、安定した製品を作りスケールさせられるエンジニアリング組織そのものが強い参入障壁だったからだと見ている。
  • 言い換えれば、「このレベルの機能を安定して実装・運用できるチームを持っている」ということ自体が堀であり、だからこそ40〜50%水準のマージンも正当化できた。
  • しかしAIが実装速度を引き上げるにつれて、純粋なエンジニアリング労働力から来る防御力 は確実に弱まっている。
  • そのため彼は、過去20年間SaaSを定義してきた事業モデルが、もはやそのまま維持されるのは難しいと認めている。
  • ただしここで重要なのは、マージン低下と堀の弱体化は、すなわち死ではない という点だ。
  • 「古いSaaSモデルが崩れる」という診断と、「もはや誰もソフトウェアにお金を払わない」という結論の間には大きな論理の飛躍があり、ホフマンはまさにその飛躍を問題視している。
  • つまりAIはSaaSの経済性を再構成するが、それがただちにソフトウェアビジネス自体の消滅へとつながるわけではない、という立場だ。

3. ソフトウェアビジネスに対する根本的な誤解

  • ホフマンによれば、多くの人はソフトウェアを「一度作れば終わりのコードの塊」のように誤解している。
  • しかし実際のエンタープライズソフトウェアは単なるコードの成果物ではなく、保守・検証・セキュリティ・コンプライアンス・運用安定性・継続的改善を絶えず必要とする 生きたシステム だ。
  • たとえば誰かが「うちの会社のCRMや給与システムも、ただバイブコーディングすればいいのでは?」と言うかもしれないが、実際の企業環境ではセキュリティと規制リスクが致命的なため、そう単純には置き換えられない。
  • 特にHR、給与、未払金、会計、エンタープライズCRMのように企業の中核業務を扱うシステムほど、「動く」ことと「運用可能な水準にある」ことの間には非常に大きな隔たりがある。
  • したがって、プロンプトだけで機能デモを作ることと、企業が実際に信頼して対価を払えるシステムを運用することは、まったく別の問題だ。
  • ホフマンはこの点で、AI楽観論者たちが コード生成の容易さと製品運用の難しさ を混同していると見ている。
  • 結論として、AIはソフトウェアをより作りやすくするが、ソフトウェアビジネスの責任構造まで消し去ることはできない。

4. 新たな競争上の堀: AI生成性(AI Generativity)

  • ホフマンが語る本当の変化は、「SaaSの消滅」ではなく 競争上の堀の中心が移動している ということだ。
  • 今後強いSaaS企業は、単に機能を提供する会社を超えて、そのカテゴリの業務をAIでよりうまく遂行できるよう設計されたシステムを提供する会社になる。
  • 彼はこれを AI生成性(AI Generativity) という概念で説明している。つまり製品に組み込まれたAIが、そのドメイン特有の要求をどれだけ深く理解し、繰り返しより良い結果を生み出せるかが、中核的な競争力になるということだ。
  • 例としてCRM企業を考えると、単に顧客データを保存・参照する機能だけでは弱くなる。
  • 代わりに強いCRMは、次のような要素を持つことになると見ている。
    • 営業ワークフローを反復的に洗練させるインテリジェントエージェント群
    • 人間のアナリストよりも包括的にパイプラインを理解するシステム
    • そのドメイン向けに特別設計された強力なバックエンドライブラリと運用構造
  • こうした製品は、単純なCRUD SaaSよりはるかに強い堀を持ちうる。
  • 結局これからの勝負は、「AIを導入したかどうか」ではなく、ドメイン深くに最適化されたAIシステムを製品の本体にできているか にかかっている。
  • ホフマンは、この変化を理解する既存プレーヤーは進化し、理解しないプレーヤーは実際に衰退し、あるいは死に至るだろうと見ている。
  • ただし、その衰退でさえ市場が想像するように一気に起こるのではなく、思われているよりもはるかにゆっくり進む可能性が高いと付け加えている。

5. ビジネスモデルの転換

  • 製品構造が変われば、経済モデルもそれに合わせて変わる可能性が大きい。
  • ホフマンは、従来のSaaSの席数ベースのサブスクリプションモデルがすべてではなくなり、今後は顧客が トークン予算や計算消費量を前払いするユーティリティ型モデル がより多く登場しうると見ている。
  • たとえばAIネイティブCRMでは、単に「何人のユーザーがアクセスするか」よりも、システムが実際にどれだけの計算と自動化を実行したかが、価格体系におけるより重要な基準になりうる。
  • つまりサブスクリプション型ソフトウェアがなくなるのではなく、コンピューティング消費ベースの経済モデル へ再編される可能性があるという話だ。
  • 彼は、こうした転換は目新しく見えても、実は初めてのことではないと言う。
  • 過去にオンプレミスソフトウェアからクラウドSaaSへ移行した時も、既存ビジネスモデルが崩れるという恐怖は大きかったが、結果として市場は終わらず、むしろさらに拡大した。
  • 今も同じように、私たちは「クラウドSaaS → AIネイティブソフトウェア」という類似した転換の入り口にいるということだ。
  • したがって重要な問いは、「SaaSは死ぬのか」ではなく、新しい単価構造と価値測定の仕組みは何になるのか に近い。

6. 既存の堀は依然として有効

  • ホフマンは、AI時代が来ても既存の堀が完全に消えるわけではないと強調する。
  • 代表的には、ネットワーク効果、顧客関係、データ優位性といった要素は依然として重要であり、むしろ場合によってはより強力になりうる。
  • 特に固有のデータソースは、AIがそのデータの上で学習・調整できるとき、以前よりも大きな価値を持つようになる。
  • 企業固有のワークフローや運用コンテキストに合わせて長年蓄積されたデータをもとにAIシステムが調整されれば、顧客ロックイン(lock-in)は以前とは異なる次元の意味を持つようになる。
  • つまりAIがコモディティ化するのは「コードを素早く作る能力」であり、顧客関係・運用データ・ドメイン文脈全体 ではない。
  • このため、既存SaaS企業がすでに持っている顧客基盤とデータ資産は、AI時代においても強力な出発点になりうる。
  • また彼はジェボンズのパラドックス(Jevons’ Paradox)にも言及し、ソフトウェア構築コストが急激に下がれば、ソフトウェアへの需要はむしろ拡大する可能性が高いと見ている。
  • 作るコストが下がれば、より多くの問題をソフトウェアで解決しようとするようになり、その結果、市場全体は縮小よりも拡大へ向かう可能性があるという解釈だ。

最終結論

  • ホフマンの結論は明快だ。SaaSは死んでいない。
  • ただし死につつあるのは、「機能を製品化して高いマージンを維持してきた古いSaaSプレイブック」のほうに近い。
  • 今後生き残る企業は、AIを道具として付け足すレベルを超え、自社カテゴリの中核業務をAI生成性中心に再設計する企業だ。
  • 逆に、従来の成功法則に安住し、AI時代における堀の移動を理解できない企業は、ゆっくりと衰退する可能性がある。
  • つまりこの記事の核心メッセージは、「ソフトウェア産業の終焉」ではなく、ソフトウェアビジネスの再編 だ。
  • 一行でまとめればこうだ。SaaSは葬式ではなく世代交代を経験している。死ぬのは業界ではなく、時代の変化に適応できないプレーヤーたちだ。

2件のコメント

 
colus001 2026-03-27

SaaS を使う理由そのものが「これを自分たちでやる必要ある?」であって、「自分たちにはこれができない」ではないので、なくなるというのはあまりしっくりこないですね。グループウェアを見ても、今でもかなり古臭いものが使われているくらいです。

 
aer0700 2026-03-28

難しいの基準は人それぞれでしょうが、Jiraを作るのが難しいから作らないというより、すでに慣れ親しんだJiraがあるのに、それをわざわざまた作る必要があるのか?と思って作らなかった、という感じではありましたね。ポチッとJiraを作れる時代……が来たので、会社ごとにカスタムJiraを作って使うのも、コスト面では悪くないのかも?という気もします。とはいえ、やっぱりそこまでする必要あるかな、という感じではありますが。