システム更改とは？刷新・リプレイスとの違いと保守期限から逆算する更改計画

サーバーの保守が切れる、リース契約が満了する、OSのサポートが終わる。こうした日付をきっかけに現行システムを次期へ入れ替える取り組みが、システム更改です。この記事では、更改と刷新・リプレイス・改修の違い、更改を検討する時期、サポート終了日から逆算する更改計画の立て方、費用の内訳、同等機能の更改にとどめるか刷新へ広げるかの判断基準を、デジタル庁のガイドラインなど公的な資料をもとに整理します。

まとめ：システム更改は期限から逆算して範囲を先に決める計画業務

システム更改で最初に決めるのは製品ではなく、動かせない期限と変更の範囲です。サポート終了日やリース満了日を起点に工程を逆算し、基盤だけを入れ替えるのか、機能や業務まで作り直すのかを切り分けます。

範囲の判断は、次の順で進めると迷いません。

• 機能改修で対応できるなら更改しない
• 現行業務に不満がなければ同等機能の更改にとどめる
• 業務の変更や構造の限界があるときだけ刷新へ広げる

計画の段階で見落としやすいのは、並行稼働の運用経費、旧環境の廃棄費用、現行事業者からの情報提供の3つです。いずれも見積りの外に置かれやすく、後から予算を押し上げます。

システム更改とは何か：基盤の入替えから次期への移行までを指す用語

「更改」は、官公庁の調達や大規模システムの現場でよく使われる言葉です。実際の使われ方を見ると、範囲がつかめます。

デジタル庁の標準ガイドラインに見る更改と機能改修の対象範囲の線引き

政府情報システムのルールであるデジタル・ガバメント推進標準ガイドライン（DS-100）は、更改を機能改修と対置して使っています。第3編第8章では、機能改修で対応できないと判断したとき、または機能改修より更改のほうが経済的と判断したときに更改を検討すると定めています。

同じガイドラインの解説書（DS-110）は、更改の例として「システムアーキテクチャの大幅な変更」と「利用するクラウドサービスの変更」を挙げました。リソースのチューニングや小規模な業務の見直しは、継続的な見直しとして更改の外に置かれています。

さらにDS-110は、更改を原則として別のプロジェクトとして管理するとしています。目標と計画を立て直す単位が更改だと考えると、社内の稟議でも説明しやすくなります。

厚生労働省の年金業務システム調達に見る基盤の入替えと更改作業の内訳

調達の件名を読むと、更改に含まれる作業が具体的に分かります。厚生労働省が令和5年3月1日に掲載した公示の件名は、年金業務システムに係る「システム更改（環境構築・賃貸借及び保守）」と、「更改に伴うアプリケーションソフトウェアの改修及びデータ移行業務」を一式にしたものでした。

この例では、環境の構築、機器の賃貸借と保守、アプリケーションの改修、データ移行までが一体で扱われています。基盤の話に聞こえる更改でも、アプリケーションとデータに作業が及ぶ点は押さえておいてください。

更改・刷新・リプレイス・改修の違いと発注時に言葉をそろえる方法

これらの語は現場で混ざって使われます。発注の場で食い違いを生まないよう、何を変えて何を残すかで整理します。

5つの用語をシステムで変える対象と残すもの・主な動機で並べた比較表

次の表は、この記事で用いる整理です。公的に統一された定義ではないため、社内と委託先で読み合わせる材料としてお使いください。

実務上の分かれ目は、業務の進め方まで変えるかどうかです。ここが変わると要件定義の工数が跳ね上がります。用語ごとの詳しい違いはマイグレーションとリプレイス・モダナイゼーションの違いの解説で扱っています。

見積り依頼書で更改と書く前に作業範囲として定義しておく4つの項目

依頼書に「システム更改一式」とだけ書くと、ある会社はサーバーの入替えのみ、別の会社はアプリケーションの作り直しまでを見積もります。金額を比べられなくなるため、次の4項目は文章で定義してください。

1. 入れ替える層（機器、OS、ミドルウェア、アプリケーション）
2. 現行機能のうち変更・追加・削除するもの
3. 移行するデータの範囲と保持年限
4. 許容できるシステム停止の日時と長さ

DS-110も、既存システムを更改するときは追加・変更・削除が明確になるよう情報をまとめ、対象範囲を特定するよう求めています。2番の項目はそのまま使える考え方です。

システム更改を検討する時期と保守期限・リース満了など7つの引き金

更改の時期は担当者の感覚で決めるものではありません。外から決まる日付と、社内の課題とに分けて洗い出します。

DS-100が挙げる改善の事由7項目と民間企業で更改を判断する確認先

DS-100の第3編第8章は、情報システムの改善を検討する事由を7つ挙げています。民間企業でも確認先を置き換えれば、そのまま棚卸しに使えます。

期限が外から決まるのは、耐用年数、リース満了、サポート終了の3つでした。計画の起点にはこの3つのうち最も早い日付を置き、残りの事由は更改の範囲を決める材料に回します。

オンプレミス5か年の目安とクラウドで更改周期の判断条件が変わる理由

DS-110は、オンプレミスのライフサイクル期間について、保守期間等を考慮してサービス開始年度から5か年程度を目安としています。一方のクラウドは、ハードウェア等の制約を必ずしも受けないため、期間を柔軟に調整できるという位置づけです。

ただしDS-110は、クラウドでも5か年程度を目安に更改の要否を検討するとしています。クラウドへ移せば更改の検討が不要になるわけではありません。サービスの提供終了や料金改定に応じて、見直しの場は定期的に設けてください。

Windows Server 2016とRHELのサポート期限に見る逆算の起点

期限の実例を見ましょう。Windows Server 2016のライフサイクルページでは、メインストリームサポートが2022年1月に終了し、延長サポートの終了は2027年1月と表示されています（2026年11月時点。表示は1/13/2027 6:59:59 AM）。2026年11月から数えて残りは2か月ほどです。

この時点で計画を始めても、通常の更改工程は間に合いません。延長策の有無と費用を製品ベンダーへ確認し、暫定措置と本番の更改計画を分けて進めることになります。

Linux側では、Red Hat Enterprise Linuxのライフサイクルが、RHEL 8・9・10について10年の期間を示し、前半5年をFull Support、後半5年をMaintenance Supportとしています。Maintenance Supportの期間は新機能と新規ハードウェアへの対応が計画されていないため、更改の検討は終了日ではなく前半の終わりを目安に始めると余裕が生まれます。

システム更改計画の立て方：サポート終了日から逆算する工程と期間の置き方

計画は開始日から積み上げず、期限から引き算で作ります。積み上げ式だと、後半の工程にしわ寄せが集まるためです。

サポート終了期限から逆にたどる7工程と各工程で確定させる成果物

次の順に、期限側から日付を置いていきます。

1. 切替期限を決める（サポート終了日より前に予備の月を取る）
2. 本番切替と切戻し条件を決める（切替手順書）
3. 移行リハーサルと受入テストの期間を置く（テスト計画書）
4. 設計と構築の期間を置く（設計書と環境）
5. 発注先を選ぶ（提案依頼書と評価表）
6. 要件と範囲を確定する（要件定義書と移行対象一覧）
7. 現行を棚卸しして予算を確保する（現行資産の一覧と概算）

たとえば切替期限まで24か月しかなく、棚卸しと予算に6か月、発注先選定に4か月かかるなら、設計からテストに使えるのは14か月です（計算の例で、実案件の数字ではありません）。ここで足りなければ、範囲を削るか暫定延命を挟むかの判断になります。一括か段階か並行かという切替方式の選び方は、システム移行の方式と進め方の解説を参照してください。

予算の締切も逆算に含めます。年度予算で動く会社では、棚卸しの完了が予算申請の締切に間に合わないと、着手が丸1年遅れることがあります。

新旧システムの並行稼働の月数で増える運用経費と更改時期の月単位の調整

新旧を同時に動かす期間は、両方の運用費がかかります。DS-110の予算の章は、次期システムへの更改時期に並行稼働期間が発生する場合、その間は通常より余分に運用経費を要するため、月単位で時期を調整する必要があると述べています。

並行稼働は「念のため長く」と考えがちですが、1か月延びるごとに旧環境の保守料とデータの二重管理の手間が増えます。終了条件を「照合の差異が2回連続でゼロ」のように数字で決めておくと、ずるずると延びません。

現行の保守事業者から次期事業者への情報提供を受ける条件の確認と契約

更改の成否は、現行システムの情報をどれだけ引き出せるかに左右されます。DS-100の第3編第9章は、更改するときには運用事業者や保守事業者に対し、次期の要件定義や設計・開発に携わる事業者へ作業経緯と残存課題を提供させ、質疑応答等の協力を求めると定めました。

民間企業の保守契約には、この義務が書かれていないことがよくあります。別の会社へ移る更改で協力を断られる、あるいは高額な費用を請求されるといった事態を防ぐには、次の契約更新時に引継ぎ協力の範囲と単価を書き足しておくのが近道です。見積り段階では、DS-110が示すとおり秘密保持契約を結んだうえで設計書を候補事業者に閲覧させる手順も組み込みます。設計書が残っていない場合は、ブラックボックス化の原因と解消手順で扱う現状把握から始めてください。

システム更改の費用内訳と再リース比較で見落としやすい経費と税務

更改の見積りは機器と構築費に目が向きがちです。公的な経費区分を物差しにすると、抜けている項目を見つけられます。

DS-100の経費区分で点検する更改見積りの12項目と抜けやすい廃棄費

DS-100の別紙2は、更改を含む整備経費を、調査研究等、設計、開発、据付調整、テスト、移行、廃棄、プロジェクト管理支援、施設整備等、ハードウェア買取、ソフトウェア買取、サービス利用料などに区分しています。受け取った見積りをこの区分に当てはめると、空欄になった項目が確認すべき点です。

抜けやすいのは廃棄と移行でした。DS-100は更改時に機器等の利用を停止し、情報セキュリティの観点を踏まえて廃棄または再利用に取り組むとしており、データ消去の証明まで含めて費用を確かめておく必要があります。

区分の考え方として、DS-100は積極的な効果を狙う「投資的整備」と、外部環境の変更による障害を避けるために義務的に行う「維持的整備」を分けています。保守期限への対応は維持的整備に近く、稟議では効果額よりも止めた場合の影響で説明するほうが通りやすくなります。

リース満了時に再リースの継続と更改を比べるときに含める費用の範囲

リース満了時の選択肢は更改だけではありません。DS-110も、再リース契約による継続利用と更改を比較し、どちらが経済的か検討するよう示しています。

再リース料は安く見えますが、比較には機器の保守契約が継続できるか、部品の供給が続くか、OSのサポート期限がいつかを含めてください。サポート期限が先に切れる場合、再リースで得られるのは機器の延命だけで、脆弱性への対応は残ったままです。1年の再リースは更改の準備期間を買う手段と割り切ると、判断がぶれません。

自社利用ソフトウェアの5年償却と更改時に経理部門と確認する除却処理の条件

更改では税務の確認も必要です。国税庁のタックスアンサーNo.5461（令和8年4月1日現在）によると、ソフトウエアの耐用年数は、複写販売の原本や研究開発用が3年、その他が5年です。

償却が残ったまま使わなくなる場合は、法人税基本通達7-7-2の2が参考になります。自社利用のソフトウエアで、ハードウェアやOSの変更により他のソフトウエアを使うことになった場合などは、物理的な廃棄がなくても帳簿価額を損金に算入できる扱いです。適用の可否は個別事情によるため、切替の時期が決まった段階で経理部門と税理士に確認してください。

同等機能の更改にとどめるか刷新へ広げるかを分ける判断基準と失敗例

更改の機会に「ついでに全部直したい」という声は必ず上がります。ここでは、広げてよい場合と広げない場合を条件で示します。

期限と担当者の余力から同等機能の更改にとどめて刷新を見送るべき3つの場面

次のいずれかに当てはまるなら、刷新はしません。同等機能の更改で期限を守ることを優先してください。

• 期限までの残り期間が、要件定義を含む刷新の工程に足りない
• 業務部門に、新しい業務の進め方を決める担当者を出す余力がない
• 現行業務への不満が画面の使い勝手など個別の改修で解消できる

1つ目は特に厳しく見ます。期限のある更改に要件の議論を持ち込むと、最初に削られるのはテスト期間です。どの工程で問題が起きたのかは、出荷停止や訴訟に至った5件を工程別に分解した基幹システム刷新の失敗事例で確かめられます。

費用の経済性と残り期間から更改に合わせて刷新まで踏み込むべき2つの条件

反対に、次の条件を両方満たすなら、更改に合わせて刷新へ広げる価値があります。

1つ目は、DS-100が示すとおり、機能改修より作り替えたほうが経済的と数字で示せることです。直近3年の改修費と保守費を集計し、次の5年の見込みと比べます。2つ目は、期限まで2年以上あるか、暫定延命で2年以上を確保できることです（前章の計算例から置いた目安で、公的な基準ではありません）。

刷新まで踏み込むと判断したら、レガシーシステム脱却の判断基準と進め方に沿って費用と停滞要因を見積もってください。社内だけで現行の棚卸しや切替方式を決めきれない場合は、システムマイグレーション・リプレイスの支援のように、現状分析から移行計画までを外部に任せる方法もあります。

現行踏襲の要件と保守要件の混同で起きる発注時の更改の失敗パターン

更改で多い失敗は、要件を「現行どおり」の一言で済ませることです。現行の動きを誰も説明できないまま発注すると、テストの段階で仕様の認識違いが次々に見つかります。DS-110が、更改の要件定義は既存の要件定義書を基に追加・変更を明示するよう示しているのは、この事態を防ぐためと読めます。

もう1つは、保守契約の範囲で更改まで賄えると考えることです。DS-100は、保守要件を機能改修及び更改と明確に区別して記載するよう求めています。DS-110も更改には運用・保守とは別に経費を要する場合があると注意を促しており、保守料の中に更改の費用は含まれないものとして予算を組むのが安全です。

システム更改の用語・周期・開始時期・費用・依頼先でよくある質問

更改の検討で出やすい疑問に答えます。

システム更改と刷新はどう違いますか？

更改は、保守期限やリース満了などを機に現行システムを次期へ入れ替える取り組みを広く指し、業務の進め方は原則として維持します。刷新との違いは、システムの構造や業務の進め方まで見直す点です。ただし語の使い方は組織で揺れがあり、官公庁の文書ではアーキテクチャの大幅な変更も更改に含めています。発注の際は、用語よりも入れ替える層と業務変更の有無を文章で定義してください。

システム更改の周期は何年が目安ですか？

デジタル庁の解説書は、オンプレミスの場合、サービス開始年度から5か年程度をライフサイクル期間の目安としています。クラウドは柔軟に調整できるものの、同じく5か年程度を目安に更改の要否を検討するとしています。実際の時期を左右するのは、機器の保守期間、リース期間、OSやミドルウェアのサポート終了日のうち最も早い日付です。一律の年数で決めず、製品ごとの期限を台帳で管理してください。

更改計画はいつから始めればよいですか？

期限から工程を引き算して、棚卸しの開始日を決めます。たとえば棚卸しと予算に6か月、発注先選定に4か月、設計からテストに14か月かかる計算なら、2年前には動き出す必要があります。これは計算の例であり、規模によって必要な期間は異なるものです。年度予算で動く会社は、予算申請の締切に棚卸しを間に合わせる点も考慮してください。残り期間が足りないときは、暫定的な延長策と本番の更改を分けて計画します。

システム更改の費用はどの項目を見積もりますか？

機器やライセンスの費用に加え、調査、設計、開発、据付調整、テスト、データ移行、旧環境の廃棄、プロジェクト管理支援までが対象です。デジタル庁DS-100の経費区分を物差しにすると、抜けを点検できます。新旧の並行稼働中に増える運用費も別枠で見込んでください。金額の相場は規模と変更範囲で大きく変わるため、範囲を文章で定義したうえで複数社から内訳つきの見積りを取り、比べるのが確実です。

現行とは別の会社に更改を依頼できますか？

依頼できますが、現行の設計書や運用記録をどこまで提供できるかが前提になります。デジタル庁のガイドラインは、更改時に現行の運用・保守事業者から次期の事業者へ作業経緯と残存課題を提供させ、質疑応答の協力を求めると定めています。民間では、保守契約に引継ぎ協力の条項があるかを先に確認してください。特定の会社に依存している状態の解消については、ベンダーロックインの回避策も併せて確認すると整理しやすくなります。

関連記事

• システム刷新のRFPとは？現行情報の開示範囲・移行要件・ベンダー選定基準を解説：更改や刷新の提案依頼書に書く内容を確認できます
• ベンダー選定とは？システム開発の発注先を決める流れと評価表の配点設計：計画の工程にある発注先選定の進め方です
• ベンダーロックインとは？原因と回避策・契約で押さえる条項とリプレイスの判断基準：現行事業者から離れるときの契約面の論点を扱います