SaaS終焉論とは?AI時代に読む論点・反論・判断軸
Check!
- SaaS終焉論の論点と発信源(VC・業界アナリスト)
- 終焉論への代表的な反論と、議論を冷静に読む観点
- 日本市場での読み解き方と規模別の判断軸
「SaaSは終焉するのか」という議論は、AIエージェントの進化、座席課金モデルへの疑問、SaaSの増えすぎによるコスト負担が重なって広がっています。ただし、SaaSがすぐに全滅するという意味ではありません。個人事業主、中小企業、中堅大企業のいずれにとっても大切なのは、話題の強さに反応して解約を急ぐことではなく、どの業務はAIで置き換わりやすいのか、どの領域はデータ管理・監査・セキュリティの理由で残りやすいのかを分けて見ることです。この記事では、SaaS終焉論の根拠と反論を中立的に整理し、日本市場で自社のSaaS活用を見直すための判断軸を解説します。
おすすめ記事
目次
開く
閉じる
開く
閉じる
SaaS終焉論とは何か|「全滅」ではなく再編論として読む
SaaS終焉論は、SaaSという利用形態そのものが消えるというより、AIエージェントや業務自動化によって従来型SaaSの価値が問い直されるという議論です。まずは「終焉」という強い言葉を、市場の再編、価格体系の変化、業務UIの変化として読み替えることが重要です。
終焉論が指すもの
SaaSは、クラウド上でアプリケーションを利用するモデルです。NIST SP 800-145では、クラウドコンピューティングをオンデマンドでネットワーク越しに共有リソースへアクセスするモデルとして整理し、SaaS、PaaS、IaaSをサービスモデルとして位置づけています。つまりSaaS終焉論を読むときは、クラウド利用そのものの終わりではなく、アプリケーション層の使われ方が変わる議論として分ける必要があります。
たとえば、入力画面を人が操作する前提のSaaSは、AIエージェントが業務を代行するほど価値の説明が変わります。一方で、顧客データ、契約履歴、承認ログ、監査証跡を保持するSaaSは、単なる画面ではなく業務の記録基盤として残る余地があります。
あわせて確認したい論点
SaaS終焉論の主張と反論を同じ土俵で整理するには、周辺の論点と分けて読むことが大切です。SaaSという概念の詳しい定義はSaaSの死、派生語の整理はSaaSの死とは、株式市場の反応はSaaSショック、懐疑論の詳しい読み方はSaaSオワコンで分けて確認できます。
終焉論の根拠とされる5つの論点
SaaS終焉論の根拠は、主に5つに分けられます。いずれも一部のSaaSには影響しますが、すべてのSaaSに同じ強さで当てはまるわけではありません。
AIエージェントがUIを置き換える論点
もっとも大きな論点は、AIエージェントが複数のSaaS画面を横断して操作し、人が入力画面を開く機会を減らす可能性です。これにより、単純な入力、転記、検索、要約だけを提供価値にしているSaaSは、従来のままでは価値を説明しにくくなります。
ただし、AIの影響はSaaSの外から来るだけではありません。既存SaaSの中にAI機能が組み込まれ、入力補助、異常検知、予測、レポート作成を担う形もあります。SaaSとAIの関係は、SaaSとAIの記事で詳しく整理しています。
座席課金モデルが揺らぐ論点
従来のSaaSは、利用者数に応じて料金が増える座席課金と相性がよいモデルでした。しかし、少人数がAIを使って多くの業務をこなす場合、人数単位の課金と利用価値がずれる可能性があります。今後は、利用量、処理回数、成果、データ量などを組み合わせた料金体系が増えることも考えられます。
ノーコード・内製化が進む論点
AIによって簡単な業務アプリや自動化フローを内製しやすくなると、汎用的な小規模SaaSの一部は置き換え候補になります。個人事業主や小規模チームでは、単機能ツールを複数契約するより、AIと汎用ツールを組み合わせる方が低コストになる場合があります。
SaaS過多とコスト最適化の論点
部門ごとにSaaSを導入した結果、似た機能の重複、使われないアカウント、権限管理の複雑化が起きることがあります。このようなSaaS過多は、終焉論とは別に、企業が定期的に見直すべき運用課題です。
データ分断と連携負荷の論点
SaaSが増えるほど、顧客データ、商談データ、請求データ、人事データが分かれます。API連携やID管理が弱いままツールを増やすと、AI活用の前提になるデータ整備も難しくなります。そのため、SaaS終焉論は「SaaSを使うかどうか」だけでなく、「業務データをどうつなぐか」という論点でもあります。
終焉論への反論|SaaSが残りやすい5つの理由
終焉論への反論は、SaaSが単なる操作画面ではなく、業務データ、権限、監査、セキュリティ、連携を支える仕組みである点にあります。AIが進んでも、企業活動の記録と統制は残ります。
業務データと監査証跡は代替しにくい
請求、会計、人事、営業、契約などのSaaSには、日々の入力結果だけでなく、誰が、いつ、どの情報を変更したかという履歴が残ります。AIが作業を代行しても、その結果を保存し、監査できる形にする基盤は必要です。
セキュリティ・権限管理・運用責任が残る
IPAのクラウド利用者向け資料やISMAP制度が示すように、クラウドサービスの利用では、アクセス制御、認証、ログ、委託先管理、インシデント対応などの確認が重要です。AIエージェントを使う場合も、誰の権限で、どのデータにアクセスし、どの処理を行ったのかを管理する必要があります。
AIはSaaSの上に組み込まれる場合も多い
AIがSaaSを外から置き換えるだけでなく、SaaSの中にAI機能として組み込まれる流れもあります。たとえば、入力補助、需要予測、チャット型検索、自動レポート、リスク検知などは、既存データを持つSaaSの中で実装されるほど使いやすい場合があります。LLMの基本を整理したい場合は、LLMとはの記事も参考になります。
| 論点 | 終焉論の見方 | 反論・補足の見方 |
|---|---|---|
| UI | AIが画面操作を代行する | 操作画面は減っても、記録基盤は残る |
| 価格 | 座席課金が合わなくなる | 利用量・成果連動などへ変化する余地がある |
| 業務アプリ | 簡単な機能は内製しやすくなる | 統制・監査が必要な業務はSaaSが残りやすい |
| データ | 複数SaaSに分断される | 連携・ID管理・データ基盤としての価値が増す |
| AI | SaaSを置き換える | SaaSに組み込まれて価値を高める場合もある |
日本市場ではどう読むべきか|導入率よりも統制と運用を見る
日本市場では、SaaS終焉論をそのまま輸入して読むより、段階的な運用改善の議論として読む方が実務に合います。総務省の情報通信白書やクラウドセキュリティ関連資料を踏まえると、クラウド利用は広がる一方で、情報管理、セキュリティ、委託先確認の重要性も高まっています。
日本企業では段階的な移行が起きやすい
既存の業務フロー、承認ルール、監査対応、取引先とのやり取りがある企業では、SaaSを一度にやめるより、重複契約の整理、ID管理の統合、AI機能の追加、データ連携の改善から進める方が現実的です。中堅大企業では、部門単位で使っているSaaSを棚卸しし、基幹システムやデータ基盤との接続を確認することが先になります。
公的制度・セキュリティ要件が意思決定を左右する
クラウドサービスの選定では、利便性だけでなく、契約、可用性、データ保護、アクセス管理、障害時対応を確認する必要があります。政府情報システムのクラウド利用ではISMAPのような評価制度も整備されており、民間企業でも同じ考え方を参考にできます。AI時代のSaaS議論をさらに広く見たい場合は、AIとはの基礎も押さえると理解しやすくなります。
企業規模別の判断軸
SaaS終焉論を自社に当てはめるときは、会社の規模によって見るべき点が変わります。個人事業主はコストと作業効率、中小企業は部門横断の管理、中堅大企業は統制・監査・データ連携を重視すると整理しやすくなります。
個人事業主の判断軸
個人事業主は、毎月使っていないSaaS、同じ機能を持つSaaS、AIや汎用ツールで代替できる軽い作業から見直すのが現実的です。一方で、会計、請求、契約、顧客管理など、証跡や法務に関わる領域は、安易に自作へ寄せすぎない方が安全です。
中小企業の判断軸
中小企業では、部門ごとに導入したSaaSが増え、アカウント管理やデータ連携が複雑になりやすいです。まずは全社のSaaS一覧を作り、契約者、利用部門、月額費用、管理者、扱うデータ、退職時の権限停止方法を確認します。そのうえで、AIで置き換える領域と、SaaSとして残す領域を分けます。
中堅大企業の判断軸
中堅大企業では、SaaSの削減だけを目的にすると、現場の業務効率や監査対応に影響が出ることがあります。経営企画、情報システム、法務、セキュリティ、現場部門が同じ基準で評価し、ID管理、ログ、データ保持、API連携、委託先管理を確認することが重要です。中長期の見方はSaaSの将来性でも補足できます。
| 対象 | 先に見るポイント | 残しやすいSaaS | 見直し候補 |
|---|---|---|---|
| 個人事業主 | 費用・作業時間・証跡 | 会計、請求、契約、顧客管理 | 低頻度の単機能ツール |
| 中小企業 | 部門重複・管理者・権限 | 全社利用、データ連携があるSaaS | 部署ごとの重複SaaS |
| 中堅大企業 | 統制・監査・連携・委託先管理 | 基幹連携、監査ログ、ID統合を持つSaaS | 孤立した部門SaaS |
SaaS終焉論を自社の判断に変える手順
SaaS終焉論を実務に活かすには、話題になっている主張をそのまま採用するのではなく、自社の契約、業務、データ、統制に分けて確認することが大切です。解約や乗り換えを急ぐ前に、どの機能が置き換わりやすく、どの機能が残りやすいのかを順番に見ます。
契約中のSaaSを棚卸しする
最初に、契約中のSaaSを一覧化します。サービス名、利用部門、管理者、契約更新月、料金体系、扱うデータ、外部連携、退職者アカウントの停止方法を確認します。使われていないSaaSや、同じ機能が重複しているSaaSは、終焉論とは関係なく見直し候補になります。
AIで置き換えやすい機能を分ける
次に、AIで置き換えやすい機能と、SaaSとして残すべき機能を分けます。文章生成、要約、転記、検索、簡単な分類はAIで補える可能性があります。一方で、承認履歴、監査ログ、権限管理、契約管理、法務・会計に関わる記録は、SaaS側に残す判断になりやすい領域です。
更新月の前に見直し基準を決める
契約更新の直前に慌てて判断すると、利用状況やデータ移行の確認が不足しやすくなります。更新月の数か月前から、利用頻度、代替手段、データ出力、解約条件、移行作業、セキュリティ要件を確認しておくと、解約、統合、継続の判断をしやすくなります。
| 確認項目 | 見るポイント | 判断の方向性 |
|---|---|---|
| 利用状況 | ログイン頻度、利用部門、利用者数 | 未利用なら整理候補 |
| データ | 顧客情報、契約情報、会計情報の有無 | 重要データがあれば慎重に判断 |
| 権限管理 | 管理者、退職者アカウント、外部共有 | 不明点があれば継続前に整備 |
| 連携 | API、CSV連携、他SaaSとの接続 | 連携先への影響を確認 |
| 契約条件 | 更新月、最低契約期間、解約手順 | 更新前に判断材料をそろえる |
よくある質問(FAQ)
Q. SaaSは本当に終わるのですか?
A. すぐに全体がなくなると読むより、機能や価格体系が再編されると読む方が実務的です。入力画面中心の単機能SaaSは見直し対象になりやすい一方で、監査ログ、権限管理、業務データを持つSaaSは残りやすいです。
Q. どのSaaSから見直すべきですか?
A. 利用頻度が低い、同じ機能が重複している、管理者が不明、重要データを扱わないSaaSから棚卸しすると進めやすいです。会計、契約、人事、顧客管理など証跡が必要な領域は慎重に扱います。
Q. AIエージェントだけに置き換えてよいですか?
A. 置き換えを考える場合も、権限、ログ、データ保持、誤処理時の責任、取引先との整合を確認する必要があります。AIは業務を速くする可能性がありますが、統制まで自動で解決するとは限りません。
Q. 日本企業は何を優先すべきですか?
A. まずSaaSの棚卸し、ID管理、退職者アカウントの停止、契約更新前の利用状況確認、重要データの所在確認を優先します。そのうえで、AIで効率化する領域と、SaaSとして残す領域を分けるのが安全です。
まとめ|今日からできる3つのこと
今日からできる3つのこと
- 契約中のSaaSを一覧化し、利用部門、管理者、扱うデータ、更新月を確認する
- AIで置き換えやすい単純作業と、監査・権限管理が必要な業務を分ける
- 解約判断の前に、ID管理、ログ、データ連携、委託先管理の影響を確認する
読み解きの姿勢
SaaS終焉論は、過度に恐れるものでも、軽く受け流すものでもありません。AI時代には、SaaSの一部機能が置き換わり、料金体系や価値の説明が変わる可能性があります。一方で、企業活動の記録、承認、監査、データ管理を担うSaaSは、形を変えながら残る余地があります。大切なのは、話題性ではなく、自社の業務、データ、統制に照らして見直すことです。
出典一覧
公的機関・標準文書
- National Institute of Standards and Technology / The NIST Definition of Cloud Computing(SP 800-145) / 2011年9月 / https://csrc.nist.gov/pubs/sp/800/145/final / 取得日:2026-06-14
- 経済産業省 / デジタルガバナンス・コード3.0〜DX経営による企業価値向上に向けて〜 / 2024年9月 / https://www.meti.go.jp/policy/it_policy/investment/dgc/dgc.html / 取得日:2026-06-14
- 総務省 / 令和7年版 情報通信白書 / 2025年 / https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r07/ / 取得日:2026-06-14
- 総務省 / クラウドサービス提供における情報セキュリティ対策ガイドライン / 2021年9月 / https://www.soumu.go.jp/ / 取得日:2026-06-14
- 独立行政法人情報処理推進機構(IPA) / クラウド利用者のための情報セキュリティチェックシート / 2022年 / https://www.ipa.go.jp/security/ / 取得日:2026-06-14
- 内閣サイバーセキュリティセンター・デジタル庁・総務省・経済産業省 / ISMAP:政府情報システムのためのセキュリティ評価制度 / 2020年制度運用開始 / https://www.ismap.go.jp/ / 取得日:2026-06-14
この記事に興味を持った方におすすめ