基幹システムの老朽化はどう判断する？刷新すべき時期の見極め方

◆監修・編集責任者　小園 将隆　2026年9月28日

B2B EC-COLUMN

基幹システムの「老朽化」は稼働年数だけでは判断できない

「動作が不安定になってきたし、ベンダーからは保守終了の案内も届いた。ただ、何年使ったら替えどきという決まった数字があるわけでもない」――刷新の要否と時期が決めきれないのは、老朽化を稼働年数で測ろうとしているからです。
公的な整理では、年数が経っていること自体ではなく、維持保守や機能改良を行いたくても行えなくなった状態が老朽化の主な症状とされています²。
だとすれば、判断の起点は年数ではなく、その状態が決定的になる日付です。
保守サポートの終了日、仕様を説明できる担当者がいなくなる時期、取引先との接続方式が変わる時期。
外部ですでに決まっている日付を先に確定させ、そこから移行に必要な期間を差し引けば、いつ着手すべきかは逆算できます。

「古い」と「老朽化している」は同じではない

「基幹システムが古い」という言い方には、二つの違う意味が混ざっています。
一つは導入してからの年数が長いこと、もう一つは、いまの業務に合わせて直したいのに直せないことです。
この二つは重なることが多いものの、同じではありません。

経済産業省・デジタル庁・IPAのレガシーシステムモダン化委員会は、技術面の老朽化、システムの肥大化・複雑化、ブラックボックス化などによって運用・保守が困難になった既存システムを「レガシーシステム」と定義しています¹。
同じ報告書を解説したIPAの資料では、年数が経っているだけでレガシーシステムになるのではなく、維持保守や機能改良を行いたくても行えなくなった状態が主な症状だと整理されています²。
判断の対象は、経過年数ではなく、保守と改良がいまも回っているかどうかだということです。

この見方に立つと、同じ「20年稼働」でも評価は変わります。
制度改正や取引先の要求に合わせて毎年の改修が問題なく続けられているなら、少なくとも「直せない」状態ではありません。
逆に稼働7年でも、開発したベンダーが対応をやめ、社内に仕様を説明できる人もいないために改修の相談自体ができないなら、実態としては老朽化の側に寄っています。
メインフレームのような特定の技術を使っていること自体も、それだけでは判断の基準になりません。

なお、同委員会の調査では、レガシーシステムを保有するユーザー企業は61%、大企業では74%と報告されています¹。
ここでのユーザー企業とは、ベンダーにシステム開発を委託して供給を受ける側の企業を指します。
自社のシステムに引っかかりを感じている状態は、少数派の特殊な事情ではないということになります。

「直せない」を自社で起きた出来事に置き換える

定義を自社に当てはめる材料として扱いやすいのは、過去2〜3年の改修要望の記録です。
通った要望、見送った要望、システムを触らずに別の方法で済ませた要望の三つに分けてみると、いまの状態がかなりはっきり見えます。

見るべきは、見送った理由のほうです。
「業務上そこまで必要ではなかった」のであれば、それは老朽化ではなく優先順位の問題です。
一方で「技術的に対応できないと言われた」「見積もりが業務の効果に見合わなかった」「そこを触ると他の処理に影響が出るので手を入れたくない」という理由が並ぶなら、肥大化・複雑化やブラックボックス化が実務の形で表れていることになります。

たとえば、取引先から請求書に品番の内訳を足してほしいと求められたとします。
帳票の出力部分に手を入れると他の帳票にも影響が及ぶため、経理がシステムの出力を表計算ソフトに貼り直し、手作業で項目を足して送っている。
このとき、システム上は何も壊れていませんし、稼働年数も変わりません。
それでも「改良を行いたくても行えない」状態は、経理の月末の作業時間という形ですでに発生しています。

この棚卸しは、年数を数えるのと違って部門ごとに答えが割れます。
営業部門は画面が変わらないことを不便と感じていない一方で、経理や出荷の担当者だけが回避策を抱えているということは珍しくありません。
情報システム部門に上がってくる声の量と、実際に手作業で埋められている量は一致しないので、改修要望の記録だけでなく、締めや月次の作業で使われている手元のファイルまで見ておくと実態に近づきます。

出典：デジタル庁「レガシーシステムモダン化委員会 総括レポート」（2025年、ベンダーに開発を委託して供給を受けるユーザー企業が対象）

刷新すべき時期はサポート終了・保守限界から逆算する

兆候は「いつ起きるか」という形に翻訳する

IPAの解説では、モダン化を要する兆候として、ビジネスの変化に対応できないこと、サプライチェーン全体に悪影響が及ぶこと、継続的なアップデートが不可能な状態であることが挙げられています²。
どれも自社に思い当たる話ではあるのですが、そのままでは時期の判断材料になりません。
これらはすべて状態の記述であって、日付を含んでいないからです。

時期を決めるために必要なのは、この状態がいつ決定的になるのかという日付です。
そして日付には、外部ですでに決まっていて自社の都合では動かせないものと、社内の事情によって前後するものがあります。

外部で決まっているものの代表が、ベンダーの保守サポート終了日です。
ここで見落としやすいのは、期限が一つではないことです。
業務アプリケーションの保守、稼働しているOSやミドルウェアのサポート、ハードウェアの保守部品の供給は、それぞれ別の日付で終わります。
加えて、取引先から接続方式の変更を通知されている場合や、制度側の変更に合わせた改修が必要になる場合も、自社では動かせない日付として同じ列に並びます。

社内の事情で前後するのは、人の側の期限です。
現行システムの仕様を説明できる担当者が一人しかいない場合、その人の定年や異動の予定が事実上の期限になります。
この日付はカレンダーに書かれていないことが多いので、意識して書き出さないと逆算の計算から抜け落ちます。

最も早い日付が、実質の期限になる

書き出した日付が複数あるとき、刷新の期限を決めるのは、そのうち最も早いものです。
アプリケーションの保守が数年先まで続いても、載っているOSのサポートが先に切れるなら、判断を迫られるのは早いほうの日付です。

もう一つ、日付と一緒に確認しておきたいのが、その期限を過ぎたときに何が起きるのかという点です。
使い続けること自体は可能で、修正プログラムの提供だけが止まるのか。
それとも接続先の仕様変更に追随できず、その日を境に業務が流れなくなるのか。
前者は判断に幅を持たせられますが、後者は交渉の余地がありません。
同じ「期限」でも、この違いによって前倒しの度合いが変わります。

ただし、どの兆候がどのくらい重なっているかは、運用体制やシステムの構成によって会社ごとに違います。
ここで示せるのは逆算という枠組みまでで、実際の日付は自社の保守契約書と、いま誰が何を見ているかという担当者の体制を当たらないと埋まりません。
契約書の保守期間の記載と、ベンダーが公表しているサポート方針の両方を確認しておくと、更新の可否も含めて話が具体的になります。

この「日付で語る」やり方には、社内の合意を取りやすいという副次的な効果もあります。
情報システム部門は保守や改良を続けられるかという技術的な限界で考え、経営層は投資として妥当かどうかで考えるため、同じ老朽化の話をしていても噛み合わないことがあります。
期限の日付は、どちらの立場からも動かせない共通の事実として置けるので、議論の出発点になります。

先延ばしにした場合に生じるコストとリスク

刷新・更新の需要は、いま多くの企業に同時に来ている

先延ばしの判断をするとき、頭の中では「いまは他に優先することがあるから、来期以降に回す」という整理がされています。
この整理が成り立つのは、時期をずらせば条件が変わらないまま先送りできる場合です。

JUASの企業IT動向調査では、2025年度計画でIT予算が増加した理由として「既存システム・基盤の刷新・更新・増強」を挙げた企業が66.3%と最も多く、他の理由を上回っています³。
この調査は東証上場企業等を対象としたもので、中小企業にそのまま当てはまる数字ではありません。
それでも、一定規模以上の企業層で刷新・更新が予算増加の最大の理由になっているという事実は、自社の順番を考えるうえで意味を持ちます。

読み取れるのは二つです。
一つは、既存システムをどうするかという問題が、自社固有の管理不足ではなく多くの企業が同じ時期に抱えている課題だということ。
もう一つは、自社が先延ばしを決めたとしても、周囲の刷新・更新の動きが止まるわけではないということです。
同じ時期に同じ種類の更新需要が重なれば、ベンダー側の対応体制に順番待ちが生じることは考えられます。
これは調査で確認された事実ではなく、需要の集中から導いた見方ですが、期限が近い状態で相談を始めるほど選択肢が狭くなりやすい、という前提は持っておいたほうが安全です。

修正プログラムが出なくなるという状態の意味

保守サポートの終了は、サポート窓口に問い合わせられなくなることだけを指すのではありません。
脆弱性が新たに見つかっても、それを塞ぐ修正プログラムが提供されないということでもあります。

IPAの「情報セキュリティ10大脅威 2026」では、「システムの脆弱性を悪用した攻撃」が組織向けの脅威として4位に挙げられており、修正プログラムが適用されていない環境やゼロデイ攻撃が対象とされています⁵。
これは組織全般を対象とした脅威の順位であり、老朽化した基幹システムに限定した被害統計ではありません。

この順位から言えるのは、脆弱性を突く攻撃が全体として無視できない位置にあるという事実までです。
そのうえで論理として付け加えるなら、修正プログラムの提供が続いている環境では「適用が遅れている期間」がリスクの長さになるのに対し、提供が終わった環境では適用する手段そのものがないため、その状態が刷新まで続くことになります。
同じ脆弱性の公表を受けても、取れる手が残っているかどうかが違う、という違いです。

公開されていないから大丈夫だという整理は、基幹システムでは成り立ちにくくなっています。
取引先との接続、テレワーク用の経路、他システムとの連携など、外につながる口が増えているためです。
どこからも直接届かない構成になっているのかどうかは、刷新の時期を決めるより前に、ネットワークの構成図を当たって確認しておく価値があります。

金額に出てこないまま積み上がるもの

先延ばしのコストが見えにくいのは、その多くが投資の科目ではなく、日々の業務の中に散らばるからです。
前の節で触れた、帳票を表計算ソフトで作り直すような回避策がその例です。

回避策は最初は臨時の対応として始まりますが、続いているうちに手順書に書かれ、引き継ぎの対象になり、いつの間にか業務の一部として固定されます。
そうなると、刷新のときに「いまの業務」を要件として書き出す作業の中に、本来はシステムがやるはずだった手作業まで混ざり込みます。
先延ばしの期間が長いほど、刷新時にほどく必要のある運用が増えるという関係になります。

もう一つ積み上がるのが、説明できる人の少なさです。
改修が止まっているシステムは、新しく関わる人が増えないまま年数だけが進みます。
仕様が文書ではなく特定の人の記憶に残っている状態は、刷新の要件定義でそのまま効いてきます。
移行するかどうかを判断するために、まず現行の仕様を調べ直す工程が必要になるからです。

検討開始から稼働までにどれくらいの期間を見込むか

移行工程で示されている期間の目安

逆算をするには、期限から差し引く「必要な期間」の見当が要ります。
ここが最も知りたいところですが、要件定義からベンダー選定、開発、移行、稼働までを通した標準的な期間として示せる公的なデータは、今回確認できた資料の範囲にはありません。
規模や連携の範囲で大きく変わるため、一つの数字で語れないという事情もあります。

一方で、工程の一部については実務の目安が示されています。
販売管理システムのデータ移行についての解説では、移行時に6〜8週間の並行稼働期間を設け、日次のデータを新旧両方のシステムに入力して売上や売掛金残高を毎日照合することが多いとされています⁴。
また、新システムへ移す過去実績データは、直近1〜2年分の月次集計（取引先別売上、商品別売上）を目安とする、という整理も示されています⁴。

この数字を扱うときに外してはいけない条件があります。
これは販売管理システムのデータ移行という、限られた工程についての実務上の目安です。
要件定義やベンダー選定、開発を含む基幹システム刷新全体のリードタイムではありませんし、対象となるシステムの規模や連携範囲によって必要な期間は変わります。
「移行には6〜8週間あればよい」という読み方をすると、逆算そのものが狂います。

部分の目安をどう逆算に使うか

それでも、この数字は二つの使い方ができます。
一つは、期限の直前に置けない期間がどれだけあるかを知ることです。
並行稼働のような工程は、旧システムが動いていることを前提にします。
保守終了の当日まで旧システムを使う計画を立てると、照合しながら不具合を見つける期間が確保できません。
期限の手前に、動かせない幅の工程が積まれるという構造を押さえておくことが、着手時期を前倒しする根拠になります。

もう一つは、現場の負担がどこに集中するかを見積もることです。
並行稼働は、同じ伝票を新旧の両方に入力し、その結果を毎日突き合わせる期間です⁴。
つまり、この数週間は入力の手間が二重になり、加えて差異を調べる作業が乗ります。
受注が跳ね上がる繁忙期や、決算の締め作業と重ねてしまうと、照合が追いつかずに差異の原因究明が後回しになりかねません。
自社の繁忙期と決算期を先にカレンダーに置いてから、並行稼働を置ける月を探すという順番で考えると、着手時期は自然に絞り込まれます。

全体の期間については、数字を借りてくるのではなく、自社の条件でベンダーに出してもらうのが確実です。
そのとき、総額と総期間だけを聞くのではなく、要件定義、開発、データ移行、並行稼働、稼働後の立ち会いといった工程ごとに期間を分けて提示してもらうと、逆算に使える形になります。
工程別に分かれていれば、自社の期限に対してどの工程を圧縮できるのか、あるいは圧縮してはいけないのかを議論できます。

移すデータの範囲も、期間を左右します。
先の資料では直近1〜2年分の月次集計が目安とされていました⁴。
過去のすべての明細を新システムに持ち込もうとすれば、その分だけ検証の対象が増えます。
どこまでを新システムに置き、どこからを旧システムの参照や書き出したファイルで済ませるのか。
この線引きは、必要な期間と、保管や参照の運用の両方に効いてくる判断です。

出典：株式会社ripla「販売管理システムのデータ移行を成功させる5ステップ」（2026年、販売管理システムのデータ移行実務における目安）

時期を判断した後、まず着手すべきこと

要件を考える前に、日付を一枚にまとめる

時期の見当がついた後、つい先に手が伸びるのは、新システムに求める機能の整理やベンダーへの問い合わせです。
ただ、その前に済ませておくと後が軽くなるのが、ここまで書き出してきた日付を一枚の表にまとめることです。

何がいつ終わるのか、終わったときに何が止まるのか、いま誰がその情報を持っているのか。
この三つを並べた表があると、以降の判断がすべてこの表を基準に進められます。
ベンダーから提案された期間が自社の期限に間に合うかどうかも、社内で「まだ先の話だ」という意見が出たときも、同じ表を見て話せます。

この作業は、資料で手順が確認できているものではなく、逆算という考え方から導いた進め方です。
そのため、項目の並べ方は自社の事情に合わせて変えて構いません。
重要なのは、日付が一箇所に集まっていることと、その日付の出所（契約書の条項なのか、ベンダーの公表資料なのか、担当者への確認なのか）が分かるようにしておくことです。
出所が書かれていないと、時間が経ったときに誰も更新できなくなります。

止まっている改良の一覧が、次の要件の原型になる

もう一つ着手しておきたいのが、最初の節で触れた「直したいのに直せなかったこと」の一覧を、要件の候補として整理し直すことです。

見送った改修要望と、システムの外で手作業に置き換わっている処理。
この二つは、現行システムで満たせていない業務要求そのものです。
新システムの検討で機能一覧を眺めながらゼロから要件を考えるより、すでに困っていることから積み上げたほうが、自社にとっての優先順位を付けやすくなります。
同時に、これはベンダーに相談するときの材料にもなります。
「古いので新しくしたい」という依頼と、「この処理が手作業になっていて、月末に何時間かかっている」という依頼では、返ってくる提案の具体性が変わります。

立場の違いも、この段階で整理しておくと動きやすくなります。
情報システム部門が持っているのは、保守や改良を続けられるかという技術面の判断材料です。
一方、決裁をする側が必要とするのは、その期限を過ぎたときに業務と取引先にどんな影響が出るのか、いつまでに決めれば間に合うのかという情報です。
技術的な限界の説明だけを重ねても判断は進みにくいので、日付の表と、止まっている改良の一覧を一緒に示す形にすると、話が投資の判断として扱われやすくなります。

時期の判断は、一度決めて終わりではありません。
ベンダーから工程別の期間が出てくれば逆算の結果は変わりますし、保守の延長が提示されれば期限そのものが動きます。
最初にまとめた表を更新しながら進める前提で置いておけば、条件が変わるたびに一から考え直さずに済みます。

保守契約の終了日や取引先から通知された変更予定は自社で集められますが、集めた日付から逆算した着手時期が現実的かどうかは、移行の工程を実際に組んだ経験がないと判断しにくいところです。

書き出した日付と、いま手作業で埋めている業務を持ち寄っていただければ、どの工程に余裕があり、どこが最初に詰まりそうかを一緒に確認できます。無料相談で要件を整理する

刷新の時期を決めるために日付を確認する先

外部ですでに日付が決まっていて自社では動かせないものから、社内の体制によって前後するものの順に並べています。

• 業務アプリケーションの保守サポート終了日（保守契約書の記載とベンダーの公表資料の両方）

• OS・ミドルウェアのサポート終了日と、ハードウェアの保守部品の供給終了時期

• 修正プログラムの提供が現在も続いているかどうか、いつまで提供されるか

• 取引先から通知されている接続方式や帳票様式の変更予定日

• 現行システムの仕様を説明できる担当者の人数と、定年・異動の予定

• 直近数年で見送った改修要望と、見送った理由（技術上の制約か、費用か、影響範囲か）

自社開発か製品の導入かで先に埋まる欄が変わり、製品導入ならベンダーの公表資料、自社開発なら担当者の在籍状況と改修履歴が起点になります。

要点の整理

軸	基準
老朽化の判断	稼働年数ではなく、維持保守と機能改良を続けられているかで見る
期限の置き方	外部で決まっている日付のうち最も早いものを実質の期限にする
期限の重さ	過ぎても使えるのか、業務が止まるのかで前倒しの度合いを変える
先延ばしの見方	刷新・更新は多くの企業が同時に抱える課題であり、自社固有の管理不足ではない
期間の見積り	工程ごとに期間を出してもらい、動かせない幅のある工程を期限の手前に置く
着手の順番	要件を考える前に、日付の一覧と止まっている改良の一覧をそろえる

判断の材料がそろっても、社内で決裁を取る段になると、技術面の限界と投資の妥当性のどちらの言葉で説明するかによって、用意すべき資料が変わります。 期限の一覧と現状の棚卸しを見ながら、どの順で何を決めれば稼働に間に合うのか、進め方の見通しを整理できます。

よくある質問

情報システム部門と経営層とで、刷新時期の判断基準はどう違いますか

情報システム部門は、保守や機能改良を続けられるかという技術面の限界から考えます。
修正プログラムが出なくなる、改修を頼める相手がいなくなるといった、対応の手段が残っているかどうかが基準になります。
経営層が判断するのは、その支出をいつ、どの規模で行うかという投資の妥当性です。
両者が噛み合わないときは、どちらの言葉でも動かせない「外部で決まっている日付」を共通の基準に置くと整理しやすくなります。
加えて、2025年度計画でIT予算が増加した理由として「既存システム・基盤の刷新・更新・増強」が66.3%で最も多かったという調査結果³は、自社だけの突発的な支出ではないことを示す材料になります。
ただしこの調査は東証上場企業等が対象で、中小企業にそのまま当てはまる数字ではない点は添えて説明してください。

サポート終了の通知が来た場合、何を最初に確認すべきですか

最初に確認するのは、終了の対象範囲です。
業務アプリケーションの保守だけなのか、OSやミドルウェア、ハードウェアの保守部品まで含むのかで、影響の広さが変わります。
次に、終了日を過ぎたときに何が起きるのかを確認します。
使い続けること自体は可能で修正プログラムの提供だけが止まるのか、接続先の仕様変更に追随できず業務が止まるのかで、前倒しの度合いが違います。
そのうえで、延長保守が用意されているか、用意されている場合の条件と期限を確認します。
延長で得られるのは時間であって解決ではないため、延長期間の終わりを新しい期限として逆算をやり直すことになります。

刷新を検討する際、まずどのデータの現状を洗い出せばよいですか

移行対象になりうるデータの範囲から見ていくと、期間の見積もりにつながります。
販売管理システムのデータ移行についての解説では、新システムへ移す過去実績は直近1〜2年分の月次集計（取引先別売上、商品別売上）を目安とする、という整理が示されています⁴。
これは販売管理システムの移行実務での目安なので、自社のシステムで何年分が必要かは、参照される頻度や保存の要件から決めることになります。
あわせて確認しておきたいのが、そのデータが現行システムのどこに入っているかです。
画面や項目として保持されているのか、帳票の出力時にだけ組み立てられているのかで、移せる形かどうかが変わります。

並行稼働期間中に日次で確認すべき項目は何ですか

販売管理システムのデータ移行では、6〜8週間の並行稼働期間を設け、日次のデータを新旧両方のシステムに入力したうえで、売上と売掛金残高を毎日照合することが多いとされています⁴。
日次で見るのは、この突き合わせた金額が一致しているかどうかです。
差異が出たときに重要なのは、翌日に持ち越さないことです。
一日分の差異なら入力の違いか計算の違いかを追えますが、数日分が重なると原因の切り分けが難しくなります。
また、この期間は入力が二重になるぶん現場の負担が増えるので、繁忙期や決算の締めと重ならない時期に置けるかどうかも、着手時期を決める段階で見ておく必要があります。

1. 1　出典：デジタル庁（経済産業省・IPA レガシーシステムモダン化委員会）「レガシーシステムモダン化委員会 総括レポート」（2025年）
2. 2　出典：独立行政法人情報処理推進機構（IPA）「DX SQUARE ITシステムのモダン化とは？」（2025年）
3. 3　出典：一般社団法人日本情報システム・ユーザー協会（JUAS）「企業IT動向調査2026 プレスリリース第1弾」（2026年）
4. 4　出典：株式会社ripla「販売管理システムのデータ移行を成功させる5ステップ」（2026年）
5. 5　出典：独立行政法人情報処理推進機構（IPA）「情報セキュリティ10大脅威 2026［組織］」（2026年）