「運用でカバー」が限界に来て、解約の話が出た
最近ご一緒したある企業グループで、利用中のCRM(顧客・商談管理のSaaS)を解約する議論が持ち上がりました。きっかけは、売上見込みの管理です。
このグループは、専門分野ごとに会社が分かれ、プロジェクト単位で会計をしています。商談は各社が自社のものとして管理していますが、受注後の役務提供では、グループ内の他社のメンバーを起用することがよくあります。売上は、参画したメンバーの所属会社にそれぞれ計上されます。
ところが、CRMの商談パイプラインは案件の総額でしか管理できませんでした。案件総額で見込みを出すと、他社に計上されるはずの売上まで、商談を持っている会社の見込みに入ってしまいます。会社別の見込みが正しく出ないのです。商談を会社ごとの明細に分けて登録する、という運用での回避策も検討されましたが、入力と管理が煩雑すぎるとして採用されませんでした。
道具が悪いわけではありません。そのCRMは、1つの商談が1つの会社の売上になる、という標準的な前提で作られています。このグループの売上の立ち方が、その前提に合っていなかったのです。標準SaaSを使うか、自社専用に作るか。この判断は、こうした「前提のずれ」をどう見極めるかに尽きます。
判断の全体像:5つの軸
判断の軸は5つあります。中心になるのは1つ目の「自社固有の要件」で、ここだけは3段階の問いで構成されます。残りの4つは、その結論を補強したり、覆したりする軸です。
- 01中心の軸
自社固有の要件
要件があるか。あるなら、業務への影響は大きいか、運用で回避できるか
- 02影響の広がり
業務への組み込みの深さ
日々の業務や他のシステムと、どれだけ密接につながっているか
- 03保守
制度改正への追随
法改正の多い業務か。誰がどう追い続けるか
- 04費用
総コストと体制
数年間の利用料と、開発・保守の費用と担い手を比べる
- 05これから
AIエージェントからの操作性
外部のAIエージェントが参照・編集できるか
軸1:自社固有の要件(3段階で考える)
出発点は単純です。その業務に、自社固有の要件があるか。なければ、標準のSaaSをそのまま使うのが正解です。SaaSは、多くの会社に共通する業務の進め方を1つの製品にまとめたものです。自社の業務がその「共通の型」に収まるなら、他社の知恵と継続的な改善をそのまま受け取れます。
固有の要件が「ある」ときにだけ、次の2つの問いに進みます。
固有の要件はあるか
標準の前提と自社の実態のずれを具体的に特定する。なければSaaSで決まり
業務への影響は大きいか
ずれが経営判断の数字や顧客対応を歪めるか。小さければSaaSのまま
運用で回避できるか
設定や入力ルールで吸収でき、現場が続けられるか。できなければ自社専用を検討
- 01
固有の要件はあるか
標準の前提と自社の実態のずれを具体的に特定する。なければSaaSで決まり
- 02
業務への影響は大きいか
ずれが経営判断の数字や顧客対応を歪めるか。小さければSaaSのまま
- 03
運用で回避できるか
設定や入力ルールで吸収でき、現場が続けられるか。できなければ自社専用を検討
固有の要件はあるか。 「使いにくい」という感想ではなく、ずれを具体的に特定します。冒頭の例なら、「1商談が1社の売上になる前提に対し、当社は1商談の売上が複数社に分かれる」というレベルです。
業務への影響は大きいか。 いちばん重い問いです。ずれが画面の見た目や入力の手間にとどまるなら、SaaSのままで構いません。会社別の売上見込みのように、経営判断に使う数字が歪むなら、影響は大きいと判断します。
運用で回避できるか。 設定の変更、入力ルール、補助的な表計算で吸収できるなら、それが最も安上がりです。ただし、現場が続けられる手間であることが条件です。回避策が煩雑で、結局Excelでの二重管理になるなら、回避できているとは言えません。
3つとも当てはまる、つまり固有の要件があり、影響が大きく、運用で回避できない。このとき初めて、自社専用に作ることが有力な選択肢になります。
軸2:業務への組み込みの深さ
次に見るのは、そのシステムが日々の業務や他のシステムと、どれだけ密接につながっているかです。この軸は、2つの方向に効きます。
1つは、合わないときの影響の広がりです。受注から請求、売上計上、見込み管理まで、多くの工程の起点になっているシステムほど、標準の前提とのずれが下流の業務すべてに波及します。業務の中心にあるシステムほど、自社に合っていることの価値は大きくなります。
もう1つは、置き換えの難しさです。深く組み込まれたシステムは、データの移行、他システムとの連携の作り直し、利用者の習熟と、切り替えの負担も大きくなります。逆に、落とし物の管理のように他の業務から独立している領域は、標準のSaaSをそのまま入れやすく、入れ替えも容易です。
軸3:制度改正への追随
給与計算、税務申告、電子帳簿保存法のように、法改正への対応が欠かせない業務があります。これまでは、ここがSaaSを選ぶ最大の理由でした。自社専用に作ると、改正のたびに自分たちで直し続ける責任を負うからです。
ただ、この前提は変わりつつあります。制度改正の情報をAIエージェントに継続して確認させ、影響する箇所を洗い出し、改修まで進める。プロダクトを作ること自体が容易になったいま、制度改正への追随も、以前ほど重い負担ではなくなってきました。「法改正があるからSaaS一択」とは言い切れなくなっている、というのが私たちの見立てです。もちろん、改正内容の解釈と最終確認は、引き続き人の仕事です。
軸4:総コストと体制
SaaSの利用料は、利用者数と年数で積み上がります。自社専用は、開発費に加えて保守の費用と担い手が要ります。数年単位で両方を並べ、誰が面倒を見るのかまで含めて比べます。
ここも、この1〜2年で分岐点が動いた軸です。AIエージェントを使った開発によって、業務アプリを作る費用と期間は大きく下がりました。以前なら「固有の要件はあるが、作るほどではない」と運用で我慢していた領域が、作る選択肢に入ってきています。
軸5:AIエージェントからの操作性
最後は、これから重みが増す軸です。業務は、人が画面を操作する形から、AIエージェントが複数のシステムをまたいで参照し、入力し、処理を進める形に近づいていきます。そのとき、外部のAIエージェントからデータの参照と編集ができるか。MCP(AIエージェントがシステムに接続するための共通の仕組み)などへの対応状況を確認します。
いまのSaaSの多くは、人が画面から操作する前提で作られています。データの参照だけでなく編集まで、外部のAIエージェントに開放しているSaaSは、まだごく限られます。AIエージェントに仕事を任せたい会社にとって、外から操作できないシステムは足かせになります。
残るSaaS、置き換えが進みうるSaaS
「これからはAIで何でも作れるからSaaSは要らなくなる」という声も聞きますが、私たちはそうは考えていません。固有の要件が限定的で、みんなが同じものを使うこと自体に価値がある領域では、SaaSは強いままです。
分かりやすい例が、株式会社find が提供する落とし物クラウド「find」です。鉄道会社、商業施設、空港といった施設側の法人が利用するサービスで、落とし物の登録と管理、利用者からの問い合わせ対応を担います。公表情報では、2025年4月時点で29社・約2,300か所に導入され、その後も鉄道や百貨店、航空会社への導入が続いています。
落とし物の管理は、どの施設でもやることがほぼ同じで、会社ごとの固有要件は限られます。他の業務からも独立しています。そのうえ、導入企業をまたいで落とし物を探せる「横断検索」のように、利用する会社が増えるほど便利になる仕組みがあります。これは、1社が自社専用に作っても決して手に入らない価値です。5つの軸のどれで見ても、SaaSであることに理由がある。見事なビジネスモデルだと思いますし、今後も残っていくはずです。
一方で、経費精算、請求書の受領、給与計算、税務申告といった経理・財務の領域では、一部で置き換えが進む可能性があると見ています。多くの会社で進め方が共通し、法改正への追随が重いこれらの業務は、これまで標準SaaSの得意分野でした。しかし、軸3で見たように制度改正への追随は以前ほどの壁ではなくなり、軸4の開発費用は下がり、軸5のAIエージェントからの操作には多くのSaaSがまだ対応できていません。SaaSの側が対応を進めるか、AIエージェントが操作する前提で作られた新しい仕組みに置き換わるか。この数年で分かれていくと考えています。
グループ経営、プロジェクト単位の採算管理、会社をまたぐ売上の配分のように、会社の「組織の形」と「数字の持ち方」に根ざした要件を持つ業務は、なおさらです。冒頭のCRMの例や、以前の記事で取り上げた予算は勘定科目×施策明細で作るのに実績が施策で追えない例は、まさに軸1の3つの問いすべてに当てはまるケースでした。
落とし穴
どちらを選ぶ場合も、気をつけたい点があります。
まず押さえておきたいのは、AIエージェントで下がったのは「最初に作る費用」であって、作った後の責任は変わっていないことです。障害への対応、セキュリティ対策、内部統制や監査での説明。SaaSであれば提供会社が担っていたこれらは、自社専用にした瞬間に自社の責任になります。決算の数字や給与に関わる仕組みであれば、正しさを誰が保証するのかを、作る前に決めておく必要があります。安く作れることと、安心して持ち続けられることは別の話です。
- 自社専用の保守を軽く見ない。 作って終わりではありません。仕様を文書に残し、担当者が変わっても直せる状態を保つ必要があります。AIエージェントで作ったものほど、作った経緯と判断を記録しておくことが大切です。
- 解約時のデータを先に確認する。 SaaSを離れるとき、過去のデータをどの形式で取り出せるか。契約の更新時期と合わせて、判断の前に確かめておきます。
- 「使いこなせていないだけ」を除外する。 課題の原因が、設定の不備や入力ルールの不徹底であることも少なくありません。作り直す前に、標準機能で解決できないかを一度は疑います。
まとめ
標準SaaSか自社専用かは、好みではなく軸で決められます。中心は自社固有の要件で、要件がなければSaaSをそのまま使う。要件があるなら、業務への影響の大きさと、運用で回避できるかを確かめる。そこに、業務への組み込みの深さ、制度改正への追随、総コストと体制、AIエージェントからの操作性を重ねて判断します。みんなが同じものを使うことに価値がある領域のSaaSは、これからも強いままでしょう。一方で、作る費用が下がり、AIエージェントが業務を担うようになるにつれて、自社専用を選ぶ理由のある領域は広がっていくと考えています。
自社のどの業務が「標準で足りる」のか、どこに「前提のずれ」があるのか。整理の段階からご相談いただけます。お問い合わせからご連絡ください。
参考資料
- 株式会社find 公式サイトおよびプレスリリース(落とし物クラウド「find」の導入状況。2025年4月時点の導入数ほか)
- Huberitus Insights「予算は『勘定科目×施策明細』で作れるのに、実績が施策で追えない理由」
本記事は一般的な情報提供を目的としたものであり、個別のシステム選定や契約判断については専門家にご相談ください。記事中の事例は複数の支援経験をもとに一般化したもので、特定の企業を示すものではありません。他社サービスに関する記述は執筆時点(2026年11月)の公開情報に基づきます。