システム保守会社は変更できる？必要な資料・権限・引き継ぎ条件

システムの保守会社を変更したい、と考えたときに最初に調べるべきなのは、他社の料金でも、いまのベンダーとの関係でもありません。手元の契約書の解約条項と、自社が受け取れる資料・権限です。この2つが揃っていないと、他社に声をかけても比較可能な見積もりは返ってきませんし、そもそも希望した時期に契約を終われません。

本記事は、保守会社の変更を「できる／できない」ではなく、いつまでに何を確認すれば選択肢が残るかという手順として扱います。根拠には、デジタル庁の標準ガイドライン、IPAと経済産業省のモデル取引・契約書、民法の条文、そしてWeb上で誰でも読める保守約款4件を使います。金額の相場は扱いません（理由は本文と「根拠資料と適用条件」に書きます）。

TL;DR｜変更できるかは、交渉力ではなく契約条項と引き継ぎ資産で決まる

• 「第三者保守」を探しているなら、たぶん違うものを探しています。 本記事で確認した第三者保守事業者の公開ページでは、対象はメーカーサポートを終えたハードウェアとされ、ソフトウェアに関する保守は対応不可に挙げられていました。稼働中の業務システムの委託先を変えたいなら、探す言葉は保守移管です
• 最初に読むのは、他社の資料ではなく自社の契約書です。 民法上、委任契約は各当事者がいつでも解除できるのが原則ですが（民法第651条第1項）、実務ではその前に契約書の予告期間・自動更新・中途解約の定めが効きます。公開されている保守約款4件では、解約の予告期間は「1ヶ月前」「1カ月以上前」「明記なし」「いつでも可」の4通りに割れ、更新は何もしなければ延長される型（予告期間型・手続型。ただし1件は対象物ごとに扱いが違う）と更新の意思表示をしなければ終わる型（更新意思型）に分かれました
• 動けるかどうかは、契約満了日から数えた6つの日付で決まります。 満了日→通知期限→社内決裁→新候補先（新たに見積もりを依頼する会社）の選定→資料の受領→現ベンダー（現在の保守会社）への照会、の順に逆算すると、いま着手すべきかどうかが1回の計算で出ます。「◯ヶ月前から」という一般的な目安は使えません。この記事の判断は最終的にこの日付に戻ってきます
• 引き継ぎ対象として政府の標準ガイドラインが名指ししているのは、設計書・作業経緯・残存課題です（設計・開発から運用・保守へ引き継ぐ場面の記述。事業者の交代の場面では後ろの2つが挙がっています）。民間の引き継ぎで用意されるのはたいてい設計書だけですが、次の会社の見積額を左右するのは後ろの2つです
• 「解約金」という名目の条項が無くても、解約には費用がかかります。 かかり方は2種類です。ひとつは中途解約の精算（残期間分の支払いや、前払い分が返ってこないこと）。もうひとつはデータ出力・データ消去・引き継ぎ支援という作業の費用です。後者3つの条件が契約に書かれていなければ、金額も範囲も、解約を申し出た後に決めることになります。それは発注側にとって最も条件の悪いタイミングです
• 「データを出せます」と「他社が使える形で出せます」は別のことです。 形式・範囲・構造・期限・費用の5つが契約に書かれていないと、出てきたファイルがそのままでは使えないことがあります。とくに構造（テーブル間の対応関係）が保たれていないと、移行費用はたいていそこで跳ね上がります
• 現ベンダーを継続するという結論も、同じくらい正しい答えです。 本記事のゴールは乗り換えの推奨ではなく、続けるか変えるかを毎年選び直せる状態を作ることです

なお、保守費用が下がりにくくなる構造そのもの（なぜロックインが起きるのか、公的データで何が示されているか）はベンダーロックインで保守費用が下がらない理由で扱っています。本記事はその先の変える側の手順を担当します。

まず用語を確認する｜「第三者保守」は保守会社の変更とは別のもの

保守会社の変更を調べていると「第三者保守」という言葉に行き当たります。ここは用語がずれやすいので、分けておきます。

第三者保守サービスを提供する株式会社ゲットイットは、自社サービスの説明で第三者保守を「サーバーやストレージ・ネットワーク機器など、ハードウェアの安定稼働をIT機器メーカーに依存せず独立企業がサポートする保守サービス」と定義しています（2026年8月21日取得）。同ページのQ&Aでは「メーカーサポート終えたIT機器（サーバー、ストレージ、ネットワーク機器など）に対して第三者企業が提供する独自の保守サービス」とも説明されています。対象はサーバー、ネットワーク機器、ストレージ、ワークステーション等のITハードウェアで、対応不可の内容として「ソフトウェアに関する保守」が挙げられています。 同ページの「メーカー保守と第三者保守の主な相違点」の表では、「OS/ソフトウェア由来の障害のサポート」の第三者保守欄にバツ印が付き、備考に「メーカーさまのOS/ソフトウェア関連のサポートを第三者保守で引き継ぐのは原則不可です」と書かれています。同じ表では「障害一次切り分け」の第三者保守欄が「お客さま」となっています（メーカー保守欄は「原則お客さま」）。同ページのQ&Aは、移行後に受けられなくなる主なサービスとして障害切り分けを挙げています。

同社はまた、メーカー保守から第三者保守へ移行した場合に受けられなくなる「主なサービス」として、サブスクリプションライセンスの延長契約（同社は「メーカーにより対応可能なケースもあり」と付記）、ファイアウォール機能やUTM機能（統合脅威管理）、自動発報機能、最新ソフトウェアの提供（原文の表記は「FWやセキュリティパッチ」）、障害切り分けの5つを挙げています。これは1社の公開サービス条件であり、業界共通の条件ではありません。それでも、言葉の指す範囲を確認するには十分です。

つまり、次の整理になります。

自社が探しているのが「いまのシステムを、いまのまま、別の会社に見てもらうこと」なら、それは第三者保守ではなく保守移管です。 検索の言葉を変えるだけで、当たる会社が変わります。逆に、ハードウェアのサポート終了が目前で困っているなら、ソフトウェアの保守会社を変えても解決しません。

本記事の登場人物

言葉をもう1組そろえておきます。以降、現在の保守会社を現ベンダー、新たに見積もりを依頼する会社を新候補先、自社の情報システム担当や管理部門を自社と表記します。まだ絞り込む前の候補一般を指すときだけ「他社」と書きます。先方へ送るメール文面の中は、読み手に伝わる表現へ置き換えています。

「変更できますか」の答えは、契約書の解約条項に先に書いてある

保守会社の変更を検討し始めると、多くの場合、最初に社内で出る質問は「そもそも途中でやめられるのか」です。ここは法律と契約書の関係を先に整理しておくと、以降の判断が速くなります。

法律上の原則と、実務で先に効くもの

システムの保守契約は、成果物の完成ではなく作業の遂行を約束する準委任契約の形をとることがあります。後掲の公開約款のうち、株式会社デジタルキューブの保守契約約款は「準委任契約にて委託し」と明記し、ゾーホージャパン株式会社の規約も「成果物の有無を問わず、全て準委任形態で行われる」と定めています。準委任には民法の委任の規定が準用されるため、途中でやめられるかどうかの原則は次の条文が出発点になります。

（委任の解除）第六百五十一条　委任は、各当事者がいつでもその解除をすることができる。 ２　前項の規定により委任の解除をした者は、次に掲げる場合には、相手方の損害を賠償しなければならない。ただし、やむを得ない事由があったときは、この限りでない。 一　相手方に不利な時期に委任を解除したとき。 二　委任者が受任者の利益（専ら報酬を得ることによるものを除く。）をも目的とする委任を解除したとき。

（民法／2026年8月21日時点の施行版。以下の条文引用も同じ）

あわせて関係するのが、途中で終わったときの報酬の扱いです。

（受任者の報酬）第六百四十八条　…　３　受任者は、次に掲げる場合には、既にした履行の割合に応じて報酬を請求することができる。 一　委任者の責めに帰することができない事由によって委任事務の履行をすることができなくなったとき。 二　委任が履行の中途で終了したとき。

そして、解除の効果は過去にさかのぼりません（民法第652条が準用する第620条は、解除は「将来に向かってのみその効力を生ずる」と定めています）。つまり、解約しても、それまでに提供された保守の対価がまとめて戻ってくるという仕組みにはなっていません。

ただし、経営判断として重要なのはここから先です。これらの条文は当事者間の取り決めがない場合の原則を示すもので、実際の契約書には予告期間・自動更新・中途解約の可否・返金の扱いが個別に書かれているのが通常です。何がいつまでにできるかは、条文ではなく手元の契約書で決まります。個別の契約の解釈や、条項が有効かどうかの判断は弁護士の領域です。本記事は、契約書のどこを読み、何を確認するかまでを扱います。

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

解約の条件は、自社の契約書を1本だけ読んでも「普通なのかどうか」が判定できません。比べる相手が要ります。ここでは、解約条項まで読める公開の約款・規約を4件選び、2026年8月21日時点の内容で並べます。見るのは金額ではありません。

4件はいずれも、定型の製品やサービスに紐づく約款です。 個別に締結するスクラッチ開発の保守契約とは成り立ちが違うため、条項の文言をそのまま自社に当てはめることも、金額の相場として読むこともできません。見るべきは、同じ「解約」という言葉が、どれだけ違う条件で運用されているかの一点です。

ラディックスの自動更新の行は、契約の一部にしか及びません。 同規約は有効期間を「各個別条項にて定める」構造をとっており、30日ルールはハードウェアとカウンター契約の個別条項にあって、ソフトウェアの個別条項には自動延長の定めがありません。同じ会社の同じ規約でも、対象物によって出口の条件が違うという例として読んでください。自社の契約書に別紙や個別条項が付いているなら、本紙だけを読んでも期限は分かりません。

エスアイの残期間支払いについては、約款の第9条に次のように書かれています。

第８条の契約期間にかかわらず、甲は、本契約の残期間分の保守料金を支払い、乙が指定する書面を提出することで、当該書面が当社に到達した日が属する月の翌月末日をもって、本契約を解約することができる。

デジタルキューブの契約終了時の扱いは、第11条に次のとおり書かれています。ここで抹消されるのは顧客の業務データではなく、事業者側が持っている保守サービスの履歴である点に注意してください。

本契約の契約期間が満了した後、乙は、Web アプリケーションサーバで管理していた甲についてのすべての保守サービス履歴を抹消します。甲は、保守サービス履歴の抹消につき異議を述べることができないものとします。

この4件から読み取れる、出口の型3つ

予告期間型（ラディックス・エスアイ） — 一定期間前に文書（事業者が指定する様式を含む）で通知すれば解約できる、という書き方です。分かりやすい代わりに、更新拒絶の期限を持つ契約では、通知の期限を1日でも過ぎると次の期間が始まります。 期限管理を誰がやるかを社内で決めていないと機能しません。

ただし、期限を逃したら出口が消えるとは限りません。前掲の4件はいずれも、更新のサイクルとは別に中途解約の途を残しています（ラディックスは1ヶ月前の文書通知、エスアイは残期間分の支払い、デジタルキューブは所定の申込書、ゾーホーは「いつでも」）。期限を過ぎて消えるのは出口そのものではなく、払った分を捨てずに抜けられる選択肢のほうです。自社の契約書に中途解約の条項があるかどうかを、更新の期限とセットで確認してください。

手続型（デジタルキューブ） — 期中の解約は、予告期間ではなく「所定の申込書の提出」で成立します。ただし同じ規約は、更新拒絶については満了の一ヶ月前までの書面を求めています（第11条）。 期中に抜けるか、更新のタイミングで抜けるかで、必要な手続きも期限も変わります。書式が事業者側にあるため、様式の取得と受理の確認までが解約手続きに含まれます。 「メールで伝えた」では終わらない可能性があります。

更新意思型（ゾーホー） — 何もしなければ期間満了で終わる書き方です。解約する側にとっては最も動きやすい一方、更新を忘れると保守が切れるという逆向きのリスクがあります。

自社の契約書がどの型かは、次の3語を検索すれば判定できます。「更新」「解約」「予告」。この3語が1つも出てこない契約書は、型が決まっていない状態です。その場合は、次回更新のタイミングで書き足す対象になります。

「一度やめると戻れない」条項がある

見落としやすい類型を1つ挙げます。ゾーホーの規約の第9条第3項には、次の定めがあります。

３　期間満了その他の事由を問わず本契約が終了した場合、契約者は、再度本契約を申込むことはできません。

さらに同規約は、申込みを認めないことができる場合の1つとして「過去に本契約を締結していて、その事由を問わず当該契約が終了した場合」を挙げています。これは違反に対する制裁ではなく、終了の理由を問わない定めです。 「試しに1年止めてみて、駄目なら戻る」という進め方が、契約上そもそも選べないことがあるわけです。

これは1事業者の規約であって、業界の標準ではありません。ただし、戻れるかどうかを確認しないまま解約を決めないという点は、どの契約でも同じです。自社の契約書に再契約の可否が書かれていないなら、それは「不可」ではなく「未確定」です。書面で確認してください。

保守の「範囲」がどこまでかという別の論点（法改正対応やOS更新が含まれるか）については、システム保守契約の範囲｜法改正・OS更新・軽微な改修は含まれるのかで契約書の範囲条項を扱っています。本記事は範囲ではなく出口の条項に絞ります。なお同記事も公開約款4件を比較していますが、ロゴスウェア株式会社を含む4件で、重なっているのは3件です。見ている条項も大部分は違います。

いつから動き出すか｜契約満了日から逆算する

保守会社の変更でもっとも多い失敗は、気づいたときには次の1年が始まっていたというものです。前掲の約款4件のうち3件では、更新拒絶や解約の申出の期限が「満了の30日以上前」「1カ月前」などと定められていました（残る1件は、更新の注文書を出さない限り期間満了で終了する型です）。日程は契約書ごとに違うので、次の順で自社の日付を埋めてください。

以下を本記事では逆算表と呼びます。

⑥から①までにどれだけの期間が必要かは、⑤の資料がどれだけ揃っているかで決まります。 資料が手元にあるなら短くできますし、整備から始めるなら整備の見積もり取得と作業期間が加わります。本記事では「◯ヶ月前から動くべき」という一般的な目安は示しません。 契約書の予告期間と、資料の整備状況で決まるためです。

もう1つ、日程で見落とされやすいのが並行稼働の期間です。現ベンダーの契約を終了した翌日から新しい会社が単独で対応できる、という前提を置くと、最初の障害で困ります。両社が同時に契約状態にある期間を置くなら、その分の費用と、どちらが一次対応をするかの取り決めを先に決めてください。決めていないと、障害時に両社が様子見をします。

変更の可否を決めるのは、交渉力ではなく引き継ぎ資産

契約上の出口が確認できたら、次は「他社が引き受けられる状態か」です。ここで役立つのが、政府情報システムの標準ガイドラインの記述です。

デジタル庁のデジタル・ガバメント推進標準ガイドライン（DS-100）は、設計・開発の章に「引継ぎ」という項目を置き、次のように定めています。

ＰＪＭＯは、情報システムの整備後の事業者変更のリスクを最小限に抑えつつ、円滑かつ効率的に当該情報システムを運用するため、設計・開発事業者に対し、運用事業者及び保守事業者に設計・開発の設計書、作業経緯、残存課題等を確実に引き継ぐよう求めるものとする。

同ガイドラインは、運用・保守の章にも「運用及び保守の引継ぎ」を置き、システムを作り替えない場合の事業者交代についても定めています。

ＰＪＭＯは、情報システムの更改を伴わずに、運用事業者、保守事業者等に交代が生じるときは、交代前の事業者から交代後の事業者に対し、作業経緯、残存課題等について確実に引継ぎがなされるよう求めるものとする。

このガイドラインは政府情報システムを対象にした政府内の共通ルールで、民間企業に適用義務はありません。それでも、経営判断の材料として次の3点が読み取れます。

なお本記事で「引き継ぎ資産」と呼ぶのは、ベンダーロックインで保守費用が下がらない理由が定義した6点（仕様書・設計書／構成図・運用手順書／管理者権限／ソースコード／データ／権利）に、本章で扱う作業経緯と残存課題の2つを加えたものです。後ろの2つは契約書に書かれることがほとんどなく、依頼して初めて出てきます。

1. 名指しされているのは「設計・開発の設計書、作業経緯、残存課題等」です。 ここは引用元を分けて読む必要があります。3つが並んでいるのは設計・開発事業者から運用事業者・保守事業者へ引き継ぐ場面の記述で、保守事業者が交代する場面の記述に並んでいるのは「作業経緯、残存課題等」の2つです。どちらの条文も末尾に「等」が付いており、これらに限る趣旨ではありません。

それでも、実務上の含意ははっきりしています。民間の引き継ぎで用意されるのはたいてい設計書だけです。「作業経緯」（これまで何をやってきたか）と「残存課題」（分かっているが直していないこと）は、依頼しない限り出てきません。 そして次の会社の見積もり金額を左右するのは、実はこの2つです。残存課題を知らずに引き受けた会社は、安全側に見積もるか、引き受けたあとに追加費用を出すかのどちらかになります。

2. 引き継ぎは、変更を決めてから考えるものとして書かれていません。 1つめの引用は設計・開発の章、つまりシステムを作っている最中の章にあります。「事業者変更のリスクを最小限に抑えつつ」という目的が、開発段階の要求として書かれています。同ガイドラインは要件定義の章でも、記載すべき事項の1つとして「引継ぎに関する事項」を挙げ、「情報システムの開発、運用等について、他の関係事業者への引継ぎに関する要件を記載する」としています。引き継ぎ条件は、稼働後に交渉するものではなく、発注時に要件として書くものだという整理です。

3. 求める相手は、交代する側の事業者です。 交代前の事業者から交代後の事業者へ引き継がせることを、発注者が求める、という構造になっています。新旧2社に任せて成り行きに委ねるのではなく、発注者が引き継ぎの範囲と完了条件を決めるという前提です。

IPAと経済産業省の情報システム・モデル取引・契約書＜第二版＞も、保守の工程について同じ方向の記述を置いています。

システムの所有者であるユーザには、必要に応じてベンダの協力を得ながら、将来的なシステムの再構築を見据え、保守内容の設計文書等への確実な反映や、業務・設計のノウハウ等の円滑な引継ぎなど、適切な管理が求められる。

ここでも主語は発注側（ユーザ）で、ベンダは「協力を得る」相手として書かれています。資料が最新化されていない状態は、ベンダー側の不作為であると同時に、発注側が管理していない状態でもあるという整理です。責任の押し付け合いをしても引き継ぎは進みません。動かせるところから動かすのが早道です。

変更前に集める資料チェックリスト｜「持っているか」ではなく「受け取れる形か」

引き継ぎ資産6点そのものの4状態判定は、前掲のロックイン記事の判定表で行います。後述の「出口条項を4状態で仕分ける」で扱うのは、その表に無い出口の条項です。ここではその手前、実際に受け取る作業のリストを置きます。判定表と違うのは、各項目に「どの形式で」「いつまでに」「何をもって受領完了とするか」を付けている点です。引き継ぎは、受け取ったつもりで終わるのが多い失敗です。

この表は依頼の順番に並べていません。 実務では、次の順で着手すると止まりにくくなります。

1. 自社だけで完結するもの（1・2・19） — 契約書と請求書は社内にあります。ここを読むだけで、解約の期限と、いま何にいくら払っているかが分かります
2. 依頼するだけで動くことが多いもの（13・14・15・20） — 権限と名義は、資料の作成に比べれば相手の負担が小さい領域です。渡っていないのは、要求されてこなかっただけであることが少なくありません
3. 作成の工数が発生するもの（3〜12・16〜18） — ここは無償では出てこない可能性があります。整備そのものを見積もり依頼の対象にするのが現実的です

3の費用を惜しんで手ぶらで他社に声をかけると、返ってくるのは調査費込みの高い見積もりか、辞退です。 どちらも「他社は高かった」という誤った結論になります。

解約費用は解約時ではなく、契約時に決まっている

ここからが、契約前に押さえておくべき条項の話です。保守契約の解約でもめる論点は、実はほとんど決まっています。解約を申し出た時点で条項に書かれていない項目は、そこから交渉することになります。 そして、解約を申し出た後の交渉は、発注側にとって最も条件の悪いタイミングです。

IPAと経済産業省の情報システム・モデル取引・契約書＜第二版 追補版＞には、SaaS/ASPを選ぶ際のチェックリストが収録されており、ライセンスの区分に次の確認項目が置かれています。

途中解約 解約した場合の料金の扱いはどうなるか データの対応はどうなるか

同じチェックリストは、サービスが廃止された場合についても「計画的廃止の場合、告知は何ヶ月前か、何年間使用可能か。データは保全されるか、データの対応はどうなるか」を確認項目としています。これらはすべて、契約する前に聞くこととして並んでいます。

この追補版は対象読者を、従業員数や資本金ではなく「ベンダと対等の交渉力を有しない」「ITや情報システム取引、法務の専門家、専従者を設置することが困難な」組織と定義しています。法務やITの専任者がいない会社ほど、契約時に条項を埋める必要が大きいという前提で作られた資料だということです。

出口を決める7条項｜契約前に埋める、契約済みなら覚書で足す

保守契約を新規に結ぶとき、または次回更新のときに、次の7条項が空欄になっていないかを確認してください。

3〜6が、本記事で言う「解約費用」の実体です。 3は中途解約したときの精算、4〜6は解約に伴って発生する作業の費用で、性質が違います。どちらも解約金や違約金という名前が付いていないぶん、契約時にも解約時にも見落とされやすい領域です。

すでに契約済みでも、埋められる

「もう契約してしまった」場合でも、打つ手はあります。相手方の合意が得られれば、契約書そのものを作り直さなくても、覚書（合意書）で個別の条項を追加できます。 そして、条項の追加がもっとも通りやすいのは、次回更新の直前です。更新の可否を検討している時期は、発注側の意思決定が唯一動く時期でもあります。

進め方としては、上の7条項のうち4・5・6の3つに絞って書面化を依頼するのが現実的です。7条項すべてを一度に求めると契約交渉になりますが、データの出口と引き継ぎ支援の条件だけなら、事業者側にとっても作業内容の明確化という利点があります。

なお、更新のたびに料金が改定される仕組み（値上げ条項やCPI連動の有無）は、本記事では扱いません。更新条件を読むときに、同じ条項の近くで料金改定の定めがあるかどうかだけ確認しておいてください。 本記事は更新の期限を「変更を実行できる最後の日」として扱うにとどめ、金額そのものの妥当性は別の論点として切り分けます。

解約時のデータ出力｜「出せます」と「他社が使える形で出せます」は違う

契約前に埋めるべき7条項のうち、実務でもっとも揉めるのがデータです。ここだけ切り出して詳しく見ます。

公的なモデルケースが「望ましい」としている水準

IPAと経済産業省のモデル取引・契約書＜第二版 追補版＞には、SaaS向けのサービスレベル項目のモデルケースが収録されています（同節が示している参照先は、国立国会図書館のアーカイブURL 1本だけです。URLに www.meti.go.jp/press/20080121004/ を含みます）。その「データ管理」の区分に、次の1項目があります。

サービスレベル項目例：データ消去の要件 規定内容：サービス解約後の、データ消去の実施有無／タイミング、保管媒体の破棄の実施有無／タイミング、およびデータ移行など、利用者に所有権のあるデータの消去方法 測定単位：有無 設定例：サービス解約後1ヶ月以内にデータおよび保管媒体を破棄。 備考：解約時には、CSVなどの一般的なフォーマットでデータ出力ができることが望ましい。

読み取るべき点は3つです。

1つめ。 備考欄の表現は「望ましい」であって義務ではありません。一般的なフォーマットでの出力は、標準で付いてくる機能ではなく、契約で決めておく項目として書かれています。

2つめ。 「消去」と「出力」が同じ項目に入っています。解約時にやることは、自社が受け取ることと、相手側から消えることの両方です。片方だけを確認して終わると、データが出せないか、あるいは出せたが相手側にも残り続けるかのどちらかになります。

3つめ。 これはSaaS/ASPを対象にしたモデルケースであり、受託開発したシステムの保守契約を対象にしたものではありません。ただし、確認すべき項目の並びは、自社サーバーで動くシステムでもそのまま使えます。 同じ資料は、設定値について「実際の設定値は、以下の設定例を参考として、業務内容など個々の状況に応じて決定されるべきものである点に留意されたい」とも書いており、「1ヶ月以内」という数字を一般的な基準として扱わないよう注意しています。

契約に書かれていない状態は、珍しくない

セキュリティ評価サービスを提供するAssuredが、契約終了後のデータの取り扱いについて公表した調査があります（Assured調べ）。同社が自社のセキュリティ調査に回答済みのクラウドサービス事業者を対象に、2024年5月9日時点で集計したものです。

• 約15％のサービスで、契約や規約等によりサービス利用終了後のデータの取り扱いが明確になっていなかった
• 約14％のサービスで、サービス利用終了時または利用者からの指示があった場合でもデータを削除していなかった

同レポートの調査概要は、調査件数を「調査項目により異なる（1：2,192サービス、2：2,141サービス）」としています（上の2項目に順に対応します）。

同レポートは、削除しない理由として事業者側から挙がったものに「問い合わせ対応に備えるため」「サービス停止後にデータ保管を依頼されることがあるため」「利用者が削除を行う必要があるため」などを挙げています。また、削除する場合でも「サービス利用者からの依頼があった場合にのみ削除を実施するケース」があり、削除できると回答したサービスでも、利用者から削除依頼をしないと削除されない点に留意するよう述べています。

この調査の対象はクラウドサービスであって、受託開発システムの保守契約ではありません。数字をそのまま自社の契約に当てはめることはできません。それでも、「終了後のデータの扱いが契約に書かれていない」という状態が例外ではないことは示されています。書かれていない前提で確認するほうが安全側です。

出力条件を確認する5つの軸

「データは出せますか」という質問には、ほぼ確実に「出せます」と返ってきます。判断に使えないので、次の5軸で聞いてください。

構造の軸がとくに重要です。 表計算ソフトで開ける形式で出てきても、テーブル間の対応関係が失われていると、次のシステムへ取り込むときに人手での突き合わせが発生します。移行費用が跳ね上がるのはたいていここです。

引き継ぎ費用は、見積書ではこう書かれる

保守会社を変更すると、見積書は2通り発生します。現ベンダーが出す「引き継ぎ支援」の見積もりと、新候補先が出す「引き継ぎ受け入れ」の見積もりです。この2つを別々に見ないと、どちらの費用なのか分からなくなります。

実際の見積書では、次のような書かれ方をします。

見積書を受け取ったら、まず「一式」と書かれた行に、単位を書き足してもらうところから始めてください。引き継ぎ支援であれば「時間」、資料整備であれば「作成対象の資料名と分量」、データ抽出であれば「対象テーブル数とやり直しの回数」です（回数は契約条項ではなく、見積書側で詰める項目です）。単位が決まっていない行は、あとから増減する行です。

実際に費用を生む作業は何か

課金される名目と、実際に人が動いている作業はしばしばずれます。前章の見積行を、おおむね同じ順で実作業へ置き換えると次のようになります（末尾2行は、前章の見積書には名目が現れないものです）。

なお、前章で「環境移管作業（双方）」として双方の見積書に現れる行は、実作業では権限・名義の移管手続き（ほぼ費用が発生しない）と、新候補先側の環境の再現に分かれます。名目と実作業のズレがいちばん大きいのがこの行で、二重計上が起きやすいのも同じ理由です。 両社の見積書にこの行があるなら、どちらが何をするのかを1行ずつ突き合わせてください。

この表のうち、契約や資料の状態で振れ幅が大きいのが「現行システムの調査・解析」と「並行稼働期間の重複費用」です。 そして、この2つはどちらも資料が揃っているかどうかで決まります。資料が揃っていれば調査は短くなり、調査が短くなれば並行期間も短くできます。逆に言えば、資料整備の費用は、新候補先の調査費用と並行期間の費用を前払いしているのと同じです。どちらに払うかの違いであって、総額が単純に増えるわけではありません。

本記事では、これらの作業の金額の目安は示しません。 引き継ぎ費用について、算定根拠が公開されている一次資料を確認できなかったためです。相場らしい数字を探すより、上の表の項目ごとに単位と数量を書いてもらうほうが、判断は速く進みます。保守費用そのものの内訳と考え方はシステム保守費用の相場と妥当性の検証手順にまとめています。

なお、注意すべきは高すぎる見積もりだけではありません。現行システムの中身を知らない新候補先の見積もりは、範囲が狭いために安く見えることがあります。 抜けやすい費目の一覧は前掲のロックイン記事に表があります。依頼の前に、いま契約している対応範囲を1枚に書き出してください。 その1枚を新候補先へ渡し、同一条件での見積もりを求めるのが、比較を成立させる最短の手順です。

現ベンダーの請求が正当と言えるケース

引き継ぎに費用を請求されると「囲い込みではないか」と感じる場面があります。ただ、請求されるほうが自然なケースがあります。

前章の表のうち、設計書・手順書の作成／更新、データ出力用スクリプトの作成と実行、過去の作業履歴の抽出と整理、残存課題の洗い出しの4つは、契約に費目が無ければこれまで実施されていない作業です。新たに発生する以上、請求されるのが自然でしょう。ここでは、金額の話に見えて実は権利・作成主体・契約主体の話である3つを挙げます。

「高い」と「不当」は違います。 判断の分かれ目は金額の水準ではなく、算定根拠が示されるかどうかです。作業内容・工数・単価の3つが示されていれば、それは検討できる見積もりです。示されないなら、金額の高低にかかわらず「判断不能」として扱ってください。

出口条項を4状態で仕分ける｜解約前に潰しておく項目

集めた回答は、「良い・悪い」ではなく説明済み／要確認／高リスク／判断不能の4状態に仕分けます。「高リスク」は不当という意味ではなく、いま動くと損をしやすい状態という意味です。

前掲の引き継ぎ資産6点そのものの判定は、ロックイン記事の判定表で済ませてください。4状態の定義は同じ枠組みですが、データだけは出口条項として範囲と構造の2軸を足した5軸で判定します。あちらで「説明済み」だった場合も、ここで判定し直してください。ここで仕分けるのは、資産そのものではなく出口の条項です。「対応する条項」の列は、前掲の「出口を決める7条項」の番号を指します。

表の末尾2項目に「7条項に無い」と付けたのは、契約書に条項として書かれることがほとんどない一方で、解約を決めたあとで効いてくるためです。作業経緯と残存課題は依頼して初めて出てくるもので、再契約の可否は条項が無ければ「不可」ではなく「未確定」です。どちらも、契約書を読むだけでは埋まりません。

「高リスク」が1つでもあるなら、その項目を解消するまで解約の意思表示をしないでください。 意思表示をした後は、条件を決める側が相手になります。

「判断不能」が多い場合は、乗り換えの検討ではなく棚卸しの実施が先です。判断不能のまま他社に声をかけても、返ってくる見積もりを評価できません。

上の表のうち、条項1〜7に対応する6項目は契約書側の条項です。契約書を見ながら手で埋めてください。残る2項目は、現ベンダーへの照会で埋めます。 どちらもツールで代替はできません。

一方、見積書の側から確認したい場合は、システム見積もり診断（登録不要）の「保守・運用」を選ぶと使えます。見るのは保守の対応範囲・月額保守費の内訳・障害対応と改修の境界の3点で、見積書から確認できなかった項目について、指摘とベンダーへの質問が返ります。出口の条項そのものは診断対象ではないので、上の表と役割を分けて使ってください。見積書はテキストPDF・XLSX・CSVで読み込ませる形式で、結果を見るまでメールアドレスの入力は不要です。返るのは金額の評価ではありません。

ベンダーへそのまま送れる確認質問｜現ベンダーへ6問・新候補先へ5問

ここまでの確認事項を、そのまま送れる文面にしました。回答は、4状態の表にそのまま書き写せます。

現ベンダーへ送る時期は、逆算表の⑥が目安です。新候補先へは、⑤の資料受領を終えたらすぐに送ります。 ④は選定が終わっている必要がある日なので、見積もりの返送と比較にかかる期間を④から引いた日が、実際の送付期限になります。資料が揃う前に声をかけたときにどうなるかは、資料チェックリストの章のとおりです。ただし新候補先への質問1（見積もりに必要な資料の一覧）だけは、⑥の時点で先に聞いておくと⑤の見通しが立ちます。

なお、前掲のロックイン記事の確認質問（引き継ぎ資産の棚卸し）を既に送っている場合、重複するのは下の質問2と質問5です。質問2は飛ばしてかまいません。質問5は、そちらでは聞いていない文字コード・日付書式・対象範囲・テーブル間の関連の保持まで踏み込んでいるので、その追加分だけを照会するか、質問5ごと送り直してください。残る4問は、そちらでは扱っていない、出口の条件（質問1・6）と、引き継ぎ資産の実体（質問3・4）です。

現ベンダーへ送る6問

〇〇株式会社
ご担当者様

いつも保守対応をいただきありがとうございます。
次回の契約更新に向けて、契約条件と資料の現況を社内で確認しております。
解約や契約内容の変更を申し入れるものではありません。
下記についてご回答をお願いできますでしょうか。

1.【契約期間と更新】現行契約の満了日、更新の条件、および
   更新を行わない場合の意思表示の期限と方法（書面／様式の指定の
   有無）をお教えください。あわせて、契約期間中に解約する場合の
   可否と、その際の料金の精算方法についてもご教示ください。

2.【資料・権限・体制の現況】設計書・システム構成図・運用手順書の
   最終更新時点と、稼働後の改修のうち資料へ反映済みのもの・未反映の
   ものの区別をお教えください。あわせて、本番環境・クラウドサービス・
   ドメイン・SSL証明書の契約名義と管理者権限の保有者、および実際に
   作業を担当されている体制と下請・再委託の有無を一覧でご教示ください。

3.【作業経緯】直近12ヶ月の作業実績（日付・事象・対応内容・
   所要時間）を一覧でご提供いただけますでしょうか。
   定額の保守料に含まれる作業と、都度ご請求いただいた作業を
   区別してお示しください。

4.【残存課題】現時点で把握されている未解決の不具合、暫定対応の
   まま残っている事象、既知の制約事項があれば一覧でお教えください。
   該当がない場合も、その旨を書面でご回答ください。

5.【データの出口条件】契約終了時における業務データの出力について、
   現行契約での定めをお教えください。定めがある場合は、出力の形式
   （ファイル形式・文字コード・日付書式）、対象範囲、テーブル間の
   関連の保持の可否、提供までの日数、費用の有無をご教示ください。
   定めがない場合は、その旨をご回答ください。

6.【引き継ぎ支援】将来、保守体制を見直す場合に備えてお伺いします。
   他社への引き継ぎ支援について、契約上の定めの有無、提供いただける
   作業内容、想定される時間と単価、成果物をお教えください。

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

新候補先へ送る5問

比較を成立させるには、こちらの条件を揃えて聞く必要があります。新候補先へは次を送ります。

〇〇株式会社
ご担当者様

保守委託先の検討にあたり、下記についてご回答をお願いいたします。
現行の契約範囲は別添のとおりです。同じ範囲を前提としたお見積もりを
お願いできますでしょうか。

1.【引き受けの前提条件】お見積もりにあたり、必ず必要となる資料・
   情報を一覧でお教えください。それが揃わない場合に、お見積もりへ
   どのような前提や割増を置かれるかもご教示ください。

2.【引き継ぎ期間の費用】引き継ぎのための現行調査・環境再現・
   体制立ち上げについて、保守料とは分けてお見積もりください。
   作業内容と工数、単価の内訳をお示しください。

3.【並行稼働の想定】現在の保守会社との並行期間を何ヶ月見込まれますか。
   その期間中、一次対応をどちらが行う前提でしょうか。

4.【資料が不足していた場合】引き受け後に、資料に記載のない仕様や
   未知の不具合が判明した場合、どのように扱われますか。追加費用の
   発生条件と、その判断の手順をお教えください。

5.【将来の引き継ぎ条件】御社との契約を終了する場合の、解約予告期間、
   データ出力の条件（形式・範囲・テーブル間の関連の保持・提供までの
   日数・費用）、資料の引き渡し範囲を、契約条項としてご提示
   いただけますでしょうか。

〇月〇日までにご回答いただけますと幸いです。
よろしくお願いいたします。

新候補先への質問5は、必ず入れてください。 出口の条件を最初に聞ける相手かどうかは、その会社の姿勢がよく出る質問です。ここで条項として提示できる会社なら、次に変更を検討するときも同じ手間で済みます。

回答をどう読むか

この表の使い方は1つだけです。回答の返らなかった項目には4状態の表で「判断不能」を立て、前掲の逆算表②の通知期限までに埋まるかどうかで、動くかどうかを決めてください。 期限までに埋まらないなら、今期は更新して整備に充て、次の満了日を目標にするほうが結果的に早く進みます。期限を過ぎてから動き出すと、ここまでの手順はどれも使えません。

「変更しない」という結論も、同じくらい正しい

ここまでの確認を終えた結果、現ベンダーの継続が合理的だと分かることは十分にあります。次の状況では、変更しないほうが合理的です。

逆に、次の状態は「継続」ではなく「先送り」です。費用の内訳が出てこない、作業実績が報告されない、資料の所在が分からない。 この3つが揃っているなら、変えるかどうか以前に、いま何を買っているのかが分かっていません。

第三の選択肢｜一部を自社で持つ

「全部を任せる」か「全部を別の会社へ移す」かの二択にする必要はありません。監視・定常作業・問い合わせの一次受けなど、切り出しやすい範囲から自社に戻し、外部委託の範囲を段階的に見直すという進め方もあります。

判断の起点は、直近1年で自社の業務知識がないと決められなかった作業がどれかを洗い出すことです。そこは外に出しても往復が発生します。逆に、手順が決まっている作業は、担当を移しやすい領域です。社内で開発・保守の一部を担う体制の作り方はClaude Code × 情シス・社内SEの内製化にまとめています。

なお、システムそのものを作り替える判断まで視野に入る場合は、保守会社の変更とは別の意思決定になります。移管の費用をかける前に、更改の時期と重ならないかを確認してください。

根拠資料と適用条件

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

チェックリスト・判定表・確認質問の文言は、上記の公的資料と公開約款の記載を参考に一般化したものであり、特定の資料からの直接の引用ではありません。原典からの引用箇所は、本文中で引用ブロックまたは表内で出典を示しています。

引き継ぎ費用・移管費用の金額の目安は、本記事では示していません。 算定根拠が公開されている一次資料を確認できなかったためです。検索すると金額のレンジを示す記事はありますが、算定の前提（対象システムの規模、資料の整備状況、並行期間の有無）が示されていないものが大半で、自社の判断には使えません。本記事では代わりに、見積書の行を作業単位へ分解し、単位と数量を書いてもらう手順を示しています。

なお本記事は、法的な最終判断を提供するものではありません。契約の解釈、条項の有効性、解約に伴う損害賠償の要否については、弁護士にご確認ください。

よくある質問