SaaS 2.0完全ガイド【2026年最新】｜OpenClaw × Salesforce CLIから見えた”SaaS is not Dead, SaaS is just a Data Warehouse”

Salesforceを2週間、開いていない。

正確に言えば、ブラウザでSalesforceのダッシュボードを見ていない。だが営業データの確認、分析、転記、レポート出力——すべて問題なく回っている。SlackからOpenClawを呼び出し、Salesforce CLIでデータを引っ張る。ただそれだけの構成で、SaaSの「画面」が自分のワークフローから消えた。

コードは1行も書いていない。設定ファイルをいくつかつなげただけだ。

この体験は、ある種の確信を与えてくれた。SaaSの本質は「画面」から「データ保管庫」へ変わる。そして、それはSaaSの終焉ではない。SaaSの再定義だ。

何が起きたのか——OpenClaw × Salesforce CLIの実体験

まず、何をやったのかを正確に書く。

OpenClawは、Slackをインターフェースにして複数のCLIツールやAPIを自然言語で操作できるAIエージェントプラットフォームだ。Salesforce CLI（sf コマンド）は、Salesforceのデータ操作・メタデータ管理をターミナルから行える公式ツール。この2つを接続した。

具体的にできるようになったこと

重要なのは、これらすべてがコードゼロで実現できたという点だ。OpenClawの接続設定とSalesforce CLIの認証設定だけ。プログラミングスキルは不要だった。

セットアップの実際——30分で完了、つまづきポイントは1つだけ

「コードゼロ」と書くと懐疑的になる読者もいるだろう。セットアップの全手順を正直に書く。

所要時間は約30分。手順はざっくり3ステップだ。（1）Salesforce CLIのインストールと認証——npmでsfコマンドをインストールし、sf org login webでブラウザ認証する。ここまで10分。（2）OpenClawのセットアップ——Slackアプリをワークスペースに追加し、Salesforce CLIとの接続設定をGUIで行う。15分。（3）動作確認——Slackで「今月の商談一覧を見せて」と打って、データが返ってくることを確認する。5分。

唯一つまづいたのは、Salesforce CLIの認証トークンの有効期限だ。デフォルトでは数時間で切れるため、接続が途切れてOpenClawが「Salesforceに接続できません」と返してくる。これはSalesforce側の接続アプリ設定でリフレッシュトークンのポリシーを「期限なし」に変更すれば解決する。公式ドキュメントには書いてあるが、初見では見落としやすいポイントだった。

つまり、実質的なハードルは「Salesforce管理者権限があるかどうか」だけだ。権限さえあれば、エンジニアでなくても30分で構築できる。

2週間使ってみた——チーム全員が移行するまでの記録

筆者自身が最初に使い始め、その後チームに展開した2週間の記録を時系列で書く。

1日目：半信半疑。セットアップ完了後、恐る恐るSlackから商談データを引っ張ってみる。ちゃんと返ってくる。だが「本当にこれで大丈夫なのか」という不安が拭えず、Salesforceの画面でも同じデータを確認した。二重チェックの1日。

3日目：もうSFを開かなくなった。Slackからの操作が習慣化した。「パイプラインの合計金額」「今週クローズ予定の案件」「○○社の最終コンタクト日」——聞けばすぐ返ってくる。ダッシュボードの読み込みを待つ時間がゼロになった。この時点で1日あたり約45分の時間節約を実感。

1週間目：チームメンバーが使い始めた。筆者がSlackでデータを引いている様子を見た営業メンバーが「それ何？」と聞いてきた。デモを見せると、最初の反応は「画面を見ないで大丈夫なの？」という不安だった。特にベテラン勢は「Salesforceの画面で全体を俯瞰する」ことに価値を感じていた。だが、実際に試してもらうと反応が変わった。「先週自分が更新したレコードの一覧出して」と話しかけるだけで即座にリストが返る体験は、説得力があった。

2週間目：全員移行完了。最も抵抗していたメンバーも含め、チーム全員がSlack経由でのアクセスに移行した。決定打は「週次営業レポートの自動生成」だった。従来は毎週金曜日に30分かけてSalesforceからデータを引き出し、スプレッドシートに整形し、Slackに投稿していた。これが「先週の営業サマリーを#salesチャンネルに投稿して」の一言で完了する。もう戻れない——全員がそう言った。

数値で整理すると、1人あたり1日約45分の節約。月に換算すると約20時間。年間で約240時間。チーム10人なら年間2,400時間。これは約1.2人分のフルタイム工数に相当する。SaaSの画面を開かないだけで、だ。

衝撃だったのは「もうSaaSの画面に戻りたくない」という感覚

一度この体験をすると、SaaSの画面を開くことが「非効率」に感じ始める。ダッシュボードの読み込みを待つ時間、フィルターを設定する手間、エクスポートしてスプレッドシートに貼り付ける作業——そのすべてが「データにアクセスするためだけの摩擦」だったと気づく。

自分が欲しかったのは「画面」ではなく「答え」だった。そして今、AIエージェントが答えを直接持ってきてくれる。

UI層の消滅——SaaSの「画面」が不要になる構造

これは個人的な体験にとどまらない。構造的な変化が起きている。

SaaSの歴史的文脈——ASP時代から20年の進化

振り返れば、SaaSの歴史は「インターフェースの進化」の歴史だった。

2000年代前半：ASP（Application Service Provider）時代。ソフトウェアをインターネット経由で提供するという発想自体が革新だった。だがUIはデスクトップアプリの劣化版に過ぎず、「ブラウザで動く」こと自体がセールスポイントだった。

2000年代後半〜2010年代：SaaS 1.0。Salesforceが「No Software」を掲げ、クラウドネイティブなUIが成熟した。ダッシュボード、ドラッグ&ドロップのレポートビルダー、リアルタイムコラボレーション。UIの使いやすさがSaaSの競争力そのものだった時代。

2020年代前半：SaaS飽和期。あらゆる業務領域にSaaSが登場し、企業は平均130以上のSaaSを利用するようになった。「SaaS疲れ」という言葉が生まれ、UIの乱立がむしろ生産性を下げ始めた。

2025年〜：SaaS 2.0の始まり。AIエージェントがUIを代替し始めた。今、我々はここにいる。

20年かけて磨き上げられたSaaSのUIが、AIエージェントの登場で「オプション」に変わろうとしている。これは退化ではない。UIという中間層を挟まずにデータに直接アクセスできるようになったという進化だ。

他業界に学ぶ——インターフェースの消滅は何度も起きている

この変化はSaaS業界だけの特殊事象ではない。インターフェースの抽象化と消滅は、他業界で繰り返し起きてきたパターンだ。

銀行：窓口 → ATM → モバイルアプリ → 音声・AIバンキング。物理的な窓口が「必須」だった時代は終わった。だが銀行そのもの（データ＝口座残高、取引履歴）は消えていない。

小売：店頭販売 → ECサイト → モバイルアプリ → 音声注文（Alexa）→ AIレコメンド自動購入。小売のUIは店舗→画面→音声と抽象化されてきたが、商品データとサプライチェーンというデータ層は健在だ。

タクシー：路上で手を挙げる → 電話予約 → 配車アプリ → 自動配車。「タクシーを呼ぶ」というインターフェースは消えたが、タクシーという移動サービス（データ＝位置情報、料金、ドライバー情報）は残った。

共通するパターンは明確だ。インターフェースは抽象化・消滅するが、その裏にあるデータとサービスは残り続ける。SaaSにも同じことが起きている。

SaaSの3層構造を分解する

従来のSaaSは、3つの層が一体化した製品だった。

UIとロジックはすべて「データにアクセスするための手段」だった。だがAIエージェントがその手段を代替できるようになった今、SaaSに残る本質的な価値はデータそのものだけだ。

なぜ今、この分離が起きるのか

3つの技術的条件が同時に揃った。

少し補足する。MCP（Model Context Protocol）はAnthropicが提唱したオープンプロトコルで、AIモデルと外部ツールの接続を標準化するものだ。これまでAIエージェントが外部ツールを操作するには、ツールごとに個別の接続コードを書く必要があった。MCPはこの「接続コスト」を劇的に下げた。USBが周辺機器の接続を標準化したように、MCPはAIとSaaSの接続を標準化しつつある。

Function Callingも急速に進化している。2023年にOpenAIが導入した当初は精度に不安があったが、2025年時点ではGPT-4o、Claude、Geminiいずれも高い精度でツール呼び出しを実行できる。「AIが意図を誤解してデータを壊すのでは」という懸念は、確認プロンプトとロールバック機構で実用レベルまで解消されている。

そしてCLI/APIの充実度。SalesforceのCLIは現在500以上のコマンドを備え、UIで可能な操作のほぼ100%をカバーしている。HubSpotのAPIはv3で大幅に改善され、StripeのCLIはもはやダッシュボードより高機能だ。SaaS各社が「APIファースト」を掲げ始めたのは、この構造変化を自覚しているからに他ならない。

この3条件が揃ったことで、SaaSのUI層は「必須」から「オプション」に変わった。

「UIが必要なケース」への反論

ここで予想される反論に答えておく。「すべてのケースでUIが不要とは言えないのでは？」——その通りだ。現時点でUIが優位なケースは存在する。

初期設定やオンボーディング。SaaSを初めて導入する際、GUIでの設定画面は直感的で分かりやすい。だがこれは「最初の1回」の話だ。日常業務でSaaSの設定画面を触る頻度は極めて低い。

複雑なビジュアル分析。営業パイプラインのファネル図や、プロジェクトのガントチャートなど、視覚的な俯瞰が必要な場面。だがこれもAIが生成するリッチなチャートやインタラクティブなレポートで代替が進んでいる。

新人トレーニング。「画面を見ながら覚える」という学習プロセス。だがAIエージェント自体が対話的なトレーニングツールになり得る。「商談の登録方法を教えて」と聞けば手順を説明し、実行まで補助してくれる。

いずれのケースも、現時点では UIが優位だが、段階的にAIが代替していく領域だ。2026年の今は過渡期にある。だが方向性は明確だ。

SaaS 3分岐モデル——Data Layer・Workflow Engine・AI-Native

ではSaaSはどこに向かうのか。筆者はSaaSが3つのカテゴリに分岐していくと考えている。

カテゴリ1：Data Layer SaaS

「データの保管庫」として生き残るSaaSだ。Salesforce、HubSpot、Workday、SAPなどの既存大手がここに収束する。

これらのSaaSは膨大な業務データを構造化して保管し、そのデータスキーマ自体が業界標準になっている。「商談」「リード」「パイプライン」というSalesforceの概念体系は、もはやSalesforceの製品機能ではなく営業プロセスの共通言語だ。

Salesforceの戦略転換は象徴的だ。2024年にAgentforceを発表し、2025年にはMCPサーバーを公式提供し始めた。これは「UIの会社」から「データプラットフォームの会社」への明確なピボットだ。Marc Benioffが「We are a data company」と発言し始めたのは偶然ではない。SalesforceはSaaSのUI層が消滅する未来を自ら認め、Data Layer企業としての再定義に動いている。

このカテゴリのSaaSは、UIの価値が減少する代わりに、API・CLIの品質とデータガバナンスが競争力の源泉になる。

カテゴリ2：Workflow Engine SaaS

SaaS間のデータフローを制御する「接着剤」として価値を持つカテゴリだ。Zapier、Make、OpenClawなどが該当する。

AI時代においてこのカテゴリは、単なる「AをトリガーにBを実行」するルールエンジンから、AIが意図を解釈してワークフローを動的に組み立てるオーケストレーターへ進化する。OpenClawが自然言語でSalesforce CLIを操作できるのは、まさにこの進化の例だ。

Zapierの進化が分かりやすい。かつてはGUIでトリガーとアクションをポチポチ設定する「ノーコード自動化ツール」だった。だが今はAIによる自然言語ワークフロー構築機能を前面に出している。「毎週金曜にSalesforceの週次データをまとめてSlackに投稿して」と言うだけでワークフローが組み上がる。UIは設定の確認用として残るが、主要なインターフェースはAIとの対話に移行しつつある。

カテゴリ3：AI-Native SaaS

最初からUIがAIとの対話であり、従来型の「画面」が存在しないSaaSだ。Cursor、Perplexity、Devin、Harveyなどが該当する。

このカテゴリは「SaaSのUI層が消える」議論の影響を受けない。そもそもUI層＝AIだからだ。代わりにドメイン特化のデータとモデル精度が競争力になる。

Cursorの急成長が示唆的だ。2024年にARR（年間経常収益）が1億ドルを突破し、開発者向けSaaSの中で最も速い成長曲線を描いた。Cursorが証明したのは、「AIネイティブな体験は、既存SaaSの延長線上にはない」ということだ。VS Codeに後からAI機能を追加するGitHub Copilotとは、設計思想のレベルで異なる。

カテゴリ間のグレーゾーン——ハイブリッド型SaaSの立ち位置

もちろん、3つのカテゴリに綺麗に分かれるわけではない。グレーゾーンに位置するハイブリッド型SaaSも多い。

NotionはData Layer + AI-Nativeのハイブリッドだ。ドキュメントとデータベースという強力なData Layerを持ちながら、Notion AIで対話的なデータアクセスを提供している。SlackはWorkflow Engine + AI-Nativeだ。コミュニケーション基盤でありながら、Slack AIとワークフロービルダーでオーケストレーション機能を拡充している。

ハイブリッド型は一見有利に見えるが、リスクもある。どのカテゴリでも中途半端になり、専業プレイヤーに各領域で負ける可能性だ。Notionのデータベース機能はAirtableほど強力ではなく、AI機能はCursorほど深くない。「広く浅く」は、AI時代の専業化の流れの中で不利に働く可能性がある。

日本市場の分岐予測

日本市場のSaaS企業がどのカテゴリに向かうかを予測する。

freee（会計・HR）：Data Layer SaaS。会計データ、給与データ、労務データという高い規制要件のデータを保管しており、Data Layer化の適性が極めて高い。API公開も進んでいる。

SmartHR（人事労務）：Data Layer SaaS。従業員データの構造化とコンプライアンス対応が本質的な価値。年末調整や社会保険手続きのUIは段階的にAIが代替可能。

Sansan（名刺管理→営業DX）：Data Layer SaaS。名刺データ＝ビジネスネットワークデータという唯一無二のデータ層を持つ。UIよりもデータのユニークさが競争力。

kintone（サイボウズ）：Workflow Engine SaaS寄りのハイブリッド。ノーコードでデータベースとワークフローを構築できる柔軟性が強み。AI連携の深度が今後の分岐点になる。

シート課金の崩壊——10ライセンスが1 API接続に置き換わる

SaaSのUI層が不要になるということは、「画面を見る人数」で課金するモデルが崩壊することを意味する。

シート課金が破綻する具体的なメカニズム

考えてみてほしい。営業チーム10人が毎日Salesforceにログインして商談を確認・更新していたとする。Enterprise版で1人あたり月額$165。年間$19,800。

OpenClaw × Salesforce CLIの構成では、SalesforceにログインするのはAPI接続用の1アカウントだけだ。10人全員がSlackから営業データにアクセスする。Salesforceのライセンスは1つ。

規模別コスト試算——10人・50人・100人で何が変わるか

規模が大きくなるほど、コスト削減のインパクトは劇的になる。

50人規模で年間約$91,000の削減。100人規模なら約$186,000。中堅企業にとっては無視できない金額だ。

もちろんSalesforce側もこれに気づいている。だからこそSalesforceはAgentforceを立ち上げ、「AIエージェントの成果に課金する」モデルへ移行しようとしている。これは防衛策であると同時に、シート課金の終焉を自ら認めた動きだ。

SaaS企業各社の反応を見ると、この流れは不可逆だ。HubSpotはAI Hubを立ち上げ、AIエージェント機能をプラットフォームの中核に据え始めた。Notion AIは月額$10の追加課金でAI機能を提供し、将来的にはAI利用量ベースの課金への移行を示唆している。Slack AIも同様に、従来のシート課金に加えてAI機能の利用量課金を導入している。各社とも「シート課金だけでは持たない」ことを自覚している。

課金モデル移行の注意点

ただし、正直に書く。「完全にシート不要」にならないケースもある。

APIレートリミットの壁。多くのSaaSはAPIの呼び出し回数に上限を設けている。Salesforceの場合、Enterprise版でも24時間あたりのAPIコール上限がある。100人が頻繁にデータアクセスする場合、APIリミットに達する可能性がある。これは追加のAPI呼び出し枠を購入するか、キャッシュ層を挟むことで対処可能だが、コスト計算に含める必要がある。

Enterprise契約の交渉。大企業の場合、SaaSベンダーとの契約にシート数が紐付いていることが多い。契約途中でのライセンス削減はペナルティが発生する場合がある。移行は契約更新のタイミングに合わせるのが賢明だ。

段階的移行の推奨。いきなり全員のライセンスを削減するのではなく、まずパイロットチームで効果を検証し、3〜6ヶ月かけて段階的に移行することを推奨する。

課金モデルの進化

SaaS is just a Data Warehouse——新しいSaaSの定義

ここで本題だ。

「SaaS is Dead」という主張がVC界隈で流行している。AIがすべてを代替し、SaaSは不要になるという論調だ。だが、これはUIとしてのSaaSを見て「終わった」と言っているだけだ。

SaaSの本質的な価値——データの構造化、保管、ガバナンス——はなくならない。むしろAIエージェントが普及するほど、信頼できるデータソースとしてのSaaSの価値は上がる。

なぜ「Data Warehouse」という表現なのか

Data Warehouseとは、様々なソースからデータを集約・構造化し、分析に使えるようにする保管庫だ。SaaSがやっていることは本質的にこれと同じだ。

DWHの歴史的定義との比較

Data Warehouseの世界には2つの古典的なアプローチがある。Bill Inmonのトップダウン型（企業全体のデータを正規化して統合）と、Ralph Kimballのボトムアップ型（部門別のデータマートを星型スキーマで構築し、後から統合）だ。

興味深いことに、SaaSはKimballアプローチに近い。Salesforceは営業データのデータマート、Workdayは人事データのデータマート、ServiceNowはITサービスデータのデータマートだ。各SaaSが「ドメイン特化のData Warehouse」として機能している。

ではSnowflakeやDatabricksとの違いは何か。Snowflake/Databricksは汎用DWH——あらゆるデータを格納できるが、ドメイン固有のスキーマや業務ロジックは持たない。対してSaaSは「ドメイン特化DWH」——営業、人事、会計といった特定領域のデータモデルと業務知識が組み込まれている。「商談のステージ遷移」「受注確度の計算ロジック」といった業務の意味論がスキーマに埋め込まれている点が、汎用DWHとの決定的な違いだ。

この違いは重要だ。AIエージェントが「今月の受注見込みを教えて」と言われたとき、Salesforceのスキーマなら「Opportunityテーブルの CloseDate が今月 かつ StageName が特定の値」と即座にクエリを組める。汎用DWHでは、まずどのテーブルのどのカラムが「受注見込み」に該当するかを理解する必要がある。ドメイン知識が組み込まれたスキーマは、AI時代においてむしろ価値が上がる。

セキュリティ・コンプライアンスがDWH化を後押しする

SaaSのDWH化を後押しするもう一つの要因がある。セキュリティとコンプライアンスだ。

GDPR、SOC 2、ISO 27001、日本の個人情報保護法——これらの規制はすべて「データがどこに保管され、誰がアクセスし、どう処理されるか」を厳密に管理することを求めている。SaaSがData Warehouseとしてデータを集中管理することは、コンプライアンス対応を容易にする。

特にデータレジデンシー要件（データを特定の国・地域内に保管する義務）は、SaaSのDWH化を加速させる。EUのデータはEU内のSaaSインスタンスに、日本のデータは日本リージョンに——この要件を満たすために、SaaS各社はリージョン別のデータ保管インフラを強化している。これはまさにDWHの機能だ。

AIエージェントが複数のSaaSからデータを横断的に取得する世界では、各SaaSが「信頼できるデータソース」として機能することがますます重要になる。データの整合性、監査ログ、アクセス制御——これらのガバナンス機能こそが、SaaS 2.0時代の競争力になる。

「SaaS is Dead」論者への反論

「SaaS is Dead」論者の主張を整理し、具体的に反論する。

主張1：「AIがすべてを代替するからSaaSは不要になる」
反論：AIが代替するのはUIとロジックであり、データの保管・構造化・ガバナンスは代替できない。AIエージェントは「どこかからデータを取ってくる」必要があり、その「どこか」がSaaS（Data Warehouse）だ。

主張2：「自社でAIシステムを構築すればSaaSは不要」
反論：自社でCRMデータのスキーマ設計、バリデーション、重複排除、アクセス制御、コンプライアンス対応をゼロから構築するコストは莫大だ。SaaSが20年かけて蓄積した業務ドメインの知識をゼロから再構築するのは非合理的。

主張3：「オープンソースとAIでSaaSを置き換えられる」
反論：技術的には可能だが、運用コストが見落とされている。データのバックアップ、セキュリティパッチ、スケーリング、コンプライアンス対応——これらを自前で維持するコストは、SaaSの利用料を上回ることが多い。

違いがあるとすれば、従来のSaaSはこれに「画面（UI）」を被せていた点だ。だがその画面は、AIエージェントの出現によってもはや必須ではなくなった。

残るのは、データの保管・構造化・ガバナンス。つまりSaaS is just a Data Warehouse。

次に何が起きるのか——SaaS 2.0時代の生存戦略

この構造変化を前提にすると、SaaS企業と利用者それぞれに明確な戦略が見えてくる。

SaaS企業がとるべき3つのアクション

API-First転換の具体的ステップ：（1）現在のUI機能とAPI機能のギャップを洗い出す。（2）UIでしかできない操作をAPIで実現するための開発ロードマップを策定する。（3）MCP/Function Callingに対応した公式コネクタを開発する。（4）APIドキュメントとSDKの品質を「UIと同等以上」のレベルに引き上げる。（5）開発者コミュニティとエコシステムを構築する。SalesforceがTrailheadで20年かけてやったことを、API中心に再構築するイメージだ。

利用者がとるべき3つのアクション

ケーススタディ——中堅SaaS企業A社の6ヶ月転換

架空だが現実的なケーススタディを示す。

A社のプロフィール：従業員80名のB2B SaaS企業。プロジェクト管理ツールを提供。年間売上約$5M。顧客数約500社。課金モデルは従来型のシート課金（$15/user/月）。

課題：大口顧客から「AIエージェント経由でアクセスするのに、全員分のシートは必要ない」というフィードバックが増加。契約更新時の解約率が上昇傾向。

6ヶ月の転換プロセス：

Month 1-2：API品質の棚卸しと改善。UIで可能な操作の70%しかAPIでカバーできていないことが判明。不足する30%のAPI開発に着手。同時にMCPサーバーのプロトタイプを開発。

Month 3-4：課金モデルのハイブリッド化。従来のシート課金に加えて「API接続プラン」を新設。1APIキーにつき月額$200、API呼出は月間10万回まで。既存顧客には移行インセンティブとして最初の3ヶ月を50%オフで提供。

Month 5-6：データガバナンス機能の強化。監査ログの詳細化、RBAC（ロールベースアクセス制御）のAPI対応、データエクスポートのバッチ処理機能を追加。これにより「Enterprise顧客のコンプライアンス要件」をData Layer SaaSとして満たす体制を構築。

結果：解約率が15%減少。API接続プランの採用企業が全体の20%に達し、ARPAが実質的に向上。「UIの会社」から「プロジェクトデータプラットフォーム」への再定義に成功。

何から始めるべきか——1週間・1ヶ月・3ヶ月のマイルストーン

SaaS企業向け：

最初の1週間：自社のAPI/CLIカバレッジ率を測定する。UIでできてAPIでできない操作をリストアップする。競合他社のAPI品質と比較する。

1ヶ月目：MCP/Function Callingに対応したプロトタイプを1つ構築する。社内でドッグフーディングし、「自社SaaSの画面を開かずに業務ができるか」を検証する。

3ヶ月目：APIファーストの開発方針を正式に策定する。新機能はAPI→UIの順序で開発する体制に転換する。課金モデルのハイブリッド化を設計する。

SaaS利用者向け：

最初の1週間：最も頻繁に使うSaaSを1つ選び、そのSaaSのAPI/CLIドキュメントを確認する。OpenClawやZapierなどのワークフローツールの無料トライアルを開始する。

1ヶ月目：パイロットチーム（3-5人）でAIエージェント経由のSaaSアクセスを試行する。時間節約の数値を計測する。

3ヶ月目：パイロットの結果を基に、SaaSベンダーとのライセンス交渉を開始する。次回の契約更新に向けて、API接続プランへの移行計画を策定する。

失敗パターンの警告

最後に、SaaS 2.0への移行で陥りがちな失敗パターンを3つ挙げる。

失敗1：UIだけ削ってAPI未整備。「SaaSのUIは不要になる」という論調に反応し、UI開発リソースを削減。だがAPI/CLIの品質が追いつかず、顧客は「UIもAPIも中途半端」な状態に不満を感じて解約する。順序が重要だ。APIを充実させてから、UIのリソースを段階的に再配分する。

失敗2：課金変更が急すぎて解約急増。シート課金を一気にAPI課金に切り替え、既存顧客のコストが急増。特にAPIの利用量が読めない段階での従量課金は、顧客に心理的な不安を与える。最低でも12ヶ月の移行期間を設け、ハイブリッドモデルを経由する。

失敗3：データガバナンスを後回し。API公開に注力するあまり、アクセス制御や監査ログの整備が後回しに。セキュリティインシデントが発生し、信頼を失う。Data Layer SaaSとしての価値の根幹はガバナンスだ。APIとガバナンスは同時に強化する。

まとめ——SaaS is not Dead, SaaS is just a Data Warehouse

もう一度、最初の体験に戻ろう。

Salesforceの画面を2週間開かなかった。だが営業の仕事は完璧に回っていた。SaaSは死んでいない。SaaSの「画面」が死んだだけだ。

Salesforceのデータは今も毎日使っている。ただし、そのアクセス方法がブラウザの画面からSlackのAIエージェントに変わっただけ。SaaSの価値は、データの保管・構造化・ガバナンスに集約されていく。

「SaaS is Dead」と言うのは簡単だ。だがSaaSが築いたデータの構造化とガバナンスのインフラは、AI時代においてむしろ価値が上がる。死んだのはSaaSではない。死んだのは「画面ありきのSaaS」というビジネスモデルだ。

SaaS 2.0は脅威ではない。チャンスだ。SaaS企業にとっては「データプラットフォームとしての再定義」という、より本質的なポジショニングを獲得する機会。SaaS利用者にとっては、シート課金の呪縛から解放され、データそのものの価値に集中できる機会。変化の方向性は明確で、準備した者が勝つ。

明日からできる3つのこと

1. 最も使っているSaaSの画面を1日開かずに過ごしてみる。Slack、CLI、APIなど代替手段で業務が回るか試す。回らないなら、何が足りないかを特定する。それがSaaS 2.0への第一歩だ。

2. 自社のSaaSライセンス一覧を棚卸しする。何人がシート課金され、実際に画面を開いている頻度はどのくらいか。「月に1回も開かないのにシートを持っている人」が何人いるか。その数字がコスト削減の潜在的なインパクトだ。

3. OpenClawやZapierの無料トライアルを今日始める。記事を読んで「なるほど」と思うだけでは何も変わらない。30分のセットアップで、SaaS 2.0を体感できる。百聞は一見にしかず、だ。

あなたが使っているSaaSのダッシュボードを、最後に開いたのはいつだろうか。もしその答えが「最近開いていない」なら——あなたはもう、SaaS 2.0の入り口に立っている。