AIにコードは書かせない――レガシーアプリの自動リファクタリング“新常識”：“50億行のソースコード”をどう修正するか

開発現場でのAI技術活用が進む中、企業の喫緊の課題であるレガシーアプリケーションのモダナイゼーションでは、AIコーディングツールに直接ソースコードを書かせる以外の手法を提唱する専門家がいる。どのような仕組みなのか。

[Cliff Saran，TechTarget]

　リファクタリングツールベンダーModerneのCEO兼共同創設者であるジョナサン・シュナイダー氏は、プログラミング言語および開発・実行環境「Java」のバージョンアップに伴うプログラム移行について、企業が採用しがちなアプローチは「持続不可能」だと指摘する。

　シュナイダー氏は、ある大手銀行との対話を例に挙げる。その銀行は特定の脆弱（ぜいじゃく）性を修正するために「Java 17」への移行を迫られていた。しかしアプリケーションサーバに「IBM WebSphere Application Server」を採用していたため、「Java 8」からのアップデートができずにいたという。

　この脆弱性を修正するには、代替となるアプリケーションサーバ「Apache Tomcat」にアプリケーションを移行しつつ、Javaをバージョン17にアップグレードする必要があった。「課題は、3000個ものアプリケーションを、正常な動作を維持したまま、いかに新しいバージョンのJavaで動くようリファクタリングするかという点だった」とシュナイダー氏は振り返る。

なぜモダナイゼーションはこれほど大事で大変なのか

併せて読みたいお薦め記事

レガシーシステムの課題

• COBOLをやめても消えない“亡霊”「JOBOL」とは何なのか
• “脱COBOL”を「自動化ツール」に頼り切ってはいけないのはなぜ？

　アプリケーションのモダナイゼーションはIT部門にとって悩みの種だ。予算や人手を浪費するだけではなく、パッチ（修正プログラム）未適用の古いアプリケーションがあれば、セキュリティリスクを抱えることにもなる。

　調査会社Forrester Researchが2025年7月に発表した、企業の予算運用に関するレポート「2026 Budget Planning: Prepare for Even More Volatility」は、企業が市場の変動に順応しようとしながら、レガシーアプリケーションを維持する上で直面するリスクを浮き彫りにしている。

　Forrester Researchによると、技術的負債はITシステムの運用費とリスクを増大させる一方で、新機能の提供を遅らせる要因にもなる。レポートはITリーダーに対し、技術的負債への対処を外部の専門業者に委託し、社内のIT部門が最新のITアーキテクチャや開発手法の推進に専念できる体制を整えるよう促している。

　「レガシーな技術群のモダナイゼーションを、実績のある外部業者に委託すれば、依頼費と引き換えに運用上の信頼性を確保できる」とForrester Researchは主張する。これによって企業は予算と人員をレガシーシステム以外のことに割り当てられるようになり、将来の成長を見据えた、適応力のあるAI（人工知能）技術を活用したエコシステム（複数の企業による共存共栄の仕組み）を構築できるようになるという。

従来のモダナイゼーション手法はなぜ応用性に欠けるのか

　一方でシュナイダー氏は、技術的負債の管理を社内部門と外部委託先のどちらが担うにせよ、「従来の方法ではうまくいかない」と主張する。

　シュナイダー氏の見解では、これまでのアプリケーションの改修やモダナイゼーションは、各製品の担当エンジニアに委ねられてきた。ITコンサルティング会社が、アプリケーションの保守を専門に実施する「ソフトウェアファクトリー」を立ち上げ、一度に1つずつのアプリケーション作業を進める場合があったが、このやり方もうまくいかなかったという。

　これに対してModerneは、複数のレガシーアプリケーションに共通する、横断的な課題を解決するアプローチを採用している。

　シュナイダー氏は動画配信サービス企業Netflixの出身で、オープンソースの自動リファクタリングツール「OpenRewrite」を開発した人物だ。同氏は「ソースコードを常に最新の状態に保つ」という複雑な課題に対して、独自の自動リファクタリング技術を中核としたビジネスを展開している。

　企業が作成したソースコードは、実行可能ファイルに変換され、本番環境にデプロイ（配備）された瞬間から、実質的に技術的負債と化す。「たとえアプリケーションのアーキテクチャに関して完璧な意思決定を下し、今ある中で最高のライブラリ（プログラム部品群）を選んだとしても、数カ月後にはさまざまな理由でそれが最適ではなくなってしまう」とシュナイダー氏は言う。

　Moderneのリファクタリングツールは企業のソースコードをスキャンし、それらのソースコードの完全な設計図を生成してデータベースに保存する。このデータベースに対して、開発者は「ソースコードのこの部分を変更するとどのような影響が生じるか」といった問い合わせを投げ掛けることができ、ソースコードの変更による影響を把握可能になる。

AIコーディングツールの活用と「レシピ」

　このリファクタリングツールは「レシピ」（手順書）と組み合わせることで、リファクタリング時にライブラリを自動で置き換えるようにすることも可能だ。開発者は、レシピが期待通りにソースコードを変更したかどうかを確認できる。必要であればリファクタリング前に微調整し、コードベース（ソースコード群）全体にわたって必要な変更を適用可能だ。

　これらのレシピは、大規模言語モデル（LLM）を基にした「Claude Code」などのAIコーディングツールを用いて作成できる。シュナイダー氏は以前、ある銀行の幹部から、アプリケーションをオンプレミスサーバからコンテナに移行しようとしていると聞いた。しかしアプリケーションが、稼働しているサーバのローカルストレージにログファイルを書き込んでいることが、移行の大きな障壁になっていたという。

　シュナイダー氏によると、この問題を解決するにはログファイルの構成を変更し、ログファイルをローカルストレージに書き込まないようにアプリケーションのソースコードを修正する必要があった。通常、このような修正をするためのレシピを作成するには、Moderneのリファクタリングツールの詳細な使い方を学び、レシピ開発のエキスパートになる必要がある。ところが同氏のチームは、Claude Codeを使うことによって20分で新しいカスタムレシピを作成できたという。

　「Claude Codeはさまざまなログ設定を変更し、出力先を切り替えるためのレシピを10パターンほど書き出してくれた。われわれはそのレシピを、まず9000個のソースコードリポジトリに適用し、ソースコードがどのように変更されるかを確認できた」（シュナイダー氏）

　開発者は、レシピが生成した変換パターンが有効かどうかを評価し、その結果をClaude Codeに繰り返しフィードバックすることで、類似のパターンを生成させたり、不適切と判断したパターンを改善させたりできる。

　シュナイダー氏にとってレシピとは、料理のレシピのように、ソースコード変更を適用するために段階的に従うことができる、微調整や改良が可能な一連の指示書だ。「開発者が変更内容に納得できれば、後はレシピに沿って、OpenRewriteがあらゆる場所に変更を適用してくれる」と同氏は言う。これによって試行を迅速に反復し、リファクタリングツールは素早くフィードバックを得ることができる。

　シュナイダー氏は次のように説明する。「LLMのように、同じ問いに毎回同じ答えを返さないシステムが、全てのソースコード修正を手掛けるわけではない。同じ問いに毎回同じ答えを返すシステムがレシピを作成し、そのレシピがコードベース全体に変更を加えるための確実な仕組みとして機能する」

　「本番環境に存在するソースコードの量を考えれば、IT部門には応用が利くリファクタリング手段が必要だ」とシュナイダー氏は言う。Moderneのある大口顧客は、約50億行ものソースコードを管理しているという。

　シュナイダー氏の見解では、ソースコードをLLMに読み込ませてリファクタリングする方法では、AIコーディングツールを使う採算が取れない。利用料金だけで数百万ドルに達する恐れもあるという。一方でClaude Codeをレシピ作成にのみ利用する同氏とModerneの手法は、大幅な費用削減につながる可能性がある。