「足りないのはCOBOL人材じゃない」日立が説くAI時代のシステム刷新と人間の役割

従来は人海戦術に頼っていた領域にAIが入り込み、さまざまな課題が解消しつつある。レガシーシステムの刷新もその一つだ。しかし、AIをシステム刷新プロジェクトで積極的に活用している日立製作所は、「人間の力がこれまで以上に重要になる」と語る。AI時代のシステム刷新で人間が果たす役割を探る。

この記事は会員限定です。会員登録すると全てご覧いただけます。

生成AIの登場で、レガシーシステム刷新の様相が変わり始めている。

経済産業省が2025年5月に公開した「レガシーシステムモダン化委員会総括レポート」によると、レガシーシステムを保有するユーザー企業は61％に上り、大企業に限ると74％に達する。刷新が進まない要因の一つが、システムのブラックボックス化だ。改修を重ねるうちにシステムの仕様が複雑化し、それをひも解ける「システム開発時の事情を把握している人」が減ったことによりブラックボックス化が進行した。従来、この解読は人海戦術に頼るしかなかった。この状況が、生成AIの登場で変わりつつある。

ただし、生成AIは全ての課題を解決する「魔法の杖」ではない。顧客企業のレガシーシステム刷新に生成AIを積極的に利用している日立製作所は、生成AI登場後も引き続き、「人間のエンジニアが果たす役割は大きい」と強調する。

同社の三部良太氏（研究開発グループ システムイノベーションセンタ デジタルエコノミー&コミュニティ研究部 プロジェクトマネージャ）は「AIやツールが進化しても、全体を見渡して設計する力、本番を見据えて何が必要かを見極める力はさらに大切になっていきます」と語る。

大企業におけるレガシーシステム刷新は、予算も人手も時間も膨大にかかる大規模プロジェクトだ。失敗が許されないプロジェクトにおいて、生成AIはどのように使われているのか。そして生成AIを活用するに当たって、なぜ人間の力が「さらに大切になる」のか。日立への取材を通じて、レガシーシステム刷新における生成AI活用の現在地と、AI時代のシステム刷新で人間が果たす役割を探る。

三部氏はAIがもたらした変化をこう説明する。「以前は有識者に聞きながら人海戦術で実施していたことが、AIの力を借りることで、手が届くようになりつつあります」。生成AIによって解消しつつあるのは、ブラックボックス化した仕様を「ひもとく手間」だ。

具体的には、ソースコードなどのシステム資産（静的な情報）から、生成AIが人の理解できる設計書を復元（生成）する「設計書リバース」が実用段階に入った。コードに書かれていないアーキテクチャや層構造を要約して抽出する技術も進んでいる。ただし、三部氏は「概念的なところまで全て分かるわけではない」と限界も認める。

「システム全体を一括で刷新しようとするのではなく、まずはブラックボックスをホワイトボックスにすることから始めます。コンサルタントによる業務分析だけでなく、システムをコード解析や動的分析にかける（プログラムを実際に動かして挙動を観察する解析手法）ことも含め、AIが思考を助けてくれるようになった。これは大きな変化です」 （三部氏）

日立による実現性の検証（PoC）では、COBOLからJavaへの変換を「COBOL設計書の生成」「Javaへの変換」「単体テストの生成・実行」の3フェーズに分けている。

対象は約1000ステップの簡単なバッチ処理で、プロンプトのチューニングを繰り返すことで変換の精度を高められたという。コードをいきなり変換するのではなく、設計書を生成するのには2つの狙いがある。AIによる変換の精度を高めることと、人が理解できる設計書を残すことで将来の「再レガシー化」を防ぐことだ。

日立は人材不足をAIによって解消するアプローチにも挑戦している。同社が2025年10月に提供を開始した「モダナイゼーション powered by Lumada」は、システム刷新の“難所”である現場の人材不足にAIエージェントを適用することで解決を図るものだ。システムと業務の双方を熟知した保守担当者の退職は、人手不足の影響を増幅させるだけでなく、レガシーシステムがブラックボックス化する要因の一つでもある。

このサービスでは、退職者が担当していた業務をAIエージェントに移植し、まずは人手の“穴”を埋める。これと並行して、その業務を支えるシステム基盤を現代的なAPIで疎結合につなぐ方式に段階的に切り替える。人手の穴をAIで埋めて時間を稼ぎながら、その間にシステム自体も次の世代に移すという、業務とIT基盤双方の変革を支援するサービスだ。

生成AIを利用することで、仕様をひもとく手間が削減され、人手の制約も解消しつつある。それでも日立製作所は、「人だからこそできる仕事がある」と語る。

日立製作所でモダナイゼーション事業の中核組織を率いる後藤恵美氏（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時代にはこれまで以上に問われることになる。

IT人材については不足が言われる一方で、生成AIの登場で、一部のIT人材の仕事はAIで代替できるのではとの議論も活発だ。AI活用が前提となる中で、システム刷新の領域で求められるIT人材とはどのようなものか。

三部氏が挙げるのは、プロジェクト全体を指揮するプロジェクトマネジャーや、システム全体の構造を設計するシステムアーキテクト、アプリケーションの構造を設計するアプリケーションアーキテクトの3つの役割だ。システムとアプリケーションの両面で、それぞれの構造を設計できる人材を組織としてそろえる必要があるという。同時に、優秀な個人の力に頼らない仕組みづくりも重視すべきだというのが同氏の主張だ。

「技術は変わりますが、『どこでつまずくか』といった積み重ねで得た知見は今後も有効です。『この時点で抽出しておくべきバグは何か』『作り込むべき観点は何か』というメソドロジーを積み重ねることが一番大事です」（三部氏）。知見を方法論として組織に蓄積すれば、経験の浅い若手も新しい開発方式に挑戦できる。

後藤氏は日立がIT人材育成で重視している資質についてこう語る。「単に技術を知っていて質問に答えられればいいのではありません。対面しているお客さまの課題を解決してこそ意味がある。たくさんのメソドロジーやソリューションが存在する中で、自社のものだけでなく他社のものも含めて課題を解決していく力を一番大事にしています」

日立は、こうした生成AIの活用に加え、直近では設計や運用における判断ノウハウを形式知化し、AIと組み合わせることで再利用可能にしている。さらに、AnthropicやOpenAIなどのフロンティアAIを活用し、モダナイゼーションの取り組みをさらに進めている。

このように生成AIは今、ブラックボックスをひも解き、ノウハウを形式知化することでモダナイゼーションに関わる作業を属人化させない手立てを提供している。一方で、システムのどこをどのように変え、システム全体の責任を誰が持つかを決めるのは、今後も人間がすべき重要な役割だ。また、顧客が抱える課題自体をどうひも解くかにも、人間ならではの力を発揮できる局面がありそうだ。人が課題を語るとき、その背景に本人が意識していない重要な要素が潜んでいるケースは多い。どの課題を拾い上げて、システムモダナイズの目的をどのように設定すべきか――。システム開発の要の部分で人間が果たすべき役割の重さは今後も不変だ。

後編では、レガシー刷新の現場で、生成AIが実際にどう使われているのかに踏み込む。大規模プロジェクト最大の難関として知られる工程に、日立はどのようにAIを適用しているのか。ユーザー企業自身もAIを使いこなす時代に、ベンダーが果たすべき役割に迫る。

Copyright © ITmedia, Inc. All Rights Reserved.