独立してから、クライアント企業のITツール導入を手伝う仕事が増えた。2010年代に入った頃のことだ。当時、中小企業のIT環境は大きく変わり始めていた。サーバーを自社に置き、システム管理者を雇い、バックアップテープを毎日交換する——そういう時代が終わりかけていた。代わりに台頭してきたのがSaaS——Software as a Serviceだ。ソフトウェアを買い切りでインストールするのではなく、月額料金を払ってクラウド上のサービスを使う。サーバーの維持管理は提供者がやってくれる。バージョンアップも自動だ。初期費用が抑えられ、いつでも解約できる。そういう触れ込みだった。
私はクライアントにSaaSの導入を勧める側だった。プロジェクト管理ツール、グループウェア、CRM。いくつものサービスを比較し、提案し、導入を支援した。「クラウドに乗せましょう」が提案書の常套句だった。実際、導入直後の反応は良かった。サーバー室の騒音が消える。バージョンアップの作業が不要になる。どこからでもアクセスできる。経営者は喜んだ。現場も最初は歓迎した。だが半年、一年と経つうちに、風景が変わっていく。最初に気づくのは、データの行き場のなさだ。
月額の身軽さは、解約の重さで帳消しになる
SaaSは「いつでも解約できる」ことが売りだった。初期費用は安い。合わなければやめればいい。だが実際に解約しようとした会社が何社あったか。私の経験では、導入から一年を超えたSaaSを解約できた会社は、ほとんどなかった。理由は単純だ。やめられなくなっていたのだ。
まず、データが出せない。SaaS上に蓄積された顧客情報、商談履歴、プロジェクトの進捗記録。これらをCSVでエクスポートする機能はたいていのサービスに備わっている。だがエクスポートしたCSVを別のサービスにインポートしようとすると、フォーマットが合わない。項目名が違う。関連テーブルの構造が異なる。添付ファイルは個別にダウンロードするしかない。コメントのやり取りや更新履歴は、そもそもエクスポートの対象外だったりする。データはある。だが「使える形」では取り出せない。第26回で書いた、CRMのデータ整理の話と構造は同じだ。あのときはデータを「使える形」にする作業を人の手でやった。だが今度は、自分たちが入れたデータが、自分たちの手の届かない場所に閉じ込められている。
次に、業務フローがSaaSに依存している。あるクライアントでは、営業の日報がSaaS上でしか書けない仕組みになっていた。報告のテンプレートも、承認のワークフローも、通知の仕組みも、すべてそのサービスの上に構築されている。解約するということは、日報の仕組みそのものを一から作り直すということだ。ツールを入れ替えるのではない。業務を設計し直すのだ。導入するときは数週間で済んだ作業が、離脱するときは数か月かかる。ここまで来ると「いつでも解約できる」は理論上の話にすぎない。
そして海外本社のSaaSには、もう一段の厄介さがあった。UIが突然変わる。昨日まであったボタンの位置が変わり、メニューの名称が変わり、操作手順が変わる。日本のユーザーに事前告知はない。本社が決めたロードマップに従って、全世界一斉にアップデートされる。クライアントから「画面が変わって操作がわからない」という問い合わせが来て、私も初めて知った——そんなことが何度もあった。料金体系も本社の判断で変わる。円安が進めばドル建ての月額が実質値上げになる。為替変動のたびに予算が狂う。機能追加やプラン改定で、今まで使えていた機能が上位プランに移される。使い続けたければ追加料金を払え。そういう一方的な変更に対して、ユーザー企業ができることはほとんどない。提供者と利用者の力関係は、最初から対等ではなかったのだ。
ChatGPTに引っ越した会社は、出口を確認したか
2023年以降、同じことがAIサービスの領域で起きている。ChatGPTを業務に導入する。ChatGPT上に社内専用のチャットボットを構築する。Copilotにコードレビューを任せる。議事録の要約、メールの下書き、提案書のたたき台。あらゆる業務がAIサービスの上に載り始めている。SaaSのときとまったく同じ構図だ。初期費用は安い。月額の料金を払えばすぐに使える。サーバーの準備もいらない。導入は簡単だ。だが一年後、そのサービスをやめると言い出したとき、何が起きるか。
社内で蓄積したプロンプトのテンプレート。業務ごとにチューニングしたChatGPTの設定。社員が日々の業務で作り上げたAIとのやり取りのノウハウ。これらはすべて、特定のAIサービスの上にしか存在しない。OpenAIがChatGPTの料金体系を変えたらどうするか。利用規約が変わり、入力データの取り扱い方針が変わったらどうするか。別のサービスに乗り換えようとしたとき、ChatGPT上に構築した設定は持ち出せるか。プロンプトのテンプレートは他のAIでそのまま動くか。動かない。サービスごとにAPIの仕様が違い、モデルの特性が違い、同じプロンプトでも返ってくる結果が違う。SaaSのCSVエクスポートと同じだ。データはある。だが「使える形」では移行できない。
ガイドラインは、AIサービスの利用者に対して、提供者の責任範囲を確認することを求めている。入力したデータがどのように取り扱われるか。学習に利用されるのか。保存されるのか。第三者に提供されることがあるのか。利用規約をきちんと読んでいるか。これらはすべて、SaaS契約のときに確認すべきだったことと同じだ。だがSaaSのときに利用規約を熟読して導入を決めた中小企業がどれほどあったか。ほとんどなかったはずだ。「便利だから使う」。判断基準はそれだけだった。私自身、クライアントに導入を勧めるとき、利用規約の細部まで確認していたかと問われれば、正直に言えば不十分だった。機能の比較、価格の比較、操作性の比較。導入の決め手はいつもこの三つだった。「やめるとき」のことは、考えていなかった。
ガイドラインが利用規約の確認を求めているのは、法律家の潔癖症ではない。SaaSの十年間で実際に起きたことの反復を防ぐためだ。入ったはいいが出られない。条件が変わっても従うしかない。使い続けるか、すべてを捨てて一からやり直すか。その二択に追い込まれる前に、出口を確認しておけ。ガイドラインはそう言っている。
賃貸住宅の自由は、契約書の中にしかない
SaaSもAIサービスも、構造は賃貸住宅に似ている。持ち家ではなく賃貸を選ぶ理由は明快だ。初期費用が安い。ローンを組まなくていい。住んでみて合わなければ引っ越せる。ライフスタイルの変化に柔軟に対応できる。身軽さこそが賃貸の価値だ。SaaSの営業資料も、まったく同じ論理で書かれていた。初期投資が不要。スケーラブル。いつでも解約可能。言い換えればそれは、「借りている」ということだ。
だが賃貸には、持ち家にはない制約がある。壁に釘一本打てない。ペットを飼えない物件がある。騒音のルールは管理組合や大家が決める。そして何より、条件は大家の都合で変わる。家賃が上がる。更新料を取られる。設備が老朽化しても修繕するかどうかは大家の判断だ。建物の取り壊しが決まれば、立ち退きを求められる。契約書には「正当事由がある場合」と書いてあるが、何が正当事由かの最終判断は借主の手にはない。賃貸の自由とは、契約書の条文の中にだけ存在する自由だ。
持ち家は不自由だ。ローンに縛られ、固定資産税がかかり、修繕も自己責任だ。簡単には引っ越せない。だが壁に棚をつけられる。庭に木を植えられる。誰の許可も要らない。自分の裁量で、自分の空間を作れる。データを自社のサーバーに置く——いわゆるオンプレミスの発想は、持ち家に近い。維持管理の手間はかかるが、データは自分の手元にある。勝手に仕様を変えられることもない。大家の都合で追い出されることもない。
SaaSは賃貸だ。AIサービスも賃貸だ。便利で身軽だが、大家の都合に左右される。OpenAIが家主、Googleが家主、Microsoftが家主。家賃を払っている間は住める。だが間取りの変更も、家賃の値上げも、家主が決める。借主にできるのは、住み続けるか出ていくかの選択だけだ。そして出ていく先が見つからなければ——荷物が多すぎて運び出せなければ——住み続けるしかない。これがベンダーロックインの正体だ。鍵をかけられているのではない。荷物の重さで動けなくなっているのだ。
ガイドラインが求めているのは、引っ越す前に契約書を読め、ということだ。家賃はいくらか。更新の条件は何か。退去時に何が残り、何が消えるか。大家が条件を変えたとき、借主にはどんな選択肢があるか。これらは入居前に確認すべきことだ。部屋に荷物を運び込み、住所変更の届けを出し、近所付き合いを始めてから「やっぱりこの物件は条件が悪い」と気づいても、簡単には動けない。
SaaSの十年を振り返って思うのは、引っ越す前に契約書を読んだ会社がほとんどなかったということだ。私自身も含めて。便利さに目を奪われ、身軽さを信じ、出口のことは考えなかった。AIサービスについて、ガイドラインは同じ轍を踏むなと言っている。新しい賃貸物件に引っ越す前に、契約書を読め。出口を確認しろ。大家が誰で、何を決める権限を持っているかを知れ。「いつでも解約できます」という言葉の裏に、どれだけの重さが隠れているか。SaaSの十年が、それを教えてくれている。
次回は、AIの利用ルールを社内でどう整えるかを取り上げる。ISMSやセキュリティポリシーの策定に携わった経験がある人には、既視感のある話になるだろう。組織に新しい技術が入ってきたとき、ルールを作るのは誰で、守らせるのは誰か。あの頃と構造は変わっていない。
次の成長に向けて、いま整えるべきことを。
AI、EC、マーケティング、採用、数値管理。
構想だけで終わらせず、実行できる体制へ。
まずは課題を整理してみるところから、スポルアップが実務目線で伴走します。
