生産管理システムの老朽化｜リプレース判断を6変数で採点する

生産管理システムの老朽化は、画面が固まるとか、処理が遅いといった分かりやすい形では表れません。多くの場合、システムは今日も問題なく動いています。だからこそ判断が先送りされ、気づいたときには基盤ソフトのサポート期限が目前という状態になります。本記事で扱うのは、PLCや制御盤といったハードウェアの更新ではなく、生産管理システムそのもの、つまり業務ソフトウェアとその稼働基盤の話です。判断を感覚に任せないための採点モデルと、全面刷新以外の選択肢を整理します。

なぜ「動いている」と「大丈夫」は別問題なのか

工場のシステム更新の話をすると、ほぼ必ず同じ反応が返ってきます。「今のところ困っていない」「止まったら考える」。この判断は、設備であれば一定の合理性があります。壊れてから直せばよい設備は実際にありますし、予備品を持っておけば当座はしのげます。

しかし生産管理システムは、壊れ方が設備とは違います。摩耗して徐々に性能が落ちるのではなく、ある日を境に「直せる人が世の中からいなくなる」という形で使えなくなります。その日はメーカーが数年前から公表しており、こちらの都合とは無関係にやってきます。

サポート終了日は、こちらの都合とは無関係に決まっている

具体的な期日で見たほうが早いので、日系工場の基幹系でいまだに広く使われている2つの基盤を挙げます。

まず、旧AS/400の系譜にあたるIBM iです。IBM i 7.3の延長サポートは2026年9月30日に終了します。この日は同時にIBM i 7.4の標準サポート終了日でもあり、性質の違う2つの期限が同じ日に重なります。7.3を使っている工場も、7.4に上げてあるから安心だと考えていた工場も、同じ日に判断を迫られる構図です。

ハードウェア側にも期限があります。IBM Power9モデルの一部は、ハードウェアの標準保守終了が2026年1月31日と発表されています。ソフトウェアのサポート期限とハードウェアの保守期限は別々に設定されており、片方だけを見ていると計画が狂います。

Windowsサーバー上で動かしているケースも同様です。Windows Server 2016はメインストリームサポートが2022年1月に終了しており、延長サポートも2027年1月12日に終了します。その後は延長セキュリティ更新（ESU）という有償の仕組みが残りますが、これは年を追うごとに段階的に高額化する設計になっています。つまりESUは「使い続けるための手段」ではなく、「移行を終えるまでの時間を金で買う仕組み」です。

これらの日付を並べて分かるのは、2026年から2027年にかけて、日系工場の基幹系が乗っている土台の期限が集中しているということです。同じ時期に多くの企業が同じ判断を迫られるため、移行を請け負える技術者の確保が難しくなることも想定しておいたほうがよいでしょう。

「生産中止」と「保守切れ」は、痛みの出る場所が違う

制御機器の世界には「生産中止」と「修理対応終了」という2つの期限があり、実務上のリスクは後者で立ち上がります。これは設備側の話ですが、ソフトウェアでも構造はよく似ています。

違うのは、代替手段の有無です。PLCであれば、生産中止になった型番でも中古市場や修理専門業者という逃げ道が一定期間は残ります。現物が存在する以上、探せば見つかる可能性があるからです。ところがソフトウェアの保守切れには、この「探せば見つかる」がありません。セキュリティ更新は市場に流通しませんし、脆弱性が公表された後に自力で塞ぐことは現実的ではありません。

もう一点、影響範囲も違います。設備の制御機器が止まれば、止まるのはその設備、あるいはそのラインです。生産管理システムが止まれば、受注も、指示も、実績も、出荷も同時に止まります。工場全体が紙とExcelでの応急運用に落ちる、という形で影響が出ます。

「2025年の崖」は終わっていない

経済産業省が提起した「2025年の崖」は、名前の印象とは裏腹に、2026年になっても解消していません。2026年1月時点の分析では、日本の大企業の74%がいまだ老朽化したITシステム、いわゆるレガシーシステムを保有しているとされています。

この74%という数字の読み方には注意が必要です。これは「74%の企業が危険な状態にある」という意味ではありません。むしろ読み取るべきは、レガシーを抱えたまま運用し続けている状態が例外ではなく標準だ、という点です。自社だけが遅れているわけではない。ただし、期限が来るタイミングは各社の事情とは無関係に決まっているので、標準的であることは安心の材料にはなりません。

前向きな動きもあります。JFEスチールは2026年2月、全製鉄所・製造所の基幹システムをオープン環境へ完全移行したと発表しました。規模も体制もタイの工場とは前提が違うため、そのまま参考にできる事例ではありませんが、長期の計画を立てて実行すれば移行は完了する、という当たり前の事実を示す例ではあります。

老朽化のサインは、技術指標ではなく運用の摩耗に出る

システムの老朽化を判断しようとすると、多くの方はまず技術的な指標を探します。稼働年数、レスポンス時間、ディスク使用率。しかしこれらの指標は、老朽化の初期段階ではほとんど動きません。動いているのに古い、という状態が長く続くからです。

先に出るのは、運用の摩耗です。システムそのものではなく、システムの周りで人が払っている労力が静かに増えていきます。次の4つは、リプレース検討のサインとして実務的によく挙げられるものです。

サイン1 現場がExcelで補完するのが常態化している

生産管理システムが導入されているのに、実際の計画は誰かのExcelで立てられている。システムには結果だけを後から入力している。この状態は、老朽化のサインとしては最も分かりやすいものです。

ここで見るべきは、Excelを使っていること自体ではありません。Excelは優秀な道具ですし、システムに載せるべきでない検討作業はいくらでもあります。問題は、そのExcelが「システムでできないこと」を埋めるために存在しているかどうかです。要求が変わったのにシステムが追随できず、その差分を人が手作業で埋めている。この構造ができあがっていると、システムの実質的な機能はExcelを作っている個人に移っています。

サイン2 新機能の見積もりが毎回高騰し、要望を諦めることが増えた

以前と同程度の改修を頼んだはずなのに、見積もりの桁が一つ上がって返ってくる。しかも金額の根拠がよく分からない。この現象には、たいてい技術的な理由があります。

長く使われたシステムは、改修のたびに例外処理が積み重なります。ある機能に手を入れるとどこに影響が出るか、誰も全体像を把握できていない。だからベンダーは影響調査とテストの工数を厚く積みます。金額が上がっているのはベンダーが足元を見ているからではなく、変更の危険度が実際に上がっているからです。

そして本当の問題は、金額そのものではなく、その先で起きることです。見積もりが高いので要望を取り下げる。取り下げた要望は現場のExcelに回る。サイン1が悪化します。この2つは連動しています。

サイン3 ベンダーの保守担当者が減り、対応が遅くなった

問い合わせへの返答が遅くなった、担当者が代わった、以前は即答だったことを持ち帰るようになった。こうした変化は、ベンダー側でそのシステムを理解している技術者が減っていることの表れであることが多いです。

古い技術の担い手は退職や配置転換で減っていきます。ベンダーとしても、新規案件のない技術に若手を育てる投資はしにくい。悪意の話ではなく、構造の話です。契約上の保守期限がまだ先だとしても、実質的に対応できる人がいなくなれば、契約書の日付にはあまり意味がありません。

サイン4 セキュリティの社内監査に引っかかり始めた

本社のIT部門やグループの内部監査で、これまで指摘されなかった項目が指摘されるようになる。使用しているOSのバージョン、暗号化方式、パスワードポリシー、ログの保存期間。

このサインが厄介なのは、期限が外から降ってくる点です。技術的にはあと数年動かせるとしても、監査で「次回までに是正」と書かれれば、その期日が実質的なサポート期限になります。しかも監査の是正期限は、たいてい移行に必要な期間より短く設定されます。

4つのサインに共通するのは、どれもシステムの障害としては記録されないことです。稼働率は100%のまま、周りの人の負荷だけが上がっていきます。だから稼働率を根拠に「問題ない」と報告され続けます。

リプレース判断の変数採点モデル

サインの有無を感覚で語ると、立場によって結論が変わります。現場は「限界だ」と言い、経理は「まだ使える」と言う。どちらも誠実に言っているのに噛み合わないのは、測る物差しが共有されていないからです。

そこで、6つの変数を0点から3点で採点し、合計0点から18点で判定する形に落とします。まず変数の一覧です。

以下、変数ごとに採点基準を示します。自社の値を当てはめながら読んでください。数字が分からない変数は、分からないという事実自体が採点材料になります。

変数1 サポート期限までの残り年数

OS、データベース、ミドルウェア、ハードウェア保守のうち、最も早く期限が来るものを基準にします。全部を確認しないまま「まだ大丈夫」と答える工場が多い変数です。

期限を調べる際は、契約書ではなくメーカーの公表資料を見てください。ベンダーとの保守契約が続いていても、その裏で基盤メーカーのサポートが切れていれば、ベンダーは重大な問題を直せません。

変数2 障害復旧時間の悪化度

絶対値ではなく推移で測ります。もともと復旧に半日かかるシステムでも、それが変わっていないなら老朽化のサインではありません。

3点に該当する場合、多くはシステムの問題ではなく、構造を理解している人がいなくなっている問題です。この場合、部分的な改修では解決しません。

変数3 Excel補完の範囲

「Excelを使っているか」ではなく「Excelが業務のどこを担っているか」で測ります。

3点の状態は、システムを入れ替えても自動的には直りません。むしろリプレース時に最も工数を食う部分になります。誰か個人のExcelに載っている判断ロジックを、要件として言語化する作業が必要になるためです。

変数4 ベンダー保守体制の縮小度

聞きにくい話ですが、率直に確認する価値があります。「このシステムを担当できる技術者は御社に何名いますか」と尋ねて、即答が返ってこない場合は、実質的に少人数へ依存していると考えたほうが安全です。人数を把握していれば即答できる質問だからです。

変数5 セキュリティ監査の指摘

本社IT部門、グループ内部監査、顧客監査のいずれかで指摘を受けているかを見ます。指摘の重さより、是正期限が設定されているかどうかが重要です。

変数6 周辺システムとの連携要求

今後2年以内に、そのシステムと何かをつなぐ必要があるかを見ます。本社の統合基幹システムへの接続、顧客からのEDI要求、設備からの実績自動収集、いずれも典型的な要求です。

以上6変数を採点したら、合計点を次の帯に当てはめます。

この表には1つ例外規則があります。変数1が3点、つまりサポート期限が1年未満か既に超過している場合は、合計点に関わらず最低でも「予算化」として扱ってください。他の変数が良好でも、期限そのものは交渉できないためです。

逆の例外はありません。変数1が0点でも、変数3と変数4が揃って3点なら、それは技術的な期限より先に運用が破綻している状態です。期限に余裕があることは、他の問題を打ち消しません。

9点と10点のように帯の境目に来た場合は、点数を押し上げている変数が「今の話」なのか「今後の話」なのかで分けてください。変数1と変数5は期限が外から決まる変数なので、これらが高いなら上の帯として扱うのが安全です。逆に変数6の連携要求が「検討中」の段階で点数を押し上げているなら、その計画が意思決定されるまでは下の帯に置いて構いません。

モデル工場で採点してみる

抽象論を続けても仕方がないので、よくある条件の工場を1つ立てて採点します。

チョンブリ県の日系電子部品メーカー、従業員240名。15年前に日本の親会社の仕組みを移植する形で生産管理システムを構築し、以後は部分的な改修を重ねてきました。基盤はWindows Server 2016です。

合計は12点で、判定は「予算化」です。加えて変数1が3点なので、例外規則からも同じ結論になります。この工場が取るべき行動は、次年度予算への計上と、体制・時期の決定です。

注目したいのは、この工場のシステムが今日も普通に動いている点です。障害は増えていません。稼働率だけを見れば健全です。それでも12点が付くのは、期限、運用、体制、要求という4方向から同時に圧力がかかっているからです。採点モデルの価値は、この「どこも壊れていないのに限界が近い」状態を数字で示せるところにあります。

全面リプレースだけが答えではない

採点で高い点数が出たとしても、直ちに全面刷新という結論にはなりません。2026年時点で主流になっているモダナイズ戦略は、むしろ逆方向です。

現在の現実解とされているのは、コアの業務ロジックは温存し、周辺機能だけをクラウドで拡張するハイブリッド構成です。長年かけて作り込まれた原価計算や生産計画のロジックはそのまま残し、API、画面、分析、AIといった周辺部分を新しい基盤側で作る。全面移行より段階移行のほうが現実的である、という判断が広く共有されるようになりました。

理由は単純で、全面移行の失敗確率が高いからです。15年動いてきたシステムには、誰も文書化していない業務ルールが埋まっています。それを全て掘り起こして新システムに再実装する作業は、見積もりが最も外れやすい部類の仕事です。

打ち手は実務上、次の4つに整理できます。

それぞれに固有の落とし穴があります。費用の安さだけで選ぶと後で高くつくのは、設備更新と同じです。

保守契約の延長は、単独では選択肢になりません。時間を買っているだけなので、買った時間で何をするかが決まっていなければ、来年また同じ判断を繰り返すことになります。

パッケージとスクラッチのどちらを選ぶかは、それ自体が独立した論点です。判断軸を整理したものとして、生産管理システムはパッケージとスクラッチのどちらを選ぶべきかを比較した記事があります。老朽化の判定で「移行」まで決まった段階で、次に読むべきはこちらになります。

リプレースにかかる期間と費用の現実

期間について、押さえておくべき数字が1つあります。EOSL、つまりサポート終了の告知を受けてから本番稼働までは、生産管理システムのリプレースで現実的に12〜18か月かかります。

この12〜18か月という数字は、決裁が順調に進み、要件がおおむね固まっている前提の期間です。稟議が一度差し戻されれば、そこで数か月が消えます。

先ほどのIBM i 7.3の例で考えてみます。期限は2026年9月30日です。12〜18か月という所要期間を当てはめると、この期限に間に合わせるためには、既に着手済みでなければならない計算になります。今から検討を始める場合、間に合うかどうかではなく、期限を超過する前提でどう凌ぐかという話から始まります。

期間が長くなる理由の内訳も知っておく価値があります。最も時間を食うのは、システムの構築ではなく現行業務の棚卸しです。何が仕様で、何が運用の工夫で、何が単なる惰性なのか。この切り分けに一番時間がかかります。次に長いのが、並行稼働と移行判定の期間です。生産管理システムは月次で締める業務が多いため、少なくとも数回の締めを新旧両方で回して結果を突き合わせる必要があります。

費用については、一律の相場を示すことに意味がありません。工場の規模、業務の複雑さ、現行の文書化状況、移行するデータの量によって桁が変わるためです。ただし、費用の内訳がどう積み上がるかという構造には共通のパターンがあります。初期費用よりも、稼働後に毎年発生する費用のほうが総額では大きくなることが多い、という点も含めて、工場のシステム保守費用の内訳を分解した記事で詳しく扱っています。老朽化したシステムの延命費用と、新システムの5年総額を同じ土俵で比べる際の材料になります。

もう1つ、期間と費用の両方に効く判断が、新しい基盤をクラウドに置くかオンプレミスに置くかです。老朽化を機にクラウドへ移す工場は増えていますが、タイの工場では回線品質や本社の方針との兼ね合いで、必ずしもクラウドが正解になるとは限りません。この判断軸は生産管理システムのクラウドとオンプレミスを比較した記事にまとめています。

タイの日系工場ならではの論点

ここまでは日本の工場にも共通する話でした。タイに拠点を持つ場合、これに固有の材料が加わります。

期限が来ても現地で買い足せない

日本国内であれば、古い基盤の保守を引き受ける専門業者や、中古のハードウェアを扱う市場が一定の厚みを持って存在します。タイでは、同じ世代の機器や同じ技術に対応できる業者を現地で見つけられる確率が下がります。日本やシンガポールから調達する場合、通関と輸送で日数が積み上がります。

この差は、4択のうち「保守契約の延長」を選んだときに効いてきます。日本の本社が同じ判断で延命しているからといって、タイの拠点で同じ手が使えるとは限りません。延命策の実現可能性は、拠点ごとに確認する必要があります。

現地エンジニアの確保という制約

古い技術を扱える技術者の不足は、日本以上に深刻です。20年前の技術で書かれたシステムを保守できるタイ人エンジニアを新規に採用しようとしても、候補者が見つかる見込みは高くありません。

これは裏返すと、リプレースの副次的な価値になります。新しい基盤へ移すことは、単に期限を回避する作業ではなく、採用可能な人材のプールを広げる作業でもあります。現行システムの保守を特定の1名に依存している状態が続いているなら、その解消も投資対効果の一部として計上してよい項目です。

本社標準と現地最適の両立

タイの工場で最も難しいのが、この論点です。本社が統合基幹システムへの集約方針を出している一方で、現地には現地の商習慣に合わせた運用があります。タイ固有の税務要件、顧客ごとの納入指示の形式、現地サプライヤーとのやり取りの実態。これらを本社標準に押し込むと現場が回らなくなり、現地最適を貫くと本社への報告が作れなくなります。

現実的な落としどころは、どこで分けるかを最初に決めることです。財務会計と原価は本社標準に寄せ、生産指示と実績収集は現地最適を許す、といった線引きを、要件定義の前に合意しておく。この合意がないまま進めると、要件定義のたびに同じ議論が蒸し返され、期間が延びます。

ここでもハイブリッド構成の考え方が効きます。本社標準に接続するための部分だけを新しい基盤で作り、現地の業務ロジックは既存資産として残す。全てを一度に揃えようとしないほうが、結果的に早く到達します。

言語と引き継ぎ

移行時に作成する文書を、どの言語で残すかも決めておく必要があります。日本語だけで作られた設計書は、日本人担当者の任期が終わった時点で読める人がいなくなります。タイの拠点では日本人管理者の入れ替わりが数年単位で起きるため、この問題は日本国内の工場より速く進行します。

最低限、運用手順と障害対応の手順はタイ語または英語でも残すことをおすすめします。せっかく新しくした基盤が、5年後にまた「誰も中身を知らないシステム」になることを防ぐための、比較的安価な保険です。

移行を任せる相手をどう選ぶか

依頼先の選定について、細かい評価項目を並べる前に、実務的な足切り基準を3つだけ挙げます。

1つ目は、現行システムを読み解けるかどうかです。新しいものを作る能力と、古いものを解読する能力は別のスキルです。移行案件で本当に必要なのは後者で、ここが弱い相手に頼むと、現行機能の洗い出しが全て自社側の負担になります。提案の段階で、現行システムの調査をどう進めるつもりかを具体的に説明できるかを見てください。

2つ目は、タイ国内で保守を完結できる体制があるかどうかです。構築は日本のチームが担当し、稼働後の保守も日本から対応する、という体制は、時差と出張の制約から現実には機能しにくくなります。夜間バッチが落ちたときに誰が対応するのか、その人はどこにいるのかを、契約前に確認してください。

3つ目は、段階移行の提案ができるかどうかです。相談の初回から全面刷新の見積もりしか出てこない場合、その相手は選択肢を検討していません。ハイブリッド延命という選択肢を含めて比較した上で全面刷新を勧めているのか、それとも最初から一択なのかは、提案書の構成を見れば分かります。

タイでの開発会社の選び方については、契約形態やコミュニケーション体制まで含めてタイのシステム開発会社の選び方をまとめた記事で整理しています。相見積もりを取る段階に入った方は、そちらもあわせてご覧ください。

なお、選定を始めるタイミングについて1点だけ。採点が「計画立案開始」の帯であっても、相談自体は始めて構いません。この段階で聞くべきなのは見積もりではなく、自社の条件でどの選択肢が成立しうるかという情報です。見積もりを先に集めると、提案されたスコープに引きずられて自社の判断が歪みます。順序は、判定、選択肢の絞り込み、見積もりの取得です。

よくある質問

生産管理システムはいつリプレースを検討すべきですか

きっかけとして最も分かりやすいのは、基盤ソフトやハードウェアのサポート終了が公表されたときです。ただし公表を待つ必要はありません。本記事の6変数を採点し、合計が5点以上になった段階で、選択肢の比較と概算見積もりの取得を始めるのが現実的です。

期間の面から逆算する方法もあります。リプレースには12〜18か月かかるため、最も早い期限の2年前が実質的な着手期限になります。この2年という余裕は、稟議の差し戻しや担当者の異動といった、計画には書けない事情を吸収するための幅です。

サポート切れのまま使い続けるとどうなりますか

すぐに動かなくなるわけではありません。多くの場合、システムは何事もなかったかのように動き続けます。これが判断を難しくしています。

変わるのは、問題が起きたときの選択肢です。セキュリティの脆弱性が公表されても修正プログラムが提供されない。障害が起きてもメーカーに問い合わせられない。ハードウェアが故障しても保守部品が出てこない。いずれも平常時には表面化せず、最も困るタイミングで顕在化します。

加えて、顧客監査や本社監査での扱いが変わります。サポート切れの基盤で基幹業務を動かしている状態は、多くの監査基準で明確な指摘事項になります。技術的なリスクより先に、この社内・社外の要求のほうが期限として効いてくるケースが少なくありません。

リプレースの費用はどれくらいかかりますか

規模と現行の状況によって桁が変わるため、相場という形で示すことはできません。同じ規模の工場でも、現行システムの文書化が進んでいるかどうかだけで、調査工数が数倍変わります。

現実的な進め方は、他社の相場を探すことではなく、自社について2つの数字を並べることです。1つは、現行システムを今後5年延命した場合の累計費用。ESUのような有償サポート、増えていく改修費、Excel補完に費やされている人件費を含めます。もう1つは、新システムの5年総額です。この2つを同じ土俵で比べれば、相場を知らなくても判断できます。費用の内訳の作り方はシステム保守費用を分解した記事を参照してください。

全面リプレース以外に延命する方法はありますか

あります。2026年時点で主流になっているのは、コアの業務ロジックを温存し、周辺機能だけをクラウドで拡張するハイブリッド構成です。全面移行より段階移行のほうが現実解とされており、長年作り込んだロジックを捨てずに済むという利点があります。

ただし、この方法が成立する条件があります。コアの業務ロジック自体が今も有効であること、そしてコアが載っている基盤の期限にまだ余裕があることです。基盤の期限が1年を切っている状態では、コアを温存したくても土台のほうが先に切れます。この場合はハイブリッドではなく、まず基盤の移行が必要になります。

まとめ

生産管理システムの老朽化は、稼働率では測れません。判断の要点を整理すると次のようになります。

システムが動いていることと、安全であることは別の問題です。IBM i 7.3の延長サポートは2026年9月30日に終了し、同日はIBM i 7.4の標準サポート終了日でもあります。IBM Power9モデルの一部はハードウェア標準保守が2026年1月31日に終了し、Windows Server 2016の延長サポートは2027年1月12日に終了します。日本の大企業の74%がいまだレガシーシステムを保有しているという状況は、標準的ではあっても安全ではありません。

老朽化のサインは技術指標ではなく運用の摩耗に出ます。Excel補完の常態化、見積もりの高騰、ベンダー保守体制の縮小、セキュリティ監査の指摘。この4つはいずれも障害としては記録されないため、稼働率を根拠にした「問題なし」の報告と共存します。

判断は6変数の採点で構造化できます。サポート期限までの残り年数、障害復旧時間の悪化度、Excel補完の範囲、ベンダー保守体制の縮小度、セキュリティ監査の指摘、周辺システムとの連携要求。合計点で様子見、計画立案開始、予算化、即時着手の4段階に振り分けます。ただしサポート期限が1年未満なら、合計点に関わらず予算化として扱ってください。

打ち手は全面刷新だけではありません。保守契約の延長、ハイブリッド延命、パッケージへの全面移行、スクラッチ再構築の4択で比較します。2026年時点の現実解は、コアを温存して周辺をクラウドで拡張するハイブリッド構成です。

そして期間です。EOSLの告知から本番稼働まで12〜18か月かかります。この数字を知っているかどうかで、着手のタイミングが1年変わります。

自社のシステムが今どの帯にいるのか、延命と移行のどちらが妥当なのか、判断に迷われている段階でも構いません。基盤のバージョンと、現在発生している運用上の負荷が分かれば、6変数での一次採点と、成立しうる選択肢をお返しできます。見積もりの前段階のご相談として、お問い合わせページからお気軽にお声がけください。タイでの導入と移行の経験をもとに、過剰にも先送りにもならない範囲をお伝えします。

参考情報

• IBM i 7.3の延長サポート終了とIBM i 7.4の標準サポート終了について

https://www.c3index.co.jp/blog/blog_3456/

• IBM Power9モデルのハードウェア標準保守終了について

https://www.c3index.co.jp/blog/blog_3082/

• AS/400・IBM i モダナイゼーションガイド2026 – Aurant Technologies

https://aurant-technologies.com/blog/as400-ibm-i-modernization-guide-2026/

• Windows Server 2016のサポート終了に向けた計画 – Microsoft

https://www.microsoft.com/en-us/windows-server/blog/2026/02/25/planning-ahead-for-windows-server-2016-end-of-support/

• 保守期限切れのリスク、リプレースに要する期間、検討開始の実務的なサイン – ベンチャーネット

https://www.venture-net.co.jp/netsuite/risk-of-expiry-of-maintenance/

• 「2025年の崖」は2026年も終わっていない – ITmedia エンタープライズ

https://www.itmedia.co.jp/enterprise/articles/2603/30/news017.html

• 全製鉄所・製造所の基幹システムをオープン環境へ完全移行 – JFEスチール

https://www.jfe-steel.co.jp/release/2026/02/260226.html