設計書なし、作った人は退職済み、一部はソースすら消えてDLLだけ——。そんな30年物の住宅ローンシステムを、AIを使ってJava/React/PostgreSQLへ移したという発表が出ました。香港に本社を置く中国系IT企業の華欽科技（CLPS）が、国際的な大手銀行向けに行った案件です。
面白いのは、AIに「いきなりコードを変換させた」話ではない点です。まずAIにソースから設計書を逆生成させ、人が検証し、その設計書からテストを作る。この順番が、日本の「仕様書が残っていない社内システム」にもそのまま使えます。
ケースの規模（ソース記載の数字のみ）
2026年8月20日の完了発表によると、移行元は次のとおりです。
- Visual Basicの機能プログラム138本、MS Accessプログラム248本
- 帳票315本、レター（差し込みWordテンプレートを含む）114本
- バッチジョブ303本、COBOLプログラム25本、ストアドプロシージャ841本
- 合計70万行超のコード
移行後は以下のとおりです。
- オンライン：VB/Accessの386本をJava＋Reactへ（約44万9,732行）
- バッチ：Javaのプロセス、Jasper Reports、Wordテンプレート、PostgreSQLストアドへ（約53万5,131行）
- データ：MS SQL ServerとVSAMの1,124テーブルをPostgreSQLに再構築
- 新システムの総量は約98万4,863行
体制は20名余りの開発者で、期間は16か月でした。当初の見積もりは「80名で約5年」だったとしています。
なお、2025年9月の第1報では「7か月・20名余り」「コード自動変換率70%」「従来手法なら40〜50名で2年」と書かれていました。完了発表とは数字が異なりますが、その差の理由はソースに説明がありません。
手順（そのまま真似できる形で）
1. AIでソースから設計書を逆生成する
独自ツール「Know Your System（KYS）」で、LLMにソースを解析させ、機能説明書を自動生成します。
2. 言語の専門家が設計書を検証する
最初の正確度は約80〜90%でした。これを反復して改善し、98%まで上げたとしています。「AIの出力をそのまま正とみなさない」ゲートが、ここに置かれています。
3. 読者別に2種類の文書にする
開発者向けの技術文書と、業務部門向けの業務説明書に分けて整理します。
4. 設計書からテストを生成する
検証済みの文書をもとに、AIでSIT・UAT・回帰テストのケースを生成します。
5. 小さく区切ってアジャイルで回す
機能モジュールを反復可能な単位に分割します。AIが出した「半完成コード」と疑似コードを開発者が読み、ロジックを解読しながら実装を仕上げます。変換が進んでいる最中にも、変換済みの部分は検証を始めます。AIの読み違いを早く見つけ、終盤での大事故を防ぐためです。
6. ソースが無い部分は、類似システムから推定する
一部のVBモジュールは、コンパイル済みのDLLしか残っていませんでした。そこで、機能の似た別システムのコードを参考に、AIで業務ロジックを推定・補完しています。
自動化 vs 手作業
| AIに任せる | 人が持つ |
|---|---|
| ソース解析と設計書の逆生成 | 設計書の正確性検証（80〜90%→98%） |
| 半完成コード・疑似コードの生成（第1報では自動変換率70%） | 残りの実装、隠れた業務ルールとの突き合わせ |
| SIT/UAT/回帰テストケースの生成 | 数百の相互依存機能の整合性確認 |
チームは、PM・AI専門家・ソース解析の専門家・Java/React開発者・テスト専門家の混成でした。全員がAI前提の開発スタイルを理解していることを、成功要因の一つに挙げています。
セキュリティの作り方
金融規制とデータ保護に対応するため、AIは顧客の自社環境にオンプレミスで配置しました。機密データは第三者のパブリッククラウドに送らない構成です。第1報では、Microsoft Copilotなど「顧客が指定したAIモデル」を使ったとも書かれています。銀行や保険のように外部送信が難しい現場では、ここが最初の関門になります。
落とし穴
- AIの解析結果をそのまま仕様とみなすと、10〜20%の誤りが残ります。専門家の検証ゲートは省けません
- 巨大なコードベースは、AIが扱える単位に分割する方針を先に決めておきます。後から決めると、機能間の整合性が崩れます
- 「変換が全部終わってからテスト」にしない。変換済みの部分から順に検証します
- 発表資料の数字（期間・人数）は、第1報と完了報で変わることがあります。社内の稟議で引用するなら、日付と出典を必ず添えてください
日本の現場で使うなら：着手前チェックリスト
- 現行の資産を種類別に数えたか（画面、帳票、バッチ、ストアド、テーブル数）
- AIを動かす場所（オンプレか閉域か）と、使えるモデルを情報セキュリティ部門と合意したか
- 逆生成した設計書を検証する担当（旧言語が読める人）と、正確度の目標値を決めたか
- 設計書を「開発者向け」と「業務部門向け」に分ける運用にしたか
- テストケースを設計書から作り、回帰テストを移行の前後で回せるようにしたか
- ソースが失われたモジュールを洗い出し、代替の情報源（類似システム、画面、運用手順書）を確保したか
VB6やAccessで作られた部門システム、古いJava＋Oracleのモノリスは、日本でも「動いているから触れない」の代表格です。変換ツールを選ぶより前に、AIで“読める設計書”を作り、人が検証する工程から始めると、見積もりもテストも一気に現実的になります。
参考
- 華欽科技（CLPS）公式ニュース「华钦科技以AI成功改造国际大型银行三十年老旧系统，树立行业新标杆」— 2026-08-20
https://www.clpsglobal.com/zh/news/189/ - 同プレスリリース（PR Newswire 中国語版）— 2026-08-20
https://tools.prnewswire.com/zh-cn/live/5983/release/20260820ZH30529?filter=5983 - 同英語版「CLPS Incorporation Sets Industry Benchmark with Completion of AI-Driven Modernization of a 30-Year-Old Legacy Banking System」（AP News掲載）— 2026-08-20
https://apnews.com/press-release/pr-newswire/press-release-f7008c7351fcb14457ae10fd7df5a66b - 第1報「华钦科技借助人工智能成功改造某香港大型银行老旧抵押贷款系统」（美通社）— 2025-09-11
https://www.prnasia.com/story/503198-1.shtml