Spring Boot から Quarkus への移行

Spring Boot アプリケーションを Quarkus に段階的かつゲート駆動型で移行します。

重要なルール

• 移行できないコードは削除しないこと。 コードの一部を完全に移行できない場合は、元のコードをそのまま残し、// TODO: Migration required — <reason> コメントを付けて何を変更する必要があり、なぜそうなのかを説明してください。これは以下に適用されます:
  • 変換方法が不明なメソッド、クラス、またはアノテーション
  • 明確な Quarkus 相当物がない Spring 固有のパターン
  • 目的が不明な設定またはワイヤリングコード コード削除が必須の場合(例: Spring 専用基本クラス)は、削除されたもの、その場所、理由を // REMOVED: コメントで記録してください。
• ビルドを壊さないこと。 各フェーズの後にコンパイルコマンドを実行してください(./mvnw clean compile -DskipTests for Maven、./gradlew clean compileJava -x test for Gradle)。ビルドが壊れた状態で次のフェーズに進まないでください。
• すべての決定を記録すること。 移行アプローチを選択する際に、トレードオフをユーザーに説明してください。
• 無言の変更をしないこと。 すべてのファイル変更は意図的で追跡可能である必要があります。フェーズ後にチェックが失敗する場合は、診断して修正してください。チェックをスキップしたり、失敗するコードを削除しないでください。

参照ファイル

モジュールで作業する際に、関連する参照ファイルを読み込んでください:

参照	使用時機
references/dependency-map.md	ビルドモジュール: 依存関係とプラグインマッピング
references/annotation-map.md	コードモジュール: アノテーション、DI、REST、Data、セキュリティ移行
references/config-map.md	ビルドモジュール: 設定プロパティ移行

ステップ 1: 分析と戦略の選択

移行が必要な内容を理解するため、アプリケーションをスキャンしてください:

• ビルドシステム: ビルドファイル(pom.xml for Maven、build.gradle または build.gradle.kts for Gradle)を読み込んでください — Spring Boot バージョン、スターター、プラグイン
• Java コード: Spring アノテーション(DI、REST、Data、セキュリティ、スケジューリング)を検索してください
• 設定: application.properties/application.yml を読み込んでください。プロファイルを確認してください
• UI / ビュー層: Thymeleaf/JSP テンプレート、静的リソース、Model+View パターンを確認してください
• テスト: @SpringBootTest、@WebMvcTest、@DataJpaTest を確認してください

領域、発見事項、および複雑さを含む概要テーブルを提示してください。その後、ユーザーに戦略を選択するよう求めてください:

• Spring 互換性(推奨): quarkus-spring-web、quarkus-spring-data-jpa などを使用します。コード変更が最小限です。
• ネイティブ Quarkus: すべての Spring アノテーションを JAX-RS/CDI に置き換えます。より多くの作業が必要ですが、完全な Quarkus エクスペリエンスが得られます。

ここで停止し、続行する前にユーザーの回答を待ってください。 同じメッセージで git ワークフローやその他について尋ねないでください。

ステップ 2: Git ブランチ(オプション)

ユーザーが戦略を選択した後、対象プロジェクトが git リポジトリかどうかを確認してください。git リポジトリの場合は、git ワークフローを提案してください:

移行ワークフロー: 各移行実行は、main から作成された独自のブランチ(migration/run-01、migration/run-02 など)に分離できます。ブランチには、すべての変更とマイグレーションレポートを含む単一のコミットが含まれます。main に対する下書き PR が作成されて、レビュー用に使用されます — マージされることはなく、永続的な差分とディスカッション記録として機能します。このワークフローを使用したいですか?

• ユーザーが同意 → modules/git.md — Pre-migration セクションに従ってください。ブランチ名を提案し、作成する前にユーザーの確認を待ってください。
• ユーザーが拒否 → git 管理をスキップし、現在のブランチで移行を進めてください。
• git リポジトリではない → ユーザーに通知し、git 管理をスキップし、通常どおり進めてください。

ステップ 3: モジュール実行

決定ゲートテーブル

各モジュールについて、このプロジェクトに適用されるかどうかを評価してください。モジュールは、ゲートが PASS のときにのみ実行されます。 プロジェクトをインスペクトしてゲート結果を判定してください — ブラインドの grep コマンドに依存しないでください。コードベースの理解を使用してください。

モジュール	ゲートチェック	ゲート結果
jdk	JDK 21+ が必須	常時 -- < 21 の場合は移行を停止
build	pom.xml の Spring Boot 親/スターター/spring-boot-maven-plugin、または build.gradle(.kts) の Spring Boot/io.spring.dependency-management プラグイン	Spring Boot ビルドマーカーが見つかった場合は PASS。それ以外の場合は SKIP
code	Java ソースの Spring アノテーション(@Component、@Service、@Controller、@Repository、@Entity、@Autowired など)	Spring アノテーションが見つかった場合は PASS。それ以外の場合は SKIP
frontend	templates/ の Thymeleaf/JSP テンプレートまたは static/ の静的リソース	ビュー層が見つかった場合は PASS。それ以外の場合は SKIP
testing	テストソースの Spring テストアノテーション(@SpringBootTest、@WebMvcTest、@MockBean)	Spring テストが見つかった場合は PASS。それ以外の場合は SKIP
cleanup	他のすべてのモジュール後の残された Spring アーティファクト	常時 — 他のすべてのモジュール後に実行

実行プロトコル

FOR module IN [build, code, frontend, testing, cleanup]:

  1. 評価 — ゲート条件についてプロジェクトをインスペクトする
  2. 決定
     IF gate == 常時 → ステップ 3 に進む
     IF gate == PASS   → ステップ 3 に進む
     IF gate == SKIP   → "Module {name}: SKIPPED — {reason}" をログに記録し、チェックボックスをマーク、続ける
  3. ロード — モジュールファイルと関連参照ファイルを読み込む
  4. 実行 — モジュール指示に従い、選択された戦略に適応させる
  5. コンパイル — プロジェクトのコンパイルコマンドを実行(`./mvnw clean compile -DskipTests` for Maven、`./gradlew clean compileJava -x test` for Gradle)
     失敗 → 進行する前に診断して修正
  6. ログ — チェックボックスを完了としてマーク

個別モジュールの実行

完全な移行フロー外の単一モジュールを実行するには、そのファイルを直接読み込んでください:

• "Read modules/build.md and execute it"(modules/build.md を読み込んで実行)
• "Run only the frontend module"(フロントエンドモジュールのみを実行)
• "Re-run the cleanup module"(クリーンアップモジュールを再実行)

モジュールは現在のプロジェクト状態と選択された戦略(既に決定済みの場合)を使用します。まだ戦略が選択されていない場合は、モジュールが尋ねます。

ステップ 4: 移行の検証

各チェックを順番に実行してください。チェック失敗 = 続行する前に停止して修正してください。

#	チェック	コマンド (Maven / Gradle)	合格基準
1	ビルド	./mvnw clean package -DskipTests / ./gradlew clean build -x test	終了コード 0、コンパイルエラーなし
2	Spring 依存関係がない	ビルドファイルで org.springframework を検索	ゼロの Spring 依存関係(その戦略を使用する場合は Spring 互換性拡張機能を除く)
3	Quarkus がある	ビルドファイルで io.quarkus を検索	Quarkus BOM と少なくとも 1 つの拡張機能が存在
4	テスト合格	./mvnw test / ./gradlew test	@QuarkusTest を使用してすべてのテストが合格
5	起動する	./mvnw quarkus:dev / ./gradlew quarkusDev	アプリが起動、curl http://localhost:8080/q/health が UP を返す
6	残された Thymeleaf/JSP 参照がない	Thymeleaf/JSP 参照を検索	なし(意図的に保持されている場合を除く)

ステップ 5: 移行レビュー(自己反映)

各質問に誠実に答えてください:

1. 何がきれいに移行されましたか? 1:1 でマップされたパターン。
2. 何が手動での判断が必要でしたか? 明らかでない決定が下された。
3. TODO として何が残されていますか? すべての // TODO: Migration required コメントと理由。
4. コードが削除されましたか? 何、どこ、正当性。ランタイムリスクにフラグを立ててください。
5. ステップ 4 で最初にどのチェックが失敗しましたか? ステップ 4 からの失敗と、その修正方法。
6. スキル参照に不足しているものは何ですか? 独自に理解する必要があったマッピング。

マイグレーションレポート

レビューを構造化されたレポートとして提示してください:

## マイグレーションレポート: [app-name]

### 概要
- 戦略: [完全移行 / Spring 互換性]
- エージェント: [AI エージェント名 - 例: claude、pi、opencode、gemini など]
- モデル: [モデル名 — 例: claude-sonnet-4-6、システムコンテキストを確認]
- 完了したモジュール: [X/4]
- 合格したチェック: [X/6]
- トークン使用量: [入力トークン / 出力トークン — セッション統計を確認]
- 推定費用: [~$X.XX — トークン数 × anthropic.com/pricing のモデル単価]

### モジュール別の変更
| モジュール | 変更されたファイル | 主な変更 |
|--------|--------------|-------------|
| build | pom.xml または build.gradle(.kts)、application.properties | ... |
| code | ... | ... |
| frontend | ... | ... |
| testing | ... | ... |

### 検証結果
| チェック | 結果 | メモ |
|-------|--------|-------|
| ビルド | PASS/FAIL | |
| Spring 依存関係がない | PASS/FAIL | |
| Quarkus がある | PASS/FAIL | |
| テスト合格 | PASS/FAIL | |
| 起動する | PASS/FAIL | |
| 残された Thymeleaf/JSP 参照がない | PASS/FAIL | |

### 未移行コード(TODO)
| ファイル | 行 | 内容 | 移行されなかった理由 |
|------|------|------|-----------------|

### 削除されたコード
| ファイル | 削除されたもの | 正当性 |
|------|-----------------|---------------|

### スキル改善の提案
- [発見された欠落マッピング、不明確な指示、またはエッジケース]

ステップ 6: コミットと PR(git ワークフローが受け入れられた場合のみ)

modules/git.md — Post-migration セクションに従ってください。コミットする前にユーザーの確認を求め、プッシュ/下書き PR 作成の前に再度確認してください。明示的なユーザー承認なしにいずれかのアクションを実行しないでください。