システム保守会社を選ぶときに最初に決めるべきは「どこまでを保守として任せるか」という範囲であって、「どの会社が良いか」ではありません。 範囲を決めずに「保守をお願いします」と発注すると、障害対応なのか、機能改修なのか、セキュリティ更新なのかが曖昧なまま月額だけが決まり、いざという時に「それは契約外です」と言われる——保守で最も多いトラブルはここから起きます。
本記事は、システムの保守会社を新しく選ぶ、あるいは今の保守が妥当か見直したい経営者・情シス・管理部門の方に向けて、保守会社の選び方を「発注する側の判断」として整理します。保守先を変更する手前の見積もり整理は保守先変更の見積もり前整理ガイド、保守・運用契約の読み方は保守・運用契約の読み方にまとめています。本記事はその前提として、**「保守会社をどう評価し、何を基準に選ぶか」**に絞ります。
目次
- 結論：保守会社選びは「範囲の定義」から始まる
- そもそも保守会社にはどんな種類があるか
- 保守会社を選ぶ5つの判断軸
- 保守費用が妥当かを見る4つの視点
- 保守レベルを3段階で設計する
- 保守契約で必ず確認すべき条項
- 保守を丸投げにしないための線引き
- 保守会社選びでよくある失敗パターン
- 保守会社 選定前チェックリスト
- ケース別の考え方
- よくある質問（FAQ）
- 保守会社の選定・見直しで迷ったら
<a id="conclusion"></a>
結論：保守会社選びは「範囲の定義」から始まる
保守は「安く継続できればよい」と考えられがちですが、実際に効いてくるのは**「止まった時・変えたい時に、どこまで・どのスピードで対応してくれるか」**です。ここを曖昧にしたまま月額の安さだけで選ぶと、障害時に「対応範囲外」「別途見積もり」と言われ、結局は割高で、しかも止まっている時間が伸びます。
良い保守会社を選ぶ発注側は、契約前に次の3つを言語化しています。
- 止まってはいけない範囲（業務が止まると困る機能はどれか）
- 求める応答・復旧のスピード（何時間で一次対応・復旧を求めるか）
- 保守に含めたい作業の種類（監視・障害対応・軽微改修・セキュリティ更新・問い合わせ対応のどこまでか）
この3つが決まっていれば、複数の保守会社を同じ土俵で比較でき、費用の妥当性も判断できます。逆に、これが無いまま相見積もりを取っても、各社バラバラの前提で見積もってくるため、比較になりません。
<a id="type"></a>
INSTANT ESTIMATE
計算式より、60秒で概算を出しませんか？
システム種別・規模・連携先を選ぶだけで、開発費用・期間・月額運用費の概算をその場で表示します。
そもそも保守会社にはどんな種類があるか
「保守会社」と一口に言っても、得意領域はかなり異なります。自社のシステムに合うタイプを見極めるのが第一歩です。
横にスクロールして確認できます
| タイプ | 得意領域 | 向く状況 | 注意点 |
|---|---|---|---|
| 開発元（作った会社） | そのシステムの中身に精通 | 作った会社にそのまま継続保守を頼む | 他社に切り替えにくくなりやすい |
| 独立系の保守・運用会社 | 監視・障害対応・複数システムの面倒 | 開発元と縁を切りたい／複数システムをまとめたい | システム内部の理解に引き継ぎ期間が要る |
| インフラ・クラウド運用特化 | サーバ・ネットワーク・クラウド | クラウド移行後の運用 | アプリ側の改修は範囲外のことが多い |
| セキュリティ特化 | 脆弱性対応・監視・インシデント | セキュリティ要件が高い | 業務機能の改修は別会社が要る |
多くの中小企業のシステムは「アプリ＋インフラ＋セキュリティ」がまたがっているため、どこを誰に任せ、責任の境界をどう引くかが重要になります。1社にまとめると窓口は楽ですが割高になりやすく、分けると安くなる一方で障害時に責任のたらい回しが起きやすい——このトレードオフを理解した上で選びます。生成AIコードを含む現代の保守で「月額保守だけでは足りない」論点は月額保守だけでは足りない保守契約も参照してください。
<a id="axis"></a>
保守会社を選ぶ5つの判断軸
保守会社は「安さ」だけで選ぶと後悔します。次の5軸で評価してください。
軸1：対応範囲が明確か
監視・障害対応・軽微改修・セキュリティ更新・問い合わせ対応のうち、何が含まれ、何が別料金かを明文化できる会社か。「なんでも対応します」は、裏を返せば範囲が決まっていないということです。
軸2：応答・復旧の基準（SLA）を約束できるか
「障害時に何時間で一次対応するか」「復旧目標をどう置くか」を数字で示せるか。ここを口約束で済ませる会社は、いざという時に動きが遅れます。
軸3：システムの引き継ぎ・理解にどう向き合うか
開発元でない会社に頼む場合、システム内部を理解する期間と体制が要ります。引き継ぎ計画とドキュメント整備をどう進めるかを説明できる会社を選びます。
軸4：ロックインを避けられるか
その会社でないと保守できない状態になっていないか。ソースコードの権利、ドキュメント、構成情報が発注側に残る形かを確認します。ロックインと引き継ぎの論点は既存ベンダーのロックイン・引き継ぎにも整理しています。
軸5：改善提案があるか
言われたことだけを直す「守りの保守」か、業務改善やコスト削減まで提案してくれる「攻めの保守」か。長期で付き合うなら、提案力の有無が費用対効果を大きく左右します。
<a id="cost"></a>
保守費用が妥当かを見る4つの視点
保守費用は「開発費の何%」といった相場だけで判断できません。金額の妥当性は、次の4点で見ます。
- 何に対する費用か分解されているか：監視・障害対応・改修工数・問い合わせ対応など、費用の内訳が示されているか。総額いくらだけの見積もりは比較も交渉もできません。
- 想定する作業量と釣り合っているか：ほとんど変更しないシステムに手厚い月額を払っていないか。逆に、頻繁に変えるのに軽微改修の枠が小さすぎないか。
- 別途費用の発生条件が明確か：「これは別料金」の線引きが契約に落ちているか。ここが曖昧だと、請求のたびに揉めます。
- 止まった時のコストと比較できているか：安い保守で復旧が遅れると、業務停止の損失が保守費の節約を上回ることがあります。費用は「止まらないための保険」として評価します。
保守費だけを切り出して安いか高いかを論じるより、システム全体の費用構造（初期開発・改修・保守）の中で妥当かを見るのが正確です。費用構造の考え方は中小企業のシステム開発費用ガイドを参照してください。
<a id="level"></a>
保守レベルを3段階で設計する
保守は「入る／入らない」の二択ではなく、業務の重要度に応じてレベルを分けると、費用の無駄も対応不足も避けられます。全システムを一律に手厚く守るのは割高で、逆に一律に薄くすると重要な業務が止まった時に耐えられません。次の3段階で自社のシステムを仕分けてください。
横にスクロールして確認できます
| レベル | 対象 | 求める内容 | 費用感の考え方 |
|---|---|---|---|
| 最低限 | 止まっても業務影響が小さいシステム | 障害の受付と対応、セキュリティ更新のみ | 薄く。応答スピードは緩くてよい |
| 標準 | 通常業務で使うが即時復旧までは不要 | 監視＋障害対応＋軽微改修の枠 | 中庸。SLAをほどほどに定める |
| 手厚い | 止まると売上・現場が直接止まる基幹 | 短時間の一次対応・復旧目標、優先対応、改善提案 | 厚く。ここに費用を寄せる |
このレベル分けを持っておくと、保守会社との交渉が具体的になります。「全部お願いします」ではなく「この基幹は手厚く、この社内ツールは最低限で」と伝えられれば、各社は同じ前提で見積もれ、費用配分の妥当性も判断できます。限られた保守予算を、止まってはいけないところに集中させる——これが保守レベル設計の狙いです。
<a id="contract"></a>
保守契約で必ず確認すべき条項
保守会社を決めたら、契約書で次の条項を必ず確認します。ここが曖昧なまま契約すると、良い会社を選んでもトラブルになります。
- 対応範囲：何が含まれ、何が別料金か。改修は月何時間まで含むか。
- 応答・復旧の基準（SLA）：一次対応の時間、対応する時間帯（平日日中のみか、夜間・休日を含むか）、復旧目標。
- エスカレーション：重大障害時に誰にどう連絡が上がり、どの体制で対応するか。
- 別途費用の発生条件：追加改修・臨時対応・大規模障害の費用がどう決まるか。
- 値上げ・更新条件：契約更新時の値上げ条件、途中解約の条件。
- 成果物と情報の引き渡し：ドキュメント・構成情報・権利が発注側に残るか。契約終了時の引き継ぎ義務があるか。
特に対応時間帯と復旧目標は見落とされがちです。「24時間対応」と思っていたら平日日中のみだった、というズレは、障害が起きて初めて発覚します。契約前に必ず言葉で確認してください。保守・運用契約の条文の読み方は保守・運用契約の読み方も参考になります。
<a id="scope"></a>
保守を丸投げにしないための線引き
保守を外部に委託しても、社内に残すべき役割があります。ここを丸投げにすると、費用も品質もコントロールできなくなります。
横にスクロールして確認できます
| 領域 | 保守会社に任せる | 社内に残す |
|---|---|---|
| 障害の一次対応・復旧作業 | ◎ | △ 状況把握は社内 |
| 監視・定期メンテナンス | ◎ | △ 報告の確認は社内 |
| 何を優先して直すかの判断 | △ 提案は受ける | ◎ 業務優先度は社内 |
| 保守費・別途費用の妥当性判断 | × | ◎ 社内で評価 |
| システム構成・権利情報の保持 | × | ◎ 社内資産として保持 |
「◎ 社内に残す」列が、保守を丸投げにしないための最低ラインです。特に構成情報と権利を社内に残すことは、将来の保守先変更やシステム刷新の自由度を守るうえで欠かせません。
<a id="failure"></a>
保守会社選びでよくある失敗パターン
- 範囲を決めずに月額だけで契約する：障害時に「対応範囲外」となり、別途費用と遅延が発生する。
- 相見積もりの前提がバラバラ：各社が違う範囲・違うSLAで見積もり、金額だけ見て安い会社を選んでしまう。
- 開発元にそのまま頼み続けて割高に気づかない：切り替えを検討したことがなく、費用の妥当性を一度も検証していない。
- 引き継ぎ計画がないまま乗り換える：新しい保守会社がシステムを理解しきれず、障害対応が遅れる。
- 構成情報・権利を確認しないまま任せる：気づけばその会社でしか保守できず、値上げやサービス低下を受け入れざるを得なくなる。
これらは、次のチェックリストを選定前に使えばほぼ防げます。
<a id="checklist"></a>
保守会社 選定前チェックリスト
- 止まってはいけない機能を業務観点で洗い出してある
- 求める**応答・復旧のスピード（SLA）**を数字で言える
- 保守に含めたい作業の種類（監視／障害対応／軽微改修／セキュリティ更新／問い合わせ）を整理してある
- 含む作業と別料金の作業の線引きを確認する準備がある
- 同じ前提で複数社に見積もりを依頼できる
- 引き継ぎ計画とドキュメント整備の進め方を確認する
- ソースコードの権利・構成情報が社内に残る形かを確認する
- 保守費を、止まった時の損失と比較して評価している
- 社内に保守を管理する窓口担当を置いている
<a id="case"></a>
ケース別の考え方
ケースA：作った開発会社にそのまま保守を頼んでいる
内部理解が深く安心な一方、費用の妥当性を一度も検証していないなら見直す価値があります。切り替えないとしても、範囲・SLA・別途費用を明文化し直すだけで、後のトラブルを減らせます。
ケースB：保守が高い気がするが妥当か分からない
まず「何に対する費用か」を分解してもらいます。分解できない・説明が曖昧な場合は、第三者に見積もりの妥当性を確認するのが有効です。
ケースC：保守切れ・サポート終了が迫っている
OS・ミドルウェア・ハードの保守終了は、放置すると障害時に復旧できないリスクになります。保守会社選びと並行して、保守切れ対応ガイドの観点で移行計画も検討してください。
ケースD：複数ベンダーで保守がバラバラ
窓口が分散し、障害時に責任のたらい回しが起きているなら、責任分界の整理と一元化を検討します。まとめる／分けるは費用と障害対応スピードのトレードオフで判断します。
<a id="faq"></a>
よくある質問（FAQ）
Q. 保守費用の相場はいくらですか？ A. 一律の相場では判断できません。システムの規模・変更頻度・求めるSLA・含める作業範囲で大きく変わります。相場より、「何に対する費用か」が分解され、想定作業量と釣り合っているかで妥当性を見てください。
Q. 開発した会社に保守も頼むべきですか？ A. 内部理解の面では合理的ですが、ロックインと費用の妥当性は別途確認すべきです。切り替えの選択肢を残すため、権利と構成情報が社内に残る形にしておきましょう。
Q. 保守会社を変えると障害対応が不安です。 A. 引き継ぎ計画とドキュメント整備を条件に入れれば、リスクは大きく下げられます。引き継ぎ期間を設けず一斉に切り替えるのが最も危険です。
Q. 安い保守会社を選んで大丈夫ですか？ A. 安さだけで選ぶと、対応範囲が狭かったり復旧が遅かったりして、止まった時の損失が節約分を上回ることがあります。費用は「止まらないための保険」として、SLAと範囲込みで評価してください。
Q. 複数システムの保守を1社にまとめるべきですか、分けるべきですか？ A. まとめると窓口が一本化されて管理が楽になり、障害時のたらい回しも減りますが、割高になりやすくなります。分けると費用は下げやすい一方、責任の境界を明確にしないと障害時に対応が滞ります。止まってはいけない基幹だけ手厚い1社に集約し、影響の小さいものは分ける、といった折衷が現実的です。
Q. 今の保守が妥当か、社内では判断できません。 A. 第三者による見積もり・保守内容のレビューが有効です。発注側に判断軸が無いと、値上げや範囲縮小に気づけません。まずは「何に対する費用か」を分解してもらうところから始めてください。
<a id="cta"></a>
保守会社の選定・見直しで迷ったら
保守会社選びは、「どの会社が良いか」より**「どこまでを任せ、どのスピードで、いくらで守ってもらうか」を発注側が定義できているか**で成否が決まります。そしてその定義は、止まってはいけない範囲・求めるSLA・含める作業の種類を言語化することから始まります。
GXOは、特定の保守を売り込む前に、保守範囲の整理と、いまの保守費・保守内容が妥当かの第三者チェックからご一緒します。
- 保守切れ・サポート終了が迫っていて急いで整理したい → レガシー・保守終了の緊急整理
- 今の保守費・見積もりが妥当か第三者に見てほしい → 見積もりセカンドオピニオン
- 保守も含めたシステム全体の体制を相談したい → システム開発・運用の相談
- まず自社のIT・DXの現在地を診断したい → DX成熟度診断
「どの会社か」より先に「任せる範囲とスピード」を決める。その整理を、契約前にご一緒します。 [//]: # (strict-audit-extension-20260717)
GXO式「保守会社選定」100点評価表
GXO独自分析では、月額の安さではなく、事故時と解約時に機能するかを採点する。
横にスクロールして確認できます
| 評価軸 | 配点 | 満点の証拠 |
|---|---|---|
| 対象範囲 | 20 | システム、環境、時間、軽微改修、対象外を一覧化 |
| 障害SLA | 20 | 重大度、受付、初動、復旧、報告、エスカレーション |
| セキュリティ | 20 | 権限、ログ、パッチ、脆弱性、バックアップ復元 |
| 改善・費用 | 20 | 月次実績、未対応課題、別料金条件、3年TCO |
| 引継ぎ・終了 | 20 | ソース、設計、環境、API、名義、90日移管計画 |
80点以上は選定候補、60〜79点は3か月限定契約、59点以下は見送る。バックアップ復元未確認、管理者権限不明、障害受付先なし、保守内外の境界なし、解約後の引継ぎなしは強制停止条件である。
SLA・費用比較テンプレート
対象 / 対象外 / 受付時間：
重大度1：初動___分 / 復旧目標___時間 / 報告___時間
費用：月額___万円 / 時間外___円 / 改修___円 / 移管___万円
月次成果：障害 / 問合せ / 変更 / パッチ / 復元 / 改善
終了：通知___日前 / 引継ぎ___日 / 成果物 / 権限停止
月額40万円でも時間外年120万円、改修年200万円、初年度移管150万円なら初年度950万円である。月額55万円ですべて含む会社の年660万円より高い可能性がある。このGXO計算例で、保守費用の内訳と例外を比較する。チェックリスト・RFP・責任分界が作れない会社は丸投げに向かない。
一次資料と根拠と検証方法
版番号: GXO-MAINT-VENDOR-20260717-v1.0。確認日: 2026年7月17日。検証可能性の証拠は契約、SLA、チケット、監視・権限ログ、復元記録、請求、引継ぎ台帳である。対象システム・体制・料金・脅威・契約変更を更新条件にする。公式資料の事実とGXOの見解である配点・費用例を分離し、無停止を保証しない。小規模SaaSだけなら自社比較できるが、基幹・EC・個人情報・24時間運用を含む会社は第三者への相談が向く。保守引継ぎ診断で現行契約から整理できる。
