経営者向け：保守費を下げるために保守先を変更する前に見る引き継ぎ条件

先に結論：保守費の削減は「月額の安い会社探し」ではなく「引き継げる状態に戻す投資」です

保守費が高い。毎月払っているのに改善提案がない。障害対応は遅い。担当者が変わるたびに同じ説明をしている。小さな改修でも見積が高い。経営者がこの状態を見て、保守先を変えたいと考えるのは自然です。

ただし、保守先変更で失敗する会社は、最初に月額だけを見ます。現在の保守費が月額80万円で、新しい会社が月額45万円なら年間420万円下がる。そう見えても、実際には、引き継ぎ調査、古い環境の再構築、設計書の再作成、監視設定の移管、権限整理、バックアップ確認、障害履歴の読み解き、契約終了時の協力費、並行運用費が発生します。結果として、初年度は削減どころか増額になることがあります。

保守費を下げるために最初に見るべきものは、月額ではありません。見るべきものは、現在の保守契約の中身、対象システム、障害履歴、改修履歴、ソースコード、環境情報、権限、監視、バックアップ、未対応課題、既存ベンダーしか知らない運用手順です。これらが引き継げない状態なら、新しい保守先は安く見積もれません。安く見積もったとしても、移管後に追加費用、対応遅延、障害再発、責任分界の争いが起きます。

結論は次の10点です。ここだけ読んでも、保守先変更の失敗原因と先に確認すべき条件が分かるように整理します。

最重要ポイント: 保守費を下げる判断は、月額比較ではなく、引き継ぎ可能性、初年度移管費、責任分界、90日並行運用、移管後KPIで決めます。ここを飛ばすと、安く見えた保守契約が追加費用と障害対応で高くなります。

1. 保守費を8分類に分解する: 保守費削減の前に、現在の保守費を「定常運用、障害対応、軽微改修、監視、バックアップ、問い合わせ、ライセンス、セキュリティ対応」に分解する
2. 初年度費用まで比較する: 月額の比較だけではなく、初年度の引き継ぎ費、並行運用費、ドキュメント整備費、緊急改修費まで含めて比較する
3. 渡せる資料を確認する: 新しい保守先へ渡せる資料は、設計書だけでなく、障害履歴、改修履歴、環境構築手順、権限一覧、監視設定、バックアップ手順まで必要
4. 感情ではなく事実で判断する: 既存ベンダー変更の判断は、関係悪化の感情ではなく、SLA、改善提案、属人化、追加費用、技術負債、セキュリティ対応の事実で行う
5. 旧ベンダーの協力条件を固定する: 既存ベンダーにしかできない作業がある場合、いきなり解約せず、引き継ぎ協力期間と成果物を契約で固定する
6. 保守対象そのものを減らす: 保守費を下げるには、保守会社を変えるだけでなく、対象システム、問い合わせ窓口、改修ルール、障害分類、承認フローを減らす必要がある
7. 権限と名義を棚卸しする: 引き継ぎ前に、管理者権限、ソースコード権限、クラウド権限、ドメイン、証明書、外部SaaS、APIキーを棚卸しする
8. 保守内と別費用を分ける: 新保守先の見積では、月額だけでなく、どこまでが保守で、どこからが別費用かを回答させる
9. 90日で並行運用する: 90日間は、旧ベンダー、新ベンダー、自社で並行運用し、障害訓練、リリース訓練、バックアップ復元確認まで行う
10. 削減額ではなく改善KPIで評価する: 保守先変更後は、保守費削減額だけでなく、障害件数、対応時間、改修リードタイム、未対応課題の減少で評価する

この記事は、保守費が高く、既存ベンダーから別会社へ保守先を変更したい経営者向けです。見積依頼前の範囲整理ではありません。正式RFPの作り方でもありません。中心となる判断対象は「既存ベンダー変更」です。いまの保守先から本当に変えるべきか、変えるなら何を引き継げば失敗しないかを扱います。

この記事を読むべき会社

この記事は、業務システム、基幹システム、Webサービス、会員サイト、予約システム、EC、CRM、SFA、販売管理、在庫管理、帳票システム、社内ポータル、クラウド環境、オンプレ環境、レガシーシステムの保守費を見直したい中小・中堅企業の経営者、CIO、DX責任者、情シス責任者、管理部門向けです。

特に、次の状態にある企業に役立ちます。

• 保守費の内訳が見えない: 保守費が高いが、何にお金を払っているのか分からない
• 障害時の初動に不安がある: 既存ベンダーの対応が遅く、障害時に不安がある
• 小さな改修が高い: 小さな改修でも見積が高く、社内説明しづらい
• 担当者依存が強い: 担当者が変わり、過去の経緯を分かる人がいない
• 資料が古い: 設計書や運用手順が古く、新しい会社へ渡せるか不安
• 解約後の協力が不透明: 解約を切り出した後に、協力してもらえるか分からない
• 停止リスクは避けたい: 保守費を下げたいが、システム停止や障害増加は避けたい
• 経営判断したい: いまの保守契約を続けるか、別会社へ変えるか、経営判断したい

逆に、まだシステムの新規開発会社を探している段階なら、本記事よりも要件定義や見積前整理の記事を先に読むべきです。すでにRFPを出す段階なら、契約条件と採点表の記事に進むべきです。

事前に整理できること

ここで扱うのは単なる「安い保守会社を紹介してください」ではありません。事前に整理したいのは、保守費の内訳診断、既存ベンダー変更可否の判断、引き継ぎ資料の棚卸し、保守契約レビュー、新旧ベンダー並行運用計画、月額保守の再設計です。

関連する支援は システム開発・DXの相談 で確認できます。

関連記事との使い分け

保守費、引き継ぎ、保守先変更は知りたい内容が近いため、記事ごとに扱う範囲を分けます。

この切り分けにより、同じ「保守費」でも知りたい内容を分けます。本記事の中心は、安い保守先探しではなく、既存ベンダーから保守を安全に移すための判断条件です。

保守費が高い理由を、まず7つに分解する

保守費が高いと感じたとき、経営者は「もっと安い会社はないか」と考えがちです。しかし、保守費が高い理由を分解しないまま会社を変えると、安くできる部分と削ってはいけない部分を混同します。

ここでの判断軸: 「高いか安いか」ではなく、何に払っているか、何が過剰か、何を削ると事故になるかを分けます。

保守費削減で見るべきことは、月額の総額ではなく、この7分類のうち、どれが過剰で、どれが不足しているかです。たとえば、月額は高いが障害対応、監視、軽微改修、月次改善が含まれているなら、単純に高いとは言えません。逆に、月額は安いが、調査、軽微改修、緊急対応、セキュリティ対応がすべて別費用なら、年間総額は高くなります。

既存ベンダーを変更すべきサイン

保守先を変更すべきかどうかは、感情ではなく事実で判断します。次のサインが複数ある場合は、変更検討の優先度が高いです。

変更を急ぐべき状態: 障害、権限、資料、追加費用、説明責任のうち複数が崩れている場合は、価格交渉だけでなく保守先変更の準備に入るべきです。

一方で、保守費が高いだけで即変更すべきとは限りません。既存ベンダーが業務理解を持ち、障害対応が速く、資料も整っており、改善提案も出しているなら、価格交渉や範囲再設計で解決できる場合があります。変えるべきなのは、費用が高い会社ではなく、説明できない費用、改善しない障害、引き継がせない情報、属人化した運用が残っている会社です。

保守先変更前に集めるべき引き継ぎ資産

新しい保守先へ依頼するとき、最初に聞かれるのは「何を見れば現状が分かるか」です。ここで資料が出せないと、新ベンダーは高めに見積もるか、責任範囲を狭くします。

最初に集めるべきもの: 設計書だけでは不十分です。コード、環境、権限、障害履歴、監視、バックアップ、契約・名義まで揃って初めて、安い見積ではなく安全な見積になります。

経営者が見るべきポイントは、資料の有無だけではありません。資料が「最新か」「実態と合っているか」「新しい会社へ共有できる契約か」「社内にも控えがあるか」です。資料が既存ベンダーの手元にしかなく、契約上の引き渡し義務も曖昧なら、保守先変更はすぐに始めず、まず引き継ぎ資産を作るべきです。

保守費削減の見込みを初年度と2年目以降で分ける

保守先変更の稟議で最も多い失敗は、初年度から月額削減額だけを効果として出すことです。保守先変更には、移管費用が発生します。そのため、初年度と2年目以降を分けて見る必要があります。

稟議での見せ方: 初年度は移管投資、2年目以降は保守費削減と品質改善として分けます。初年度だけを見て「削減できていない」と判断すると、必要な引き継ぎ投資まで削ってしまいます。

たとえば、現行保守費が月額80万円で、新保守費が月額50万円なら、月額差は30万円、年間差は360万円です。しかし、初年度に引き継ぎ調査200万円、ドキュメント整備100万円、並行運用2か月分160万円が発生すれば、初年度は削減額を超えます。これは失敗ではありません。むしろ、これまで見えなかった保守負債を可視化している状態です。

問題は、初年度の移管費を隠して「安くなります」と稟議することです。経営会議では、初年度は移管投資、2年目以降は保守費削減と品質改善、と分けて説明する方が正確です。

既存ベンダーに切り出す前に決めること

既存ベンダーへいきなり「解約します」と伝えると、必要な協力を得にくくなる場合があります。特に、資料が不足している、環境情報がベンダー管理、リポジトリ権限が社内にない、クラウド契約がベンダー名義、障害履歴が社内にない場合は、切り出し順序が重要です。

切り出す前に決めるべきことは次の通りです。

1. 解約ではなく、保守範囲の見直しとして始めるのか
2. 引き継ぎ協力を有償で依頼するのか、契約範囲内で求めるのか
3. どの資料をいつまでに受け取るのか
4. 受け取った資料を新ベンダー候補へ共有してよいか
5. 旧ベンダーの管理者権限をいつ停止するのか
6. 並行運用期間中の障害責任をどう分けるのか
7. 旧ベンダーに改善提案の再提出機会を与えるのか

既存ベンダー変更は、交渉でもあります。感情的に切るより、資料、契約、権限、責任分界を先に固めた方が、結果として安全に移管できます。

新しい保守先に必ず聞く質問

新しい保守先候補には、月額費用だけでなく、保守の境界を質問します。

候補会社を選ぶときは、安い会社ではなく、分からないことを分からないと言い、初期調査でリスクを明らかにする会社を選ぶべきです。保守移管では、最初から断言する会社ほど危ないことがあります。

90日移管計画

保守先変更は、契約を切り替える日ではなく、90日で安定運用へ移す計画として見るべきです。

90日で見る理由は、資料確認だけでは保守品質が分からないからです。実際の問い合わせ、障害、リリース、バックアップ、権限変更を一度通さないと、移管後の穴は見えません。

保守費を下げるために削ってよいもの、削ってはいけないもの

保守費削減では、削ってよいものと削ってはいけないものを分けます。

安くするために重要な運用を削ると、保守費は下がってもリスクが増えます。保守費削減の正しい順序は、不要作業を減らし、属人作業を手順化し、問い合わせを分類し、障害の再発を減らし、そのうえで月額を見直すことです。

契約で揉めやすいポイント

保守先変更で揉めるのは、技術より契約です。

契約書を法務だけに任せるのではなく、情シス、現場、経営、候補会社で実務上の責任分界を先に作るべきです。

経営会議で使う判断表

最後に、経営会議で使える判断表を示します。

経営会議で決めること: 「変えるか、続けるか」だけでは足りません。継続交渉、段階移管、変更優先、刷新検討、一時停止の5択で判断します。

経営者が避けるべきなのは、「高いから変える」「安いから選ぶ」という二択です。正しい問いは、「このシステムは、別会社が安全に保守できる状態か」「保守先を変えることで、費用だけでなく品質と改善速度も上がるか」です。

業種別に見る、保守先変更の危険ポイント

保守費の見直しは業種によって危険ポイントが変わります。同じ月額50万円の保守でも、EC、製造、士業、医療、物流、BtoB業務システムでは止めてはいけない機能が違います。新しい保守先に引き継ぐ前に、自社の業種で何が止まると損失になるかを明確にしてください。

業種別の危険ポイントを見ないまま保守費だけを削ると、削減した金額より大きな業務停止リスクを抱えます。保守先変更は、システム一覧ではなく、止まると売上、請求、出荷、顧客対応、法務、監査に影響する業務から順に見るべきです。

GXO式「保守移管5ゲート・100点」判定表

この記事の中核は、この判定表です。GXO独自分析として、保守先変更の失敗を「契約・権利」「技術再現性」「運用継続性」「サービス水準」「移管統制」の5つに分解しました。

各ゲートは5項目、1項目4点の合計20点です。採点は 0点＝未確認・口頭説明のみ、2点＝記載はあるが責任者・期限・実地証拠のいずれかが欠ける、4点＝第三者が証拠を追跡し再実行できる の3段階とします。総合点が高くても、Gate 1またはGate 2に0点があれば、旧ベンダーを解約しません。 権利がなく、第三者がシステムを再現できない状態では、他の高得点で補えないためです。

Gate 1：契約・権利（20点）

具体例：月額は下がるが、クラウドを移せない

旧ベンダー名義のクラウドで本番環境が動き、ソースコードの著作権とリポジトリ管理も旧ベンダーに残っているケースです。新保守先が月額50万円から30万円を提示しても、クラウド再構築、データ移行、コード再作成が必要なら、初年度費用は増えます。

このケースで経営者が確認するのは「新会社はいくらか」ではなく、次の4点です。

1. 現契約で第三者へソースと設計書を渡せるか
2. クラウド契約を自社へ名義変更できるか
3. 解約後も旧ベンダーが質問へ回答する期間はあるか
4. データ返却後、旧環境の削除証明を受け取れるか

Gate 1のレッドフラグと通過基準

• レッドフラグ: 「成果物一式」「必要に応じて協力」など対象と期限が特定されていない
• レッドフラグ: 管理者が旧ベンダー個人のアカウントになっている
• レッドフラグ: 解約を通知しないと資料の有無を確認できない
• 通過基準: 解約後も自社または新保守先が利用・改修・運用できる資産と、再契約・再作成が必要な資産を一覧化できている

Gate 2：技術再現性（20点）

具体例：コードはあるが、本番を再現できない

リポジトリは受領済みでも、本番DBが手作業で変更され、マイグレーションへ反映されていないことがあります。また、外部APIのキーが旧担当者のメールアドレスにひも付き、検証環境が存在しない場合もあります。

新保守先は見積前に、次の再現テストを行います。

1. 空の環境へリポジトリを複製
2. 文書化された手順だけでビルド
3. バックアップからDBを復元
4. 主要API・バッチ・画面をテスト
5. 既知障害を再現し、監視で検知
6. テスト環境からリリースし、切り戻し

Gate 2のレッドフラグと通過基準

• レッドフラグ: 見積前調査をせず「そのまま保守できる」と断言する
• レッドフラグ: 本番環境でしかテストできない
• レッドフラグ: バックアップはあるが復元した記録がない
• 通過基準: 第三者が新環境で主要機能を再現し、再現できない部分を初期調査費・再作成費として見積へ分離できる

Gate 3：運用継続性（20点）

具体例：仕様書にない「月末だけの手作業」が止まる

販売管理システムでは、月末に担当者がCSVを加工し、特定の順序でバッチを実行してから請求書を確定していることがあります。設計書に記載がなく、旧ベンダー担当者と経理担当だけが知っていると、移管後最初の締め日に請求処理が止まります。

並行運用中に、平常時だけでなく次を一度通します。

• 月次締め、請求、在庫確定などの重要業務
• 障害受付、一次切り分け、復旧、経営報告
• リリースと切り戻し
• バックアップ復元
• 入退社に伴う権限変更
• 証明書・ドメイン・外部サービスの更新

Gate 3のレッドフラグと通過基準

• レッドフラグ: 運用手順が画面操作だけで、判断条件と例外処理がない
• レッドフラグ: 月次処理を新保守先が一度も実行していない
• レッドフラグ: 障害連絡先はあるが、誰が復旧判断するか不明
• 通過基準: 重要業務を新旧ベンダーと自社で実行し、新保守先単独でも継続できることを業務責任者が確認している

Gate 4：サービス水準・費用（20点）

具体例：月額30万円削減が、追加請求で消える

現行80万円、新保守50万円なら年間360万円の削減に見えます。しかし、初期調査200万円、資料再作成100万円、並行運用160万円が発生すると、初年度は100万円増です。さらに、軽微改修と夜間障害がすべて別費用なら、2年目以降も期待どおり下がりません。

24か月総費用 = 旧保守の残存費 + 新保守24か月分
             + 初期調査 + 資料再作成 + 並行運用
             + 想定追加改修 + クラウド・ライセンス
             + 社内移管工数 × 社内時間単価

Gate 4のレッドフラグと通過基準

• レッドフラグ: SLAが「速やかに」「可能な限り」で数値化されていない
• レッドフラグ: 安い月額だけが提示され、除外作業と追加単価がない
• レッドフラグ: 月次報告が作業時間の報告だけで、障害・課題・改善を含まない
• 通過基準: 候補会社を同一条件で24か月比較し、費用だけでなく初動・復旧・改修速度・未対応課題を経営会議で比較できる

Gate 5：移管統制（20点）

具体例：二社とも「相手の担当」と回答する

並行運用中に障害が起き、旧ベンダーは「新会社が変更したため対象外」、新ベンダーは「旧環境の問題なので対象外」と回答するケースです。契約を二重にしても、責任分界がなければ可用性は上がりません。

障害、問い合わせ、軽微改修、リリース、監視、バックアップ、セキュリティ対応ごとに、次を決めます。

• 最初に受け付ける会社
• 原因を切り分ける会社
• 復旧を承認する自社責任者
• 顧客・経営へ報告する担当
• 費用負担を判断する条件
• 旧ベンダーから新ベンダーへ責任が移る日

Gate 5のレッドフラグと通過基準

• レッドフラグ: 契約開始日と完全移行日が同じ
• レッドフラグ: 旧ベンダー権限を残したまま責任だけ終了する
• レッドフラグ: 移管判定が「資料を受領した」で終わる
• 通過基準: 障害・リリース・復元・権限変更を実地訓練し、残課題と例外を経営者が承認してから旧契約を終了する

100点の読み方

GXO式・保守移管5ゲート100点判定表をCSVでダウンロード

25項目を同じ結論にする「0・2・4点」証拠アンカー

同じ会社を部長は90点、担当者は60点と採点する状態では、解約判断に使えません。25項目すべてに次の共通ルールを適用し、条件書のページと証拠IDを判定表へ記録します。

ファイルの存在だけでは満点にしません。構成図は現行環境と一致するか、手順書は新担当者が実行できるか、バックアップは復元できるか、契約条項は対象資産を特定できるかまで確認します。更新日が古い資料は、現物との差分を別紙にしない限り最大2点です。

旧ベンダーが資料を出さない場合の代替回収と停止線

旧ベンダー非協力を「新会社が何とかする」で処理すると、推測に費用を払うことになります。資産ごとに代替回収を行い、それでも確認できないものは移管範囲から外すか、解約停止条件にします。

契約上の成果物返還、著作権、個人情報、解約義務に争いがある場合は、事実と契約書を整理して弁護士等へ確認します。この判定表は個別の法的判断を代替しません。

システム形態別：同じ「引き継ぎ」でも合格証拠は違う

3つの記入済みケース：点数と解約判断

以下は判定方法を示す架空例であり、実在企業やGXOの支援実績ではありません。

70点の製造業例を「条件付き合格」にしてはいけません。復元不能は総合点で相殺できない重大欠陥だからです。82点のEC例も、いきなり全範囲を切り替えず、平日日中から段階移管します。94点でも残点を口約束にせず、責任者と期限を付けて完全移管議事録へ残します。

総合点より優先する7つの重大欠陥

次のどれかがある場合、総合点が85点以上でも旧契約を終了しません。

1. ソース・設計・データを第三者が利用または改修できる権利を確認できない
2. 自社または新保守先がクラウド、ドメイン、証明書の管理権限を持てない
3. 本番とリポジトリの一致を確認できず、新環境で再現できない
4. バックアップから必要時間内に復元できない
5. 売上・請求・出荷に関わる重要運用を新担当者が単独実行していない
6. 並行運用中に障害を最初に受け付ける主体が決まっていない
7. 旧契約終了後も旧ベンダーの個人アカウントや秘密情報が残る

採点結果を90日移管計画へ転記する

判定表は点数を付けて終わりではありません。0点と2点を、90日計画、契約別紙、完全移管議事録へ一度ずつ転記します。

Day 30は「資料を受け取った日」ではなく技術再現の合否、Day 60は新担当者が重要運用を実行できるか、Day 90は重大欠陥がゼロかを判定します。未達なら日付を優先せず、並行運用を延長するか移管範囲を縮小します。

5ゲート判定表の根拠と検証方法

5ゲートは、公開資料の文言を並べたものではありません。GXOが、デジタル庁のシステム整備・管理の共通ルール、IPAのモデル契約、非機能要求、情報セキュリティ対策を、保守移管の経営判断へ使える形に再構成したものです。

• 判定表バージョン: 2.0（2026年7月14日）。25項目・0/2/4点の証拠採点、7つの重大欠陥、代替回収、90日計画への転記を追加
• 監修範囲: GXO AI・DX開発チームが、システム移管、保守運用、要件・非機能、技術再現性を確認
• 非監修範囲: 個別契約の法律判断、特定製品の適合保証、停止損失の保証
• 更新条件: 公式資料の改定、実地利用で不足項目が判明した場合に版番号と更新日を変更
• 検証可能性: 各点数に証拠ファイルまたは実地テスト結果を付け、口頭説明だけの項目は満点にしない

この運用により、「資料があるから移管できる」「月額が安いから成功する」という判断を避けられます。

旧ベンダーへ依頼する資料一覧

既存ベンダーへ引き継ぎを依頼するときは、口頭で「資料をください」と言うだけでは足りません。何を、いつまでに、どの形式で、誰へ渡すかを明確にします。

依頼すべき資料は次の通りです。

• 契約: 現行保守契約書、SLA、作業範囲、除外範囲、追加費用条件
• 構成: 最新のシステム構成図、ネットワーク図、外部連携一覧
• コード: ソースコードのリポジトリ、ブランチ運用、デプロイ手順、リリース履歴
• 環境: 本番、検証、開発環境の構成、ミドルウェア、バージョン、環境変数
• 仕様: DB定義、主要テーブル、バッチ、帳票、API、CSV連携の仕様
• 運用: 定常運用手順、月次処理、締め処理、バックアップ、復元手順
• 障害: 障害履歴、原因、復旧手順、暫定対応、再発防止策
• 改修: 改修履歴、見積、工数、テスト結果、リリース判定
• 権限: 管理者権限、クラウド権限、ドメイン、証明書、APIキー、外部SaaS契約
• 監視: 監視対象、通知先、閾値、エスカレーション、夜間休日対応ルール
• 残課題: 未対応課題、技術負債、既知の制約、今後の更新期限

旧ベンダーがすべてを出せない場合でも、それだけで責める必要はありません。重要なのは、出せないものを特定し、新ベンダーの初期調査範囲と見積条件に入れることです。資料がないものを「ないまま安く保守してください」と依頼すると、新ベンダーも旧ベンダーと同じように属人化します。

移管後の月次レポートで見るKPI

保守先変更は、移管して終わりではありません。移管後3か月は、月次レポートで改善が起きているかを見ます。

保守費削減の成果は、月額が下がったことだけではありません。障害が減る、問い合わせが減る、改修が速くなる、追加費用が読める、権限が整理される、バックアップ復元が確認できる。この状態になって初めて、保守先変更は成功と言えます。

保守先を変えない方がよいケース

保守先変更は万能ではありません。次の状態では、いきなり別会社へ変えるより、先に現行整理や再交渉をした方がよい場合があります。

• 既存ベンダーが業務理解を深く持ち、障害対応も速い
• 保守費は高いが、軽微改修、監視、障害対応、改善提案が含まれている
• 社内に業務担当が少なく、新ベンダーへ説明できる人がいない
• システムが古すぎて、保守先変更より刷新判断が必要
• ソースコードやクラウド契約の権利が曖昧で、先に契約整理が必要
• 重要な制度改正、繁忙期、大型リリース直前で移管リスクが高い
• 既存ベンダーとの関係改善で、費用内訳やSLAを見直せる余地がある

この場合は、いきなり解約ではなく、保守範囲の再定義、月次報告の改善、SLAの明文化、軽微改修枠の整理、資料整備の依頼から始めます。それでも改善しない場合に、既存ベンダー変更へ進む方が安全です。

保守先変更とレガシー刷新の分岐点

保守費が高い原因が、保守会社ではなくシステムの古さにある場合があります。この場合、保守先を変えても根本的には安くなりません。

経営判断としては、短期は保守先変更で止血し、中期は刷新計画を作るという選択もあります。重要なのは、保守費削減と刷新投資を同じ会議で混ぜないことです。保守費は現行を安全に動かす費用、刷新は将来の業務とデータ活用に向けた投資です。目的が違うため、評価軸も分けるべきです。

初回診断で作るべき成果物

保守先変更を相談する段階で、最初から新しい保守契約まで決める必要はありません。むしろ、最初の診断では「変えるべきか」「変えるならどこからか」「変えないなら何を交渉するか」を決めるための成果物を作るべきです。

この成果物があれば、既存ベンダーとの交渉にも、新保守先候補との面談にも使えます。逆に、成果物がないまま候補会社へ「月額いくらで保守できますか」と聞くと、各社の前提がばらばらになり、比較できない見積が集まります。

よくある質問

Q. 保守費が高い場合、まず相見積を取ればよいですか

相見積を取る前に、現在の保守範囲と引き継ぎ資産を整理してください。現行の範囲が不明なまま相見積を取ると、安い見積は出ますが、実際には障害対応、調査、軽微改修、セキュリティ対応が別費用になっていることがあります。相見積は、同じ前提条件を候補会社へ渡せる状態になってから有効です。

Q. 既存ベンダーに不満がある場合、すぐ解約してよいですか

解約通知の前に、資料、権限、契約、クラウド名義、ソースコード、障害履歴を確認してください。解約後に協力を求めるより、契約中に引き継ぎ成果物を明確にした方が進めやすい場合があります。特に本番環境やドメイン、証明書、クラウド契約がベンダー管理の場合は、先に名義と権限を整理するべきです。

Q. 新しい保守先が「資料がなくても対応できる」と言っています。信じてよいですか

資料がなくても調査から入ることは可能です。ただし、資料がない状態で安く断言する会社は注意が必要です。良い候補会社は、資料不足を前提に、初期調査、対象外、追加費用条件、リスク、段階移管を説明します。資料がないこと自体より、資料がないリスクを見積に入れているかが重要です。

Q. 保守先変更でどれくらい保守費を下げられますか

一律には言えません。削減できるのは、不要な定例、重複監視、過剰な待機、属人的問い合わせ、使われていない軽微改修枠などがある場合です。一方で、障害対応、バックアップ、セキュリティ、権限管理、変更管理を削ると、安くなっても危険です。初年度は移管費で増えることもあるため、2年目以降の総額と品質KPIで判断してください。

Q. 保守先変更とレガシー刷新はどちらを先に考えるべきですか

業務停止リスクが高いなら、まず保守の安定化です。古い環境、資料不足、障害多発、権限不備を放置したまま刷新に入ると、要件定義が崩れます。一方で、現行システムが事業成長、AI活用、データ連携、セキュリティ対応の制約になっている場合は、保守先変更だけでなく刷新計画も並行して作るべきです。

GXOに相談すべきタイミング

次のどれかに当てはまるなら、記事を読むだけで止めず、保守費診断か既存ベンダー変更レビューから相談してください。

• 保守費の内訳を経営会議で説明できない
• 既存ベンダーの月額、追加見積、障害対応が妥当か分からない
• 解約前に、何を引き継がせるべきか整理したい
• 新しい保守先候補の見積が安いが、抜け漏れが不安
• ソースコード、クラウド、ドメイン、証明書、権限が誰の管理か曖昧
• レガシー刷新すべきか、保守先変更で足りるか判断したい
• 90日で安全に移管する計画を作りたい

GXOでは、保守費内訳診断、既存保守契約レビュー、引き継ぎ資料チェック、候補会社見積レビュー、90日移管計画、保守運用改善、レガシー刷新の優先順位整理を支援できます。

相談先は システム開発・DXの相談 です。

出典・参照した一次情報

• デジタル庁「デジタル社会推進標準ガイドライン」: https://www.digital.go.jp/resources/standard_guidelines
• IPA「情報システム・モデル取引・契約書」: https://www.ipa.go.jp/digital/model/index.html
• IPA「非機能要求グレード」: https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html
• IPA「中小企業の情報セキュリティ対策ガイドライン」: https://www.ipa.go.jp/security/guide/sme/about.html
• IPA「情報セキュリティ関連ガイド」: https://www.ipa.go.jp/security/guide/

上記は2026-07-13に公式ページと内容を確認しました。この記事は一般的な実務整理であり、個別の契約解釈、システム停止リスク、法的判断、セキュリティ適合性を保証するものではありません。既存契約、個別システム、外部サービスの条件は、契約書、社内規程、顧問弁護士、専門家、各ベンダーの公式情報を確認してください。