日本マイクロソフトのハッカソン「GitHub Copilot Quest Lv3」をレポート

60年の時を超え「COBOL」がGitHub Copilotでよみがえる　勘定系アプリの“超難関”モダナイに7社が挑戦

富士通：すべてを書き換えず“あえてCOBOLを残す”選択肢

　2番手は、多様なバックグラウンドのメンバーが集まった富士通。彼らが挑んだのは、GitHub Copilotをフル活用し、機能の特性に合わせて作り変えるマイグレーションだ。加えて、各機能をコンテナへ分割し、ビルドからデプロイまでを自動化する試みにも取り組んだ。

富士通 柴田隆志氏

　実際には、現行調査や移行方針の検討を経て、システムを「外接・登録」「計算」「帳票出力」の3つの機能に分割し、それぞれをコンテナ内に実装するアーキテクチャに決定。外接・登録と帳票出力にはPythonを選択した一方で、コアとなる計算には、あえてCOBOLのまま現状維持とした。「計算処理はCOBOLが得意な領域。精度も言語によって変わる可能性があるため、COBOLのまま残すという選択をした」（富士通・柴田氏）

　結果としてビルドまでは到達したものの、実行環境の構築は間に合わず時間切れとなった。それでも、GitHub Actionsワークフローを用いたイメージビルドやPushの自動化まで実現している。

将来的にはコンテナで新機能も追加可能なアーキテクチャとなった

　柴田氏は、「GitHub Copilotでブラックボックスだったシステムを可視化することで、全体像を俯瞰でき、移行の方針が立てやすかった」とコメント。一方で、AIに適切なコンテキストを与えたり、出力されたコードの妥当性を判断したりするために、「人間側も技術を磨き続けていく必要がある」と実感したという。

日立製作所：AI-DLCに挑戦！GitHub Copilotを使い倒し、現新比較まで完遂

　3番手は、モダナイゼーションに携わるメンバーを揃えた日立製作所だ。同チームでは、AIが開発プロセスの中心となり人間は意思決定に専念する開発手法「AI-DLC（AI駆動開発ライフサイクル）」に全員で初挑戦。レガシーCOBOLの暗黙知をAIエージェント主導で形式知化することを目指した。加えて、Azureネイティブな構成で稼働までやり切ること、GitHub Copilotの機能を使い倒してハッカソンを楽しむことを目標に掲げている。

日立製作所 池田夕太郎氏

　実際にAI-DLCの思想に則り、GitHub Copilotの解析結果を人が承認するプロセスを採用。加えて、管理者エージェントと6つのサブエージェントからなるマルチエージェントを編成して、タスクの自動化を推進した。2台のPCで並行してAI-DLCのサイクルを回し、出力のゆれを軽減する工夫も凝らしている。

　アーキテクチャでは、言語・実行にJava 25+Spring Batchを採用し、実行基盤は常時稼働のLinux VMからサーバーレスのContainer Apps Jobsへと移行した。COBOLの暗黙知的な構造と制御を、Java/Spring Batchの明示的な設計へと翻訳し、業務ロジックは変えずに設計の「型」だけを刷新している。「業務ルールと数値の一致は勘定系システムの大前提。逐語移植せずに再設計し、非機能要件はフレームワークの標準機能で置き換えた」（日立製作所・池田氏）

Java・Azureのアーキテクチャに刷新し、GitHub ActionsとBicepによるIaCベースの自動デプロイも

　最終的には、全ての機能をAzureにデプロイし、勘定系のコア機能の現新比較テストをするところまでを完了。AI-DLCの実践については、形式知化は体験できたものの、その評価・検証にまで至らなかったのが心残りとなった。学びとしては、クラウドネイティブ化における設計の難しさを痛感したという。「保守性・拡張性に優れた疎結合な設計になっていることが重要。制限内で動かすという視点から最終的には妥協を迫られたが、将来的に拡張できる設計を心掛けた」（池田氏）

　ただ、目標通りGitHub Copilotの主要機能をフル活用し、楽しみながら開発を効率化できたという。AI-DLCに積極的に挑戦した結果、ハッカソン終了後に公開されたチーム別のAI利用量では、日立製作所がトップを記録した。