基幹システムの刷新判断｜延命か段階移行か、依存関係の棚卸し・移行順序と保守期限【2026年10月】

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

2026年から2027年にかけては、基幹システムの判断を迫られる日付が重なります。データベース製品のSQL Server 2016は2026年7月に延長サポートがすでに終了し、IBM i 7.4（AS/400の流れをくむ基盤）も2026年9月30日で標準サポートが終わり、10月からは有償の延長サポートの期間に入りました。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日時点で確認。MicrosoftとIBMの期限は2026年10月10日に公式ページで再確認）。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社が回答）によると、システム開発の規模が大きいほど、品質の不満・予算超過・工期の遅れの割合が高くなります（2025年度の調査）。エンジニア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で延命できないこと

次の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万円の手作業を100万円の改修でなくせれば、約17か月（1年5か月ほど）で改修費を回収できる計算です。

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

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

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

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

どこから調べればよいか決まっていない段階でも、基幹システムの製品名と、つながっている他のシステムが分かれば相談できます。初回相談は無料・30分（オンライン）で、相談後に依頼範囲の候補・進め方・費用の目安をまとめた相談メモをお送りします。

▶ 基幹システムの現状調査と段階移行の範囲を相談する

段階移行の進め方｜止められない依存関係・移行順序・並行稼働と撤退条件

刷新でも延命でも、決める前に「基幹システムを止めたら、何が止まるか」を書き出します。保守期限は日付で分かりますが、移行の順序と期間を左右するのは、基幹システムにつながっている他のシステム・帳票・取引先・担当者です。経産省のレポートが移行で最も問題が起きやすいとしているデータの移行も、どのデータを誰が使っているかが分からないと計画できません。

止められない依存関係を書き出す（記入例）

次の表は、社員30名の会社の販売・在庫の基幹システムを想定した説明用の記入例（架空）です。「基幹システムとデータをやりとりしているもの」1つにつき1行として、自社の分を書き出します。

書き出すと、「代わりの手段がない」「運用している人が1人」「社外の会社が関わる」行が見えてきます。こうした行は移行の後半に回すか、並行稼働を長めに取る対象です。逆に、代わりの手段があり、影響が社内で収まる行は、先に移して手順を確かめる候補になります。

情報の集め方は3つです。①基幹システムの出力・取込の設定と、夜間に動く処理の一覧を保守会社に依頼する、②各部門に「基幹から出したデータを何に使っているか」を聞く、③ファイルの受け渡しに使っているフォルダの中身を見る。ソースコードがあれば、外部とやりとりしている箇所をAIに洗い出させることもできます。ただし、誰が手で取り込んでいるかといった実際の運用は、コードには出てきません。

移行の順序を決める（記入例）

依存関係の表をもとに、移す順番を決めます。基本は「影響が小さく、元に戻せるものから」「データの持ち主が1つに決まっているものから」です。次も説明用の記入例（架空）です。

順番4・5のように止められない業務や社外が関わる部分は、一度に切り替えるか、業務・拠点ごとに分けるかを、取引先や倉庫の都合と合わせて決めます。前の章のJUASの調査でも、開発の規模が大きいほど予算超過や工期の遅れの割合が高くなっていました。切り替えを分けることは、1回あたりの規模を小さくすることにもつながります。

並行稼働の条件と、元に戻す条件を先に決める

並行稼働は、新旧のシステムを同じ期間に動かし、結果を突き合わせる期間です。長いほど安全ですが、その間、現場は二重に入力することになります。始める前に次の5つを決めておきます。

• 突き合わせる数字：在庫数、受注残、売掛・買掛の残高、請求額など、「変えてはいけない結果」
• 一致の判定：どこまでの差を許すか（端数の処理を含む）、差が出たら誰が原因を調べるか
• 終える条件：例「月次の締めを2回、差が出ずに終えたら旧システムへの入力をやめる」
• 元に戻す条件：例「出荷が半日以上止まる」「残高の差の原因が3営業日で分からない」ときは旧システムに戻す。誰が戻すと決めるか、戻すときに新システムに入ったデータをどう扱うかも書いておく
• 二重入力の人手：並行稼働中の入力を誰が担うか。人手が足りないなら、突き合わせを自動にする仕組みを先に用意する

元に戻す条件を決めずに切り替えると、問題が出たときに「直しながら進む」しか道がなくなります。前の章で紹介した江崎グリコの例でも、切り替え直後の在庫数の食い違いが出荷停止につながりました。

AIを使って社内でできる部分と、会社に頼む部分

ChatGPTやClaudeなどの生成AIは、この作業の多くを手伝えます。書き出す表のひな形、部門へのヒアリング項目、保守会社への質問の下書き、手元のソースコードや夜間処理の設定から外部とのやりとりを洗い出す作業、移行順序の案づくりまでは、社内でAIを使って進められます。

一方で、次の4つは自社に固有の事情が絡み、AIだけでは決まりません。

• 既存環境と権限：本番のサーバーやデータベースに誰がどこまで触れてよいか、保守会社との契約上どこまで調べられるか
• 例外：年に1回だけ動く処理や、特定の取引先だけの例外ルールなど、データにもコードにも残っていない運用
• 正しさの確認：新旧の結果が一致するかを、どのデータで、誰が確かめて合格とするか
• 変更の責任：移行した後に問題が出たとき、誰が直し、誰が元に戻すと決めるか

この4つを社内で持てるなら、調査も移行も自社で進められます。持てない部分、たとえば「保守会社以外の目でソースコードと構成を調べてほしい」「新旧のデータを突き合わせる仕組みを作ってほしい」といった部分だけを外に頼むと、費用を絞れます。

調査と開発の発注を分ける

最初の発注を「作り直し一式」にすると、調べてから分かった依存関係や例外が、すべて追加費用か工期の遅れになります。先に現状調査だけを発注し、依存関係の一覧・移行順序の案・並行稼働と元に戻す条件を成果物として受け取ってから開発の見積を取ると、各社の見積の前提がそろいます。調査を頼む会社と開発を頼む会社は分けても構いません。調査の成果物は相見積の共通の資料として使えます（相見積もりの取り方）。

当社が公開している実績

当社が公開している受託開発の実績は、通信事業の数万件の請求情報を取り込み・集計し、確認する画面を作った案件と、薬局の複数店舗・数千人分の記録を、権限と確認の工程を含めて管理する仕組みの2件です。どちらも基幹システムの刷新そのものの案件ではありません。基幹システムの依存関係の書き出しや移行順序は、ご相談の中で自社の状況に当てはめて一緒に確かめます。

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

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

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

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

初回のご相談は無料・30分・オンライン（Google Meet）です。延命か刷新かが決まっていない段階でも、要件が決まっていなくても構いません。30分では、①何を解決したいか（対象の業務・使う人・今のシステム）、②社内でAIを使って進められる部分と、会社に頼んだ方がよい部分の切り分け、③依頼の形の候補（現状調査のみ／既存システムの改修／PoC／本開発）と進め方を伺います。相談後に、依頼範囲の候補・進め方・費用の目安をまとめた相談メモをメールでお送りします。

ご相談の前に次の4つが分かっていると、話が早く進みます。すべてそろっていなくても大丈夫です。

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

秘密情報・本番の認証情報・実際の顧客データは、相談の段階では送らないでください。

現状調査の報告、要件定義書の作成、PoC、開発は有償です。有償の作業に入る前に、範囲と金額をお示しして合意をいただきます。進め方の詳細は受託開発サービスの進め方をご覧ください。

よくある質問

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

いずれかに当てはまるなら、ご相談ください。初回相談は無料・30分（オンライン）で、要件が決まっていなくても大丈夫です（要件が固まっていなくても相談できる理由）。当社の価格は、既存システムの改修が100万円〜、PoCが300万円〜、本開発は個別見積です（すべて税別。クラウドやAIの利用料、ソフトウェアのライセンスなどの実費は別途）。

基幹システムの製品名、保守の終わりの日付、つながっている他のシステム、いちばん時間を取られている作業を伺い、6つの選択肢のどれが合いそうか、現状調査から始めるか、段階移行をどこから始めるかを一緒に整理します。相談後に、依頼範囲の候補・進め方・費用の目安をまとめた相談メモをお送りします。パッケージ・SaaSへの入れ替えで足りる場合や、今のまま使い続けられる場合は、開発をおすすめしません。

▶ 基幹システムの現状調査と段階移行の範囲を相談する