「SaaSの死」とは何か ～生成AI時代の内製化とノーコード・ローコードの位置づけ～

「SaaSの死」とは何か ～生成AI時代の内製化とノーコード・ローコードの位置づけ～

本記事で解決できるお悩み

• 生成AIが進化する中で、どのようにIT戦略を考えればよいかわからない
• 生成AIを用いてアプリケーションを内製化してみたいが、本当に可能かわからない
• 現在ノーコード／ローコードを用いた「市民開発」を行っているが、生成AIが進化してもなお必要なのかわからない

はじめに：SaaSは死んだのか？

最近よく投資家の間では「SaaSの死」という言葉がささやかれています。これは何も、「SaaSが消滅する」という意味ではありません。また、IT企業に投資する投資家にだけ関係のある話というわけでもありません。SaaSを作っている企業の将来性に疑問が呈されているということは、裏を返せば、企業がSaaSを使う必要性が揺らいでいることを意味するためです。より正確に言えば、SaaSを「買うこと」が最適解だった前提が揺らぎ、「必要な機能なら作る」という選択肢が現実的になってきたということです。

生成AIによって、ソフトウェア開発のコストが劇的に下がり、企業が「この機能なら自社で作れる」と判断するケースが増えています。そしてこの変化は、SaaSベンダーだけでなく、SaaSを使う側であった、企業の情報システム部門・DX推進部門にも影響します。

本記事では、

• 「SaaSの死」とは何か
• なぜ内製化が加速するのか
• 生成AI時代の“現実的な内製化”の進め方

を整理して解説します。

0. そもそもSaaSとは？

「SaaS（サース）」とは、Software as a Service の略で、ソフトウェアを「買い切り」ではなく、「サービスとして利用する」形態を指します。

たとえば昔は、ソフトウェアといえばCD-ROMを購入してPCにインストールするのが一般的でした。企業向けの場合には、パッケージ製品を導入し、自社のサーバに構築して運用していました。こうした形は、今風に言えば「オンプレミス型」と呼ばれます。

これに対し、SaaSは、ソフトウェアを自社で保有せず、インターネット経由で利用します。ユーザーはログインして使い、料金は月額課金が基本です。

身近な例でいえば、

• Microsoft 365（Officeのクラウド版）
• Google Workspace（GmailやGoogleドキュメント）
• Salesforce（営業支援）
• Slack / Teams（コミュニケーション）
• Adobe Creative Cloud（画像処理）

などが代表的なSaaSです。

SaaSが普及した最大の理由は、企業にとっての「導入のハードル」を大きく下げたことにあります。サーバを用意しなくてよい。アップデートもベンダー側がやってくれる。初期費用も比較的小さい。結果として、ITに強い大企業だけでなく、中堅・中小企業でも高度なソフトウェアを使えるようになりました。

一方でSaaSには、「業務がSaaSに寄っていく」という側面もあります。SaaSは多くの企業に共通する業務を前提に作られているため、導入が進むほど、現場側が「業務の方をSaaSに合わせる」ことが増えていきます。例外業務はExcelで補う。追加要望は「それは仕様です」で終わる。こうした状況に心当たりのある方も多いのではないでしょうか。

もちろん、SaaSには「こういう手順で業務を回せばうまくいく」という設計思想が埋め込まれているものも多く、それに合わせること自体が悪いとは限りません。

ただ、現場では、例外業務が増えるほど「結局、Excelで補うしかない」という状況にもなりがちです。この「SaaSに業務を合わせることへの違和感」が、生成AI時代の内製化の議論と直結してきます。

1. 「SaaSの死」の正体：何が壊れたのか

「SaaSの死」とは、SaaSが消えるという意味ではありません。

ここ数年、生成AIが自然言語を用いたコーディングを可能にしたことによって、ソフトウェアが以前より簡単に作れるようになりました。その結果、「便利な機能」や「使いやすさ」だけでは、SaaSの価格は正当化しにくくなってきました。

これまでSaaSは、機能やUIの差で選ばれてきました。しかし今、企業がより強く問うようになっているのは「そのツールが業務の成果に直結するか」「運用まで含めて定着するか」という点です。言い換えるなら、SaaSは便利な道具であるだけでは評価されにくくなり、ソフトウェアの価値は「機能」から「業務成果」へと重心が移り始めています。便利であることと、成果に直結することは同義ではないという当たり前の事実が、改めて可視化されつつあります。ここに「SaaSの死」と呼ばれる現象の核心があります。

1-1. SaaSが強かった理由

そもそもSaaSは、非常に強いビジネスモデルでした。

その強さは、ソフトウェアという商品の性質をうまく利用した点にあります。

ソフトウェアは、一度作ってしまえば同じものを何度でも提供できます。追加でかかるコストはほとんどなく、売れれば売れるほど利益率が上がる。これは物理的な商品にはない圧倒的な強みです。つまり、限界費用が小さいことがこのビジネスモデルの1つ目の魅力でした。

そしてこの性質は、ベンダー側だけでなく利用者側にとっても大きなメリットでした。従来のように高額な初期費用をかけてシステムを導入しなくても、月額課金で小さく試すことができる。必要に応じてユーザー数を増減できる。さらにアップデートや保守もベンダー側が担ってくれる。こうしてSaaSは、「導入コストの低さ」と「始めやすさ」を武器に、急速に企業へ普及していきました。

さらに、SaaSはサブスクリプション型です。顧客が一度導入すれば、毎月一定の料金が積み上がっていきます。売上が積み上がる（ストック型）ため、事業計画を立てやすいという点がベンダー側にとっての第2の魅力でした。

毎月一定の料金という性質もまた、ベンダー側だけでなく利用者側にとってメリットをもたらしていました。利用者側もシステムを一から開発するよりもSaaSを利用するほうが、IT予算の見通しを持ちやすく、SaaSが普及した理由の一つとなりました。

ベンダー側にとっての第3の魅力は、乗り換えの面倒さです。これはユーザーにとっては悩ましい問題でもあります。

業務システムは単なる道具ではありません。データが溜まり、運用が定着し、現場の手順がそのツールに合わせて変わっていきます。そうなると、別のツールに移るだけでも大仕事になります。この「乗り換えコストの高さ」が、SaaSにとっては強烈な追い風でした。業界用語では「ロックイン」と呼びますが、顧客は簡単には解約できず、結果としてSaaSは長く使われる前提で成立します。

この3つの要素がかみ合った結果、SaaSは、作ったあとに強くなるビジネスモデルとして成立し続けてきました。

1-2. 生成AIが壊したSaaS企業の3つの前提

生成AIが普及すると、大きく3つの原因からSaaS企業の経営モデルの前提が崩れます。

第一に、機能差がすぐに消えるということです。AIで開発スピードが高速化したため、似たような機能が短期間で模倣されやすくなりました。こうなると、他社に先駆けて新しいサービスや機能を開発した企業が先行者優位を持つ期間は短くなります。

第二に、乗り換えコストが下がってしまったということです。生成AIの進化によって、データ移行や業務手順の整理も容易になりました。囲い込みが困難になったという意味においても、SaaS業界において先行者利益が持つ意味は小さくなりました。他方で、このことは、ユーザー企業にとってはより安価でより高機能なツールを使いやすくなったことを意味します。

第三に、機能差がすぐに消えるようになり、乗り換えコストも低下したことで、「その機能に月額を払う意味」が従来に比べてよりシビアに問われるようになりました。SaaS業界においてもコモディティ化が起きたということであり、同時に、従来のユーザーが「内製する」というオプションも選べるようになったということでもあります。

2. 内製化は本当に進むのか？

以上で述べたように、コード生成技術の進展が少なくとも技術という面においては内製化の障壁を急激に下げたことは事実でしょう。しかし、本当に事はそううまく運ぶのでしょうか？本当にこれまでの内製化の壁は「技術」だったのでしょうか？

実は、同じような期待はこれまでにも何度も語られてきました。プログラミングは常に「高レベル化」してきました。機械語やアセンブリから始まり、C言語やJavaといった高級言語へと進み、さらにフレームワークやライブラリが整備され、記述すべきコード量は劇的に減ってきました。かつては専門家しか扱えなかった処理が、より抽象化された形で再利用可能になり、開発効率は着実に向上してきました。

それでも、多くの企業が基幹システムを本格的に内製化する流れにはなりませんでした。

1990年代以降には、EUC（End-User Computing）が注目を浴びました。現場部門が自らExcelやAccessを用いて業務アプリケーションを作成する動きです。そして、2010年代末からはRPAやノーコード／ローコードツールが注目され始めています。芸能人がアプリケーションを作っているCMもあるように、「専門知識がなくても業務アプリを作れる」というメッセージが繰り返し発信されてきました。

確かに、これらの技術は一定の成果を上げました。しかし同時に、属人化やブラックボックス化、ガバナンスの不在といった問題も生みました。また、現場主導のツールが乱立し、全体最適が見えなくなり、IT部門が後から整理に追われるという構図も珍しくありませんでした。

つまり、技術のハードルはこれまでも何度も下がってきたのです。それでも内製化が全面的に進まなかったのは、別の要因があったからではないでしょうか。多くの場合、真のボトルネックは「コードを書く能力」ではありませんでした。「業務が整理できない」、「要件定義ができない」、「仕様が固まらない」、「担当者が忙しく、改善に時間を割けない」といった声を、私自身何度も耳にしています。

何を作るのかが定まらなければ、どれだけ高度なツールがあっても形にはなりません。失敗を許容する文化がなければ、現場は挑戦しません。担当者が日常業務に追われていれば、改善の時間も確保できません。

生成AIは、こうした構造を一気に変える魔法の道具ではありません。ただし、「作ること」そのものに対する心理的・技術的ハードルをさらに下げたことは確かです。次に問われるのは、組織が自らの在り方をどのように選択するかです。つまりこれは、ガバナンスの問題です。語源をたどれば、古代ギリシャ語のkybernân（舵を取る、操舵する）に行き着きます。企業が自ら舵を取るのか、それともツールに委ねるのか。その選択が問われているのです。

2-1. それでも内製化は自動的には進まない

ここまで述べてきたように、これまでの内製化の壁は必ずしもプログラミング技術ではありませんでした。むしろ問題は、業務整理や要件定義、組織の意思決定といった部分にありました。

その意味では、生成AIが登場したからといって、企業の内製化が自動的に進むわけではありません。業務が整理されていなければ、AIに何を作らせるのかも決まりません。責任の所在が曖昧であれば、誰も運用を引き受けません。

こうした問題は、依然として企業の中に残っています。

ただし、生成AIが変えたものが一つあります。それはソフトウェア開発のコスト構造です。これまでシステム開発は、多くの専門人材と長い開発期間を必要としました。そのため企業は「自社で作る」よりも「SaaSを購入する」方が合理的なケースが多かったのです。しかし生成AIによって、試作や小規模なアプリケーションの開発コストは大きく下がりました。以前であれば数ヶ月かかったものが、数日で形になることも珍しくありません。

この変化は、企業に新しい選択肢を生みます。

これからは、「全部SaaS」か「全部内製」かというゼロイチではなく、どこまで自社開発し、どこからSaaSに頼るかの線引きが、よりシビアに問われる時代です。

3. ノーコード・ローコードは生き残るのか？

ここで気になるのが、ノーコード・ローコードの存在です。生成AIがコードを書けるのであれば、これらのツールは不要になるのでしょうか？

結論から言えば、実際には、その逆です。生成AIは、ノーコード・ローコードの強みを補完するツールです。

これまでも、ノーコード・ローコードツールを使えば「誰でもアプリを作れる」と言われてきました。しかし実際には、ツールの操作方法を覚える必要があり、必ずしも現場の担当者がすぐに使えるわけではありませんでした。

生成AIはここを補います。例えば、市民開発者が業務内容を文章で説明すると、生成AIがアプリ構成を提案し、自動的にノーコード・ローコードツールで形にするといった形です。実際、Microsoft Power PlatformにもCopilotが搭載されています。（もっとも、現時点では“何でも自動で完成する”というより、叩き台を早く作るための補助と捉えるのが現実的でしょう。）

この意味で、生成AIはノーコード・ローコードを置き換える存在ではなく、活用のハードルをさらに下げる補助装置といえます。

4. まとめ：SaaSの死は内製化のチャンス

本記事では、生成AIがなぜ「SaaSの死」を引き起こしているのかと、ITシステムを活用する側の企業にとって「SaaSの死」が意味するところについて考察してきました。

「SaaSの死」とは、SaaSが消えるという話ではありません。生成AIによってソフトウェアが安く作れるようになり、SaaSを「買うこと」だけが唯一の選択肢ではなくなったという変化です。

これからの企業は、①SaaSを使う部分、②内製する部分、③ノーコード・ローコードで補う部分を組み合わせながら、自社の業務に最適な形を設計していくことになります。

そして、その設計こそがDXの核心です。

生成AI時代において重要なのは、「ツールを導入すること」ではありません。自社の業務とシステムの関係をどのように設計するかです。

「SaaSの死」と呼ばれる現象は、企業にとって見れば、むしろ内製化を見直す好機なのかもしれません。

ただし、ここで注意したいのは、生成AIやノーコードが普及しても「設計」と「運用」の問題は残り続けるということです。どこを内製し、どこをSaaSに寄せ、どこを市民開発に任せるのか。さらに、乱立や属人化を防ぐためのガバナンスをどう敷くのか。

こうした線引きと運用設計は、ツール導入以上に難易度が高く、だからこそ外部の伴走支援（コンサルティング）が効果を発揮します。

筆者：W.S.

ITガバナンスおよび市民開発推進を得意領域とするコンサルタント。中堅〜大手企業のIT統制設計・DX推進支援に従事。
個人開発者としてJavaScriptおよびFirebaseを用いたWebアプリ開発にも取り組み、開発現場と統治設計の両面からDXを研究している。
同志社大学大学院経済学研究科博士後期課程修了単位取得退学。

＼今なら無料！／

【30分DX無料相談 実施中】

もし「自社の場合、どこまで内製すべきか」「市民開発をどの範囲に閉じるべきか」「ガバナンスをどう設計するか」といった線引きで迷われている場合は、一度壁打ちをご活用ください。当社では、ITガバナンス設計と市民開発推進の両面から、生成AI時代の内製化を伴走支援しています。

初回30分は無料でご相談いただけます。（オンライン）

→ お申込みはこちら：https://www.qloba.com/forms/10862?_gl=1*1iahbda*_g...