システム引き継ぎで開発会社を変更するには｜ソースと資料から頼める調査を決める

他社が作った業務システムを別の開発会社に引き継ぐなら、今の会社との契約を終える前に、ソースコード、本番環境の管理権限、データを自社で管理できる状態にしてください。そのうえで新しい会社にはいきなり改修を頼まず、まず「調査」を頼みます。手元に何が残っているかで、「調査のみ」「調査＋改修」「作り直しを判断する」のどこから頼むかが決まります。

この記事は、他社が作ったシステムを使っていて、「今の開発会社に改修や保守を頼みにくい」「担当者が辞めた」「連絡がつかない」という状況にある経営者・事業責任者・システム責任者に向けて書いています。読み終えたときに、次の4つを自分で決められることを目指しています。

今の会社との関係を終える前に、何を自社で押さえるか
手元の資料の有無から、どこまでの調査を頼むか
調査の報告で、保守の継続・部分改修・作り直しのどれを選ぶか
業務を止めずに切り替える順番と、元に戻す条件

開発会社の変更と引き継ぎ調査が合う場合・合わない場合

開発会社への不満があっても、会社を変えることが答えとは限りません。まず不満の中身を分けてください。

状況	合う方法	開発会社の変更
改修の見積や回答が遅いが、ソースや管理権限は自社で押さえている	今の会社と担当者・対応時間・費用の説明方法を見直す。比べる材料として別の会社に調査だけ頼む	必須ではない
保守費が高いと感じるが、内訳を聞いたことがない	保守の作業内容と金額の内訳を今の会社に確認する（保守運用費の考え方）	内訳を見てから判断
作った会社が廃業した、担当者が辞めて誰も分からない、連絡がつかない	新しい会社に調査を頼む	必要
必要な画面・帳票を追加してもらえない、追加が断られる	他社に部分改修を頼めるか調べる	部分改修だけ別の会社に頼む形もある
同じ機能のクラウドサービス（SaaS）やパッケージが既にある	既製品への置き換えを先に比べる（SaaSかカスタム開発か）	置き換えるなら引き継ぎ自体が不要
担当者が個人で作ったスプレッドシートの自動処理だけが問題	処理の一覧を作り、作り直すか引き継ぐかを決める（後述）	開発会社の問題ではない

「改修か、作り直しか」を費用で比べたい段階なら、システムの改修とリプレイスの比較が先に役立ちます。この記事は、他社が作ったものを調べて引き継ぐ手順に絞ります。

今の会社との関係を終える前に、自社で押さえるもの

出典: GitHub 公式

契約が終わってから「ソースコードの最新版がない」「サーバーの管理者が前の会社の名義だった」と分かると、取り戻すために前の会社との交渉からやり直すことになります。解約や保守契約の終了を伝える前に、次の表を埋めてください。

資産の確認表（記入例はすべて架空）

確認するもの	確認すること	記入例（架空）
ソースコード	本番で動いている版と同じか。どこに保管されているか	開発会社のリポジトリ。自社は閲覧権限なし
本番サーバー・クラウド	契約の名義人、管理者権限を持つ人	クラウドの契約名義は開発会社。請求は自社へ転送
ドメイン・SSL証明書	登録名義と更新期限	名義は自社、管理画面のログインは開発会社の担当者
データベース	データの置き場所、バックアップの有無と取り出し方法	毎日バックアップしていると聞いているが未確認
外部連携	つないでいる外部サービス、取引先、外部サービスの利用契約の名義	取引先へ毎朝CSVを送信。認証情報の管理者は不明
定期処理	どの処理が、いつ、どのサーバーで動くか	夜間の集計がある。時刻は不明
仕様書・操作手順	最後に更新された時期、今の動きと合っているか	5年前の仕様書のみ
テスト	改修後に何を確かめているか、手順が残っているか	なし
運用手順	障害時の連絡先、再起動・復旧の手順	開発会社に電話するだけ
契約書	著作権の帰属、ソースコードが納入物に入っているか、契約終了時の協力の定め	保守契約書は総務が保管。中身は未確認

パスワードや鍵（認証情報）は、メールやチャットで受け取って使い回すのではなく、新しい担当者用のアカウントと権限を作ってもらう形で受け取ります。切り替えが終わったら、前の会社のアクセス権を外し、鍵を作り直す作業を計画に入れておきます。

契約書で見る箇所

契約の解釈は弁護士の仕事なので、ここでは「どこを見るか」だけを示します。IPA（情報処理推進機構）が公開している情報システム・モデル取引・契約書第二版の第45条は、納入物の著作権について3つの案を示しています。

IPAモデル契約第45条	著作権の扱い	引き継ぎで確かめること
A案	開発会社に残る。ただし発注者は、自分で使うために必要な範囲で複製・改変できる（著作権法47条の3・47条の6）	自社の契約がこの形に近いか。他社に保守を頼む範囲が契約上認められるか
B案	汎用部品を除き、委託料の支払いが終わった時点で発注者へ移る	支払いが完了しているか。汎用部品として除かれた部分はどこか
C案	汎用部品を除き、発注者と開発会社の共有（持分は均等）。モデル契約では、第三者への利用許諾を含めてどちらも行使でき、そのための合意を契約であらかじめ与えている	自社の契約に同じ定めがあるか。ない場合は、共有部分を他社に改修させるときに相手の同意が要るか

同じ資料の解説では、著作権を持たない発注者でも保守運用を別の会社に委託することは可能としたうえで、ソースコードの開示は「納入物にソースコードを明記する」か「第三者に預ける制度（ソースコード・エスクロウ）を使う」ことで確保できると書いています。つまり、著作権の帰属とは別に、ソースコードが納入物に入っていたかを確認する必要があります。「著作権をすべて譲渡する」とだけ書かれている場合の注意点は、システム開発の納品物と著作権で詳しく扱っています。

足りない資料ごとに、調査で分かること・分からないこと

仕様書がなくても、ソースコードと動く環境があれば調査は進められます。反対に、仕様書が揃っていても本番の版のソースがなければ、改修の見積は出せません。足りないものごとに、何が決められなくなるかを整理しました。

足りないもの	調査で分かること	調査だけでは分からないこと	判断への影響	代わりの手段
仕様書	機能の一覧、計算や分岐のルール、データの構造（ソースコードから読み起こせる）	そのルールを作った理由、今も必要か	改修の範囲は決められる。業務の確認に時間がかかる	業務の担当者に確認する場を設ける
本番と同じ版のソースコード	手元の版の構成	本番で実際に動いている処理	改修の見積が出せない	現在の会社・保管先から最新版を入手する。入手できなければ作り直しを検討
ソースコード全体	画面・帳票・出力データから見える機能	内部の計算、例外処理	改修はできない。作り直しの範囲を決める調査になる	画面操作と出力結果から機能一覧を作る
サーバー・クラウドの管理権限	ソースに書かれた接続先の名前	実際の設定値、定期処理の実行時刻、ログ	本番での動作確認と切り替えの計画が立てられない	名義人に権限の付け替えを依頼する
データベースの構造	ソースから推定できる表と項目	本番で後から追加された項目	推定と本番が違うと、改修後に止まるおそれがある	データの中身ではなく構造（定義）だけを出してもらう
テスト・確認手順	―	改修後に何を確かめれば合格か	改修のたびに確認範囲を決め直す必要がある	調査の中で最低限の確認手順を作る
運用手順・障害の履歴	ログから分かる範囲のエラー	止まったときに誰が何をしていたか	切り替え直後に障害が起きたときの対応が遅れる	現在の担当者に聞き取りをする

ソースコードが手元になく、権利の所在も分からない場合、勝手に解析したり、アクセス制限を回避して中身を取り出したりする方法は取りません。まず「誰が持っているか」「誰に利用を認めてもらえばよいか」を契約書と名義から整理します。

架空の小さなシステムを実際に調べてみた

調査で何が分かり、何が分からないまま残るのかを確かめるため、架空の受注管理システムを用意して、引き継ぎ調査の手順を実際に試しました。

対象：この検証のために作った架空のシステム（5ファイル。画面からの受注登録、毎朝の取引先向けCSV送信）。実在する顧客・システムとは関係ありません
意図的に入れた不足：説明書（README）なし、テストなし、設定値なし、説明のない値引きルール、ソースコードの保管場所（リポジトリ）にあるデータベース定義と本番データベースのずれ
方法：AIのコーディング支援ツールでコードを読み、手元のパソコン（macOS、Python 3.14.8）で実行
実施日：2026年10月9日。かかった時間は計測していません

検証の結果（架空のシステムでの結果）

調べたこと	結果	分かったこと	分からないまま残ったこと（確認先）
起動手順	説明書・テストなし	―	起動方法（前の担当者）
必要な設定値	コードから4つの設定名を特定（データベースの場所、取引先の接続先・ユーザー名・パスワード）	何を用意すれば動くか	設定の中身（サーバー管理者）
設定なしで起動	起動時にエラー	設定値がないと動かない	―
受注登録	動作した。顧客コードが「K-」で始まると10,000円が9,700円になる	3%の値引きルールがある	「2019/4 部長指示」とだけ書かれたこのルールが今も有効か（業務の責任者）
毎朝のCSV送信	「税率の項目がない」というエラーで停止	リポジトリのデータベース定義と、本番のデータベースが違う可能性	本番に後から追加された項目と、その値（本番データベースの定義）
税率の項目を仮に追加して再実行	社内ファイルサーバーの保存先がなく停止	社内のファイルサーバーに依存している	保存先の場所と権限（社内の情シス）
部品（ライブラリ）の導入	指定どおりの版は入ったが、読み込み時に別の部品が足りずエラー	部品の一覧だけでは本番と同じ環境を作れない	本番サーバーに入っている部品の版（サーバー管理者）
毎朝の実行時刻	リポジトリに設定がない	コメントに「毎朝」とあるだけ	実行時刻と実行するサーバー（サーバー管理者）

5ファイルの小さなシステムでも、コードを読んで手元で動かすだけで、設定値・隠れた業務ルール・定義のずれ・社内サーバーへの依存は洗い出せました。この洗い出しはAIを使えば速く進みます。一方で、表の右端に残った項目は、本番環境を見る権限と、業務を知っている人への確認がなければ埋まりません。実際の業務システムはこれより大きく、確認先も増えます。引き継ぎ調査を頼むときは、「コードを読む作業」よりも「本番と照合し、関係者に確かめる作業」をどこまで含めるかを決めることが重要です。

担当者のアカウントで動いている自動処理（GAS・スプレッドシート）

Google Apps Scriptのプロジェクトをコマンドラインで管理するclaspの公式リポジトリ

出典: google/clasp GitHub 公式

開発会社が作ったシステムとは別に、社内の担当者が作ったスプレッドシートの自動処理（Google Apps Script、略してGAS）が業務を支えていることがあります。担当者の異動や退職で引き継ぎが必要になるのは、こちらも同じです。

Googleの公式ドキュメントでは、インストール可能なトリガー（時刻や操作をきっかけに処理を自動で動かす設定）について、次のように説明しています。

常に、トリガーを作った人のアカウントで実行される
別のアカウントからは、他の人が作ったトリガーを表示できない

つまり、担当者のアカウントで動いている自動処理は、他の人が画面を見ても「どの処理が、いつ動いているか」が分かりません。担当者がいなくなる前に、次の一覧を作ってもらってください。

項目	記入例（架空）
処理の名前と目的	毎朝、受注シートから出荷指示を作る
動かしているアカウント	担当者個人の会社アカウント
きっかけ（時刻・操作）	毎朝7時
読むファイル・書くファイル	受注シート（営業部共有）、出荷指示シート
外部への送信	倉庫へのメール送信、外部サービスへのデータ送信
止まったときに誰が気づくか	倉庫から「指示が来ない」と電話が来て気づく
作り直すか引き継ぐか	未定

アカウントが止まったときにトリガーがどうなるかについて、公式ドキュメントで確認できる記述は見つかりませんでした。止まるおそれがあるものとして扱い、引き継ぐ人のアカウントでトリガーを作り直す、または業務システムへ移す判断をします。自動化が定着しない・属人化する理由そのものは業務自動化が定着しない原因とPower Automateの属人化、スプレッドシート業務をシステムに移す判断はExcel業務のシステム化で扱っています。

調査の頼み方｜調査のみ・調査＋改修・作り直しの判断

新しい会社への依頼は、手元の資料と目的に合わせて3つのどれから始めるかを選びます。

頼み方	合う状況	受け取るもの	次の判断
調査のみ	会社を変えるか決めていない。今の会社との条件見直しの材料が欲しい	調査報告（下の目次例）	報告を見て、変える・変えない・作り直すを決める。調査だけで終えてもよい
調査＋改修	ソースと管理権限が揃っていて、急ぎの画面・帳票追加や不具合修正がある	調査報告と改修	改修後に保守をどこに頼むかを決める
調査＋作り直しの判断	ソースがない、古い技術で動かせない、改修の積み重ねで手を付けられない	調査報告と、作り直す範囲・残す範囲の案	作り直しの見積と段階分けを決める（段階的な発注）

画面や帳票を足したいだけの場合

「既存の画面は残したまま、検索条件や出力帳票を1つ足したい」という依頼でも、他社が作ったシステムでは最初に調査が入ります。変更してよい権利があるか、追加した部分を誰が保守するか、追加の影響がどこまで及ぶかを確かめる必要があるためです。作った会社以外に改修を頼むと費用が上がる場合がある理由は、システムの小規模改修の費用で説明しています。

調査報告で受け取るもの

調査費を払っても、報告書を読んで何も決められなければ意味がありません。次の目次例を、依頼時に「この内容が入っていること」として伝えると、受け取った後の判断が速くなります。

調査報告の目次例（説明用の構成例）

調査の範囲と、受け取った資料・権限の一覧
手元で動かせたか（再現した手順と、動かなかった箇所）
構成と接続先の一覧（サーバー、データベース、外部連携、定期処理）
業務ルールの一覧（それぞれがコードのどこに書かれているか）
未確認の事項と、その確認先
リスク（サポートが終わった部品、本番との食い違い、特定の人への依存）
選択肢と前提（保守の継続／部分改修／部分的な作り直し／全体の作り直し／今の会社との条件見直し）
次の見積に必要な資料と、決めること

受け取ったときは、「確かめた事実」「推測」「未確認」が分けて書かれているかを見てください。この3つが混ざっている報告書では、どこまで信用して次に進めるかが決められません。

業務を止めずに切り替える順番と、戻す条件

開発会社の切り替えで業務を止めないためには、新しい会社が責任を持つ日まで、今の会社の保守を残しておくことが基本です。止まる可能性をゼロにはできないので、「どうなったら元に戻すか」を先に決めておきます。

切り替えの分担表（説明用の構成例）

段階	今の会社	自社	新しい会社	次に進む条件	戻す条件
1. 資産の確保	ソース最新版・管理権限・資料を渡す	名義を自社に移す。契約書を確認する	―	資産の確認表が埋まる	―
2. 調査	質問に答える	業務ルールを確認する	調査し、報告する	報告を読んで方針を決めた	本番と照合できない項目が残り、判断できない
3. 試験環境での確認	保守を続ける	確認する業務を選ぶ	本番と同じ構成の試験環境で動かす	主要な業務の確認が通る	試験環境で再現できない処理が残る
4. 切り替え	待機する	止められない時間帯を伝える	本番の作業をする	切り替え後の確認が通る	決めた業務が決めた時間内に動かない
5. 引き渡しの完了	アクセス権を外す	鍵・パスワードを作り直す	保守を始める	新しい会社の保守開始日を契約で決める	―

試験環境で確かめず、戻す手順も決めないまま本番を切り替える進め方はおすすめしません。切り替えた後の保守の範囲と費用は、システム保守運用費の考え方を参考に決めてください。

AIで自社で進められること・会社に頼むこと

ChatGPTやClaudeなどのAIを使えば、自社でもソースコードの概要説明や機能一覧の下書きは作れます。上の検証のとおり、設定値や隠れたルールを洗い出す作業もAIで速く進みます。ただし、社外のAIサービスにソースコードや設定ファイルを入れる前に、社内規程とサービスの利用条件を確認してください。パスワードや鍵が書かれたファイルは入れないでください。

作業	自社でAIを使って進められるか	会社に頼む理由
ソースの概要説明、機能一覧の下書き	進められる	―
業務ルールの洗い出し	下書きはできる	業務の担当者への確認と、ルールを残すか変えるかの判断
本番との照合	管理権限があれば可能	権限を持って本番の構成・データベースの定義・定期処理を確かめる
手元・試験環境での再現	小規模なら可能	本番と同じ構成を作り、足りない部品や設定を埋める
改修と改修後の確認	可能	影響範囲の確認、戻す手順、改修後の責任
切り替えと保守の引き受け	―	障害時の対応と、誰が責任を持つかを契約で決める

AIで作った下書きを持ち込んでいただければ、調査の出発点として使えます。

費用の目安

当社（AI革命）の受託開発の公開価格は次のとおりです（税別）。

区分	価格（税別）	含むもの・含まないもの
初回相談	無料	30分・オンライン。相談後に相談メモをお送りします
引き継ぎの調査	個別にお見積り	調査報告は有償です。始める前に範囲と金額をお示しし、合意をいただいてから進めます
小規模な既存改修	30万円〜	既存システムの一部の改修。他社が作ったシステムでは、調査の結果によってはこの価格帯に収まりません
PoC（試作と検証）	300万円〜	作り直しの方式を試す段階の価格です。本番システムの完成価格ではありません
本開発・作り直し	個別見積	機能、利用者数、外部連携、データ移行で決まります
実費	別途	クラウド、外部API、ライセンスなどの利用料

他社の公開例も参考に挙げます（2026年10月9日に各社のサービスページで確認。相場を示すものではありません）。

会社	公開している内容
FALXTER	既存システムの調査・引き継ぎ 50万円〜（税別）、2〜4週間程度。調査報告書・リスク一覧・概算工数などを受け取り、調査だけで終えることも可能
ネオロジック	価格は非公開。期間は2週間〜2か月
FIXIT	価格は非公開。現状調査2〜3週間、方針と見積1〜2週間

当社は、他社が作ったシステムの調査・引き継ぎ・改修に対応しています。言語やフレームワークを理由にお断りはしていません。「調査のみ」も「調査＋改修」もお受けできます。最初に、ソースコード・仕様書・環境情報があるか、それを使ってよい権利があるかを確認します。なお、他社システムの引き継ぎで公開できる事例はまだないため、この記事の検証と表は架空のシステムと説明用の例で示しています。

困っている操作と、手元にあるソース・仕様書・環境情報の有無から、引き継げるか相談する

相談の前に揃えておくと早いもの

初回相談は無料・30分（オンライン）です。要件が決まっていなくても大丈夫です。次の情報があると、30分で依頼範囲の候補まで話を進められます。

困っている操作と、困っている理由（改修できない、止まる、担当者がいないなど）
システムの用途、使っている部署と人数の目安、使っている言語やサーバーが分かればその名前
手元にあるもの：ソースコード、仕様書、操作手順、サーバー・クラウドの管理アカウント（有無だけで構いません）
今の開発会社との状況：保守契約が続いている、終了予定、連絡がつかないなど
いつまでに決めたいか、止められない時間帯

ソースコードそのもの、パスワードや鍵などの本番の認証情報、実際の顧客データは、相談フォームやメールで送らないでください。

相談では、自社でAIを使って進める部分と任せる部分を一緒に切り分けます。相談後に、依頼範囲の候補・進め方・費用の目安をまとめた相談メモをお送りします。初回の30分で確定見積や「引き継げる・引き継げない」の断定はしません。資料を見てから判断します。

よくある質問

Q1. 今の開発会社に知らせずに相談できますか。

相談の段階では知らせる必要はありません。ただし、本番環境の管理権限やソースコードの最新版が今の会社の名義で管理されている場合、調査を始める前にどこかで依頼や連絡が必要になります。いつ、誰から、何を依頼するかを相談の中で一緒に整理します。

Q2. 調査だけ頼んで、改修は今の会社に続けてもらうことはできますか。

できます。調査報告は、会社を変えるかどうかを決めるための材料です。報告をもとに今の会社と改修の範囲や費用を話し合い、会社を変えないという結論になっても問題ありません。

Q3. 古い言語やフレームワークで作られたシステムでも引き継げますか。

技術の古さを理由にお断りはしません。ただし、本番と同じ部品・版の環境を手元で再現できるかどうかで、調査と改修の進め方が変わります。上の検証のように、指定された版の部品を入れても動かない場合があり、その解消も調査の範囲に入ります。

Q4. 調査や切り替えの途中で障害が起きたら、誰が対応しますか。

新しい会社の保守開始日を契約で決めるまでは、今の会社の保守契約が残るように順番を組むのが基本です。どの日から誰が対応するかが曖昧な期間を作らないことが、切り替えで最も重要な点の一つです。

Q5. ソースコードがなく、画面と出力される帳票しか残っていません。

ソースコードが見つからない限り今のシステムを直すことはできないため、画面の操作と出力結果から機能の一覧を作り、作り直しの範囲を決める調査になります。その前に、ソースコードを持っている可能性のある相手を当たります。前の開発会社のほか、契約にソースコード・エスクロウ（第三者への預け入れ）の定めがあれば預け先、社内の旧担当者の端末や共有フォルダが候補です。作り直しを選ぶ場合も、今のシステムのデータを取り出せるかどうかは別に確認が必要です。

Q6. 社内でAIにソースコードを読ませた結果を持ち込んでもよいですか。

歓迎します。機能一覧や構成の下書きがあれば、調査の出発点になります。ただし、AIの説明は本番と照合する前の仮説として扱います。社外のAIサービスにコードを入れる前に、社内規程と利用条件の確認を済ませてください。

他社が作ったシステムの引き継ぎを相談する

開発会社を変えるかどうかは、手元に何が残っているかを確かめてから決められます。今の資料の状況と困っている操作を伺い、「調査のみ」「調査＋改修」「作り直しの判断」のどこから始めるかを一緒に整理します。初回相談は無料・30分（オンライン）で、相談後に依頼範囲の候補・進め方・費用の目安をまとめた相談メモをお送りします。

困っている操作と、手元にあるソース・仕様書・環境情報の有無から、引き継げるか相談する