評価軸マトリクス
評価は ◎ 高 / ○ 中 / △ 低 の3段階。フルスタック（MPA）構成での一般的な傾向を示すもので、個別の要件で前後する点には留意してください。
| 評価軸 | Struts（2.x/レガシー） | Spring Boot | Quarkus | Micronaut | Jakarta EE / JSF |
|---|---|---|---|---|---|
| ① 開発生産性 | △ XML設定が重い | ◎ 自動構成 | ◎ 開発体験良好 | ○ | ○ |
| ② 保守性・テスタビリティ | △ DIが弱い | ◎ DI中心 | ◎ | ◎ | ○ |
| ③ エコシステム | △ 停滞 | ◎ 最大 | ○ 拡張豊富 | ○ | ○ 標準準拠 |
| ④ 習熟コスト（情報量） | ○ 枯れた情報 | ◎ 情報最多 | ○ | ○ | ○ |
| ⑤ サポート継続性（LTS） | △ EOL多数 | ◎ | ◎ LTSあり | ○ | ◎ 標準 |
| ⑥ 移行コスト（Strutsから） | —（基準） | ◎ 移行先本命 | △ 距離大 | △ | ○ EE資産があれば |
| ⑦ 人材確保・採用 | ○ 経験者は多いが… | ◎ 母数最大 | △ | △ | ○ |
| ⑧ 開発の活発さ | △ | ◎ | ◎ | ○ | ○ |
※ Struts は「2.x 系・EOLバージョンを使い続ける現実のレガシー」を想定。Struts 7.x は継続中だがフルスタック新規の主流ではない。
マトリクスの読み方
この表を「Struts を全否定する表」として読むのは正確ではありません。Struts は ⑦ 人材確保（経験者の母数） や ④ 枯れた情報 では一定の値を持ちます。問題は、それらの利点が ⑤ サポート継続性 の致命的な弱さを補えない点です。
⚠️ ⑤ は足切り条件になりうる
EOL（公式パッチが出ない）という状態は、他の軸がどれだけ良くても覆せないことがあります。とくにインターネットに面したシステムでは、サポート継続性の △ はそのまま「使い続けてはいけない理由」になります。
Struts との差はどこに出るか
新世代が Struts に対して明確に優れるのは、次の3点に集約されます。
- 設定の軽さ（①）：XML中心からアノテーション・自動構成へ。新規開発の立ち上がりが段違いに速い。
- テスタビリティ（②）：DI が設計の中心にあり、ユニットテストが書きやすい。長期運用の保守コストを下げる。
- サポートと将来性（⑤⑧）：継続的なリリースとセキュリティ更新。これが Struts との決定的な差。
新世代どうしの違い
新世代の中では、Spring Boot が総合力で抜けているのがフルスタック構成の現実です。Quarkus・Micronaut は ① の中でも特に 起動速度・メモリ効率で優れますが、⑥ 移行コスト（Strutsからの距離）や ⑦ 人材確保では Spring Boot に劣ります。
| こだわるなら | 候補 |
|---|---|
| 総合力・移行先・人材 | Spring Boot |
| 起動速度・低メモリ・サーバーレス | Quarkus / Micronaut |
| 標準仕様・既存EE資産の活用 | Jakarta EE / JSF |
✅ 次の章では…
PART 06 はシリーズの主役、Struts からの移行戦略です。現行システムの評価方法、段階的移行 vs 全面刷新、共存のさせ方、典型的な落とし穴を解説します。