開発会社と完全に連絡が取れなくなった。廃業・音信不通時の放置システム対処法

ある日、社内システムに不具合が出て、いつもの窓口にメールを送った。しかし返信がない。電話をかけても「おかけになった電話番号は現在使われておりません」というアナウンスが流れる。会社のホームページはドメインごと消えている。慌てて契約書を引っ張り出しても、書かれているのはその使われなくなった電話番号とメールアドレスだけ——。

こうした「開発会社と完全に連絡が取れなくなった」という事態は、決して珍しい話ではありません。中小企業のシステム開発を担う会社の中には、数名から十数名規模の小さな会社も多く、代表者の高齢化や後継者不在による廃業、あるいは経営難による事実上の営業停止が起きることがあります。廃業の場合は官報や登記に手がかりが残ることもありますが、より厄介なのは「廃業したのかどうかも分からないまま、ただ連絡が取れない」という宙ぶらりんの状態です。

この記事では、開発会社と連絡が取れなくなったときに、放置されたシステムをどう扱えばよいのかを、次の3つの段階に分けて解説します。

• 状況の確認: 本当に連絡不能なのか、相手の状態(廃業・移転・単なる担当者不在)を一次情報で確認する方法
• 緊急度の切り分け: いますぐ動くべきリスクと、時間をかけて検討してよい課題を仕分ける方法
• 今後の体制づくり: 応急処置のあとに、同じ事態を繰り返さないための引き継ぎ・保守体制の作り方

先に結論を言うと、開発会社が消えたからといって、その日からシステムが即座に止まるわけではありません。多くの業務システムは、開発会社が何もしなくても動き続けます。パニックになって高額な緊急対応を契約してしまう前に、まず「今すぐ困っていることは何か」を冷静に切り分けることが最初の一歩です。

この記事で分かること

開発会社と連絡が取れなくなったときに、感情的にならず順序立てて対応するための考え方と、具体的な確認手順を解説します。相手が本当に廃業したのかを調べる方法、システムが止まる・止まらないの見極め、著作権やソースコードの権利関係の基本的な考え方、そして次に頼れる先の探し方まで、一連の流れをカバーします。

法律に関わる話(著作権、契約不適合責任など)は、e-Gov法令検索で確認できた条文の範囲にとどめ、断定できない部分は「弁護士など専門家に確認すべき」という書き方に統一しています。この記事だけで法的な最終判断をするのではなく、あくまで状況を整理し、次に誰に相談すればよいかを見極めるための地図として使ってください。

まず落ち着く。システムは「即座に」止まらないことが多い

結論から言うと、開発会社と連絡が取れなくなったからといって、動いているシステムがその瞬間に停止するわけではありません。多くの業務システムは、開発会社が保守作業を続けなくても、サーバーやクラウド環境の契約が生きている限りそのまま稼働し続けます。

パニックになりやすい理由は、「保守してくれる人がいない」という不安と、「今すぐ何か起きるかもしれない」という漠然とした恐怖が結びついてしまうからです。しかし実際に緊急対応が必要になるのは、次のようなケースに限られます。

• サーバーやドメイン、SSL証明書の更新期限が近づいており、支払いが止まると停止する
• 目の前で実際にエラーや不具合が発生し、業務が止まっている
• セキュリティ上の重大な脆弱性が既に指摘されている、または悪用の兆候がある

これらに当てはまらない場合、まずやるべきことは「緊急対応」ではなく「現状把握」です。慌てて高額な移行提案に飛びつく前に、次の章から順に状況を整理していきましょう。

焦って高額な「緊急復旧パッケージ」のような契約を即決してしまうのが、この状況で最も避けたい失敗パターンです。相手が本当に信頼できる会社かどうかも含め、一呼吸置いて確認する時間はほとんどの場合、確保できます。

本当に「連絡不能」なのかを一次情報で確認する

「連絡が取れない」と一言でいっても、実際の状態はいくつかのパターンに分かれます。まずどのパターンに該当するのかを、感覚ではなく確認できる情報で切り分けることが重要です。

• 担当者の異動・退職: 会社自体は存続しているが、窓口だった担当者が変わっただけ
• 一時的な人手不足: 小規模な会社で、繁忙期や体調不良などにより対応が滞っている
• 移転・改称: 会社は存続しているが、住所や社名、連絡先が変わっている
• 休眠・実質的な営業停止: 登記上は存続しているが、実態として事業を行っていない
• 廃業(解散・清算): 会社が正式な手続きを経て消滅している、またはその途中にある

このうち最初の3つは、「連絡が取れない」ように見えても解決の糸口が残っているケースです。まずはこれらの可能性を一つずつ潰していきます。

会社の登記情報を確認する

法人であれば、法務局で登記事項証明書(いわゆる登記簿謄本)を取得することで、その会社が現在も存続しているかどうかを確認できます。会社が解散・清算結了している場合は「閉鎖事項証明書」として、その経緯(いつ解散したか、清算結了したか)が記録として残っています。

登記事項証明書は、法務局の窓口・郵送・オンライン請求のいずれの方法でも取得可能です。オンラインで請求すれば、法務局窓口での受け取りで1件あたり数百円程度の手数料で取得できます(手数料は請求方法によって異なります)。取引先の会社が実在するか、どんな状態にあるかを確認する最も確実な一次情報が、この登記情報です。

会社の登記情報の確認方法については、法務局「登記事項証明書（会社・法人）を取得したい方」で案内されています。連絡が取れない状況が続く場合は、まずこのページの案内に沿って登記情報を確認することをおすすめします。

契約書に書かれた情報を洗い直す

契約書や発注書、過去のメールのやり取りには、会社の正式名称・法人番号・登記上の住所が記載されていることが多くあります。ホームページが消えていても、これらの情報から法務局での確認や、後述する代表者個人への連絡につながる手がかりが見つかることがあります。

• 契約書・発注書に記載された会社の正式名称と法人番号
• 過去の請求書・領収書に記載された振込先(金融機関名の変更などから実態が分かる場合がある)
• 名刺に記載されていた代表者や担当者の個人の連絡先(会社の電話が通じなくても、個人の携帯や別のメールアドレスが生きている場合がある)
• 開発時に使っていたチャットツール(Slack、Chatworkなど)のアカウントが今も存在するか

これらを一つずつ確認していくと、「廃業したと思っていたが、実は社名変更しただけだった」「代表者個人には連絡がついた」といった展開になることも珍しくありません。焦って次の手を打つ前に、まずこの棚卸しから始めてください。

なぜ中小規模の開発会社は連絡が取れなくなりやすいのか

背景を知っておくと、目の前の状況を必要以上に特別視せずに済みます。中小企業が発注するシステム開発の委託先には、数名〜十数名規模の小さな会社が選ばれることが少なくありません。小回りが利き、費用感も合いやすいという利点がある一方で、次のような構造的な弱さも抱えています。

• 代表者への依存度が高い: 営業・開発・保守のすべてを代表者や少数の技術者が担っており、その人が体調不良や高齢化で動けなくなると、会社全体の機能が止まりやすい
• 後継者不在: 家族経営や個人事業に近い形態の会社では、代表者引退がそのまま廃業に直結しやすい
• 景気変動への耐性が低い: 大手と違って手元資金の余裕が少なく、受注の波が激しいと資金繰りが急に悪化することがある
• 廃業の告知が徹底されないことがある: 大企業のように広報体制が整っていないため、取引先への個別連絡が漏れる、あるいは連絡先リストの更新が追いつかないまま事業を畳んでしまうことがある

これらは、発注先を選ぶ段階では見えにくいリスクです。だからといって「小規模な会社には発注すべきではない」という話ではありません。小規模だからこそ生まれる柔軟さや、話の早さといった利点もあります。重要なのは、こうした構造的なリスクがあることを理解したうえで、マルチベンダーの発想や、契約時点でのソースコード管理・ドキュメント整備を意識しておくことです。

緊急度を切り分ける。今すぐ困っていることは何か

相手の状態がある程度分かったら、次は「自社が今すぐ困っていることは何か」を切り分けます。開発会社が消えたという事実そのものよりも、それによって具体的に何が止まりうるのかを特定することが、パニックを防ぐ鍵になります。

以下の表のように、リスクの種類ごとに緊急度を整理してみましょう。

特に見落としやすいのが、サーバーやドメインの契約です。これらは開発会社名義で契約されていることがあり、開発会社が消えると更新の請求書が届かなくなり、気づかないうちに支払いが滞って停止してしまうケースがあります。まずはサーバー会社・ドメイン管理会社に直接連絡し、契約者情報と支払い状況を確認することを優先してください。

自社での確認が難しい場合、システム管理台帳が整備されていれば、契約先・ドメイン・サーバーの情報が一覧化されているため、そこから素早く洗い出せます。もし台帳がまだ無ければ、この機会に作成しておくと、次に同じような事態が起きたときの初動が大きく変わります。

ソースコードとデータの権利関係、著作権の基本的な考え方

開発会社と連絡が取れなくなったとき、多くの担当者が気にするのが「このシステムのソースコードは自分たちのものなのか」という点です。ここは法律が関わる領域のため、断定的な言い方を避けつつ、公的に確認できる範囲の基本知識を整理します。

著作権は「作った側」に残るのが原則

著作権法では、プログラムの著作物についても、実際に創作した人(法人の場合はその法人)に著作者としての権利が生じるのが基本的な考え方です。著作権法第15条2項では、法人等の発意に基づきその業務に従事する者が職務上作成したプログラムの著作物は、契約や勤務規則に別段の定めがない限り、その法人が著作者になると定められています。

つまり、発注者である自社が何も契約で定めていなければ、システムの著作権は開発会社側に残っている可能性が高いということになります。「お金を払って作ってもらったのだから、当然自社のものだろう」という思い込みは、契約書に権利の譲渡について明記されていない限り、法的には正しいとは限りません。

さらに、著作権法第61条1項では、著作権を譲渡する契約において翻訳・翻案などの権利(納品物の不具合に関する責任とは別の概念です)が譲渡の対象として明記されていない場合、それらの権利は譲渡した側(開発会社側)に留保されたものと推定する、という規定もあります。つまり「著作権を譲渡する」という一文があるだけでは不十分で、改変や機能追加につながる権利まで明確に契約書へ書き込んでおく必要があるということです。

契約書に著作権の帰属についての条項がなかった、あるいは何が書いてあったか分からない場合は、この記事の解説だけで自己判断せず、契約書の写しを持って弁護士に確認することを強くおすすめします。著作権の帰属は、今後の改修を誰にどう依頼できるかを左右する重要な論点です。

手元にあるシステムを「動かす」ことと「改変する」ことは別問題

著作権法第47条の3には、プログラムの著作物の複製物を持っている(所有している)者が、自分でそのプログラムをコンピュータ上で実行するために必要な範囲で複製できる、という規定があります。これは、既に納品されて自社で運用しているシステムを、これまで通り「動かし続ける」こと自体には、著作権法上の大きな障害がないことを意味します。

一方で、ソースコードを書き換えて機能を追加したり、別の開発会社に改修を依頼したりする行為は、著作権法第27条が定める「翻案権」に関わってくる可能性があります。著作権が開発会社側に残ったままの状態で、無断で改変を進めてしまうと、著作権侵害を指摘されるリスクが理論上は残ります。

ここで実務上重要になるのが、次の2つを分けて考えることです。

1. 今のシステムを、今のまま動かし続けること → 大きな問題になりにくい
2. 別の会社に依頼して改修・機能追加すること → 著作権の帰属次第でグレーになりうる

連絡が取れない状況で2番目を検討する場合は、契約書の内容を確認したうえで、専門家に相談してから動くのが安全です。何も確認せずに新しい開発会社へソースコード一式を渡して改修を依頼してしまうと、後から権利関係のトラブルに発展する可能性があります。

契約不適合責任には期間の制限がある

もう一つ知っておきたいのが、納品されたシステムに不具合があった場合の「契約不適合責任」の期間制限です。民法第566条では、種類・品質に関して契約内容に適合しない目的物が引き渡された場合、買主(発注者)がその不適合を知った時から1年以内に売主(開発会社)へ通知しないと、修補や損害賠償などを請求できなくなる、と定められています(ただし、売主が引渡し時に不適合を知っていた、または重大な過失で知らなかった場合は除きます)。

さらに、民法第166条1項では、債権は権利を行使できることを知った時から5年間、または権利を行使できる時から10年間で時効消滅するという一般原則も定められています。

つまり、「開発会社が連絡不能になったから、今から不具合の責任を追及しよう」と考えても、納品からの経過期間によっては、法的に請求できる期間を過ぎている可能性があります。契約不適合責任を根拠に何かを主張したい場合は、契約書に記載された特約の有無も含め、早い段階で弁護士に相談することをおすすめします。

それでも今のシステムを使い続けられるのか、判断の視点

開発会社が消えても、システムそのものが即座に使えなくなるわけではないことは既に説明した通りです。では、今後どれくらいの期間、今のシステムを使い続けられるのか。この判断には、次の3つの視点が参考になります。

• 技術的な老朽化の度合い: 使われている技術がどれくらい古いか、EOL（サポート終了）を迎えたOSやミドルウェアの上で動いていないか
• 改修の必要性の有無: 法改正や業務変更で、システム側の改修が必要になる予定があるか
• 社内で対応できる範囲: 画面上の設定変更程度は自社で対応できるのか、それともソースコードの修正が必須なのか

これらの視点を使った延命・作り直しの判断基準については、姉妹記事「老朽化した社内システムの「延命 vs 作り直し」判断基準」で詳しく扱っています。開発会社の消滅は、多くの場合「今すぐ作り直すべきかどうか」を検討し直すきっかけになりますが、慌てて結論を出す必要はありません。

一方で、システムの中身が全く分からない状態のまま使い続けることには、別のリスクがあります。仕様書がなく、誰も中身を把握していないシステムを不用意に触ると、思わぬ不具合を引き起こす可能性があるためです。この場合の調査手順は「仕様書がないシステムを引き継いだときの調査手順」で解説している内容がそのまま応用できます。まずは外側から見える範囲(画面・帳票・データの入出力)を確認するところから始めてください。

新しい依頼先を探すときに確認すべきこと

現状把握が終わり、いよいよ別の開発会社や技術者に依頼する段階になったら、次の点を確認しながら進めます。焦って1社だけに話を聞いて即決するのではなく、複数の選択肢を比較検討する余裕を持つことが望ましいです。

• ソースコード一式が手元にあるか: なければ、まずそれがないと何もできないことを前提に相談する
• 著作権・利用権の状況を正直に伝える: 契約書の有無、権利の帰属が不明な点も含めて隠さず共有する
• どこまでを「調査」として発注するか: いきなり改修を依頼するのではなく、まず現状調査だけを発注する選択肢もある
• SOW（作業範囲記述書）を明確にしてもらう: 「調査した上で改めて見積もる」という段階的な進め方を提案してくれる会社は、誠実な対応をしてくれる可能性が高い

いきなり全面刷新を持ちかけてくる会社よりも、まず現状を調査し、延命できる部分とできない部分を切り分けて提案してくれる会社の方が、中立的な判断をしてくれる傾向があります。この段階的なアプローチについては、PoC（概念実証）的に小さく検証してから本格的な依頼に進む考え方が参考になります。

複数の会社に相見積もりを取る際は、「開発会社と連絡が取れなくなった経緯」を正直に伝えることをおすすめします。事情を隠して依頼すると、実際に着手した段階で想定外の追加費用が発生し、トラブルに発展しやすくなります。

廃業が確定していた場合に、実務上できること・できないこと

登記情報の確認により、開発会社が正式に解散・清算結了していたと分かった場合、実務上の対応は「連絡がつかないだけで会社は存続している」場合とは変わってきます。ここでは、廃業が確定した場合に現実的に取りうる選択肢を整理します。

清算人や代表者個人への連絡を試みる

会社が解散していても、清算手続きの過程では「清算人」が選任され、登記情報にその氏名が記載されていることがあります。また、多くの中小企業では代表者が個人事業主に近い形で会社を運営しているため、代表者個人への直接連絡が唯一の手がかりになるケースも少なくありません。

• 登記事項証明書に記載された清算人の氏名を確認する
• 代表者の個人名がSNS(Facebook、X、LinkedInなど)で見つからないか調べる
• 業界団体や同業者のつながりから、代表者の消息を知っている人がいないか当たる

ただし、これらの調査には限界があります。個人情報の取り扱いに配慮しながら、常識の範囲内で行うようにしてください。しつこい接触や、業務と無関係な私的な追跡は避けるべきです。

損害賠償請求などの法的手段は現実的か

「廃業した会社に対して、不具合の責任を追及できないか」と考える担当者もいますが、これは慎重に検討すべき論点です。会社が清算結了している場合、法人格そのものが消滅しているため、通常の方法ではその法人を相手取った請求は困難になります。代表者個人の責任を問えるかどうかは、契約形態や個別の事情によって大きく異なり、一般論で答えられる話ではありません。

廃業した会社への責任追及を検討する場合は、時間と費用をかけてまで請求する価値があるかどうかも含め、まず弁護士に相談することをおすすめします。多くの場合、法的手段よりも「今後どう自社を守るか」に労力を振り向けた方が現実的な着地になります。

システムの継続利用に立ちはだかる壁

廃業が確定していても、著作権法第47条の3で説明した通り、既に納品されたシステムを「今のまま動かし続ける」こと自体に大きな障害はありません。ただし、次のような技術的な壁にぶつかることがあります。

• 開発会社が独自に契約していた外部API・ライセンスが、支払い停止とともに使えなくなる
• ライセンス認証がオンラインでの定期的な通信を必要とし、開発会社側のサーバーが止まると認証エラーになる
• ソースコードの改変履歴やドキュメントが開発会社の社内システムにしかなく、それらへのアクセスが失われている

これらは著作権の問題ではなく、純粋に技術的・契約的な依存関係の問題です。廃業が分かった時点で、まずシステムが依存している外部要素を洗い出しておくことが重要になります。

よくある失敗パターンと避け方

開発会社と連絡が取れなくなった担当者が陥りやすい失敗には、共通するパターンがあります。同じ轍を踏まないよう、代表的な例を挙げておきます。

これらの失敗の多くは、「早く何とかしなければ」という焦りから生まれます。この記事の冒頭でも触れた通り、システムの多くは即座には止まりません。焦りを感じたときこそ、一度立ち止まって状況を整理する時間を意識的に作ってください。

同じ事態を繰り返さないための備え

今回の一件が落ち着いたら、次に同じような状況に陥らないための備えを整えておくことが重要です。特別なシステムや高額なツールは必要なく、以下のような基本的な仕組みを整えるだけで、次に開発会社が連絡不能になっても慌てずに済みます。

1. システム管理台帳の整備: どのシステムを、どの会社が、どんな契約で保守しているかを一覧化する
2. 契約書の保管場所を明確にする: 誰が異動・退職しても、契約書の所在が分かる状態にしておく
3. サーバー・ドメインの契約者名義を確認する: 開発会社名義になっている場合、自社名義への変更を検討する
4. ソースコード一式の定期的な受領: 保守契約の中に、最新版ソースコードの提供を含める
5. 複数の連絡手段を記録しておく: 会社の代表電話だけでなく、担当者個人の連絡先も可能な範囲で控えておく

これらは、開発会社との関係が良好なうちにこそ整えやすいものです。「今の担当者と連絡が取れているから大丈夫」と考えず、関係が良好なタイミングで台帳の整備や契約内容の見直しを進めておくことが、結果的に自社を守ることにつながります。

属人化した管理を防ぐ台帳の具体的な作り方については、「属人化を防ぐ社内システム管理台帳の作り方」で詳しく解説しています。まだ台帳を作っていない場合は、今回の経験を機に着手することをおすすめします。

まとめ

開発会社と連絡が取れなくなるという事態は、担当者にとって大きな不安を伴いますが、パニックになって高額な緊急対応に飛びつく必要はありません。まずは次の順序で対応することを覚えておいてください。

• 相手の状態(存続・移転・廃業)を、登記情報や契約書などの一次情報で確認する
• 今すぐ困っていること(契約更新の期限、実際に起きている不具合)を切り分ける
• 著作権や契約不適合責任など、法的な論点は自己判断せず専門家に確認する
• 今のシステムを使い続けられるかどうかを、延命・作り直しの視点で検討する
• 次の依頼先には段階的な調査から発注し、いきなり全面改修に飛びつかない
• 落ち着いたら、二度と同じ状況で慌てないための台帳・契約整備を進める

開発会社が消えたという事実は変えられませんが、そこから先にどう動くかは、順序立てて考えれば決して手に負えない話ではありません。次は、今回整理した「今すぐの緊急度」を踏まえたうえで、老朽化したシステムをどう扱うかの判断基準に進んでみてください。