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

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

AIエージェントのできることを追求　効率化を体感（NECソリューションイノベータ）

　2回目の参加となるNECソリューションイノベータは、初顔合わせの1～4年目の社員5人でチームを構成。「『またいつか』が社交辞令にならないことを祈っています」とのことで、濃密な時間が過ごせたよう。5人がそれぞれの担当部分を語る全員登壇のスタイルで成果を披露した。

NECソリューションイノベータ DXソフトウェア開発事業部門 サービスPF開発統括部　SWエンジニア 大久保翔太氏

　チームでは、機能、品質、行動の3つのゴールを設定した。機能目標は「期限内で既存アプリと同様の動きを再現できること」、品質目標はバグ修正や脆弱性改善などソフトウェアの品質を上げること。そして行動目標は、AIエージェントによる全作業の自動化を掲げた。既存機能の把握やバグの摘出や修正計画の立案はもちろん、修正の実施、成果物のレビューやテスト、デプロイまでをAIエージェントで実現するという高みを目指したという。

　これらの作業のうち、修正計画の立案までの作業に対してAIエージェントを作成できた。すなわち目標状態の定義、7段階の移行フェーズと成功条件、4段階の優先度を設定したバグの修正計画、リスク評価と緩和策などがAIエージェントのアウトプットとして実現した。バグは全部で77件抽出し、コーディングエージェントでは限られた時間内での効果を重視して、優先度の高い8件を修正したという。

　カスタムエージェントは、GitHubのawesome-copilotリポジトリを利用し、品質や分析、モダナイズに関するエージェントを検索。検出したエージェントをコード分析、バグ分析、モダナイズ提案などそれぞれの要件に合わせてカスタマイズした。エージェント同士は次のコンテキストにあわせてハンズオフの機能で連携した。計画書を作成した後は、イシュー化して、細かい粒度でコーディングエージェントに割り当て、実装を行なったという。「Webブラウザから全員で進捗管理できるので使いやすかった」という感想だった。

　今回GitHub Copilotを利用した感想としては、「一部実現できなかった部分はあったもののタスクの立ち上げ、バグの摘出、イシュー作成、コード修正、レビューまでを自動的にできる点に驚いた。しかも、一度カスタムエージェントを作成してしまえば、他のプロジェクトでも再利用できる」というものだった。

　総じて環境構築に時間がかかったが、開発自体はかなり効率化できたという。GitHub Copilot Quest全体を通しては、全員が「GitHub Copilot最強」という感想。普段GitHub Copilotを使っているユーザーも新たにエージェントの開発を学び、カスタムエージェントで開発自体を大きく効率化できたという。

　コメントを担当したNTTデータの井上大輔氏は、チームをねぎらった後、「アーキテクチャのモダナイズも行なったのでしょうか？」と質問。これに関しては、NECソリューションイノベータのチームは、Javaやビルドツール、フレームワークなどのモダナイズを実施した上で、バグの修正まで行なったと回答。これに対して井上氏は「今日1日でエージェントを探すところからやっていたのが、素晴らしい。エージェントを探すのは、体制構築みたいなところだと思っていて、エージェントがないときは、そもそも人のアサインから始めなければならなかった」とコメント。開発工程の多くの部分でエージェントに依存しつつ、きちんと使いこなしていたところを高く評価した。

NTTデータの井上大輔氏

仕様変化への説明責任と事業の安定・発展にこだわった （BIPROGY）

　6番手は初参加のBIPROGYは、デジタルエンジニアリング本部アドバンスト技術部という同じ部の4人。チームで設定したゴールは、老朽化した書店バックオフィス基盤を安全・継続成長を支える業務基盤に作り直すこと。「特に大きな投資になったり、長期管理になるプロジェクトは目的設定が大事。システム面と事業面での目標を設定した」とコメントする。

BIPROGY デジタルエンジニアリング本部 アドバンスト技術部 東佳輝氏

　システム面の課題分析では、Java 1.5/Struts/Hibernate 3/Antのレガシー構成で、JDBCやHibernate、Action内のSQLが混在し、構造が複雑な点が挙げられた。また、SQLインジェクションの対策がなかったり、CSRFが未実装だったり、いまだにMD5認証だったりといった重大な技術負債も存在していた。その他、トランザクションが不完全だったり、ログ方式が乱立していたり、メモリリークが存在していたり、障害対応や改修のコストも高いという点も課題。意図的とは言え、与えられた課題ソースコードは問題だらけだった。

　とはいえ、事業面では書籍検索や販売、カート、チェックアウト、在庫確認、発注、レポート、監査までを担うまさに書店の店舗運営の中核システムであり、現場のオペレーションに直結するため、技術的なリスクが表面化すると影響が大きいと認識。モダナイズ後に保守改修が容易になった暁には、在庫が少ない場合にアラートを上げて欠品を防止したり、日次売上、書籍別売上、トップ書籍レポートなどを活用した追加発注の最適化、カテゴリや期間ごとの販売傾向に応じた仕入れの最適化まで実現できるとビジョンを披露した。

　こうしたビジョンを示しつつ、全体をリアーキテクチャや技術的負債解消といったフェーズ1、CI/CDの構築や機能追加を実現するフェーズ2に分割。このうち今回は前者のフェーズ1を実施し、老朽化した基盤を保守可能な状態に立て直すことに専念したという。これにより、障害リスクの低減、セキュリティの強化、保守性や可読性の向上、そして将来改修する際の前提条件の整備につなげるという。

　基本のプロセスとしては、「ASIS（現状）を理解し、TOBE（理想）を設計し、標準規約で統制し、実装へ落とす」という流れで実施、このうち規約と標準策定は特にこだわったところで、命名ルールや例外、試験方針、実装ルールを定義した上で、TOBEの実装に進むようにしたという。また、コードだけではなく、設計・仕様・差分を分離して管理しつつ、プロセスやフォルダの使い方自体もカスタムエージェントとして設計し、都度 エージェントに説明しないで済むようにしたという。

　モダナイズ前のアプリケーションは、「さまざまな罠」が仕掛けられており、動作が遅かったり、依存パッケージが不足しているため、そもそもビルドができないといった課題があった。また、ビルドできても起動しないため、warファイルを手作業でコピーする必要があったという。これに対しては、前述した通り、対応関係や使用差分を管理し、ステークホルダーに技術的な負債を明示できるようにした。

　また、品質確保のため、ASISの設計書を作成する際に、変換後のテストケースの作成もGitHub Copilotに依頼。また、仕様検証（ベリフィケーション）に加え、業務プロセスの妥当性（バリデーション）の確認ケース案もリバースしたという。

　GitHub Copilotを利用した感想としては、「シームレスな開発体験を生み出しているとともに、タスクやプロセスを設計することで、大規模なモダナイズでも適用しやすいと感じた」とのこと。一方で、想定した以上にGitHub Copilotの動作完了を待つ時間が長かったり、仕様と異なる設計と実装を人間の目できちんとレビューする必要があるという声もあった。とはいえ、「レガシーアプリの動作環境整備に苦戦した際など、エラー文と共に質問すると的確な応答があり GitHub Copilotは心強いと感じた」という。

　GitHub Copilot Quest全体の学びとしては、チーム活動ではタスクだけではなく、食べ物やお菓子の配布といった雰囲気作りが、メンバー同士のよい関係の構築につながると改めて実感したという。また、普段は開発環境やCI/CDが整っているため、自動化されていないオンボーディングの難しさを感じたのも大きかった。「マイクロソフトへの訪問が初めての社用外出というメンバーもいた」という感想もあり、いろいろな意味で貴重な体験だったとまとめた。

　コメントを担当した日立製作所の佐山 史織氏は、「単にモダナイズだけではなく、その先のお客さまの事業価値向上を見せているところがよいと思った」とコメント。「技術的な負債の解消に、どのようにGitHub Copilotを利用しているのか？」という佐山氏の質問に対してBIPROGYチームは、「大部分はGitHub Copilotが見つけてくれました。ASISの設計書を起こすときに、プロジェクトのプロセスやコードの陳腐化といった背景情報をカスタムインストラクションに入れておくと、GitHub Copilotもその前提でコードを調べてくれ、危ないところを知らせてくれました」という回答が戻ってきた。

日立製作所の佐山 史織氏