このページの本文へ

チームでAIを使えば、レガシーマイグレーションも楽しいぞ!

基盤も古いし、コードも酷い! そんなクエストにGitHub Copilotで試行錯誤しまくった「みんな」こそ最高

2026年05月11日 11時00分更新

文● 大谷イビサ 編集●ASCII 写真●曽根田元

  • この記事をはてなブックマークに追加
  • 本文印刷

「リライト」か「リビルド」か。それが問題だ(NTTデータグループ)

 トップバッターのNTTデータグループは、おそらく四半世紀前のJavaを知らない若いメンバー5人で参加。まずは対象の書店システムの課題を「ECの販売画面や検索機能の改修に時間がかかり、販売機会を逃している」と仮定し、売上向上につながる機能の追加・改善を迅速に行なえるアーキテクチャに移行するという目的を設定した。

NTTデータグループ 技術革新統括本部 AI技術部 主任 小野寺智春氏

 その上で、GitHub Copilotを活用しながらモダナイズ手段として2つの手段を検討した。既存機能を活かしながら、品質と変更容易性を高める「リライト」と、アーキテクチャやUXを抜本的に解決する「リビルド」だ。両者のメリット・デメリットを整理した結果、チームが選択したのは後者のリビルド。「JavaやAntなどEC基盤の技術負債が大きく、段階的改修では根本的な解決に至らないため、リビルドを選択した」という背景だ。

 作業は3ステップで実施。最初のスコープ分析では、基盤と業務の影響を分析した結果、業務ロジックやデータベースに手を入れるのは最低限にし、基盤のフレームワーク移行に専念することに。次のステップではGitHub CopilotのAIコーディングを用いて、AntをMavenに、Java 5はJava 21にバージョンアップし、フレームワークをSpring化。フレームワーク移行を行なっても、現行システムと変わらない書籍検索が実現できたことをテストで確認できたという。

 並行して品質改善のためのリファクタリングも実施したが、フレームワーク自体の移行を優先したため、どこまで手を入れるのかの判断が難しかった。基盤自体の入れ替えまでは進めたので、今後は順次業務への影響を抑えつつ、モダナイズを進めていくという方針を示して発表を終えた。ちなみにスライドもGitHub Copilot、Skills、Claude Opusで作成したという。

 NTTデータグループのプレゼンにコメントしたのはBIPROGYの富永 陽一氏。「最初にリビルドでいくか、リライトでいくかの方針を決め、スコープを決めるという流れで進めたということで、納得感のあるプレゼンだった。若手のみなさまにとって苦手なレガシーシステムの移行も、GitHub Copilotで楽になることが実感できたのではないか」とコメントした。

BIPROGYの富永 陽一氏

GitHub Copilotと試行錯誤を重ねながら挑戦(アバナード)

 初参加のアバナードは4名のチーム。GitHub Copilotを業務で使った経験ある3人はJava初心者で、GitHub Copilot経験のない残り1人はJava 3年生だ。GitHub Copilotに作ってもらったチーム名は、AvanadeとAdventuresを合体させた「AvaVentures」だという。

アバナード コンサルタント 岩井佑介氏

 GitHub Copilotが初心者・初参加のチームに提案したゴールは全面刷新ではなく、段階的な移行だった。比較的独立していて利用頻度も高い「書籍検索」という単一機能のみを切り出し、コンテナ上にモダンアプリとしてデプロイ。機能ごとにレガシーと使い分ける構成を目指した。モダンアプリはクラウド上にデプロイ。このユースケースで進め方をイメージできるようにし、他の機能のモダナイズに活かしていこうという方針だ。

 モダンアプリはJavaを5から21に上げ、フレームワークをSpring化。テンプレートをJSPからThymeleafへ、ビルドをAntからMavenへ、ORMもHibernateからSpring Data JPAに変更し、コンテナ上にデプロイした。その上でリクエストは、NGINXがURLパスごとに振り分ける。書籍検索を利用する場合は、Spring Bootベースのモダンアプリ、その他の機能はStrutsベースのレガシーアプリに分けるという方法をとった。プロジェクト構成やテストコードもGitHub Copilotの指示に従って実装。改善の余地はあるものの、画面もリニューアルしたという。

 かなりヘビーにGitHub Copilotを使い込んだアバナードのチームだったが、振り返ると「GitHub Copilotを使いこなすことに試行錯誤し、時間をとってしまった」というのが感想だった。特にコンテナ周りの設定やデバッグでは、GitHub Copilotで把握できない情報があったため、はまってしまったという反省。とはいえ、GPT-5.1-CodexやClaude Opus4.5など異なるモデルで提案が異なっていたり、課題の抽出やクラス図の作成、GitHub Codespaces特有のエラー対応など、さまざまな場面でGitHub Copilotが役に立つことを体感できたとのこと。

 GitHub Copilot Quest全体の感想も披露された。まずは「Javaを知らないチームでも、GitHub Copilotを使えばなんとかなる。とても頼もしい存在」という感想。また、直前にプレゼンしたNTTデータグループで実施していた現新比較の重要さを理解するとともに、できることが多すぎるためスコープを設定する必要があったという反省もあった。登壇したアバナード コンサルタント 岩井佑介氏は、「時間が足りなくて、やりきることができなくて悔しかった。でも、初対面・初心者のメンバーとGitHub Copilotとで肩を組めた」とまとめた。

 NECソリューションイノベータ 小川 英孝氏のコメントパートは、質問中心となった。「GitHub Copilotの出力したコードを誰が評価したのか?」「Java 21の挙動はどのようにチェックしたの?」「エージェントやスキル、インストラクションなどは作ったのか?」などと鋭い質問を投げかけつつ、チームメンバーにアドバイスを送るという展開。まるで同じ会社の上司と部下のようなリアルなやりとりが新鮮だった。

NECソリューションイノベータ 小川 英孝氏

カテゴリートップへ

本記事はアフィリエイトプログラムによる収益を得ている場合があります

  • 角川アスキー総合研究所