SaaS is Dead. Long Live SaaS ― SaaSは本当に終わるのか？進化の本質を読み解く

今から20年以上前、私がマイクロソフトに在籍していたころ、Windows XPの日本でのCMにレニー・クラヴィッツの楽曲が採用された。曲名は「Dig In」。私はこのCMの前からレニー・クラヴィッツの音楽が好きだったので、彼の起用を喜んだ記憶がある。

レニー・クラヴィッツの代表曲のひとつに「Rock and Roll is Dead」がある。直訳すれば「ロックンロールは死んだ」。しかしこれは、ロックという音楽ジャンルそのものが終わったという意味ではない。むしろ、商業化し表面的なイメージばかりが強調される音楽業界への皮肉と、ロックの精神を問い直す強いメッセージが込められている。

実際、「Rock is Dead」という言葉は、クラヴィッツに限らず、幾度となく音楽業界で語られてきた。時代が変わるたびに「ロックは死んだ」と言われてきた。しかし、ロックはそのたびに形を変えながらも生き続け、私たちの心を揺さぶる音楽であり続けている。

「〇〇 is Dead」という表現は、音楽に限らず、テクノロジーやビジネスの世界でもよく使われる。変化や進化の過程で、一つのフェーズが終わったことを象徴的に表現するための強い言葉だ。最近では、「SaaS is Dead」という言葉が、ソフトウェア業界を中心に注目されている。

たとえば、2024年末、マイクロソフトCEOのサティア・ナデラがBG2ポッドキャストで「従来の業務アプリケーションはほとんど使われておらず、AIによってその役割が再構成される」と語ったことで、「SaaS is Dead」は一気に現実味を帯びたキーワードとして業界内外に広がった。

この言葉は、SaaSが本当に終わったのか、それとも新たなフェーズへと進化を遂げようとしているのかという問いを私たちに投げかけている。

この少し過激にも思える言葉の背景に、どんな変化があるのか。そして、それが本当に“終わり”を意味するのかどうか、自分なりに考えてみたい。

── SaaSは死んだ。だが、SaaSは生き続ける。（SaaS is dead. Long live SaaS.）

SaaSの全盛と限界

SaaS（Software as a Service）は、2000年代から2010年代を通じて、クラウドコンピューティングの進展とともに急速に普及したビジネスモデルである。

プロダクトマネジメントやグロース戦略においても、「LTV（顧客生涯価値）を最大化し、CAC（顧客獲得コスト）を最小化する」という方程式は、成功の基本原則として多くの企業に浸透していった。

この前提にあるのが、SaaSというビジネスモデルがもたらした3つの本質的価値である。これを理解することが、SaaSの成長と限界を見極める鍵となる。

1つ目は、インフラの抽象化と標準化である。サーバーの構築やアプリケーションのインストール、保守などの煩雑な作業を不要にし、IT管理にかかる手間や専門知識の必要性を大きく軽減した。

2つ目は、スケーラビリティとコスト構造の変化だ。サブスクリプション型や従量課金モデルにより、ユーザーは初期投資を抑えながら導入でき、スモールスタートが容易になった。これはSaaSの導入障壁を大きく下げることに貢献した。

3つ目は、業務領域でのベストプラクティスの具現化である。業務における“あるべき姿”がUIや操作フローに組み込まれており、サービスを導入するだけで、組織の成熟度が自然と高まる仕組みとなっていた。

これらは、SaaSを単なるクラウド上のアプリケーションにとどまらず、業務の変革ツールとして社会に浸透させる要となっていた。これらの要素によって、SaaSは企業のIT導入と業務の変革を同時に実現する強力なモデルとして広がっていった。

しかし、2020年代に入り、その優位性には綻びが見え始めている。市場が成熟し、あらゆる業務領域にSaaSが乱立する中で、競争は激化。差別化が難しくなり、顧客の期待値も高まり続ける。新規参入のハードルが上がる一方で、既存ユーザーの維持にも大きなコストがかかるようになった。

加えて、SaaSモデルは当初、その継続課金構造から「一度顧客を獲得すれば長期的に安定した収益が得られる」という非常に魅力的なビジネスモデルと見なされていた。しかし近年、その前提が過度に楽観的であったことが明らかになりつつある。初期の低チャーンレート（解約率）に基づく楽観的なLTV予測に引きずられ、過剰なCAC（顧客獲得コスト）を投下した結果、思ったように収益が回収できないケースが目立ち、まるで魔法のようだと信じられてきたモデルの現実が露呈してきている。

「SaaSの限界」は、その構造的な伸びしろの減少に加え、ユーザー行動の変化やテクノロジーの進化によっても露呈しつつある。従来型のSaaSでは、「人がアプリを操作すること」が前提だったが、AIの登場により「人が直接操作しなくてもよい」サービスへのニーズが急速に高まっている。

SaaSが成長しきった今、その肥大化も無視できない問題となっている。顧客が導入するSaaSの数は年々増加し、それに伴ってコストも積み上がっている。加えて、各サービスのアカウント管理や連携設定、セキュリティ対策など、運用・管理の負担も無視できないレベルに達しつつある。機能追加を繰り返す中で、SaaSは本来のシンプルで使いやすい姿から離れ、顧客の期待とかけ離れた“重たい”存在になってしまったケースも多い。

ここで私が思い出すのは、お笑いコンビ「タイムマシーン3号」のネタである。彼らは「デブの三段活用」として「デブ（deb）」「デバー（deber）」「デッド（dead）」と展開するが、まさにSaaSもこの流れに重なる。便利だったSaaS（deb）が、機能過多のSaaS（deber）になり、いまや“使いにくい”“高すぎる”“同じようなものばかり”といった不満を抱かれるSaaS（dead）になりかけている。

サービスを豊かにしようとするほどに複雑化し、顧客の体験価値が薄れる。この「機能肥大」の問題は、プロダクト開発において避けて通れないテーマになっている。

SaaSは本当に終わったのか？

「SaaS is Dead」という言葉が独り歩きしているように見えるかもしれないが、ここで強調しておきたいのは、「SaaSが完全に終焉を迎えた」という意味ではないということだ。

実際には、SaaSはまだ広く使われている。企業の業務基盤として根強い存在感を保っており、その多くが日々のオペレーションに深く組み込まれている。SaaSは死んでなどいない。しかし、確実に「古いSaaSの形」は終わりつつある。

従来のSaaSモデルは、ある業務領域の課題を効率的に解決する「アプリケーション」として成立していた。だが今、ユーザーの期待は「自分が操作する」ことから、「自分の代わりにやってくれる」ことへと移り変わりつつある。

この背景には、AI技術、特に生成AIの進化がある。

実際、多くのSaaS製品はすでにAIを取り込んでいる。たとえばSalesforceのEinsteinのように、既存のSaaSの構造を維持しながら、AIがデータ分析や提案業務を補助し、業務を効率化する例は増えている。これは、従来のSaaSモデルに自然に溶け込む "組み込み型AI（Embedded AI）" と呼べるものであり、実用性が高く、今後も進化が期待される領域である。

ただし、ここで議論している「AIエージェント」は、それとは異なる存在だ。AIエージェントは、ユーザーの指示や目的を理解し、自律的に複数のアクションを実行して業務を完了させる。つまり、単に"支援"するのではなく、"代理"として業務を遂行する主体である。

この流れについては、冒頭でも触れた通り、2024年末にマイクロソフトCEOのサティア・ナデラが語った「従来の業務アプリケーションはAIによってその役割が再構成される」という視座が象徴的だ。

この発言は、単なるテクノロジー論を超えて、プロダクトの設計思想やユーザー体験の再定義、そして業界構造そのものの変化を示唆している。これまで人間が手作業で行っていた入力や操作の一部をAIが肩代わりするようになり、ユーザーは画面を開いてメニューを選ぶというプロセスすら煩雑に感じ始めている。

この変化は、「アプリケーションとしてのSaaS」から「エージェントとしてのSaaS」への移行を意味する。つまり、ユーザーの意図を理解し、先回りして業務をこなすAIエージェントが、従来のSaaSの役割を置き換えていくという構図だ。

さらに重要なのは、この変化が単なるUIや技術的進化にとどまらず、SaaSの設計思想や提供形態、ひいてはビジネスモデル全体に波及する可能性があるという点である。従来のSaaSは、ユーザーが能動的に操作する前提で設計されており、UI/UXがプロダクトの評価軸の中心にあった。しかしエージェント型のSaaSでは、ユーザーが何かを操作するのではなく、目的が達成されることそのものが価値になる。UIはあくまで手段であり、最終成果こそが評価対象となる。この変化は、プロダクトが「使われるもの」から「任せられるもの（結果を委ねられる存在）」へと変わる転換点を示している。

SaaSは死んだのではない。ただし、それは“従来のかたち”でのSaaSであり、今後求められるのはまったく新しいSaaSの姿――すなわち、AIエージェントと共存する、再構築されたSaaSである。

エージェント時代のSaaSプロダクト再設計ガイド

AIエージェントの時代を迎え、従来のSaaSにおけるプロダクトマネジメントの前提は大きく揺らいでいる。画面ベースの操作、UI中心の設計思想、継続利用を前提とした評価指標など、これまでの成功モデルが通用しないフェーズに入った。ここでは、そうした変化の中でプロダクトマネジメントに求められる再設計の方向性と、実務者として取るべきアクションについて考察する。

パラダイムシフト：SaaSからAIエージェントへ

従来のSaaSは、ユーザーがUIを通じて操作し、業務を効率化することを前提に設計されていた。しかしAIエージェント時代においては、ユーザーが意識的にUIを操作する機会そのものが減少し、場合によってはUIが登場しない体験もありうる。

私が日本語版の序文を担当させて頂いた書籍『さよなら、インタフェース -脱「画面」の思考法』では、人間が画面を通して操作することそのものが古い前提であると語られている。Nestのようなスマートサーモスタットは、ユーザーが操作せずとも周囲の状況を学習し、自律的に適切な温度調整を行う。こうしたプロダクトが象徴するように、AIエージェントは“操作される”のではなく、“目的を達成する存在”として振る舞う。

この変化により、プロダクトマネージャーには、従来にも増して、ユーザーとエージェントがどのように関わり、どのように価値を感じるかという“協働体験”全体を設計する視点が求められる。UIや機能といった表層的な構成だけでなく、エージェントが介在することで生まれる新しい価値の形を構想し、実装することが、今後ますます重要になっていくだろう。

UX再設計：AIエージェントを前提とした体験

AIエージェントに求められるのは、単にタスクを自動化することではない。ユーザーの文脈や状況を理解し、最適なタイミングで、最適な方法で、価値を提供することが重要である。通知の出し方ひとつをとっても、タイミングや頻度を誤れば逆効果になりかねない。

ユーザーが明示的な操作をすることなく、意図を汲み取り、行動に移す。必要なときだけUIが現れ、それ以外は静かに背景で動いている――そんな体験を設計する必要がある。たとえば、旅行予約エージェントであれば「来週の出張を手配して」と一言伝えるだけで、目的地・日時・宿泊先などを過去の履歴から補完して提案するような体験だ。

プロダクトマネージャーは、こうした体験を支えるために、シナリオ設計（どのような順で何を行うか）、意図理解（ユーザーが何を求めているかを解釈する仕組み）、フィードバックループ（成功・失敗の情報を次に活かす設計）といった“対話の枠組み”全体を構想・設計する役割を担うことになる。

アーキテクチャと設計に対する視点の転換

プロダクトの設計思想にも転換が求められる。重厚長大な機能セットは、エージェント時代にはむしろ足かせになる。

AIエージェントは特定の目的に沿って軽量かつ柔軟に動作する必要があり、そのためには設計も“呼び出されやすく”“理解されやすく”なければならない。また、今後は人間だけでなく他のAIエージェントが利用者になる可能性もある。人間向けのUI中心設計ではなく、機械同士の連携を前提としたインターフェース設計が求められる。たとえば、あるAIエージェントがスケジュールを管理し、別のエージェントが出張の手配を行うといった“エージェント同士の連携”を想定し、そのやりとりがスムーズに行えるようAPIやデータ構造を整備しておく必要がある。

そしてその基盤にあるのが「データ」である。AIエージェントが適切に判断・行動するためには、社内外に点在する情報を統合し、矛盾なく参照可能な状態に保つ必要がある。たとえば、顧客情報・業務履歴・過去の意思決定といった断片的なデータがサイロ化されたままでは、エージェントは適切な価値提供ができない。

しかし現実には、これらのデータはしばしば部門やサービスごとに分断されており、「一元的に整備されている」と言い切れる状況はまれである。加えて、どの部門やどのプロダクトが主導権を握るのかという“データの奪い合い”が生じやすく、プロダクトマネージャーがデータ整備をリードすることも難しい。

だからこそ、プロダクトマネージャーは「理想のエージェント体験を実現するには、どんなデータがどの粒度で必要か」を明確にし、関係者との対話を通じて、段階的にでもデータの整備・連携を進める役割が求められる。情報システム部門の責任にせず、自ら体験設計の一部としてデータ要件を定義し、現実的な実装方針に落とし込むことが、これからのプロダクトマネージャーにとって不可欠なスキルとなる。

つまり、どんな機能を持つか以上に、どんなデータにアクセスできるかが、エージェント型プロダクトの実力を左右する。データ整備と構造設計は、もはや裏方ではなく、ユーザー体験そのものに直結する中核的な設計対象となっている。

ビジネスモデルと評価指標の変化

従来、SaaSの成功は「使われ続けること」によって測られてきた。しかし、エージェント時代においては、「頼られ続けること」が真の価値指標となる。

LTVは単なる継続利用ではなく、「どれだけ頻繁に、どれだけ深く価値を提供したか」によって再定義されるべきである。チャーン率では測れない「信頼されるプロダクトかどうか」が、これからのプロダクトマネジメントの成否を分ける。もちろん、チャーン率が高い状態は明確な課題であり、継続利用が前提となるプロダクトにおいては重要な指標であることに変わりはない。しかし、継続して使われているという事実だけでは、真に価値を提供しているかどうかまでは測れない。

このことは従来のSaaSにおいても同様であり、「契約は続いているが、実際には使われていない」「使ってはいるが、深い価値は感じていない」というケースは多く存在する。エージェント型プロダクトでは、価値の提供がより非可視化されやすくなる分、こうした“信頼の質”や“活用の濃度”をどう評価するかが、より問われるようになる。

AIエージェントという新たな前提のもと、プロダクトのあり方、ユーザー体験の設計、ビジネスの評価軸がすべて変わろうとしている。その変化を読み解き、柔軟に適応していくことが、これからのプロダクトマネージャーに求められる最大のスキルである。あなたのプロダクトは、この変化にどこまで備えられているだろうか？

なお、「SaaS is Dead」という言説が語られているのは主に米国であり、それをそのまま鵜呑みにするのは危険である。SaaSの普及状況や導入数、価格モデルの成熟度は国や地域によって大きく異なる。たとえば、日本では一企業あたりのSaaS導入数は米国に比べてまだ少なく、従量課金よりもコストを計画的に管理できるモデルが好まれる傾向がある。つまり、米国で語られている課題が、そのまま自社プロダクトのターゲット市場にも当てはまるとは限らない。

だからこそ、プロダクトマネージャーには、ある言説が流布された際に、なぜそう言われているのかを構造的に読み解き、自らが向き合う市場や顧客にとっても同様の課題が存在するのかを冷静に判断する力が求められる。衝撃的なメッセージに反射的に反応するのではなく、その背景を分析し、自身のプロダクトをどう進化させるべきかを見極める必要がある。

とはいえ、SaaSのAIエージェント化という流れ自体は、単なる一過性のトレンドではなく、SaaSの枠組みを超えて社会全体に波及する必然的な変化である。その動向には引き続き注視すべきだ。

変化を読み解く力とSaaSの再定義

「SaaS is Dead」という言葉は、単なる終焉ではなく、進化の合図である。ソフトウェア業界において、プロダクトの提供形態が成熟しきったとき、それは次の形に脱皮するタイミングでもある。SaaSもまた、UI中心・定型業務・人間主体の前提から、エージェント中心・柔軟な体験・人間とAIの協働へと進化しようとしている。

このような進化は、実はSaaSに限った話ではない。クラウド以前にも、オンプレミスからASP、そしてSaaSへと移行してきた歴史がある。今また新たな転換点を迎えているにすぎない。大切なのは、プロダクトマネージャーとしてその変化に慌てず、構造を見極める眼を養うことである。

その鍵となるのが、「変わらないもの」と「変わるもの」を見極める視点であり、その対比を通じて“何を守り、何を更新すべきか”を判断する構造的な思考である。

SaaSの本質的な価値については、「SaaSの全盛と限界」でも述べたように、以下の3点に集約される：

インフラの抽象化と標準化
スケーラビリティと導入コストの最適化
業務におけるベストプラクティスの具現化

これらは、形を変えても本質としては今後も重要であり続ける。実際、AIエージェント時代においても、ユーザーがインフラを意識せず、スモールスタートが可能で、あるべき業務の姿を自然と実現できるような体験は、引き続き求められる価値である。

ただし、SaaSの3つ目の価値として挙げた「業務におけるベストプラクティスの具現化」は、そのままでは通用しなくなりつつある。「業務のあるべき姿」がひとつに定まっていた時代から、個別最適化・文脈依存・個人や組織ごとのパーソナライズが可能な時代に移り変わっている。その変化を駆動するのがAIであり、従来はベストプラクティスに従うしかなかった領域にも、柔軟性が入り込む余地が生まれている。

さらに、「ユーザー」の定義も変わりつつある。これまでは人間のみが対象だったが、今後はLLMや他のAIから呼び出されるエージェント同士の連携も前提となる。つまり、人間だけでなくAIもプロダクトの“ユーザー”となる時代がやってきている。

このように、プロダクトの本質と文脈を分けて捉え、「何が変わり、何が変わらないか」を丁寧に整理することで、表層的な流行や技術に振り回されるのではなく、構造的な洞察を得ることができる。

そのための思考フレームとして有効なのが、拙著『プロダクトマネジメントのすべて』でも紹介している「Core / Why / What / How」の4層構造である。これはプロダクトの構想から提供・運用までを階層的に捉える枠組みであり、変化に柔軟に対応する判断基準となる。

Core（核となる理念）：そのプロダクトが存在する根源的な意義。変化の時代においても揺らぐことのない、長期的なミッションやビジョンを担う。
Why（市場とユーザーの課題理解）：誰がどんな課題を抱えていて、それをなぜ今解決すべきかという構造的な背景。プロダクトが果たすべき役割を定義する。
What（提供する解決策）：どのような機能やサービスとしてユーザーに価値を届けるかの具体的設計。ユーザー体験の青写真を描く。
How（実現方法）：技術的実装、開発体制、運用設計などの実務的要素。ここがもっとも変化しやすく、時流の影響を大きく受ける。

AI時代のように環境が大きく変化する局面では、HowやWhatが大きく変わることがあっても、CoreやWhyは変わらないというケースが多い。ただし、Whyについても注意が必要だ。人間の課題を解決するという軸は変わらないかもしれないが、プロダクトの“ユーザー”の定義自体が拡張されることで、Whyの意味合いが変化（アップデート）するケースもある。たとえば、従来は人間の利便性を主に考慮していたSaaSプロダクトが、今後はLLMや他のAIエージェントによって呼び出され、タスクを代行する構成の一部となる場合、人間以外の存在にとっての使いやすさや統合性といった新たな“課題”がWhyの対象として浮上してくる。

実際、SaaSがAIエージェント型へと進化する過程においても、この構造は当てはまる。たとえばCoreとして「ユーザーの業務生産性を向上させる」というミッションが変わらなかったとしても、What（どのような機能を提供するか）は「ユーザーが操作するUI」から「ユーザーの意図をくみ取って自律的に動くエージェント」へと大きく変化する。また、How（実装方法）においても、従来のUI中心の画面設計から、LLMを活用した自然言語理解、API連携、プロンプトエンジニアリングといった新たな構成要素へのシフトが求められる。

このように、AIエージェント化という変化は、SaaSのWhatとHowのレイヤーにおいて特に大きなインパクトをもたらす。プロダクトマネージャーはこの階層構造を意識し、「WhatをHowで再構成する」「Whyを再解釈する」といった柔軟なリフレーミングを行うことで、変化に適応しながらも軸を失わない意思決定が可能になる。

この分解と再定義の思考は、流行や技術革新にただ追随するのではなく、本質を見極めたうえで自らのプロダクトを再設計する力となる。まさにこれこそが、AI時代におけるプロダクトマネージャーに求められる思考力である。

こうした視点でSaaSの未来を考えるとき、ふと頭に浮かぶのが“Rock is Dead—Long Live Rock”という言葉だ。

1971年にThe Whoが制作を試みた未発表アルバムのタイトルでもあるこの言葉には、「ロックという形式は変わっても、その精神は生き続ける」という強いメッセージが込められている。冒頭で触れたレニー・クラヴィッツの「Rock and Roll is Dead」が音楽業界への警鐘であったように、この表現もまた「表層の終わり」と「本質の継続」を同時に語るものである。

同じように、“SaaS is Dead”は、あるフェーズの終焉を告げるものであると同時に、“Long Live SaaS”という続きによって、その価値の再定義と進化を力強く宣言する構造になっている。

この言い回しは、もともと「The king is dead. Long live the king!（王は死せり、王よ永遠なれ）」という歴史的フレーズに由来する。旧体制の終焉と新体制の即位を同時に告げるこの表現は、SaaSの進化を語るうえでも象徴的だ。

SaaSは死んだ。だが、SaaSは生き続ける。（SaaS is dead. Long live SaaS.）

時代とともに変化し、形を変えて受け継がれていくものにこそ、本質は宿る。そして、それを見極める力こそが、これからのプロダクトマネージャーにとっての羅針盤となる。