システム保守契約の範囲｜法改正・OS更新・軽微な改修は含まれるのか

システムの保守契約の範囲がどこまでかを確かめたくなるのは、たいてい「これは保守に含まれますか」と聞いて「別途お見積もりになります」と返ってきた直後です。契約書を開いても、そこには「乙は、本件システムの保守業務を行う」としか書かれていない。含まれるのか含まれないのかを判断する材料が、契約書の本文には載っていません。

この記事は、その状態から抜け出すための手順書です。相場や値下げ交渉の話はしません。手元の契約書一式を「含む／別料金／対象外／不明」の4状態に仕分け、書かれていない項目をベンダーに書かせるところまでを扱います。

TL;DR｜範囲は契約書の本文ではなく「業務仕様書と受託条件明細」で決まる

• 保守の範囲は契約書の本文には書かれていません。 公開されているモデル契約でも、範囲は基本契約書ではなく、個別契約書とその添付（業務仕様書・受託条件明細）側で決める設計になっています。まず取り寄せるべきは、この添付2点（本記事では以下「別紙」と呼びます）です
• 判断は「妥当／不当」ではなく、含む／別料金／対象外／不明の4状態で行います。値段の話に入れるのは、この仕分けが終わってからです
• いちばん危険なのは「不明」です。 公開約款のなかには「明示的に挙げられていない作業」を対象外とする受け皿条項を置いているものがあり、その設計では不明はそのまま対象外に倒れます
• 法改正対応は、モデル契約では保守の例として挙げられています。 ただし実際に公開されている保守約款4件を確認したところ、法令改正への対応を明記していたのは1件だけで、その1件も、対応の可否をベンダー側が判断すること、施行日以降の提供になる場合があることを条件としていました
• OS・ミドルウェアの更新は、同じ「保守」という言葉でも約款によって扱いが正反対です。 確認した4件のなかに、更新適用を保守に含むもの、別料金とするもの、対象外とするものが同時に存在しました
• 多くの場合、バグ修正が無償か有償かの分かれ目は保守契約ではなく、開発契約の契約不適合責任の条項です。見る紙が違います
• 範囲を広げる交渉より先に、いま何がどう書かれているかを確定させてください。そのうえで「現行のままで問題ない」という結論になることも普通にあります

なぜ契約書を読んでも範囲が分からないのか｜モデル契約の4階層

保守契約書を読んでも範囲が分からないのは、読み方が悪いからではありません。そもそも範囲を本文に書かない構造になっているからです。

独立行政法人情報処理推進機構（IPA）と経済産業省が公開している「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）＜第二版＞」（2020年12月22日公開、文書は2025年4月8日更新）は、保守運用の委託契約を次の4階層で組み立てています。

同モデル契約は、この構造をとった理由を明記しています。保守運用の作業は「極めて多種多様であり、広範に渡る」ため、「全ての受託業務のパターンを網羅した一律的な雛形を作成することができない」からです。そこで共通条項だけを基本契約書に置き、実際の中身は下の階層へ送っています。

この設計が発注側にとって何を意味するかは単純です。手元に基本契約書しかない状態では、範囲は原理的に判定できません。 見るべき紙は3番目と4番目です。

個別契約で決めるべき8項目

同モデル契約の第3条第1項は、業務に着手する前に協議して個別契約で定める取引条件として、次の8項目を挙げています。

1. 契約形態（請負・準委任）
2. 業務内容
3. 対象とする情報システムの範囲及びその詳細
4. 本件業務の実施開始日及び実施期間
5. 甲・乙の役割分担
6. 甲が乙に提供する情報、資料
7. 委託料及びその支払方法
8. その他本件業務遂行に必要な事項

範囲に直接関わるのは2・3・5の3つです。このうち1つでも「別途協議」で止まっている契約は、範囲が確定していない状態だと考えてください。特に3（対象とする情報システムの範囲及びその詳細）が抜けていると、後から追加したサブシステムや他社が作った連携部分が対象なのかどうかで必ずもめます。

「どこまでの修正が保守か」は最初から論点になっている

同モデル契約には、アプリケーション保守サービスの業務仕様書サンプルが付いています。その業務内容は8区分で構成されており、第1区分の「本件業務実施状況管理」はさらに案件管理・インシデント管理・問題管理・変更管理・リリース管理・構成管理・定例報告の7項目に分かれています。

注目すべきは、そのサンプルに付された脚注です。

どこまでの修正が本件保守業務の対象となるか（新規ソフトウェア開発との境界線）については、受託条件明細等によりその範囲を明確に規定しておく必要がある。

つまり、保守と新規開発の境界が曖昧になることは、モデル契約の作成段階からすでに想定されている問題です。そして解決策として指定されているのは、契約書の本文ではなく受託条件明細等です。「うちの契約書には書いていない」のではなく、「書く場所が別にある」というのが正確な理解になります。

なお、このモデル契約のサンプル事例が対象としているのは、脚注に明記されているとおり「信頼性ガイドライン」の分類における(B)企業基幹システムです。小規模なWebサイトや業務ツールの保守は前提が異なるため、階層の考え方は流用できても、業務区分の細かさをそのまま自社に当てはめる必要はありません。

（参考までに、このモデル契約の第一版は2007年4月に経済産業省商務情報政策局情報処理振興課が単独名義で公開したもので、第二版の表紙には独立行政法人情報処理推進機構と経済産業省が併記されています。版によって名義の立て方が異なります。）

4状態への仕分け｜含む／別料金／対象外／不明

範囲の議論が空回りするのは、「含まれるか、含まれないか」の2択で考えているからです。実際の契約書には、その中間が2つあります。

「別料金」と「対象外」を分けているのは、事故が起きたときの動きがまったく違うからです。別料金なら発注書1枚で動けますが、対象外なら合意の交渉から始まります。障害が起きている最中に契約交渉をするのは現実的ではありません。

なお、姉妹記事のシステム保守費用の相場と妥当性も4状態を使いますが、あちらは「説明済み／要確認／高リスク／判断不能」で、金額の根拠を発注側が確認できているかを測ります。本記事の4状態が測るのは契約書に何が書かれているかです。軸が違うので、混ぜて使わないでください。

「不明」は放っておくと「対象外」になる

不明をいちばん危険な状態と書いたのには理由があります。公開されている保守約款のなかには、対象外作業を列挙したうえで最後に次のような受け皿条項（法務では包括条項とも呼びます）を置いているものがあるからです。

その他、前項に明示的に挙げられていない作業

これはゾーホージャパン株式会社の「年間保守サポートサービス規約」（2017年5月1日制定、2021年4月14日改定／2026年8月19日取得）の第4条第2項第11号です。同条第1項は「当社が提供する本サービスの範囲は、別紙により定めるものとします」としているので、この規約でいう別紙（本記事の略語とは別で、同社が定めるサービス範囲表）に挙がっていない作業は原則として対象外になるという組み立てです。

この設計自体は不当なものではありません。むしろ範囲が明確で、ベンダー側から見れば誠実な書き方です。同条は続けて、対象外の作業でも契約者が希望すれば受託の可否と料金を協議すると定めており、道が閉ざされているわけでもありません。問題は、発注側がこの構造を知らないまま「書いていないから、たぶんやってくれるだろう」と考えてしまうことにあります。この型の契約では、書かれていない作業は保守料の範囲では実施されません。

公開されている保守約款4件では、範囲がこう書かれている

「他社はどう書いているのか」を知らないまま自社の契約書だけを読んでも、何が抜けているのかは分かりません。ここでは、Web上で誰でも読める保守サービスの約款・規約4件を、2026年8月19日に取得して並べます。

4件はいずれも、自社の製品・サービスに対する保守約款です。 受託開発したスクラッチシステムの個別保守契約とは前提が違います。金額の相場としては使えません。ここで見てほしいのは金額ではなく、範囲を書く型がどれだけ違うかです。

論点別の比較

この表から読み取れる4つの型

型1：ポジティブリスト型（B） — 提供する作業を別紙に列挙し、そこに挙がっていないものは対象外にする。範囲は最も明確ですが、発注側が別紙を精読しないと事故ります。

型2：別料金型（C・D） — 範囲外の作業も、依頼して受諾されれば所定の料金で対応する。柔軟ですが、「所定の料金」が事前に開示されていなければ、予算は読めません。単価表があるかどうかが分かれ目です。

型3：定義条項型（C） — 契約の冒頭で「保守」と「開発」を言葉として定義し、境界を先に固定する。Cは第1条で「保守」をサーバ環境のセキュリティ・パフォーマンス維持のためのOS／ミドルウェアのアップデートとセキュリティパッチ適用と定義し、「開発」を新規作成・機能追加・修正を目的とした設計、コーディング、サーバ環境の設定などと定義しています。

型4：前提条件型（A・D） — 保守を提供する前提条件を先に定め、前提が崩れれば保守の対象から外れうる、という書き方をする。Aは対応OSを特定し、Dは製造元の通常サポートが続いていることを提供の前提条件にしています。範囲を広げる／狭めるのではなく、保守そのものが成立する条件を書く型です。

4件を並べて比較すると、境界がいちばん揉めにくいのは型3（定義条項型）です。型4は範囲の広狭とは別の軸なので、どの型の契約でも確認が要ります。この扱いは境界4で詳しく見ます。

「保守なのに対象範囲が狭い」は不当ではない

Cには、契約者自身が独自に開発したプラグイン、または第三者が開発したカスタムプラグインは保守サービスの対象外とし、同社が開発・作成したものは対象に含む、という規定があります。同じシステムのなかで、誰が作った部分かによって保守対象が変わるという設計です。

これは冷たい対応ではありません。他社が書いたコードの挙動を保証するには、その調査費用を全員の保守料に転嫁するしかないからです。発注側がすべきなのは抗議ではなく、自社のシステムのどの部分が誰の手で作られたのかを一覧にして、その一覧を契約書の別紙に載せてもらうことです。

判定マトリクス｜手元の契約書を20項目で仕分ける

ここまでで、4状態の定義と、実際の約款での書かれ方が揃いました。手元の契約書一式を仕分けます。

左端の作業項目について、契約書・業務仕様書・受託条件明細のどこかに右3列のような記載があるかを探します。3列のどれにも当たらなければ、その項目は「不明」です。

この20項目は、実務でもっとも金額が動き、もっとも解釈が割れる5つの論点に集約できます。該当する12項目は以降の「境界1〜5」で扱い、右端の「深掘り」列がその対応を示します。深掘り列が「—」の8項目のうち、対象環境と対象コンポーネントは質問8で、残る6項目は質問1（範囲を定めた別紙）と質問2（対象外作業の一覧）で確認できます。

以下の文言例は、前章の公開約款4件とIPAモデル契約の業務仕様書サンプルの記載を参考に、実務でよく見る書き方として一般化したものです。右3列の「—」は、確認した資料にその書き方の実例が見当たらなかった項目です。実務では記載が落ちやすく、そのまま「不明」になります。右端「深掘り」列の「—」は、独立した章を設けていない項目という意味です。

20項目のうち「不明」がいくつあったかを数えてください。この数が、有事にまず書面のやり取りから始めなければならない項目の数です。自社の契約が型1（ポジティブリスト型）なら、その多くは実質的に対象外だと考えてください。

仕分けた結果を見積書の金額と突き合わせたい場合は、システム保守見積書の見方が行項目の分解手順を扱っています。本記事が契約書の範囲条項、あちらが見積書の金額内訳という分担です。

手元の契約書と見積書を見ながら整理したい場合は、保守見積書の無料診断（登録不要）の「保守・運用」モードで、保守対象範囲・対応時間・改修の扱いなどを入力すると、確認事項が整理されます。結果を見るまでメールアドレスの入力も不要です。

境界1｜納品時からの不具合は、保守費で直すのか

「バグは保守で直してもらえるはずだ」と「それは保守の範囲外です」がぶつかる場面は、実は保守契約の話ではありません。見るべき紙が違います。

不具合には2種類あります。

1. 納品時点ですでに存在していた不具合 — 開発契約で約束した仕様を満たしていない状態
2. 稼働後に発生した不具合 — データ量の増加、外部サービスの仕様変更、環境の変化などで顕在化したもの

1は開発契約の契約不適合責任の領域、2は保守契約の領域です。IPAのモデル契約も、この責任の区分を脚注で明記しています。

実務的に、発生する障害が本来の開発フェーズの契約不適合（ソフトウエア自体の）に起因とするものと、保守運用の作業の問題に起因するものとが混在する場合がある。これらは法律上区別されるべきものであり、また工程分割発注における責任関係にもかかわるため、責任の切り分けを規定する必要がある。

つまり「保守か開発か」の前に、「開発契約の責任がまだ生きているか」を確認する順番になります。

条文はどうなっているか

民法（明治二十九年法律第八十九号）第637条第1項は、請負について次のように定めています。

前条本文に規定する場合において、注文者がその不適合を知った時から一年以内にその旨を請負人に通知しないときは、注文者は、その不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。

起点は「引渡しから1年」ではなく「不適合を知った時から1年」です。ただしこれは当事者の合意で変更できる規定で、実際の開発契約では別段の定めが置かれていることがあります。

これは推測ではありません。IPAのモデル契約の開発側（ソフトウェア開発委託基本モデル契約書）第29条第5項は、ベンダーが契約不適合責任を負う範囲を「前条の検収完了後〇ヶ月／○年以内」に通知された場合に限る、という書式にしています。その解説は、意図をこう説明しています。

民法上のデフォルトルールにかかわらず、契約不適合責任の期間制限の起算点を検収完了時という客観的なものとした。

確認すべきは民法ではなく、手元の開発契約書の契約不適合責任の条項、それも起算点と期間の2つだということになります。

なお、保守契約が準委任の形をとっている場合、受託者が負うのは民法第644条の善管注意義務です。IPAの保守運用側モデル契約（情報システム保守運用委託基本モデル契約書）第14条も、準委任型については「乙の責任は、本件業務を善良な管理者の注意をもって実施することに限られ、かかる注意をもって実施している限り、本件業務の内容、結果等について、乙は責任を負わないものとする。」とし、請負型については「本件業務の結果に、誤り、業務仕様書との不一致がある場合、乙は、当該誤り、不一致を修正するものとする。」としています。同号は続けて、この責任を負う期間を「実施した日から○年間」とする欄も置いています。同じ「保守」でも、準委任か請負かで結果への責任がまったく違います。 そして同条は「なお、準委任型又は請負型であるかは個別契約に定められるものとする。」とも書いています。ここでも決め手は基本契約書ではなく個別契約です。

準委任と請負で見積書の見え方がどう変わるかは、請負と準委任の違いは見積書のどこに出るかで扱っています。

具体的な事案が契約不適合に当たるかどうかの判断は、契約書の文言と経緯の評価を伴うため、弁護士にご確認ください。この記事で示せるのは、どの紙のどの条項を持っていけば話が早いかまでです。

この境界で確認すること

• 開発契約書の契約不適合責任の条項（期間の起算点と長さ、通知の方法）
• その期間が満了しているかどうか
• 保守契約が準委任か請負か（個別契約書に書かれている）
• 不具合の原因が納品物側か、稼働後の変化側かを、どちらの費用で調べるのか

4つ目が抜けていることがあります。原因を調べる作業そのものが誰の費用で行われるのかは、事前に決めておく価値があります。ロゴスウェアの約款には、自社製品に起因するか第三者製品に起因するかの切り分けが必要な場合に顧客が協力する義務が定められ、さらに障害対応でやむを得ずバージョンアップやパッチ適用が必要になった際に顧客が実施するシステム検証等の費用を同社が負担しない旨も書かれています。原因究明と復旧にコストがかかることは、契約でも織り込まれている前提です。

→ 確認質問4で聞きます。

境界2｜「軽微な改修」はどこまでが軽微なのか

「月◯時間まで軽微な改修対応を含む」という行は、保守見積書でよく見ます。しかし「軽微」の定義が別紙に書かれていないことがあります。

定義がないと何が起きるか。発注側は「画面に項目を1つ足すだけ」を軽微だと考え、ベンダーは「項目を足すと帳票・検索・CSV出力・権限設定・テストまで波及する」と考えます。どちらも正しく、どちらも譲る理由がありません。結果として、毎回その場の力関係で決まるという運用になります。

これを避けるには、次の4点を別紙に書いてもらいます。

工数ではなく変更の種類で定義するのがコツです。工数で定義すると「これは3時間で終わるはずだ」という水掛け論になりますが、種類で定義すれば、その改修が定義に当たるかどうかは仕様書を見れば決まります。

デジタルキューブの約款が「保守」と「開発」を用語の定義で分けているのは、まさにこの型です。「機能追加、修正を目的とした設計、コーディング」を開発と定義してしまえば、軽微かどうかを毎回議論する必要がなくなります。

→ 確認質問3で聞きます。

境界3｜法改正・税制・帳票の制度変更は保守か追加開発か

範囲の論点のなかで、金額の振れ幅がいちばん大きいのがここです。小さな修正で終わることも、要件定義からやり直す規模になることもあります。

モデル契約では「保守の例」として挙がっている

IPAのモデル契約は、業務仕様書サンプルのアプリケーション保守サービスを次のように定義しています（脚注）。

ユーザの動作環境などが変化した場合において、対象アプリケーション（ユーザ固有の業務を遂行するために作成されたプログラム群（例：受注システム、 給与計算システムなど））を使用できるように保ち続けるための修正及び性能改善、保守性改善（例：法律の改正による修正など）を実施するサービス。

「法律の改正による修正など」が、保守サービスの例として明示的に挙げられています。法改正対応を保守の一部と考えること自体は、モデル契約が示した枠組みのなかでは自然な理解です。

ただし同じモデル契約は、前掲のとおり「どこまでの修正が本件保守業務の対象となるか（新規ソフトウェア開発との境界線）については、受託条件明細等によりその範囲を明確に規定しておく必要がある」とも書いています。含めうるが、書かなければ決まらないというのが正確なところです。

実際の約款では、書かれていないほうが多かった

前章で並べた公開約款4件のうち、法令改正への対応を明記していたのは1件だけでした。エスアイ・システムの第3条は、提供するサービスの内容として次を挙げています。

労働者派遣法、消費税、所得税、社会保険などの法令が改定になった場合、新法令に対応したプログラムまたは対応方法の提供。但し、本ソフトウェアのプログラムの修正または対応方法の変更が可能であると判断した場合とし、この判断は乙において決定する。また、新法令に対応したプログラムまたは対応方法の提供は、新法令の成立から施行までの間に時間的余裕がない場合には、新法令の施行日以降となる場合がある。

含むと書いてありますが、条件が3つ付いています。対象法令が列挙されていること、対応の可否をベンダー側が判断すること、施行日に間に合わない場合があることの3つです。しかも同条は、顧客の要求による改良・仕様変更・機能追加は含まないとしています。

残る3件は、法令改正への対応にまったく触れていません。このうちゾーホージャパンの規約は「明示的に挙げられていない作業」を対象外とする型なので、書かれていない＝保守料の範囲では実施されないという帰結になります。

これはパッケージ製品の約款であって、受託開発したシステムの個別保守契約ではありません。それでも示唆はあります。製品ベンダーですら条件付きでしか約束していない作業を、スクラッチ開発の保守契約が無条件に含んでいると期待するのは無理がある、ということです。

制度変更は実際に起きている

発生頻度を予測することはできませんが、直近で実際に起きた制度変更は確認できます。

国税庁の電子帳簿保存法の特設サイトには、「自社開発システムの要件定義に悩んでいる」場合の相談窓口が設けられています。

自社のシステムがこれらの制度で改修を要するかどうか、また要件を満たしているかどうかの判断は、税理士または所轄の税務署にご確認ください。ここで扱っているのは、その改修が必要になったときに誰が費用を負担するのかという契約の問題だけです。

契約に書いてもらう条件文の例

法改正対応を「不明」から動かすには、条項を1つ足してもらうのが早道です。ポイントは、対象法令・通知期限・費用負担の3点を欠かさないことです。

（法令等の改正への対応）
第◯条 乙は、本件システムを継続して使用できる状態に保つために必要な範囲で、
    別表◯に掲げる法令等の改正に対応するプログラムの修正を、本件業務として実施する。

2 乙は、別表◯に掲げる法令等の改正が公布されたことを知った日から◯営業日以内に、
    甲に対し、本件システムへの影響の有無、想定される作業範囲、実施可能な時期を
    書面により通知する。

3 前項の通知の結果、必要となる対応が本件業務の範囲を超えると乙が判断する場合、
    乙は、その理由と概算費用を同時に提示する。甲及び乙は、当該対応を本件業務として
    実施するか、個別契約により別途実施するかを協議のうえ決定する。

4 別表◯に掲げる法令等以外の改正への対応は、本件業務に含まれない。
    甲が対応を希望する場合、甲及び乙は個別契約を締結する。

5 法令等の公布から施行までの期間が短く、施行日までに対応を完了できないと
    見込まれる場合、乙は速やかにその旨と対応予定日を甲に通知する。

別表◯（対象法令等）
消費税法／法人税法／所得税法／電子帳簿保存法／
健康保険法・厚生年金保険法（社会保険料率の改定を含む）／労働基準法／
（業種固有の法令があれば追記）

この5項のうち、もっとも効くのは第2項の通知義務です。費用の負担者が決まっていなくても、「改正があったら◯営業日以内に影響の有無を知らせる」という約束さえあれば、施行日直前に慌てる事態はかなり減ります。逆に、通知義務がないまま費用負担だけを「協議」と書いても、協議が始まるタイミングが遅すぎて意味を持ちません。

第4項をあえて置いているのは、対象を絞る代わりに、絞った範囲は確実に実施してもらうためです。すべての法令改正を無条件に含めろと要求すると、ベンダーはリスクを織り込んで保守料を上げるか、条項自体を断ります。別表方式なら、自社の業務に効く法令だけを名指しできます。

「頻度は年◯回」といった前提は置かない

法改正対応の費用を見積もるとき、「年に1〜2回は発生する前提で」といった数字が出てくることがあります。この記事ではその種の頻度を示しません。 業種・システムの種類・改正の規模によって桁が変わり、汎用的に使える公開データを確認できなかったためです。

代わりに使えるのは実績です。現行ベンダーに対して、直近3年間で法令・制度の変更を理由に実施した作業の件数と、それぞれ保守費内で処理したか別途請求したかを聞いてください。 予測より、その会社での実際の運用のほうが精度が高い情報になります。

→ 確認質問5で聞きます。

境界4｜OS・ミドルウェアの更新はどこまでか

前掲の比較表で、いちばん結論が割れたのがこの項目です。同じ「保守サービス」という言葉で、4件が別々の扱いをしていました。

契約書に「OS更新対応」と一言だけ書いてあっても、このどれなのかは決まりません。分けて確認すべきなのは次の3段階です。

1. 更新の適用そのもの（パッチを当てる作業）
2. 更新後の動作確認（アプリケーションが従来どおり動くかのテスト）
3. 更新で動かなくなった箇所の改修（コードの修正）

1だけが含まれていて2と3が別料金、という契約があります。1だけを買っていると、更新後に動かなくなったときに何も進みません。

サポート終了（EOL）は、契約が止まる条件になりうる

見落とされやすいのが、前掲の型4です。OSやミドルウェアが製造元のサポート対象であることを、保守サービス提供の前提条件にしている書き方があります。

ロゴスウェアの約款は、保守対象製品がインストールされたコンピュータのOSおよび前提ソフトウェアならびにハードウェアが製造元の通常サポート対象となっていることを、保守サービス提供の前提条件としています。エスアイ・システムの約款も、クライアント動作対応OSを特定したうえで「マイクロソフト社のサポートが終了したOSは、動作対応OSとはしない」と書いています。

つまりOSがEOLを迎えた時点で、保守料を払い続けていても保守が受けられない状態になりうるということです。これは値上げやロックインとは別の問題で、契約書を読めば事前に分かります。手元の契約書に「前提条件」「動作環境」という見出しがあれば、そこを先に読んでください。

なお、スマートフォンアプリのOSバージョン対応（iOS・Androidの年次アップデートへの追随）は、開発側の作業量やストアの要件が絡むため論点が別に立ちます。本記事では契約書の範囲条項としての扱いにとどめます。

→ 確認質問6で聞きます。

境界5｜バックアップは取得・テスト・復元のどれを買っているのか

3つとも「バックアップ」という言葉でまとめられがちですが、契約上は別の作業です。

ゾーホージャパンの規約は「本製品のデータ復元」を対象外作業として列挙しています。ロゴスウェアの約款は、顧客のデータや動作環境を復旧させることまでは保証せず、それらは顧客が責任をもって管理するものとしています。エスアイ・システムの約款も、データは顧客自身により管理・バックアップされるものとしています。そもそもバックアップを取っているのは誰かという前提から確認が必要です。

金額そのものの妥当性は、システム保守費用の相場と妥当性の5つのコストドライバーが判断材料になります。

→ 確認質問7で聞きます。

ベンダーの「対象外です」が正当と言えるケース

ここまで確認の話を続けてきましたが、ベンダーが対象外と答えること自体は、まったく正常な運用です。次の条件を満たしているなら、その回答は誠実な運用の結果だと考えてよいと思います。

4つとも満たしているなら、価格の交渉に入るより、その範囲を前提に社内の運用と予算を組み直すほうが早いです。範囲を広げれば保守料は上がります。それが妥当かどうかは、その作業が年に何回発生しているかで決まります。

書面での確認が必要になる8つの契約状況

この8つが指しているのは、ベンダーの姿勢ではなく発注側が範囲を確認できていない状況です。中小規模の保守契約では、そもそも別紙が作られていないことがあります。重要なのは責任追及ではありません。当てはまったものを、次章の確認質問9問でまとめて書面に落とします。

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

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

契約更新や予算編成を理由にすると、角が立ちません。範囲を疑っているのではなく、社内で説明するために書面が要る、という立て付けにしてあります。

◯◯株式会社
◯◯様

いつもシステムの保守運用でお世話になっております。
次回の契約更新にあたり、社内でシステム保守の対応範囲を
整理する必要が生じました。
恐れ入りますが、下記9点についてご回答をお願いできますでしょうか。

1. 現在の契約に添付されている業務仕様書・受託条件明細（貴社での
   呼称が異なる場合は、サービス範囲を定めた書面）の最新版を、
   ご送付いただけますでしょうか。
   保守の対象範囲がどの書面のどこに書かれているかも併せてお教えください。

2. 保守の対象外となる作業の一覧をお示しいただけますでしょうか。
   一覧に挙がっていない作業の扱い（対象なのか、対象外なのか）も
   併せてお教えください。

3. 「軽微な改修」の定義、軽微に当たるかどうかを判断する方法、
   月間の上限時間、上限を超えた場合の単価、未使用分の繰越の可否を
   お教えください。

4. 納品時から存在していた不具合の修正と、稼働後に発生した不具合の修正で、
   費用の扱いが変わるかどうかをお教えください。変わる場合は、
   （a）その境界（開発契約の契約不適合責任の期間と起算点）
   （b）原因が納品物側か稼働後の変化側かの切り分けを、どちらの費用で実施するか
   の2点も併せてお教えください。

5. 法令・制度の改正への対応について、
   （a）保守に含まれるか、含まれる場合の対象法令の範囲
   （b）改正を把握した際に弊社へ通知いただけるか、その期限
   （c）含まれない場合の費用の算定方法
   をお教えください。あわせて、直近3年間で法令・制度の変更を理由に
   実施いただいた作業の件数と、保守費内で処理したか別途請求だったかの
   内訳もお教えください。

6. OS・ミドルウェアの更新について、
   （a）更新の適用作業
   （b）更新後の動作確認
   （c）更新により動作しなくなった箇所の改修
   の3つが、それぞれ保守に含まれるか、別料金か、対象外かをお教えください。
   また、OSやミドルウェアが製造元のサポート対象であることが
   保守提供の前提条件になっているかも併せてお教えください。

7. バックアップについて、取得・復旧テスト（リストア試験）・
   誤削除データの復元の3つが、それぞれ保守に含まれるか、別料金か、
   対象外かをお教えください。復旧テストを実施している場合は、
   頻度と直近の実施結果も併せてお教えください。

8. 保守の対象となる環境（本番・検証・開発）と、対象となる
   コンポーネントの範囲をお教えください。他社が開発した機能や、
   弊社側で追加したプラグイン・スクリプトの扱いも併せてお教えください。

9. 本件保守業務の契約形態（請負・準委任）と、業務の一部を
   再委託される場合の再委託先の有無をお教えください。
   再委託がある場合、実際に作業される会社名と責任の所在も
   併せてお教えください。

お手数をおかけしますが、◯月◯日までにご回答いただけますと幸いです。
よろしくお願いいたします。

回答をどう読むか

右の列が多いこと自体は、ベンダーの怠慢を意味しません。 範囲を細かく書いた保守契約が用意されていないことは、実務で普通に起こります。重要なのは、次の更新までに書面へ落とすことに合意できるかです。合意できるなら、多くの場合は現行ベンダーの継続が合理的な選択になります。

回答が揃ったあとの進め方

4状態への仕分けが終わったら、「不明」を減らす方法は3つしかありません。

3つのどれを選んでも構いません。決まってさえいれば目的は達しています。

そして、仕分けの結果として「現行の範囲で問題ない」という結論に落ち着くことも普通にあります。この記事のゴールは範囲を広げさせることではなく、何が含まれていて何が含まれていないかを、社内で説明できる状態にすることです。

前掲の保守見積書の無料診断（登録不要）は、契約更新前の整理にもそのまま使えます。

根拠資料と適用条件

本記事で使用した資料と、その適用範囲です。約款は事業者ごとに前提が違うため、まとめて扱わないでください。

判定マトリクスの文言例は、上記の公開約款4件とIPAモデル契約の業務仕様書サンプルの記載を参考に一般化したものであり、特定の資料からの直接の引用ではありません（同表内の鉤括弧は、一般化した文例であることを示すためのものです）。原典からの引用箇所は、本文中で引用符または引用ブロックを付けて示しています。

法改正対応の発生頻度について、業種横断で使える公開データを確認できなかったため、本記事では頻度の目安を示していません。現行ベンダーの過去実績を確認する方法を代わりに提示しています。

なお本記事は、法的・税務的な最終判断を提供するものではありません。契約解釈、法令の適用、税務上の取り扱いについては、それぞれの専門家にご確認ください。

よくある質問