昔の開発会社が倒産していた。ソースコードがない場合の選択肢

法務局で登記事項証明書を取ったら、「閉鎖事項証明書」という見慣れない書類が出てきた。担当していた開発会社は、もう存在していなかった——。連絡が取れないだけならまだ望みがありますが、倒産・清算が事実として確定してしまうと、状況はもう一段階厳しくなります。契約の相手方がいない、督促する先がない、そして何より、ソースコード一式の引き渡しを一度も受けていないまま今日を迎えている。この記事は、そういう「詰んだように見える」状態から、実際に何ができて何ができないのかを一つずつ切り分けるために書きました。

先に結論を言うと、ソースコードがなくても、多くの場合システムは今のまま動き続けられますし、改修や移行を諦める必要もありません。ただし「今のシステムをそのまま直す」という選択肢は現実的に狭まっており、「動いているものから調べ直す」「作り直す」という方向に舵を切る判断が早晩必要になります。この記事では、倒産という事実確認の手順、著作権の帰属という誤解されやすい論点、そして倒産という後戻りできない前提の上でどう次の一手を選ぶかを、順を追って整理します。

なお、この記事は「開発会社と連絡が取れないが、まだ廃業・倒産したかどうか分からない」という段階の対処法とは別の記事です。相手が本当に存在しなくなったことを確認した後の話として読んでください。連絡が取れないだけの段階の方は、属人化した状態からの初動を扱う記事を先にご覧いただくほうが状況に合っています。

この記事の前提となる状況

まず、この記事が想定している状況を明確にしておきます。次の3つがすべて当てはまる場合、この記事の内容がそのまま役立ちます。

• 開発会社の倒産・破産・清算結了が、登記や官報などの記録で事実として確認できている、またはほぼ確実な状況にある
• 納品されたシステムのソースコード一式（プログラムのソースファイル、設計書、データベース定義など）の引き渡しを、契約時にも運用中にも一度も受けていない
• 現在システムは動いているが、改修・移行・不具合対応のいずれかで「中身を触る」必要が出てきている

逆に、まだ相手の生死が分からない段階であれば、慌てて「作り直し」に踏み切る前に、まず相手の状況を確認するところから始めるべきです。倒産していると思い込んでいたら実は代表者が引っ越しただけだった、というケースも実務上はあり得ます。事実確認の具体的な手順（登記事項証明書の取得方法など）は、後述の「倒産の事実をどう確認するか」の章で改めて解説しますが、まだ確認が済んでいない方は先にそちらを実施してください。

ソースコードがなくてもシステムはなぜ動き続けるのか

まず安心していただきたいのは、ソースコードが手元になくても、システムそのものはすぐには止まらないという点です。ソースコードとは、人間が読み書きできる形でプログラムの処理内容を記述したテキストファイル一式のことで、これをコンピュータが実行できる形式（実行ファイル）に変換したものが、実際にサーバー上で稼働しています。

つまり、稼働中のシステムは「変換済みの完成品」がサーバー上に置かれて動いている状態であり、その元になった設計図（ソースコード）が手元にあるかどうかは、稼働の継続そのものには直接関係しません。サーバーやクラウドの利用契約が継続していて、ドメインの契約も切れていなければ、開発会社が消滅した後もシステムは何事もなく動き続けます。

問題が表面化するのは、次のようなタイミングに限られます。

• 何らかの不具合が発生し、原因を特定して直す必要が出てきたとき
• 法改正・税制改正・OSやミドルウェアのEOL（サポート終了）対応など、外部要因で改修が避けられなくなったとき
• 事業拡大や業務フローの変更で、機能追加・仕様変更が必要になったとき
• サーバーやドメインの契約更新期限が近づいているのに、更新作業をする担当者が誰もいないとき

逆に言えば、これらのいずれにも当面直面しないのであれば、今すぐ何かを決断する必要はありません。まずは「今のシステムに何を求めているのか」「いつまでに何をしなければならないのか」を落ち着いて棚卸しすることが、最初の一歩になります。

焦って高額な「緊急対応」を謳う業者に飛びつく前に、まず自社が本当に緊急事態にあるのかどうかを見極めてください。ソースコードがない状態そのものは不便ですが、それ単体で今日明日にシステムが停止する理由にはなりません。

倒産の事実をどう確認するか

「倒産したらしい」という情報が噂や又聞きの場合、まず一次情報で事実を確認する必要があります。法人の存続状況は法務局で誰でも確認できます。

法人であれば、法務局で登記事項証明書を取得することで、その会社が現在も法人格を保っているかどうかを確認できます。すでに解散・清算結了している場合は、通常の登記事項証明書ではなく「閉鎖事項証明書」として、解散の経緯（破産・特別清算・通常清算など）や日付が記録として残っています。取得方法は法務局の窓口、郵送請求、オンライン請求（登記・供託オンライン申請システム）のいずれでも可能で、契約書に記載された会社の正式名称や法人番号を手がかりに調べられます。

倒産にはいくつかの法的な手続きの種類があり、それぞれ意味が異なります。

法的にどの手続きを経ているかによって、「誰に連絡すれば資産（ソースコード等）の所在を確認できるか」という窓口が変わってきます。破産法第78条1項は「破産手続開始の決定があった場合には、破産財団に属する財産の管理及び処分をする権利は、裁判所が選任した破産管財人に専属する」と定めています。つまり破産手続きが開始された会社については、代表者個人ではなく、選任された破産管財人が資産の管理処分権を持つことになります。もし破産管財人が選任されている場合は、その管財人にソースコード等のデータ資産の所在を照会できる可能性がありますが、この照会や交渉には専門的な判断が必要になるため、次章で触れる著作権の扱いとあわせて弁護士に相談することをおすすめします。

ソースコードの著作権は誰のものか、という誤解

「お金を払って発注したのだから、ソースコードの著作権は当然自社のものだろう」という考え方は、実務上は誤解であることが多いです。契約書で著作権の譲渡について明記されていない限り、システムを開発した会社側（あるいはその会社が消滅した今は、その資産を承継した側）に著作権が残っている可能性が高くなります。

著作権法第15条2項は、プログラムの著作物について次のように定めています。

法人等の発意に基づきその法人等の業務に従事する者が職務上作成するプログラムの著作物の著作者は、その作成の時における契約、勤務規則その他に別段の定めがない限り、その法人等とする。

これは、開発会社の従業員が業務としてプログラムを書いた場合、特段の定めがなければその著作者（＝著作権者）は開発会社になる、という規定です。発注者である自社ではありません。請負契約や準委任契約の中で「納品物の著作権は発注者に譲渡する」という条項が明記されていれば話は別ですが、そうした条項がない古い契約書は珍しくありません。

ここで注意したいのは、著作権が開発会社側にあるからといって、「今のシステムをそのまま動かし続けること」自体が違法になるわけではないという点です。すでに納品を受けて利用している範囲であれば、通常は利用許諾の範囲内と考えられます。問題になり得るのは、次のような行為です。

• ソースコードを改変して機能追加・修正を行う（改変権に関わる）
• 別の開発会社にソースコードを渡して改修を依頼する（複製・提供に関わる）
• システムを丸ごとコピーして別の環境に展開する

著作権法第47条の3第1項は「プログラムの著作物の複製物の所有者は、自ら当該著作物を電子計算機において実行するために必要と認められる限度において、当該著作物を複製することができる」と定めていますが、これはあくまで「実行するために必要な複製」を許容する規定であり、改変や第三者への提供までを無条件に認めるものではありません。

ソースコードが手元にない今回のケースでは、そもそも改変しようにも改変の対象となるソースコード自体が存在しないため、著作権侵害の心配をする以前の技術的な壁の方が大きい、というのが実態です。とはいえ、開発会社が破産等で消滅している場合、その著作権（資産）が破産財団の一部として扱われ、最終的にどこに帰属するのかは個別の事情によって変わります。改修や移行の方針を決める前に、契約書の内容を確認したうえで、著作権の扱いについては弁護士に相談することを強くおすすめします。

「取り戻せないか」を先に検討する価値はあるか

3つの選択肢の話に入る前に、多くの担当者が最初に考える「どうにかしてソースコードそのものを取り戻せないか」という道について触れておきます。結論としては、可能性はゼロではありませんが、期待しすぎない方がよいというのが実情です。

考えられる取り戻し方としては、次のようなものがあります。

• 破産管財人への照会: 破産手続きが開始されている場合、前述のとおり資産の管理処分権は破産管財人に移っています。もし開発会社のサーバーやパソコン、外部ストレージなどにソースコードが物理的に残っていれば、破産財団の一部として扱われている可能性があります。ただし、破産管財人はあくまで債権者への配当を最大化する立場で動くため、無償での引き渡しに簡単には応じてもらえない場合があります。また、そもそもデータが破棄・消去されていれば取り戻しようがありません
• 元従業員・元代表者への照会: 個人的なつながりがあれば、元従業員が個人所有のパソコンやクラウドストレージにバックアップを残していないか尋ねてみる価値はあります。ただし、これは相手の善意に頼る方法であり、確実性はありません。連絡先が分かる場合は試す価値がありますが、それだけを頼りに計画を立てるのは避けるべきです
• 契約時の再委託先・協力会社への照会: システム開発の一部を別の会社（協力会社）に再委託していた場合、その協力会社側にソースコードの控えが残っている可能性があります。契約書や請求書に協力会社の名前が記載されていないか確認してみましょう

いずれの方法も「当たれば儲けもの」程度の位置づけで臨むのが現実的です。数週間から数ヶ月かけて交渉した結果、結局見つからなかったというケースは珍しくありません。並行して次章の「調査して進める」前提の準備も進めておくことをおすすめします。

特に破産管財人への照会は、法的な立場を踏まえた交渉が必要になる場面です。管財人は多数の債権者・利害関係人とやり取りをしている最中であることが多く、素人判断で連絡すると話がこじれることもあります。この交渉に踏み切る前には、弁護士に相談し、進め方を整理してから動くことをおすすめします。

ソースコードがない状態で改修・移行するための3つの選択肢

事実確認と権利関係の整理がついたら、次はいよいよ「実際にどう進めるか」です。ソースコードがない状態での対応は、大きく3つの方向性に分かれます。それぞれのメリット・デメリットを比較します。

選択肢1: 動いているものから調べ直す

稼働中のシステムを外部から観察し、画面遷移・入出力・データベースの構造・外部連携の有無などを一つずつ調査して、仕様を逆算的に把握していくアプローチです。ソースコードそのものは手に入りませんが、「何が」「どう動いているか」という仕様レベルの理解を取り戻すことはできます。

この調査には、ある程度の技術的な知見が必要になりますが、必ずしも元の開発会社でなければできない作業ではありません。データベースへの直接アクセス権限（管理者アカウント）さえ確保できれば、外部の開発会社に調査を依頼することも可能です。調査の具体的な進め方は、仕様書が一切ない状態からの調査手順を解説した記事で6段階に分けて詳しく解説していますので、そちらもあわせてご確認ください。

ただし、この方法で分かるのは「今どう動いているか」までで、「なぜそう作られたのか」という設計判断の背景までは分かりません。軽微な不具合修正や、影響範囲の小さい機能追加には有効ですが、大規模な改修には向きません。

選択肢2: 実行ファイルのまま最小限の延命措置をとる

システムの中身に手を入れず、稼働環境（サーバー、OS、ミドルウェア）だけを維持・更新して、現状のまま動かし続けるアプローチです。ソースコードがなくても、実行環境さえ保守できれば、システムの機能自体はそのまま使い続けられます。

この方法は初期費用を抑えられる一方で、次のような制約があります。

• OSやミドルウェアがサポート終了（EOL）を迎えた場合、システムを新しい環境に移行できないため、セキュリティリスクを抱えたまま使い続けることになりやすい
• 機能追加や仕様変更が一切できない（中身に触れないため）
• サーバーが故障した場合、代替機への移行そのものが困難になる可能性がある

延命措置は「時間を稼ぐ」ための一時的な手段と位置づけ、並行して次の選択肢（作り直し）の検討を進めておくことをおすすめします。老朽化したシステムをいつまで延命させ、いつ作り直すべきかの判断基準は、TCO（総保有コスト）や技術的負債という観点から別の記事で詳しく整理しています。

選択肢3: 仕様を整理した上で作り直す

もっとも根本的な解決策は、選択肢1の調査で洗い出した仕様をベースに、新しい開発会社へフルスクラッチ開発開発、あるいはパッケージ・ノーコード・ローコードツールへの置き換えを依頼することです。ソースコードという「過去の資産」に縛られず、現在の業務に合った形でゼロから設計し直せるという利点があります。

一方で、当然ながら費用と時間がかかります。特に「今動いているシステムが何をしているか」の調査（選択肢1）を十分に行わずに作り直しに着手すると、既存システムが担っていた重要な業務ルールや例外処理を見落とし、移行後に「前はできていたことができなくなった」というトラブルが起きがちです。作り直しを決める場合でも、調査工程を省略しないことが成功の分かれ目になります。

3つの選択肢を整理すると、以下のようになります。

調査を外部の開発会社に依頼するときの進め方

選択肢1（調査）や選択肢3（作り直し）を選ぶ場合、多くの担当者は「元の開発会社以外に、こんな面倒な調査を引き受けてくれる会社があるのだろうか」と不安に感じます。結論から言うと、ソースコードなしでの調査・改修・作り直しは、決して珍しい依頼ではありません。ただし、依頼する側が準備しておくべきことと、開発会社選びで確認すべきポイントがあります。

まず準備しておくべきものは次のとおりです。

• 管理者権限でのログイン情報: サーバー、データベース、管理画面などにアクセスできるアカウントとパスワード。これがなければ調査自体が始められません。パスワードが分からない場合は、先にその復旧から着手する必要があります
• 契約書一式: 元の開発会社との契約書、見積書、仕様書（残っていれば断片でも構いません）。著作権の扱いを確認する材料になります
• 業務フローの分かる資料や、実際にシステムを使っている担当者への聞き取り時間: システムの中身が分からなくても、「これで何をしているか」を業務側の人間が説明できれば、調査の助けになります

依頼先の開発会社を選ぶ際は、次の点を見積もり段階で確認しておくとミスマッチを防げます。

1. ソースコードがない前提での調査経験があるか（初めて聞かれて戸惑うようであれば、別の会社も検討する）
2. 調査フェーズと改修・作り直しフェーズを分けて見積もってもらえるか（調査だけ先に依頼し、結果を見てから次を判断できると、リスクを抑えられます）
3. 調査・開発の過程で作成される新しい資料（画面設計書・データベース定義書など）を、今後は自社が保有できる形で納品してもらえるか

いきなり「作り直し」の大きな契約を結ぶのではなく、まずは調査だけを小さく発注し、状況を正確に把握してから次のステップの予算感を固める進め方が、リスクを抑える上で現実的です。

開発会社選びで同じ失敗を繰り返さないために

作り直し、あるいは調査を依頼する開発会社を選ぶ段階になったら、今回のような事態を二度と招かないための契約上の取り決めを、最初から盛り込んでおくことが重要です。今回の教訓を踏まえると、少なくとも次の3点は契約前に確認・交渉すべきポイントです。

1. ソースコード・設計書一式の引き渡し時期と方法を契約書に明記する。「納品時に引き渡す」だけでなく、保守契約中も最新版が定期的に共有される取り決めにしておくと安心です
2. SOW（作業範囲記述書）（作業範囲記述書）や見積もりの中に、成果物としてソースコードが明示的に含まれているかを確認する。口頭やメールでの「もちろんお渡しします」ではなく、書面に残す形にします
3. 著作権の帰属・譲渡について契約書で明確にする。特に理由がない限り、納品物の著作権は発注者に譲渡される条項を入れてもらうよう交渉するのが一般的です

これらは、発注時のRFP（提案依頼書）や見積もり比較の段階から意識しておくべき論点です。今回のような「倒産して連絡が取れない」という事態そのものを完全に予測することはできませんが、契約書にソースコードの引き渡し条項さえあれば、少なくとも「引き渡しを受けていない」という状態そのものを避けられた可能性があります。

また、今後は特定の1社に開発・保守を集中させず、ベンダーロックインを避ける体制を検討することも有効です。ソースコードや設計資料を自社側でも常に把握・保管しておく運用にしておけば、たとえ委託先に何かあっても、業務への影響を最小限に抑えられます。

契約時点では「まさか倒産するとは」と考えるのは難しいものです。だからこそ、性善説に頼らず、引き渡し条項を機械的に契約書へ盛り込む運用を、社内のルールとして定着させておくことをおすすめします。

ソースコードと合わせてデータのバックアップ状況も確認する

ソースコードがないという事実に気を取られがちですが、忘れてはいけないのが、システムに蓄積された「データそのもの」の保全です。ソースコードは失われていても、業務で日々入力してきた顧客データや取引履歴といったデータベースの中身は、また別の話です。

まず確認すべきは、次の2点です。

• 現在稼働しているデータベースから、データを自社側でエクスポート（CSV等の形式で取り出すこと）できる権限があるか
• 過去のバックアップ（開発会社側が取得していたものを含む）がどこかに残っていないか

もし管理者権限があれば、システムの中身に手を入れなくても、データそのものは今のうちに自社側へバックアップを取っておくことを強くおすすめします。仮に選択肢3（作り直し）を選ぶ場合、既存データの移行が新システムへの引き継ぎで最も重要な工程になりますが、稼働中のシステムからデータを抜き出せる状態を保っておけば、ソースコードがなくてもデータ移行自体は十分に実現可能です。

逆に、稼働環境のサーバーが老朽化していたり、契約更新が近い場合は、データを失う前にバックアップを最優先で確保してください。ソースコードは後からでも「調査」という形で仕様を復元できますが、蓄積されたデータそのものは一度失うと二度と戻りません。バックアップの基本的な設計（3-2-1ルール（バックアップ）など）については、別記事で詳しく解説しています。

今後同じ状況に陥らないための備え

システムの再構築や延命措置と並行して、社内の管理体制も見直しておくべきタイミングです。今回、ソースコードの引き渡しを受けていなかったこと自体が、担当者個人の落ち度というより、会社としてシステムの管理台帳や契約書を体系的に保管する仕組みがなかったことに起因している場合が多くあります。

社内で稼働しているシステムの名称、委託先、契約内容、そして納品物（ソースコード・設計書を含む）の保管場所を一覧化したシステム管理台帳を整備しておくと、次に同じような事態が起きたときに、初動が大きく変わります。台帳があれば「そもそも契約書にソースコードの引き渡し条項があったかどうか」を確認するだけで済み、今回のように事実確認から始める必要がなくなります。

台帳整備は地味な作業に見えますが、次のような最小限の項目から始めれば十分です。

• システム名・利用目的
• 委託先の会社名・法人番号・連絡先
• 契約書の保管場所（原本・PDFへのリンク等）
• ソースコード・設計書の保管有無と保管場所
• サーバー・ドメイン・SaaSアカウントの契約情報と更新期限

一度に全社のシステムを網羅する必要はありません。まずは今回問題になったシステムの記録を残すところから始め、余力ができたら他のシステムにも広げていく進め方で構いません。

誰に相談すればよいか、窓口を整理する

ここまで弁護士への相談を繰り返し勧めてきましたが、「弁護士といっても誰に、どう相談すればいいのか分からない」という声もよく聞きます。最後に、状況ごとの相談窓口を整理しておきます。

弁護士に相談する際は、契約書一式・登記事項証明書（取得済みであれば）・現在困っている具体的な事象（不具合の内容や更新期限など）をまとめて持参すると、相談がスムーズに進みます。多くの弁護士事務所は初回相談を無料または低額で受け付けているため、「まずは著作権の扱いだけ確認したい」という軽い相談から始めても問題ありません。

一点注意したいのは、法律相談と技術調査は別物だという点です。弁護士に「システムをどう直せばいいか」を聞いても技術的な回答は得られませんし、開発会社に「著作権は誰のものか」を聞いても正式な法的見解にはなりません。それぞれ適切な窓口に、適切な内容を持ち込むことを意識してください。

まとめ

開発会社の倒産が確定し、ソースコードもない、という状況は精神的に厳しいものですが、対処不能というわけではありません。この記事で整理した内容を、もう一度手順として振り返ります。

1. まず倒産の事実を、登記事項証明書・閉鎖事項証明書など一次情報で確認する
2. システムは多くの場合すぐには止まらないため、緊急度を冷静に切り分ける
3. ソースコードの著作権は開発会社側にある可能性が高いことを理解し、改変・第三者への提供を検討する段階で弁護士に相談する
4. 「調査して直す」「延命する」「作り直す」の3つの選択肢を、緊急度と予算に応じて選ぶ
5. 次の契約では、ソースコード引き渡し条項を必ず盛り込み、社内の管理台帳を整備する

一つ一つは地道な作業ですが、順序立てて進めれば、必ず着地点は見えてきます。次にご紹介する記事もあわせてご覧いただくと、今回のケースへの理解がさらに深まります。