ブラックボックス化とは？システムが読めなくなる原因と解消手順・リプレイス判断

ブラックボックス化とは、仕組みの中身を説明できる人や資料が失われ、外からは入力と結果しか見えなくなった状態を指します。経済産業省が2025年5月28日に公表したレガシーシステムモダン化委員会の総括レポートは、ブラックボックス化をレガシーシステムを生む5要因の一つに数え、仕様や設計のドキュメントが整っておらず移行や再構築で支障が出る状態と説明しました。この記事では、業務とシステムの両面からブラックボックス化の原因を整理し、自社システムの診断項目、解消の手順、文書化・改修・リプレイスのどれを選ぶかの判断基準までを、発注する側の立場で解説します。

まとめ：ブラックボックス化したシステムを解消する順序とリプレイスを選ぶ条件

システムのブラックボックス化は、担当者の退職といった個別の出来事よりも、改修のたびに記録を残さない運用と、仕様の判断をベンダーに預けたままにする発注の形から生まれます。解消は、全量の仕様書を作り直すところから始めません。IT資産を棚卸しし、変更頻度と業務への影響で対象を絞り、絞った範囲だけ仕様を復元して回帰テストで固める順序をとります。

手段の選び方は単純です。本番と一致するソースコードと実行環境が手元にあり、基盤のサポートが残っているなら、文書化と改修で中身を取り戻します。ソースが揃わない、第三者がビルドできない、OSやミドルウェアのサポート期限が迫っている、のいずれかに当たればリプレイスを先に検討してください。変更がほとんど発生しない機能は、文書化の費用をかけずに塩漬けにする判断も成り立ちます。

もう一つ外せないのが権利の確認です。成果物の著作権がベンダー側に残る契約だと、ソースを受け取っても他社に改修を頼めません。診断の段階で契約書まで確かめておくと、解消手段の選択肢を狭めずに済みます。

ブラックボックス化の意味と業務の属人化・システムの不可視化を分ける見方

同じ「ブラックボックス化」という言葉でも、人事や業務改善の記事と情報システムの記事では対象が違います。最初に意味の幅を押さえておくと、自社の課題がどちらに当たるかを取り違えずに済みます。

ブラックボックスの語源とビジネス・情報システムで使うときの意味の違い

ブラックボックスはもともと工学の用語で、内部構造を問わず入力と出力の関係だけで扱う箱を指します。ソフトウェアテストの「ブラックボックステスト」も同じ発想で、仕様に対する入出力だけを確かめる技法です。この場合、中身を見ないのは意図した設計であり、悪い意味はありません。

ビジネスで「ブラックボックス化」と言うときは否定的な意味に変わります。本来は見えているべき中身が、いつの間にか誰にも説明できなくなった状態です。担当者の頭の中にしか手順がない「業務のブラックボックス化」と、ソースコードや設計の意図を誰も追えない「システムのブラックボックス化」の二つに分かれ、本記事は後者を中心に扱います。

属人化との違いと業務・システムのブラックボックス化が連鎖する経路

属人化は特定の人に依存している状態で、その人がいる間は業務が回ります。ブラックボックス化は、依存先の人が抜けたり記録が失われたりして、中身を確かめる手段そのものが消えた状態です。属人化が原因、ブラックボックス化が結果という関係で捉えると、対策の順番を誤りません。業務側の属人化をほどく手順は属人化とは？原因・リスクと脱属人化を進める仕組み化・標準化の実務で扱っています。

二つは連鎖します。Excelのマクロや帳票の手修正で業務の例外を処理していると、その例外ルールはシステムの仕様書にも業務マニュアルにも載りません。担当者が異動した時点で、業務とシステムの両方が同時に読めなくなる。周辺の手作業までを調査範囲に含める理由がここにあります。

システムがブラックボックス化する原因と経産省の総括レポートが示した構造

原因を「担当者が辞めたから」で片づけると、次の担当者のもとで同じことが起こります。公的な調査が示した構造と、現場で起きている発生の経路を分けて見ていきます。

総括レポートが定義したレガシー化の5要因とブラックボックス化の中身

経済産業省はIPAを事務局としてレガシーシステムモダン化委員会を開き、議論の結果を総括レポートとして2025年5月28日に公表しました。レポートはレガシーシステムを、単に古いだけでなく維持保守や機能改良が難しくなり、高コストの原因となって経営・事業の足かせになっているシステムと定めています。要因は技術観点の「技術の老朽化」「肥大化・複雑化」「ブラックボックス化」と、経営観点の「IT投資がされていない」「古い制度としがらみ」の5つです。

ブラックボックス化の中身として、総括レポート本文は「仕様や設計のドキュメントが整備されておらず、新システムへの移行や再構築時に支障が発生」「システムの運用維持保守が属人的な状態に陥っている」の2点を挙げました。レポートは、メインフレームが必ずしもレガシーとは限らず、メインフレームから脱却した後でも再びレガシー化しうると注記しています。古さではなく、この2点の有無で判定するということです。5要因全体の解説はレガシーシステムとは？再構築が必要な理由を経産省の定義と5要因で解説にまとめました。

改修の積み増しと設計書の未更新・ベンダー丸投げが生む5つの発生経路

現場でブラックボックス化が進む経路を、影響の大きい順に並べます。

• 改修のたびに設計書を更新しない。初版の設計書だけが残り、その後の改修内容はコードの中にしかない
• 要件と仕様の判断をベンダーに預けたまま発注する。社内に判断の記録が残らない
• パッケージへのカスタマイズとアドオンを積み増す。標準機能との差分を説明できる人がいなくなる
• 担当者の異動・退職と保守ベンダーの交代が重なり、引き継ぎが口頭で終わる
• Excelマクロ・RPA・手作業で例外処理を補い、システムの外に業務ルールが散らばる

実務で最初に疑うべきは一つ目です。設計書の最終更新日と直近の改修日を並べるだけで、記録が止まった時期が分かります。二つ目は、委員会の第1回説明資料が再掲したDXレポートの課題「ユーザ企業からベンダー企業への丸投げ」と同じ構図で、要件を確定するのはユーザー企業であるべきだと指摘されています。

経営層と情シスの情報共有が途切れた企業で対策が止まる調査結果

総括レポートのアンケート分析では、経営層と情報システム部門の間でシステムに関する情報を共有しているユーザー企業ほど、仕様の可視化やブラックボックス対策が進み、内製化とモダン化も進む傾向が出ました。共有できていない企業については「それらが全て進まない傾向がある」と書かれています。CxOを置いている企業と置いていない企業の比較でも、同じ向きの差が示されました。

ブラックボックス化は技術者の怠慢と見られがちです。しかし調査の結果は、経営側の関与の薄さと結びついていることを示しています。仕様書の更新に予算と工数が割り当てられていなければ、現場は記録を後回しにするほかありません。

ブラックボックス化を放置したときに表面化する障害対応・改修・移行のリスク

ブラックボックス化は平常時には目立ちません。問題が表に出るのは、障害、制度対応の改修、システム移行という三つの場面です。

障害の切り分けが長引き復旧の見通しを示せなくなる問題と受動的な契機

中身が分からないシステムで障害が起きると、ログの読み方、安全な再起動の手順、どのバッチを再実行してよいかを判断できる人がいません。復旧手順書があっても、前提の構成が変わっていれば役に立たないのです。

総括レポートは、システムのモダン化を決断する要因を尋ねた結果、「基幹システムの障害の頻発、リカバリができないといったシステム保守の限界」や保守要員の確保難・保守料の値上げといった受動的な要因がトップだったとまとめ、「痛い目にあって初めて自覚する」状態と表現しました。障害が起きてから中身を調べ始めると、調査と復旧と刷新の検討を同時に抱えることになります。

法改正・制度変更の改修で影響調査の工数が膨らみ見積もりが読めない構造

インボイス制度や電子帳簿保存法への対応のように、制度改正の改修は期限を動かせません。ブラックボックス化したシステムでは、どこを直せばよいかを調べる影響調査の工数が改修そのものに上乗せされ、見積もりの幅が大きくなります。

保守ベンダー自身も中身を把握していない場合、調査だけで数週間を要したり、改修を引き受けられないと回答されたりすることもあります。期限のある改修ほど、調査不足のまま手を入れる危険な判断を迫られます。

移行・再構築で現行仕様が確定できずプロジェクトが止まる典型的な経過

総括レポートは、ベンダー企業から見たモダン化の難しさとして「仕様がブラックボックス化」「現行踏襲への強いこだわり」を並べました。現行の仕様が分からないまま「今と同じ動きで」と発注すると、受け入れテストの合否基準が存在しない状態で開発が進みます。

結果として、移行の終盤で現行との差異が次々に見つかり、追加費用と延期の原因になります。刷新に踏み切るかどうか、どのシステムから着手するかの判断軸はレガシーシステム脱却の判断基準と進め方で整理しています。

自社システムのブラックボックス度を測る診断項目とソースコード・権利の確認

ブラックボックス化しているかどうかは、印象ではなく確認できる事実で判定します。技術面の診断と、契約面の確認を分けて進めます。

ソースコード・ビルド環境・設計書の有無で判定する7つの診断項目

次の表は、発注者が保守担当者に質問するだけで埋められる項目に絞っています。

上の3項目のどれかが危険な状態なら、そのシステムは中身を取り戻す前提条件が欠けています。下の4項目だけが該当する場合は、手元の資産から仕様を復元できる見込みが高いと判断できます。

契約書で成果物の著作権とソースコードの引き渡し条件を確かめる手順

見落とされやすいのが権利です。受託開発の契約で成果物の著作権がベンダーに留保されていると、ソースコードを受け取っても他社に改修や移行を頼めない場合があります。契約書では、著作権の帰属条項、ソースコードと設計書の納品義務、第三者への開示と改変の可否を確認してください。

ベンダー依存が強まる仕組みと、契約で押さえる条項の詳細はベンダーロックインとは？原因と回避策・契約で押さえる条項とリプレイスの判断基準に書きました。権利がベンダー側にある場合は、解消手段を決める前に譲渡や利用許諾の交渉から始めます。

ブラックボックス化を解消する進め方：IT資産の棚卸しから仕様復元とテスト整備

総括レポートは企業がとるべき対策として、IT資産の棚卸し・可視化と内製化を挙げ、ブラックボックス化したシステムの仕様を復元・ドキュメント化して属人性を排除し、担当者が代わってもナレッジを引き継げる状態にするよう提言しています。ここではその提言を、発注者が動かせる手順に置き換えます。

IT資産の棚卸しと変更頻度×業務影響による復元対象の絞り込み

全システムを同じ深さで復元する必要はありません。経済産業省のDXレポートは、機能ごとに四象限で評価する考え方を示しています。頻繁に変更が発生する機能はクラウド上で再構築し、新たに必要な機能は適宜クラウドへ追加し、肥大化したシステムの中の不要な機能は廃棄し、あまり更新が発生しない機能は塩漬けにする、という仕分けです。この図はIPAのレガシーシステムモダン化委員会の第1回説明資料にも再掲されています。

仕様の復元に予算を割くのは、変更が続き、止まると業務が止まる機能からです。過去1〜2年の改修履歴と障害履歴を機能単位で数えるだけでも、優先順位の大枠は決まります。

仕様の復元でコード解析・本番ログ・担当者の聞き取りを突き合わせる手順

復元は一つの情報源に頼らず、三方向から突き合わせて進めます。

1. 本番で動いているソースコードとジョブ定義を一か所に集め、版を固定する
2. 画面・帳票・バッチ・外部連携の一覧を作り、呼び出し関係を図にする
3. 本番ログとデータの実際の値から、よく通る処理経路と使われていない機能を分ける
4. 業務担当者に例外処理を聞き取り、コード上の分岐と対応づける
5. 復元した仕様を「現在の挙動」と「本来あるべき挙動」に分けて記録する

5番目を省くと、不具合まで正しい仕様として固定してしまいます。コードの解読や仕様書の下書きには生成AIを使う方法もあり、入力資産の揃え方や限界は生成AIモダナイゼーションの実装手順｜コード解読・仕様復元・テスト生成と限界で解説しています。

回帰テストを先に用意し改修のたびに記録が残る運用へ切り替える方法

仕様書は作った翌月から古くなり始めます。復元した仕様を保つには、現在の挙動を確かめる回帰テストを先に用意し、改修のたびにテストと設計の差分を更新する運用に変えるしかありません。テストがあれば、担当者が代わっても、どこを変えると何が壊れるかをテストの失敗で知ることができます。

運用面では、チケットとコミットの紐づけ、変更理由の記録、二人以上でのレビューを最低限の決まりにします。総括レポートでも、ブラックボックス対策に取り組む企業ほど内製化が進む傾向が示されました。記録が残る状態は、内製と外注の切り替えを自由にします。

解消手段の選び分け：文書化で足りる場合・改修する場合・リプレイスの場合

競合する解説記事の多くは、マニュアル化やツール導入を並べて終わります。システムの場合は、中身を取り戻すのか、作り直すのかを先に決めなければ、費用の使い道が定まりません。

文書化と改修で中身を取り戻すべき業務システムの条件と判断の目安

次の三つがそろうなら、リプレイスより文書化と改修を選びます。本番と一致するソースコードがあり第三者がビルドできること、OS・ミドルウェア・言語処理系のサポート期限まで十分な期間が残っていること、業務ロジックがいまの業務と合っていることです。

このとき、リプレイスを選ぶとかえって損をします。動いている業務ルールを新システムで作り直す費用と、移行時の不具合のリスクを新たに抱えるからです。文書化と回帰テストの整備で説明できる状態に戻し、その後の改修でリファクタリングを少しずつ進めるほうが総額は抑えられます。

リプレイスを先に検討すべきシステムの4条件と仕様復元の範囲の絞り方

次のいずれかに当たる場合は、文書化に予算を投じる前にリプレイスを検討します。

• 本番と一致するソースコードが見つからない、またはビルドできない
• サポート期限が切れた、または期限が目前の基盤の上で動いている
• 業務が変わり、現行機能の多くが使われていない
• パッケージやSaaSの標準機能で業務の大半を賄える

総括レポートは、現行機能の保証や現行踏襲へのこだわりを捨て、標準的な仕様に寄せる部分と付加価値を作り込む部分を分けるよう求めているのです。リプレイスを選ぶなら、復元すべき仕様は新システムに引き継ぐ業務ルールだけに絞れます。移行方式ごとの違いはマイグレーションとは？リプレイス・モダナイゼーションとの違いと発注判断を解説で比べています。

全量の仕様書作成を発注すべきでない場面とよくある二つの失敗パターン

解消を急ぐ企業がやりがちなのが、全システムの設計書を外部に一括で作らせる発注です。変更がほとんど発生しない機能まで同じ深さで書くと、費用の多くが読まれない資料に消えます。リプレイスの時期がすでに決まっているシステムで、現行の詳細設計書を一から作り直すのも過剰です。この二つの場面では、全量の文書化は発注しません。

もう一つの失敗は、ドキュメントを作っただけで運用を変えないことです。改修のたびに更新する決まりがなければ、数年で元の状態に戻ります。総括レポートが、移行を終えた後でも再びレガシーになりうると注記しているのはこのためで、新しい基盤に移しただけではブラックボックス化は再発します。

ブラックボックス化の解消を外注するときに契約と体制で押さえる点と支援範囲

解消の作業を外部に頼むこと自体は問題ありません。問題になるのは、判断まで預けて、新しいベンダーのもとで同じ状態を再生産することです。

仕様の判断を社内に残す役割分担とベンダーに任せる作業範囲の線引き

外注先に任せてよいのは、コード解析、図表化、テストの整備、移行の実装といった作業です。業務ルールが正しいかの判定、使わない機能の廃棄、優先順位づけは社内に残します。総括レポートが内製化と並べて「ベンダーとの協力体制への移行」を挙げているのも、判断と作業を分ける考え方に沿っています。

契約では、復元した仕様書・テストコード・構成情報の権利と引き渡し形式、ソースコードを置くリポジトリの所有者を発注側にすることを明記してください。ここが曖昧だと、解消のための契約が次のロックインの入り口になります。

一創が支援できる範囲：現行システムの調査からリプレイス・移行まで

株式会社一創はWebシステム・業務システムの受託開発会社として、既存システムのソースコード調査と仕様の整理、回帰テストの整備、段階的な移行計画の立案から、リプレイス後の開発・保守までを支援しています。中身が分からないシステムを残すか作り直すかの判断がつかない段階でも、診断項目の確認から一緒に進められます。

支援内容と進め方はシステムマイグレーション・リプレイスの支援内容で紹介しています。

よくある質問

ブラックボックス化について、検索の多い疑問に短く答えます。

ブラックボックス化の反対語や対になる言葉は何ですか？

決まった対義語はありませんが、実務では「可視化」や「見える化」、テストの分野では「ホワイトボックス」が対になる言葉として使われます。ホワイトボックスは内部の構造や処理の流れを把握したうえで扱う考え方で、ホワイトボックステストはコードの分岐や経路を確かめる技法を指します。システムのブラックボックス化を解消するという文脈では、仕様が文書とテストで説明できる状態に戻すことを「可視化」と呼ぶのが一般的です。

ソースコードが手元にないシステムはどう扱えばよいですか？

まず契約書で著作権とソースコードの納品義務を確認し、保守ベンダーに本番と一致する版の提出を求めます。提出されない、または本番と一致する版が存在しない場合は、仕様の復元に予算をかけるよりリプレイスを先に検討するほうが現実的です。その際は、画面・帳票・データの実物と業務担当者への聞き取りから、新システムに引き継ぐ業務ルールだけを洗い出します。逆コンパイルなどで中身を取り出す方法は、契約や利用許諾の条件に反しないかを先に確かめてください。

生成AIでブラックボックス化したシステムの仕様書を作れますか？

コードの解読や仕様書の下書きには役立ちますが、出てきた内容が正しいかは人が判定する必要があります。生成AIはコードに書かれた処理は説明できても、その処理が業務として正しいのか、使われていない機能なのかは判断できません。本番ログや業務担当者への聞き取りと突き合わせ、「現在の挙動」と「あるべき挙動」を分けて記録する工程は省けないと考えてください。ソースコードが揃っていない場合は、解析の入力そのものが欠けるため効果が限られます。

ブラックボックス化の解消にかかる期間や費用は何で決まりますか？

主に、復元対象とする機能の数とコード量、ソースとビルド環境が揃っているか、説明できる人が社内外に残っているか、で決まります。全システムを対象にすると期間も費用も読めなくなるため、棚卸しで変更頻度と業務影響の大きい機能に絞り、その範囲で見積もるのが基本です。リプレイスを選ぶ場合は、新システムの開発費に加えて、引き継ぐ業務ルールの洗い出しとデータ移行の費用を別に見込みます。

クラウドやSaaSに移行すればブラックボックス化は防げますか？

移行しただけでは防げません。総括レポートは、メインフレームから移行を終えたシステムでも再びレガシーになりうると注記しているのです。クラウド上でも、設定や連携の変更を記録せず、特定の担当者やベンダーしか構成を説明できなければ、同じ状態に戻ります。SaaSは標準機能に業務を合わせる限り中身の管理を提供元に任せられますが、カスタマイズや外部連携を積み増すと、その部分が新たなブラックボックスになります。

関連記事

• レガシーシステムとは？再構築が必要な理由を経産省の定義と5要因で解説：ブラックボックス化を含むレガシー化の5要因の全体像
• レガシーシステム脱却の判断基準と進め方｜経産省調査が示す停滞要因と費用の見積り方：刷新に着手するかどうかの判断軸と費用の比べ方
• モダナイゼーションとは？レガシー刷新の手法と実装アプローチ・進め方を解説：仕様を取り戻した後の刷新手法を実装の視点で整理
• 2025年の崖とは何だったのか｜DXレポートの試算と2026年に刷新を判断する基準：ブラックボックス化が問題視された経緯とDXレポートの試算
• 属人化とは？原因・リスクと脱属人化を進める仕組み化・標準化の実務：業務側のブラックボックス化を防ぐ仕組み化の手順