MENU
中小企業のためのAI導入・活用の実務メディア（運営：株式会社Walkers）
  1. ホーム
  2. 比較・選び方
  3. 「SaaS is dead」とは｜誰がいつ言ったのか、中小企業の見直し範囲

「SaaS is dead」とは｜誰がいつ言ったのか、中小企業の見直し範囲

比較・選び方
2026年9月7日
「SaaS is dead」とは｜誰がいつ言ったのか、中小企業の見直し範囲
著者: Walkers編集部監修: 渡辺 敦司（株式会社Walkers 代表取締役）公開: 2026年9月7日最終更新: 2026年10月9日監修者: AI駆動開発・FDE型AI導入支援の実務家

「SaaS is dead（SaaSは死んだ）」は、クラウド経由で提供される業務ソフトウェア（SaaS）の将来をめぐり、2024年後半からテック業界で広まった議論の象徴的なフレーズです。2024年12月12日に配信されたポッドキャスト「BG2 Pod」における、Microsoft CEO（当時）サティア・ナデラ氏の発言をメディアが要約した表現として知られていますが、ナデラ氏自身はこの言葉を使っていません。ナデラ氏が語ったのは、業務手順や判定条件といった「業務ロジック」の置き場所が、個々の業務アプリケーションから全体を束ねる「AI層（基盤側）」へ移るという構造変化の予測でした。この記事では報道と一次発言の時系列を整理し、中小企業が実際に見直すべきツールの範囲を解説します。

目次

「SaaS is dead」は誰がいつ言ったのか — 一次情報で見る実際の発言

この議論で特によく引用されるのが、Microsoft CEO（当時）のサティア・ナデラ氏が2024年12月12日配信のポッドキャスト「BG2 Pod」（Bill Gurley氏・Brad Gerstner氏との対談）で語った内容です。ナデラ氏は既存のビジネスアプリケーションについて、本質的には大量の業務ロジックを伴うCRUD（データの登録・参照・更新・削除）データベースのような構造であるという趣旨を指摘しました。そのうえで、今後は業務ロジックがAIエージェント側に移り、複数のデータベースを横断して自律的に処理を担うようになるという技術的な将来像を語っています。

「SaaS is dead」という刺激的な言葉自体は、ナデラ氏自身が発した表現ではありません。この対談内容を取り上げたメディアやアナリストが、要約の見出しとして用いた例が知られています。ナデラ氏が提示したのは「SaaSというソフトウェア形態が完全に消滅する」ということではなく、「個々のSaaSアプリが抱えていた業務ロジックの主導権が、AI層へ移行する可能性がある」というシステム構造の変化でした。

なぜこの言葉が広まったのか — Klarna報道とその後の本人による説明

「SaaS不要論」がナデラ氏の発言前から注目を集めていた背景には、後払い決済サービスを手がけるスウェーデンKlarna（クラーナ）社をめぐる一連の報道がありました。時系列を整理すると、次のようになります。

発端は2024年8月の投資家向け電話会議です。Klarna社CEOのSebastian Siemiatkowski氏が「AI、標準化、簡素化の組み合わせ」によりSalesforceの利用を停止し、数週間以内にWorkdayも停止予定であると述べたと報じられました。これを受け、2024年8〜9月にかけてテック系メディア（Salesforce Benなど）を中心に「Klarnaが大手SaaSをAIに置き換えた」と大々的に報じられ、業界に大きな衝撃を与えました。

しかし、その後の取材報道や本人発言によって実態が明らかになります。2024年12月のCX Todayの報道では、Klarna社は人事管理（HR）をWorkdayから別のSaaSであるDeelへ切り替えており、顧客管理（CRM）機能も別のSaaSや社内基盤を組み合わせて再構築していたことが伝えられました。社内チャットツールとしてSlack（Salesforce傘下）の利用を継続している点も指摘されています。

さらに2025年3月、Siemiatkowski氏本人がX（旧Twitter）で当時の過熱報道に言及し、”we did not replace SaaS with an LLM”（SaaSをLLM〈大規模言語モデル〉で置き換えたわけではない）と明言しました。実際に行ったのは、社内データが複数のSaaSに分散してサイロ化（孤立）していたため、Neo4jなどのグラフ技術やAIを活用して社内データを統合し、不要になったSaaS契約を整理したというプロセスでした。つまり「AIが既存SaaSを丸ごと消し去った」のではなく、「社内データの統合と業務の標準化を進めた結果、不要なSaaS契約を削減・集約した」というのが実態です。

Klarna社の実態とナデラ氏の将来予測を照らし合わせると、「SaaSはすべて不要になる」という極論は成り立ちません。中小企業にとっての実務上の焦点は、「SaaSかAIか」という二者択一ではなく、標準機能のSaaSで十分に回る領域と、自社の商流に合わせて自前で組む価値がある領域を冷静に見極めることにあります。

「SaaS is dead」をめぐる報道と実際の発言の時系列
  1. 2024年8〜9月：Klarna報道（メディア報道） 投資家電話会議でSalesforce停止とWorkdayの停止予定が言及され、AIによる大手SaaS代替としてメディアが報道
  2. 2024年12月：実態報道（メディア取材） CX Todayが取材。HRは別SaaS（Deel）へ移行し、CRMも他SaaS・自社基盤を併用。Slackも継続と判明
  3. 2024年12月：ナデラ氏の対談（本人発言） BG2 Podにて「業務ロジックがアプリからAI層へ移る」構造変化を予測。メディアが「SaaS is dead」と要約
  4. 2025年3月：Klarna CEOの説明（本人発言） CEOがXで「LLMでSaaSを置換したのではない」と明言。実態はデータ統合に伴うSaaSの整理・集約
  5. 実務への示唆（編集部の整理） 全SaaSの廃止ではなく、制度対応・社外接続SaaSの維持と自社独自業務の仕分け・統合が本質

矢印は時間順序を示します。「SaaS is dead」という言葉はナデラ氏本人の発言ではなくメディアの要約表現です。

中小企業でSaaS費用はどう積み上がるのか — 20名規模のモデルケース

SaaSの費用が「気づいたら積み上がっている」状態になるのは、多くの場合、悪意ある無駄遣いではありません。部門ごとに必要なツールを都度契約し、ユーザー数課金のプランが従業員の増加とともに比例して膨らみ、契約更新のタイミングで見直されないまま自動更新が続く。この3つが重なった結果です。

自社の場合に置き換えて考えるために、従業員20名規模の会社を想定したモデルケースを示します。これは契約構造の違いを可視化するための架空の試算例であり、実際の支払額は各社の契約内容・オプション・利用状況によって異なります。

試算の前提条件: 全社ツール（Chatwork、kintone、KING OF TIME）は20名全員が利用。会計（freee会計）は経理・経営者権限の5名（基本3名＋追加2名、追加有料機能や申請・承認等の従量利用は含めない前提）、請求書（Misoca）は発行担当5名（所有者1名＋招待メンバー4名の登録上限、月間発行100通以内）が利用するものとして設定します。年契約が確認できるものはその条件を用い、月額料金のみのものは12か月分を積算した年額目安として算出しています（税別・税込の表示条件は各社公式サイトに準拠）。

カテゴリ 例として挙げるサービス 価格体系と想定利用人数（公式サイト表示に基づく） 月額換算目安 年額目安
チャット・社内連絡 Chatwork（スタンダード） 1ユーザー月額700円（税別・年契約）× 20名 14,000円 168,000円
業務アプリ基盤・案件管理 kintone（スタンダード） 1ユーザー月額1,800円（税別・10名以上）× 20名 36,000円 432,000円
勤怠管理 KING OF TIME 1ユーザー月額300円（初期費用0円）× 20名 6,000円 72,000円
法人会計 freee会計（法人スタンダード） 基本料月額換算8,980円（3名分含む）＋経理権限追加2名（月300円×2）＝月額換算9,580円（税別・年払い・追加有料機能や従量利用なし） 9,580円 114,960円
請求書作成・発行 Misoca（プラン100） 年額33,500円（税別・次年度以降通常価格。月100通まで・所有者1名と招待4名の登録メンバー上限5名）※月額換算は約2,792円 2,792円 33,500円

価格は2026年9月7日時点で各社公式サイトに掲載されていた情報に基づく試算です。Misocaは初年度無償キャンペーンがありますが、継続的な固定費を把握するため次年度以降の通常価格を採用しています。この5カテゴリの掲載額を単純合算すると、年額で820,460円（月額換算で約68,372円、約6.84万円／月・約82.05万円／年）となります。各社で税別表示や端数処理の条件が一部混在するため、これは実際の請求総額ではなく構成比を見るための参考合計値です。ここに営業支援（SFA）やファイル共有、Web会議などが加われば費用はさらに積み上がります。重要なのは総額の多寡だけでなく、「人数に比例して自動で増える課金」「基本料＋権限別の追加課金」「定額・従量課金」がどのように組み合わさっているかを把握することです。

SaaSを残すべき領域、見直し候補になりやすい領域

「SaaS is dead」を額面通りに受け取って全SaaSを解約するのは、実務的ではありません。Klarna社の事例が示すように、実際の作業は「全否定」ではなく「仕分け」です。判断軸を、残すべき領域になりやすいものと、見直し候補になりやすいものに分けて整理します。オンプレミスやパッケージの製品も、提供元がサポートを終える時期が来れば同じ仕分けの対象になります。具体例は奉行11シリーズのサポート終了はいつかで扱っています。

判断の視点 SaaSを残すべき領域になりやすい 見直し・再設計の候補になりやすい
法改正・外部制度への追従 会計・給与計算など、税制や法令改正への継続アップデートをベンダーに委ねる必要がある領域（例: freeeなど） 法対応がほぼ関係なく、自社独自の商流や手順に汎用SaaSの画面や制限を無理に合わせている領域
社外接続・標準プロトコル 社外の取引先・顧客と直接接続するメール・チャットなど、業界標準の仕様が求められる領域 社内完結の業務で、似た役割のツールが複数乱立しデータが分断・二重入力されている領域
課金構造と利用規模 組織単位の固定制や、利用人数が増えても追加コストが緩やかな料金体系の領域 全社員へのID付与が必須で、利用実態の薄い層の分までユーザー単価が毎月積み上がっている領域
機能の活用状況と保守責任 ID管理・セキュリティなど専門的な保守を自社で抱えきれない基盤領域 上位プランの一部機能しか使っておらず、休眠アカウントや形骸化した入力項目が放置されている領域

「残すべき領域」は、法改正への追従やセキュリティパッチの提供をベンダーが責任を持って継続してくれる点に本質的な価値があります。これを自前で内製・保守しようとすると、制度変更のたびに自社で開発保守費用を背負い続けることになり、かえって負担が増加します。経理業務でのAI活用のように、標準的な専門SaaSを活用しつつ自社独自の集計や自動化を補う組み合わせが現実的です。

一方「見直し候補」は、契約時の構想と現場の運用実態にズレが生じやすい領域です。特にCRM（顧客管理）や営業管理ツールは、営業業務でのAI活用でも触れているように、自社独自の商談フローに合わないまま形骸化し、単なる二重入力の手間になっているケースが散見されます。定額か人数課金かという料金形態のラベルだけでなく、実際の利用頻度と業務適合度をセットで点検することが重要です。

業務データの置き場と生成AIの担当範囲をあえて分けた実例は、事例集の〈CASE 06｜業務DBと生成AIを、あえて分ける〉で確認できます。

内製・独自構築という選択肢は現実的か — AI駆動開発という視点

SaaSの重複やギャップを整理する選択肢として、自社業務に合わせた個別システムの独自構築・内製を検討する企業も増えています。AI駆動開発（コード生成や設計補助にAIを活用する開発手法）の進展により、仕様設計からコーディングまでの試行錯誤を速められる環境が整ってきたためです。ただし、開発にAIを使うこと、完成したシステム内にAI機能を組み込むこと、そして社内で完全に自前開発（内製）することと外部パートナーへ委託することは、それぞれ別の論点です。

独自構築が常に既製品SaaSより優れているわけではありません。判断の基準となるのは次の4点です。

  • 制度変更への追従頻度: 法令や税制への対応が必要な領域は、自前で構築すると改修と検証の責任を永続的に負うことになります。
  • 運用・保守の責任体制: リリース後のバグ修正や仕様変更、クラウド基盤・外部APIの利用料管理を社内人材または委託先が安定して担えるか。
  • 業務手順の独自性と競争力: 自社特有の商流や強みに直結する部分か、他社と共通の定型処理か。
  • 投資対効果の見合い: チャットやメールなどの汎用ツールは既製品SaaSが圧倒的に安価であり、独自構築する合理性は希薄です。

自社のどの業務に自動化や独自開発の余地があるか整理したい場合は、無料のAI自動化診断を検討材料として活用できます。

なお、当メディアを運営する株式会社Walkersは、AI駆動開発を基盤とした個別システムの開発支援を手がける事業者です（共通SaaSを提供するのではなく、顧客ごとに独立した環境を構築・伴走する提供形態についてはFDE型AI導入支援とはで詳述しています）。自社の立場を開示したうえで、SaaS継続か独自構築かの判断は、業務の汎用性と保守体制を踏まえて客観的に検討することをおすすめします。

自社専用の自動化基盤を検証した実例（自社開発での実装・検証事例）は、事例集の〈CASE 02｜毎日の巡回・転記を、AIが引き取る〉で確認できます。

自社のSaaS構成を見直す実務手順

SaaS構成の見直しは、思いつきで契約を切るのではなく、次の手順で進めると現実的です。

  1. 契約中のSaaSを棚卸しする: 部門ごとに個別契約され全体像が見えなくなっているケースが多いため、請求明細やクレジットカード明細から一覧化します。
  2. カテゴリごとの機能重複を洗い出す: チャット、CRM、勤怠、会計、請求書発行など、役割が重なるツールや二重管理がないか確認します。
  3. 課金構造に合わせて年間コストを算出する: 単純な「人数×単価×12か月」だけでなく、基本料金＋権限別追加料金、年額固定＋従量課金など、ツールの契約タイプ別に正確な年間費用を集計します。
  4. 「残す領域」と「見直す領域」に仕分けする: 法改正への追従性、社外接続性、課金の弾力性、現場での実際の稼働率の4点から客観的に評価します。
  5. 契約更新月を起点に計画を立てる: 年間契約の途中解約による違約金や返金不可のリスクを避けるため、各ツールの次回更新月を逆算して代替案や統廃合を進めます。

棚卸し台帳の作成法や休眠アカウントの見つけ方はSaaS費用の棚卸し実務、解約条件やデータ移行の注意点は脱SaaSのよくある質問20で解説しています。

業務別の具体的な見直し基準は、各個別記事で詳しく整理しています。既存リンクを用途別に参照できます。

この手順を進める前提として、そもそも自社のどの業務にAIやシステムを充てるべきかという棚卸しが必要になります。進め方の全体像は中小企業のAI導入 完全ガイド、ツール選定でつまずきやすい典型パターンは中小企業のAI導入 失敗パターン7選で解説しています。

AI駆動開発で独自構築する場合の確認事項

見直しの結果として独自構築を選択する場合、SaaSの利用時とどのような違いが生じるかをあらかじめ押さえておく必要があります。例えば弊社の提供形態のように顧客ごとに専用環境（1社1環境）を構築する構成では、ベンダー共通の既製品仕様から自社の業務フローに合わせた設計へ移る点が特徴です。採用する構成によってはユーザー数課金や画面の制約を回避しやすくなる反面、不具合対応やデータ保全、クラウド基盤・外部APIの管理責任を自社または委託先との保守体制でどう分担するかを明確にしておく必要があります。

また、費用構造も変化します。SaaSの月額ライセンス課金から、初期の開発工数およびサーバー・外部API利用料を含む継続保守費用の管理へとシフトします（費用の全体構造はAI駆動開発の費用相場を参照）。そのため、まずは業務の棚卸しを行い、最初から全社一括で作り替えるのではなく、影響範囲の限定された1業務から小さく検証（MVP）して拡張する手順を踏むことがリスク回避につながります。

当然ながら、法改正の頻繁な会計・給与計算や、標準機能で十分業務が回っている領域は、あえて独自構築する対象ではありません。SaaSに残す業務と自社で組む業務の役割分担を明確にすることが肝要です。

よくある質問

SaaSは本当になくなるのですか？

なくなるとは言えません。会計・給与など法改正対応が必要な領域は、SaaSの継続的な更新に強みがあります。「SaaS is dead」は全否定ではなく、自社に合わない契約や重複投資を見直す契機と捉えるのが実務的です。

「SaaS is dead」と言ったのはナデラ氏本人ですか？

この言葉自体を氏が使ったわけではありません。氏が語ったのは、ビジネスアプリケーションはCRUDデータベースと業務ロジックの集合体であり、そのロジックがAI層に移っていくという趣旨の発言です。メディアがこれを要約フレーズとして取り上げた例が知られています。

どのSaaSから見直せばいいですか？

自社独自の業務に汎用ツールを無理に当てはめ、複数併用でデータが分散している領域と、ユーザー数課金で人数増加とともに費用が膨らむ領域から確認してください。契約時の想定より使用頻度が低いプランも点検の対象です。

「SaaS is dead」はいつから言われるようになったのですか？

本記事で取り上げる時系列では、2024年8〜9月にKlarna社の大手SaaS見直しが報じられ、同年12月にサティア・ナデラ氏が業務アプリケーションの構造変化を対談で語った際、メディアや論者が要約の見出しとして用いた例が注目されました。初出や定着の経緯を一律に断定できるものではありませんが、この時期の一連の報道や発言を契機に議論が盛んになりました。

なぜ「SaaS is dead」と言われるようになったのですか？

業務ロジックがAIエージェント側に移行するというナデラ氏の将来予測をメディアが見出しとして要約した例や、Klarna社のSaaS見直し報道と関連づけて取り上げられたことが主な契機として挙げられます。ただしKlarna社CEOは後にSaaSのLLM代替を否定しており、すべてのSaaSが不要になるという意味ではありません。

自社のSaaS構成のどこから見直すべきかを客観的に知りたい方は、無料のAI自動化診断をご利用ください。自社の業務に合わせたシステムをAI駆動開発で作る場合の相談・見積りは、株式会社Walkersのシステム開発事業で受け付けています。本記事は、FDE型のAI導入支援を行う株式会社Walkersが運営しています。

参考

執筆時点（2026年9月）に各一次情報・公式サイトで確認できた内容に基づきます。

比較・選び方
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

この記事を書いた人

Walkers編集部のアバター Walkers編集部

関連記事

目次
閉じる