道具の壁：SaaSのAI化の限界

既存SaaSにAI機能を足すだけでは、業務再設計には届かない

経営層が動き、現場の地ならしも進んだ。市販されているAI機能付きSaaSを次々に導入すれば、それで業務は変わるのでしょうか。

残念ながら、答えは「いいえ」に近い。

ここに三つ目の壁があります。

SaaS搭載型のAIには、業務横断の事業KPIに責任を持つ主体になりにくいという、構造的な限界がある、という壁です。技術的に、別SaaSのデータを読むこと自体は不可能ではありません。API連携、Data Cloud、iPaaS、カスタム連携を組めば、データを参照させることはできます。

論点は技術的な接続可能性ではなく、誰がSaaSの境界を越えて事業KPIに責任を持つのか、にあります。

各SaaS搭載AIは、自社SaaSの中で最適化される

CRMに搭載されたAIは、CRM内の営業支援に強みを発揮します。商談履歴を要約し、次のアクションを提案し、顧客スコアを算出する。MAツールに搭載されたAIは、配信タイミングの最適化、件名のA/Bテスト、リードのナーチャリング設計が得意です。CSツールのAIなら、FAQマッチングや一次返信の自動化に力を発揮するでしょう。

それぞれは、その範囲では確かに役に立ちます。 ただし、それぞれのAIは、各SaaSの体験、データ、収益モデルの内側で最適化されています。Salesforceの中で最適化されたAIは、自社のARPU向上やプラットフォーム回帰を促す方向に進化します。HubSpotの中のAIも同様です。

事業KPIから逆算して複数SaaSを横断し、業務全体の責任を負う主語にはなりにくい。

これは技術論ではなく、誰の目的関数で動いているかという、ガバナンスの話です。

業務は、複数SaaSの境界を意識せずに動いている

なぜこれが致命的かというと、実際の事業活動は、SaaSの境界を意識せずに動いているからです。

ある顧客がGoogle広告から流入してLPに着地し、フォームから問い合わせる。CRMに登録され、MAでナーチャリングされ、Zoomで商談し、契約管理ツールでサインし、CSツールでサポートを受ける。この間、顧客は一度も「どのSaaSの中の話か」を意識していません。

ところが、企業側の道具はSaaSごとに分断されています。

事業成果は、この一連の流れの中で生まれます。CVRが上がるかどうかは、CRMだけでも、LPだけでも決まりません。広告のターゲティングが甘いままCRMだけをAI化しても効きません。LPが分かりにくいまま、チャットボットだけをAI化しても、問い合わせ数は伸びません。

事業成果を出すには、複数SaaSを横断して業務を見る必要があり、なおかつ、その横断に責任を持つ主体が必要です。

SaaS搭載型AIは、構造的にその主体にはなりにくい。

「AI機能付きSaaS」を増やすほど、部分最適は深まる

ここで起きる事態は、しばしば直感に反します。

各SaaSがそれぞれにAI機能を載せる。CRMの中では営業が便利になり、MAではメール配信が便利になり、CSでは問い合わせ対応が便利になる。それぞれの部署では「AIで楽になった」という声が上がります。

ところが、事業全体のKPIは思ったほど動かない。

なぜか。

それぞれのAIが自社SaaS内で局所最適を進めているからです。

データ連携の複雑性は増し、各SaaSの仕様変更ごとに整合性を取り直す必要が出る。AIによる自動化が増えるほど、サイロも深くなる。

部分最適の集合は全体最適にはなりません。

業務単位のAI化は、SaaSの外から設計する必要がある

ここから導かれる結論はシンプルです。

業務設計の主語は、SaaSではなく業務そのものです。

事業KPIから逆算して業務を分解し、その実現に必要なAIエージェントを構成する。既存のSaaSは、データソースや実行基盤として活用する対象に位置づけ直します。SaaSをSystem of Recordとして活かしつつ、その上で業務を実行し成果に責任を持つOutcome Layerを、私たちが担う。

これが、本書を貫く構造です。

ここまで、経営、現場、道具の三つの壁を見てきました。

次節では、これらを乗り越える正しい順序、すなわち「業務再定義から始める」というアプローチに進みます。