この記事では、GitHub Copilotモダン化で再アーキテクチャ機能を使用して、従来のフレームワークから最新のアーキテクチャ (スラットから Spring MVC など) にプロジェクトを書き換える方法について説明します。
概要
再アーキテクチャ機能を使用すると、AI を利用したマルチエージェント ワークフローを使用して、プロジェクト全体をレガシ フレームワークから最新のアーキテクチャに変換できます。 ファイル単位の手動移行ではなく、自然言語で目的の変換を記述し、最新化エージェントが分析、計画、およびコード生成を処理します。
一般的な再アーキテクチャのシナリオは次のとおりです。
- Struts から Spring MVC へ
- Struts から Spring Boot へ
- JSP から Thymeleaf
- EJB から Spring Boot
- Spring Boot への WebSphere アプリケーション
- 従来のサーブレットベースのアプリケーションから最新の Spring ベースのアーキテクチャ
- Windows フォーム (WinForms) デスクトップ アプリケーションから Angular Web アプリケーションへ
- ASP.NET MVC フロントエンド アプリケーションから Angular Web アプリケーションへ
前提条件
- Visual Studio CodeにGitHub Copilotモダン化拡張機能をインストールしている。
- GitHub Copilot サブスクリプション。 詳細については、「Copilot プランを参照してください。
- (省略可能) ナレッジ グラフを構築するための Python 3.7 以降。これは、書き換えプロセス中にエージェントがプロジェクト構造をより明確に理解できるようにします。 Python使用できない場合、ナレッジ グラフの手順はスキップされます。
- (省略可能) ランタイム検証の 一環として Playwright テストを実行するためのNode.js18 以降。 Node.js 使用できない場合、Playwright テスト ステップはスキップされます。
- (省略可能) ランタイム検証用 Docker Desktop 。 Docker を使用できない場合、ランタイム検証手順はスキップされます。
再アーキテクチャ エージェントを使用する
GitHub Copilot Chat パネルで最新化エージェントを使用します。
プロジェクトを再設計するには、次の手順に従います。
Visual Studio Codeでプロジェクトを開きます。
GitHub Copilot Chat パネルを開きます。
エージェントの一覧からエージェントの 最新化 を選択します。
実行する変換について説明します。 例えば次が挙げられます。
Rewrite the entire project from Struts to Spring MVC using rearchitecture agent
エージェントは、次の手順を実行するマルチエージェント チームを調整します。
- 分析 - 既存のコードベースを調べ、フレームワーク パターン、依存関係、およびモジュールの境界を識別します。
- 計画 - 順序付けされたタスクと要件の追跡可能性を備えた構造化された実装計画を生成します。
- 実行 - プランに従ってコード変換を適用し、各ステップで検証チェックを行います。
Important
分析と計画のフェーズが完了すると、エージェントは一時停止し、コード生成を開始する前に確認を求めます。 この時点で計画を慎重に確認してください。 エージェントが実装を続行する前に、プランの変更を要求したり、優先順位を調整したり、制約を追加したりできます。
より多くのコンテキストを提供する
プロンプトに追加のコンテキストを指定することで、変換結果を改善できます。
- ターゲット フレームワークのバージョンを指定します 。たとえば、"Spring Boot 3.2 と Java 21 を使用する" などです。
- リファレンス ドキュメントのリンクまたは移行ガイド。
- 組織固有のパターンまたは規則について説明します。
- 優先順位を付けるモジュールまたはパッケージを指定します。
例えば次が挙げられます。
Rewrite the entire project from Struts to Spring MVC using Spring Boot 3.2.
Refer to the Spring MVC migration guide at https://docs.spring.io/spring-framework/reference/web/webmvc.html.
Keep the existing backend business logic unchanged.
一般的な問題のトラブルシューティング
再アーキテクチャ プロセス中に、エージェントはプロジェクトの .github/modernize/ ディレクトリに成果物を生成します。 これらの成果物を使用して、問題が発生したときに診断します。
生成された成果物を確認する
.github/modernize/rearchitecture ディレクトリには、次の主要なリソースが含まれています。
-
board.md- すべてのフェーズとその状態を追跡するタスク ボード。 このファイルを調べて、渡されたタスク、失敗したタスク、または必要なイテレーションを確認します。 -
artifacts/- 各タスクの詳細なレポート。 ファイルは、初期テスト レポートのt21-tester-report.mdや再試行の繰り返しのt21.2-tester-report.mdなどの名前付け規則に従います。 -
learn.md- タスクの実行中に各ロールによってログに記録された検出、バグの検出、および手法の累積ナレッジ ベース。 エージェントが直面した問題とそれをどのように解決したかについては、このファイルを参照してください。 -
team/- 各エージェントの責任を定義するロール固有のチャーター。
品質ゲートが失敗すると、エージェントは修正の試行を文書化する反復成果物 (たとえば、 t21.1、 t21.2) を作成します。 これらの番号付きイテレーションを探して、問題がどのように検出され、解決されたかを理解します。
分析と計画を確認する
エージェントは、コードの記述を開始する前に、レビューする必要がある分析および計画成果物を生成します。 これらの成果物を使用すると、エージェントがプロジェクトについて理解した内容と、ビルドする予定の内容を把握できます。
分析成果物には、次のものが含まれます。
-
アーキテクチャの概要: 既存の技術スタック、プロジェクト構造、データ モデル、統合ポイントの概要。 この概要を確認して、エージェントがプロジェクトの主要コンポーネントを正しく識別したことを確認します。
artifacts/t2-architect-architecture-summary.md、artifacts/t2-architect-tech-stack.md、artifacts/t2-architect-data-model.mdなどのファイルを探します。 -
機能インベントリ: 元のアプリケーションのすべての機能のカタログ。それぞれに要件 ID (
REQ-001など) が割り当てられます。 このリストが完全で正確であることを確認します。artifacts/t3-pm-spec.mdを探します。 -
ターゲット アーキテクチャの設計: 新しいアプリケーションに対して提案された API コントラクト、モジュール構造、およびテクノロジの選択肢。
artifacts/t5-architect-api-contracts.mdやartifacts/t5-architect-integration.mdなどのファイルを探します。
計画成果物には次のものが含まれます。
-
実装計画: フェーズにグループ化された依存関係を持つタスクの順序付きリスト。 各タスクは、機能インベントリから 1 つ以上の要件にマップされます。
artifacts/t7-teamlead-plan.mdを探します。 -
テスト戦略: 単体テスト、統合テスト、エンド ツー エンド テストの計画的アプローチ。
artifacts/t7-teamlead-testing-strategy.mdを探します。
エージェントは、これらの成果物を生成した後に一時停止し、確認を待ちます。 この機会を利用して、次の操作を行います。
- インベントリに欠落している機能がないことを確認します。
- ターゲット アーキテクチャが期待値と一致していることを確認します。
- 実装を開始する前に、タスクの優先順位を調整するか、制約を追加します。
この段階での慎重なレビューは、実装と検証のフェーズでコストのかかるやり直しを回避するのに役立ちます。
ビルドと起動の失敗
変換されたアプリケーションがコンパイルまたは起動に失敗した場合は、次の方法を使用します。
- テスト担当者レポートの成果物 (たとえば、
t21-tester-report.md) でビルド出力とスタック トレースを確認します。 - アーティファクト内の例外の種類またはエラー メッセージを検索して、根本原因を特定します。
- エージェントが修正イテレーション (
t21.1、t21.3など) を作成した場合は、それらの成果物を確認して、試行された変更を確認します。
一般的な根本原因には、レガシ クラスと新しく生成されたクラス間の名前付けの競合、不適切な Spring プロファイル構成、 pom.xmlの依存関係の不足または競合などがあります。 たとえば、レガシ コントローラーとモダン コントローラーが同じクラス名を共有している場合、Spring は起動時に ConflictingBeanDefinitionException をスローします。
実行時エラー
アプリケーションが起動しても API 呼び出しでエラー (500 または 400 応答など) が返される場合は、次の方法を使用します。
- エンドポイントが失敗したテスター レポート成果物と、関連するエラー メッセージを確認します。
- 構成上の問題について、セキュリティ調査結果のアーティファクト（例えば、
t20-security-findings.md）を確認します。 - 生成されたエンティティ クラスとコントローラー コードで、データベース スキーマと ORM マッピングの不一致を調べます。
一般的な根本原因としては、 @Column 注釈でのデータベース予約キーワードの競合、DTO フィールド型とエンティティ フィールド型の不一致、要求オブジェクトでの検証注釈の欠落などがあります。
クオリティゲートの失敗と反復
エージェントは、再アーキテクチャ プロセス中にいくつかの品質ゲートを適用します。 ゲートが失敗すると、エージェントは自動的に修正タスクを作成し、検証を再試行します。 ゲート障害の一般的な例を次に示します。
-
アーキテクチャ レビュー: エージェントは、実装が設計された API コントラクト、DTO 構造体、およびエンドポイント マッピングと一致することを確認します。 通常、エラーには、エンドポイントの不足、フィールドの名前の変更、または検証注釈の欠落が含まれます。 特定の結果については、アーキテクト レポート成果物 (
t19-architect-review.mdなど) を確認します。 -
準拠レビュー: エージェントは、実装が初期構成で定義されているすべての原則を満たしていることを確認します。 一般的なエラーは、構成で必要な場合にブラウザー レベルのエンド ツー エンド テストが見つからない場合です。 チーム リーダーレビュー成果物 (たとえば、
t22-teamlead-review.md) を確認して、どの原則が満たされなかったかを特定します。 -
機能同等性の承認： 担当者は、カタログ化されたすべての要件が実装されていることを確認します。 部分的なサインオフは、特定の機能が不完全であることを意味します。たとえば、
fromDateがtoDate前であることを確認するなど、クロスフィールド検証が欠落しています。 PM サインオフ成果物 (たとえば、t23-pm-signoff.md) を確認して、要件ごとのブレークダウンをレビューします。
エージェントがすべての問題を解決せずにイテレーションの制限に達した場合は、最新の成果物ファイルを確認して、残りのギャップを把握し、手動修正を適用します。
ランタイム検証の前提条件
エージェントは、外部ツールに依存する省略可能なランタイム検証手順を実行します。 ツールを使用できない場合、対応する手順はスキップされます。
-
Pythonインストールされていません: ナレッジ グラフの手順はスキップされます。 エージェントは引き続き再アーキテクチャを実行できますが、プロジェクト構造に関するコンテキストが少なくなる可能性があります。 Python 3.7 以降をインストールし、PATH で
python3を使用できることを確認します。 - Node.js インストールされていません:Playwright ブラウザー レベルのエンド ツー エンド テストはスキップされます。 エージェントは Maven を介して統合テストを実行します。 Node.js 18 以降をインストールして、ブラウザーのテストを有効にします。
- Docker を使用できません:ランタイム検証 (コンテナーでアプリケーションを起動し、要求に対応することを確認する) はスキップされます。 エージェントは、代わりに単体テストと統合テストに依存します。 Docker Desktop をインストールして起動して、この手順を有効にします。
制限事項
次の制限事項に留意してください。
- レガシ フレームワークが深く結合された複雑なプロジェクトでは、複数のイテレーションが必要になる場合があります。
- 変更をコミットする前に、生成されたコードを慎重に確認する必要があります。
フィードバックの提供
再アーキテクチャ機能に関するフィードバックがある場合は、