SaaSは本当に死ぬのか ―― AIが「奪える層」と「奪えない層」の境界線

―― AIとバイブコーディングが「代替できる業務」と「代替できない業務」の境界線

「SaaS is dead（SaaSは死んだ）」。

この言葉が、ここ一年ほど業界を歩き回っています。AIエージェントが業務アプリを飲み込み、サブスクリプションで提供されてきたソフトウェアはまとめて不要になる――そうした終末論として語られることが少なくありません。

実際、2026年2月には、この不安から世界のソフトウェア株がわずか数日で数千億ドル規模の時価総額を失う「SaaSpocalypse（SaaSの黙示録）」と呼ばれる急落まで起きました。もはや床屋談義ではなく、市場を現実に動かす力を持った言葉になっているのです。

私は普段、AX（AIトランスフォーメーション）推進やAI活用支援、AI駆動開発・エージェント導入に携わる一方で、複数社の情報システム部門の請負――いわゆる情シス代行も担っています。つまりSaaSを"置き換える側"であると同時に、日々SaaSを使い、運用し、守る側にも立っているわけです。

だからこそ個人的に思うのは、こうした刺激的な見出しにこそ、冷静な検証が必要ではないか、ということです。本当にすべてが死ぬのでしょうか。もし死ぬとすれば、どのような条件がそろったときなのでしょうか。

本稿のねらいはひとつです。「自分が今扱っている業務は、AIやバイブコーディングで作られたアプリに置き換わるのか」を見極めるための地図をお持ち帰りいただくこと。専門用語が避けにくい題材ですので、できるだけ身近なたとえに置き換えながら進めてまいります。

1. そもそも、誰が「死ぬ」と言ったのか

発端は、Microsoftのサティア・ナデラCEOでした。2024年12月のあるポッドキャストで「SaaSは死ぬ」という趣旨の発言をし、業界に衝撃が走りました。

ただし、発言を最後まで追うと、その主張はもっと限定的なものです。要約すると、次のようになります。

業務アプリは、つまるところ「CRUDデータベース＋ビジネスロジックの塊」である。そのロジックの部分が、これからAIエージェント側へ移っていく。

ここで、用語をひとつだけご説明します。CRUD（クラッド） とは、データを「作る・読む・直す・消す」という4つの基本操作のことです。たとえば顧客名簿アプリであれば、「新規登録（作る）」「一覧表示（読む）」「情報修正（直す）」「退会処理（消す）」――この繰り返しで成り立っています。

つまりナデラ氏の主張は、「画面を操作してデータをいじる作業は、エージェントに話しかけるだけで済むようになる」ということです。「SaaSという仕組みそのものが消える」とは、実は述べていません。

同じ方向の声は、ほかにもあります。著名なベンチャーキャピタルであるa16z（Andreessen Horowitz）は、「AI時代に安全な既存プレイヤーはいない」とSalesforceを名指しで批判しました。後払い決済のKlarnaにいたっては、CEOが「自社のSaaSをAIで内製置き換えする」と宣言し、市場を動かしています。

2. 「いや、死なない」と主張する人たち

当然ながら、反論も激しく交わされています。その急先鋒が、Salesforceのマーク・ベニオフCEOです。

同氏は決算説明会で「SaaSの終末（SaaSpocalypse）などというものはない。エージェントのおかげで、SaaSはむしろ良くなった」と一蹴し、「終末が来るとしても、せいぜい"SaaS雪男"に食われる程度のものだ」と冗談まじりに語りました。

調査会社IDCも、「SaaSは衰退しているのではなく、進化によって作り変えられているのだ」と冷静に分析しています。

そして、この論争には興味深い"結末"がふたつあります。

結末① ―― Klarnaは結局、別のSaaSに置き換えただけだった

「AIで内製置き換えする」と宣言したKlarnaは、半年後にその内実を明らかにしました。

Salesforceを手放した先は「AI」ではなく、別のSaaSだったのです。人事はDeel、データ統合は別のデータベース製品――というように、SaaSからSaaSへ乗り換えていたにすぎませんでした。CEO自身が、SNS上で「たいへん恥ずかしい思いをした」と認めています。

ここから読み取れるのは、「AIですべてをSaaSに置き換える」という主張は、現実にはしばしば誇張されるということです。これは、置き換えに携わる私自身こそ、最も心に留めておくべき教訓だと感じています。

結末② ―― 擁護派の筆頭も、結論は「データが命」だった

死なない派の代表格であるベニオフ氏でさえ、最も力点を置いていたのは「データ事業こそ、最も戦略的で重要な事業である」という一点でした。

つまり同氏は、ナデラ氏と正反対のことを述べているようでいて、実は同じ場所を指しているのです。ナデラ氏は「ロジック（画面操作）は剥がれる」と言い、ベニオフ氏は「だがデータは残る、そここそが本丸だ」と言う。両者を重ね合わせると、次の結論が浮かび上がります。

論争の本当のテーマは、「SaaSは死ぬか否か」ではありません。 「SaaSのどの"層"が死に、どの"層"が残るのか」 なのです。

3. SaaSは一枚岩ではない ―― 「層」で解剖する

ここが、本稿の背骨にあたる考え方です。SaaSを「ひとつの塊」として死ぬ・死なないと論じるから、議論がこじれてしまいます。

実際のSaaSは、性質の異なる5つの層が重なり合ってできています。ビルの階層を思い浮かべていただくと、わかりやすいかと思います。

「SaaSは便利な画面（①）を売っている」と受け止められがちですが、本当に提供しているのは②〜⑤――すなわち「正しいデータを保持していること」「他者とつながっていること」「責任を肩代わりすること」「止まらずに動き続けること」のほうです。

ナデラ氏が「死ぬ」と述べたのは、ほぼ①の層だけだったのです。

4. バイブコーディングのアプリは、どの層を持てるのか

ここで「バイブコーディング」について確認しておきます。

AIに自然言語で「こういうアプリを作ってほしい」と指示し、コードをほとんど書かずに動くものを生み出す手法です。驚くほど速く、そして安価に、業務アプリを作ることができます。

では、そうして作られたアプリは、先ほどの5層のうちどこまでを備えられるのでしょうか。

ここに本質があります。バイブコーディングは①を一瞬で複製できますが、②〜⑤は肩代わりしません。 ですから「業務の画面操作」は置き換わっても、「正本・接続・責任・運用」を抱えるSaaSは、すぐには死なないのです。これこそが、「SaaSが全滅しにくい理由」の正体だと考えております。

とりわけ⑤は、見落とされがちです。バイブコーディングで作られたアプリは、「作った瞬間がピークで、放置すれば劣化していく」という性質を持ちます。誰が障害に対応し、誰がセキュリティのパッチを当て、誰が翌年の法改正に合わせて手直しするのか――SaaSは、この「劣化させない仕事」そのものを提供しているのです。

ここまでは理屈の話です。では、現実はどうでしょうか。①の層――つまり定型的な業務の置き換えは、すでに始まっています。興味深いことに、先ほど「SaaSは死なない」と語っていたSalesforce自身が、AIエージェントの導入によって、自社のカスタマーサポート人員を9,000人から5,000人へと減らしました。IBMでは、定型的な人事問い合わせの実に94%をAIが処理しているといいます。①の層は、もはや机上の空論ではなく、現実に剥がれ始めているのです。

しかも、置き換えはSaaSを"売る側"だけの話ではありません。SaaSを"使う側"も、自分でアプリを作り始めています。あるイベント運営企業では、担当者が対話だけで社内ツールを自作し、それまで使っていた複数のSaaS――顧客管理、メール配信、分析ダッシュボードなど――を、まとめて一つの自作ツールへ置き換えてしまいました。月数十ドルの便利な道具なら、いまや午後のひとときで作れてしまう。そんな声も聞こえてくる時代です。

ただし、ここに重要な但し書きがつきます。第2章で登場したKlarnaは、別の場面でも示唆を残しました。同社は定型業務にとどまらず、顧客対応そのものまでAIに丸ごと委ねたのです。結果は品質の低下を招き、人間のスタッフを雇い直すことになりました。剥がせるのは、あくまで定型的な①の層まで。判断や気配り、関係性が問われる仕事は、依然として人の手に残ります。

5. 【本題】では、どうなれば②〜⑤も代替されるのか

ここが、本稿で最もお伝えしたかった部分です。②〜⑤は「現時点では」剥がれていません。しかし、永久に安全というわけではありません。 それぞれに「これが起きれば陥落する」という引き金が存在します。置き換えに携わる立場の私自身としても、ここを見据えておかなければ足元をすくわれかねない、と感じています。

② データの正本層が代替される条件

引き金:データの"持ち運び標準"が普及すること。――そして、これはすでに起こり始めています。

これまで各SaaSは、自社のデータを内部に囲い込んできました。だからこそ乗り換えが煩雑になり、それが堀の役割を果たしてきたのです。

ところが、その前提を崩す動きが、すでに現実のものとなっています。AIが共通の作法で外部のツールやデータに直接つながるための標準規格――MCP（Model Context Protocol）です。2024年末に登場したこの規格は、わずか一年あまりで主要なAIベンダーがこぞって採用し、対応するサービスは一万を超える規模にまで広がりました。GitHubやデータベース、各種SaaSにいたるまで、「AIから直接操作できる対象」が日々増え続けているのです。

これが意味するのは、データがどこに置かれていても、AIが共通の作法で読み書きできる世界が、現実に近づいているということ。そうなればSaaSは「単なる保管庫」へと格下げされかねません。画面（①）が不要になった次は、保管庫を選ぶ理由そのものが薄れていくわけです。

→ 現状:引き金は、すでに引かれ始めています。 標準規格は急速に普及し、AIがつながれる対象は拡大の一途をたどっています。ただし「あらゆる業務データを、安全に、本番運用で任せきれる」段階かと言えば、まだそこには至っていません。普及の速さと、実運用の慎重さがせめぎ合っている、というのが現在地です。

③ 接続・ネットワーク層が代替される条件

引き金:エージェント同士が、組織をまたいで直接やり取りを始めること。

現在は「自社のエージェント」が社内で完結しています。しかし、自社のエージェントと取引先のエージェントが共通の作法で交渉・調整・取引を行えるようになれば、あいだに立っていたSaaSのハブ（予約・発注・決済の仲介役）は中抜きされます。電話交換手が不要になったのと同じ構図です。

現状:こちらも、実験段階から本番運用へと動き出しました。 エージェント同士を組織やベンダーをまたいでつなぐ標準規格（A2Aと呼ばれます）が2025年に登場し、わずか一年で150を超える組織が支持、主要なクラウド基盤にも統合され、一部は実際の業務で動き始めています。決済をエージェント同士でやり取りする試みも始まりました。ただし、組織をまたいで"信頼して任せきれる"取引の標準としては、まだ確立の途上にあります。

④ 責任・コンプライアンス層が代替される条件

引き金:AIが「規制を遵守していること」を自動で証明・監査できるようになること。

私が実務の現場で痛感しているとおり、現在はeKYCやマネーロンダリング対策、会計監査、個人情報保護を「人と仕組みで保証する」ことに価値があります。

しかし、AIが「この処理は法令に準拠している」と自動的に記録・証明し、監査する側もAIで検証できる基盤が整えば、自作のアプリでも準拠が可能になります。責任という名の堀が、浅くなっていくわけです。

現状:作業レベルの自動化は、すでに進んでいます。 証拠の自動収集や規制変更の追跡、マネーロンダリング対策の監視を継続的に行うツールは、すでに商用化され、監査の現場に入り込んでいます。

それでも、ここは最後まで残る堀になりやすいと私は見ています。「誰が最終的な責任を負うのか」は技術だけでは解けず、しかも"コンプライアンスを担うAIそのものを、どう統治し、どう説明可能にするのか"という新たな難問まで生まれているからです。

⑤ 動き続ける層が代替される条件

引き金:ソフトが"自らを保守"し、法改正を自動で取り込むようになること。

先述の「作った瞬間がピークで劣化する」という問題が解消される日が来るかもしれません。AIが障害を自己修復し、脆弱性を自ら塞ぎ、税制や労務の法改正をリアルタイムで読み込んで自作ロジックを自動更新する――そうなれば、「劣化させない仕事」を外部に委ねる理由はなくなります。

現状:インフラの自己修復は、すでに本番運用へ入りつつあります。 障害を自動で検知・診断・復旧する仕組みは、大半のインシデントを人手を介さずに解決する水準へと近づいています。

とはいえ"運用ゼロ"は幻想で、想定外の障害には人間の判断が要り、オンコール担当がなくなるわけではありません。そして「法改正への自動追従」まで委ねられる段階には、まだ至っていないのが実情です。

全体像

②〜⑤の引き金を一覧にすると、次のようになります。

この4つがすべてそろった瞬間が、SaaSの「本当の死」だと考えられます。

ここで注目すべきは、②のデータ、③の接続、⑤の運用と、いくつもの引き金がすでに引かれ始めているという事実です。とはいえ、すべてが出そろったわけではありません。とりわけ④の「責任」は、技術が普及するだけでは崩れにくい、最後の砦として残ります。「誰が責任を負うのか」という問いが残るかぎり、SaaSは死にきらない――というのが、私の見立てです。

6. ご自身の業務は代替される側か ―― 判定チェックリスト

理屈はご理解いただけたかと思います。

では、実務に落とし込んでみましょう。今お使いの業務やツールが、AI／バイブコーディングに置き換わりやすいかどうかは、次の5つを問うことで見当がつきます。

1. その作業は、データを入力・計算・出力するだけの繰り返しでしょうか。 （はい、であれば①の層＝置き換わりやすい）
3. そのデータは自社の中だけで完結しますか。社外と共有・接続していないでしょうか。 （社内完結ならば置き換わりやすい／社外接続があれば③の堀あり）
5. そのデータは"唯一の正本"として、ほかが依存しているものでしょうか。 （正本であれば残りやすい）
7. 停止したり誤ったりすると、法的・契約的に誰かが責任を問われますか。 （問われるならば残りやすい・④の堀）
9. 法改正や外部ルールの変化に、追従し続ける必要があるでしょうか。 （必要であれば残りやすい・⑤の堀）

判定の目安: 質問1・2に「はい」が多いほど → バイブコーディングで置き換えやすい（薄いロジック業務）。 質問3・4・5に「はい」が多い（＝堀がある）ほど → 当面はSaaSや既存の仕組みが安全。

たとえば「社内の備品管理台帳」は質問1も2も「はい」となり、明日にでもバイブコーディングで作れてしまいます。一方で「取引先と決済をまたぐ受発注」や「監査対象となる会計処理」は、3・4・5に当てはまるため、簡単には剥がれません。

7. おわりに ―― 「殺す／殺さない」ではなく「層を引き継ぐ」

SaaSは「すべて死ぬ」のでも「不滅」でもありません。

薄いロジック層（①）から順に剥がれ、データ・接続・責任・運用の層（②〜⑤）は、条件がそろうまで残ります。 論争の両陣営――ナデラ氏もベニオフ氏も、突き詰めれば同じことを述べていたのです。

ここで、私自身の見方を、控えめに申し添えます。

私が考えるに、目指すべきは「SaaSを倒すこと」ではありません。剥がれていく①の層をAIとバイブコーディングで引き取り、残る②〜⑤の層となめらかに繋ぎ直すことではないでしょうか。置き換えるのではなく、層を引き継ぎ、再設計する。Klarnaの事例が教えてくれたように、「すべてAIで」と旗を振る者ほど、足をすくわれてしまうのです。

最後に、私が大切にしている考えを申し上げます。

AIに委ねられる単純なロジック層は、思い切って手放す――いわば、戦略的に「サボる」。そうして空いた人の時間とSaaSの役割を、機械には肩代わりできない「正本・接続・責任・追従」という、剥がれにくい層へと振り向ける。

手放してよい層を見極めることが、手放してはならない層を守ることにつながります。 SaaSの死をめぐる議論は、煎じ詰めれば、その境界線をどこに引くか、という問いに行き着くのではないでしょうか。