LASSIC Media らしくメディア
システム更改とは？刷新・リプレース・改修との違いと進め方を解説
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- システム更改は、機器やソフトを入れ替えることと、そのための計画・移行・切り替えをひとまとめにした言葉です。
- 改修や保守はいまのシステムを使い続ける作業で、更改とリプレースは新しいものに置き換える作業です。
- 改修で済むか更改すべきかを費用と期間で比べ、いまの保守会社からの引き継ぎを早めに確かめることが大切です。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
上司から「次のシステム更改の計画を出してほしい」と言われたが、刷新やリプレースと何が違うのか分からない。改修で済む話なのか、入れ替えまで必要なのか判断がつかない——。情報システムの担当になったばかりの方の間では、こうした迷いが起こりがちです。システム更改とは、サーバーなどの機器やソフトウェア、業務のアプリケーションを新しいものに入れ替えることと、そのために必要な一連の作業をまとめて指す言葉です。
機器の入れ替えの時期やソフトのサポート終了に合わせて計画されることが多い一方、改修で足りる場面で更改を選ぶと、費用も期間も大きくなります。ただし万能な決め方があるわけではなく、いまのシステムの状態によって答えは変わります。本記事では、IT投資を判断する立場の方に向けて、システム更改の意味、刷新・リプレース・改修との違い、更改が必要になるきっかけと進め方、そして外部に頼むときに確認したい点を整理します。
目次
システム更改とは
デジタル庁の標準ガイドライン群用語集は、更改を「ハードウェア、ソフトウェア製品、アプリケーションプログラム等の入替え又はその入替え時に発生する一連の行為のまとまり」と定めています。*1 つまりシステム更改は、機器やソフトを新しいものに替えることだけでなく、替えるために必要な計画・移行・切り替えまでをひとまとめにした言葉です。
- 対象：サーバーなどの機器、OSやデータベースなどのソフトウェア製品、業務のアプリケーション
- 中身：入れ替えそのものに加え、移行の準備、データの移し替え、テスト、切り替え、古い機器の片づけまでを含む
- 単位：政府のガイドラインは、更改を元のプロジェクトとは別の「後続プロジェクト」として分けて管理するとしています*2
社内では新しいシステムを「次期システム」と呼んで計画することも多く、ふだんの小さな直しとは別の、予算と体制を組み直す大きな仕事として扱われます。
刷新・リプレース・改修との違い
現場では、更改・刷新・リプレース・改修が混ざって使われます。同じ用語集は、機能改修を「設計された仕様を変更又は追加し、当該情報システムに改変を加える行為」、保守を「情報システムを設計された仕様どおりに動作させることを目的とした行為」と定めています。*1 刷新とリプレースには用語集の定義はありませんが、一般には次のような意味で使われています。
| 言葉 | 何を変えるか | いまのシステムとの関係 |
|---|---|---|
| 更改 | 機器・ソフトウェア製品・アプリケーションを入れ替える。移行や切り替えの作業を含む | 新しいものに置き換わる |
| リプレース | 機器やソフトを新しいものに置き換える。英語の「replace」から来た言葉で、更改とほぼ同じ意味で使われる | 新しいものに置き換わる |
| 刷新 | 仕組みの作りや業務のやり方まで見直して作り直す。入れ替えより変える範囲が広い場面で使われる | 考え方から作り直す |
| 改修 | いまのシステムの仕様を変えたり、機能を追加したりする | いまのシステムを使い続ける |
| 保守 | 仕様どおりに動き続けるよう、不具合を直したり部品を交換したりする | いまのシステムを使い続ける |
見分けるときは「いまのシステムを使い続けるのか、置き換えるのか」を先に考えると迷いません。置き換えるなら更改かリプレース、仕組みから見直すなら刷新です。置き換えるときの方式（そのまま載せ替えるか、作り直すか）はリホスト・リライト・リビルドの違いで扱っています。
なぜ更改が必要になるのか
政府のガイドラインは、情報システムの改善を検討するきっかけとして7つの事由を挙げています。*2 そのうち、民間の会社でも更改の話が出やすいのは次の4つです。
- 法令や制度の変更、業務環境の変化などで、業務が大きく変わるとき
- サーバーなどのハードウェアの耐用年数が過ぎるとき
- ハードウェアやソフトウェア製品のリース期間が終わるとき
- OSやデータベースなどのソフトウェア製品のサポート期間が終わるとき
ただし、きっかけがあるだけで更改が決まるわけではありません。同じガイドラインは、まず機能改修で対応できるかを検討し、機能改修では対応できないとき、または機能改修よりも更改のほうが経済的なときに更改を検討するとしています。*2 改修で済むか、置き換えるかを費用と期間で比べることが、更改の最初の判断です。
システム更改の進め方
システム更改は、新しい機器を選ぶ作業より、いまのシステムの中身を確かめる作業から始めます。次の4つの段階で進めると、移行の途中で抜けに気づいて手戻りすることを減らせます。
- ステップ1：いまのシステムの機能・データ・つながっている先を洗い出す
- ステップ2：入れ替える範囲と方式を決め、費用と期間を見積もる
- ステップ3：データ移行とテストを行い、切り替えの手順を固める
- ステップ4：本番を切り替え、古い機器のデータを消してから廃棄する
ステップ1では、使われていない機能や業務まで新しいシステムに持ち込まないよう、続ける必要があるかどうかも判断します。ガイドラインも、更改や機能改修のときは既存のサービスや業務を続ける必要があるかを判断するとしています。*2 ステップ4では、古い機器やソフトの利用を止め、情報セキュリティの観点を踏まえて廃棄か再利用に取り組むことが求められています。*2 費用の内訳はシステムリプレイスの費用の内訳にまとめています。
外部に頼むときに確認しておきたい点
システム更改は、いまの保守会社とは別の会社が新しいシステムを作ることもあります。ガイドラインは、更改のときに運用や保守を担ってきた事業者から、次のシステムを作る事業者へ作業の経緯や残っている課題を伝えさせるとしています。*2 外部に頼むときは、次の点を見積もりの前に確かめておきます。
- 引き継ぎ：いまの保守会社から、設計書・作業の経緯・残っている課題を受け取れるか
- 範囲：機器の入れ替えだけか、アプリケーションの作り直しやデータ移行まで頼むのか
- 移行の確かめ方：移す前と後のデータ件数や金額をどう照らし合わせるか
- 切り替えの計画：本番の切り替え日、うまくいかないときに元へ戻す手順があるか
- 更改の後：新しいシステムの保守を誰が受け持ち、次の更改に向けた記録を残すか
特に引き継ぎは、いまの保守会社との契約の中で協力を頼めるかどうかで進めやすさが変わります。更改の話が出た段階で契約の内容を確かめておくと、引き継ぎの段取りを早めに組めます。
まとめ：システム更改で確かめておきたい3つの点
システム更改を計画するうえで、確かめておきたい点は3つに整理できます。第一に、いまのシステムを使い続けるのか置き換えるのかを決め、改修で済む話かどうかを費用と期間で比べること。第二に、いまのシステムの機能やデータを洗い出し、続ける必要のない業務まで持ち込まないこと。第三に、いまの保守会社から作業の経緯と残っている課題を受け取れるよう、早めに段取りをつけることです。この3点を踏まえておけば、「入れ替えてみたら、前のシステムでしていた処理が抜けていた」という事態を避けやすくなります。範囲の決め方や移行の進め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
保守会社を替えるだけでもシステム更改にあたりますか
システムをそのまま使い続けて保守の担当会社だけを替える場合は、更改ではありません。政府のガイドラインも「更改を伴わない事業者の交代」を別に扱い、交代前の事業者から作業の経緯や残っている課題を引き継ぐよう求めています。*2
システム更改の費用は改修や新規開発と分けて考えますか
政府のガイドラインの経費区分では、新規開発・機能改修・更改はどれも「整備経費」という一時的な経費にまとめられています。*2 毎年かかる運用や保守の費用とは分けて予算を組み、何年ごとに入れ替えるかを見越して計画しておくと、急な出費を避けやすくなります。
クラウドへ移すこともシステム更改と呼びますか
自社のサーバーで動かしていたシステムをクラウドの環境へ移す場合も、機器や置き場所を入れ替える作業なので、更改として計画されることがあります。アプリケーションをそのまま移すのか、作り直すのかで手間が大きく変わるため、方式を先に決めてから見積もりを取ると比べやすくなります。
システム更改の計画と移行のご相談
いまのシステムの洗い出しから、改修と更改の比較、データ移行と切り替え、更改後の運用保守まで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：デジタル庁「標準ガイドライン群用語集」（https://www.digital.go.jp/resources/standard_guidelines）。出典：用語「更改」「機能改修」「保守」の定義を参照（デジタル社会推進標準ガイドラインの掲載ページから入手）（2026年10月確認）
- *2 参考：デジタル庁「デジタル・ガバメント推進標準ガイドライン（DS-100）」2026年6月12日（https://www.digital.go.jp/resources/standard_guidelines）。出典：更改を後続プロジェクトとして管理すること、情報システムの改善を検討する事由、機能改修と更改の判断、既存業務の継続必要性の判断、廃止・更改時の廃棄、更改時の事業者からの情報提供、更改を伴わない事業者の交代、経費区分（整備経費）の記述を参照（2026年10月確認）
