基幹システムのクラウド化｜オンプレミスとの判断基準と移行の注意点

基幹システムのクラウド化は、「全部クラウドか、全部オンプレミスか」ではなく、業務ごとに判断するものです。そして、クラウドにしても設定・権限・データの責任は自社に残ります。この記事では、クラウドの3つの種類、オンプレミス（自社でサーバを持つ形）との判断基準表、5年の総費用で比べる費目、移行で気をつける点を、大手コンサルティングファーム出身の専門家の知見と公的機関の資料をもとに解説します。

基幹システムのクラウド化とは：3つの種類で管理する範囲が変わる

「基幹システムのクラウド化」と一口に言っても、何を借りるかで自社の作業と責任が大きく変わります。米国国立標準技術研究所（NIST）のクラウドの定義（SP 800-145）は、サービスの形を次の3つに分けています。

同じSaaSでも、1社ごとに環境を分ける形と、複数の会社で同じ環境を共有する形があります。共有型は機能の更新が利用者全体に順次適用されるため、自社の都合だけで更新を止められないことが多くあります。この違いは、判断基準表の「2. 業務の変更頻度」に関わります。

中小企業で「基幹システムをクラウドに」という場合、多くはSaaSを使うか、今のシステムをIaaSへ移すかのどちらかです。この2つは費用の出方も社内の作業もまったく違うため、どちらの意味で検討しているのかを最初にそろえます。製品の種類の整理はERPの種類でも解説しています。

調査で見るクラウドの使われ方：業務によって差がある

総務省の「令和7年通信利用動向調査」（2026年5月公表。企業調査は常用雇用者100人以上の企業が対象）によると、クラウドサービスを一部でも利用している企業は83.5％、全社的に利用している企業は60.0％でした。ただし、何に使っているかを見ると、業務によって大きな差があります。

※総務省「令和7年通信利用動向調査の結果（概要）」より一部の項目を抜粋して作成。

給与・会計・人事は半数を超える一方、受注販売・購買・生産管理は2割に届きません。法令や会計基準で処理が決まる業務は標準のサービスに乗せやすく、会社ごとのやり方が強く出る業務は、まだ自社の仕組みで回している会社が多いと読めます。同じ調査で、クラウドを使う理由の1位は「場所、機器を選ばずに利用できるから」（50.7％）でした。基幹システムのクラウド化も、業務ごとに向き不向きを見て判断するのが現実的です。

クラウドとオンプレミスの判断基準表

判断は、会社全体ではなく業務ごとに行います。次の8つの基準で、どちらに寄るかを確認します。

たとえば「会計・購買はSaaS、生産設備とつながる工程管理は工場内のサーバ、両者はデータ連携」のように、業務ごとに分けた答えになることも珍しくありません。パッケージとスクラッチと同じく、クラウドとオンプレミスも二者択一ではありません。作り方ごとの比べ方は作り方の比較で解説しています。

8の「今のサーバの状況」では、OSのサポート期限も確認します。たとえばMicrosoftのライフサイクル情報では、Windows Server 2016の延長サポートは2027年1月12日（米国時間）に終了します。サポートが切れたOSのまま基幹システムを動かし続けると、セキュリティ更新が受けられません。更新期限は検討のきっかけになりますが、それだけで判断はしません（後述の「社内での検討の仕方」を参照）。

判断の例：業務ごとに分けた答え

次の表は、従業員80名・2拠点の機械部品卸売業を例に、8つの基準で業務ごとに判断した結果です。

※説明用の例です。

このように分けた場合は、取引先・品目などのマスタをどの仕組みが持つか（正とするか）を1つに決め、ほかの仕組みはそこから受け取る形にします。両方で登録できる状態にすると、コードと名称が少しずつずれていきます。

費用は5年の総額で比べる

クラウドは初期費用が小さく見え、オンプレミスは初期費用が大きく見えます。しかし、比べるべきは5年程度の総保有コスト（TCO）です。次の表で、どの費目がどちらで発生するかを確認します。

見落としやすいのは最後の行です。データ移行、外部システムとの連携、テスト、教育は、クラウドでもオンプレミスでも同じようにかかります。見積書では、金額と同じくらい「対象外項目」「前提条件」「発注側が行う作業」の欄を読みます。費目の考え方はERPの費用で詳しく解説しています。

比べるときは、次のように年ごとの表にすると、どの年に費用が集中するかが見えます。

※説明用の例です。実際の金額は製品・規模・契約条件で大きく変わります。

クラウドにしても自社に残る責任

「クラウドにすれば、セキュリティも運用も提供者に任せられる」と考えるのは誤りです。総務省が2022年に公表した「クラウドサービス利用・提供における適切な設定のためのガイドライン」をわかりやすく解説した「クラウドの設定ミス対策ガイドブック」（2024年）は、提供者と利用者が責任を分担する考え方を前提に置いたうえで、SI事業者が行った設定であっても、最終的な責任は利用者が負うと明記しています。また、初期設定（デフォルト値）が安全とは限らないため、設定のルールを決めて確認することを求めています。

基幹システムをクラウドにするとき、自社で決めて管理するのは次のようなものです。

オンプレミスなら安全というわけでもありません。警察庁「令和7年上半期におけるサイバー空間をめぐる脅威の情勢等について」によると、同期間のランサムウェア被害の報告は116件で、そのうち中小企業が77件と約3分の2を占めました。被害組織へのアンケートでは、VPNやリモートデスクトップ用の機器からの侵入が感染経路の8割以上を占めています。社外から社内のサーバにつなぐ仕組みを自社で管理している場合、その機器の更新とアカウント管理も自社の責任です。

SaaSの契約書・サービス仕様で確認する項目

SaaSは、提供者が用意した利用規約とサービス仕様に同意して使う形が一般的で、個別の交渉ができないことも多くあります。だからこそ、契約前に次の項目を読み、自社の業務に合わない点がないかを確認します。

特に「解約時のデータの受け取り方」は、次にシステムを替えるときの費用を左右します。契約前に、取引履歴や残高を他の仕組みに移せる形式で出力できるかを、テスト環境で試しておくと安心です。

提供者を選ぶときの参考として、政府には、政府が求めるセキュリティの要求を満たすクラウドサービスをあらかじめ評価・登録する制度（ISMAP）があります。どのような基準で評価されているかを知る手がかりになります。

クラウドへの移行で気をつける6つの手順

1. 今のシステムを棚卸しする
   使っている機能、帳票、他システムとの連携、夜間の一括処理を一覧にします。仕様書がない場合は、システムに詳しい人と業務に詳しい人の両方に確認します。
2. 標準機能で足りるかを見極める（Fit&Gap）
   SaaSでは作り込みに限界があります。足りない部分は「業務を変える」「設定で対応する」「別の仕組みで補う」のどれにするかを、業務ごとに決めます。
3. データを整える
   取引先や品目の重複、表記ゆれ、使い回されたコードを洗い出し、統一のルールと新旧コードの対応表を作ります。
4. 連携と回線、止まったときの手順を決める
   会計・勤怠・EC・取引先とのデータのやり取りを、対象項目・頻度・エラー時の処理まで決めます。回線やサービスが止まったときに、出荷や請求をどう続けるかも決めておきます。
5. 移行のリハーサルで照合する
   テスト移行で件数・金額・残高を照合し、業務担当者が実際の画面で確認します。重大な不整合が残ったら稼働を延期するか、元に戻すかを判断できる基準を、事前に決めておきます。
6. 稼働後に使われているかを確認する
   稼働後1〜3か月は、使われていない機能や入力の負担が大きい箇所を確認し、改善する期間を設けます。

切り替える時期も先に決めます。会計は期首（新しい事業年度の初日）に切り替えると、期の途中の残高を二つの仕組みで突き合わせる手間が減ります。販売や在庫は、月末の締めと棚卸しの直後、かつ繁忙期を避けた月が候補です。稼働日から逆算して、テスト移行とリハーサルを少なくとも2回入れられる日程になっているかを確認します。日程に余裕がない場合は、業務ごとに稼働時期をずらす段階移行も検討します。

3と5の進め方は基幹システムのデータ移行で、稼働を延期するか判断する基準の作り方は稼働判定と本番切替で解説しています。

稼働後に必要な社内の役割

クラウドにすると、サーバの保守はなくなりますが、社内の仕事がゼロになるわけではありません。提供者は数か月ごとに機能を更新することがあり、そのたびに業務への影響を確かめる人が必要です。情報システムの専任者がいない会社でも、次の役割は名前を決めて割り当てます。

※説明用の例です。

役割が決まっていないと、退職者のアカウントが残ったままになったり、機能の更新で帳票の形が変わったことに月末まで誰も気づかなかったりします。ガイドブックが求める「設定する人とチェックする人を分ける」も、この役割分担があって初めて回ります。また、特定の委託先しか設定を触れない状態は、将来の乗り換えを難しくします。防ぎ方はベンダーロックインとはで解説しています。

クラウドサービスを契約する前のチェックリスト

• SaaS・PaaS・IaaSのどれを検討しているかが社内でそろっている
• 業務ごとに、判断基準表の8項目を確認した
• 利用人数や機能を増やしたときの料金の変わり方を確認した
• 機能の更新の頻度と、事前の通知の方法を確認した
• 計画停止（メンテナンス）の時間帯が、自社の業務時間と重ならない
• 解約時にデータをどの形式で受け取れるかを確認した
• 利用規約の免責条項・責任制限条項を読んだ
• 権限の設計と、退職・異動時のアカウント削除の担当が決まっている
• 回線やサービスが止まったときの業務の続け方が決まっている
• データ移行の照合方法と、稼働を延期する判断基準が決まっている

システムに求める稼働時間や性能、移行の条件は、IPA（情報処理推進機構）の「非機能要求グレード」の6つの大項目（可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジー）に沿って整理すると漏れを防げます。中小企業向けの書き方は非機能要件とはで、古い独自システムからの移行はオフコンのリプレイスも参考にしてください。

よくある質問

まとめ

基幹システムのクラウド化は、業務ごとに判断基準表で確かめ、5年の総費用で比べ、クラウドでも残る自社の責任を決めておくことで判断を誤りにくくなります。移行では、データを整え、照合の基準と稼働を延期する基準を事前に決めることが欠かせません。成功したかどうかは、クラウドに移ったかではなく、業務が良くなったかで判断します。

自社のどの業務をクラウドにすべきか整理したい、という方は、無料診断で現状の課題と、刷新の前に決めるべきことを整理します。