汎用SaaSの固定費を見直す、内製化の判断軸

2026年9月5日：計算条件を十分に示せていなかった業種別の効果試算と、その参照表現を削除しました。自社の導入実績を示すものではありません。

企業のIT支出のなかで、汎用SaaSの利用料は年々存在感を増しています。1つひとつは月数万円でも、部門ごとの契約が積み重なれば、年間では無視できない固定費になります。やっかいなのは、この費用が解約されにくいことです。「業務に組み込まれているから」という理由で利用実態を検証されないまま、自動更新が続いていきます。本稿では、なぜ汎用SaaSの固定費が下がりにくいのかを構造から分解し、内製への置き換えでどこまで下げられるのか、そして置き換えてはいけない領域はどこかまでを、実務の順序に沿って整理します。

固定費が下がらない3つの構造

• 席数課金：実際に使っている人数ではなく、配布した人数分を払い続けている
• 機能の過剰：必要なのは一部の機能なのに、パッケージ全体・上位プランの料金を払っている
• 分散契約：部門ごとに似た用途のツールを別々に契約し、全社では重複している

これらは担当者の怠慢ではなく、汎用SaaSというビジネスモデルの構造から生まれます。SaaSは「あらゆる会社に売るための機能」を抱えており、その開発コストが価格に乗っています。自社が使うのはその一部でも、支払いは全体に対して発生します。

私たちの支援の現場でよく見るのは、契約更新のたびに「使っているか」ではなく「解約して困らないか」だけで判断してしまう失敗です。困らないと言い切るには利用ログを確認する必要がありますが、そこまで踏み込まないと、休眠席や重複契約はそのまま温存されます。棚卸しの最初の対象を「不安だから残している契約」に定めると、削減余地が見えやすくなります。

まず現在の費用と内製後の総コストを比較する

内製化で費用が下がるかどうかは、総コストを見積もって判断します。手順はシンプルで、まず現在の年間コストを、席数×単価×12ヶ月で洗い出します。そこに、実際にログインしている席数と、配布したまま使われていない席数の内訳を重ねます。次に、内製した場合にかかる開発の初期投資と、月々の運用コスト（インフラ・保守）を見積もります。

比較の軸は2つです。1つは、年間の固定費が内製後にどれだけ小さくなるか。もう1つは、初期投資を何ヶ月で回収できるかです。回収後は運用コストだけが残るため、そこからが構造的にコストの下がる領域になります。内製にも開発・セキュリティ・保守・更新の費用がかかるため、少人数で標準機能を使い切っている場合はSaaSの継続が合理的なこともあります。この見立てを先に立てておくことが、どの契約から着手するかの判断基準になります。

内製化で費用構造はどう変わるか

この構造を逆手に取るのが内製化です。内製であれば自社に必要な機能だけを実装すればよく、席数課金からも解放されます。使う人数が倍になっても、利用料が倍になることはありません。

かつて内製は「高くつく選択肢」でした。生成AIとオープン技術の進化で、その前提が変わっています。鍵は、ゼロから作らないことです。開発済みのモジュールと最先端のオープン技術を組み合わせれば、汎用SaaSが提供してきた機能の相当部分を、より軽い構造で実装できます。開発の初期投資はかかりますが、毎月の利用料という固定費が消えるため、一定期間で回収し、以降はコストが構造的に下がります。

どの契約から手をつけるか

すべての契約が置き換えの候補になるわけではありません。優先度が高いのは、席数課金の比率が大きく、使っている機能が一部に偏っている契約です。反対に、少人数で全機能を使い切っている契約は、置き換えても削減幅が小さいため、後回しでかまいません。ここで無理をして効果の薄い契約から着手すると、労力の割に数字が動かず、社内の熱が冷めてしまいます。

もう1つの物差しは、その業務が自社の差別化に関わるかどうかです。差別化に直結する業務ほど、汎用SaaSの標準機能では細部が噛み合わず、内製で自社の型に合わせる価値が出ます。残すか置き換えるかで迷うときの整理は内製とSaaSの判断フレームにまとめています。

進め方：診断 → 試算 → 段階的置換

• 活用度診断：契約中のツール・席数・年間費用と、実際の利用状況を棚卸しする（進め方は活用度診断のはじめ方を参照）
• 置換試算：内製した場合の開発・運用コストと、削減できる利用料・回収期間を比較する
• 段階的置換：影響範囲の小さい業務から置き換え、検証しながら対象を広げる

いきなり基幹業務から着手する必要はありません。まず1つのツールで、置き換えても業務が回ることと、試算どおりにコストが下がることを確認します。この最初の1件は、失敗しても影響が小さく、かつ削減効果が数字で見えやすいものを選ぶのが定石です。実績を数字で示せれば、次の置き換えに向けた社内合意が格段に取りやすくなります。逆に、検証を飛ばして複数のツールを同時に切り替えると、問題が起きたときにどの置き換えが原因かを切り分けられなくなります。

すべてを内製すべきではない

注意点も明確にしておきます。内製には保守・セキュリティ・運用の責任が伴い、担当者への依存という新たな属人化リスクも生まれます。会計や労務のように標準化が進んだ領域、法改正への追従が頻繁で外部に任せたほうが安全な領域は、SaaSのままでよいケースが多いです。

よくある失敗は、削減額の大きさだけを見て基幹業務からいきなり内製に踏み込み、保守できる体制がないまま運用が回らなくなることです。置き換えの判断は、削減額と、それを維持する体制の両方で見ます。作る前に、誰が直し、誰が更新し、担当者が抜けたときにどう引き継ぐかを決めておくこと。これが、内製を一時的な節約ではなく、固定費削減として定着させる条件になります。

まとめ

汎用SaaSの固定費は、席数課金・機能の過剰・分散契約という構造から下がりにくくなっています。内製はこの構造を組み替える打ち手ですが、効くのは全置換ではなく、差別化や高コストの領域を選んで切り替えたときです。判断の出発点は、契約と利用実態を数字にすることにあります。どの契約から手をつけると回収が早いかを一緒に見極めたい方は、無料相談から現状の棚卸しをご相談ください。