SaaSは、従来のベンダーロックインに対する特効薬となるはずだった。月額料金を支払い、継続的なアップデートを受け取り、90日前の通知で解約できる。このビジネスモデル全体は、柔軟性を基盤として構築されていた。しかし、AIはその約束を静かに崩しつつある。契約書の最初のページにある条項を変えるのではなく、ユーザーが実際に購入しているものの本質そのものを変えていくことで。
クラウドプロバイダーが生産性スイートにAIエージェントを組み込んだり、CRMベンダーがパイプラインデータから学習するAIアシスタントを提供したり、ERPプロバイダーが調達決定を自動化するエージェント型ワークフローを導入したりすると、その「ソフトウェアサブスクリプション」は、まるで電力供給契約のようなものになってくる。理論上は乗り換えることは可能だが、その際の真のコストは、更新時に誰もが想定している額をはるかに上回るものとなっている。
「昨年締結した契約書は、現在実際に適用されている内容とは全く異なるものになっています――しかし、多くの組織はそれにまだ気づいていません。」
現在、企業の調達、財務、テクノロジーの責任者が直面している最大の課題は、AI機能によってSaaSの関係性が「サブスクリプション型」から「インフラ型」へと変化しつつあるという点です。この変化をいち早く認識した組織は、より有利な条件を交渉し、より強靭なシステム基盤を構築し、新たなベンダー依存を回避できるでしょう。一方、この変化に気づかない組織は、本来受け入れるつもりはなかった条件に縛られることになってしまうでしょう。
どれほど状況が変わったかを理解するには、そもそもSaaSがオンプレミス型ソフトウェアにどのような変革をもたらしたのかを振り返るとよいでしょう。その最大の特徴はコストの低さではなく、「代替可能性」でした。人事管理ソフトウェアのベンダーが価格を引き上げたり、機能面で遅れをとったりした場合でも、競合他社との比較評価を行い、データを移行し、四半期以内に新しいプラットフォームで運用を開始することができたのです。乗り換えコストは確かに存在しましたが、それは限定的なものであり、予測可能な範囲内でした。
それに伴い、企業の調達手法も変化した。契約期間の短縮が標準となった。利用量に応じた課金体系により、買い手は過剰なコミットメントを避けつつ、柔軟に規模を拡大できるようになった。パイロット導入を優先するモデルにより、組織は複数年契約を結ぶ前に、自社のニーズに合致しているかを確認できるようになった。SaaSベンダーは、かなりの程度において代替可能であるという前提のもと、調達戦略のすべてが見直された。
これが機能したのは、SaaS製品の価値が、ソフトウェアの機能(機能セット、ユーザーインターフェース、統合ライブラリなど)へのアクセスに根ざしていたからです。ソフトウェアはユーザーを認識せず、ユーザーから学習することもありませんでした。ユーザーのデータはシステム内に保存されていましたが、システムの知能はそのデータに基づいて成長することはありませんでした。つまり、乗り換えとは、構造化されたレコードをあるデータベースから別のデータベースへ移行することであり、学習済みのモデルが持つビジネスへの理解を解体することではなかったのです。
主な洞察
SaaSが当初掲げた「柔軟性」「低い乗り換えコスト」「サブスクリプションモデル」という約束は、ソフトウェアが代替可能であるという前提に基づいていました。しかし、AIはソフトウェアにビジネスを学習させることで、その前提を覆します。一度学習が完了すれば、乗り換えは単なる移行ではなく、再構築となるのです。
その世界は終わりを迎えようとしている。ベンダーが価格ページを変更したからではなく、AIがソフトウェアの役割を根本から変え、ひいてはソフトウェアに依存することの意味そのものを変えてしまったからだ。
サブスクリプションからインフラへの移行は、単一のメカニズムによって進んでいるわけではありません。それは、互いに相乗効果を生み出す3つの構造的要因が融合した結果です。それぞれが単独でも重要な要素ですが、これらが相まって、新たな調達の実態を形作っています。
AI機能が、自社のデータ(顧客記録、サポートチケット、営業通話の記録など)を用いて学習、微調整、あるいは継続的に改善されるようになると、データの移行は単なるデータエクスポートの問題ではなく、データアーキテクチャの問題へと変化します。
従来のSaaS移行では、構造化されたレコードの移行が中心でした。AI時代の移行では、「モデルが学習したコンテキストはどこへ行くのか」という問いが重要になります。多くの場合、その答えは「どこにも行かない」ということです。それはベンダー側に残り、いかなるエクスポート形式でも取り込むことのできないシステムに組み込まれたままになるのです。 そのAIの性能向上に向けた投資——ラベリング、フィードバックループ、カスタムトレーニング——は、貸借対照表には表れないものの、移行を試みる際には非常に現実的な「切り替えコスト」となります。
「クラウドプロバイダーを切り替えるには、インフラの再構築が必要です。AIネイティブのSaaSへの移行においても、同様の対応がますます求められるようになっています。」
AIコパイロットやアシスタントは、単にタスクをこなすだけではありません。それらは人々の働き方を根本から変えるのです。営業チームが12か月間、フォローアップメールの下書き作成、取引リスクの指摘、次のアクションの提案といった業務をAIと共に行うと、メンバーはそのAIの出力結果に基づいて業務の習慣を再構築していきます。その際の切り替えコストは、もはや技術的なものだけではありません。それは行動面や組織面におけるコストでもあるのです。
これは、データ移行よりも定量化が難しいものの、潜在的にはより重大なロックインの一形態です。ワークフローが変更されるたびに、従業員の生産性は低下します。その変更が、長年にわたり共に進化してきたAIシステムの解体を伴う場合、その生産性の低下は深刻かつ長期にわたり、元に戻すことも困難です。
3つ目にして、最も過小評価されがちな要因は、モデルへの依存です。AIエージェントが契約書の作成、カスタマーサポートの優先順位付け、財務予測の生成といった重要な意思決定を行う際、組織はソフトウェアプラットフォームだけでなく、特定のモデルの挙動、調整、推論パターンにも依存することになります。
チームは特定のモデルの出力結果を信頼するようになります。プロセスはそのモデルのエラー率やエッジケースに基づいて構築されます。ガバナンスの枠組みも、そのモデルの特有の傾向に合わせて調整されています。そのモデルが更新されたとき、あるいは挙動の異なる競合他社のモデルへの切り替えを検討するとき、単にソフトウェアを変更するだけではありません。組織が頼りにするようになった意思決定に、体系的な不確実性が持ち込まれることになるのです。
調達の実情
一見、CRMの更新契約のように見えるものも、実は今後5年間にわたり顧客関係を管理するAIをどの製品にするかという決定なのです。一見、サポートプラットフォームの契約のように見えるものも、実は顧客に対して自社ブランドをどのように表現するかという決定なのです。契約書の文言がまだ追いついていないとしても、その時間軸はインフラの時間軸なのです。
この変化を認識することが第一歩です。これに対応するためには、調達、財務、技術の各チームが、AIを活用したSaaSとの関係をどのように捉えるかを見直す必要があります。その取り組みは、導入後ではなく、契約交渉の段階から始めるべきです。
契約には、インフラレベルにふさわしい条項が必要である
データの移植性、モデルの透明性、そして実質的なSLAについては、かつてデータセンター契約に対して組織が求めていたのと同じ厳格さで交渉すべきです。つまり、データだけでなく、トレーニング成果物、モデル構成、統合ロジックについても、エクスポートに関する明確な条項を設ける必要があります。また、ベンダーのAIシステムを改善するためにデータがどのように使用されるかについて、監査権限を確保することも求められます。さらに、SLAではプラットフォームの稼働時間だけでなく、AIの出力の品質と一貫性も対象とすべきです。
ベンダー評価は上流工程まで視野に入れる必要がある
現在、AIネイティブのSaaSベンダーを評価するとは、単に現在の機能セットだけでなく、そのAIプロバイダー、モデルの更新方針、データガバナンスの実践、そして製品ロードマップを評価することを意味します。更新サイクルが頻繁なプロバイダーの基盤モデルを採用しているベンダーは、モデルバージョンの安定性を提供するベンダーとは異なるリスクプロファイルをもたらします。こうした質問は、導入後のレビューではなく、RFP(提案依頼書)に記載すべきものです。
「総退出コスト」が新たな指標となる
依然としてSaaSをライセンス費用や機能適合性だけで評価している調達チームは、最大のリスク要因を見落としている。AI時代において重要な指標は「総退出コスト」である。これは、データ移行、スタッフの再教育、プロセスの再構築、そしてAIの出力結果に現在組み込まれている組織的知見など、ベンダーから離脱する際に生じる経済的コストの総和を指す。契約更新後ではなく、契約締結前にこの数値を算定しておくことこそが、洗練されたバイヤーとそれ以外のバイヤーを分ける重要な姿勢である。
ガバナンスはAIの行動にも及ばなければならない
AIが重大な影響を及ぼす推奨を行う場合、責任の所在という問題は自然に解決されるものではない。契約書にはモデルのバージョン管理に関する約束を明記すべきであり、そうすることで組織は、意思決定の基盤となるAIがいつ変更されるかを把握できるようになる。また、定められた閾値を超える意思決定については、人間による上書き義務を盛り込むべきである。さらに、AIによる意思決定に対する監視がますます厳しくなる分野において、規制遵守を支えるのに十分な強固な監査権限を確立すべきである。
「AI-SaaSを最初からインフラとして位置づける組織は、より有利な条件で契約を結ぶことができ、より強靭なシステム構成を構築し、新たなベンダー依存を回避できるだろう。」
これらは決してAI導入に反対する論拠ではありません。生産性の向上は確実であり、競争上の優位性はさらに拡大しています。他社がAIを大規模に導入する中、傍観している組織は、別の形で代償を払うことになるでしょう。
しかし、導入と意図的な取り組みは相反するものではありません。現在AIで成功を収めている組織は、コミットメントを避けているわけではありません。むしろ、最初からベンダーとの関係にインフラレベルの厳格さを適用し、意図的にコミットメントを確立しているのです。彼らは、移行する価値のあるデータをまだ生成していない段階で、データの移植性について交渉しています。また、特定のベンダーに縛られる前に、乗り換えコストをモデル化しています。さらに、AIがワークフローに組み込まれる前に、モデルガバナンスについて厳しい問いを投げかけているのです。
苦境に立たされるのは、AIの導入を急ぎすぎた組織ではない。むしろ、サブスクリプション型のスピードで進めながら、その取り組みがいつの間にかインフラ規模へとシフトしてしまった組織である。
次回のSaaS契約更新は、単なるソフトウェア契約ではありません。それは5年先を見据えたアーキテクチャ上の決定なのです。あなたのチームは、それをそのように捉えていますか?
| 検討事項 | サブスクリプション時代のSaaS | AI時代のSaaS |
|---|---|---|
| ロックイン式 | 機能とワークフローの依存関係 | データの集積 + モデルへの依存 |
| 切り替えコスト | 低 – 移行にかかる週数 | 多忙な時期、データ移行、再教育 |
| 契約期間 | 通常、1~2年の任期 | 3~5年の契約が相次いでいる |
| 価値の源泉 | ソフトウェア機能の利用 | 蓄積されたコンテキストとAIの出力品質 |
| ベンダー評価 | 機能一覧と価格 | AIプロバイダー、モデルポリシー、データ取り扱い |
| 出口指標 | ソフトウェアの入れ替えにかかる費用 | 総費用:データ、再トレーニング、プロセスの再構築 |
| ガバナンスの必要性 | SLAおよび稼働率 | モデルのバージョン管理、監査権限、ポリシーの上書き |
| 調達枠 | 購入・キャンセルの柔軟性 | インフラグレードのコミットメント |
AI機能を備えたSaaS契約に署名または更新を行う前に、チームは以下の質問に答えられるようにしておく必要があります。