情報サービス業の倒産166件で過去10年最多｜委託先が消えても自社システムを守る契約防衛チェックリスト

結論から書く。東京商工リサーチが2026年7月14日に公表した集計によると、2026年上半期（1〜6月）の情報サービス業の倒産は166件で、前年同期比18.5%増、過去10年で最多を更新した。そして、その内訳が重要だ。負債1億円未満が147件（構成比88.5%）、従業員5人未満が135件（同81.3%）。つまり、いま倒れているのは大手SIerではない。中小企業が「安くて融通が利くから」という理由で開発・保守を任せている、社長を含めて数人の零細ベンダーそのものである。

年商1〜10億円規模の会社の基幹業務システム、受発注管理、ECサイト、勤怠・給与連携の仕組みは、こうした小さな開発会社が支えているケースが非常に多い。委託先がある日突然消えたとき、あなたの会社のシステムは動き続けるのか。ソースコードは手元にあるのか。サーバーの契約名義は誰か。ドメインの更新は誰が止めるのか。この問いに即答できない会社は、166件という数字を「業界の話」ではなく「自社の話」として読むべきだ。

本記事は、倒産の予測でも業界動向の解説でもなく、「委託先が消えても自社のシステムと事業を守れる状態を、今の契約と今の資産管理で作れているか」を点検するための実務記事である。事前確認の10項目、契約に欠けがちな条項、危険シグナルの見抜き方、実際に倒産が起きたときの初動までを、強い情シス部門を持たない経営者・決裁者向けに順番に整理する。なお、倒産発生後の30日間の対応タイムラインやSaaS利用時のデータ救出手順は、既に公開しているベンダー倒産に備える事業継続計画の記事で詳述しているため、本稿は「倒産が起きる前の契約と資産の防衛」に焦点を絞る。

この記事を読むべき人

• 開発・保守を任せている会社の規模を正確に把握していない経営者。担当者の顔は知っているが、その会社の従業員数や財務状況は見たことがない、という状態なら該当する
• 「保守料が安いから」という理由で10年来同じ小規模ベンダーに依存しており、契約書を最後に読んだのがいつか思い出せない会社
• システムのソースコード、設計書、サーバーやドメインの契約名義が自社と委託先のどちらにあるか、今この場で答えられない決裁者
• 委託先の担当者が最近立て続けに辞めた、返信が遅くなった、という違和感を抱えている管理部門
• 新規開発や刷新の見積もりを取っている最中で、これから契約書を交わす段階にある会社。契約前のいまが、本記事の条項リストが最も安く効くタイミングだ

2026年上半期の倒産統計を数字で確認する

まず一次情報を正確に押さえる。以下は東京商工リサーチ公表データ（2026年7月14日）の要点である。

この表から読み取るべきことは3つある。

第一に、増加が小規模層に集中しているという点だ。負債1億円以上の倒産は19件で前年同期比5.0%減、従業員10人以上20人未満・20人以上50人未満の区分も減少している一方、5人未満は25.0%増、5人以上10人未満も10.0%増、資本金1千万円未満は21.5%増だ。業界全体が一様に沈んでいるのではなく、逆風は明確に小規模の側に偏っている。あなたの委託先が従業員数人の会社なら、その会社は統計上、まさに直撃を受けている層にいる。

第二に、形態の97.6%（166件中162件）が破産だという点である。破産は民事再生や事業譲渡と違い、事業が原則としてそのまま消滅する。誰かが顧客とシステムを引き継いでくれる展開は期待できず、ある日を境に連絡窓口が消え、以後の窓口は破産管財人になる。「潰れても誰かが引き継ぐだろう」という楽観は、この統計の前では成立しない。

第三に、倒産はフローの一部にすぎないという点だ。2025年通年では、倒産276件に対して休廃業・解散が3,014件。合算3,290件は前年比20.8%増である。休廃業は法的手続きを踏まない静かな撤退で、ニュースにもならない。少なくとも2025年の実績では、委託先が「倒産はしていないが、静かに市場から退出する」件数が、統計に表れる倒産件数の10倍を超えていた。なお東京商工リサーチの倒産統計は負債1,000万円以上が対象であり、休廃業・解散にはこの下限がない点は割り引く必要があるが、法的倒産だけを見ていると撤退の全体像を大きく見誤る、という結論は変わらない。

なぜ零細ベンダーに倒産が集中するのか：構造を理解する

東京商工リサーチは、ノーコード・ローコードツールや生成AIの普及による内製化の進展と価格競争が、小規模事業者に逆風となっていると分析している。この分析を、発注者側の目線で構造に分解しておきたい。なぜなら、構造が分かれば「自社の委託先が危ないかどうか」を財務諸表なしでもある程度推定できるからだ。

零細ITベンダーの多くは、次の3つの条件のうち複数を抱えている。

1つ目は、価格以外の差別化要素がないこと。 従業員数人の受託開発会社の売り物は、突き詰めれば「大手より安い工数単価」である。ところが、簡単な業務アプリやWebサイトはノーコードツールと生成AIで発注者自身が作れる時代になり、「安く作る」という価値そのものが浸食されている。単価を下げて対抗すれば利益が消え、下げなければ案件が消える。どちらに転んでも資金繰りが細る。

2つ目は、少数の顧客と少数の技術者への極端な依存だ。 5人未満の会社では、売上の大半を2〜3社の継続保守が占め、技術の中身を1〜2人のエンジニアが握っていることが珍しくない。主要顧客が1社離れる、あるいはエンジニアが1人辞めるだけで、事業の継続性が崩れる。発注者から見れば、これは「自社システムの知識が、他社のたった1人の頭の中にしかない」という状態と同義である。

3つ目は、多重下請け構造の末端に位置していることだ。 元請けの発注量や単価の調整が、そのまま末端の売上に直撃する。生成AIによる開発効率化で元請けが内製・省力化を進めるほど、末端に流れる仕事は減る。なお倒産の63.2%（105件）は関東に集中しているが、これは情報サービス業の事業所自体が首都圏に偏在していることも大きく、地域固有の要因と断定はできない。

ここで強調したいのは、これらの構造は発注者にとって「安さ」の源泉だったものと同じだという点である。少人数だから安い。専属に近い形で面倒を見てくれるから融通が利く。下請け経験が長いから言い値で受けてくれる。つまり、あなたの会社がその委託先を選んだ理由そのものが、その委託先の倒産リスクの源泉なのだ。委託先を責める話ではない。「安くて融通の利く零細ベンダーに任せる」という合理的な選択には、倒産リスクという見えない対価が最初から含まれており、その対価を契約と資産管理で中和するのは発注者側の仕事である——これが本記事の中心的な主張だ。

委託先が消える前に確認する10項目：自社システムの「資産台帳」を作る

では何を点検するか。倒産対応の実務で最初に問題になるのは、契約書の条文よりも先に「そもそも自社が何を持っていて、何を持っていないか」である。以下の10項目を、システムごとに一覧表にして埋めてほしい。埋められない欄が、そのまま倒産時に事業が止まる箇所になる。

1. ソースコードの所在と取得可否：最新版のソースコードが自社の手元（自社管理のリポジトリやストレージ）にあるか。ベンダーのGitHubアカウントやベンダー所有のサーバーにしかない場合、倒産と同時にアクセス手段を失う可能性がある。「納品時にCD-Rでもらった」は最新版とは限らない。保守で改修が続いているなら、手元のコードは何年も前のものだ。
2. 設計書・仕様書・運用手順書の有無と鮮度：別のベンダーが引き継ぐには、コードだけでなく「なぜそう作ったか」「どう運用するか」の文書が要る。文書が存在しない、または初期構築時のまま更新されていない場合、引き継ぎ工数とコストは跳ね上がる。
3. 実行環境の契約名義：システムが動いているサーバー（クラウド含む）の契約者は自社かベンダーか。ベンダー名義の場合、倒産すれば利用料の支払いが止まり、環境ごと消える。破産手続の中で管財人が契約を解除すれば、猶予はさらに短くなる。
4. ドメインとSSL証明書の名義・管理画面：自社サイトやシステムのドメインがベンダー名義で登録されているケースは、いまだに多い。名義がベンダーなら、更新失念や登録業者との契約失効でドメインを失い、最悪の場合は第三者に取得される。証明書の期限と更新主体も同様に確認する。
5. ライセンスとアカウントの名義：OS、データベース、ミドルウェア、外部SaaS、決済や地図などのAPIキーが誰の名義・誰の支払いで契約されているか。ベンダーの包括ライセンスに相乗りしている場合、倒産と同時に自社の利用権も宙に浮く。
6. 管理者権限の保有状況：本番サーバー、DNS、クラウドコンソール、CMS、データベースの管理者権限を自社が保有しているか。「作業はすべてベンダーがやるので自社にはアカウントがない」という状態は、平時は楽だが、有事にはシステムに入る手段がないことを意味する。
7. データのバックアップを自社で取得できるか：顧客データ・取引データを、ベンダーの手を借りずに自社だけでエクスポートできるか。手順を知っているか。一度も試したことがないなら、それは「できない」と同じである。
8. 再委託の構造：実際に手を動かしているのは契約相手か、それともさらに下請けのフリーランスや外注先か。契約相手が営業と窓口だけで、実装は外部の個人という構造なら、契約相手の倒産以前に「その個人が離れた時点」でシステムはブラックボックス化する。
9. 保守の属人性：自社システムの中身を説明できる人間が、ベンダー側に何人いるか。担当者1人なら、その人の退職は会社の倒産と同じ効果を持つ。訪問時や定例の場で「私が倒れたら誰が対応できますか」と直接聞いてよい質問だ。
10. 契約書の終了時条項の有無：契約書に「契約終了時に何を引き渡すか」を定めた条文があるか。そもそも契約書がどこにあるか。保守契約が自動更新を繰り返して原本が行方不明、という会社は珍しくない。まず探すところから始める。

この10項目は、1システムあたり半日もあれば埋められる。外部の専門家も高額なツールも要らない。それでいて、埋める過程で「うちはソースコードを持っていなかった」「ドメインがベンダー名義だった」という発見が高い確率で出てくる。倒産統計への正しい反応は、不安になることではなく、この表を埋めることだ。

作った表は、作りっぱなしにしないことも重要だ。管理の責任者を一人決め、契約更新のタイミングと年1回の定期点検で更新する。強い情シスがいない会社なら、総務や経理の責任者で構わない。この表が要求する能力は技術力ではなく、名義と所在を確認し続ける事務能力だからだ。逆に、責任者を決めずに経営者の頭の中だけで済ませると、点検した事実そのものが数年で失われ、担当交代のたびに振り出しに戻る。ベンダーの属人性を問題にする以上、自社側の点検も属人化させてはいけない。

今の契約に何が欠けているか：入れるべき条項リスト

資産台帳で「持っていないもの」が見えたら、次はそれを契約で担保する。零細ベンダーとの契約書は、ベンダー側の雛形をそのまま使っていることが多く、発注者を守る条項は入っていないのが普通である。次回の契約更新時に、以下の観点で追記・修正を申し入れたい。

成果物の引き渡しと権利の帰属。 開発したプログラムの著作権が発注者とベンダーのどちらに帰属するか、そして権利帰属とは別に「最新のソースコード・設計書一式を、契約終了時および発注者の求めに応じて引き渡す」義務を明文化する。著作権がベンダーに残る契約でも、引き渡しと改変・保守目的の利用許諾さえ確保できていれば、実務上の継続性は守れる。逆に、権利は自社にあるのに現物を受け取る手続きがない契約は、倒産時に絵に描いた餅になる。

定期的な引き渡しの実行。 条文だけでは足りない。倒産したベンダーから引き渡しを受けるのは、相手に人がいない以上、極めて困難だからだ。「四半期に一度、最新のソースコード・設計書・環境情報を発注者管理のストレージに納める」という運用をセットで決め、実際に納めさせる。これが実質的な自前エスクローとして機能する。第三者機関に預託する正式なソースコードエスクローは、開発規模が大きく代替の利かないシステムでは検討に値するが、小規模な保守契約では、この定期引き渡し運用のほうが安く確実に回る。

データの返還と形式の指定。 契約終了時（倒産による終了を含む）に、システム内の自社データを一般的な形式で返還する義務と、返還が完了するまでデータを削除しない義務を定める。形式を指定しないと、独自形式のバックアップファイルを渡されて読めない、という結末があり得る。

倒産・支払停止時の契約終了と協力義務。 ベンダーに破産・民事再生等の申立てや支払停止が生じた場合に、発注者が契約を解除でき、かつサーバー・ドメイン等の名義変更と引き継ぎに協力する義務を定める。ただし正直に書けば、倒産時にこの「協力義務」を強制する実効性は低い。だからこそ前段の名義の平時整理と定期引き渡しが本丸であり、条項は最後の拠り所と位置づけるべきだ。

再委託の事前承諾と開示。 再委託を行う場合は事前の承諾を要し、再委託先の名称と担当範囲を開示する条項。誰が作っているかを知る権利を確保することが、属人性リスクの把握につながる。

ここで想定すべき反応がある。これらの申し入れに対し、ベンダーが強く抵抗する場合だ。「ソースコードは渡せない」「当社の資産なので」という回答には一定の合理性がある場合（自社パッケージの流用部分など）もあるが、個別開発部分の引き渡しすら拒み、代替案の提示もないなら、それは囲い込みによって解約コストを高く保つことが事業モデルの一部になっているサインである。そのベンダーが健全なうちはロックインで済むが、倒産すればロックインは「鍵を持つ者の消失」に変わる。条項交渉への反応そのものが、委託先のリスク評価情報だと考えてほしい。交渉の持ち込み方や、拒否された場合の保守先変更の進め方は、保守先を変更する前に見るべき引き継ぎ条件の記事が実務手順を扱っている。

危険シグナル：財務諸表なしで委託先の異変を察知する

零細ベンダーの決算書を毎年取り寄せてチェックできる中小企業は少ない。しかし、統計が示した倒産の構造——価格競争依存・属人性・下請け末端——を踏まえると、日常の取引の中に表れるシグナルで異変はかなり察知できる。

最も重いシグナルは、担当者の退職が連鎖することだ。5人未満の会社で技術者が続けて辞めるのは、単なる人の入れ替わりではなく、事業の中核が流出している可能性が高い。「担当が変わります」の連絡が半年に2回来たら、資産台帳の10項目を即座に総点検するタイミングである。

次に、レスポンスの質的な悪化。返信が遅くなるだけでなく、「確認します」のまま止まる、障害対応の一次連絡が来なくなる、定例の場で先方の出席者が減る。少人数の会社では、資金繰り対応や退職者の穴埋めに経営者が忙殺されると、真っ先に既存顧客への対応品質が落ちる。

三つ目は、逆説的だが、値上げの申し入れが一切ないことである。この数年、人件費もクラウド費用も上がり続けている。それでも保守料が10年前から据え置きなら、そのベンダーは値上げ交渉をする力すら持てない価格競争依存の構造にいる、と読むべきだ。安さを喜ぶ場面ではなく、「この価格で先方の事業は持続するのか」を問う場面である。逆に、突然の大幅値上げや長期一括前払いの要請は、資金繰りの窮迫を示す古典的なシグナルだ。据え置きと急変、どちらの極端も危険信号として扱う。

これらのシグナルを検知したときにやるべきことは、委託先を問い詰めることではない。10項目の資産台帳を埋め、引き渡しを受けられるものは受け、名義を移せるものは移す——つまり、委託先が消えても困らない状態を静かに作ることだ。委託先の信用調査や継続的な監視体制の組み方は、前掲の事業継続計画の記事に譲る。

倒産が起きてしまったときの初動

備えが間に合わないまま倒産の一報が届いた場合の初動も、要点だけ押さえておく。統計が示すとおり、情報サービス業の倒産の大半は破産である。破産では、開始決定後、会社の財産の管理処分権は破産管財人に移る。つまり、昨日まで話していた社長や担当者は、もはや会社として何かを約束できる立場にない。

初動でやるべきことは4つ。第一に、事実確認。「倒産らしい」という噂の段階と、破産申立て・開始決定の段階では打てる手が違う。官報公告や代理人弁護士名義の受任通知で、手続きの種別と段階を確認する。第二に、自社システムの生存確認と時限の把握。システムは今動いているか、動いているならそれを支えるサーバー・ドメイン・証明書の名義と次回更新日・支払日はいつか。ベンダー名義で支払いが止まるものが、事実上のタイムリミットになる。第三に、取れるものの確保。自社がアクセス権を持つ範囲でのデータエクスポートとバックアップは直ちに行う。ただし、ベンダー管理の環境に無断で立ち入ってコードやデータを持ち出すことは、契約と法律の両面で問題になり得る。管財人への引き渡し・開示の請求という正規ルートがあるので、判断に迷う行為は弁護士に確認してからにする。第四に、管財人への早期のコンタクト。ソースコードや預けているデータの引き渡し、契約関係の処理について、管財人宛てに書面で申し入れる。管財人は多数の債権者対応を抱えるため、早く・具体的に・書面で動いた発注者から処理される傾向がある。

そして初動と並行して、引き継ぎ先となる開発会社の確保を始めることになる。ここで足元を見られないためにも、平時に資産台帳と文書が揃っているかどうかが、引き継ぎ費用と復旧期間を大きく左右する。

よくある質問（FAQ）

Q. 委託先は昔からの付き合いで信頼している。それでも点検が必要か。 A. 必要である。本記事の点検は委託先への不信の表明ではなく、火災保険と同じ純粋なリスク管理だ。今回の統計で増えているのは、悪質な会社ではなく、真面目に安く受け続けた末に価格競争と内製化の波に飲まれた小規模事業者である。信頼と、倒産リスクの構造的な高さは、両立する。

Q. ソースコードの引き渡しを求めたら関係が悪くなりそうで言い出しにくい。 A. 切り出し方の問題である。「御社を疑っている」ではなく「監査・事業継続の要請で、全委託先に同じ確認をしている」という形にすれば、実務上の摩擦は小さい。それでも引き渡しにも代替案にも一切応じない場合は、関係悪化を恐れる段階ではなく、依存度を下げる計画を立てる段階だ。

Q. 従業員5人未満のベンダーとは契約しないほうがよいのか。 A. そうではない。小規模ベンダーの機動力と価格は実際に価値であり、全国の中小企業のシステムは彼らが支えている。本記事の主張は「使うな」ではなく「リスクの対価を契約と資産管理で払っておけ」である。10項目が埋まり、定期引き渡しが回っているなら、零細ベンダーへの委託は引き続き合理的な選択肢だ。

Q. 点検の結果、ほぼ全項目がベンダー任せだと分かった。何から手を付けるべきか。 A. 優先順位は「失うと即日事業が止まるもの」からだ。一般には、①データのバックアップ取得、②ドメイン・サーバー名義の確認と移管、③最新ソースコード・文書の引き渡し、④契約条項の整備、の順で進める。①と②は委託先の協力があれば数週間で終わる。

Q. 引き渡しを受けたソースコードや文書の中身が妥当か、自社では判断できない。 A. これは中小企業に共通の弱点で、外部の目を使うのが現実的だ。受け取ったコード・文書・環境情報で「別の会社が引き継げる状態か」を第三者に評価してもらうことで、引き渡しが形式だけになるのを防げる。GXOでもこの評価を含めた相談を受けている。

GXOに相談すべきタイミング

GXOは、システム開発・保守の受託と、発注者側に立った整理・評価の両方を行っている。この記事のテーマで言えば、相談が最も効果的なのは次の局面だ。

第一に、10項目の点検で埋まらない欄が多く、委託先との交渉の進め方を設計したい局面。引き渡し要求の順序、条項の入れ方、拒否されたときの代替案について、発注者側の立場でセカンドオピニオンを提供できる。委託先と利害関係のない第三者の評価が入ることで、交渉が感情論にならずに済む。

第二に、危険シグナルが出ており、引き継ぎ先の目星を平時のうちに付けておきたい局面。既存システムの資料一式から引き継ぎ可能性と概算規模を評価しておけば、有事の初動が「ゼロから業者探し」ではなく「準備済みプランの実行」になる。老朽化が進んだシステムで、引き継ぎではなく作り直しが合理的なケースはレガシーシステム刷新として、引き継ぎ・再構築を含む開発体制の再設計はDX・システム開発支援として対応する。

第三に、この機会に、委託の全体像を見直したい局面。ベンダー依存の点検は、往々にして「そもそもこの業務はいまの形のシステムであり続けるべきか」という問いに行き着く。AIやノーコードの活用で内製・簡素化できる部分の切り分けはAI導入可否アセスメントで、要件と投資判断の整理から支援している。

166件という数字が今後どう動くかは断定できないが、東京商工リサーチ自身が「淘汰が加速へ」と表現するとおり、2025年通年で倒産と休廃業・解散が3,290件・前年比20.8%増という流れは、一過性の変動というより構造の変化を示している。委託先が消える日は選べないが、消えた日に困らない状態は今日から作れる。まずは10項目の表を埋めることから始めてほしい。埋め方や埋まらない欄の扱いに迷ったら、委託先リスクの点検・契約防衛のセカンドオピニオン相談（無料）で現状の資料を見ながら整理できる。相談だけで完結して構わないし、営業電話もしない。

---

参考資料

• 東京商工リサーチ「2026年上半期の『情報サービス業』倒産が166件、過去10年で最多」（2026年7月14日公表）: https://www.tsr-net.co.jp/data/detail/1203052_1527.html