基幹システムの刷新判断｜作り直すかAIで延命するか、5つの確認と費用・期限【2026年9月最新】

基幹システムを作り直すかどうかは、古さではなく「保守の終わりの日付」と「困りごとが基幹システムの中にあるか、外にあるか」で決まります。保守の終わりまで3年以上あり、困りごとが転記や集計など基幹の外にあるなら、作り直さずにAIや自動化で周りを補う「延命」の方が安く早く済み（当社なら小規模な改修30万円〜・約5週間から、税別）、保守の終わりが3年以内に迫っている・法改正に追いつけない・データを外に出せない場合は、延命では解決しないため刷新の準備（入れ替え・作り直しは開発会社各社の公開目安で数千万円・1〜2年）に入ります。

2026年から2027年にかけては、基幹システムの判断を迫られる日付が重なります。データベース製品のSQL Server 2016は2026年7月に延長サポートがすでに終了し、IBM i 7.4（AS/400の流れをくむ基盤）は2026年9月30日で標準サポートが終わります。2027年にはWindows Server 2016とSQL Server 2017の延長サポート、SAP ERP 6.0の標準保守が期限を迎えます。一方で、古いプログラムからAIで設計書を起こすサービスが国内の大手からも出てきており、「分かる人がいないから判断できない」という状況は変わり始めています。

この記事では、判断のための5つの確認、2026〜2035年の保守期限カレンダー、6つの選択肢の費用と期間、AIで延命できること・できないこと、延命と入れ替えを5年で比べる方法、当社が担当したケースを順に解説します。延命すると決めた後に、基幹システムとAIを具体的にどうつなぐかは基幹システムと生成AIを連携させる方法で解説しています。

基幹システムの刷新を迷う会社で、いま起きていること

出典: IPA（情報処理推進機構） 公式サイト

基幹システムの刷新を迷っている会社では、次のような状況がよく重なっています。

• 保守会社から「来年度で保守を終了します」「保守料を上げます」と通知が来た
• 基幹システムのことが分かる担当者が社内に1人、保守会社側にも1人しかおらず、その人が休むと障害対応が止まる
• インボイス制度や電子帳簿保存法など、法改正のたびに改修の見積が届き、対応が期日ぎりぎりになる
• 基幹システムで足りない部分を部門ごとのExcelで補い、月末にCSV（表計算ソフトで開ける形式のファイル）を出して加工し、別のシステムへ手で書き写している
• 新しく入れたクラウドサービスやAIとつなごうとしたら、「今のシステムにはデータを出す口がない」と言われた
• 取引先との受発注データのやりとり（EDI）が電話回線（INSネット）経由で、切り替えを求められている
• 作り直しの見積を取ったら数千万円と言われ、比べる材料がなく判断が止まっている

こうした状況は珍しくありません。経済産業省の委員会が2025年5月にまとめたレガシーシステムモダン化委員会の総括レポート（約4,000社に調査、799社が回答）では、老朽化・複雑化・ブラックボックス化によって運用や改良が難しくなっている「レガシーシステム」を持つ企業が61%、大企業に限ると74%でした。中小企業でも約5割です（デジタル庁ニュースによる要約）。IPA（情報処理推進機構）の「DX動向2025」でも、日本企業の15.5%が「ほとんどがレガシー」、16.8%が「わからない」と答えており、IPAは「レガシーシステムの刷新が頭打ち」とまとめています。

同じ経産省の調査では、刷新を決めたきっかけの上位は「大規模なシステム障害」「保守要員の離脱」といった受け身の理由でした。多くの会社は、困ったことが起きてから刷新を考え始めています。 判断を先送りにするほど、残された時間の中で選べる方法は少なくなります。

「古いから作り直す」ではない

ただし、古いシステムがすべて作り直しの対象になるわけではありません。同じレポートは、メインフレーム（大型の汎用コンピューター）のような古い技術で作られたシステムでも、「開発・運用維持保守体制が整備され、デジタル技術の活用やデータ連携が可能で、仕様が明確で継続的な機能改良が可能な適切な作り」であればレガシーシステムではない、と明記しています。逆に、新しい技術へ移した後でも、保守に問題があれば再びレガシーになるとしています。

つまり判断の基準は「何年使っているか」ではなく、「いつまで保守を受けられるか」「直せるか」「分かる人がいるか」「データを外に出せるか」というシステムの状態です。次の5つの確認で、自社の状態を整理します。

刷新か延命かを決める5つの確認

確認1：保守の終わりの日付は決まっていますか

最初に確認するのは、基幹システムが動いている土台（サーバー・OS・データベース）、パッケージ製品、保守契約のそれぞれの「終わりの日付」です。1つでも期限が決まっていれば、そこから逆算して判断の締切が決まります。

入れ替えや作り直しには、開発会社各社の公開目安で1〜2年、中堅企業では検討から本稼働まで15〜30ヶ月かかります。そのため、期限までの残り年数で取れる手が変わります。

• 3年以上ある：延命を含めて、すべての選択肢を検討できる
• 1〜3年：入れ替えるなら準備を急ぐ必要がある。延長サポートを買って時間を確保するかを並行して検討する
• 1年未満、またはすでに終わっている：延長サポートや土台の更新で、まず安全を確保する

期限は契約書と保守会社への問い合わせで確認でき、社内だけで進められます。主な製品の期限は、次の章のカレンダーにまとめています。

確認2：法改正や取引先の要求に、期日内に対応できていますか

制度の変更は、基幹システムの中の計算や帳票に直接響きます。2026年1月1日には下請法が「中小受託取引適正化法（取適法）」に改まり、手形による支払いが禁止されました。支払処理や支払条件の登録を持つ基幹システムでは、対応が必要になった会社もあるはずです。2027年4月1日以後に始まる事業年度からは、新しいリース会計基準の適用も始まります（上場企業や会社法の監査を受ける会社が中心）。

こうした変更に、期日までに、納得できる費用で対応できているかを振り返ってください。毎回ぎりぎり、あるいは見積の根拠が分からないまま払っているなら、「直せる」状態が崩れ始めています。

確認3：仕様を説明できる人・設計書はありますか

IPAの「システム再構築を成功に導くユーザガイド」には、今のシステムをそのまま再現する方針で作り直しを進めたところ、「5割以上の設計書がシステムと乖離しており、有識者も存在しない」ことが途中で分かり、試験の段階で問題が多発したトラブル事例が載っています。設計書があっても、実物と合っているとは限りません。

基幹システムの移行を手がける開発会社のエクサは、次のような状態を深刻度の高い目安として挙げています（同社の経験にもとづく目安）。

• 改修のたびに、どこに影響するかを調べるだけで数週間かかる
• 中心メンバーの年齢が50代後半に集中している、または3〜5年以内に定年を迎える人が複数いる
• 保守会社に相談すると、打ち合わせが数週間先になる

分かる人も設計書もない場合、刷新するにも延命するにも、まず「今どう動いているか」を調べる工程が必要です。この調べる工程は、2026年に入ってAIで短くできるようになってきました（後述）。

確認4：困りごとは、基幹システムの中ですか、外ですか

判断を大きく分けるのが、この確認です。

「基幹システムが古いから大変だ」と感じていても、実際に時間を取られているのは基幹の外の手作業、ということは少なくありません。その場合、作り直しても周りの作業の流れを見直さなければ、同じ手作業が新しいシステムの外にも残ります。Excelで補っている業務の見直し方はExcel業務のシステム化で解説しています。

確認5：データを外に出せますか

基幹システムからCSVを出せるか、外部のシステムとデータをやりとりする受付窓口（API）があるかを確認します。データを出せれば、基幹システムに手を入れずに周りを自動化できます。出せない場合は、人の画面操作をロボットに再現させる方法（RPA）くらいしか残らず、画面が変わるたびに止まるため、延命の手段としては不安定です（RPAが動かなくなる原因）。

データを出せるかどうかは、将来の入れ替えのしやすさにも直結します。経産省のレポートも、システムの移行で最も問題が起きやすいのはデータの移行だとしています。

5つの確認の結果から、選択肢を絞る

①〜⑥の中身と費用は、後の「選択肢は6つ」の章で比べます。

基幹システムの保守期限カレンダー（2026〜2035年）

出典: Microsoft Learn 公式

中堅・中小企業の基幹システムに関わりが深い期限を、日付順に並べました。自社の基幹システムが動いている土台と、使っている製品に当てはまる行を確認してください。

出典：IBM、Microsoft、SAP、富士通、NTT東日本、中小企業庁、企業会計基準委員会の公表資料（2026年9月19日時点で確認）。SAPの延長保守の料金はSAPの発表を伝えた報道によるもので、契約ごとに異なる場合があるため、SAPや保守会社の窓口で確認してください。サーバー証明書やプログラム言語の期限など、保守費に響くその他の外部要因はシステム保守運用費の相場にまとめています。

判断の締切は、期限から逆算して決める

判断の締切は、次の式で出せます。

判断の締切 ＝ 保守の終わりの日付 －（入れ替え・作り直しにかかる期間）－（製品の選定・見積・試作にかかる期間）

たとえばSAP ERP 6.0の延長保守（2030年末まで）を使い切る前提で、パッケージへの入れ替えに2年、製品の選定・見積・試作に1年かかるとすると、判断の締切は2027年末です。これは標準保守が終わる時期と重なります。延長保守を買う会社でも、判断そのものは標準保守の終わりまでに済ませておく必要があるということです。

2035年度末の富士通メインフレームも、先の話ではありません。移行を支援するエクサは、移行できるかの検証と評価に数か月、本格的な移行に数年規模がかかるとして、「決して余裕があるわけではない」と指摘しています。

延長サポートは、次の判断日を先に延ばすためのものです。料金は割増で、期限も決まっています。延長を買うなら、その期間中に判断材料を集める計画とセットで買うのが基本です。SAPの移行先の動向はSAP Autonomous Enterpriseで解説しています。

選択肢は6つ｜使い続ける・AIで補う・設計書を起こす・一部置き換え・入れ替え・作り直し

出典: Microsoft Dynamics 365 Business Central 公式サイト

「刷新するか、しないか」の2択で考えると、判断が止まりがちです。実際の選択肢は6つあります。

「公開目安」は、開発会社各社が自社サイトで公開している目安です。基幹システムの刷新費用について、公的機関がまとめた相場の統計はありません。

このほか、使われていない機能や、他のシステムで代わりが利く機能は「やめる（廃止する）」のも正当な結論です。AWSが公開している移行の考え方でも、「今の環境で使い続ける」「廃止する」は移行の方法と並ぶ正式な選択肢に入っています。刷新ありきで考える必要はありません。

中堅・中小企業は「パッケージ・SaaSが原則」と国は示している

当社は受託開発の会社ですが、ここは正直にお伝えします。経産省のレポートは、「特に、大企業に比べて経営資源の制約の大きい中堅・中小企業は、オーダーメイドのスクラッチ開発は避け、パッケージやSaaSを原則とすべき」としています。製品と自社の業務に大きな差がある部分も、最小限の作り込みで済ませる方法を検討すべき、という立場です。

同じ調査では、今のシステムに作り込みを重ねている会社ほど、移行先でも作り込む割合が高いことも分かっています。一方でIPAのガイドは、製品と業務の差を埋める追加開発が大きくなる場合は「パッケージ製品を利用しないという判断も必要」としています。

つまり⑥の作り直しを選ぶのは、業務のやり方そのものが自社の強みで、製品に合わせると強みが失われる場合に限られます。入れ替え先を製品にするか作るかの判断は、SaaSかカスタム開発かの判断フローで詳しく解説しています。

全部を一度に作り直すほど、失敗しやすい

日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査報告書2026」（957社が回答）によると、システム開発の品質・予算・工期は、規模が大きいほど予定どおりにいかない割合が高くなります。エンジニア1人が1か月働く量を「1人月」とすると、10人月未満の案件では品質・予算・工期のいずれも、予定どおりにいかなかった割合が10%を下回ります。これが500人月以上になると、品質の不満が29.6%、予算超過が42.2%、工期の遅れが47.8%に跳ね上がります。

予定どおりにいかなかった理由の上位は「計画時の考慮不足」（予算51.0%・工期52.5%）、「想定以上の現行業務・システムの複雑さ」（予算51.4%・工期48.8%）、「仕様変更の多発」（予算48.6%・工期42.4%）でした。確認3で見た「分かる人も設計書もない」状態は、2つ目の理由に直結します。

大企業の例では、江崎グリコが2019年12月に始めた基幹システムの刷新で、当初2022年12月の完了予定が延び、投資額は215億円から342億円へ約1.6倍に膨らみました。2024年4月の切り替え直後には、倉庫の在庫数とシステム上の在庫数が合わず、一部商品の出荷を止め、全面的な再開は同年11月になりました（日経クロステックなどの報道）。規模は違っても、切り替えの瞬間と、データの移し替え・突き合わせが最大の山場になる構造は中堅・中小企業でも同じです。

中堅・中小企業の基幹システムの刷新は、公開目安の2,000万〜8,000万円（社員50〜300名規模）を1人月あたり60万〜100万円の単価で割ると約20〜130人月で、500人月を大きく下回ります。それでも、延命で時間を買い、置き換えを業務ごとに小さく分けることは、この調査結果に沿った判断です。小さく分けて発注する方法はシステム開発を段階的に発注する方法、よくある失敗の型はAI開発の失敗例で解説しています。

AIで延命できること・できないこと

出典: AWS Transform for mainframe 公式サイト

「AIで延命」と言っても、AIが古い基幹システムそのものを若返らせるわけではありません。AIにできるのは、基幹システムの周りの作業と、古いシステムを調べる作業です。

AIで延命できること

• 基幹の外の転記・集計・照合を減らす：基幹システムから出したCSVをAIで整形・分類し、別のシステムに取り込む。システム間の食い違いだけを人に回す
• 紙やPDFの内容を登録の下書きにする：注文書などを読み取り、基幹システムへの登録の下書きを作る（OCRで基幹システムへの登録を自動化する方法）
• 基幹のデータを調べて答える：在庫・納期・過去の取引など、担当者に集中している問い合わせにAIが答える
• 古いプログラムを読んで設計書を起こす：分かる人がいない基幹システムの仕様を見える化する（この章の最後で解説）

基幹システムとAIをつなぐ5つの方法（提供元のAI用の窓口、API、CSV、データの写し、画面操作）と費用の内訳は基幹システムと生成AIを連携させる方法、基幹以外も含めた既存システムへのAIの足し方と、データの扱いの注意点は既存システムにAIを組み込む方法で解説しています。

なお、新しい仕組みを作る必要はなく、毎月くり返す転記や照合をそのまま任せたいだけなら、開発ではなく定型業務をAIが代行する当社のシゴハヤエージェント（初期100万円＋月額10万円〜、税別）の方が早く始められることもあります。

AIで延命できないこと

次の5つは、周りにAIを足しても解決しません。当てはまる場合は、延命ではなく別の手を打つ必要があります。

延命には、期限と「後で作り直しになる部分」がある

延命にも限界があります。延長サポートは割増で、期限も決まっています（SAP ERP 6.0は2030年末まで、IBM i 7.4は2029年9月30日まで）。経産省も、業務の進め方を変えないままシステムを継ぎ足し続けることは、レガシー化に拍車をかけ、脱却を難しくするとしています。

また、延命のために周りに足した仕組みは、基幹システムを入れ替えたときに作り直しになることがあります。1年以内に入れ替える予定があるなら、周りには足さず、入れ替え先の製品に付いている機能を先に確認する方が無駄がありません。延命するなら「いつまで延命するか」を先に決め、その期間中に設計書の整備やデータの整理を進めておきます。

AIで設計書を起こしてから決める（2026年に出てきた選択肢）

「分かる人がいない」「設計書がない」は、これまで刷新を先送りにする最大の理由でした。2026年は、この調べる工程をAIで短くするサービスが国内大手からも出ています。

いずれも提供元や報道が公表している数字で、価格は公開されていません。中堅・中小企業の基幹システムの規模でどれだけ効くかは、個別に確かめる必要があります。

限界もあります。AWSは、実際の移行から得た教訓として、1本のプログラムだけをAIに渡すと共通部品や呼び出し先を見落とすこと、端数の四捨五入などの細かい動きが元の環境に左右され、金融のシステムでは重大な誤差になること、変換が終わってもテスト用のデータの計画がなければ先に進めないことを挙げています。AIが作った設計書や変換結果の正しさは、最終的に人が確認する前提です。

AIで大きく縮みつつあるのは「読む（調べる）」作業で、テストとデータの移し替えは残ります。 判断の前の現状調査を短くする手段として使うのが現実的です。なお、ソースコードを社外のAIに渡すことになるため、秘密保持の契約と、渡したデータがAIの学習に使われない設定を事前に確認してください。

費用の目安｜延命と刷新を5年で比べる

延命と刷新は、1年目の支払額ではなく5年の総額で比べます。延命は毎年の保守費が続き、刷新は最初の支払いが大きい一方で、その後もライセンスや保守の費用がかかるためです。

延命にかかる費用

入れ替え・作り直しにかかる費用

パッケージ・SaaSの公式価格（2026年9月時点の公式表示・税抜）は次のとおりです。

入れ替えや作り直しの総額は、開発会社各社が次のような目安を公開しています。

LASSICも明記しているとおり、これらは公的な統計ではなく各社の目安で、規模と方式によって幅があります。開発費の相場の見方は業務システムの開発費用の相場で解説しています。

5年で比べる計算例

次の条件を仮定して、5年の総額を比べてみます。

• 社員30名が使う販売・在庫の基幹システム
• 今の保守費は年300万円（開発費2,000万円の15%と仮定）
• 基幹の外で、CSVの加工と書き写しに毎月20時間かかっている（時給3,000円で換算すると月6万円・年72万円）

②では、月6万円の手作業を30万円の改修でなくせれば、約5か月で改修費を回収できる計算です。

ただし、5年の総額で延命が安く出るのは、5年間保守を受け続けられることが前提です。期限が5年以内に来るなら①②の数字は成り立たず、延長の割増か、入れ替えの費用が途中で上乗せされます。確認1とカレンダーで期限を確かめてから、この表を使ってください。自社の数字での試算方法はAI導入のROI試算で解説しています。

当社に依頼する場合の費用

当社が基幹システムの刷新判断でお手伝いするのは、主に「延命期間の周りの自動化」「判断材料を集める試作」「パッケージ・SaaSで埋まらない部分の開発」の3つです。基幹システム全体をゼロから作り直す前に、まずパッケージ・SaaSで足りるかを確かめることをおすすめしています。

クラウドの利用料、外部APIの利用料、ソフトウェアのライセンスは実費で別途かかります。既存システムの改修は、今の構成とソースコードを確認し、改修できる範囲を整理してからお引き受けします。サービスの内容と進め方は受託開発サービスのページで確認できます。PoCの費用の内訳はAI PoCの費用、30万円の改修でできる範囲はシステムの小規模改修の費用で解説しています。

実際にやった事例｜作り直さずに、周りから直したケース

守秘義務のため社名は出せませんが、当社が担当した3つのケースを、この記事の5つの確認に当てはめて紹介します。AIを使ったのは医療機関のケースです。調剤薬局とインフラ企業のケースはAIを使ったものではありませんが、「基幹システムを作り直さずに、周りから直す」構造の例として取り上げます。

調剤薬局のケース（小規模改修・約5週間）

課題：あるシステムに入力した内容を、別の管理表へ手で書き写す作業が毎日ありました。

作ったもの：一方のシステムから出力したデータを整え、もう一方の形式に変換して取り込む仕組みです。システム本体には手を入れず、出力と取込の機能だけでつなぎました。期間は、相談と仕様の確定に2週間、実装に2週間、現場での試験運用に1週間です。

変わったこと：書き写しの作業と、書き写しの誤りを確認する時間がなくなりました。確認4（困りごとは外）と確認5（データを出せる）がどちらも「はい」の典型で、本体を作り直さなくても5週間で困りごとを解消できました。

インフラ企業のケース（本開発・約7ヶ月）

課題：複数のシステムにまたがるデータを人が突き合わせて確認しており、月末に負荷が集中していました。

作ったもの：システム間のデータを自動で照合し、食い違いがあるものだけを人に回す仕組みです。期間は、要件定義に2ヶ月、実装に3ヶ月、テストに1ヶ月、移行と現場教育に1ヶ月です。

変わったこと：確認作業の総量が減り、月末に集中していた負荷が平準化されました。複数の既存システムを入れ替えずに、あいだをつなぐ仕組みを作ることで解決した例です。 要件定義に2ヶ月かかったのは、それぞれのシステムのデータの出し方を確認する必要があったためで、確認5がどれだけ期間を左右するかを示しています。

医療機関のケース（PoC・約3ヶ月）

課題：文書や記録は蓄積されているのに、必要な情報を探すのに時間がかかっていました。

作ったもの：手元の資料をAIに読ませ、質問に対して根拠となる箇所を示しながら答える仕組みです。期間は、対象の絞り込みと合格ラインの設定に2週間、データの受け取りと整形に3週間、試作と調整に5週間、現場での試用と判定に2週間です。

変わったこと：開始前に合格ラインを決めていたため、広げるかどうかを最後の2週間で判断できました。大きな投資の前に、判断材料を試作で集める進め方の例です。 延命か刷新かで迷う場合も、「どの業務で、どの水準まで改善できたら延命を選ぶか」を先に決めて試せば、試作の結果をそのまま判断に使えます。

判断から稼働までの流れと期間

1〜3は、開発会社と契約する前から社内で進められます。刷新する場合に「今と同じものを作ってほしい」という依頼で失敗しないための要件の決め方は要件定義の進め方（発注側）、開発会社への任せ方の線引きは開発会社への丸投げを避ける方法で解説しています。

また、刷新しても、設計書がない・分かる人が1人だけという状態を繰り返せば、10年後に同じ判断を迫られます。新しいシステムでは、ソースコードと設計資料を必ず自社で受け取っておいてください（システム開発の納品物）。

当社に相談いただく場合の流れ

ご相談（初回無料）→ 課題・要件の整理 → 提案・見積 → PoCまたは本開発 → 導入・改善、の順に進めます。延命か刷新かが決まっていない段階でも構いません。ご相談の前に次の4つが分かっていると、どの選択肢が合うかを早く見立てられます。すべてそろっていなくても大丈夫です。

• 基幹システムの製品名（または作った会社）と、動いているサーバー・OS・データベース
• 保守契約の終わりの日付と、保守会社からの通知の内容
• 設計書とソースコードが手元にあるか
• 今いちばん時間を取られている作業（基幹の中か、外か）

開発したシステムのソースコード（プログラムの保管場所ごと）や設計資料はお引き渡しします。進め方の詳細は受託開発サービスの進め方をご覧ください。

よくある質問

Q1. 保守会社から「保守を終了する」と通知されました。まず何をすればいいですか。

終了日を確かめたうえで、次の順に確認してください。①延長の保守を受けられるか、その費用と期限、②ソースコードと設計書がどこにあり、契約上自社が受け取って使えるか、③データをCSVなどで外に出せるか、の3つです。特に②は、保守会社が撤退した後では交渉が難しくなります。作った会社以外に保守を引き継ぐ場合、中小規模でも2〜4か月かかるのが一般的なので、終了日の半年以上前には動き出すのが安全です。引き継ぎの進め方はシステムの小規模改修の費用で解説しています。

Q2. ソースコードが手元にありません。それでも刷新の見積は取れますか。

取れますが、見積の幅は大きくなります。まず、作った会社や保守会社がソースコードを持っていないか、契約上引き渡しを求められないかを確認してください。ソースコードが手に入れば、開発会社の調査やAIで設計書を起こすサービスで仕様を見える化できます。手に入らない場合は、画面・帳票・データの中身から業務の流れを書き起こすことになり、選択肢は実質的に⑤入れ替えか⑥作り直しに絞られます。この場合、新しいシステムがこれまでと同じ結果を出すかを、実際の帳票や過去のデータと突き合わせて確かめる工程を必ず見積に入れてもらってください。

Q3. 開発会社から「AIでプログラムを自動変換するので、安く作り直せる」と提案されました。何を確認すればいいですか。

次の4つを質問してください。①変換の対象に、共通部品や呼び出し先のプログラム、共有しているファイルまで含まれているか。②今のシステムと計算結果が一致すること（特に端数の処理）を、どのデータで、誰が確かめるか。③テスト用のデータを誰がいつまでに用意するか。④ソースコードを社外のAIに渡す際の秘密保持と、学習に使われない設定がどうなっているか。変換そのものが速くなっても、テストとデータの移し替えの費用は残ります。見積の中で、変換・テスト・データの移し替えがそれぞれいくらかを分けて出してもらうと、安くなる根拠を確かめられます。

Q4. 現場から「今と同じ画面・操作のまま新しくしてほしい」と言われています。

その要望をそのまま受けると、費用が膨らみやすくなります。経産省の調査でも、刷新の障壁の上位に「今の機能を保証する・引き継ぐ制約が大きいこと」が挙がり、「今と同じ機能・操作性を求めて作り込みが増え、導入・運用のコストが高騰した」という声が寄せられています。おすすめは、「変えてはいけない結果」（計算の結果、取引先に出す書類、法令で求められる記録）と、「変えてよい手順」（画面の並び、入力の順番）を分けて書き出すことです。IPAのガイドも、製品に合わない部分の埋め方として、業務を製品の標準に合わせる方法や、システムを使わない運用で補う方法を挙げています。

Q5. 延命すると決めた場合、その期間に何をしておけばいいですか。

4つあります。①カレンダーから逆算した判断の締切日を、社内の予定として決めておく。②分かる人がいるうちに、業務の手順と、基幹システムの設定や計算ルールを文書に残す。③取引先・品目などの台帳の重複や表記ゆれを整理する（入れ替えのときに最も問題が起きやすいのがデータの移し替えのため）。④周りに足す仕組みは、基幹システムから直接ではなく、CSVやデータの写しを介してつなぎ、入れ替え後はつなぎ先を差し替えるだけで使い続けられる形にしておく。延命期間を「何もしない期間」にしないことが、次の判断を楽にします。

Q6. 基幹システムは止められません。入れ替えのときは、どう切り替えればいいですか。

一度に全部を切り替えるほどリスクが高くなるため、業務や拠点ごとに段階的に移すのが基本です。切り替えの前には、新旧のシステムで在庫数や残高などのデータが一致するかを突き合わせるリハーサルを行い、一定期間は新旧を並行して動かす計画を入れておきます。切り替え直後に問題が出たとき、手作業でどこまで補えるか、元のシステムに戻せるかも事前に決めておいてください。契約の分け方はシステム開発を段階的に発注する方法で解説しています。

Q7. 基幹システムの刷新に補助金は使えますか。

選択肢によります。「デジタル化・AI導入補助金」は、登録されたITツール（パッケージ・SaaSなど）の導入が対象のため、⑤の入れ替えでは対象になりえますが、自社専用の作り直しは対象になりにくい制度です。2026年9月時点の公式スケジュールでは、通常枠の次回締切が2026年9月29日（火）17時（交付決定は11月9日予定、事業実施と実績報告の期限は2027年4月30日予定）で、それ以降の締切は未発表です。対象になるツールの見分け方はAI導入補助金の対象ツール、申請から入金までの資金繰りは補助金の入金時期で解説しています。

Q8. 刷新か延命かを、社内の稟議でどう説明すればいいですか。

次の4つを1枚にまとめると、経営会議で判断しやすくなります。①期限の日付と、そこから逆算した判断の締切、②延命と入れ替えの5年総額（同じ条件で出したもの）、③何もしない場合に続く手作業の時間と金額、④試作で確かめる範囲と合格ライン。経産省の調査では、大規模なシステムの導入・刷新を中期経営計画に書いている企業は12%にとどまり、経営層・情報システム部門・業務部門で情報を共有している企業ほど、システムの見える化や刷新が進む傾向がありました。稟議資料の作り方は生成AI導入の稟議資料で解説しています。

基幹システムの刷新か延命かで迷っている方へ

基幹システムの刷新判断は、古さではなく「保守の終わりの日付」「直せるか」「分かる人がいるか」「困りごとが基幹の中か外か」「データを外に出せるか」で決まります。期限まで時間があり、困りごとが基幹の外にあるなら、作り直さずに周りを補う延命が安く早い選択です。期限が迫っている、法改正に追いつけない、データを出せないなら、延命期間を使って入れ替えの準備に入ってください。

• 保守会社から、保守の終了や値上げの通知が来た
• 基幹システムの周りで、CSVの加工や書き写しに毎月何十時間もかかっている
• 分かる人も設計書もなく、刷新の見積が数千万円と言われたが比べる材料がない
• 延命か刷新か、社内に説明できる判断材料がほしい

いずれかに当てはまるなら、初回のご相談は無料です。当社の価格は、小規模な改修が30万円〜、PoCが300万円〜、本開発は個別見積です（すべて税別。クラウドやAIの利用料、ソフトウェアのライセンスなどの実費は別途）。医療機関・薬局・インフラ企業での開発実績があり、要件が固まっていない段階からご相談いただけます（要件が固まっていなくても相談できる理由）。

基幹システムの製品名、保守の終わりの日付、いちばん時間を取られている作業をお聞かせいただければ、6つの選択肢のどれが合うかと、おおよその費用・期間をお伝えします。パッケージ・SaaSへの入れ替えで足りる場合や、今のまま使い続けられる場合は、開発をおすすめしません。

▶ 基幹システムの刷新か延命かを無料で相談する