生成AIの登場により、レガシーシステム更新の課題が解消されつつある一方で、人間の役割はさらに重要になっている。前編では、日立製作所（以下、日立）のレガシーシステム更新における生成AI活用の在り方を通じ、生成AI活用の現状と、AI時代に人間が担う役割に迫った。
後編となる本稿では、レガシー更新の現場で生成AIが具体的にどう使われているのか、そして、ユーザー企業自身がAIを使いこなす時代にベンダーが担う役割を掘り下げる。
更新プロジェクトを止めずに動かすために
レガシーシステムの更新プロジェクトの現場でAIはどのように使われているのか。日立の保田晋吾氏（金融第二システム事業部 金融システム第四本部 担当本部長 兼 Modernization CoE）は、更新に取り組むユーザー企業に共通する悩みとして次の4つを挙げた。
- 画面や業務ロジック、データベース、外部システムとの連携といったシステム構成要素が強く依存し合う密結合状態になり、複雑化したことによる保守性の低下
- 修正の積み重ねで錆びついたような機能や処理が増え、システムが肥大化している
- 業務とシステムの双方を熟知した人材が高齢化し、現場から失われつつある
- 人に依存する運用のコストが増し、若手が定着しにくくなっている
これらの要素が積み重なった結果、ブラックボックス化したシステムは「どこから手を付けるべきか」の判断自体が難しくなっている。さらにシステム更新には長い期間とコストがかかるが、その間も現行業務は止められない。新基盤のシステムを並行運用するダブル体制によって、現場の人的負担も増す。
アセスメントから始める段階的更新
こうした課題が積み上がるシステム更新プロジェクトで、まず重要なのは社内の方向性を統一することだ。「更新プロジェクトを途中で止めてしまわないためにも、強いリーダーシップの下、トップダウンでプロジェクトのゴールを決めることが重要です」（保田氏）。
ゴールを決めた後も、全システムの更新にいきなり乗り出すのは現実的ではない。日立が推奨するアプローチは、現状調査と課題整理（アセスメント）から始める段階的な更新だ。同社が2025年10月から提供を開始した「モダナイゼーション powered by Lumada」は、生成AIを活用してシステムの構造や業務との対応関係、更新の優先順位、適切な移行手法を見極めるためのサービスだ。
保田氏によると、アセスメントの結果を基に作成するロードマップの前半には、事業部門が効果を実感しやすい領域を配置することが多い。具体的には、営業支援システムや顧客向け画面などの機能改善がそれに当たる。基幹システムの更新は数年単位の長期プロジェクトになるため、早い段階で目に見える成果を出す「クイックウィン」を実現することで、事業部門の協力を得やすい環境を作るのが目的だ。
「典型的なパターン」として保田氏が挙げるのは、まずマイグレーションでメインフレームからオープン系の環境にシステムを移し替え、その後のモダナイゼーションでシステムの構成や処理の作り方を見直す「2段構え」だ。移行と更新の実施時期をずらすことで、現場の負担とリスクを分散する狙いがある。
プロジェクト最大の「難所」、AIで何が変わった？
この後に待ち受けているのが、更新プロジェクトの「難所」である更新の実行フェーズだ。日立はこれらの工程で生成AIをどのように使っているのか。
本題に入る前に、用語の意味を整理しておきたい。システム開発の品質を保証する代表的な考え方に「V字モデル」がある。設計工程（要件定義、基本設計、詳細設計）を左側に、それぞれに対応する検証工程（単体テスト、結合テスト、システムテスト）を右側に配置し、V字型に並べて両者を対応付ける開発モデルだ。単体テストは1つのプログラムが仕様通りに動くかどうか、結合テストは複数のプログラムをつないだときに想定通り動くかどうかを確認するためのものだ。
レガシーシステムの更新で特に重要になるのが「現新結合テスト」だ。これは、現行システムと新システムに同じ条件を与えて実行し、出力結果が一致するかどうかを確認するテストを指す。レガシーシステムの仕様書には現状が反映されていないケースが多く、「現行システムと新システムが同じ動きをすること」自体が品質保証の根幹になる。
日立の中島知也氏
加えて、V字モデルの「右側」である検証工程には生成AIが組み込まれている。同社の中島知也氏（アプリケーションサービス事業部 テクノロジートランスフォーメーション本部 AIソフトウェアエンジニアリング部 兼 Modernization CoE）はこれについて次のように説明する。
「従来はプログラムを実行せずに、コードの書き方や静的なバグを機械的にチェックする『静的解析』と、人の目によるレビューを組み合わせてレビューを実施してきました」。現在、日立は生成AIを「1段階目のレビュー」として加え、人によるレビューはより重要な観点に集中させている。
ここで、生成AIに品質保証の一部を任せて大丈夫なのかという懸念が生まれる。「生成AIの出力が100％正しいとは保証できません。しかし、これは人によるレビューも100％正しいと保証できないのと同じです」（中島氏）。
人とAI双方のレビューを実施することで、全体の網羅性を高めていく。こうした人とAIを補完的に組み合わせる発想に基づき、日立は品質保証のプロセスを設計している。
最難関「現新結合テスト」にAIをどう適用するか
更新プロジェクトで最も難しい工程の一つが、先に説明した現新結合テストだ。単体テストや結合テストは、仕様書から「この入力に対してはこういう出力になるはず」というテストの条件と確認内容（テストケース）を作れる。しかし、レガシー更新では、業務仕様がブラックボックス化しているために、そもそも「何を期待する結果とするか」を仕様書から導けないケースが多い。
そのため、現新結合テストでは本番に近いトランザクションデータを使い、現行システムと新システムの両方を動かして結果を突き合わせる方法を取らざるを得ない。出力が一致しなかったときに、原因が新システムの不具合なのか、それとも現行システムの古いバグを新システムが意図せず修正してしまったのか、人が一つ一つ目視で追っていく。膨大な工数がかかるからこそ、現新結合テストは「難所」と呼ばれている。
この工程にも、日立は生成AIの適用を試みている。仮想的な実行環境で現行システムと新システムを動かし、不一致が起きた箇所とその原因候補を生成AIに提示させる仕組みだ。これにより、原因調査の効率化を図る。
それでも残る、人の手による設計
生成AIの活用が進む一方で、更新プロジェクトには人の手でしか進められない領域もある。その中で代表的なのが「処理方式設計」だ。システム全体をどのような制御方式で動かすか、性能や障害対策をどう作り込むかを決めるもので、システム開発における上流工程に当たる。
特に難しいのは、メインフレームベンダー独自のミドルウェアが絡む部分だ。仕様書が非公開の機能に対し、日立はまず既存ドキュメントの解析や有識者へのヒアリングを徹底して仕様を可視化する。その上で、どうしても埋めきれないブラックボックス部分に限り、外部からの動作調査で仕様を補っている。
「外部の振る舞いとしてどういう動作をしているかをヒアリングや調査で確認し、そこから再設計しています」（保田氏）。
内部の処理ロジックがブラックボックス化している場合、外から観測できる入出力や応答を手がかりに、新しい環境で同じ振る舞いを実行する設計に落とし込む。この際、どのように再設計するかという判断は、AIではなく人が下す必要がある。
更新後に始まる「再レガシー化」をどう防ぐか
ここまで、更新プロジェクトを動かす上での組織課題と、開発・検証工程での生成AI活用を見てきた。しかし、レガシーシステム更新は、新しいシステムを稼働させて終わりではない。
保田氏は「更新後のシステムが再びブラックボックス化してしまうケースもあります」と語る。再レガシー化を防ぐには、更新のタイミングで「土台」を作っておく必要がある。
保田氏が語る、再レガシー化を防ぐための「3つの土台」は次の通りだ。
- 疎結合を前提としたITデザインの統一：疎結合とは、システムの構成要素を緩やかにつなぎ、一部の変更が他の部分に波及しにくい状態を指す。技術的に疎結合な構造を採用することと併せて、全社でシステムを統一することも重要だ。各部局でシステムを導入、運用するために設計思想がバラバラになれば、認証方式やデータ連携の方式が統一されにくくなる。こうした状況を放置すると、全社で見たときにシステム間の依存関係が強まり、再び密結合な状態に戻ってしまう。これを避けるため、部局横断でITデザインを統制する仕組みを組み込む必要がある。
- 定期的なアーキテクチャの見直し：システム全体の構造や設計方針（アーキテクチャ）は、業務の変化や新しい技術の登場により、実態と徐々に乖離していく。定期的に見直し、現状を更新する運用ルールを更新時に決めることで、アーキテクチャ図と実態が一致している状況を保つ。
- データ活用とのセット設計：更新したシステムから、業務の利用状況やシステムの稼働状況を自動的に収集する仕組みを整備する。この仕組みによって、「どの業務にどのシステムがよく使われているか」「どこに性能のボトルネックがあるか」をデータで把握できる。人の勘に頼った運用に先手を打たせないために重要な仕組みだ。
これら3つの土台を実効性のあるものにするため、日立が力を入れているのが「マイグレーションナレッジベース」だ。保田氏によると、過去のプロジェクト管理書から基本設計書、テスト計画までの成果物を蓄積することで、生成AIによって必要な情報を引き出せるようにした仕組みだ。属人化していたノウハウを組織の資産として残し、更新後も知見が個人に張り付かない形に整える狙いがある。
AI時代ならではの「新しいブラックボックス化」
AI時代のリスクとして保田氏が挙げるのが、生成AIが新たなブラックボックスを生むことだ。同氏は多くの組織が抱えがちなリスクとして、次の2つを挙げる。
「1つ目が『闇鍋AI』の乱立です」（保田氏）。営業部門が契約書要約用の生成AIサービスを独自に契約し、経理部門はまた別サービスを使っている企業もある。IT部門の知らないところでAIツールが導入されることで、誰がどのデータをAIツールに送っているのか、AIの出力結果を業務でどのように利用しているのかが見えなくなる。
「2つ目がプロンプトの属人化です」（保田氏）。生成AIで質の高い出力結果を得るためにはプロンプトを作り込む必要があるが、そのノウハウは共有されないことが多い。特定の業務担当者が編み出した優れたプロンプト構築のノウハウが、担当者の異動や退職とともに失われれば、出力の精度が維持できなくなる。COBOL人材の不足や、システム有識者の枯渇と同じ問題が生まれているわけだ。
「こうした『新しいブラックボックス化』を防ぐには、AIの活用とAIのガバナンス（組織として統制する仕組み）を切り離さず、設計と運用の両面でセットにする必要があります」（保田氏）。具体的には全社で使うAIサービスの選定基準やデータ連携のルール、プロンプトを組織の資産として蓄積する仕組み、AI出力の品質をチェックする体制などを更新プロジェクトで設計すべきだ、と同氏は話す。
ここで重要なのは、AIに関するガバナンスはベンダーに丸投げできないという点だ。どの業務にAIを使い、どの判断を人が下すかは、自社の業務を熟知しているユーザー企業自身が決めるべきものになる。
AI時代にベンダーが担うべき役割とは
ここである問いが浮かび上がってくる。再レガシー化を防ぐためにも、ユーザー企業がシステム更新とAI活用に主体的に取り組むべきだという機運が加速したとき、ベンダーが担うべき役割は何か。
今回の取材から見えてきたのは、ベンダーの仕事の重心が下流工程から上流工程へと移りつつある姿だった。
ここまで見てきたように、テストの一部やコーディングといった下流工程では、生成AIによる代替が急速に進んでいる。
こうした中で、ベンダーが担う役割として中島氏が挙げるのが、システムを「どう作ったか」を組織に残す仕事だ。
「この業務でこういう処理を実現したい」といった業務的な要件を実装にどのように落とし込むか、システムがどう動くのかを可視化して残す仕事は、システムを作ったベンダー側にしか担えない。「『このシステムはこういう設計の意図で作られている』というところを残すのが、我々ベンダーの責任です」（中島氏）。
加えて、AI時代にベンダーが担う役割としての比重を増しているのが、上流工程の人材育成だ。例えば、現状調査と課題整理から更新の方向性を示すアセスメントや、「どのシステムから更新すべきか」「どの業務にAIを導入すべきか」といった方向性の提案は、業務側とシステム側の双方を理解し、両者を橋渡しできる人材でなければ務まらない。
「効率化による値引き」ではなく「業務転換の共創」へ
ベンダーの役割が変われば、ユーザー企業との関係性とビジネスモデルも変わらざるを得ない。AIで開発工程が効率化される中で、ユーザー企業から「効率化できるなら、その分の費用を下げてほしい」という反応も出てくるだろう。
これに対し、保田氏はベンダーの提供価値は効率化に留まらないと語る。AIを使った更新プロジェクトの過程で、日立側にはユーザー企業のシステムと業務に対する深い理解が蓄積される。この知見を業務変革の支援に振り向けたい、というのが同氏の構想だ。
「まずスケジュール短縮や品質向上というAI活用のメリットを提供します。その上で、AIで蓄積したノウハウを活用して、お客様の業務のあり方の再構築に向けて、共創するパートナーとして活動したいと考えています」（保田氏）。
この取材後、日立はAnthropic（注1）やOpen AIといったAIベンダーとの協業を発表した。モダナイゼーションにAIを適用するスピードはさらに加速しそうだ。
現在、受託開発から共創パートナーに、日立以外も含めて多くのベンダーがその立ち位置を移行しようとしている。ベンダーが担う役割は、システムを作ることから、ユーザー企業の業務変革、そして事業変革の実現に重心が移りつつある。
ユーザー企業からすると、パートナー企業と今後、どのような関係を築くべきかが重要になる。今後も受託開発の依頼先を求めるのか、共創パートナーとしていくのか、それともシステム開発を内製化に切り替えて、パートナー企業には人材育成の支援を求めるのか――。どの選択肢を取るにしても、ベンダーがAIをどのように活用しているかがパートナー選びの判断を大きく左右することは間違いなさそうだ。
（注1）日立はAnthropicと組んで何を図るのか 従業員29万人へのClaude導入で目指す姿
