日立とOpenAI、古いコードの理解から移行検証へ

コードの解析から移行テストまで

日立の公式発表では、両社のForward Deployed Engineers（FDE）が連携し、Codexを用いたAIモダナイゼーションの手法確立に取り組むと説明する。既存コードをもとに上流の仕様を可視化し、新システムへの移行テストまでを支えるソリューションを開発する方針だ。

成果は「モダナイゼーション powered by Lumada」に組み込み、金融機関をはじめ幅広い産業へ順次提供する予定としている。したがって、発表だけで、あらゆる顧客システムの移行が完了した、あるいは一定の時間短縮が実測されたと解釈することはできない。

FDEは、利用する現場に近い位置で実装を進める技術者の体制として理解できる。基幹システムには、文書に書かれていない運用や、例外処理の積み重ねがある。AIによるコード解析と、現場の業務知識を結び付けることが、今回の取り組みの要点になる。

古いコードは、仕様のすべてではない

ここからは編集部の考察だ。コードが現在の動作を表していても、その動作が本来の業務要件と一致しているとは限らない。過去の暫定対応や、利用されなくなった分岐が残る場合もある。AIが動作を説明した結果を、そのまま新システムの正式な仕様にするのは慎重であるべきだ。

移行では、コードから読み取れた事実、運用担当者が確認した要件、今後変更する判断を分けて記録したい。入力と出力の例を保存し、日次・月次の処理、障害時の手順、外部システムとのやり取りまで照合する。見た目が新しくなったことより、必要な業務が同じ条件で成立することが重要だ。

また、AIが生成したテストだけでは、元のコードの誤った前提を引き継ぐ可能性がある。既存の業務上の検査、実際の処理記録、担当者が把握する例外を併用し、別の根拠から確かめる工程が必要になる。移行速度と検証の独立性は、同時に設計したい。

防御用モデルへのアクセスも段階がある

もう一つの柱として、日立はOpenAIのTrusted Access for Cyber（TAC）を通じ、サイバーセキュリティ向けAIモデルへのアクセス取得を予定すると説明した。Daybreakに基づく防御重視の枠組みのもと、安全策、ガバナンス、人による監督を前提に、脆弱性の特定、優先順位付け、修復、検証などを検討するという。

ここでも「取得する予定」「活用を検討する」という段階の表現が大切だ。利用できるモデル、対象システム、許可された操作の範囲を確認せず、攻撃や自動修正の能力を一括して利用可能と捉えることはできない。

日立は、自社で先に実践するカスタマーゼロの取り組みを通じ、Cyber CoEが検証するとしている。知見はFrontier AI Deployment Centerを介し、HMAXの高度化にも活用する方針だ。社内で得た結果を顧客へ展開する際には、業種やシステム構成による違いも改めて検証する必要がある。

日本企業が先に整えられること

AIによる刷新を検討する企業にとって、すぐ始められるのは本番コードの一括変更ではなく、対象と根拠の整理だ。リポジトリ、設計書、運用手順、データの関係、接続先を対応付ける。閲覧できる情報と変更してよい情報を分け、実行前に承認が必要な操作を決めておく。

小さな機能を対象に、解析結果を担当者がレビューし、隔離した環境でテストし、差分を確認してから移す流れなら、失敗の影響を限定しやすい。復旧方法と判断者を決めることも、AIの能力を測ることと同じくらい重要になる。

今回の連携は、AIをコード生成だけでなく、既存資産を理解し、移行を検証する工程へ広げる発表と読める。その価値を確かめるには、生成量よりも、根拠を説明できる仕様と再現可能なテストがどれだけ増えたかを見たい。

業務システムの工程分解やAI導入設計については、運営会社のRO合同会社が相談窓口を設けている。本稿は発表内容の解説で、実システムへの接続や防御モデルの利用を行ったものではない。参考報道：イノベトピア。