高額SaaSを解約して内製化すべきか｜生成AI時代の判断基準7つ

こんにちは、株式会社TIMEWELLの濱本 隆太です。

SaaSの更新見積もりを開いて、去年より上がった金額を見たとき、「これなら自分たちで作ったほうが安いのではないか」と頭をよぎったことはないでしょうか。生成AIでコードを書く費用が下がったいま、その感覚は以前より現実味を帯びています。

先に私の立場を書いておきます。ほとんどのSaaSは、解約しないほうがいいと考えています。会計や給与のように法令に縛られた業務は、今でもSaaSに任せるのが合理的です。ただし、利用者の数に比例して課金され、機能の変化が遅く、仕組みが単純な業務に限っては、作り直す価値が出てきました。難しいのは、その「限っては」の線をどこに引くかです。

この記事は、すでに払っている高額なSaaSを解約して自前で作るべきかを判断するための、7つの基準をまとめたものです。全5本のシリーズの1本目にあたり、候補の選び方、5年総額の試算、解約と移行の実務、自社クラウドに置く設計を、それぞれ別の記事で掘り下げています。AI活用のどこまでを社内に置くかという、もっと広い分界の話はAIの内製化はどこまで自社でやるかに書きました。こちらは「いま払っているSaaSをやめるか」の一点に絞ります。

「作ったほうが安い」と感じ始める理由

SaaSの費用が膨らんで見える理由は、大きく二つあります。価格そのものの上昇と、円安です。

価格の例を一つ挙げます。海外大手のソフトウェア会社の日本法人は、2024年4月1日から法人向けのソフトウェアとクラウドサービスの円建て価格を一律20％引き上げました。あわせて、今後も米ドルに対する為替変動を考慮し、年2回の定期的な価格評価の一環として現地通貨建ての価格を調整する場合がある、としています¹。円で払うSaaSの価格は、ドル建ての定価の改定と、円建て価格の見直しという二つの経路で動くわけです。

円相場も見ておきます。日本銀行が公表している月中平均を暦年ごとに平均すると、2020年の1ドル106.78円に対し、2024年は151.50円、2026年1月から8月は158.78円でした（日銀の統計から私が算出）²。2020年と比べて4割以上の円安です。ドル建てで値付けされたサービスは、こちらが何もしなくても円の請求額が上がっていきます。

企業の側もこれを実感しています。日本情報システム・ユーザー協会（JUAS）の2026年版の調査では、IT予算が増える理由の2位が「円安・人件費高騰・ベンダー提供価格の値上げなどによる影響」で、2025年度計画で46.6％の企業が挙げました³。同じ調査で、システム開発の内製化に期待する効果の1位は「開発コスト削減」（41.3％）となり、前年1位の「社内へのナレッジ蓄積による開発能力向上」を上回っています。報告書は、著しいベンダーの価格高騰を受けて「目の前のコスト削減の優先度が急速に高まった」と推察しています³。

そこへ生成AIが来ました。海外の開発ツール会社が自社の利用者817人に行った調査（2026年2月発表）では、35％が少なくとも1つのSaaSを自作のツールに置き換えたと答えています。ただ、回答者はもともと作るための道具を使っている人たちなので、世の中の平均より作る方向に偏っているはずです。

象徴的に語られるのが、スウェーデンの決済会社Klarnaです。大手CRMの利用をやめたことが話題になり、AIがSaaSを置き換えたという受け止め方が広がりました。ところがCEOのSebastian Siemiatkowski氏本人は、2025年3月のX（旧Twitter）への投稿で、社内の推計で約1,200のSaaSを止めたと書く一方、SaaSをLLMで置き換えたわけではなく、CRMのデータをLLMに保存するのには限界がある、と明言しています⁴。実際にやったのは、Neo4jなどを使ってデータを知識としてまとめる社内の技術基盤づくりでした。そのうえで「すべての会社がKlarnaと同じことをするだろうか。私は疑わしいと思う」とも書いています⁵。

私はこの説明が、いちばん参考になると思っています。SaaSをやめられたのは、AIが画面を作ってくれたからではありません。ばらばらのSaaSに散っていたデータを、先にひとつにまとめたからです。画面はあとからいくらでも作れます。データがまとまらないまま解約だけ進めると、同じ仕事をする道具を社内に増やしただけで終わりかねません。

それでも、基本はSaaSを使い続けるほうが正しい

主張を弱める材料を、先に並べておきます。隠して書くと、読む方の判断を誤らせるからです。

まず、公的な指針ははっきりSaaS寄りです。経済産業省のDXレポート2（2020年12月）は、企業は協調領域について「自前主義を排し」、業務プロセスの標準化を進めてSaaSやパッケージを活用し、IT投資の予算と人材の投入を抑えるべきだと書いています⁶。デジタル庁が政府情報システム向けに定めたDS-310（2025年5月）も、SaaSは開発量を減らせるので、幅広く優先的に利用を検討するよう求めています⁷。

日本企業の実態も同じ方向です。IPA（情報処理推進機構）の「DX動向2025」によると、ノンコア・非競争領域のシステムの調達手段は「パッケージソフトウェアの導入」が33.8％、「SaaSの導入」が24.4％で、「内製による自社開発」は16.6％でした。システム開発の内製化を「進めている」企業は日本で22.3％、米国では46.4％です。そして、内製化を進めている日本企業の82.3％が「人材の確保や育成が難しい」を課題に挙げています⁸。

生成AIで開発が速くなるという話にも、留保がつきます。米国の研究機関METRが、経験豊富なオープンソース開発者16人と実際の課題246件で行ったランダム化比較試験では、AIを使える条件のほうが作業時間が19％長くなりました。開発者自身は事前に24％速くなると予想し、終わったあとも20％速くなったと感じていたそうです⁹。2026年2月の続報では、2025年末のツールで所要時間が18％短くなったという推定が出ましたが、信頼区間はマイナス38％からプラス9％で、ゼロをまたいでいます¹⁰。約5,000人を対象にしたDORAの2025年の調査は、AIの利用が開発のスループットと正の関係を持つ一方で、変更の安定性とは負の関係が続いていると報告しました¹¹。セキュリティ製品を提供するVeracodeの調査では、100を超えるLLMが生成したコードの45％がセキュリティ試験に通りませんでした¹²。

速く作れることと、安全に長く動かせることは、別の話です。SaaSの利用料には、この「長く動かす」ための費用が含まれています。

それでも解約の話をするのは、DS-310自身が例外を書いているからです。同じ文書は、SaaS利用は強く推奨されるものの無条件ではないとし、利用者数が段階的に増える場合など運用段階で利用料が高額になるケースでは、ライフサイクルコストの観点から本当にコスト削減になるかを慎重に評価するよう求めています。SaaSと同様の機能をほかのマネージドサービスで実現できるなら、両方式を比べて評価すべきだ、とも書いています。アカウント数に対して課金されるSaaSや高額なSaaSについては、利用アカウントの推移に十分注意するよう、別の箇所で念を押しています⁷。

この記事の主張は、この例外の範囲にとどめます。SaaSをやめろ、という話ではありません。例外に当たるものを見分け、当たったものだけ作り直しを検討しよう、という話です。

解約を検討してよいかを決める7つの基準

私が使っている7つの基準を、先に表で示します。どれか一つで決めるのではなく、並べて眺めるためのものです。

基準	見るもの	解約を検討してよいサイン	使い続けたほうがよいサイン
① 年額と値上げ幅	今の年額、過去の改定、為替の影響	年額が大きく、改定が続いている	年額が小さく、作る費用のほうが明らかに高い
② 利用者数とアカウント課金	課金の単位、利用者の増え方	1人ごとの課金で、利用者が増え続ける	定額制、または利用者がほぼ増えない
③ データと機能の変化の遅さ	項目や画面を変える頻度	数年ほぼ同じ項目と手順で回っている	毎月のように新機能を使っている
④ 法令・会計ルールの複雑さ	税制、会計基準、業法の改正への追随	法令の改正に振り回されない社内業務	会計、給与、税務申告など改正の多い業務
⑤ ほかのシステムとの連携	つないでいるシステムの数と向き	連携が少なく、データの出入り口が限られる	多数の外部サービスと双方向につながる
⑥ 保守を担う人と体制	直す人、使える時間、伴走先	担当者を決めて時間を確保でき、伴走先もいる	誰も担当できない、兼務の片手間しかない
⑦ 解約と移行の条件	更新日、通知期限、データの出し方	全データを使える形式で出せ、期限に余裕がある	通知期限が迫っている、出力できないデータがある

① 年額と、これからの値上げ幅

最初に見るのは、今いくら払っていて、これからいくらになりそうかです。当たり前に聞こえますが、請求書の年額は見ていても、過去5年の改定の履歴と為替の影響を並べて見ている会社は、それほど多くないように感じています。

見る数字は三つです。今の年額、過去の改定の頻度と幅、そしてドル建てのサービスなら為替の感応度。先ほどの例のように、年2回価格を見直すと表明しているサービスなら、1ドルが10円動いたときに年額がいくら変わるかを計算しておくと、稟議での議論が具体的になります。

反対に、年額が数十万円のSaaSを解約して作り直すのは、まず割に合いません。作る費用、保守する人の時間、サーバーの費用を足せば、解約で浮く金額をあっさり超えます。この基準は「解約してよい」を示すより、「検討する価値がない」をふるい落とすために使うのが実用的です。5年総額の具体的な試算の仕方は、シリーズ3本目のSaaSの5年総額を試算するで扱います。

② 利用者数の伸びと、アカウント課金

DS-310が名指しで注意を促しているのが、この基準です⁷。1人あたりの月額で課金されるSaaSは、会社が成長して利用者が増えるほど、機能は同じでも請求額が伸びていきます。

仮の数字で計算してみます。1人月額3,000円のSaaSを300人で使っていると、年額は1,080万円です。利用者が毎年20％増え、単価が毎年5％上がると仮定すると、5年目の利用者は約620人、年額は約2,720万円になり、5年間の合計は約9,040万円に達します。人数も単価も据え置きなら5年で5,400万円なので、差は約3,600万円です（いずれも当社の仮定による計算で、実際の単価や増え方は会社ごとに違います）。

作る側の費用は、利用者が倍になっても倍にはなりません。サーバーの費用は増えますが、1人ごとの課金とは増え方がまるで違います。社内ポータル、申請、台帳のように全社員が触る道具ほど、この差が効いてきます。総務省の令和7年の調査では、クラウドサービスを一部でも使う企業が83.5％で、使っている内容の2位が「社内情報共有・ポータル」（61.4％）でした¹³。全員が触る道具ほど、クラウドのサービスで賄われているわけです。

利用者がほとんど増えない会社や定額制の契約では、この基準は効きません。利用者数の見通しは、採用計画と並べて確かめてください。

③ データと機能の変化が遅いか

三つ目は、そのシステムがどれくらいの頻度で変わるかです。誤解しやすい基準なので、原典から確かめます。

ガートナーが2012年に示したペースレイヤーという考え方は、会社のシステムを変化の速さで三つの層に分けます。いちばん遅い層の「Systems of Record（記録のシステム）」について、原典は、中核の取引処理と重要なマスターデータを管理する既存のパッケージやシステムで、プロセスが確立していて多くの組織に共通し、しばしば規制要件の対象になるため、変化の速度が遅い、と説明しています¹⁴。つまり原典の立場では、変化が遅いものほど標準のパッケージで持つのが基本です。「変化が遅いから自前で作ってよい」と単純に言うと、原典と逆のことを言ってしまいます。

それでも変化の遅さを基準に入れているのは、もう一つの軸と組み合わせると使えるからです。その軸が次の④、法令や会計ルールによる複雑さです。変化が遅く、しかも仕組みが単純なもの。社内の台帳、FAQ、社内ポータル、申請の受付、見積の台帳といった業務は、一度作れば項目も手順も数年ほぼ変わりません。こうした業務では、SaaSの利用料の多くが、自社では使わない新機能の開発費を支えていることになります。

同じ原典は、同じアプリケーションでも会社によって属する層が違いうる、とも書いています¹⁴。ある会社にとってのただの台帳が、別の会社では競争力の源泉かもしれません。候補にする業務の見分け方は、シリーズ2本目の自前で作ってよい業務システムの見分け方で、データの更新頻度という当社の見立てを使って掘り下げています。なお、データの更新頻度を軸に作るか買うかを分けた公的な枠組みは、調べた範囲では見つかりませんでした。あくまで当社の見立てとして読んでください。

④ 法令・会計ルールの複雑さ

変化が遅く見えても、法令に縛られた業務は別扱いにします。会計、給与、税務申告、勤怠のように、税制改正や会計基準の変更に追随しなければならない業務です。

具体例を挙げます。2024年の定額減税では、給与所得者への減税は、原則として2024年6月1日以後に支払う給与等の源泉徴収税額から控除する方法で行われ、6月に控除しきれなかった分は同じ年の給与から順次控除することになりました¹⁵。給与計算を自前で持っていたら、この仕組みを税制改正から数か月のうちに実装して検証し、年末調整での精算まで確かめる必要があったわけです。SaaSの利用料には、こうした改正への追随の費用も含まれています。

生成AIでコードを書く速さが上がっても、改正の中身を読んで正しく解釈し、例外を洗い出す仕事は残ります。しかも間違えたときの影響は、社員の給与や税務申告に直接出ます。この種の業務は、SaaSやパッケージを使い続けるべきだと私は考えています。

線引きの目安は、「その業務のルールを決めているのは自社か、法令か」です。社内の申請の承認ルートは自社が決めます。給与の源泉徴収の計算は法令が決めます。前者は候補になりえますが、後者は原則として候補から外してください。

ただし、外すのは原本と法定の処理だけです。同じ会計や人事労務のSaaSでも、全社員が触る申請の画面や集計は自社が決める部分です。そこを自前で作り、データはSaaSにAPIで渡す形にすれば、SaaSのシートを経理や人事の担当者の分まで減らせることがあります。基準②のアカウント課金に効く手です。分け方と、契約で先に確かめる条項は、シリーズ2本目の自前で作ってよい業務システムの見分け方に書きました。

⑤ ほかのシステムとの連携がどれだけ多いか

五つ目は連携の数です。これは公的な指針ではなく私の見解ですが、作ったあとの保守の手間をいちばん左右するのは、ほかのシステムとのつながりだと感じています。

多くのSaaSは、シングルサインオン、会計、人事マスタ、チャット、メール、BIなどとつなぐ部品を持っていて、つなぎ先の仕様が変わったときの追随もベンダーが引き受けています。自前で作れば、この追随はすべて自社の仕事です。連携先が一つ増えるたびに、壊れうる場所が一つ増えると考えてください。

数え方は単純です。そのSaaSにデータを入れているシステムと、そのSaaSからデータを受け取っているシステムを全部書き出します。数が多く、しかも双方向に同期しているなら、作り直しの費用は画面の開発より、連携の開発と保守が大半を占めるはずです。社員が画面から入力し、出力は月に一度CSVで渡すだけ、という程度の出入り口なら、難しさはぐっと下がります。

Klarnaの話を思い出してください。やめられた理由は、データを先にまとめたことでした⁴。連携の多いSaaSを解約したいなら、先にデータの置き場所をまとめる設計が要ります。その設計は、シリーズ5本目の業務アプリを自社クラウドに置く設計で扱います。

⑥ 作ったあとを誰が保守するか

7つの中で、私がいちばん重く見ているのがこの基準です。作ることより、作ったあとを誰が直し続けるかのほうが、ずっと難しいからです。

国内の数字は厳しいものです。先ほどのIPAの調査では、内製化を進めている企業の82.3％が人材の確保や育成を課題に挙げ、19.5％が「外部開発したシステムの内製化への移行が難しい」と答えています⁸。IPAの2026年版でも、DXを推進する人材の量が「やや不足している」「大幅に不足している」と答えた企業は合計85.5％でした¹⁶。

海外でも、保守は最後まで残る課題です。米国の医療保険会社Curativeのフレッド・ターナーCEOは、年60万ドルのCRM契約を解約して社内のCRMを2か月で作ったと語る一方、保守は「間違いなく最も困難な課題の一つ」だと述べた、と報じられています¹⁷。作るのが速くなったぶん、保守の重さが目立つようになったとも言えそうです。

この基準で確かめる問いは三つあります。作ったシステムを直す担当者を、名前で1人決められるか。その人の時間を、週に何時間と明示して確保できるか。担当者が一人で抱えきれない変更や障害のときに、頼れる伴走先がいるか。三つに答えられないなら、解約はまだ早いと判断します。

ここで言う伴走先は、代わりに作って納める外注先のことではありません。社内の担当者が自分で直せるようになるまで、隣で一緒に作る相手です。DXレポート2も、ユーザー企業の内部人材ではすぐに対応できない技術について、ベンダーが内製開発への移行を支援し、伴走しながらスキルを移転することへのニーズが高まる、と書いています⁶。

⑦ 解約と移行の条件

最後は契約の条件です。ほかの条件がそろっていても、解約の手続きと移行の時期を誤ると、二重に払う期間が延びたり、データを失ったりします。

乗り換えの難しさは数字にも出ています。公正取引委員会が2022年に公表したクラウド分野の実態調査では、過去10年でクラウド事業者を切り替えた経験がある事業者は15.7％（548社のうち86社）にとどまりました。利用中のサービスが5〜10％値上げされた場合に切り替えると答えた事業者も、はっきり答えた中の14.1％程度です¹⁸。この設問の対象は主にIaaSやPaaSの利用者ですが、一度使い始めたクラウドからは出にくいという傾向ははっきりしています。

確かめる項目は、IPAの「中小企業のためのクラウドサービス安全利用の手引き」（2026年6月版）が利用終了時の確認事項に挙げているものが出発点になります。全データの返却やダウンロード、データの互換性と移植性、残ったデータの完全な消去、別の利用者が再利用できないことの保証です¹⁹。DS-310も、データの移行性が担保され、合理的な価格体系が公開されているサービスを選ぶことで、ベンダーロックインを避けるよう求めています⁷。

契約書では、三つの点を必ず見てください。自動更新の条件と解約の通知期限。ライセンス数を減らして一部だけ残す場合の単価の扱い。そして契約終了後、何日以内ならデータを取り出せるか。当社が確認した海外大手SaaSの基本契約（2026年9月版）では、注文書に別段の定めがない限り、満了の30日前までに通知しないと1年単位で自動更新されること、数量や期間を減らして更新すると前の単価にかかわらず価格を設定し直すこと、終了後30日以内に求めないとデータを保持する義務がなくなることが定められていました。一部を残せば安くなる、とは限らないのです。解約の段取りは、シリーズ4本目のSaaS解約と移行の実務で、更新日から逆算するスケジュールとして書いています。

7つの基準をどう使うか

7つを同じ重さで足し算すると、判断を誤ります。私は次の順番で使っています。

最初に、④と⑥で足切りをします。法令や会計ルールに強く縛られた業務は、ほかの基準がどれだけ解約寄りでも候補から外します。保守の担当者を名前で決められない業務も、いったん外します。この二つは、失敗したときの損失が大きく、しかも作ったあとにならないと表に出てこないからです。

足切りを通ったものについて、①と②で金額を見ます。5年でいくら払うことになりそうか、そのうちアカウント課金の伸びがどれだけを占めるか。作る費用と比べて差が小さければ、解約する理由はありません。差が大きいものだけが次に進みます。

次に、③と⑤で難しさを見ます。変化が遅く、連携が少ないものほど作り直しは易しく、作ったあとの保守も軽くなります。最後に⑦で時期を決めます。候補になっても、通知期限まで3か月しかないなら、その回の更新は見送り、次の更新に向けて準備するほうが安全です。

候補は一つに絞ってください。複数のSaaSを同時に解約しようとすると、移行の作業が重なり、並行稼働の期間に現場の負担が集中します。一つ目で段取りを覚え、保守が回ることを確かめてから、二つ目に進むのが現実的です。

シリーズの残り4本は、この順番に沿って読めるように書いています。

読む順	記事	扱うこと
1	自前で作ってよい業務システムの見分け方	基準③④をもとに、候補にする業務を選ぶ
2	SaaSの5年総額を試算する	基準①②をもとに、作る場合と使い続ける場合の総額を比べる
3	SaaS解約と移行の実務	基準⑦をもとに、通知期限、データの持ち出し、並行稼働を段取りする
4	業務アプリを自社クラウドに置く設計	基準⑤⑥をもとに、権限、データの所在、保守の体制を設計する

SaaSの解約と内製化を、FDEで進める

ここからは当社の話です。当社はFDE（Forward Deployed Engineer）というやり方で、この判断から作り直し、移行、社内での自走までを一緒に進めています。FDEは、顧客の現場に入り、隣に座って開発と実装を担うエンジニアのことです。どんな仕事なのかはFDEとは何かに詳しく書きました。

当社のFDEでできること

まず、いま使っているSaaSを棚卸しし、この記事の7つの基準で候補を一つに絞ります。年額、課金の単位、利用者数の推移、連携先、契約の更新日と通知期限を一覧にし、足切りに当たるものは「残すべきです」と正直にお伝えします。

候補が決まったら、個人情報などを伏せた実際のデータで動く試作を、最初の週のうちに見ていただきます。仕様書が固まるのを待たず、現場の担当者に触ってもらい、「今の業務とどこが違うか」を聞いて翌日に直します。この往復を続けると、SaaSのどの機能が本当に使われていて、どれが使われていないかが見えてきます。

そのうえで並行稼働の期間を決め、データを移し、解約の通知を出す時期を更新日から逆算します。期間は最初に45日から90日で区切り、終わりの条件を「社内の担当者が自分で直せる状態になっていること」と決めてから始めます。

AIの使い方にも一つ約束があります。当社は、処理に使うクラウドサービスやAIモデルを、顧客のデータを学習に使わないものだけから選びます。どこで処理するかは、要件と費用の釣り合いを見て案件ごとに設計します。情報セキュリティの管理体制では、ISO/IEC 27001の認証を取得しています（登録範囲はAIテクノロジーを活用したSaaSプロダクトの企画・開発・提供）。

進め方と体制の詳細は、FDEのサービスページにまとめています。

受託開発との違い

SaaSを解約して、その代わりを受託開発で作り直すと何が起きるでしょうか。作ったシステムの中身を知っているのは受託先だけになり、変更のたびに見積もりと発注が要ります。SaaSのロックインから抜けたつもりが、受託先の保守契約という別のロックインに入っていた、という結果は避けたいところです。

当社のFDEは、この点で受託開発と組み立てが違います。一つは工数の意味です。受託開発では工数が売上なので、長くいるほど得になります。当社はFDEの工数を投資と位置づけ、顧客ごとの工数が減っていくことをよしとしています。二つ目は、得たノウハウの行き先です。他社でも使える共通の仕組みは当社の製品の機能に返し、次の案件を速く、安くするために使います。その会社だけの手順や業務の用語は、その会社のものとして残します。三つ目は終わり方です。検収して終わるのではなく、社内の担当者が自分で直せるようになった時点で当社は離れます。基準⑥の「保守を担う人」を、作る過程で社内に育てるところまでを仕事に含めている、ということです。

当社の実践と限界

正直に書きます。この進め方が合わない会社や業務もあります。

会計、給与、税務申告のように法令に縛られた業務のSaaSは、解約のご相談をいただいても、当社は作り直しを勧めません。基準④のとおり、改正への追随の費用まで含めればSaaSのほうが安く、安全だからです。ERPの中核のように取引量が多く、多数のシステムとつながっているものも同じ扱いです。

保守の担当者を社内に置けない場合は、お引き受けしません。当社は社内で自走できた時点で離れる前提で組んでいるので、担当者がいないまま作れば、誰も直せないシステムが残るだけです。担当者を置けるようになるまで開始を遅らせるか、SaaSを使い続ける判断をおすすめしています。

年額の小さいSaaSは、作る費用と保守の人件費が解約で浮く金額を上回りやすく、対象になりにくいのが実情です。通知期限が迫っている場合は、次の更新に向けた準備から始めるようご提案します。

当社自身の線引きも書いておきます。当社は社員向けのポータル（日報や目標の管理、社内研修など）を自前で作って運用していますが、会計は外部のクラウド会計サービスを使い続けています。線を引いた理由は、基準④と⑥そのものです。

最後に、当社の容量のことです。当社は小さな会社で、経営陣が直接現場に入っています。同時に進められる案件の数には限りがあり、この上限は隠しません。

まとめ

• SaaSの費用が膨らんで見える背景には、値上げと円安の二重の動きがあり、JUASの調査でも内製化に期待する効果の1位が開発コスト削減になった
• それでも公的指針の基本はSaaS優先で、生成AIで作る速さには、安定性や安全性の留保がつく
• 例外はDS-310自身が書いている。アカウント課金で膨らむ高額なSaaSや、同等の機能をマネージドサービスで作れるものは、ライフサイクルコストで比べる
• 判断は7つの基準で行う。④法令・会計ルールと⑥保守の体制で足切りし、①②で金額、③⑤で難しさ、⑦で時期を見る
• 候補は一つに絞り、データを先にまとめてから画面を作る

Klarnaの例から私が受け取った教訓は、SaaSをやめられるかどうかはAIの賢さでは決まらない、ということです。データと保守を自分たちの手に持てるかどうかで決まり、解約はその結果にすぎません。

いま払っているSaaSのうち、どれが7つの基準で候補になるのか、棚卸しから一緒に始めたい方は、FDEのサービスページをご覧いただくか、FDEの個別相談でお話ししましょう。次の記事では、候補にする業務の見分け方を、データの更新頻度という軸から書きます。

Footnotes

1. 海外大手ソフトウェア会社が2024年4月から法人向けソフトウェアとクラウドサービスを値上げ（＠IT、2023年12月11日）。2024年4月1日からの20％の引き上げと、年2回の定期的な価格評価に関する記述は同記事による ↩

2. 時系列統計データ検索サイト（日本銀行）。系列「東京市場 ドル・円 スポット 17時時点/月中平均」（FM08、FXERM07）の月次値を、筆者が暦年ごとに単純平均した値。2026年は1月から8月の平均 ↩

3. 企業IT動向調査報告書2026（一般社団法人日本情報システム・ユーザー協会）。IT予算の増加理由は2.1節の図表2-1-3、内製化に期待する効果は図表7-2-6（n=863）。2025年度調査、東証上場企業とそれに準じる企業4,500社が対象で回答957社 ↩ ↩²

4. Sebastian Siemiatkowski氏のXへの投稿（2025年3月4日）。約1,200のSaaSを止めたという社内推計、SaaSをLLMで置き換えたのではないという説明は同投稿による（筆者訳） ↩ ↩²

5. KlarnaのCEOが、他社がAIで大手CRMを置き換えることに懐疑的だと語った報道（TechCrunch、2025年3月4日、英語）。Neo4jなどを使った社内の技術基盤、他社が同じことをするかは疑わしいという発言は同記事の引用による（筆者訳） ↩

6. DXレポート2 中間取りまとめ（経済産業省 デジタルトランスフォーメーションの加速に向けた研究会、2020年12月28日）。協調領域でのSaaSとパッケージの活用は本文p.22、内製開発への移行支援と伴走によるスキル移転は本文p.24〜25 ↩ ↩²

7. DS-310 政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針（デジタル庁、2025年5月27日）。SaaSの優先利用と、アカウント課金や高額なSaaSへの注意はPDFの16ページ、ベンダーロックインの回避は3.3節、ライフサイクルコストでの比較は本文p.33〜34 ↩ ↩² ↩³ ↩⁴

8. DX動向2025（独立行政法人情報処理推進機構、2025年6月26日）。ソーシング手段は図表2-13（ノンコア事業／非競争領域、日本n=1,475）、内製化の状況は図表2-14（日本n=1,500、米国n=509）、内製化の課題は図表2-16（内製化を進めている企業n=334）。2024年度調査 ↩ ↩²

9. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity（METR、2025年7月10日） ↩

10. We are Changing our Developer Productivity Experiment Design（METR、2026年2月24日）。以前の研究に参加した開発者での推定。著者自身が、選択効果によって真の効果が見えにくくなっている可能性を注記している ↩

11. State of AI-assisted Software Development 2025（DORA）。2025年9月公表、世界の技術者約5,000人の回答にもとづく ↩

12. 2025 GenAI Code Security Report（Veracode、2025年7月30日）。セキュリティ製品を提供する会社による調査 ↩

13. 令和7年通信利用動向調査の結果（総務省、2026年5月29日）。企業編の図表4-1、4-3。常用雇用者100人以上の企業が対象 ↩

14. Gartner Says Adopting a Pace-Layered Application Strategy Can Accelerate Innovation（Gartner、2012年2月14日。MarketScreenerによる転載）。定義の訳は筆者による ↩ ↩²

15. 令和6年分所得税の定額減税について（給与所得者の方へ）（国税庁） ↩

16. DX動向2026（独立行政法人情報処理推進機構、2026年7月30日）。DXを推進する人材の「量」の確保状況は4.2節の図表4-1。2025年度調査 ↩

17. 米医療企業キュラティブが独自のCRMを2カ月で構築し、大手CRMとの年間60万ドルの契約を解約したとの報道（Business Insider Japan、2026年8月15日）。発言の出典はポッドキャスト「20VC with Harry Stebbings」とされる。筆者は発言の原典の音声を確認できていない ↩

18. クラウドサービス分野の取引実態に関する報告書（公正取引委員会、2022年6月28日）。報告書本体p.49〜50、図3-6。切り替えに関する設問は、主にIaaSとPaaSの利用者548社が対象 ↩

19. 中小企業のためのクラウドサービス安全利用の手引き（独立行政法人情報処理推進機構、2026年6月）。項目13「利用終了時のデータを確保する」 ↩