レガシーシステムの保守費用｜「古いから高い」を3つの上乗せに分けて検証する

レガシーシステムの保守費用について調べるとき、多くの場合すでに手元には具体的な紙があります。「基幹システム保守費　一式　月額◯◯万円」と書かれた見積書か、前年より数万円だけ上がった更新案内です。そしてベンダーからは、たいてい同じ説明を受けています。「古いシステムなので、対応できる技術者が限られていまして」。

この説明は嘘とは限りません。ただし、これは金額の根拠ではなく、金額の理由づけです。 根拠であれば「どの技術に、何人が、何時間」まで分解できます。理由づけは分解できません。この違いを確認しないまま更新を繰り返すと、稼働年数が増えるたびに上乗せの説明だけが厚くなり、内訳は薄くなっていきます。

本記事は、保守費用の相場を示す記事ではありません。「古いから高い」という説明を3つの上乗せに分けて、それぞれが手元の見積書で確認できるかどうかを判定するための記事です。保守費全体の検証手順はシステム保守費用の相場と妥当性にまとめてあるため、本記事は「古さ」に起因する部分だけを扱います。

TL;DR｜「古いから高い」は理由ではなく、3つの上乗せの合計

• 稼働年数そのものは費用を生みません。 経済産業省の研究会がまとめたDXレポートは、レガシーシステムを稼働年数ではなく「高コスト構造の原因となっているシステム」と定義しています。同レポートは「古い技術を使っているシステムだから必ずレガシー問題が発生するわけではない」とも明記しています
• 「古いから高い」と説明される部分は、実際には次の3つに分けられます。ここでいう上乗せとは、同等の新しいシステムなら発生しない増分のことです。この3つは、確認できる度合いがまったく違います

• A・B・Cという並びは、そのまま確認すべき順番です。 Aは製造元の公表条件と突き合わせられ、Bは作業実績で測れます。Cだけが残ったとき、それは「説明済み」ではなく「要確認」です
• 発注側が実際に負担と感じている順序は、直感と違います。JUASの調査（2017年・N=99・複数回答）でレガシーシステムが足かせと感じる理由の1位は「ドキュメントが整備されていないため調査に時間を要する」（49件）で、「特定技術に関する技術者を確保するのに、多大なコストがかかる」は9位（22件）でした
• 「2025年の崖で年間12兆円」は保守費の根拠になりません。 あの数字はシステム障害による経済損失の推定であって、保守費の総額ではありません（算出根拠の分解）
• 延命と刷新の比較は、金額の大小ではなく比較の単位を揃えることから始めます。期間・対象範囲・残るリスクを揃えないと、どちらが安いかは計算上どうにでもなります

判断は「高い／安い」の二択ではなく、システム保守費用の相場と妥当性と同じ説明済み／要確認／高リスク／判断不能の4状態で行います。

「レガシー」は古さの話ではない｜経済産業省の定義で確認する

出発点をずらしておく必要があります。「レガシーシステム」という言葉が、稼働年数を指していないからです。

経済産業省の研究会がまとめたDXレポート（正式名称「DXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～」、デジタルトランスフォーメーションに向けた研究会、平成30年〈2018年〉9月7日）は、レガシーシステムを次のように定義しています。

レガシーシステムとは、技術面の老朽化、システムの肥大化・複雑化、ブラックボックス化等の問題があり、その結果として経営・事業戦略上の足かせ、高コスト構造の原因となっているシステム、と定義している

注目すべきは、「高コスト構造の原因となっている」ことが定義の一部に入っている点です。つまり定義上、レガシーかどうかは結果から判定されます。稼働年数は判定条件に入っていません。

同レポートはさらに踏み込んで、次のように書いています。原典では1つの段落なので、前半だけを取り出さずにそのまま引きます。

レガシー化は技術の側面のみならず、「マネジメント」の側面が大きな問題と考えるべきである。古い技術を使っているシステムだから必ずレガシー問題が発生するわけではない。適切なメンテナンスを行うITシステムマネジメントを行っている場合は、ブラックボックス化はしにくい。ただし、システム全体が一体化した古いアーキテクチャや開発技術はメンテナンスによって肥大化、複雑化する傾向にあり、時間の経過と共にレガシー問題を発生しやすいのは事実である（開発から時間が経っているためレガシー化の確率が上がる）。

前半は「古い＝レガシーではない」、後半は「ただし古いほど確率は上がる」。どちらか片方だけを根拠にはできません。さらに次の段落は逆方向の指摘を置いていて、「逆に、最新のクラウド技術を適用していても、時間の経過と共にレガシー問題が発生し得る」と書いています。

これらを並べると、見積書に対する問いが変わります。「古いから高いのか」ではなく、**「このシステムのどこがブラックボックスになっていて、その解消にいくら払っているのか」**です。前者には答えがありませんが、後者には答えがあります。

「稼働◯年目なので」は、それ自体では根拠にならない

保守費の更新案内に「稼働10年目に入り、保守難度が上がっているため」と書かれていることがあります。この一文が根拠として成立するのは、次のどちらかが示されているときだけです。

1. その年に実際に発生した作業量が、前年より増えていること（作業報告で確認できる）
2. その年から新たに発生する外部費用があること（メーカーのサポート終了など、日付が公表されている）

どちらも示されずに年数だけが書かれている場合、それは値上げの説明であって費用の内訳ではありません。値上げ自体は不当ではありませんが、条件と上限が契約に書かれているかは別の論点になります。

保守見積書では、「古さ」がこう書かれている

実際の見積書で「古さ」に関連して現れる行と、そこから読み取れないことを整理します。

「どの上乗せか」を特定できない行は、そのまま「判断不能」です。 高いとも安いとも判定できません。逆に、上乗せが特定できた行も、それだけでは「要確認」までしか進みません。「説明済み」に変わるのは、後述の突き合わせが済んだときです。

レガシー特有の読み方は1つだけです。「古さ」を名乗る行は、それが外れる条件が書かれているかを見てください。 「レガシー対応加算」に対して聞くべきは金額の妥当性ではなく「この加算が外れる条件は何ですか」であり、条件が出てこない加算は、稼働年数が伸びるかぎり永久に続きます。行項目全般を待機・人の作業・システムの作業・実費の4区分へ分解する一般手順は、システム保守費用の相場と妥当性にあります。

「古いから高い」を3つの上乗せに分解する

ここからが本題です。3つの上乗せを、A・B・Cの順（＝確認しやすい順）で見ていきます。

なお、この3つはシステム保守費用の相場と妥当性で挙げた5つのコストドライバーと別物ではありません。A（延長費）は④実費、B（調査時間）は②人の作業と③システムの作業、C（希少性）は②の単価と⑤引き継ぎ困難性に対応します。本記事は、そのうち「古さ」が効いている部分だけを取り出しています。

上乗せA｜サポート切れ製品の延長費は、金額が公表されていることが多い

もっとも確認しやすいのがこれです。OS・データベース・ミドルウェアの多くは、製造元がサポート期間と延長条件を公表しています。

Microsoftは、Windows 10の拡張セキュリティ更新プログラム（ESU）について、法人向けの価格を次のように記載しています（Microsoft Learn「Extended Security Updates (ESU) program for Windows 10」、記事日付2025年11月17日、2026年8月21日取得）。

Extended Security Updates for organizations and businesses on Windows 10 can be purchased today through the Microsoft Volume Licensing Program, at $61 USD per device for Year One. … The price doubles every consecutive year, for a maximum of three years.

1台あたり1年目61米ドル、以降は毎年倍額、最大3年。このページには日本円換算と税区分の記載がないため、日本での実際の請求額は販売形態によって変わります。 見積書と突き合わせるときは、この点を確認してください。

なお同ページは、Windows 365・Azure Virtual Desktop・Azure仮想マシンなどの上で動くWindows 10仮想マシンについては「at no additional cost」（追加費用なし）でESUが提供されると記載しています。見積書の対象が実機かクラウド上の仮想マシンかで前提が変わるため、台数を数える前にそこを確認してください。

同ページには、購入方法についても条件が書かれています。

The Extended Security Update Program for Windows 10 must be purchased by year. Customers can't buy partial periods, for instance, only six months. Year One starts in November 2025. If you decide to purchase the program in Year Two, you have to pay for Year One too, as ESUs are cumulative.

2年目から入っても1年目分の支払いが必要、という累積の設計です。「来年から考える」が費用を減らさない構造になっています。

さらに重要なのは、延長サポートで買えるものの範囲です。同ページの制限事項には次のように書かれています。

ESUs doesn't include the following items:

• New features
• Customer-requested nonsecurity updates
• Design change requests
• General support won't be provided for Windows versions past the end of support date. The Windows 10 ESU only includes support for the license activation, installation, and possible regressions of the ESU itself. To get technical support for these issues related to the ESU, organizations must have an active support plan in place.

延長サポートで買えるのはセキュリティ更新だけです。新機能、利用者が要望した非セキュリティ更新、設計変更要求は含まれず、4項目めが示すとおり、サポート終了後のWindowsに対する一般的なサポートも提供されません。技術サポートについても、同ページのFAQに回答があります。

Is technical support included in ESU? — No, technical support isn't included in the ESU program. Microsoft will provide support for customers that encounter challenges related to the ESU.

ここは「サポートが一切ない」という意味ではありません。 通常のWindows 10としての技術サポートは付かず、ESU自体のライセンス認証・インストール・ESUが原因の不具合についてだけ対象になる、という限定です。しかも同ページは、その対応を受けるには別途有効なサポート契約（active support plan）が必要だと書いています。

つまり延長サポート費を払っても、障害時の問い合わせ窓口は別に必要です。見積書の「延長サポート費」に窓口対応が含まれているように読める場合、それはメーカーへの支払いではなくベンダー側の役務なので、分けて金額を確認してください。

同じ構造は他社にもあります。Oracleの「Oracle Technology Products — Oracle Lifetime Support Policy」（Effective Date: August 7, 2026、2026年8月21日取得）は、サポートを3段階に分けています。各段落の記載から、費用の判断に効く項目だけを抜粋します。

「無期限サポートがあるから大丈夫」という説明には注意が必要です。 Oracleの文書が明記しているとおり、無期限の段階では新しいセキュリティ修正は提供されません。なお、この文書にExtended Supportの具体的な料率（何パーセント上乗せか）の記載はなく、「追加料金」とだけ書かれています。料率を数字で説明された場合は、その出所を確認してください。

SQL Serverについては、Microsoftが終了日とESU提供期限を具体的に公表しています（Microsoft Learn「Extended Security Updates FAQ - SQL Server」、記事日付2026年6月22日／メタ上の更新2026年8月5日、2026年8月21日取得）。

The end of support date for SQL Server 2016 (13.x) is July 14, 2026. ESUs are available until July 17, 2029. The end of support date for SQL Server 2014 (12.x) was July 9, 2024. ESUs are available until July 8, 2027.

SQL Server 2016のサポート終了は2026年7月14日で、ESUは2029年7月17日まで。SQL Server 2014は2024年7月9日に終了し、ESUは2027年7月8日までです。終了日もESUの提供期限も、すべて公表されています。 見積書を待たずに自社で調べられる情報です。

同ページは、ESUに含まれる更新の範囲も限定しています。

ESUs include Security Updates and Bulletins rated Critical by the Microsoft Security Response Center (MSRC), for a maximum of three years after the end of extended support. … Technical support is limited to issues directly related to the released updates.

対象はマイクロソフトのセキュリティ対応センター（MSRC）が「Critical」と評価した更新に限られ、期間は延長サポート終了後の最大3年、技術サポートも配信された更新に直接関係する問題に限定される、という内容です。「延長サポートに入っているから従来どおり」ではありません。

Aを確認するときにやることは1つです。 見積書の「延長サポート費」「旧環境保守費」の行について、製品名・バージョン・対象台数（またはコア数・デバイス数）を確認し、製造元の公表条件と突き合わせます。ここに差額があること自体は普通で、販売店のマージン、代理購入の手数料、円建て固定のための為替リスク負担などが乗ります。問題は差額の存在ではなく、差額が何なのか書かれていないことです。

なお、EOLは費用だけの問題ではありません。保守約款のなかには、OS・ミドルウェアが製造元のサポート対象であることを保守サービス提供の前提条件にしているものがあり、その場合はEOLを迎えた時点で保守料を払っていても保守が受けられない状態になり得ます。この論点は保守契約の範囲で公開約款を並べて確認しています。

上乗せB｜資料欠落による調査時間は、時間なので測れる

2番目に確認しやすいのがこれです。設計書がないシステムでは、直す前に読む時間が要ります。 これは技術の古さではなく、資料の状態から生まれる費用です。

DXレポートは、この状態がどう生まれるかを説明しています。

国内企業では、大規模なシステム開発を行ってきた人材が定年退職の時期を迎え、人材に属していたノウハウが失われ、システムのブラックボックス化が起きている。

原因は世代交代だけではありません。同レポートは、記録が残らない構造そのものにも触れています。

多くの国内企業は終身雇用が前提のため、ユーザ企業においては、ITシステムに関するノウハウをドキュメント等に形式知化するインセンティブは弱い。そのため、ノウハウが特定の人の暗黙知に留まっている。このため、開発当初はドキュメントが正確に記述されていても、特定の技術者が「有識者」として居続ければ、組織としての管理がおざなりになってしまう可能性が高い。

ここで発注側にとって重要なのは、Bは時間として現れるという点です。時間は測れます。したがってBは、次の3つで検証できます。

1. 1件あたりの調査時間。同種の改修依頼について、着手から影響範囲の確定までに何時間かかっているか
2. 調査結果が資産として残るか。調査のたびに同じ場所を読み直しているなら、その時間は毎回課金され続けます
3. 試験の範囲。「影響が読めないので広く試験する」は、資料欠落が試験費に転化した形です

Bに対する上乗せは、原則として減っていくべき費用です。 調査した内容が文書として残れば、次回の調査時間は短くなります。逆に、同じ「現行調査費」が3年間まったく同じ金額で計上されているなら、調べた結果がどこにも残っていない可能性があります。これは値下げ交渉の話ではなく、払った費用が資産になっているかどうかの話です。

見積書に「ドキュメント整備費」が入っている場合は、成果物の一覧・納品後の権利・更新責任の3点を確認してください。整備した文書がベンダー側にしか残らない設計だと、費用を払ったのに引き継ぎ可能性は上がりません。この構造はベンダーロックインと保守費の高止まりで詳しく分解しています。

上乗せC｜技術者の希少性は、いちばん検証しにくい

最後がこれです。そして、最初に説明されるのがたいていこれです。

「COBOLを触れる人がもういない」「あの言語の技術者は単価が違う」。この説明が正しい場面は実際にあります。しかし、公的な将来試算を見ると、レガシー技術者の希少性は自動的には成立しないことが分かります。

経済産業省の委託事業としてみずほ情報総研株式会社がまとめた「IT人材需給に関する調査 調査報告書」（2019年3月）は、IT人材を「先端IT人材」と「従来型IT人材」に分けて需給を試算しています。この試算の概要をまとめた経済産業省「IT人材需給に関する調査（概要）」（情報技術利用促進課、平成31年4月）の注に、従来型IT市場の定義が置かれています。

従来型ITシステムの受託開発、保守・運用サービス等に関する市場を従来型IT市場と定義した。

つまり、受託開発と保守・運用サービス等を担う人材が試算対象に含まれています。その2030年時点の需給ギャップは、報告書本編の表3-15によれば次のとおりでした（生産性上昇率0.7%の前提）。

原典の注記どおり、**無印は「需要数＞供給数」（不足）、△は「供給数＞需要数」（供給過剰）**を意味します。報告書本文の説明も明確です。

需要構造の変化と人材供給のバランスや需要構造に応じたスキル獲得（スキル転換）が出来なければ、例えば、デジタル技術に対応したIT人材（先端IT人材）は需要が供給を上回る一方で、従来型の需要に対応したIT人材（従来型IT人材）は、供給が需要を上回る状況を生み出す可能性もある。

読み方はこうです。従来型IT人材が不足するか余るかは、前提の置き方で逆になります。 従来型IT人材から先端IT人材への転換（Reスキル）が進まないシナリオでは、2030年に従来型IT人材は供給過剰（△9.7万人〜△22.0万人）になると試算されています。逆に転換が市場の変化に連動して進むシナリオでは、従来型も5.7万人〜18.0万人の不足になります。

なお、報告書本編の地の文には、この「中位」ケースの従来型IT人材を「供給が需要を18.0万人上回る」（＝供給過剰）と記した箇所があり、表3-15の凡例（無印＝需要数＞供給数）と食い違います。本記事は次の理由から表の記載に従いました。同じ報告書の表3-5は、生産性上昇率0.7%のときの2030年の需給ギャップを低位16.4万人・中位44.9万人としており、表3-15の数値を両方とも不足として足すと低位が5.7＋10.7＝16.4、中位が18.0＋26.9＝44.9でこれに一致するためです。

適用範囲は正確に押さえてください。

• この試算の「従来型IT人材」は市場区分に基づく分類で、COBOLなど特定言語の技術者数を数えたものではありません
• 2019年3月時点の将来試算で、2030年時点の推計値です
• 報告書自身が「試算に必要な要素や仮定・条件等が増え、試算の確からしさという点では様々な課題がある」と限定を付けています

したがって本記事は、「レガシー技術者は不足していない」とも「不足している」とも主張しません。主張するのは次の1点だけです。希少性は一般論では決まらないので、見積書で単価差を説明されたら、そのシステムに固有の根拠を求めてよい、ということです。

具体的には次を聞きます。「その技術を扱える担当者は現在何名で、他の案件と兼務ですか」「担当者が確保できなかった場合、対応はどうなりますか」「同じ作業を標準的な技術者が行った場合との単価差はいくらで、その差は何に対する対価ですか」。

なお、DXレポートはベンダー側の人員事情にも触れており、「ベンダー企業においても、近年は技術者の不足感が強まっており、急な人員増やスキルシフトへの対応は困難になりつつある。これは、構造問題であるため、人員確保の短期的な解決は難しい状況である」と記載しています。ベンダーの困りごとが本当であることと、その分を発注側が単価で負担すべきかは別の問題です。 単価差が正当なら、根拠は示せるはずです。

発注側が実感している負担の順序は、直感と違う

ここまでの3分解を、発注側の実感データと突き合わせます。

DXレポートには「レガシーシステムが足かせと感じる理由」という図が掲載されています。出典は一般社団法人日本情報システム・ユーザー協会（JUAS）「デジタル化の進展に対する意識調査」（平成29年）。設問は【Q.23-2】「足かせになっていると感じる理由をご選択ください。（いくつでも）」、N=99です。図の横軸に単位の表記はありませんが、目盛りが0〜60でN=99であることから、割合（%）ではなく回答数（件）と読めます。 原典に単位が明記されていない点は留保してください。

1位と3位が、どちらも本記事の上乗せBにあたります。 「ドキュメントが整備されていないため調査に時間を要する」（49件）と「影響が多岐にわたるため試験に時間を要する」（45件）です。一方、上乗せCにあたる「特定技術に関する技術者を確保するのに、多大なコストがかかる」は22件で9位、上乗せAに近い「メーカーのサポートが切れており触れたくない」は4件で、「その他」（3件）を除けば最も少ない選択肢でした。

この表の適用範囲は、はっきりさせておく必要があります。

• 設問は「（レガシーシステムが）DXの足かせになっていると感じる理由」であって、保守費の内訳でも金額でもありません
• N=99の複数回答で、回答者は「足かせになっていると感じている」と答えた企業に限られます
• 2017年の調査です

それでも、見積書を読む順番を決めるには十分な示唆があります。発注側が実際に重いと感じているのは、技術者の希少性ではなく、調べる時間と試験の広さです。 ベンダーの説明が上乗せCだけで組み立てられているとき、それは発注側の実感とはズレた説明である可能性があります。少なくとも、上乗せBについての説明が同時に出てこないのは不自然です。

なお、上乗せAにあたる選択肢が4件と最も少ない部類だった点は、逆の読み方もできます。**サポート切れは「感じる問題」ではなく「日付が決まっている問題」**だからです。感じる前に契約と請求に現れます。だからこそ、Aは最初に確認すべき項目になります。

「2025年の崖の12兆円」を保守費の根拠に使ってはいけない

レガシーシステムの費用を語る文脈で、必ずと言っていいほど登場するのが「2025年の崖」と「年間最大12兆円の経済損失」です。この数字は実在します。ただし、保守費の話ではありません。

DXレポートの本文は次のように書いています。

複雑化・老朽化・ブラックボックス化した既存システムが残存した場合、2025年までに予想されるIT人材の引退やサポート終了等によるリスクの高まり等に伴う経済損失は、2025年以降、最大１２兆円／年（現在の約３倍）にのぼる可能性がある

同レポートは、この数字の算出根拠を注として明記しています。要約せずに構造だけ取り出すと、次の3段階です。

1. 土台：EMCジャパン株式会社の調査をもとにした独立行政法人情報処理推進機構のまとめ（2016年2月公開、2018年3月更新）で、データ損失やシステムダウン等のシステム障害により生じた2014年1年間の損失額が国内全体で約4.96兆円
2. 絞り込み：日経BP社「日経コンピュータ 2017.8.3」のシステムダウン原因別割合のうち、レガシーシステムに起因して起こる可能性があるものを「仮に」4分類とすると合計79.6%。4.96兆円×79.6%＝約4兆円／年
3. 3倍：JUAS「企業IT動向調査報告書2016」で、企業が保有する「最も大きなシステム」（≒基幹系システム）が21年以上前から稼働している企業の割合は20%、11年〜20年稼働は40%。**「仮に、この状態のまま10年後の2025年を迎えると」**21年以上稼働の割合は60%になる。これを踏まえトラブルリスクも3倍になると推定すると、最大で約12兆円／年

読み取れることは3つあります。

第一に、12兆円は障害による経済損失の推定であって、保守費の総額ではありません。 したがって「レガシー保守は高い」の根拠として引用するのは、資料の使い方として誤りです。

第二に、「2025年に21年以上稼働が6割」は実測値ではありません。 原典が「仮に、この状態のまま10年後の2025年を迎えると」という条件付きで書いた推計です。実測値として書かれているのは、JUAS「企業IT動向調査報告書2016」が示した時点で21年以上が20%、11〜20年が40%という数字のほうです。

第三に、この推定が示しているのは費用ではなくリスクです。 そしてリスクの見積もりは、保守費の議論よりも延命と刷新の比較で効いてきます。止まったときに何が起きるかは、金額の大小とは別の軸だからです。

見積書の説明にこの数字が引用されていたら、悪意を疑う必要はありません。ただし、その数字は目の前の金額の根拠にはならないということは、社内で共有しておいてください。

ベンダー側の言い分が正当と言えるケース

ここまで確認の話を続けましたが、上乗せが正当な場合もはっきりあります。次に当てはまるとき、上乗せは「説明済み」として扱ってよい費用です。

共通しているのは、どれも「そのシステムに固有の事情」として説明されている点です。 「一般にレガシーは高い」「業界的にそうなっている」という説明は、この表のどの行にも当てはまりません。

また、現行ベンダーの継続が合理的という結論も普通にあり得ます。 資料が欠落しているシステムでは、そもそも他社が見積もりを出せません。他社が出せない状態で「安いほうへ乗り換える」判断をすると、移行後に想定外の費用が出ます。継続が合理的かどうかは、価格ではなく引き継ぎ可能性で決まります。

確認が必要なケース｜4状態への仕分け

上乗せA・B・Cを、それぞれ4状態に仕分けます。同じ見積書のなかで、Aは「説明済み」、Bは「要確認」、Cは「判断不能」ということが普通に起きます。 全体を1つの状態でまとめないでください。

高リスクの行について補足します。「高リスク」は「ぼったくり」という意味ではありません。 ベンダーが誠実でも、EOLを過ぎた製品が本番で動いていて代替措置が契約に書かれていない状態は、事故が起きたときに責任の所在が決まっていないという意味でリスクです。ここは金額の議論より先に、書面で状態を確定させるべき箇所になります。

判断不能の行が3つ以上あるなら、金額交渉に入る前に内訳の分解を依頼してください。断られた場合は、断られた理由を記録しておきます。理由の記録は、次の相見積もりのときに「なぜ他社が見積もれないのか」を説明する材料になります。

何と突き合わせれば状態が決まるか

状態を決めるのは金額ではなく、突き合わせる相手があるかどうかです。 A・B・Cそれぞれについて、何と照合すれば状態が確定するかを一覧にします。

なお、突き合わせる相手が見つからないのは、高い費用だけではありません。安い保守費のほうが、照合すべき相手が最初から存在しないことがあります。

「安い保守費」のほうが危険なケース

保守費が安いことは、それ自体では良い状態を意味しません。古いシステムでは、安さが「やっていない」の裏返しであることがあります。

特に上から2行目は、金額に現れないまま責任だけが移動している状態です。 サポート切れの製品が本番で動いていて、その事実が保守見積書のどこにも書かれていない場合、事故が起きたときに「知らなかった」と言えるのは発注側だけではありません。契約書に前提条件として書かれていれば、ベンダー側は範囲外だと主張し得ます。

安いこと自体を問題にする必要はありません。確認するのは1点です。「安いのは、やらなくてよいからですか、それともやっていないからですか」。この問いに書面で答えが返ってくれば、それは説明済みの安さです。

延命と刷新を比べる｜総保有コストの組み立て方

「保守費が高いなら作り直したほうがいいのでは」という問いは、この記事を読む理由として自然です。ただし、この比較は金額を並べるだけでは成立しません。

DXレポートは、経営側から見た構造をこう書いています。

老朽化・複雑化・ブラックボックス化した既存システムの刷新は、数年間に及び、多額の費用が発生する事例が多く見られる。そのため、経営層としては、投資リスクの高さが先に立ってしまい、システム刷新に向けた戦略的な投資を判断できないという現状がある。

そして、その裏側についても書いています。

他方で、既存システムを放置した場合に増大するであろう技術的負債（将来にわたる運用・保守費）は、経営者にとって顕在化しにくく、システムが稼働している限りは、コストやリスクの伴う刷新の決断が先延ばしされる恐れがある。

片方は見えて、もう片方は見えない。 これが比較を歪める主因です。刷新費は見積書という1枚の紙になりますが、延命費は毎月の請求に分散していて、合計が誰にも計算されていないことがあります。

そして前掲の12兆円が示していたのは、費用ではなくリスクでした。だからこの比較では、金額の列とリスクの列を最初から分けます。

比較の前に、単位を3つ揃える

金額を比べる前に、次の3つを揃えてください。揃えないまま比べると、どちらが安いかは計算上どうにでもなります。

両側で入れ忘れやすい費用

抜ける費用は左右で性格が違います。 延命側は毎月の請求に分散していて誰も合計していない費用が落ち、刷新側は見積書に載らない前提作業が落ちます。

「刷新すれば下がる」は自動ではない

DXレポートは、この点にはっきり釘を刺しています。

レガシーシステム問題はマネジメントの問題でもあるので、「ブラックボックス化」する原因を追究しておかなければ、たとえ一時期の投資でシステムをモダナイズしても、時間と共に再度レガシー問題が出現する可能性は高くなる。単純なリホストや、プログラムのコンバージョンだけでは、一時的にはコストは下がっても、本質的には「ブラックボックス化」は解消されていないため、レガシー化は深刻になってしまう。

つまり、上乗せBの原因（資料が残らない体制）を直さないまま作り直すと、数年後に同じ費用構造が再現します。 刷新の見積もりを受け取ったら、金額と同時に「設計書の納品範囲」「更新責任」「引き継ぎ時の権利」を確認してください。これは刷新パートナー選定の中核でもあります。刷新すると決めたあとの進め方——リホスト／リプラットフォーム／リビルドの選び分けと段階移行の手順——はレガシーシステム刷新戦略が扱います。本記事が担当するのは、その決定に入る前の保守費の内訳検証までです。

参考までに、DXレポートには「既存システムを刷新してDXを進めた事例」として匿名事例が2件掲載されており、そのうち1件が電気通信事業者の事例です。ITコスト全体に対する運用経費の割合に着目し、3〜5年程度かけてレガシー刷新を進めることで、ITコストに占める運用経費の割合を80%強から50%程度に削減した、という内容です。これは1社の事例であり、割合の変化だけが示されています。 金額も、前提となるシステム規模も書かれていません。自社の削減見込みを見積もる根拠にはできませんが、「運用経費の割合」という指標で刷新の効果を測る考え方の例にはなります。

延命と刷新、どちらに寄るか

この表が答えるのは「どちらに寄るか」までです。 何から着手するかは、次章のベンダーへの確認質問の回答が揃ってから決めます。

4行目が重要です。 他社が見積もりを出せない状態では、延命と刷新のどちらを選んでも価格が競争にさらされません。この状態の解消は費用の話ではなく、引き継ぎ可能性の話です。

ベンダーへそのまま送れる確認質問8問

ここまでの内容を、そのまま送れる文面にしました。質問1〜3が上乗せA、4〜6がB、7〜8がCに対応します。 全部を一度に送っても構いませんが、1〜3だけ先に送って回答の質を見る、という進め方も有効です。

そのまま送れるメール文面

件名：保守見積書の内訳についてのご確認（◯◯システム）

お世話になっております。◯◯株式会社の◯◯です。 標記の保守見積書について、社内の予算承認にあたり内訳を確認する必要が生じました。 お手数ですが、下記8点について書面でご回答いただけますでしょうか。 金額の交渉を目的としたものではなく、費用の性格を社内で説明できるようにするための確認です。

1.【延長サポート費用の対象】 見積書の「◯◯」の行に、メーカーの延長サポート費用（拡張セキュリティ更新等）は含まれていますか。含まれている場合、対象製品名・バージョン・対象数量（台数またはコア数・デバイス数）と、契約期間をご教示ください。

2.【サポート終了日の一覧】 現在稼働しているOS・データベース・ミドルウェア・ハードウェアについて、製造元のサポート終了日（EOL）の一覧をご提供いただけますか。すでに終了しているものがある場合は、現在どのような代替措置をとっているかもあわせてご教示ください。

3.【契約上の前提条件】 保守契約書に、対象製品が製造元のサポート対象であることを保守サービス提供の前提条件とする条項はありますか。ある場合、EOL到達後の保守の取り扱いをご教示ください。

4.【調査にかかっている時間】 改修依頼を受けてから影響範囲を確定するまでに、直近1年間で平均何時間かかっていますか。件数と合計時間でも構いません。

5.【調査結果の成果物】 見積書の「◯◯」に含まれる調査作業について、成果物（設計書・影響範囲一覧・構成図等）は納品対象になりますか。納品される場合、その文書の権利と、次回以降の更新責任の所在をご教示ください。

6.【試験の割合と縮小の条件】 直近1年間の作業報告のうち、試験（回帰試験・影響確認）に費やした時間の割合をご教示ください。あわせて、試験範囲を狭めるために必要な資料が何かをご教示いただけますと助かります。

7.【担当できる技術者の人数】 本システムの保守を担当できる技術者は、現在何名いらっしゃいますか。他案件との兼務状況と、当該担当者が不在となった場合の対応方針もご教示ください。

8.【単価上乗せの対象と差額】 見積書に特定技術に対する単価の上乗せが含まれている場合、上乗せの対象作業と、上乗せがない場合との差額をご教示ください。あわせて、その差額が何に対する対価か（希少性・習熟期間・確保コスト等）をご説明ください。

恐れ入りますが、◯月◯日までにご回答いただけますと幸いです。 現時点で回答が難しい項目がございましたら、その旨をご記載いただければ結構です。 よろしくお願いいたします。

回答をどう読むか

回答が返ってきたら、内容の正しさより先に、どの質問に答えていないかを見てください。

8番の回答が一般論で返ってきたとき、それは相手が不誠実だという意味ではありません。 単価の内訳は営業上の情報でもあり、答えにくい質問です。ただし、答えられない項目は社内で「要確認」として扱う必要があります。

回答が揃ったあとの選択肢

回答が揃うと、取り得る行動はおおむね次の5つに落ち着きます。

いずれの場合も、保守費を下げること自体を目的にしないでください。 下がった保守費の内訳が「やらないことにした作業」であれば、費用はリスクに置き換わっただけです。

手元の保守見積書について、どの行がA・B・Cのどれに当たるかを整理したい場合は、**見積書の費用分解診断（登録不要）**が使えます。見積書のテキストはブラウザ内で識別情報をマスクしたうえで診断にかけられ、結果を見るまでメールアドレスの入力は不要です。診断結果は「高い／安い」ではなく、確認すべき項目とベンダーへの質問として返ります。

根拠資料と適用条件

本記事で使った資料と、その適用範囲です。数値ごとに性格が違うため、まとめて扱わないでください。なお区分欄の「一次資料A」は資料の格付けを表す記号で、本文の上乗せA・B・Cとは関係ありません。

あわせて、次の3点にご注意ください。

レガシーシステムの保守費の「相場」は、本記事では示していません。 公的機関が公表しているレガシー保守費の相場データを確認できなかったためです。開発費に対する保守費の比率（いわゆる15〜20%）も業界慣習値であって公的な相場ではなく、この点はシステム保守費用の相場と妥当性で扱っています。

レガシー言語技術者の人数・平均年齢・単価は、本記事では扱っていません。 「COBOL技術者の平均年齢は◯歳」といった数値について、一次統計での裏づけを本記事の調査範囲では確認できなかったためです。確認できない数値は使用していません。

延命と刷新の金額比較は、本記事では行っていません。 対象システムの規模・業務要件・残存リスクによって前提が大きく変わり、一般化した金額に意味がないためです。本記事が提供しているのは比較の単位を揃える枠組みだけです。

なお本記事は、法的・技術的な最終判断を提供するものではありません。契約解釈、個別のセキュリティ対策やEOL対応の要否については、それぞれの専門家にご確認ください。

よくある質問