この記事の要約
システムのブラックボックス化とは何か、なぜシステムの知識がソースコードと一部の担当者の頭の中にしか残らなくなるのかを解説します。知識が「どこで失われたのか」を特定する3層モデル、バス係数を使った自己診断、AIと人を組み合わせて仕様を復元する5つのステップを紹介します。最後に、再発を防ぐ仕組みと、解消プロジェクトを稟議に通すための考え方もまとめました。
システムのブラックボックス化とは、システムの仕様や業務ロジックがソースコードと一部の担当者の頭の中にしか残っていない状態を指します。設計書は実態と合っておらず、システム全体が「何を、なぜ」処理しているのかを説明できる人がいません。
その結果、改修のたびに想定外の不具合が起き、「詳しい人」が不在のときは障害対応が長引きます。クラウド移行やDXの計画も、「現行システムを理解する」段階で止まってしまいます。解消するには、コードから「何をしているか」を復元する道（AIが得意）と、人から「なぜそうなっているか」を回収する道（人にしか答えられない）の両方を同時に進めることが必要です。
システムのブラックボックス化とは？知識が「コードと数人」に閉じた状態
解決策を考える前に、まず定義をそろえておきましょう。「ブラックボックス」という言葉は複数の意味で使われるため、問題の捉え方がずれやすいからです。
システムにおけるブラックボックス化の定義
企業のITにおけるシステムのブラックボックス化とは、システムは動いているのに、その内部で何が行われているのかを正確に説明できる人がいない状態です。入力と出力は見えても、その間の処理ルールが見えません。
AI分野でいう「ブラックボックス」（モデルの判断根拠を説明できないこと）とは別の問題です。ここでの課題は技術の難しさではなく、システムに関する知識が時間とともに失われたことにあります。
では、よく混同される「属人化」や「技術的負債」とは何が違うのでしょうか。
属人化・技術的負債・レガシー化との違い
この4つの概念は密接に関係していますが、それぞれ別の側面を表しています。
| 概念 | 本質 | どこにあるか | 何で測るか |
|---|---|---|---|
| ブラックボックス化 | 誰もシステムを説明できない | コード・ドキュメント・人の間のすき間 | 実態と一致した仕様がある機能の割合 |
| 属人化 | 知識や業務を特定の一人しか担えない | 人 | バス係数、モジュールごとの対応可能人数 |
| 技術的負債 | 場当たり的な設計・実装が改修コストを積み上げる | ソースコード、アーキテクチャ | 複雑度、重複コード、改修にかかる時間 |
| レガシー化 | 技術が古くなり保守が難しい | 基盤、言語、インフラ | EOL、稼働年数、市場の技術者数 |
ひと言でいえば、属人化は最も多い「原因」であり、ブラックボックス化はその「結果」です。古いシステムでも、ドキュメントが整っていればブラックボックスとは限りません。逆に稼働5年のシステムでも、一人が作り、その人が退職していればブラックボックス化します。
では、なぜこの問題が今、深刻になっているのでしょうか。
なぜ今、深刻化しているのか
経済産業省の「DXレポート」は、複雑化・老朽化・ブラックボックス化した既存システムが残り続けた場合、2025年以降に最大12兆円／年の経済損失が生じる可能性があると警告しました。いわゆる「2025年の崖」です。
同レポートでは、2025年には大企業の基幹システムの約6割が稼働21年以上になると試算されています。システムを構築した世代は順次定年を迎え、一度も文書化されなかった知識も一緒に失われつつあります。
さらに、AI活用やDXの波によって、データ連携やシステム改修のスピードが求められています。現行システムを理解できなければ、変えることもできません。だからこそ、システムのブラックボックス化はあらゆるモダナイゼーションの最大のボトルネックになっているのです。
知識はどこに消えたのか — コード・人・ベンダーの3層モデル
ブラックボックス化に関する多くの記事は、原因の列挙で終わっています。しかし効果的に解消するには、知識がどの層に残っているのかを見極める必要があります。層ごとに復元の方法が違うからです。
コード層：仕様がソースコードにしか残っていない
最もよく見られるのがこの層です。設計書は初期開発時に作られたものの、その後の数百回の改修がドキュメントに反映されていません。その結果、ソースコードが「唯一信頼できる仕様書」になります。
問題は、コードが示すのはシステムが何をしているかであって、なぜそうしているかではない点です。さらに業務ロジックはバッチ処理、ストアドプロシージャ、設定ファイルなどに分散しており、ツールなしでは読み解くのが困難です。
一方で、コードには決して書かれない知識があります。それが2つ目の層です。
人の層：「あの人しか知らない」暗黙知
ここには暗黙知が蓄積されています。なぜその特別な条件分岐が追加されたのか、どの取引先に例外処理をしているのか、月末にどのバッチを手動で再実行するのか、といった知識です。
これを持つ担当者が退職・異動・定年を迎えると、その知識は完全に失われます。コードからツールで復元することはできません。
そして多くの日本企業には、見落とされがちな3つ目の層があります。
ベンダー層：契約終了・再委託で知識が社外に流出する
開発・保守をベンダーに全面委託している場合、特に多重下請け構造では、知識は発注側ではなくベンダー側に蓄積されます。契約終了やベンダー変更のタイミングで、その知識も一緒に流出してしまいます。
緊急の改修が必要になって初めて「その案件の担当者はもう弊社にはおりません」と告げられ、この事実に気づく情シス担当者も少なくありません。
コードから復元できる知識／人にしか残らない知識
3層モデルを踏まえると、システムの知識は大きく2つに分けられます。
| コードから復元できる知識（What／How） | 人にしか残らない知識（Why／例外） |
|---|---|
| モジュール構成、呼び出し関係 | 各ルールが存在する業務上の理由 |
| 計算ロジック、分岐条件 | システム外の手作業運用（Excel・手入力） |
| CRUD図：どの機能がどのデータを読み書きするか | どのコードが不要で、どれが年1回だけ動くのか |
| バッチジョブ間の依存関係 | 取引先や他部門との暗黙の取り決め |
| 外部システムとのインターフェース | 過去の障害履歴と暫定対応の方法 |
ここがこの記事の核心です。コード解析だけでは「なぜ」が欠け、ヒアリングだけでは正確さと網羅性が欠けます。システムのブラックボックス化を解消するには、常に両方のアプローチが必要です。
システムのブラックボックス化が起きる6つの原因
3つの層の知識は、自然に失われるわけではありません。日本企業の基幹システムでよく見られる6つの原因を整理します。
① 設計書・仕様書が更新されない
コードの修正は必須でも、ドキュメントの更新は「後回し」になりがちです。数年経つとドキュメントとコードの乖離が大きくなり、誰もドキュメントを信用しなくなります。
② 長年の改修・追加開発で構造が複雑化している
変更要求のたびに、設計を見直すのではなく「継ぎ足し」で対応してきた結果、改修の層が地層のように積み重なります。小さな変更の影響範囲すら予測できなくなります。
③ 特定の担当者に知識が集中している（属人化）
システムに最も詳しい人は、たいてい最も忙しい人でもあります。知識を共有する時間がなく、組織としても優先されない——その人が去るまでは。
④ ベンダー任せで社内に知見が残らない
ベンダー層で見たとおり、機能の検収だけを行い、知識そのもの（ドキュメントや設計の説明）を成果物として定義していないと、知識は二度と社内に戻ってきません。
⑤ COBOLなど古い言語と技術者の減少
COBOLやPL/I、独自言語で書かれたシステムは、読める人材を確保すること自体が年々難しくなっています。コードが残っていても、コードから知識を「読み出せる」人が減り続けています。
⑥ IT予算が「守り」に固定され、ドキュメント整備が後回しになる
DXレポートに関連する分析では、日本企業のIT予算の約8割が既存システムの維持・運用に充てられているとされています。ドキュメント整備やナレッジ移転は新しい機能を生まないため、真っ先に削られてしまいます。
システムのブラックボックス化を放置する4つのリスク
ブラックボックス化は、すぐに障害を引き起こすわけではありません。だからこそ、問題が起きるまでリスクが過小評価されがちです。
保守コストの増大と「改修の影響範囲が読めない」
変更の影響範囲が分からないため、テスト範囲は広がり、改修は遅くなり、それでも不安が残ります。小さな修正依頼に数週間かかることも珍しくありません。
キーパーソン不在で障害対応が止まる
深夜に障害が発生し、「詳しい人」が休暇中だったらどうなるでしょうか。数時間で済むはずの復旧が数日に延び、基幹システムであれば直接的な事業損失につながります。
セキュリティ・内部統制・監査への影響
システムがデータをどう処理しているか分からなければ、規制への準拠を証明できません。古いライブラリの脆弱性も、誰も触れられないため放置されがちです。
刷新・マイグレーション失敗の最大要因になる
最もコストの大きいリスクがこれです。刷新プロジェクトの多くは、新技術の難しさではなく現行システムの理解不足——業務ルールの見落とし——によって失敗し、最終テスト段階で機能漏れが発覚します。詳しくはレガシーシステム刷新のリスクと判断時期、およびレガシーシステムアセスメントの進め方で解説しています。
自社システムのブラックボックス度、把握できていますか？
HBLABのAIアセスメントツールが、ソースコードを解析して現行システムの構造と業務ロジックを可視化します。まずは無償でお試しください。
自社システムのブラックボックス度を測る — 診断シートとバス係数
「うちのシステムは少しブラックボックス気味だ」というのは感覚であって、データではありません。経営層を説得し、適切な対策を選ぶには、問題の度合いを測れる形にする必要があります。
8項目チェックシート（3段階スコア）
各項目を 0点（当てはまらない）、1点（一部当てはまる）、2点（完全に当てはまる）で採点してください。
| # | チェック項目 | 点数 |
|---|---|---|
| 1 | システム全体を説明できるのは1〜2人だけ | 0／1／2 |
| 2 | 設計書がここ3年更新されていない | 0／1／2 |
| 3 | 改修のたびに想定外の箇所で不具合が起きる | 0／1／2 |
| 4 | 「機能Xがどのテーブルを使うか」にコードを読まずに答えられない | 0／1／2 |
| 5 | ベンダーに確認しないと技術的な判断ができない | 0／1／2 |
| 6 | どこにも記録されていない手作業の運用がある | 0／1／2 |
| 7 | 主担当者が3年以内に定年・異動・退職する予定 | 0／1／2 |
| 8 | 使われているか分からず、誰も削除できないコードがある | 0／1／2 |
判定：0〜4点＝軽度 5〜10点＝中度 11〜16点＝重度
このシートで全体の度合いは分かります。しかし、どのモジュールが最も危険なのかを知るには、より具体的な指標が必要です。
バス係数（Bus Factor）で属人化を数値化する
バス係数とは、「その人たちが同時にいなくなるとプロジェクトが継続できなくなる」最少人数を指します。バス係数＝1なら、その部分の知識はすべて一人に集中しているということです。
簡単な測り方は、GitやSVNのコミット履歴、または変更履歴台帳を使い、直近2〜3年でモジュールごとに何人が修正したかを数える方法です。一人しか修正していないモジュールが「レッドゾーン」になります。
バージョン管理がないシステムでは、ヒアリングで代用できます。「この人が明日いなくなったら、このモジュールは誰が直しますか？」——答えが「誰もいない」なら、それもバス係数＝1です。
診断スコアとバス係数マップがそろったら、次は度合いに応じた打ち手を選びます。
スコア別の打ち手
- 軽度（0〜4点）：バス係数の低いモジュールからドキュメントを更新し、副担当者を置く。
- 中度（5〜10点）：コード解析による可視化と、計画的なナレッジ移転を行う（次章の5ステップ）。
- 重度（11〜16点）：包括的なアセスメントを実施し、維持・改修・刷新を判断する。詳しい手順はレガシーシステムアセスメントの評価7領域と進め方をご覧ください。
システムのブラックボックス化を解消する5ステップ
以下の手順は、3層モデルで示した2つの道——コードからの復元と人からの回収——を組み合わせたものです。順番が重要で、先にコードを解析し、その後にヒアリングを行います。
STEP 1：IT資産の棚卸しと対象範囲の決定
プログラム、バッチジョブ、データベース、外部インターフェースをすべて洗い出します。そのうえで、業務上の重要度とバス係数をもとに優先範囲を決めます。システム全体を一度に対象にする必要はありません。
一覧ができたら、次はそれぞれの中身を見ていきます。
STEP 2：ソースコード解析で構造と業務ロジックを可視化
静的解析によって、コールグラフ、CRUD図、ジョブ依存関係図を作成します。AIによって最も時間を短縮できるのがこの工程で、機能の要約やCOBOLなど古いコードからの業務ルール抽出を高速化できます。詳しくはマイグレーションにおけるAI活用をご覧ください。
この工程の成果は、ドキュメントだけではありません。次のステップで使う「質問リスト」にもなります。
STEP 3：キーパーソンから暗黙知を回収する（ヒアリング設計）
よくある失敗は、担当者に「システムについて一通り説明してください」と依頼することです。時間がかかるうえに、抜け漏れが多くなります。効果的なのは、コード解析の結果を持参し、コードでは答えが出ない点だけを質問する方法です。
- 「この条件はいつ、誰の要望で追加されたものですか？」
- 「このコードは今も使われていますか？使われているなら、どのタイミングですか？」
- 「このバッチの前後に、システム外で行う手作業はありますか？」
- 「エラーXが起きたとき、普段はどう対応していますか？」
実務上のポイントは、定年・異動を控えた人から優先的にヒアリングすること、録画や文字起こしを残すこと、長時間1回ではなく60〜90分の短いセッションを複数回に分けることです。
STEP 4：仕様書の再構築と検証
STEP 2とSTEP 3の結果を統合し、仕様書を作り直します。ドラフトはAIで生成できますが、BA/SAと業務担当者によるレビューが不可欠です。そのうえで、システムが本当に仕様書どおりに動くかをテストで検証します。移行テストの進め方も参考にしてください。
STEP 5：維持・改修・刷新の判断
システムが「見える」ようになって初めて、判断の根拠がそろいます。新しいドキュメントで維持を続けるのか、部分的にリファクタリングするのか、マイグレーション／モダナイゼーションに踏み切るのか。それぞれの違いはモダナイゼーションとマイグレーションの違いで、4象限の判断フレームはアセスメントのピラー記事で解説しています。
AIで仕様を復元する — できること・できないこと
AIは、システムのブラックボックス化を解消するスピードを大きく変えつつあります。一方で、AIへの誤った期待が新たな失敗要因にもなっています。
AIが速くする作業
- 古い言語を含む、各プログラムの機能要約
- 業務ルール（条件・計算式）の文章化
- 設計書や処理フロー図のドラフト作成
- 現行の挙動を検証するためのテストケース生成
これまで手作業のコードリーディングで数か月かかっていた作業が、数週間に短縮できるケースもあります。ただし、AIにも越えられない限界があります。
AIでも分からないこと
- 判断の背景：そのルールがなぜ存在し、現在の業務でも正しいのか。
- システム外の運用：Excelファイル、手作業、紙の承認フロー。
- 不要なコードと「休眠中」のコード：年に1回しか動かないコードは、使われていないコードと見分けがつきません。
そのため、AIの出力は最終仕様ではなく、検証が必要な仮説として扱うべきです。
AIと人（BA/SA・現場担当者）の役割分担
| 役割 | 担当 |
|---|---|
| コードの読解・要約・抽出 | AI |
| 質問設計、ヒアリング、業務との照合 | BA/SA |
| 「なぜ」と例外の確認 | 現場担当者 |
| 最終仕様の承認 | 発注企業（情シス＋業務部門） |
再発させない仕組み — ドキュメントを書くだけでは元に戻る理由
一度ドキュメントを整備しても、3〜5年後に再びブラックボックスに戻ってしまう企業は少なくありません。原因は、結果だけを直して仕組みを直していないことにあります。
「生きたドキュメント」：コードと仕様を同時に更新する
ドキュメントの更新を、改修の完了条件に組み込みましょう。ドキュメントが更新されていなければリリースしない、というルールです。ドキュメントをコードと同じ場所で管理する（Docs as Code）ことで、両者の乖離を防げます。
ドキュメントの仕組みと合わせて、人の仕組みも必要です。
複数担当制とコードレビューで属人化を防ぐ
重要なモジュールには、修正できる人を最低2人置きます（バス係数2以上）。コードレビューの必須化は、日常業務の中で自然に知識を共有できる、最もコストの低い方法です。
ベンダー契約に「知識移転」と成果物定義を入れる
あまり議論されませんが、非常に効果的なのがこの方法です。開発・保守契約を結ぶ際に、次の点を明確にしておきましょう。
- 成果物には、ソースコードだけでなく最新の設計書を含める
- ソースコードの権利は発注企業に帰属させる
- 契約終了時や担当者変更時の引継ぎ期間を義務づける
解消プロジェクトを稟議に通す — 放置コストの見積もり方
情シス担当者にとって最大の壁は、技術ではなく「新しい機能を生まない取り組み」に予算を出してもらうことではないでしょうか。
放置コスト＝保守費＋障害損失＋キーパーソン退職リスク
「解消にかかる費用」ではなく、「何もしないことのコスト」を示すのが効果的です。
- 過剰な保守コスト：影響範囲が分からないことによる改修期間の長期化
- 障害損失：システム停止時間 × 1時間あたりの売上・業務損失
- キーパーソンリスク：モジュールXを唯一理解している人が退職した場合、ゼロから解析し直すコストはいくらか
経営層に響く伝え方
経営層が関心を持つのは、技術の詳細ではなく事業リスクとDXの実現性です。バス係数マップを「リスクマップ」として示し、範囲と予算を限定したスモールスタートを提案しましょう。稟議資料の構成例は、ピラー記事の「アセスメント結果を社内で通す」で紹介しています。
HBLABのブラックボックス解消支援
HBLABは、コードと人の両面から知識を復元し、日本企業のシステムのブラックボックス化解消を支援しています。
AI解析 × BA/SAの二層体制
HBLABのAIアセスメントツールは、診断だけのツールではありません。技術調査 → 評価 → 戦略策定 → 業務仕様の整理 → コード変換 → 単体テスト → 結合テストという7ステップのパイプライン全体を支援します。AIが生成した成果物は、必ずHBLABのBA/SAが検証してから納品します。
日本語で現場ヒアリングができる体制
暗黙知は、直接の対話でしか回収できません。HBLABには日本語で業務・システム担当者にヒアリングできる体制があり、通訳を介さずに知識を引き出せます。
ブラックボックス化したシステムを、まず可視化しませんか
ソースコード（一部でも可）をお預かりし、AIが解析した構造・業務ロジックのレポートを、BA/SAのコメント付きでお届けします。
関連情報：HBLABのモダナイゼーションサービス／Migration Assessmentウェビナー資料
よくあるご質問
Q1. ブラックボックス化と属人化の違いは何ですか？
属人化は、知識が特定の一人にしかない状態で、これが「原因」です。ブラックボックス化は、誰もシステムを説明できなくなった「結果」です。属人化が続き、その人がいなくなったときにシステムはブラックボックスになります。
Q2. 設計書がまったく無くても解消できますか？
できます。ソースコードは、現在の挙動を最も正確に表す仕様書です。AIを活用したコード解析で「何をしているか」を復元し、ヒアリングで「なぜそうなっているか」を補います。
Q3. 担当者がすでに退職している場合はどうすればよいですか？
「なぜ」の部分の復元は難しくなりますが、実データ、運用ログ、業務部門へのヒアリングから推測することは可能です。まずは、知識を持つ現役メンバーへのヒアリングを最優先にしてください。
Q4. 解消にかかる期間と費用の目安は？
コード規模、使用言語の数、既存ドキュメントの品質、対象範囲によって異なります。一般的なアセスメントは数週間〜数か月程度です。規模別の目安はピラー記事をご覧ください。
Q5. ブラックボックスのままクラウド移行できますか？
技術的には可能です（リフト＆シフト）。ただし、ブラックボックスはそのままクラウドに持ち込まれ、機能漏れのリスクが高くなります。少なくとも移行対象の範囲は、移行前に可視化しておくことをおすすめします。
まとめ
システムの知識は、コード・人・ベンダーの3層に存在します。ドキュメントが更新されず、知識が一部の人に集中すると、システムは徐々にブラックボックスになります。解消には、AIによるコード解析とキーパーソンへのヒアリングを組み合わせ、棚卸しから判断までの5ステップを進めるとともに、再発を防ぐ仕組みが欠かせません。最初の一歩は、自社におけるシステムのブラックボックス化の度合いを正しく測ることです。
