オンプレ回帰・スクラッチ開発回帰は起きているのか｜中小企業の選び直し方

「クラウドは高いのでオンプレミスに戻す」「AIで作れるならSaaSを解約する」。こうした話を見聞きして、自社も方針を変えるべきか迷う経営者や情シス・DX担当者は少なくないでしょう。ただ、海外の大規模な移行事例と、自社の限られた人員で支える業務を、そのまま重ねることはできません。

オンプレ回帰とスクラッチ開発への動きはありますが、どちらも全面回帰と捉える根拠にはなりません。業務ごとに、システムの置き場所とソフトウェアの作り方を選び直す動きと捉えるのが適切です。 調査の「戻す企業の割合」と「戻されたワークロードの割合」を分け、費用・データ管理・運用担当をそろえて判断してください。以下は2026年10月22日時点の公開情報に基づきます。

---

本記事のポイント

1. オンプレ回帰も独自開発への動きも、全面回帰ではなく、業務ごとに置き場所と作り方を選び直す判断として捉えます。
2. 回帰を検討した企業の割合、全面回帰の予定、戻されたワークロード量は、分母と時点が異なる指標です。
3. SaaS・独自開発と自前基盤・クラウドを別の軸で比較し、総費用、データ管理、更新・保守の担当を決めます。

---

オンプレ回帰は起きているが、数字の分母が違う

オンプレ回帰とは、パブリッククラウドで動かしていた処理やデータを、自社管理の設備などへ移すことです。クラウド・レパトリエーションとも呼ばれます。調査によって移行先にプライベートクラウドを含むため、必ずしも自社の事務所にサーバーを置くことを意味しません。データセンターのラックを借り、機器を自社で保有する形もあります。

ワークロードは、受注処理、顧客データの保管、バックアップ、AI推論など、一定の目的を持つ処理のまとまりです。会社のシステム全体ではありません。ある企業がバックアップだけを戻した場合も、「回帰を実施した企業」には入り得ます。

BroadcomのPrivate Cloud Outlook 2026は、同社とRadius Techが従業員1,000人以上の企業のIT意思決定者1,800人を対象に実施した調査です。VMwareのプライベートクラウド製品を持つ企業によるベンダー調査であり、回帰が進むという結果に商業上の利害があります。日本の中小企業全体の割合には置き換えられません。

8〜9%はIDCが2024年10月に公開した説明で確認できます。調査の回答者数は同ページに明記されていません。17.6%はBroadcom出資のIDCホワイトペーパーに掲載された別の指標です。対象、時期、分母が異なるため、この数字同士を引き算して回帰の増減を求めることはできません。

37signalsとGEICOから分かる、回帰が成立する条件

BasecampやHEYを運営する37signalsの共同創業者DHHは、2024年10月の本人発表で、クラウド料金を従来の年間320万ドルの水準から130万ドルへ下げたと説明しています。新規ハードウェアへの支出は約70万ドルでした。ただし、同社には既存のデータセンターのラックと電力枠があり、運用チームも存在しました。5年間で1,000万ドル超という削減額は、その時点の将来見込みです。

米保険会社GEICOも、同社執筆のOCP導入資料で、計算コア当たりの単価を50%超、ストレージのGB当たり単価を60%超削減したと報告しています。比較対象は従来のOEM機器とパブリッククラウドです。これは単位費用の改善であり、移行費や人件費まで含めた会社全体のIT費用削減率ではありません。資料自体も他社で同じ結果になるとは限らないと注記し、ファームウェア管理や専門知識の確保を課題に挙げています。

これらは「サーバーを買えば誰でも安くなる」という話ではありません。一定以上の処理量、継続する利用、運用を担う人や設備がそろい、移行後の経済性が成立した事例です。担当者を新たに確保する企業は、その費用を自社の比較表に加える必要があります。

AI・GPUは、置き場所を再検討する理由を増やした

AIでは、モデルを試す段階と、業務のたびに推論を実行する段階で負荷の形が変わります。需要が読めない実験や短期的な計算と、毎日続く大量の推論では、適した契約や設備も異なります。機密データをどこまで外部へ送れるか、応答の遅れをどこまで許容できるかも判断材料です。

Clouderaの2026年8月の発表では、回答者の66%が過去1年にAIワークロードをパブリッククラウドからプライベートクラウドまたはオンプレへ移したと回答しています。これは移行経験を答えた回答者の割合で、AI処理量の66%ではありません。対象は9市場の設計・インフラ担当者1,500人で、日本を含む大半の市場では従業員1,000人以上の企業です。ハイブリッド基盤を販売するClouderaの委託調査である点も踏まえて読みます。

一方、Synergy Research Groupの推計では、2026年第2四半期の世界のクラウドインフラサービス売上は前年同期比43%増でした。IaaS、PaaS、ホステッド・プライベートクラウドを含む市場の金額で、ワークロード数ではありません。回帰する処理があることと、クラウド市場が拡大することは両立します。

DeloitteのTech Trends 2026も、業務ごとに計算基盤を選ぶ考え方を示しています。中小企業では、まず実際の利用量、必要な品質、ピーク時の性能を測りましょう。GPUの購入から始めると、十分に使わない設備と、その更新・電力・冷却の負担が残り得ます。外部AIサービスを使う案、自社管理のモデルをクラウドで動かす案、社内設備で動かす案を同じ要件で比べることが出発点です。

スクラッチ開発への動きは、SaaSを全部作り直す動きではない

スクラッチ開発は、自社の要件に合わせて独自のソフトウェアを作ることです。ただし、自社社員が作る「内製」と、外部の開発会社へ委託する「独自開発」は同じではありません。また、既存の開発基盤や部品を活用した自作ツールまで、すべてゼロから作ったと受け取るのも不正確です。AIコーディングの普及を読む際は、何を、誰が、どの基盤で作ったかを分けます。

McKinseyの2026年AI調査では、回答者の32%が、AIコーディングツールで社内構築できるため、自社で少なくとも1つのソフトウェア製品または機能の購入を見送ったと答えています。調査は2026年5〜6月、97か国の1,719人が対象です。これは回答者が報告した組織の購入判断であり、SaaS市場の売上が32%減ったという意味ではありません。購入の見送りと、既存契約の解約も区別する必要があります。

Retoolの2026 Build vs. Buy Reportでも、回答者の35%が、チームで少なくとも1つのSaaSを自作ツールに置き換えたと回答しています。ただし、対象は2025年後半に調査したRetoolの顧客・開発する人817人です。社内アプリ開発基盤を売るRetool自身のベンダー調査であり、開発に取り組む層へ偏っています。「企業の35%がSaaSから撤退した」と一般化することはできません。

作るか買うかは、業務の差別化と保守範囲で分ける

AIによって試作品を作りやすくなると、部署独自の承認フロー、複数サービス間の転記、社内向けの集計画面などが独自開発の候補になります。SaaSの標準機能へ無理に業務を合わせる負担と、独自の仕組みを保守する負担を比較できるからです。

一方、会計、給与、法定帳票のように制度変更への継続対応が必要な機能は、最初に動いた後の維持が重要です。認証、権限、監査ログ、バックアップ、データ移行、問い合わせ対応まで同等に用意するなら、画面を作る工数だけでは比較できません。使っていないライセンスの削減、契約プランの変更、既存SaaSへの小さな連携追加で解決するかも先に調べます。

独自開発を選んでも、実行場所をオンプレに戻す必要はありません。クラウド上のマネージドデータベースを使い、業務固有の画面だけ作ることもできます。Webサイトでも、CMS、フォーム、公開基盤をどう組み合わせるかという判断があります。構成の選択肢はウェブサイト構築の手法と選び方で確認できます。

Klarnaの「SaaSをLLMで置き換えた」という理解は訂正されている

Klarnaは、SaaSをAIで置き換えた企業として語られることがあります。しかしCEOのSebastian Siemiatkowski氏は、本人の投稿で、SaaSをLLMに置き換えたわけではないと訂正しています。説明しているのは、SaaSの整理と、社内の技術基盤に知識・データをまとめてAIから利用する仕組みです。

この事例から「AIに頼めばCRMや人事システムをそのまま代替できる」と結論づけることはできません。業務データの整合性や権限を管理する仕組みと、それを検索・要約するAIは役割が異なります。自社でも、まず不要な契約の整理とデータの接続を行い、それでも残る固有業務を開発対象にすると、作る範囲が明確になります。

Studioとphp2shellが示す、委託先の集中リスクと自前の保守責任

2026年10月には、外部サービスに集約した情報のリスクと、自社側で管理するソフトウェアの更新責任を考える事象が相次ぎました。この2件だけでSaaSと自前運用の安全性の優劣を決めることはできませんが、どちらを選んでも残る責任を整理する材料になります。

Studioの2026年10月16日の第一報（10月18日更新）では、全登録顧客について情報流出の可能性があると説明しています。保存されたフォーム回答や外部サービスのAPIキー・トークンなども対象として挙げられています。一方、実際に第三者が取得した事実は確認できておらず、取得されたものとみなして対応するとしています。「全利用者の情報流出が確定」と言い換えてはいけません。利用者向けの確認事項はStudio不正アクセスの影響と対応に整理しています。

PHP公式の2026年10月21日の告知は、CVE-2026-109618とCVE-2026-109619への更新を促しています。対象環境を自社や契約先で管理している場合は、アプリの修正だけでなく、サーバー側のPHP本体の修正適用が必要です。実務手順はphp2shellの影響確認と更新依頼を参照してください。独自開発したシステムをクラウドで動かしていても、実行環境の更新を誰が担うかは確認が必要です。

SaaSを選ぶと、基盤の保守を提供会社へ委ねられますが、預けるデータや認証情報、契約上の対応範囲を把握する責任は残ります。自前化すると、公開範囲や構成を制御しやすくなる一方、脆弱性情報の受信、修正、監視、障害対応の担当を確保する必要があります。自社で実施するか保守会社に委託するかを含め、責任が空白になる箇所をなくします。

AIがコードを書いても、レビューと運用は必要になる

セキュリティ製品を販売するVeracodeの2025年の検証報告では、100超のLLMに80の課題を与えた評価で、生成タスクの45%が既知の脆弱性を含むコードを生んだとしています。特定の言語・脆弱性・課題条件でのベンダー検証であり、現在のすべてのAI開発や、完成した業務アプリの45%が危険という意味ではありません。

実務では、AI生成の有無にかかわらず、権限を越えてデータを閲覧できないか、入力値を安全に扱うか、秘密情報が残っていないかを確認します。担当者が変更内容を説明でき、テスト・脆弱性確認・バックアップからの復旧を実施できることまでを、独自開発の受入条件に含めてください。

日本の現状は、全面回帰より業務と体制の見直しとして読む

日本の中小〜中堅企業に当てはめる際は、海外大企業の調査から結論を移さないことが重要です。クラウドの利用経験があること、社内で開発していること、既存環境から戻したことは、それぞれ別の状態です。ある時点の利用率だけでは「回帰が増えた」とは判断できません。

IPAのDX動向2025、図表2-14では、「システム開発の内製化を進めている」とした回答は日本で22.3%、米国で46.4%でした。2025年2〜3月の調査で、日本の回答数は1,500、米国は509です。別の選択肢に「必要な部分については内製化済み」があるため、22.3%を日本の内製化全体の普及率とは呼べません。また、クラウドやSaaSからの回帰件数を測った調査でもありません。

移行すれば自動的に安くなるわけでもありません。デジタル庁の早期移行検証報告書（2026年3月公表）では、対象10自治体の業務について、現行と同規模のシステムを更新・継続する場合と、ガバメントクラウドへリフトする場合の5年間の運用経費を比較し、後者の合計が8.0%高い試算となっています。これは特定条件の比較であり、全国の自治体の移行実績や民間企業一般の増加率ではありません。

ここから中小企業が持ち帰れるのは、「移す先を決める前に、構成と運用を比較する」という判断です。古いシステムをそのままクラウドへ移す案、不要な処理を減らして移す案、既存サービスへ業務を寄せる案では、移行後に払う費用も担当範囲も変わります。逆方向に戻す場合も同じです。自前化という言葉だけで、現行の重複機能や運用上の問題が解消することはありません。

中小企業の判断表：業務ごとに自前・クラウド・SaaSを組み合わせる

最初に「置き場所」と「作り方」を別々に記録します。 置き場所は自前基盤やクラウド、作り方・調達方法はSaaSや独自開発です。SaaSの多くはクラウド上で提供され、独自開発もクラウドで動かせます。同じ列の二者択一と考えず、業務ごとの組み合わせとして比較してください。

下表は選定を始めるための判断例です。特定企業の導入実績や、無条件の推奨を示すものではありません。個々の製品の契約・機能・管理範囲と、自社の要件を照合して使ってください。

比較表へ必ず加えるチェックリスト

1. 同じ範囲の総費用で比べる：月額料金と機器の購入費だけを比べず、移行、回線、電力、保守、担当者の時間、AI利用料、データの取り出し、廃止まで含めます。比較期間と、利用量が増えた場合の費用もそろえます。
2. 現行の無駄を先に減らす：不要なサーバー、過大な構成、使わない契約、重複する機能を洗い出します。整理した現行案と移行案を比べなければ、回帰の効果を過大評価します。
3. 運用の責任者を決める：平常時の更新、緊急修正、障害連絡、退職時の引継ぎを、自社と委託先のどちらが担当するかを明記します。「AIが作ったから分からない」を保守の前提にしません。
4. 情報の流れを確認する：個人情報、機密資料、フォーム回答、認証情報について、保存先と送信先、閲覧できる人、削除・回収の方法を記録します。
5. 小さい範囲で確かめる：移しても業務影響を制御できる対象で、性能、費用、復旧、担当者の作業量を測ります。並行稼働中の費用と、本移行する条件も決めます。
6. 次の移行手段を残す：データの書き出し形式、コードや設定の管理権限、契約終了条件、転送料を確認します。新しい基盤に移っても、自社が業務とデータを把握できる状態を保ちます。

判断の順番は、業務要件の確認、現行構成の整理、複数案の総費用と責任の比較、小規模な検証です。安い基盤を先に決めて業務を押し込むより、何を自社で管理する必要があるかを明確にすると、SaaSを残す部分と作る部分を分けやすくなります。

よくある質問

オンプレ回帰はクラウドからの全面撤退ですか？

全面撤退とは限りません。一部の処理やデータだけを戻す企業も含まれます。調査を見る際は、回帰を検討・実施した企業の割合なのか、全量回帰の予定なのか、移したワークロードの割合なのかを区別してください。

スクラッチ開発と内製化は同じですか？

異なります。スクラッチ開発は独自の要件でソフトウェアを作る方法、内製化は自社の人が開発を担う体制の話です。外部へ委託して独自開発することも、内製で既存の開発基盤を使うこともあります。AIを使う場合も、誰が仕様と保守に責任を持つかを決めます。

AIで作れるならSaaSを解約した方が安いですか？

試作品の開発費だけでは判断できません。認証、権限、監査、バックアップ、制度対応、運用支援を含めて比較します。不要な契約を整理する、既存SaaSへ小さな連携を足す、不足部分だけ作る案も比べてください。

中小企業でもAI用GPUを購入すべきですか？

利用量と要件を測ってから検討します。需要が不明な段階では外部サービスで品質と利用量を確かめ、継続的な負荷、機密性、応答時間、運用体制を確認して比較します。GPU購入の有無と、業務にAIを活用できるかは別の判断です。

SaaSの不正アクセスを避けるには自前化すべきですか？

自前化だけで安全にはなりません。外部サービスへ預ける情報の集中を管理する責任と、自社管理するソフトウェアを更新・監視する責任の両方があります。扱うデータ、管理範囲、事故時の対応者を比較し、自社が維持できる構成を選びます。

自社に合う構成と、公開後の運用を整理したい方へ

ファネルAiは、Webサイト・業務システムの構築と運用設計、AI活用を支援しています。現行業務と費用を整理し、SaaSを活かす部分、独自に作る部分、更新・保守を担う体制を一緒に検討できます。

Webサイト・業務システムの構成と運用設計を相談する