意思決定フロー
選定は「新規か、既存（Struts）保守か」を起点に分岐させると整理しやすくなります。
Q1. 新規開発か、既存 Struts の保守・刷新か？
新規 → Q2 へ
既存 Struts → Q3 へ
▼
Q2.（新規）起動速度・低メモリが要件として明確か？
いいえ → Spring Boot ＋ Thymeleaf（基本線）
はい → Quarkus / Micronaut を検討
▼
Q3.（既存）EOL バージョンを使っている／インターネットに面しているか？
はい → 優先度「高」。段階移行（→ Spring Boot）を計画化
いいえ → サポート対象へ更新しつつ移行を計画
▼
Q4.（移行）規模は大きく、稼働を止められないか？
はい → 段階移行（ストラングラー）
いいえ・小規模 → 全面刷新も可
ユースケース別のおすすめ
| ケース | おすすめ | 理由 |
|---|---|---|
| 新規フルスタック開発 | Spring Boot ＋ Thymeleaf | 総合力・エコシステム・人材すべてが厚い。迷ったらこれ。 |
| レガシー（Struts）の刷新 | 段階移行 → Spring Boot | 移行先として情報・実績が最多。共存しやすい。 |
| 軽量・高速起動・サーバーレス | Quarkus / Micronaut | 起動速度・メモリ効率に優れる。性能要件が明確な場合。 |
| 標準仕様・既存EE資産あり | Jakarta EE / JSF | ベンダー非依存。既存資産を活かせる。 |
選定チェックリスト
- 評価軸（8つ）に重みをつけ、プロジェクト文脈に合わせたか
- サポート継続性（LTS / EOL）を足切り条件として確認したか
- 既存 Struts が EOL バージョンでないか、脆弱性の影響を受けないか確認したか
- 移行は段階か全面か、規模とリスクから判断したか
- 移行前に挙動を固定する自動テスト（安全網）を用意したか
- 共存期間の期限とマイルストーンを決めたか
- 人材確保・引き継ぎのしやすさを考慮したか
まとめ：実践的な結論
フルスタックJavaのフレームワーク選定は、突き詰めるとシンプルな結論に収れんします。
💡 結論
① 新規開発なら Spring Boot ＋ Thymeleaf が基本線。特別な性能要件があるときだけ Quarkus / Micronaut を検討する。
② Struts は新規非推奨。既存資産は「危険だから今すぐ全部捨てる」でも「動いているから放置」でもなく、計画的な移行対象として捉える。
③ 移行は 段階移行（ストラングラー）＋安全網（テスト）を基本とし、共存は期限を切る。
重要なのは、Struts を悪者にすることではなく、評価軸に照らして自分のプロジェクト文脈で根拠を持って選ぶことです。本シリーズがその判断の土台になれば幸いです。