システム保守の引き継ぎ｜渡すものの一覧と進め方、契約が切れる前にしか取れないもの

システムの保守を頼んでいる会社を変えることになった。何を受け取っておけばよいのか。この記事はその場面にいる担当者に向けたものです。従業員10〜20名で、専任のIT担当がいない会社を想定しています。専任者のいない会社は、受け取った資料を自分で読むわけではありません。次のベンダーへ渡すために、いったん自社で預かる立場です。この違いが、受け取るべきものを変えます。

結論

専任者のいない会社は、引き継ぎを自分で読むために受け取るのではありません。次のベンダーが作業できる状態を保つために預かる立場です。順序も決定的です。受け取ってから解約を伝えます。解約の意思を先に伝えると、相手にとって優先度の低い作業になります。

引き継ぐのは自社ではなく、次のベンダー

保守の引き継ぎ（保守移管）とは

保守の引き継ぎ（保守移管）とは、いま動いているシステムはそのままにして、面倒を見る会社だけを別の会社へ移すことをいいます。画面も機能も昨日までと同じで、変わるのは連絡先と請求元だけです。システムそのものを作り替える場合は別の話になるため、そちらはレガシーシステムの移行計画を参照してください。この記事は、システムは変えずに保守する会社だけが変わる場合を扱います。

引き継ぎが難しくなるのは、その作業を作った会社にしかできない状態になっているからです。公正取引委員会はこれをベンダーロックインと呼び、ソフトウェアの機能改修やバージョンアップ、ハードウェアのメンテナンス等、情報システムを使い続けるために必要な作業を、それを導入した事業者以外が実施することができないために、特定のシステムベンダーを利用し続けなくてはならない状態、と定義しています。この定義は、国の機関及び地方公共団体における情報システム調達の実態を把握するために行われた調査の中で示されたもので、対象は民間の中小企業ではありませんが、起きていることは同じです。出典: 公正取引委員会の報道発表（令和4年2月8日公表）／出典の確認日: 2026年9月5日。

引き継ぎが起きる場面は3つに分かれます。社内の担当者が辞めて分かる人がいなくなる場合、保守を頼んでいる会社を変える場合、保守会社が倒産したり連絡が取れなくなる場合です。この記事が扱うのは2つ目で、会社を変える場面に絞っています。1つ目は担当者が辞めるとき、AIまわりで何が消えるか、3つ目は発注したAI開発が動かない・連絡が取れないで扱いました。

ここからは、専任のIT担当がいない会社という前提に立ち戻ります。誰が引き継ぎの中身を読むのかによって、先に押さえるものの順番は変わってきます。

立場	最も重要なもの	理由
自社に技術者がいる	設計書・ソースコード・手順書	自分たちで読んで直す
自社に技術者がいない	契約名義・アカウントの管理者権限・権利の所在	次のベンダーが作業できる状態を保つ

資料をどれだけ受け取っても、サーバーの契約が前のベンダーの名義のままなら、次のベンダーは何も触れません。資料は後から作り直せますが、契約と権利は後から取り戻せないことがあります。専任者のいない会社ほど、資料の量よりも名義と権限を先に押さえるほうが安全です。

契約が切れる前にしか取れないもの

全体の流れと、契約終了日からの逆算

時期	やること	終わっていないと起きること
契約終了の3か月前	契約書を読み、義務の範囲と納入物の記載を確認する	何を請求できるか分からないまま交渉に入る
契約終了の2か月前	請求書1年分から契約と名義の一覧を作る	名義の分からない契約が残る
契約終了の1か月前	受け取りを完了し、その場で動作を確かめる	不足に気付いても取り戻せない
契約終了日まで	次のベンダーと旧ベンダーが並走し、質問できる状態を保つ	障害時に聞く相手がいなくなる
契約終了後1か月	旧ベンダーのアカウントを停止し、共有パスワードを変更する	外部から入れる状態が残る

引き継ぎの解説を出している各社の記事でも、全体にかかる期間はばらばらです。小規模なら2週間、大きなものは6か月以上と幅があり、規模と構成で変わるため一律の日数は示せません。日数で測るよりも、契約終了日を起点に逆算して、いつまでに何が終わっていればよいかで押さえるほうが確実です。逆算にすると、遅れがそのまま「取り戻せないもの」へ変わる境目が見えてきます。

順序が決定的です。契約期間が終わった後では、次のものは入手が難しくなります。相手に応じる義務がなくなるからです。

取れなくなるもの	終了後に起きること	いつまでに取るか
各種アカウントの管理者権限	パスワードを聞ける相手がいなくなる	契約終了の1か月前
ドメイン・サーバーの契約情報	更新の案内が前ベンダーに届き、失効に気付けない	同上
ソースコードと設定ファイル	「保管義務は契約期間内まで」とされることがある	同上
過去の障害の記録	担当者の記憶に依存しており、退職で失われる	同上
外部サービスの連携設定	APIキーの発行元が分からなくなる	同上

この表のうち「過去の障害の記録」と「外部サービスの連携設定」は、資料として残っていないことが珍しくありません。担当していた技術者の頭の中にしかない情報で、これを属人化と呼びます。書類を受け取るだけでは埋まらないため、契約が終わる前に、担当していた技術者へ直接ヒアリングする場を設けることを勧めます。「何か資料はありますか」ではなく、「過去に起きた障害を教えてください」「よく聞かれる質問は何ですか」と具体的に聞くほうが、暗黙知は引き出しやすくなります。

「解約を伝えてから引き継ぎを頼む」のは順序が逆です。解約の意思を伝えた後は、相手にとって優先度の低い作業になります。引き継ぎに必要なものを受け取ってから、解約の話をします。

費用と期間について、世の中に出ている目安

金額を書いている記事は多くありませんが、相場観がまったくないまま見積もりを受け取るのも困ります。ここでは、引き継ぎの解説を公開している4社が示している目安を、そのまま並べます。数字はいずれも各社の記載であって、この記事で裏づけを取れた金額ではありません。

掲載元	引き継ぎにかかる費用の目安	期間の目安	出典表記
FUNBREW	小規模30〜80万円／中規模80〜200万円／大規模200万円〜	小規模2週間〜1か月／中規模1〜2か月／大規模2〜6か月	なし
olana	ソースコード解析30〜100万円／データ移行10〜50万円／ドキュメント整備20〜80万円	1〜3か月	なし
three dots.	保守費1〜3か月分相当から数十〜数百万円	中小規模で全体2〜4か月	参照5件のうち4件は同業他社のコラム
システム幹事	記載なし	移管に1か月半〜10か月	なし

上の表の出典（いずれも各社のコラム、確認日 2026年9月5日）: FUNBREW、olana、three dots.、システム幹事。4社はいずれも開発や保守を請け負う事業者で、金額は自社の実務にもとづく目安として書かれています。

4社とも本文に出典表記がなく、同じ数字を裏づける公的な統計は、2026年9月5日に確認した範囲では見つけられませんでした。移管後の月額保守費についても、システム幹事は開発費の5〜15％が毎月かかると書き、three dots.は年間で開発費の10〜20％と書いていて、桁が1つ違います。したがって、これらを相場として扱うことはできません。自社が受け取った見積もりを並べ、どの作業にいくら付いているかを見比べる材料としてだけ使います。

契約名義を確認する｜誰の名前で契約されているか

対象	確認すること	自社名義でない場合
ドメイン	登録者情報が自社になっているか	移管手続きを依頼する。認証コードが要る
サーバー・レンタル環境	契約者と請求先	名義変更または新規契約への移行
SSL証明書	発行先と更新の担当	期限を確認し、次の更新を誰がやるか決める
業務で使っているSaaS	管理者アカウントが自社の誰かか	管理者権限の移譲を依頼する
外部サービスのAPIキー	誰のアカウントで発行されたか	自社アカウントで再発行する

ベンダーが代行で契約していること自体は珍しくありません。問題は、その状態のまま関係が終わると、更新も変更もできなくなることです。ドメインが失効すれば、メールも止まります。確認は請求書からたどるのが早い方法です。毎月・毎年何に対して払っているかを一覧にすると、名義の分からないものが浮かびます。

ドメインは、名義を移す手順まで決まっている

JPドメイン名の管理を任せられる指定事業者は1社だけで、すでに登録されているドメイン名でも、別の事業者へ変更できます。変更には認証コード（AuthCode）が必要になります。これはJPRSが生成するもので、登録者の側で文字列を決めることはできません。有効期限は、JPRSが認証コードを生成した日の翌日を1日目とした35日後の23:59:59で、切れた場合は変更元の指定事業者への確認からやり直しになります。手続きは変更元から登録者への意思確認を通り、登録者が「承認」を回答した時点で完了します。指定事業者変更ロックやレジストリロックが設定されている場合は、先に解除しておく必要があります。出典: JPRSの指定事業者変更の案内（出典の確認日: 2026年9月5日）。

いま誰が管理指定事業者になっているか分からない場合は、JPRSの窓口へドメイン名を添えて問い合わせれば教えてもらえます。ただし答えてもらえるのは、問い合わせた人が登録者、または登録・技術の連絡担当者であることを確認できた場合に限られます。契約が切れた後では、その確認そのものが通らなくなることがあります。出典: JPRSのよくある質問（出典の確認日: 2026年9月5日）。

35日という期限が効いてくるのはここです。契約終了の直前になってからAuthCodeを取ると、移管の手続きが終わる前に有効期限のほうが先に来てしまい、もう一度旧ベンダーに頼み直すことになります。ドメインの名義は、受け取るものの一覧の中でも早い時期に着手する対象です。

ソースコードは誰のものか

受け取れるかどうかは、契約書の記載で決まります。特に取り決めがない場合、作ったものの著作権は制作した側に残るのが原則です。渡してもらえない可能性があります。

契約書で次の3点を確認します。

確認する条項	見るところ	書かれていない場合
著作権の帰属	納品物の権利が発注者に移るか	移らない前提で考える。次の契約で明記する
第三者への開示	自社が別のベンダーへ渡してよいか	禁じられていれば、渡せない
契約終了後の扱い	保管期間、返還、削除の義務	期間内に受け取る

IPA（独立行政法人情報処理推進機構）は「情報システム・モデル取引・契約書（第二版）」を公開しています。掲載ページのダウンロードは「受託開発（一部企画を含む）、保守運用」と「パッケージ、SaaS/ASP活用、保守・運用」の2種類に分かれ、保守・運用が独立した契約書として置かれている点が特徴です。保守を別の会社へ引き継ぐ場面が、契約の側でも独立した取引として想定されているということです。

著作権を持たない発注者でも、保守を別の会社へ委託すること自体はできます。ソースコードや付帯するドキュメントの開示・交付を受けるには、納入物にソースコードを明記するか、エスクロウ制度を活用するという対応が示されています。ただし、この整理が書かれているのは契約書の本体と解説で、掲載ページの本文には出てきません。条項の番号まで確かめる場合は、ページから契約書と解説をダウンロードして読む必要があります。

つまり「納入物にソースコードを含める」と契約書に書いてあるかどうかが分かれ目です。書かれていなければ、次の契約で明記します。

出典: IPA「情報システム・モデル取引・契約書（第二版）」（2020年12月22日公開／2025年6月17日更新／出典の確認日: 2026年8月31日）。法的な判断が必要な場合は専門家へご相談ください。

同じ資料は、引き継ぎがうまくいかない実態についても記述しています。長年運用してきたシステムを作り直す場面では、関係者の退職や異動により業務内容やシステムの仕様を理解する人材がいない、資料が散逸している、改良した内容が資料へ反映されず動いているシステムと設計書やソースコードが一致していない、といった問題が少なくない、というものです。引き継ぎの前に、この状態になっていないかを確認します。

クラウドサービスを乗り換える場合

会計や販売管理をクラウドサービスで使っている場合、確認する項目が違います。中小企業向けの公的なチェックリストがあります。

IPAの「中小企業のためのクラウドサービス安全利用の手引き」は、利用終了時に次を確認するよう示しています。

確認すること	確認できないと起きること
過年度データを含む全データを返却またはダウンロードできるか	過去分が取り出せない
データの形式は他のサービスと互換性があるか	移せない形式で渡される
移行先のサービスに、一括で取り込む機能があるか	手入力になる
返却後にサービス上に残るデータが完全に消去されるか	解約後も相手側にデータが残る

1番目の「過年度データを含む」がとくに重要です。直近の年度だけを渡され、過去分が取り出せないという事態が起こりえます。契約前に確認しておく項目です。

出典: IPA「中小企業のためのクラウドサービス安全利用の手引き」PDF 7ページ チェックシートNo.13（「中小企業の情報セキュリティ対策ガイドライン 第4.0版」付録7／出典の確認日: 2026年8月31日）

ここまでは受け取る側の話です。次にどこへ頼むかは、見るところを3つに絞ります。1つ目は、同じ言語・同じ作りのシステムを、他社が作ったものとして引き取った実績があるかどうかです。2つ目は、1人ではなくチームで受ける体制になっているかどうかで、受け側で属人化すると、数年後に同じことがもう一度起きます。3つ目は、資料が無い状態からの調査費用を、通常の保守費と分けて見積もれるかどうかです。判断の材料はAIで作ったシステムは保守できるかでも扱っています。

前のベンダーが協力してくれない場合

渡してもらうものを、優先順位を付けて頼む

優先度	渡してもらうもの	無いと止まること
最優先	各種アカウントの管理者権限、サーバー・ドメイン・SaaSの契約情報	次のベンダーが何も触れない
高	ソースコード一式、設定ファイル、データベースのバックアップ	同じものを作り直す費用がかかる
中	構成図、デプロイ手順、障害時の対応手順	障害が起きてから調べることになる
低	設計書、テスト仕様書、過去の変更履歴	あれば早いが、無くても動かせる

依頼は「何を、いつまでに、どの形式で」を書いた文書で出します。口頭のやり取りは残らないため、依頼した日付と内容を記録に残しておきます。優先度を付けずに全部をまとめて頼むと、量に押されて最初の1つも出てこないことがあります。上の4行のうち、最優先と高の2行だけは必ず期日を切って頼みます。それでも出てこない場合は、次の順で進めます。

順序	やること	備考
1	契約書に書かれている義務の範囲を確認する	資料の提供・データの返還が明記されていれば、それを根拠に依頼する
2	依頼を書面（メール）で行い、記録を残す	口頭のやり取りは残らない。日付と依頼内容を明確にする
3	自社で取得できるものを先に押さえる	管理画面にログインできるものは、自分で書き出す
4	次のベンダーに、現状から調査してもらう	資料なしで着手する費用を見積もってもらう
5	取れなかったものを一覧にして次のベンダーへ渡す	何が無いかが分かれば、次の会社は対処できる

5番目が実務的に効きます。「資料が揃っていない」ことより、「何が揃っていないか分からない」ことのほうが、次のベンダーにとって困ります。受け取れなかったものを正直に一覧化します。

受け取ったものが本物か確かめる

確認したいこと	確かめ方	専任者がいない場合
ソースコードが本番と同じか	受け取ったコードから、動く環境を作れるか試す	次のベンダーに確認を依頼する
設定ファイルが最新か	更新日時を見る。本番の稼働開始より古すぎないか	日付だけなら自社でも確認できる
データが全部あるか	件数を、システムの画面上の件数と突き合わせる	自社で確認できる
アカウントで実際に入れるか	受け取った情報で、その場でログインしてみる	自社で確認できる

最後の項目は、受け取ったその場でやります。後日試して入れなかった場合、相手に確認する手間が増えます。パスワードは受領時に必ず動作を確かめます。

旧ベンダーのアクセス権をいつ止めるか

旧ベンダーと次のベンダーが同時に動く期間を、並走期間と呼びます。止めるのが早すぎると、引き継ぎ中に確認できなくなります。遅すぎると、外部からアクセスできる状態が残ったままです。

時期	やること	理由
引き継ぎ開始時	止めない	資料の不足を確認する必要がある
次のベンダーが稼働を確認した日	権限を「参照のみ」に落とす	変更はできないが、質問には答えられる
切り替えから1か月後	アカウントを停止する	問い合わせが落ち着く目安
停止と同時に	共有していたパスワードをすべて変更する	アカウント停止だけでは、共有パスワードは残る

最後の項目を忘れやすくなります。アカウントを消しても、複数人で使い回していたパスワードは有効なままです。止めた記録とあわせて、変更した日付を残します。自社で作ったアプリを引き継ぐ場合は事情が変わり、使わなくなったアプリの畳み方はノーコードで作った業務アプリの畳み方にまとめています。

よくあるご質問

引き継ぎにはどのくらいの期間を見ておくべきですか

規模によって変わるため一律の日数は示せませんが、契約終了日から逆算して考えます。受け取るものの確認、次のベンダーへの共有、動作の確認という3つの工程が必要です。少なくとも、契約終了の1か月前には受け取りを完了している状態を目安にします。ぎりぎりになると、不足に気付いても取り戻せません。

設計書がないと言われました。どうすればよいですか

小規模なシステムでは、設計書が作られていないことがあります。無いものは受け取れないため、次のベンダーに「資料なしの状態から調査する費用」を見積もってもらいます。あわせて、次の契約では納品物に何を含めるかを明記します。設計書がないこと自体より、無いと分かっていない状態のほうが問題です。

パスワードを一覧でもらう形で問題ありませんか

受け取ること自体は必要ですが、受け取った後に全て変更します。渡された時点で、相手の手元にも同じ情報が残っています。変更した日付を記録し、誰が新しいパスワードを知っているかを明確にします。メールで受け取った場合は、そのメールの扱いも決めます。

次のベンダーが決まっていない状態でも進められますか

進めます。むしろ、決まっていない段階で受け取っておくほうが安全です。契約名義の確認、アカウント情報の取得、請求書からの契約一覧の作成は、次のベンダーがいなくてもできます。次の会社を選ぶときにも、その一覧が見積もりの材料になります。

引き継ぎ費用を請求されました。払うべきですか

契約書に引き継ぎ支援の記載があるかを確認します。記載がなければ、追加作業として費用が発生することはあります。ただし、契約書にデータの返還義務が定められている場合、その範囲の作業は本来の義務に含まれます。何が義務の範囲で、何が追加作業かを、書面で確認してから判断します。

ソースコードの引き渡しを断られました。どうすればよいですか

まず契約書に、納入物としてソースコードが書かれているかを確認します。記載があれば、それを根拠に書面で請求できます。記載がない場合は、原則として作った側に著作権が残るため、渡らない前提で計画を立て直すほうが早く進みます。そのうえで次のベンダーに、動いているシステムから調査して引き取る費用を見積もってもらいます。次の契約では、納入物にソースコードを明記しておきます。

引き継ぎの間、前のベンダーと次のベンダーの両方に払うことになりますか

期間が重なれば、その分は両方に払うことになります。重なりを短くしたい場合は、切り替え日を先に決めて、そこから逆算して受け取りの期日を置きます。ただし、障害が起きたときに聞ける相手がいない期間を作ってしまうと、復旧に時間がかかり、結果としてかえって高くつくことがあります。並走の期間は、費用ではなく保険として見ておくほうが実態に合います。

今日できることは、請求書を1年分並べて、何に対していくら払っているかの一覧を作ることです。そこに名義の分からないものが出てきたら、それが最初に確認する対象になります。

着手の順序に迷う場合は、お問い合わせからご連絡ください。