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

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

日本アイ・ビー・エム システムズ・エンジニアリング：“言語を使い分けた”モダンな構成に挑戦

　6番手は、インフラ構築をメインとした部署のメンバーが集結した日本アイ・ビー・エム システムズ・エンジニアリングだ。同チームでは、まず、リポジトリ全体の探索を経て、GitHub Copilotに「仕様復元」をさせることを再設計の出発点にした。さらに、データフローや依存関係をMermaid図で可視化することで、合意形成を高速化。ここからAzureに載せることを最優先に、4パターンのアーキテクチャを検討している。

日本アイ・ビー・エム システムズ・エンジニアリング 冨本優介氏

　結果、AKS（Azure Kubernetes Service）を利用して22個のサブシステムをマイクロサービス化し、バッチ処理はCronJobで動かすという構成を採用。データはAzure Database for PostgreSQL Flexible Serverに集約して、イベント連携にはAzure Service Busを選んでいる。

　さらに、業務特性に合わせて最適な言語を選択する「適材適所」なモダンアプローチにも挑戦。高精度な計算が求められる業務ロジックは「Java 21 / Spring Boot 3.3」、データが入出力される外部連携・明細は「Python」、メモリ消費を抑えたいマスタ・照会APIは「Go」、フロントエンドは「TypeScript」に、それぞれ置き換えた。

複数の言語を使いわけたモダンな構成に

　最終的には、AKS上で一通りのアプリケーションをコンテナ化するところまで完了。大幅刷新をやり遂げたが、現新比較をする直前で時間切れとなった。

　日本アイ・ビー・エム システムズ・エンジニアリングの冨本氏は、「業務フローを理解した上でのモダナイゼーションはAIと相性が良いと実感した。ただ、agent.mdなどで定義を共有できなかったため、生成されたコードの品質や整合性に差が生まれてしまった」とコメント。加えて、「IaCやコンテナはAIでのマイグレーションと相性がよく、インフラとアプリケーションの両実装で相互に活用してくれる」と振り返った。

BIPROGY：Code to Doc/Doc to Codeを重視し、モダナイの範囲を“取捨選択”

　ラストバッターを務めたBIPROGYからは、コーディングエージェントに不慣れなメンバーが「GitHub Copilotを使い倒すぞ！」という想いを持って参加。COBOLからJavaへモダナイズしつつ、最初のコード分析から時間内ですべての機能を移行するのは難しいと判断し、「少しでもAzure上で動作させる」ことを目標に掲げた。

BIPROGY 犬井太一氏

　方針としては、Azureネイティブを意識してコンテナ型のアーキテクチャを採用。実行環境は、アプリケーションのモダナイゼーションに注力するためシンプルなAzure Container Appsを選択した。Java移行においては、「Code to Doc（コードから仕様書へ）」および「Doc to Code（仕様書からコードへ）」というステップを重視。人間のレビューを挟みながら、工数をかけて丁寧に進めたという。

　また、モダナイゼーションの範囲は、依存関係が少ない「マスタ参照層（参照系）」と「取引本流層（取引・記帳系）」に絞り込んだ。それぞれの機能を別サービスとして構築し、取引本流層からマスタ参照層をWebAPIで呼び出す形をとり、それぞれのデータはPostgreSQLに格納する構成だ。昼休憩の時点では「絶望していた」という話だが、IaCで環境を構成し、GitHub Actionsでアプリケーションをデプロイするという当初の目標まで粘りきった。

依存関係が少ないマスタ参照層と取引本流層にフォーカス

　最後に犬井氏は、「GitHub Copilotと各種機能が非常に優秀だった」とコメント。コード解析や実装はすべて任せられるという手ごたえを得たという。一方で、「人間の認知負荷がボトルネックだった」と言い、「仕様理解や設計に時間を割いている間にも、AIにタスクを任せるべきだった」と振り返った。Javaへの移行にこだわり、一部のCOBOLを残す選択肢を見逃していたのは、他チームのプレゼンからの学びだ。