SaaS is deadとは？AIエージェント時代に死ぬもの・残るもの【3層モデルで解説】¶

この記事の対象者

2026年2月のSaaS株暴落の構造を理解したいIT業界関係者
「SaaS is dead」の議論を整理したいエンジニア・経営層
自社のSaaS戦略やキャリアへの影響を判断したい方

この記事のポイント¶

SaaSは死なない。UI/Workflowが圧縮され、System of Recordが強化される
死ぬもの: Notionやプロジェクト管理ツールのような汎用SaaS、座席課金モデル
残るもの: SAPやSalesforce CRMのような基幹SoR。信頼・監査・リスク移転が参入障壁
変化の速度: 運用責任・調達構造・課金移行の3摩擦が急激な置換を阻む
読者のアクション: 自分の仕事がどの層にあるかを確認し、影響の時間軸を見極める

この記事の問い¶

「SaaS is dead」は本当なのか。2026年2月のSaaS株暴落をきっかけに、この問いが一気に広がった。

どちらが正しいのか？ ――実はこの問い自体が粗すぎる。「SaaS」という一語が指す範囲が広すぎるからだ。

この記事では、SaaSを3つの層に分解し、何が死に、何が残り、それはどのくらいの速度で起きるのかを構造化する。

この記事で使う3つのキーワード

UI層 = ユーザーが画面で触る部分。Notionのエディタ、Salesforceのダッシュボードなど
Workflow層 = 承認フローやタスク振り分けなど、業務プロセスを回す部分
SoR（System of Record）層 = 会計・契約・顧客マスタなど、「正式なデータ」を保持する部分

何が起きたのか¶

きっかけ¶

2026年2月、AnthropicがClaude Coworkに法務向けプラグインをリリースした。「AIプラグインが知識労働を丸ごと置き換える」という物語が一気に広がった。

市場の反応¶

売りはソフトウェア株全体に波及した。Reutersによれば、1月28日以降でソフトウェア・サービス株から約8,300億ドルの時価総額が消失。Thomson Reutersは当日約16%、RELX（LexisNexis親会社）は約14%急落した。市場では「SaaSpocalypse（SaaSの黙示録）」という呼称まで広がっている。

反対意見¶

全員がパニックしたわけではない。

JP Morgan（Mark Murphy）: 「生産性ツールから、全企業がミッションクリティカルなソフトウェアを自社開発で置き換えるという飛躍は非論理的だ」 → SoR層は脅かされていない、という立場
Wedbush Securities: 「ハルマゲドンシナリオは現実から程遠い」 → 既存インフラの置換コストを根拠に否定
Gartner: 「Coworkとプラグインはタスクレベルの知識労働の潜在的な破壊者だが、重要な業務運用を管理するSaaSアプリケーションの代替ではない」（Fortune、2026年2月6日） → UI層は危険だがSoR層は別物、という切り分け

この記事の問い¶

市場の反応自体が割れている。何が脅かされていて、何がそうでないのか。「SaaS」という言葉が指す範囲を分解しないと、この問いには答えられない。

3層モデル：SaaSの何が死ぬのか¶

「SaaS is dead」議論が噛み合わない最大の原因は、論者ごとに「SaaS」が指すレイヤーが違うことだ。

先ほど定義した3つの層を、具体的な製品名とともに見ていく。

UI層 ― 最も早く圧縮される¶

どんなもの？ ユーザーがブラウザで触る画面。ダッシュボード、入力フォーム、レポート画面。

具体例で言うと： Notionのドキュメント画面、Tableauのダッシュボード、Jiraのカンバンボード。要は「人間がGUIを操作してデータを入力・閲覧する」インターフェース全般だ。

なぜ脅かされるのか。 Claude Coworkが示したスライド作成やファイル整理の自動化を思い出してほしい。AIエージェントがDBを直接更新しレポートを自動生成するなら、人間がボタンを押す必要はなくなる。

たとえばこういうことだ。今まで営業担当がSalesforceの画面を開いて商談情報を手入力していた作業を、AIエージェントがメールとカレンダーから自動的に抽出・登録する。入力画面そのものが不要になる。

Workflow層 ― 競争が激化する¶

どんなもの？ 承認フロー、業務ルール、タスクの自動振り分け。SaaSの「動いている部分」。

具体例で言うと： Zapierの自動化フロー、ServiceNowのITSMワークフロー、HubSpotのリードスコアリング。

なぜ主戦場になるのか。 「AIエージェントで内製した方が速い」という議論はここが中心だ。実際、ワークフローを「作る」だけなら、AIエージェントのほうが速いケースは増えている。

ただし、勝負は「作れるか」ではなく「運用・監査できるか」だ。プロセスを組み立てることと、以下を維持することは別の問題になる：

監査証跡を残す
障害時に原因を特定する
権限管理を維持する

ここでの本当の問いは「構築コスト」ではなく「運用責任を誰が負うか」だ。

SoR層 ― 残る、むしろ重要性が増す¶

どんなもの？ 会計、契約、顧客マスタ、監査ログ。SaaSの「信頼の根幹」。

具体例で言うと： SAPのERPモジュール、Oracle Financials、Salesforceの顧客マスタ（CRM機能のうちUI部分ではなくデータ基盤部分）。

なぜ置換が難しいのか。 Fortune 500企業がこれらを簡単に切り替えられないのは、ソフトウェアの機能が理由ではない。長年にわたって蓄積された以下の資産があるからだ：

数十年分のデータ整合性
統合テストの蓄積
監査対応の実績

企業がSaaSベンダーに払っているのは、コードの対価だけではない。SLA、セキュリティ認証、障害時の責任所在――つまりリスク移転の対価だ。自社でAIアプリを作っても、この「責任の引き受け先」は自動的には生まれない。

ここまでの要点： 「SaaS is dead」と言うとき、UI層の話をしているなら概ね正しい。SoR層の話をしているなら的外れ。Workflow層はケースバイケース。

「死ぬ」側の論拠¶

3層モデルを踏まえた上で、「SaaS is dead」側の論拠を見ていく。3つの柱がある。

1. 座席課金モデルの崩壊¶

AIエージェントが業務を処理するなら「ユーザー数×月額」の前提が崩れる。

Salesforceはすでに動いている。ALEA（Agentic License Enterprise Agreement）という定額AIライセンスを導入し、座席課金からの移行を始めた。

ここは区別が重要だ。これは「SaaSの死」ではなく「SaaSの課金モデルの死」だ。SaaS企業が消えるのではなく、収益の計算式が変わる。

2. 「Build vs Buy」の逆転¶

AI駆動開発で、カスタムアプリの構築コストが劇的に下がった。

Forrester等の調査会社は「振り子はBuild側に振れている」と分析している。AIネイティブ企業では、従来5〜10年かかった$100M ARRの到達が1〜2年に短縮されるケースも出ている。

構築コストの低下がどこまで進むかを示す一次情報がある。Claude Codeの開発者Boris Chernyは、Meta時代にFacebookグループのコードベース移行に「20〜30人のエンジニア×約2年」かかったプロジェクトについて、「今なら5人で6ヶ月。半年後には1人でできるかもしれない」と見積もっている（The Developing Dev、2025年12月）。Anthropic社内では、社員数が3倍になったにもかかわらず、Claude Code導入後にエンジニアあたりの生産性が約70%向上したという。

引用元のバイアスに注意

ChernyはClaude Codeの開発者であり、AIコーディングの有効性を語るインセンティブが最も高い人物だ。上記の数字はAIネイティブな環境（最先端モデルへの無制限アクセス、AI前提のチーム文化）での結果であり、一般企業にとっての「上限値」であって「平均的な到達点」ではない。Cherny自身も「6ヶ月前と今では答えが全然違う。6ヶ月後も全然違う」と予測の不確実性を認めている。

3. 汎用SaaSの淘汰¶

差別化の薄い汎用ツール――プロジェクト管理、ドキュメント管理、簡易CRMなど――は、AIエージェントが同等機能を即席で構築できるようになった時点で存在意義を失う。

市場では「death by a thousand plugins（特化プラグインによる千の死）」という表現が使われ始めている。

ここまでの要点： 「死ぬ」のはUI層寄りの汎用SaaSと座席課金モデル。SaaS全体が一様に消えるわけではない。

「残る」側の論拠¶

反対に、「SaaSは残る」側の論拠も3つある。

1. SoRとリスク移転は置き換えられない¶

自社でAIアプリを作っても、SLA・セキュリティ認証・監査対応は自動的には付いてこない。

Wedbush Securitiesの指摘がわかりやすい：「企業は数百億ドル規模の既存ソフトウェアインフラを完全に刷新してAIラボに移行することはない」。

数十年分のデータ整合性と運用責任の実績は、コードの代替とは別次元の価値だ。

2. SaaS自身がAIを取り込む¶

SaaSが座して待っているわけではない。

SalesforceはAgentforceでAIエージェントを自社プラットフォームに統合
HubSpot、ShopifyもAIを深く組み込んでいる
Gartnerは2028年までにエンタープライズソフトウェアの33%がエージェント型AIを組み込むと予測

「AIがSaaSを食う」のではなく「SaaSがAIの土台になる」シナリオだ。

具体例がすでにある。Anthropic社内では、セールスチームがClaude Codeを使ってSalesforceに直接接続し、データ入力や分析を行っている（Cherny、前掲インタビュー）。注目すべきは、彼らがSalesforceのUI画面を操作しているのではなく、APIを経由してSoR層に直接アクセスしている点だ。UI層の圧縮とSoR層の強化が同時に起きている具体例であり、SaaSが「データ基盤」として機能するシナリオを実証している。

3. 全体が一様ではなく「分断」が起きる¶

淘汰されるのは汎用SaaS。強化されるのは深い垂直SaaS（業界特化・規制対応）。

MIT Media LabのNANDAイニシアティブ（2025年7月）によれば、企業のAIパイロットプロジェクトの約95%は測定可能なP&L影響を出せていない。成功しているのは特定の課題に集中した約5%に限られる。

「AIで何でも置き換えられる」は、現時点のエビデンスからは支持されない。

NANDA報告書の留意点

この95%という数字は方法論について複数の専門家から批判を受けている。「大半のAIパイロットが期待通りのP&L成果を出せていない」という傾向の参考値として読むのが妥当だ。

製品タイプ別の影響度マップ¶

「死ぬ」「残る」の議論を、製品タイプ・課金モデル・理由で一枚にまとめる。

影響度	製品タイプ	例	課金モデル	なぜ
大	浅い横断SaaS	Notion、Asana、汎用CRM	座席課金	AI代替が容易。課金の前提も崩壊
中	Workflow特化だが差別化が薄い	Zapier、簡易ITSM	座席＋従量の混在	部分的に代替可能。価格競争に巻き込まれる
小	SoR/規制/監査が中核	SAP、Oracle Financials	リスク移転が価値の本体	データ整合性と責任の蓄積が参入障壁

ここまでの要点： 方向性は明確だ。問題は「どのくらいの速度で進むか」――次のセクションで扱う。

変化を遅らせる3つの構造的摩擦¶

「死ぬ／残る」は方向の話だ。ここからは速度の話をする。

市場には3つの構造的摩擦があり、変化の上限速度を規定している。「AIで何でも置き換えられるはず」という期待と現実のギャップは、おもにここから生まれる。

摩擦1：運用責任とデータ移行¶

AIでアプリを作れることと、本番環境で運用責任を負えることの間には大きな差がある。

具体的に想像してほしい。ある製造業が基幹ERPをAI生成アプリに置き換えようとする場面だ：

基幹系は停止＝業務停止。他システムとの接続が数百〜数千本ある
20年分の会計データ、顧客マスタ、在庫データを新環境に移行する必要がある
移行後のデータ整合性を検証し、切り替え後も一貫性を維持する
障害が起きたら誰が責任を取るのか？

この「データ移行と整合性の確保」は、コーディング速度とは無関係の、地味で時間のかかる作業だ。AIがどれだけ速くコードを書いても、この作業は短縮しにくい。

大手SIerが10〜20年の保守で蓄積した業務知識・統合ノウハウ・データ移行経験は、まさにこの摩擦を乗り越えるための資産であり、コーディング能力とは別物だ。

摩擦2：調達プロセスとガバナンス¶

大企業のシステム調達には時間がかかる。稟議、RFP、コンペ、評価委員会――半年から1年は普通だ。ベンダー選定基準に財務安定性やサポート体制が含まれる以上、新興のAIネイティブ企業が既存ベンダーを短期間で置き換えるのは構造的に難しい。

もう一つ見落としがちなリスクがある。AI駆動開発の民主化は、VBA氾濫の大規模な再来だ。

2000年代、Excel VBAで業務アプリを乱造した結果、誰も保守できない「野良マクロ」が社内に氾濫した。AIで誰でもアプリを作れる環境では、同じことがより大きな規模で起きうる。

これは仮説ではなく、すでに現実化している。Anthropic社内では、データサイエンティストがClaude CodeでSQL・dbtパイプラインを自作し、10年コードを書いていなかったマネージャーが週に数回コーディングしている。セールスチームもSalesforce連携を自分で構築している（Cherny、前掲インタビュー）。非エンジニアがコードを書く「現実」はすでに到来している。

ただし、同じインタビューには歯止めの先行事例も含まれている：

ChernyのチームではAIが書いたコードも人間が書いたコードも同じ基準でレビューするルールを徹底
CLAUDE.mdファイルにAIの間違いを蓄積し、学習コンテキストとしてフィードバック
AIに自分の成果物を検証させる「検証ループ」で品質が2〜3倍改善

つまりAnthropic内部では「VBA化しない仕組み」が意識的に構築されている。問題は、こうしたガバナンスを全社的に整備できる企業がどれだけあるかだ。

Gartnerは2027年末までにエージェント型AIプロジェクトの40%以上がキャンセルされると予測しており、主因は「ハイプに駆動された初期段階の実験」だとしている。

摩擦3：課金モデルの移行痛¶

SaaS企業自身にとっても、課金モデルの移行は容易ではない。

座席→消費量ベース： 収益の予測可能性が下がる。投資家が嫌う
成果連動（outcome-based）： 「成果」の定義で顧客と合意するのが難しい
定額制（SalesforceのALEA方式）： 結局「新たなロックイン」を生む

ベンダー側が新モデルに移行しきれない限り、顧客側の乗り換えも進まない。この移行期の混乱自体が、変化のブレーキになっている。

ここまでの要点： 方向性は「UI層の圧縮、SoR層の強化」で明確。ただし3つの構造的摩擦により、変化は市場が期待するほど速くは進まない。

レイヤー別の変化タイムライン¶

ここまでの分析を、時間軸で整理する。

層	想定期間	何が起きるか
UI層・汎用SaaS	1〜2年	座席課金の圧縮とエージェントによる操作代替が進む。株式市場はすでにこのシナリオを織り込み中
Workflow層	2〜5年	AIエージェントによる業務プロセス構築が普及する。ただし監査・ガバナンスの枠組み整備が並行して必要。「build vs buy」の主戦場
SoR層・基幹系	5年以上	データの正確性・監査・コンプライアンスの要件は変わらない。この層を押さえるSaaS企業とSIerは、AIの「土台」として強化される
調達構造・ベンダー関係	10年以上	長期契約、人的関係、スイッチングコストは技術革新とは別の時計で動く

この見積もりの根拠

AI側の進化速度： ChernyによればClaude Codeの利用率は半年で「10% → 50% → 80〜90%」に急伸した。ただし「モデルは全体的にまだコーディングがそれほど上手くない」とも認めている。AIツールの進化は速いが、安定性はまだ不十分だ。

企業側の摩擦： 一方、データ移行・調達プロセス・ベンダー関係は技術の進歩とは別の時計で動く（上述の摩擦1〜3）。方向は明確だが、速度を決めるのはAIの能力ではなく組織の変化速度だ。

よくある質問（FAQ）¶

Q. SaaS is deadは結局本当ですか？

A. 半分正しく、半分誤りです。 UI層中心の汎用SaaSは圧縮されやすい一方、SoR（System of Record）層はむしろ重要性が高まります。正確には「SaaSが死ぬ」のではなく「層ごとに分断して再編される」です。

Q. 企業はまず何から着手すべきですか？

A. SoRを維持したまま、UI/Workflow層で小さな実験から始めるのが現実的です。 具体的には、エージェント化の対象業務を限定し、監査ログ・権限管理・障害時責任の3点を先に設計してください。

Q. エンジニア個人はどのスキルを伸ばすべきですか？

A. 単純な実装速度より、統合・ガバナンス・品質判断の比重が上がります。 特に「どの層で価値を出すか（UI/Workflow/SoR）」を意識しつつ、AI活用とレビュー能力をセットで強化するのが有効です。

読者の立場別：明日から何をすべきか¶

同じ結論でも、読者の立場によって意味が変わる。

SaaS企業の経営者・プロダクトマネージャー。 まずUI価値への依存度を棚卸しする。課金モデルの再設計（座席→タスク/従量/成果連動）は避けて通れない。生存の分岐点は、SoRとガバナンスの価値を再定義し、AIの「土台」としてのポジションを確立できるかどうかだ。

企業IT・情シス。 SoRは維持しつつ、UI/Workflow層からエージェント実験を始めるのが合理的だ。ただしガバナンス不在のまま全社展開するとVBA時代の再来になる。先に決めるべきは「誰が何を作り、誰が運用責任を持つか」のルールだ。

SI・受託。 人月の工数売りから、統合設計・データ移行・ガバナンス構築へ価値を移転する。コーディング単価の下落は不可避だが、泥臭い調整と責任負担の価値は残る。上述の「摩擦1」こそが、SIerの存在価値が最も効く領域だ。

エンジニア個人。 自分の仕事がどのレイヤーにあるかを確認すること。UI層中心なら影響は早い。SoR/統合/ガバナンス寄りなら時間的猶予がある。問いは「エンジニアはどうなるか」ではなく「自分のスキルはどの層で効くか」だ。

ただし「どの層にいるか」とは別の軸もある。Chernyは採用において「コードも書けるし、プロダクトワークもデザインもユーザーリサーチもできるジェネラリスト」を重視すると語っている（前掲インタビュー）。AIがコーディング作業を圧縮する時代に価値が上がるのは、AIツールを使いこなしつつ、コード品質の基準を自分で判断でき、プロダクト感覚を持つエンジニアだ。レイヤーの確認に加えて、自分のスキルの「幅」を点検する視点が要る。

まとめ：SaaSは死なない、分断する¶

2026年2月のSaaS株暴落は、市場が「AIエージェントによるSaaS全面置換」シナリオに過剰反応した結果だ。実際に起きているのは全体の死ではなく、分断（bifurcation）だ。

死ぬもの： UI層に価値が偏った汎用SaaSと、座席課金モデル
残るもの： System of Recordとしての信頼・統制・リスク移転を提供する深い垂直SaaS
進化するもの： SaaS自身がAIを取り込み、課金モデルを再定義しながら変化していく

「SaaS is dead」という3語は議論の入口としては機能するが、判断材料としては粗すぎる。どの層の、どの機能の、どの課金モデルが影響を受けるのか。その分解なしに、投資判断もキャリア判断もできない。