こんにちは。わいけいです。
個人でSaaSを開発・運営しています。
最近「SaaS is Dead」という言葉をよく目にするようになりましたが、正直なところ 運営者の立場からしても「わかる」と言わざるを得ない 状況になってきました。
今回は零細SaaS運営者のリアルな肌感覚から、SaaS is Dead論の実態、今後の予測、そして生き残るために自分が実際にやりはじめたことについて書きます。
そもそも「SaaS is Dead」論とは
そもそも「SaaS is Dead」論とは何かを最初に振り返っておきましょう。
「SaaS is Dead」論とはClaude CodeのようなAIエージェントの急速な普及により、SaaSの存在意義そのものが揺らいでいるという議論です。
主に2つの側面があります。
1. 「作れちゃう」問題
個人利用レベルの使い捨てツールや簡単な社内ツールであれば、Claude Codeに頼めば数分でサクッと作ってくれます。
もはや何種類ものSaaSを使いこなす必要はなく、普段から使い慣れたAIに雑に日本語で命じるだけで事足りる。
生半可なサービスは根本的な存在意義を失ったといえます。
2. 「ユーザーが減る」問題
ユーザー数課金型のSaaSでは、AI活用によって人間側の必要作業員が減少するため、顧客企業あたりの契約シート数が減ります。
追加機能への課金も、AIが代替してしまえば不要になります。
つまり 仮に顧客が解約しなくても売上が落ちる という構造的なミスマッチが発生します。
自分が「SaaS is Dead」を実感している理由
SaaS is Dead論には肯定・否定を含めて様々な意見があります。
しかし、法人個人を問わずSaaS運営者であれば、少なからず「自分も駆逐されるのでは？」という不安を抱いているケースが多いのではないでしょうか。
自分の場合について少し語ります。
私はMydayAIという零細日記サービスを運営しています。
Web上で日記が書けるシンプルなサービスで、毎日書かれる日記は30〜40件ほどです。
自分で作ったサービスなのでアレなのですがAI時代の水準で考えると、控えめに言って 使うのがめんどい 。
そもそも日記というのは「続けること」自体が最大のハードルです。わざわざブラウザを開いて、画面をポチポチ操作して、テキストを入力して……。
AIエージェントに何かを依頼する体験と比較するとめんどくさいと言わざるを得ないです。
一方で、日々AIエージェントを使っていると、小難しい操作手順など考えずとも雑にお願いすれば大体柔軟にやってくれます。
その体験と比べると、自分のSaaSがどうにも陳腐でイケてないものに感じてしまう。 自分で作ったサービスに自分で萎えている わけです。
そもそも、個人の日記帳レベルであれば、それぞれのユーザーがAIエージェントに作らせることが可能です。
Claude CodeやらCodexやらに日記記入用のUIを作成させ、
日記データ自体はテキストファイルとしてローカルに蓄積させても一応は実現可能です。
ユーザーはわざわざこうしたSaaSを使う必要があるのだろうか？と最近疑問に感じるようにもなっていました。
もちろんMydayAIは日記という比較的シンプルなサービスなので、AIに置換されやすい部類ではあります。しかし、もっと複雑で大規模なSaaS——例えばCRMやプロジェクト管理ツールなど——であっても、AIがデータ入力を自動化したり、レポートを自律生成したりするようになれば、「人間がUIをポチポチ操作する」部分の価値は確実に薄れていきます。規模の大小を問わず、SaaS事業者が感じている不安の根っこは同じでしょう。
多くのSaaS事業者は細かいチャーンレート（解約率）を血眼で追っていますが、
一方で心の奥底に感じている「このサービス、根本的にAIで置換可能じゃね？」という疑問には正面から向き合えずにいることが多いのではないでしょうか。
今後AIがさらに進化・普及するとどうなるか
このままAIが進化・普及し続けると、実際どうなるのか個人的な予想を書いてみます。
結論、多くのSaaSは事実上「AIのプラグイン」へと変化することを余儀なくされるのではないかと思います。
これに伴い、ユーザー側、SaaS提供側ともに大きな変化があると考えています。
以下、この考えに至った経緯から順を追って説明します。
最近、複数の仕事の関係先から「今後は人間ではなくAIが自律的に作業を進行できるようなSaaSを構築していきたい」という意見を聞く機会がありました。
イメージとしてはこういうことです。
例えば勤怠管理ツールであれば、従来は人間が毎日タイムカードを押す必要がありました。
これがAI時代には、PCの起動ログなどからAIが自律的に出勤を検知し、「この時間で打刻しておきました。修正が必要な場合は指摘してください」とSlackで通知してくれる——そんなUXへの移行です。
人間が能動的にSaaSを操作するのではなく、AIがSaaSを操作して人間に確認を求める 、という構造的な変化が起きるわけです。
そもそも以前から、各種業務ツールを使いこなすのは人間にとっては面倒なものでした。
が、SaaS事業者側は（しばしば自分たち自身にも嘘をついて）「弊社のツールは使いやすい!」とアピールすることに注力し、
クライアント企業内の担当者を抱き込んだりして、無理やりに社内に自社SaaSを浸透させる努力をしてきました。
しかし、今やSaaS事業者内の議論としても「SaaSを使うのは人間にとって負担」という事実が自由に主張できる空気感に変化してきているわけです。
この変化は個人的に意義深いと感じています。
そして、「AIが自律的に作業を進められるようなSaaSを作ろう」という考えの事業者が増えていくと、将来的にどのような世界が実現するでしょうか。
自分は、
「ユーザーが個別にAIにツールを作らせる」世界ではなく、「ユーザーが手元のAIに既存のSaaSを操作するよう命じる」 世界が実現するのではないかと予想しています。
そもそも、AIがどれだけ強力になっても、何でもかんでもゼロから作らせるのは合理的ではありません。
冒頭では「AIで使い捨てツールを簡単に作れるようになった」と言いましたが、
逆に使い捨てツール以外のものをAIで作成して実際に使い続けるのはそれなりに難しいです。
AIの開発能力の話とはまた別の論点として、例えば次のような点を考慮しなければならないからです。
- セキュリティが重要なサービスを非エンジニアとAIだけで作るのはリスクが高い
- 永続化が必要なデータをローカルPCに溜め込むのは不便（端末間の同期、PC買い替え時の移行……）
- 少数の事業者が大規模なサーバーを稼働させて大量のユーザーがそれを共有したほうが量産効果でコスト的に全体最適になる
こういった事情を考慮すると、「だれでもAIで何でも作れる！」という主張は少し無理があると思われます。
こういった事情を背景に、自分としては今後のSaaSの姿として、こんなモデルがありえるのではないかと考えています。
- SaaS事業者 はDBを準備し、AIが操作可能なAPIを公開する
- ユーザー は手元のAIエージェント、あるいはChatGPTのような大手AIサービスから、そのAPIを通じてSaaSを操作する
この構図はすべてのステークホルダーにメリットがあります。
| ステークホルダー | メリット |
|---|---|
| SaaS事業者 | UI開発コストを大幅に削減できる |
| AIプロバイダー | 自社AIにSaaSの機能が追加され、エコシステムが強化される |
| ユーザー | SaaSの操作手順を覚える必要がなく、AIに頼むだけで完了する |
AIはもはやSaaSのUIではなく、ネットにおけるブラウザのような基盤的存在になる と言えるかもしれません。
これまでSaaS事業者は「ユーザーがブラウザを持っている」ことを前提にサービスを開発してきました。「サービスを作ろう！」と思い立ったときに「アクセス用のブラウザも一緒に開発しよう」と考える人はいません。
これと同じで、強力なLLMはOpenAI・Google・Anthropicといったプロバイダーが作ってくれる前提で、それらのAIから使いやすいサービスを作っていく——これが今後の1つの潮流になると予想しています。
そうなると基盤LLMプロバイダーは大多数のSaaSへの入口を握ることになり、そのパワーは絶大です。
現在SaaSと呼ばれているサービス群は、いつの間にか単なる AIのプラグイン へと姿を変えるかもしれません。
ただ、これをSaaS提供側にとってのディストピアとは捉えていません。逆に言えばSaaS事業者は基盤モデル開発の莫大なコストを肩代わりしてもらっているとも見ることができます。一方的な搾取というよりは、一定の権力勾配の上に成り立つ共生関係でしょう。
この構造はクラウドと非常に似ています。AWS・GCP・Azureも、IT業界の基盤であり構築に要する資本・技術が桁外れであることから米国の数社が市場を寡占していますが、利用料金は年々下がっています。複数のビッグテックが競争する限り、ディストピア的な状況にはなりにくいと考えています。
SaaS is Deadで駆逐されないために今できること
この状況を踏まえて、SaaS事業者が今すぐ取り組めることは大きく2つあると考えています。
1. AIフレンドリーな体制に移行する
最も直接的なアクションは、AIから操作しやすい窓口を追加する ことです。
具体的な手段はいくつかあります。
- サービス専用のCLIを開発・公開する
- MCPサーバーを開発・公開する
- 外部公開のREST APIなどを整備してAIエージェントから叩きやすくする
2. 課金モデルを見直す
ユーザー数課金のままでは、AIによるオペレーション効率化が進むほど売上が縮小します。API呼び出し回数課金、データ保存量課金、成果連動型課金など、AIエージェント時代にフィットする課金体系への移行を検討すべきでしょう。
実際にMCPサーバーを追加してみた
自分の場合はまず手を動かしてみようと思い、MydayAIにMCPサーバーとしての機能を付与しました。
これにより、ユーザーは例えば以下のことが可能になります。
- AIエージェントに日記を代筆させる (面倒な入力作業からの解放)
- AIエージェントに過去の日記を参照させる (自分の記録をコンテキストとして活用し、普段のAIとの会話の質を上げる)
実際、自分自身が日記をつけるのが面倒になってきていたので、毎日24時にカレンダーやメールの履歴を参照させて自動で日記を書かせる、という使い方も試してみたいと思っています。
Claude Codeで定期実行の設定もしやすくなっているので、すぐに実現できる話です。
もちろん、MydayAIは別にエンジニア向けサービスではないので、日常的にAIエージェントを使っているユーザーが少ないため、MCP連携が当面爆発的に利用されることはないでしょう。
ただ、Claude Codeが非エンジニアにも急速に広まっている流れを踏まえ、今のうちから仕込んでおきたい という判断です。
AIエージェント経由でSaaSを操作する人がどのくらい増えるのか、それを見守っていきたいという思いです。
MCPサーバー化はそんなに難しくない
技術的には、MCPサーバーの公開は既存のAPI開発とそこまで大きく変わりません。
汎用的なMCPサーバー構築用のフレームワークやライブラリも出てきており、MCPサーバー向けのOAuth認証を追加すれば、多くのサービスがすぐに対応できるはずです。
「SaaS is Dead」と嘆く前に、まずはAIエージェントとの接点を1つ作ってみる。
それだけでも見える景色がだいぶ変わると思います。
最後に
「SaaS is Dead」は単なる煽りではなく、AIの進化によってSaaSの存在意義やビジネスモデルが構造的に変化しつつあるという現実を反映しています。
ただし、それは「SaaSが消滅する」ということを必ずしも意味するとは限りません。
サービスにAIフレンドリーな接点を用意し、課金モデルを時代に合わせて見直すことで、むしろAIエコシステムの一部として新たな価値を発揮できる可能性があります。
冒頭で「SaaS is Deadを実感している」と書きましたが、正確に言えば、時代の潮流の変化に対応できない一部のSaaSが駆逐される一方で、多くのSaaSは形を変えて生き残るだろうと考えています。これはクラウド化の波、モバイルシフトなど、過去にも何度も起きてきた時代の変化と本質的には同じです。
月並みな結論ではありますが、「SaaS is Dead」ではなく「SaaSは進化する」 と捉えるのが建設的なアプローチだと思います。
自分もMCPサーバーの追加という小さな一歩から始めてみました。MCP対応はまだ出したばかりで、正直なところ目に見える変化はこれからです。
今後、実際にAIエージェント経由の利用がどのくらい増えるのか、ユーザーの使い方にどんな変化が出るのかなど、知見が得られればXなどで発信していきたいと思います。
自分は普段、Web開発やAIエージェント活用についての発信をX（旧Twitter）でしています。
よければフォローしてください。