経済産業省が2025年5月に公開した「レガシーシステムモダン化推進委員会総合レポート」によると、レガシーシステムを保有するユーザー企業は61%に上り、大企業に限ると74%に達する。更新が進まない要因の一つが、システムのブラックボックス化だ。修正を重ねるうちにシステムの仕様が複雑化し、それを解きほぐす「システム開発時の情報を把握している人」が減ったことでブラックボックス化が進行した。従来、この解読は人海戦術に頼るしかなかった。この状況が、生成AIの登場で変わりつつある。
生成AIがもたらした変化と限界
しかし、生成AIは全ての問題を解決する「魔法の杖」ではない。日立製作所（以下、日立）は、生成AI登場後も引き続き「人間のエンジニアが果たす役割は大きい」と強調する。同社の三浦良造氏（研究開発グループ システムイノベーションセンタ デジタルエコノミー&コミュニティ研究部 プロジェクトマネージャー）は「AIやツールが進化しても、全体を見渡して設計する力、本番を見極めて何が必要かを見極める力はさらに大切になっていきます」と語る。
大企業におけるレガシーシステム更新は、予算も人手も時間も莫大にかかる大規模プロジェクトだ。失敗が許されないプロジェクトにおいて、生成AIはどのように使われているのか。そして生成AIを活用するに当たって、なぜ人間の力が「さらに大切になる」のか。日立への取材を通じて、レガシーシステム更新における生成AI活用の現状と、AI時代のシステム更新で人間が果たす役割を探る。
「生成AIはレガシー問題の何を解決したのか」
三浦氏はAIがもたらした変化をこう説明する。「以前は有識者に聞きながら人海戦術で実施していたことが、AIの力を借りることで、手が届くようになりつつあります」。生成AIによって解消しつつあるのは、ブラックボックス化した仕様を「はみとく手間」だ。
具体的には、ソースコードなどのシステム資産（静的な情報）から、生成AIが人の理解できる設計書を復元（生成）する「設計書リバース」が実用段階に入った。コードに書かれていないアーキテクチャや構造要件を要約して抽出する技術も進んでいる。ただし、三浦氏は「概念的なところまで全て分かるわけではない」と限界も認める。
「システム全体を一気に更新しようとするのではなく、まずはブラックボックスをホワイトボックスにすることから始めます。コンサルタントによる業務分析だけでなく、システムをコード解析や動的分析（プログラムを実際に動かして挙動を観察する解析手法）にかけることも含め、AIが思考を助けてくれるようになりました。これは大きな変化です」（三浦氏）
COBOLからJavaへの変換PoC
日立による実現性の検証（PoC）では、COBOLからJavaへの変換を「COBOL設計書の生成」「Javaへの変換」「単体テストの生成・実行」の3フェーズに分けている。対象は約1000ステップの簡単なバッチ処理で、プロンプトのチューニングを繰り返すことで変換の精度を高められたという。コードをいきなり変換するのではなく、設計書を生成するのには2つの狙いがある。AIによる変換の精度を高めることと、人が理解できる設計書を残すことで将来の「再レガシー化」を防ぐことだ。
日立は人材不足をAIによって解消するアプローチにも挑戦している。同社が2025年10月に提供を開始した「モダナイゼーション powered by Lumada」は、システム更新の「難所」である現場の人材不足にAIエージェントを適用することで解決を図るものだ。システムと業務の双方を熟知した保守担当者の退職は、人手不足の影響を増幅させるだけでなく、レガシーシステムがブラックボックス化する要因の一つでもある。
このサービスでは、退職者が担当していた業務をAIエージェントに移管し、まずは人手の「穴」を埋める。これと並行して、その業務を支えるシステム基盤を現代的なAPIで疎結合に繋ぐ方式に段階的に切り替える。人手の穴をAIで埋めて時間を稼ぎながら、その間にシステム自体を次の世代に移すという、業務とIT基盤双方の変革を支援するサービスだ。
生成AIを利用することで、仕様をはみとく手間が削減され、人手の制約も解消しつつある。それでも日立製作所は、「人だからこそできる仕事がある」と語る。
「足りないのはCOBOL人材じゃない」
日立製作所でモダナイゼーション事業の中核組織を率いる後藤敏彦氏（AI＆ソフトウェアサービスビジネスユニット Head of Modernization CoE）は、レガシー問題の本質をこう指摘する。「足りないのはCOBOL人材ではありません。現行システムがなぜそうなっているのか、業務がどうなっているのかを知る人材が減っていることが一番の問題です。そこに手をつけず、単にコードをそのまま変換するだけでは、リスクは残ったままになってしまいます」
この問題の背景には日本のIT産業の構造がある。日立コンサルティングの梶山真弓氏（チーフグローバルマーケティングオフィサー）は、「日本企業のレガシー問題がここまで深刻化したのは、『失われた30年』の間、ずっと部分最適でコストを最小限に抑えてシステム修正を続けてきた結果です」と指摘する。
日本のIT人材はユーザー企業よりもITベンダー側に多く存在している。ユーザー企業が開発を外部に委託する体制と、部分最適のシステム修正が長く続いた。この結果、システムがブラックボックス化し、加えてシステム処理が複雑に絡み合って解きほぐせない「スパゲッティ状態」になった。「今や誰も運用を保証できなくなりつつあります」（梶山氏）
だからこそ、AIによる解読だけでシステム更新は完結しない。後藤氏が重視するのが、業務とITのマッピングだ。どの業務がどのシステム（あるいはどの処理）に支えられているのかを一つ一つはみ付け、業務側とシステム側の地図を重ね合わせる作業を指す。
後藤氏はこう説明する。「日立コンサルティングがお客様の業務内容を分析し、われわれ日立のエンジニアリング＆デリバリー部門がシステム資産から生成AIなども使いながらシステム構造を明らかにします」（後藤氏）
業務側はコンサルタントが「全社の業務はこう構成されているはず」と上から下に整理する（トップダウン）。一方、IT側はソースコードや稼働ログといった現物の細部から積み上げて全体構造を推定する（ボトムアップ）。この2つを突き合わせ、「この業務はどのシステムが支えているのか」を1対1で対応付ける。
AIがボトムアップで明らかにしたシステム構造と、人間がトップダウンで分析した業務を突き合わせると、「このシステムは何のために動いているのか」が見えてくる。機能の重複が見つかれば、統合するか、2つのまま維持するかという問いが生まれる。統合には大きな痛みが伴う。この判断を下せるのは経営者だけだ。
もう一つ、人間にしか担えない領域として後藤氏が挙げるのが、「意図」の解釈だ。「仕様書にプログラムと同じことが書いてあればいいのではなく、『なぜそう設計するのか』という意図が一番大事です。そこが書かれないまま担当者が退職などで去ってしまうと、『なぜこのシステムが作られたのか』という理由が分からなくなってしまいます」（後藤氏）
例えば、「この処理は土日に動かせる」「この項目は手入力を残す」といった一見不自然な仕様の裏には、当時の業務上のやむを得ない事情や、過去に発生した事象の再発防止策が隠れていることがある。何のための処理かを知らないまま同じ動きをするコードに置き換えるだけでは、変えてはいけない業務ルールに抵触したり、更新後に事象が発生したりするリスクが残る。
AIは「どうなっているか」を復元できるが、当時のビジネス背景から「なぜそう作ったか」を解釈し、将来の業務にどう生かすかを考える仕事は人間ならではのものだという。
アーキテクチャ設計力の重要性
そして三浦氏が「今日一番伝えしたい」と強調したのが、冒頭の発言に繋がるアーキテクチャ設計力だ。三浦氏は、コードの変換率を100%にすることが目的ではないと断言する。AIが生成したコードがそのまま本番稼働できる品質に達しているか、システムのどこにAIを使うのが最適かという判断こそが重要だという。
「ここは生成AIで行く、ここはロジックをバシッと組む、データアクセスはゼロから作った方がきれいだ――。こうした要素を組み合わせて設計することで、今後の業務変化にも柔軟に対応できる構造を作ります」（三浦氏）
クラウドの普及で、アプリケーションとインフラの境界は曖昧になり、「動かすだけ」なら容易に実現できるようになった。しかし本番の運用に耐える性能や品質をどう確保するかという視点を持つことは、AIが代わりにできない最大のものだ。三浦氏は「早い段階で品質を確保する『シフトレフト』の考え方や、非機能要件も含めた処理方式を見ることが重要です」と語る。
シフトレフトには、後工程で発覚する重大な不具合を防ぐ狙いで、本来は開発の後半で実施するテストや品質検証を、設計や実装の早い段階に前倒しする考え方だ。「非機能要件」とは、「振り込み処理を実行する」「請求書を発行する」といったシステムが何をするかを決めた「機能要件」に対し、どれだけ速く動作するか、どれだけ多くの同時利用に耐えるか、どれだけ落ちにくいか、誰がどう運用・保守するかといった、システムを長く安定して動かすために欠かせない品質や運用上の条件を指す。非機能要件は、AIが書いたコードを並べただけでは満たせない。性能や品質まで見渡して全体を設計する力が、AI時代にはこれまで以上に問われることになる。
AI時代の人材育成 日立が重視するもの
IT人材については不足が言われる一方で、生成AIの登場で、一部のIT人材の仕事はAIで代替できるのではとの議論も活発だ。AI活用が前提となる中で、システム更新の領域で求められるIT人材とはどのようなものか。
三浦氏が挙げるのは、プロジェクト全体を指揮するプロジェクトマネージャーや、システム全体の構造を設計するシステムアーキテクト、アプリケーションの構造を設計するアプリケーションアーキテクトの3つの役割だ。システムとアプリケーションの両面で、それぞれの構造を設計できる人材を組織としてそろえる必要があるという。同時に、優秀な個人の力に頼らない仕組みづくりも重視すべきだというのが同氏の主張だ。
「技術は変わりますが、『どこでつまずくか』といった積み重ねで得た知見は今後も有効です。『この時点で抽出しておくべきバグは何か』『作り込むべき観点は何か』というメソドロジーを積み重ねることが一番大事です」（三浦氏）。知見を方法論として組織に蓄積すれば、経験の浅い若手も新しい開発手法に挑戦できる。
後藤氏は日立がIT人材育成で重視している資質についてこう語る。「単に技術を知っていて質問に答えられればいいのではありません。対面しているお客様の問題を解決してこそ意味があります。たくさんのメソドロジーやソリューションが存在する中で、自社のものだけでなく他社のものも含めて問題を解決していく力を一番大事にしています」
日立は、こうした生成AIの活用に加え、直近では設計や運用における判断ノウハウを形式知化し、AIと組み合わせることで再利用可能にしている。さらに、AnthropicやOpenAIなどのフロンティアAIを活用し、モダナイゼーションの取り組みをさらに進めている。
このように生成AIは今、ブラックボックスをはみ解き、ノウハウを形式知化することでモダナイゼーションに関わる作業を属人化させない手立てを提供している。一方で、システムのどこをどのように変え、システム全体の責任を誰が持つかを決めるのは、今後も人間がすべき重要な役割だ。また、顧客が抱える問題自体をどうはみ解くかにも、人間ならではの力を発揮できる局面がありそうだ。人が問題を語るとき、その背景に本人が意識していない重要な要素が潜んでいるケースは多い。どの問題を拾い上げて、システムモダナイズの目的をどのように設定すべきか――。システム開発の要の部分で人間が果たすべき役割の重さは今後も不変だ。
後編について
後編では、レガシー更新の現場で、生成AIが実際にどう使われているのかに迫る。大規模プロジェクト最大の難関として知られる工程に、日立はどのようにAIを適用しているのか。ユーザー企業自身もAIを使いこなす時代に、ベンダーが果たすべき役割に迫る。
