システムをリニューアルしたい、新しくしたいのに、開発会社・制作会社と連絡が取れない。
メールをしても返事がなく、電話もつながらない。
一方で、業務システムも会社のサイトも今日は動いていて、止めるわけにはいかない。手元にはソースコードも設計書もなく、事情の分かる担当者もいない…。
いま、こうした「どうしていいか分からない」状況に直面しているかもしれません。
まずは落ち着いてください。
システムが動いているうちは、確認・確保できる資産や、まだ打てる手が残っています。
本記事は、開発会社・制作会社に依頼してシステムやサイトを作ってもらった、非エンジニアの経営者・担当者の方に向けて、次の3ステップを解説します。
- 1.ドメインやサーバーの権利の所在を確定させる
- 2.「引き継ぐ」か「作り直す」かを判断する
- 3.情報がゼロでも作り直せる道筋を立てる
開発会社・制作会社と連絡が取れない。音信不通の典型パターン
まずは、ご自身のシステム・サイトが置かれている状況を整理するところから始めましょう。
次のチェックリストで、当てはまるものを確認してみてください。
- →メールや電話に、1週間以上まったく応答がない
- →これまでの担当者が退職し、問い合わせ窓口が消えた
- →保守料や利用料の請求だけが止まった、または請求元が変わった
- →会社の代表番号にかけても、つながらなくなった
- →請求書の会社名を検索しても出てこない（以前は表示されていた）
- →更新や不具合修正を頼みたいのに、誰に頼めばよいか分からない
一つでも当てはまるなら、解約や削除を急ぐ前に、まずは権利の棚卸しから始めましょう。
慌てて動く前に、現状を把握することが先決です。
音信不通は「HP」だけでなく「業務システム」でも起きている
こうした事態は、会社のウェブサイトに限った話ではありません。
顧客管理、受発注、在庫、予約など、データベース（データを保管する仕組み）を持つ業務システムでも同じように起こります。
むしろ業務システムのほうが、止まったときの影響は深刻になりがちです。
本記事では、ウェブサイトと業務システムの両方を対象に、対処の手順をお伝えします。
開発会社と連絡が取れないと、サイト・システムを引き継げない理由
システムやサイトを別の会社に引き継ごうとしても、うまくいかないことがあります。
主な原因は、次の3点です。
1. ドメインやサーバーの契約名義が制作会社側にある
ドメイン（サイトの住所にあたる名前）やサーバー（システムを動かす場所）の契約名義が、制作会社側になっているケースです。
制作会社に費用を払っていたとしても、名義が相手にあると、自社の判断だけではすぐに動かせません。
2. ソースコードやデータへのアクセス権が手元にない
ソースコードとは、プログラムの中身そのものです。
人間が読める形で書かれており、既存システムを安全かつ効率的に修正・引き継ぐうえで重要な資料になります。
ソースコードやデータへのアクセス権が手元になく、サーバーの管理画面にも入れない場合、システムが動いていても、中身を取り出す鍵を持っていない状態になります。
3. 契約書が見当たらず、成果物の権利関係が曖昧である
IPA（独立行政法人情報処理推進機構）が公開する「情報システム・モデル取引・契約書」（第二版）の契約書本文でも、著作権の帰属については複数の案が示されています（出典：IPA）。
つまり、権利の帰属は契約のひな型でさえ複数案を示すほど、論点になりやすいテーマです。
契約書がなければ、その分だけ権利関係や引き渡し条件を確認しにくくなります。
【Step1】権利関係を棚卸しして「リスト」を作る
ここからが本記事の中核です。
まず、自社の資産が「どこにあり、誰の名義で、どうすれば触れるのか」を一つずつ確認します。
非エンジニアの方でも自力で進められるように解説します。
ドメイン：WHOISで登録情報とネームサーバーを確認する
最初に確認したいのがドメインです。
ドメインの登録情報やネームサーバーなどは、「WHOIS（フーイズ）」という仕組みで照会できます（出典：JPRS）。
.jpドメインであれば、JPRS（日本レジストリサービス）のWHOISで自社のドメイン名を入力するだけで、公開されている範囲の登録情報やネームサーバーを確認できます。
ただし、注意点が2つあります。
1つは、ドメインを実際に管理している「管理指定事業者」の名前は、WHOISには表示されないことです。
事業者の特定には別途の照会や確認が必要です（出典：JPRS）。
もう1つは、移管に関わる期限です。
ドメインの管理事業者を変更するには「AuthCode（認証コード）」が必要で、このコードには有効期限があります。
JPDirectでは、発行後35日以内に移管を完了するよう案内されています（出典：JPRS／JPDirect）。
放置すると再取得が必要になるため、移管を決めたら早めに動きましょう。
サーバー：契約者・データ所在・バックアップの有無を確認する
次にサーバーです。
まず「誰が契約者か」を突き止めます。
手がかりは、過去の請求書、クレジットカードの利用明細、そして制作会社とのメールのやり取りです。
サーバー会社名やサービス名が見つかれば、そこが起点になります。
同時に確認したいのが、バックアップ（データの複製）の有無です。
バックアップがあるかどうかは、復旧できるかどうかを大きく左右します。
IPAの「中小企業の情報セキュリティ対策ガイドライン」第4.0版では、従来の「情報セキュリティ5か条」に「バックアップを取ろう！」が新たに追加され、「情報セキュリティ6か条」となりました（出典：IPA）。
公的なガイドラインでも重視されるほど、バックアップは基盤となる備えです。
現時点で、次の点を必ず確かめておきましょう。
- →バックアップは存在するか
- →どこに保存されているか
- →どの頻度で取得されているか
- →直近のバックアップはいつか
- →実際に復元できる状態か
ソースコードとデータ：確認すべき論点を分けて理解する
ソースコードやデータが「誰のものか」は、非常に気になる点だと思います。
ここは一般論として理解し、個別案件で断定しないでください。
プログラムは「プログラムの著作物」として著作権法上の保護対象になり得ます。
また、従業員が職務として作成したものが法人に帰属する「職務著作（法人著作）」という考え方もあります（出典：文化庁「著作権テキスト」）。
ただし、外部の制作会社に発注した成果物が最終的に誰に帰属するかは、契約内容によって変わります。
契約書に権利の定めがあれば、それを確認する必要があります。
重要なのは、個別の帰属判断を自社だけで結論づけないことです。
契約書の有無や文言によって結論が変わるため、権利関係の判断は弁護士等の専門家に相談してください。
データについても同様です。
データの利用、取り出し、移管、委託先変更の可否は、契約内容や扱っている情報の種類によって変わります。
顧客情報や個人情報を含む場合は、移管先の管理体制も含めて慎重に確認する必要があります。
権利棚卸しの確認リスト
ここまでの確認を、一つのリストに集約しましょう。
資産ごとに「何を確認し、どこに当たり、詰まったら誰に相談するか」を整理します。
ドメイン
契約書がある場合は、登録者名義と更新条件を確認し、WHOISの情報と突き合わせます。
契約書がない、または不明な場合は、WHOISで登録情報とネームサーバーを照会します。管理事業者は別途確認が必要です。
詰まった場合は、ドメイン登録事業者またはJPRS窓口へ相談します。
DNS・メール
契約書がある場合は、DNSの管理者、ネームサーバー、メールの送受信設定を確認します。
契約書がない、または不明な場合は、過去のメール、請求書、管理画面情報から利用中のサービスを特定します。
詰まった場合は、判明したサービス事業者のサポートへ相談します。
サーバー
契約書がある場合は、サーバー会社、契約者、データの所在を確認します。
契約書がない、または不明な場合は、請求書、カード明細、メール履歴から契約先を特定します。
詰まった場合は、判明したサーバー会社のサポートへ相談します。
ソースコード
契約書がある場合は、著作権、納品、保守、再委託に関する条項を確認します。
契約書がない、または不明な場合は、納品物、ソース管理サービス、開発環境の所在を確認します。
詰まった場合は、リプレイスを得意とする会社、もしくは弁護士等の専門家へ相談します。
データ
契約書がある場合は、データ引き渡し、利用、保管に関する条項を確認します。
契約書がない、または不明な場合は、バックアップの有無、保管場所、取り出し方法を確認します。
詰まった場合は、サーバー会社または弁護士等の専門家へ相談します。
外部サービス
決済、フォーム、予約、メール配信、地図、外部連携などの契約を確認します。
契約書がない、または不明な場合は、請求書、利用明細、運用メールから契約先を特定します。
詰まった場合は、各サービス事業者のサポートへ相談します。
【Step2】「引き継ぐ」か「作り直す」かを判断する
Step1の棚卸し結果によって、次に取るべき道は分かれます。
どのような状況でも次の一手が見つかるよう、3つの分岐を確認しましょう。
パターンA：ソースコードもサーバーもアクセスできる
新しい委託先へ「引き継ぐ」道を進められます。
この場合は、新しい委託先への移管を軸に進めます。
ドメインの移管については、前述のJPRSの手順に沿って進めます。
移管作業そのものの技術的な部分は、新しい委託先が対応する範囲です。
パターンB：一部だけアクセスできる
確保できるものから順に、自社の管理下へ移す道です。
たとえば「サーバー契約だけは自社名義だった」というケースがあります。
この場合は、名義が自社にあるもの、失効期限が近いもの、日常業務に直結するものから優先的に確保します。
パターンC：ソースコードや設計書はないが、一次情報が残っている
データベース、現行画面、帳票、メール通知、運用担当者の知識などが残っている場合は、Step3の「作り直す」道を検討できます。
ここで諦める必要はありません。
再構築に必要な手がかりを整理し、仕様を復元していきます。
ただし、ドメイン、DNS、サーバー、データベースへの正当なアクセス権が何もない場合は、先に権利関係とアカウント回復の可能性を整理する必要があります。
画面を再現できることと、過去のデータを移行できることは別の問題です。
【監修・長島より】監修者が経験した実話
私自身、2010年に開発依頼をしていた携帯ブログサービスが、契約書が残っていたにもかかわらず音信不通となり、利用者全員に機能を提供できなくなった経験があります。
当時は解約すらできず、既存サービスを引き継ぐ道もありませんでした。最終的には、新しいシステムを別途つくるという選択しか取れませんでした。
この経験から強く感じたのは、契約書があることだけでは、サービスを守り切れないということです。ドメイン、サーバー、データ、管理アカウントなどを、実際に自社で確認・管理できる状態にしておかなければ、いざという時に動けません。
数多くのご相談をうかがって感じるのは、経営者が本当に失っているのは資産そのものではなく、「打つ手が分からない」という感覚だということです。何が誰のものかを確定させれば、次にどうすべきかは見えてきます。
設計書がなくても、今日も動いているシステムの画面、帳票、データ、運用担当者の知識は、サイトやシステムを再構築のための重要な情報となります。
【Step3】ソースコードも設計書も無くても、作り直せる
「ソースコードも設計書もないなら、すべてをゼロから考え直すしかない」と思われがちです。
実際、この状況では「情報がないので対応できません」と断られることも少なくありません。
しかし、現行システムにデータベース、画面、帳票、ログ、メール通知、運用担当者の知識が残っていれば、再構築に必要な仕様を復元できる場合があります。
たとえば、サーバーにSSHで入れない、ソースコードもない、設計書もない。
その一方で、データベースへの読み取り接続だけは許可されている。
このような権限の制約がある環境でも、調査の起点は残っています。
残っている情報から、仕様を復元していく
現行システムに残っているデータベース、画面、帳票、ログ、メール通知、そして運用担当者の記憶。
これらは、失われた仕様を組み立て直すための手がかりになります。
実際に、情報がほとんどない状態から、稼働を止めずに作り直した事例もあります。
うまくいかない時のつまずきポイントと、よくある質問
Q1. 相手の会社が倒産していた場合はどうすれば？
倒産・破産の手続きは、個別の事情に大きく左右される領域です。
破産管財人への対応などが必要になるため、必ず弁護士等の専門家に相談してください。
なお、契約時にソースコード等を第三者に預けておく「ソフトウェア・エスクロウ」という制度があります。
契約で定めた条件（倒産や保守の不履行など）を満たせば、預けたソースコード等の引き渡しを受けられます（出典：SOFTIC）。
利用の可否や詳細な条件は個別に異なるため、各機関へ確認してください。
裏を返せば、預託していなかった場合は、ソースコードの取得ルートが限られ、交渉や法的な確認が必要になることがあります。
Q2. 契約書が見つかりません。
まずは請求書、メール、稟議書など、周辺の資料から、契約の実態を裏付ける材料を集めましょう。
それらは、ドメインやサーバーの契約先を特定する手がかりになります。
権利の帰属の判断そのものは、集めた資料をもとに弁護士等の専門家に相談してください。
Q3. ドメインの名義が制作会社になっていました。
WHOISで登録情報を確認したうえで、移管できるかどうかと手順を検討します。
.jpドメインなら、AuthCodeを用いた移管手続きがあります（出典：JPRS）。
名義変更に相手方の協力が必要な場合の交渉は、専門家に相談するのが安全です。
Q4. 動いているシステムを止めずに調べられますか？
当社の手法では、データベースへの読み取り接続だけで構造を解析し、稼働を止めずに確認を進められる場合があります。
詳しくは本記事のStep3をご覧ください。
ただし、無停止で調査・移行できるかどうかは、システム構成、権限、データ量、外部連携の有無によって異なります。
Q5. 自分で調べる時間がありません。
日々の業務と並行しての調査は、負担が大きいものです。
何から手をつけるべきかだけでも整理したい場合は、この後の無料現状診断をご検討ください。
費用・期間はどれくらい？
正直にお伝えすると、費用や期間について一律の相場を提示することはできません。
システムの規模、データ量、権利関係の複雑さによって、ケースごとに大きく異なるためです。
案件の条件を確認せずに相場の数値だけを示すと、かえって判断を誤るおそれがあります。
そこで当社では、無料の現状診断で、個別にお見積りの前提を整理しています。
診断では、次のことが分かります。
- →ドメイン・サーバー・ソースコード・データの権利の所在を整理する道筋
- →「引き継ぐ」か「作り直す」かの判断材料
- →情報がない場合でも再構築が可能かどうかを見立て
同じ事態を繰り返さないために
問題が解決したら、再発防止の備えも整えておきましょう。ポイントは3つに絞ります。
1. 権利棚卸しマトリクスを保管し、年に1回見直す
Step1で作った権利棚卸しの記録を保管し、年に1回は見直して最新の状態に保ちましょう。
委託先が変わったとき、ドメインを移管したとき、外部サービスを追加したときにも更新します。
2. バックアップ体制を定期的に確認する
バックアップを取っているだけでなく、保存場所、取得頻度、復元できる状態かどうかまで確認してください（出典：IPA「中小企業の情報セキュリティ対策ガイドライン」第4.0版）。
3. 次の委託契約では、終了時の引き渡しまで確認する
次に開発・制作を委託する際は、契約の時点で次の点を確認する習慣をつけましょう。
- →権利の帰属
- →データの引き渡し
- →管理アカウントの名義
- →バックアップの保管方法
- →保守終了時の対応
- →新しい委託先へ引き継ぐ場合の協力範囲
これらは、システムとサイトの両方を自社の手の中に置き続けるために、最低限整えておきたい備えです。
まとめ：まず「権利の棚卸し」から始めよう
最後に、全体の流れを振り返ります。
Step1：棚卸し
ドメイン、DNS、サーバー、ソースコード、データの権利と所在を確認します。
使うものは、請求書、メール、WHOIS、棚卸しリストです。
詰まった場合は、各事業者の窓口または弁護士等の専門家へ相談します。
Step2：判断
引き継ぐ、一部を確保する、作り直すという選択肢を、Step1の結果から判断します。
新しい委託先や専門家と連携し、優先順位を決めます。
Step3：再構築
設計書がなくても、データベース、現行画面、帳票、担当者へのヒアリングから仕様を復元します。
データベース接続、現行画面、帳票、そしてStep3で触れた「残っている情報から仕様を復元する」進め方を活用し、再構築ができるかどうかを整理します。
最初の一歩は、とてもシンプルです。過去の請求書とメールを探し出し、自社ドメインをWHOISで引いてみること。
そこから、次の一手が見えてくるはずです。
システムが稼働しているうちは、確認・確保できるものが残っています。
落ち着いて、順番に進めていきましょう。
最後に
ワンシックスでは、ドメインの名義・サーバーの名義はクライアントに契約してもらい、権限を絞ってもらいアクセスをしています。
令和では当たり前に近いのですが、平成では開発会社がドメインとサーバーの契約も代行をすることが多かったです。
いま困っている経営者の方へ。もし僕が同じ状況になったら、こう動きます。
まず、ドメインのWHOISを調べる。ネームサーバーを調べる。それでも分からなければ、DNSでどのサーバーかを調べる。
ここで、ドメインのレジストリ、サーバー、CloudFrontを使っているのか、Cloudflareか、国内サーバーか。お名前ドットコムからネームサーバーをCloudflareに向けて、そこからAWSなどの場合も考えて調べます。
まず、ドメインとサーバー。ここを突き止めにいきます。
そして、その後に、ソースコードがウェブ上にない、PCの中にない場合は、過去のサイトをウェブアーカイブで遡る、もしくはAIを活用してプログラミング言語を特定します。
そして、復元するために、全システム・サイトのスクショをとり、ウェブサイトの場合は裏側のHTMLのソースを、業務システムの場合は、表示されている名前・項目・カテゴリをコピーしてテキストに貼り付けておきます。
念のため、Chrome開発ツールのNetworkで、どのAPIを見ているのか、どこを叩いているのかまで全部スクショをとります。
ボタンを押したときに、Network上でレスポンスがどう動いたかも確認します。
そしてウェブサイトの場合、Gtagを利用していて自社提供でなければ、gtagのIDも保存します。
画像の保存先は、S3かR2か、同一ドメインのpublic内にあるのか、CDNなのかも確認します。
その後に、このリストを元に、専門の業者に伝えて相談にのってもらいます。
お伝えしたかったのは、そのくらい徹底的に調べる、リスト化するということです。
不安のまま抱え込まずに、お気軽にご相談ください。
出典・参考資料
- 1.株式会社日本レジストリサービス（JPRS）「WHOISご利用ガイド」 https://jprs.jp/about/dom-search/jprs-whois/whois-guide-check.html
- 2.JPRS「ドメイン名の管理指定事業者の変更」 https://jprs.jp/about/dom-rule/agent-change/index.html
- 1.JPDirect「AuthCodeの発行手順」 https://jpdirect.jp/support/domain/authcode.html
- 2.文化庁「著作権テキスト（令和8年度）〜初めて学ぶ人のために〜」 https://www.bunka.go.jp/seisaku/chosakuken/seidokaisetsu/pdf/94388701_01.pdf
- 3.独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書（第二版）」 https://www.ipa.go.jp/digital/model/model20201222.html
- 4.IPA「中小企業の情報セキュリティ対策ガイドライン」第4.0版 https://www.ipa.go.jp/security/guide/sme/about.html
- 5.一般財団法人ソフトウェア情報センター（SOFTIC）「ソフトウェア・エスクロウ」 https://www.softic.or.jp/index.php/service/escrow/escrow-report
執筆：遠藤葉月
監修：長島弘明