SaaSの死とは｜利用者の3つのリスク

SaaSの死とは、生成AIやAIエージェントの進化によって、SaaSの価値の出し方や料金の決め方が変わりつつあるという議論を指す言葉で、SaaSというサービスが消えるという意味ではありません。読み方は「サースのし」が一般的で、英語の「SaaS is dead」を日本語にした表現です。ニュースやSNSで見かけて「今使っている業務システムは大丈夫なのか」と不安になった方に向けて、この記事では言葉の意味と発端、背景にある市場の動き、利用者が注意すべき3つのリスク、そして自社の契約を点検する手順を、公的資料と公式情報をもとに整理します。株式市場や投資家の見方ではなく、SaaSを使う側の企業が何を確認しておけばよいかに絞って解説します。

目次

開く

閉じる

1. 「SaaSの死」で利用者が最初に確かめたい、自社のSaaS契約の見える化
2. 「SaaSの死」とは｜意味・読み方・言葉の発端
3. 背景｜AIエージェントの台頭と株式市場の反応
4. 利用者が注意すべきリスク1：ベンダーの事業継続性
5. 利用者が注意すべきリスク2：データ移行の困難さ(ベンダーロックイン)
6. 利用者が注意すべきリスク3：契約形態・価格モデルの変化
7. 自社のSaaSを点検する4つのステップ
8. よくある質問(FAQ)
9. まとめ｜SaaSの死は「契約とデータを見直すきっかけ」
10. 参考文献

「SaaSの死」で利用者が最初に確かめたい、自社のSaaS契約の見える化

「SaaSの死」を受けて利用者が最初に取り組みたい備えは、自社がどのSaaSをどんな条件で契約しているかを一覧にし、更新日と解約条件をすぐ確認できる状態にすることです。

後述する3つのリスク(事業継続性、データ移行、契約形態・価格モデルの変化)は、いずれも契約書や利用規約の条項、更新日、通知の期限といった契約情報に関わります。ところが、これらの情報は契約書、利用規約、申込時のメールに散らばっていることが多く、ベンダーの料金体系や事業方針が変わったときにすぐ確認できないと、気づいたときには自動更新が済んでいた、データの保存期間が過ぎていた、ということになりかねません。

SaaSの契約は、契約書を取り交わさずオンライン上で利用規約に同意して始まる場合もあります。その場合は規約の控えや申込メール、請求書もあわせて同じ場所にまとめておくと確認しやすくなります。契約書の保管と更新日の通知を1つの仕組みで行えるものとして、契約書の管理に対応した電子契約システムがあります。取引先と結ぶ契約とSaaSの契約を同じ場所で管理できる場合もあるため、一例として5つのサービスの役割の違いを、商品ページで確認した内容(2026年10月15日時点)をもとに並べます。優劣や順位ではなく、どんな会社に向くかの違いとして読んでください。

契約の相手や用途に応じて署名の方式を選びながら、契約業務をオンラインにそろえたい場合の一例が電子印鑑GMOサインです。運営会社はGMOグローバルサイン・ホールディングス株式会社で、サービス提供事業者が仲介する立会人型と、当事者同士が電子署名をする当事者型の両方に対応しています。ユーザーごとの閲覧管理や役割権限の設定もできるため、契約書を誰が見られるかを分けたい会社にも向きます。導入実績には民間企業のほか自治体も挙げられています。一方で、機能やオプションが豊富なぶん、すべてを使おうとするとオプションの費用がかさみやすい点には注意が必要です。料金はプランによって異なるため、資料や公式サイトで確認してください。

契約の締結状況をリアルタイムで把握できるようになった点も大きなメリットです。

出典: 日建レンタコム株式会社の導入事例(電子印鑑GMOサイン)

「SaaSの死」とは｜意味・読み方・言葉の発端

SaaSの死とは、生成AIとAIエージェントの進化によって、人が画面を操作して使うことを前提にしたSaaSのビジネスモデルが転換点を迎えている、という議論を指す言葉です。SaaSという提供形態そのものが消えるという意味ではありません。

SaaS(Software as a Service)は、ソフトウェアを自社のサーバーに導入するのではなく、インターネット経由で必要な分だけ利用し、多くの場合は利用人数(ID数)に応じた月額・年額料金を支払う形態です。会計、勤怠、顧客管理、グループウェアなど、企業の業務の多くがこの形で提供されています。SaaSの死の議論は、この「人が使うためのソフトウェアを、人数単位で貸す」という前提が、AIが人に代わって業務を実行するようになると成り立ちにくくなるのではないか、という問題提起です。SaaSの略称やサブスクリプションとの違いを先に確認したい方は、SaaSモデルとは｜略・サブスクとの違いもご覧ください。

読み方と英語表記

「SaaS」は「サース」と読むのが一般的で、「サーズ」と読む人もいます。英語では「SaaS is dead」と表され、日本語では「SaaSの死」「SaaSの終焉」と訳されます。「死」という強い言葉が使われていますが、企業が倒産する、サービスが消えるという意味ではありません。投資家の目から見て、SaaSが成長の鈍化した事業と見なされ、投資対象としての魅力を失いつつある状況を指して使う論者もいます(Authense法律事務所「THE INNOVATORS」の連載より)。このように、同じ言葉でも語る人によって指す中身が違う点に注意が必要です。

誰が言い出したのか、発端とされる2つの出来事

特定の1人が提唱した用語ではなく、2024年ごろからシリコンバレーで議論が始まったと説明されています(ITソリューション塾のブログ)。広く使われるようになったきっかけとして、よく挙げられるのが次の2つです。

1つ目は、2024年12月、MicrosoftのサティアナデラCEOがポッドキャスト「BG2」で、AIエージェントが主流になれば従来のビジネスアプリケーションのあり方が変わるという趣旨の見解を示したことです。ただし、ナデラ氏自身が「SaaS is Dead」と言ったわけではなく、この言葉は発言を受けて広まったものだと解説されています(マイナビニュースTECH+)。

2つ目は、2026年1月30日にAnthropic社が、パソコン上のファイルやアプリを操作して業務を進めるAIエージェント「Claude Cowork」向けに、営業、法務、財務など11種類のプラグインを公開したことです(Anthropic公式ブログ)。その後、米国の株式市場で大手SaaS企業や情報サービス企業の株価が大きく下落したと報じられ、「SaaSの死」という言葉が一般のニュースでも使われるようになりました。

「SaaSの死」が指す3つのこと

ITソリューション塾のブログは、SaaSの死が意味する内容を、次の3つの「死」として整理しています。利用企業の立場では、それぞれが契約・データ・料金の見直しにつながります。

• 画面(GUI)の価値が下がる：AIがAPIなどを通じて裏側でシステムを操作するため、人間用の管理画面の重要度が下がる
• ID課金が成り立ちにくくなる：「1ユーザーあたり月額いくら」という、人がログインすることを前提にした料金の決め方が見直される
• 記録場所から実行する主体への進化が求められる：データを蓄えるだけでなく、仕事を実行する役割まで担うことが期待される

「SaaSの死」をめぐる論点の整理

同じ「SaaSの死」という言葉でも、語る人の立場によって指している中身が違います。混同しないために、論点を立場別に分けておくと理解しやすくなります。

立場	「SaaSの死」で主に語られること	利用企業との関係
投資家・株式市場	SaaS企業の将来の成長性や収益性への評価が下がること	直接の影響は小さいが、ベンダーの経営方針の変化として間接的に表れる
SaaS事業者	ID課金からの脱却、AI機能の組み込み、事業の再編	料金体系や提供機能、サービス継続の判断に影響する
利用企業	業務のやり方がAI中心に変わり、必要なツールの組み合わせが変わること	契約・データ・運用の見直しが必要になる

この記事で扱うのは、表の3行目、利用企業にとっての意味です。株価の動きは議論のきっかけにはなりましたが、利用者として重要なのは、ベンダー側の変化が自社の契約やデータにどう波及するかという点です。「SaaSの死」という主張が本当かどうかを一次情報で検証したい場合は「SaaSの死」は本当か｜AI時代に進化するSaaSの実態を、終焉論に対する反論や判断軸を知りたい場合はSaaS終焉論｜論点・反論・判断軸をご覧ください。

背景｜AIエージェントの台頭と株式市場の反応

SaaSの死が議論される背景には、AIが「質問に答える道具」から「業務を代わりに実行する存在」へと役割を広げつつあることがあります。この変化が、SaaSのどの部分に影響すると考えられているのかを整理します。

AIエージェントが変える「画面を操作する」という前提

AIエージェントとは、与えられた目標に対して、自分で手順を考え、複数のソフトウェアやデータを操作してタスクを進めるAIのことです。たとえば「先月の請求書を取引先別に集計し、未入金の相手に催促メールの下書きを作る」といった指示を受けると、会計ソフトからデータを取り出し、表計算で整理し、メールソフトで下書きを作るところまでを一続きで進めることが想定されています。

これまでのSaaSは、担当者がログインして画面を操作し、データを入力・確認することを前提に設計されてきました。料金も「何人がログインするか」で決まるのが一般的です。AIエージェントが人の代わりに操作するようになると、ログインする人の数が減る、画面の使いやすさよりもデータ連携のしやすさが重視される、といった変化が起こりえます。これが、人数課金を柱としてきたSaaS事業者の収益モデルにとって逆風になると見られている理由です。

市場が反応した理由と、冷静に見るべき点

2026年2月ごろの株価下落は、AIエージェントが実際の業務領域向けの機能を備え始めたことで、それまで「将来の話」とされていた代替の可能性が現実味を帯びたと受け止められたことが大きいと考えられます。一方で、株価はあくまで投資家の将来予想を反映したものであり、利用企業の業務がすぐに変わることを意味するわけではありません。第一ライフ資産運用経済研究所のレポートも、「SaaSの死」という悲観論は一面的な見方にすぎず、企業がAIを使ううえでセキュリティや正確性が壁となるため、安全なデータ管理ができる既存SaaSの価値はむしろ高まりうると指摘しています(第一ライフ資産運用経済研究所のレポート)。

実際、会計や人事労務のように法令対応が必要な業務、取引先や社内の他システムと深く連携している業務では、データの正確性や監査への対応、権限管理といった要件があり、汎用のAIだけで置き換えるのは簡単ではありません。多くのSaaS事業者は自社製品にAI機能を組み込み、「AIが使うためのデータ基盤」として価値を高める方向に動いています。SaaSの死という言葉は、SaaSが不要になるというよりも、SaaSの役割と売り方が変わる過渡期を表していると捉えるのが実態に近いでしょう。

影響を受けやすいSaaSと、価値が残りやすいSaaS

SaaSの死をめぐる議論では、すべてのSaaSが同じように影響を受けるわけではない、という見方が一般的です。Salesforceのブログに登場する有識者のコメントでも、機能を提供するだけのSaaSは淘汰されうる一方、業界特有の知見や業務データを蓄積したデータ基盤を持つSaaSは残るという見方が紹介されています(Salesforceブログ)。利用者の立場から、自社が使っているSaaSがどちらに近いかを考える目安として、よく挙げられる特徴を整理すると次のようになります。

分類	よく挙げられる特徴	利用者が意識したい点
影響を受けやすいとされるSaaS	画面の使いやすさが主な強みで、定型的な入力や転記、簡単な集計が中心。似た機能を持つ製品が多い	AI機能を持つ製品への統合や価格改定、提供終了が起こりやすいため、更新前の見直しを優先する
価値が残りやすいとされるSaaS	会計・人事労務・顧客情報など業務の記録を正確に蓄積する。法令対応や権限管理、監査への対応が求められる	使い続ける前提でも、AI機能の追加料金やデータ連携の条件が変わる可能性があるため、契約条件は確認しておく

この分類は将来を保証するものではなく、同じ製品でもベンダーの方針次第で位置づけは変わります。ただ、点検の優先順位をつけるときの手がかりにはなります。後半で紹介する点検の手順では、影響を受けやすい側に近いSaaSから確認していくと効率的です。

AIツールが「野良ツール化」するリスク

利用者側で見落としやすいのが、社員が個別の判断でAIツールを使い始め、会社が把握できない状態になる「野良ツール化」です。Salesforceのブログでも、この点がSaaSの死をめぐる論点の1つとして挙げられています。部署単位でAI機能つきの新しいサービスを契約したり、無料のAIツールに業務データを入れたりすると、契約情報の一覧から漏れ、更新日も、データの保管先も、規約の内容も確認されないまま残ります。のちほど紹介する点検では、既存のSaaSだけでなく、AI関連のサービスも対象に含めることをおすすめします。

日本企業の状況

日本では、クラウドサービスの利用が企業の間で広く定着しています。総務省の令和8年版情報通信白書によると、AIを活用する方針を持つ日本企業は2025年度調査で68.9%(大企業74.0%、中小企業58.1%)で、前年度の49.7%から増えています。また、独立行政法人情報処理推進機構(IPA)のDX動向2025では、国内企業のDXの取り組み状況や生成AIの活用動向が調査されています。SaaSは多くの企業にとってすでに業務の基盤になっているからこそ、提供する側のビジネスモデルが変わるときには、利用する側にも少なからず影響が及びます。次の章から、その影響を3つのリスクに分けて見ていきます。

利用者が注意すべきリスク1：ベンダーの事業継続性

1つ目のリスクは、契約しているSaaSのベンダーが、事業の縮小や撤退、他社への売却、サービスの統合といった判断をする可能性です。ビジネスモデルの転換期には、収益の柱を見直すなかで、採算の合わない製品の提供終了や、別製品への統合が起こりやすくなります。

起こりうる変化の例

• 提供終了：一定の告知期間を経て、サービスそのものが終了する
• 統合・移行：同じベンダーの別製品やAI版の新製品へ移行するよう案内される
• 買収・事業譲渡：運営会社が変わり、サポート体制や規約が変わる
• 機能の縮小：利用者の少ない機能が廃止され、業務に必要な機能がなくなる

いずれも、ある日突然使えなくなるというよりは、数か月前に告知があるのが一般的です。問題は、その告知を誰が受け取り、誰が判断するのかが社内で決まっていないことです。部署ごとに契約したSaaSでは、告知メールが退職者のアドレスに届いていた、という例も珍しくありません。

事業継続性を見極めるための確認ポイント

ベンダーの将来を完全に予測することはできませんが、次のような点を定期的に確認しておくと、変化の兆しに早めに気づきやすくなります。

確認する観点	見るべき情報	注意したいサイン
製品の更新状況	リリースノート、お知らせページ	機能追加の告知が長期間止まっている
ベンダーの方針	プレスリリース、決算説明資料(上場企業の場合)	新製品への注力を強調し、既存製品への言及が減っている
サポートの質	問い合わせへの回答速度、窓口の変更	回答が遅くなる、窓口が縮小される
規約の改定	利用規約・サービスレベルの改定履歴	サービス終了や提供条件変更に関する条項が改定される

なお、ここで挙げたサインは、あくまで「確認を始めるきっかけ」にすぎません。ひとつ当てはまったからといって、そのサービスがすぐに終わるわけではない点には注意が必要です。重要なのは、変化に気づいたときに、代替手段の検討やデータの退避に取りかかれる体制を持っておくことです。

利用者が注意すべきリスク2：データ移行の困難さ(ベンダーロックイン)

2つ目のリスクは、特定のSaaSにデータや業務の進め方が深く依存し、他のサービスへ移りたくても移れない状態、いわゆるベンダーロックインです。SaaSの死のように市場が大きく動く時期には、乗り換えを検討する場面が増えるため、このリスクが表に出やすくなります。

ロックインが起こる3つの原因

ロックインは、単に「データを出力できない」ことだけが原因ではありません。実務では、次の3つが重なって移行を難しくしているケースが多く見られます。

• データの形式：出力はできても独自形式で、他システムに取り込むには加工が必要になる。添付ファイルや履歴、コメントが出力対象外になっていることもある
• 連携の作り込み：他のシステムとの連携や自動化をそのSaaS専用の仕組みで作っており、乗り換えると作り直しになる
• 業務の慣れ：画面や手順に合わせて社内ルールやマニュアルが作られていて、移行すると教育のやり直しが必要になる

AIエージェントの時代になると、AIが社内のデータを横断して扱えるかどうかが業務効率を大きく左右します。そのため、データを標準的な形式で取り出せること、外部とつなぐための仕組み(API)が公開されていることの価値は、これまで以上に高まると考えられます。

今のうちにやっておきたい備え

移行が必要になってから慌てないために、平時から次のような準備をしておくと安心です。まず、重要なSaaSについて、どのデータをどの形式でエクスポートできるかを一度実際に試し、手順を記録しておきます。次に、解約後にデータがどのくらいの期間保持されるか、返還や削除の手続きがどう定められているかを契約書や利用規約で確認します。さらに、SaaS間の連携を作る際には、特定製品だけに依存する作り方を避け、どこに何のデータがあるかを一覧にしておくことが役立ちます。

データの取り扱いは、セキュリティや個人情報保護の観点からも重要です。SaaS利用時に利用者側が負う責任の範囲についてはSaaSのセキュリティ｜利用者の責任範囲で詳しく解説しています。中小企業向けの基本的な対策は、IPAの中小企業の情報セキュリティ対策ガイドラインも参考になります。

利用者が注意すべきリスク3：契約形態・価格モデルの変化

3つ目のリスクは、利用者にとって最も身近で、影響が表れやすいものです。SaaS事業者がID課金中心の収益モデルを見直すなかで、料金の決め方や契約の条件が変わる可能性があります。

考えられる価格モデルの変化

料金の考え方	仕組み	利用者が気をつけたい点
ID課金(従来型)	利用人数に応じて月額・年額が決まる	使っていないIDの費用が積み上がりやすい
従量課金	処理件数やAIの利用量に応じて料金が変動する	月ごとの費用が読みにくく、予算管理が難しくなる
成果報酬型	AIが完了させたタスクの数や成果に応じて課金する	「成果」の定義が契約上あいまいだと、請求額をめぐって認識がずれる
AI機能の追加料金	基本料金とは別に、AI機能をオプションとして課金する	必要な機能が上位プランやオプションに移され、実質的な値上げになる

どの形が一概に良い、悪いというものではありません。ただし、料金体系が変わるタイミングでは、プランの再編や旧プランの提供終了がセットで行われることが多く、気づかないうちに更新後の費用が上がっていた、ということが起こりえます。大手SaaSでも、人数課金から利用量に応じた課金への移行が進められていると解説されています(ITソリューション塾のブログ)。

契約書で確認しておきたい条項

価格や条件の変化に備えるには、契約書や利用規約のどこに何が書かれているかを把握しておくことが欠かせません。SaaSの契約では、特に次の条項を確認しておくと、変化が起きたときの選択肢を確保しやすくなります。

条項	確認するポイント
契約期間・自動更新	更新日と、解約の申し出が必要な期限(何日前までか)
料金・価格改定	ベンダーが料金を変更できる条件と、事前通知の期間
規約の変更	規約を一方的に変更できる定めがあるか、変更時の通知方法
サービスの終了・変更	提供終了時の告知期間、返金や移行支援の有無
データの返還・削除	解約後のデータ保持期間、返還の形式、削除の証明
AI・データの利用	自社データがAIの学習などに使われるか、その可否を選べるか

契約内容の解釈や、条項の有効性の判断は、個別の契約や事情によって異なります。本記事は一般的な情報提供を目的としたものであり、法的助言ではありません。具体的な判断が必要な場合は、弁護士などの専門家に相談してください。

契約の点検を仕組みにする

上の表の条項を、契約しているSaaSごとに一度確認するだけでも効果はありますが、SaaSの数が増えるほど、更新日や通知期限を人の記憶や表計算ファイルだけで追い続けるのは難しくなります。担当者の異動があれば、どこに何の契約書があるのか分からなくなることもあります。契約書管理の仕組みを使えば、SaaSの利用契約や申込書、規約の控えを1か所に集め、更新日の前にアラートを受け取る運用がしやすくなります。価格改定や規約変更の通知が届いたときも、元の契約条件とすぐに照らし合わせられるため、「更新するか、別のサービスに移るか」を期限に追われずに判断できます。

紙やPDFの契約書も含めて契約情報をデータ化し、期限を見逃さない運用にしたい場合の一例がContract Oneです。運営会社はSansan株式会社で、紙・PDF・電子契約といった形態の契約書を、AI-OCRと専門スタッフの確認によって主要項目までデータ化して一元管理します。契約期限が近づいたときのアラート通知や、契約の自動更新設定にも対応していると商品ページに記載されています。導入時に業務フローの見直しが必要になる場合があるため、運用の進め方まで資料で確認すると安心です。料金はプランによって異なるため、資料や公式サイトで確認してください。

今回Contract Oneを導入し契約書を一元的に管理することで、必要な契約書を迅速に確認できるようになったほか、属人的な管理に伴うリスクを抑え、期日管理の精度向上にもつながっています。

出典: イオンマーケティング株式会社の導入事例(Sansan プレスリリース)

契約書の作成から承認、締結、保存、管理までを1つのサービスで進めたい場合の一例が、マネーフォワード クラウド契約です。運営会社は株式会社マネーフォワードで、紙の契約書と電子契約書をまとめて一元管理でき、他社の電子契約サービスで締結した契約書も締結後に取り込める機能があります。契約書の送信や保管で件数に応じた追加課金が発生しない料金体系である点が特徴として挙げられていますが、詳細は資料で確認が必要です。注意点としては、印影の表現にもう少し工夫があるとよい、という指摘が商品ページに挙がっています。

営業活動においては見積書を出して、その後に注文書、そして最後に請求書と複数の書類が存在するため、それらをクラウド上で一元管理できるのは、非常に便利だなと感じています。

出典: 株式会社ワンオールシステムの導入事例(マネーフォワード クラウド契約)

5サービスの役割を比較表で見る

自社のSaaSを点検する4つのステップ

自社のSaaSを点検するには、契約の一覧を作り、重要度を分け、3つのリスクを確認し、見直しの時期を決めるという4つのステップで進めます。大がかりなプロジェクトにする必要はなく、年に1回、契約更新の時期に合わせて見直すだけでも十分な備えになります。

1. 契約の一覧を作る：部署ごとに契約しているものも含め、SaaS名、契約部署、担当者、利用人数、費用、更新日を1つの表にまとめます。AI関連のサービスも忘れずに加えます。
2. 重要度を分ける：止まると業務が回らないもの、代替がききやすいものに分け、点検の優先順位をつけます。
3. 3つのリスクを確認する：重要度の高いものから、ベンダーの更新状況、データのエクスポート方法、契約条項(自動更新・価格改定・データ返還)を確認します。
4. 見直しの時期を決める：更新日の数か月前に見直す運用ルールを決め、通知を受け取る担当者を明確にします。

点検の結果、使われていないIDが多いSaaSや、同じ機能を複数の部署が別々に契約しているSaaSが見つかることもあります。SaaSの死の議論をきっかけに契約を棚卸しすることは、将来のリスクへの備えであると同時に、今のコストを見直す機会にもなります。

台帳づくりの手間を減らす選択肢

ステップ1の一覧づくりは、最初の1回よりも、更新し続けることのほうが負担になりがちです。契約書を台帳として管理するサービスは、その負担を減らす手段になります。すでにfreeeの会計などの製品を使っている会社なら、契約書の作成、締結、管理をワークフローでそろえたい場合の一例がfreeeサインです。運営会社はfreeeサイン株式会社で、30種類以上の契約書フォーマットを用意し、freeeの他の製品との互換性が高いと商品ページに記載されています。画面がシンプルなぶん、機能の場所が分かりにくいと感じる場合がある点は事前に確認しておきたいところです。

契約書の情報を自動で台帳にしたい場合の一例が、SMBCクラウドサインです。運営会社はSMBCクラウドサイン株式会社で、「AI契約書管理」により契約金額や契約期間などを自動で読み取って登録できると商品ページに記載されています。メガバンクのセキュリティ基準でモニタリングされている点も特徴とされています。一方で、フォルダ管理の自由度が低い点は、導入前に自社の運用に合うか確認しておく必要があります。

発注ルールの整備とクラウドサインの導入により一元管理を実現。案件の適正化、効率化に貢献。

出典: 山一建設の導入事例(SMBCクラウドサイン)

よくある質問(FAQ)

Q1. 「SaaSの死」とはどういう意味ですか？

A. 生成AIとAIエージェントの進化によって、人が画面を操作することを前提にしたSaaSのビジネスモデルが転換点を迎えている、という議論を指す言葉です。SaaSという提供形態がなくなるという意味ではありません。

Q2. 「SaaSの死」は誰が言い出したのですか？

A. 特定の1人が提唱した言葉ではありません。2024年12月にMicrosoftのサティア・ナデラCEOがAIエージェント時代のビジネスアプリケーションの変化について語った発言が、「SaaS is Dead」として広まったと解説されています。2026年1月にAnthropic社がAIエージェント向けの業務プラグインを公開し、その後に米国でSaaS関連企業の株価が大きく下落したと報じられたことで、一般のニュースでも使われるようになりました。

Q3. 「SaaSの死」の読み方と英語表記を教えてください。

A. 「SaaS」は「サース」と読むのが一般的で、「サーズ」と読む人もいます。英語では「SaaS is dead」と表し、日本語では「SaaSの死」「SaaSの終焉」と訳されます。

Q4. 今使っているSaaSはすぐに解約したほうがよいですか？

A. 議論を理由に慌てて解約する必要はありません。まずは契約の一覧を作り、ベンダーの事業継続性、データ移行のしやすさ、契約と価格の条件を確認したうえで、更新時期に合わせて判断するのが現実的です。

Q5. 利用者が注意すべきリスクは何ですか？

A. ベンダーの事業継続性、データ移行の困難さ(ベンダーロックイン)、契約形態・価格モデルの変化の3つです。価格モデルでは、ID課金に加えて従量課金や成果報酬型、AI機能の追加料金といった形が広がる可能性があります。いずれも、平時から契約とデータの状況を把握しておくことで備えられます。

Q6. SaaSの契約書は何を確認し、どう管理すればよいですか？

A. 契約期間と自動更新、価格改定、規約変更、サービス終了時の扱い、データの返還・削除、AIによるデータ利用の各条項を確認します。契約数が多い場合は、契約書管理に対応したシステムで1か所に集め、更新日のアラートを受け取る運用が有効です。

まとめ｜SaaSの死は「契約とデータを見直すきっかけ」

SaaSの死は、SaaSが消えるという話ではなく、AIエージェントの台頭によってSaaSの役割と料金の決め方が変わりつつあることを表す言葉です。利用者として押さえておきたいのは、次の4点です。

1. 言葉の意味を正しく理解する：株価の議論と、利用企業への影響を分けて考える
2. ベンダーの変化とデータの出口を確認する：更新状況や告知を受け取る担当者を決め、エクスポートの形式と解約後の保持期間を確かめる
3. 契約条件を一元管理する：自動更新・価格改定・データ返還の条項を一覧にし、更新前に見直す
4. 契約書の管理を仕組みにすることを検討する：契約書の一元管理や更新日の通知ができるシステムの資料を取り寄せ、自社に合うかを確かめる

議論の行方を見守りつつ、自社の契約とデータを点検しておくことが、変化の時代にSaaSを安心して使い続けるための現実的な備えになります。

参考文献

• 総務省「令和8年版 情報通信白書」 https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r08/html/nd121110.html
• 独立行政法人情報処理推進機構「DX動向2025」 https://www.ipa.go.jp/digital/chousa/dx-trend/dx-trend-2025.html
• 独立行政法人情報処理推進機構「中小企業の情報セキュリティ対策ガイドライン」 https://www.ipa.go.jp/security/guide/sme/about.html
• Anthropic「Cowork plugins」 https://claude.com/blog/cowork-plugins
• マイナビニュース TECH+「AIエージェント時代にSaaSは本当に終わるのか？再燃する「SaaS is Dead」論」 https://news.mynavi.jp/techplus/article/20260304-4180669/
• 第一ライフ資産運用経済研究所「AIエージェントはSaaS企業の敵か味方か」 https://www.dlri.co.jp/report/asset/623568.html
• Salesforceブログ「「Saas is Dead」、有識者はどうみているか」 https://www.salesforce.com/jp/blog/jp-expert-perspectives-on-saas-is-dead/
• Authense法律事務所「THE INNOVATORS」「SaaSの死」が叫ばれる根本的な原因と企業が取りうる打ち手とは？ https://www.authense.jp/innovators/7752/
• ITソリューション塾「【図解】コレ1枚でわかる「SaaSの死」」 https://blogs.itmedia.co.jp/itsolutionjuku/2026/02/saasai.html