SaaSの正体は3層｜AIで薄くなる層と、それでも残る3つ
文・編集：ワークデイズ合同会社
業務ツール——顧客管理のCRM、営業支援のSFA、会計システムなど——の料金は、実は3つの層に分かれています。前回、AI機能つきSaaSに払う価値があるかを4つの類型で振り分けました（「AI SaaSの料金は何に払っているのか」）。今回はそのうち、いちばん判断が難しかった2つ目の類型を、もう一段だけ分解します。
結論を先に言うと、3つの層のうち2つは、AIが賢くなるほど意味が薄くなります。ただし残るものには、AIがどれだけ賢くなっても消えない価値があります。読み終えたときに、自社が契約しているSaaSの料金が「どの層に対して払われているのか」を分けて見られる状態を目指します。
業務ツールは、だいたい3つの層でできている
業務ツールの中身を分解すると、次の3層になります。
| 層 | 中身 | 役割 |
|---|---|---|
| ① データの箱 | 顧客・取引・仕訳などを溜めるデータベース | 情報を貯める |
| ② UI（画面） | 人がそれを読み書きするための画面 | 人が触れるようにする |
| ③ 業務ロジック | 承認の流れ、締め処理、集計のルール | 業務の型を持たせる |
普段は3つがひとまとまりの「ソフト」として見えているので、分けて考える機会はあまりありません。ただ、AIが入ってくると、この3層は同じようには扱えなくなります。
②のUIは、AIが賢くなるほど意味が薄くなる
まず結論から。入力画面に打ち込んで、一覧画面で確認するという行為は、そもそも人がデータベースを操作するための迂回路でした。
考えてみると、私たちがやりたかったのは「この案件のステータスを進める」であって、「所定の画面を開き、該当の1件を探し、プルダウンを選び、保存を押す」ではありません。後者は、人が直接データベースを触れないからこそ必要になった手順です。自然言語で読み書きできるなら、この迂回路の存在意義は急速に薄れます。
この考え方自体は、SaaSの中の話ではなく業務設計の話です。メールやカレンダーなど必ず発生する作業から情報を拾う設計にすれば、入力という行為そのものが減ります（詳しくは「中小企業の“入力作業ゼロ”は、こうして実現する」に書きました）。このとき、画面は「入力するところ」ではなく「確認するところ」に変わります。
誤解のないように言い添えると、UIが全部消えるという話ではありません。入力のためのUIの価値が下がる、という話です。人が状況を眺めて判断するための画面は残ります。
③の業務ロジックも、実は「UIに収まる形」だった
もうひとつ、見落としやすい点があります。
SaaSに載っている業務ロジックの多くは、その会社の業務をそのまま写したものではありません。画面と項目で表現できる範囲に、業務を圧縮した結果であることが少なくありません。承認フローが3段階なのは業務がそうだからではなく、画面でそう作れるからだった、ということが起こります。
そう考えると、SaaSの価値の相当部分は「UIという制約に最適化されたもの」だった、という見方ができます。制約が変われば、最適な形も変わります。
残るのは①のデータの箱。ただし、溜めるだけなら難しくない
3層のうち②と③の意味が薄くなるなら、残るのは①のデータの箱です。
ここは確かに価値があります。データが一箇所に集まっていること自体が、業務の土台だからです。ただし、単にデータを溜める箱というだけなら、いまはPostgreSQLのようなデータベースを立てれば済みます。技術的な難易度は、以前ほど高くありません。
ここまでを素直に受け取ると、「では基幹システムも要らないのでは」という話になりそうです。でも、そうはなりません。
それでも消えない3つ
私たちが見ている限り、残る価値は大きく3つです。地味ですが、どれも自前でやると本当に大変な部分です。
マルチテナント（複数の会社や部署が同じ仕組みを共有する形）の権限と監査。 誰が・何を・いつ触ったかを、部署や会社をまたいで破綻なく管理する仕組みです。人数が増えるほど難しくなり、事故が起きたときに効いてきます。自前で作ろうとすると、作るより「作り続ける」ほうがきつい領域です。
外部との接続点。 銀行との連携、税制の変更への対応、電子帳簿保存法のような制度要件、業界ごとの標準フォーマット。ここで買っているのは機能というより、制度が変わるたびに追いかけ続ける労力の外注です。変わり続けるものを追う体制を、自社で持ち続けられるかという話になります。
組織の共通言語。 全員が同じ画面を見て、同じ言葉で話せること。これは技術ではなく、調整コストを下げるという社会的な機能です。「例の案件、どうなってる？」が通じるのは、全員が同じ場所を見ているからです。先ほど「残る」と書いた確認のための画面が、ここで効いてきます。
この3つは、前回の4類型のうち「データそのものが商品」「責任と監査」「非技術者が大人数で使う」と、根っこは同じものです。裏を返すと、前回4類型のひとつに挙げた「基幹システムに埋まっている」だけが、こうして分解すると性質が違うということになります。
作る側として、私たちが決めていること
ここまでは買う側の見方です。私たちはAI機能を含むものを作って提供する側でもあるので、そちらのルールも書いておきます。4つあります。
- API（AIの機能を直接呼び出す仕組み）の原価は、お客様のアカウントで持ってもらう。 私たちが原価を抱えて上乗せする形にしません。使用量と単価はお客様が直接見られます。
- どのモデルを使っているかは、すべて開示する。 隠さないので、こちらの都合で黙って安いモデルに替えるということが起こりません。
- できる限りターミナル（コマンドで操作する画面）上で動かす。 独自の画面に包み込まないという意味です。中身が見える状態のまま渡します。
- SaaSに閉じ込めた形のAIサービスは提供しない。 出ていきたくなったときに出ていけるようにしておきます。
理由は単純で、中身が見えなくなった瞬間に、お客様は自分が何にいくら払っているか分からなくなるからです。前回書いたとおり、そこが分かれ目でした。
前回、買う側の確認事項として「どのモデルか分かるか／使用量が見えるか／解約時に持ち出せるか」を挙げました。作る側から同じ問いに答えると、この4つになります。
ただし、降りられるのは限られる
ここは前回も書きましたが、3層に分けたあとのほうが強く効くので、角度を変えて繰り返します。
紙の上で「②はもう要らない」と言えても、実際に剥がすときに抵抗するのは②そのものではありません。②に慣れた人と、②に沿って固まった手順です。画面を覚え直す負担、引き継ぎ資料、取引先とのやりとりの型——どれも技術の合理性とは別の勘定で効いてきます。
結論は前回と同じです。降りられるのは、新しく組むときか、小さい組織のとき。理屈で要らないものが現実には要る状態は、当分続きます。それは判断が間違っているのではなく、組織にはそういう慣性があるというだけの話です。
明日からできること
自社で使っている業務ツールを1つ選んで、3層に分けてみてください。紙に3行書くだけで済みます。
- データの箱として：ここにしかないデータは何か。取り出せるか
- UIとして：この画面で人がやっているのは「入力」か「確認・判断」か
- 業務ロジックとして：この流れは自社の業務が決めたものか、画面の都合で決まったものか
そのうえで、消えない3つ（マルチテナントの権限と監査／外部との接続点／組織の共通言語）のどれに当てはまるかを見ます。当てはまるものが多いほど、その料金には理由があります。逆に、入力のためのUIしか残らないなら、次に作り直すときの選択肢は広いということになります。
まとめ
- 業務ツール（CRMやSFA、会計システムなど）は①データの箱／②UI／③業務ロジックの3層に分けられます
- ②の入力UIは、AIが賢くなるほど意味が薄くなる。フォーム入力は、人がデータベースを触るための迂回路でした
- ③の業務ロジックも、多くは「画面で表現できる範囲に業務を圧縮した結果」。制約が変われば形も変わります
- それでも消えないのはマルチテナントの権限と監査／外部との接続点／組織の共通言語の3つ。どれもAIが賢くなっても残ります
- ただし降りられるのは、新しく組むときか小さい組織のとき。既存の仕組みを剥がすコストは、技術の話とは別次元です
自社の業務ツールを3層で見ると、料金の内訳が少し見えるようになります。「高いか安いか」ではなく「何に対して払っているか」で考えられるようになるのが、この分解の目的です。