1. はじめに
こんにちは。
これまで自分が携わってきた案件では、長らく JSF（JavaServer Faces） や Struts といった、いわゆるレガシーなJavaのWebフレームワークを使ってきました。
次にお世話になる案件では、これまでとは毛色の違うフレームワークを使うことになり、ふと「そういえば自分はJavaのフレームワークをJSFとStrutsくらいしかまともに知らないな」と気づきました。
今回は、自分自身の整理も兼ねて、Javaの主要フレームワークについて、それぞれの特徴を調べてまとめてみました。
※ 記事中の記載内容は、いずれも執筆時点（2026年9月3日）のものです。
2. この記事はこんな方におすすめ
- JSFやStrutsなど、レガシーなJavaフレームワークの案件を経験してきた方
- 新規案件で、これまでとは違うフレームワークに触れることになりそうな方
- Javaのフレームワークにどんな種類があるのか、全体像を把握したい初心者エンジニアの方
- 各フレームワークの良い点・悪い点を比較しながら整理したい方
3. Javaフレームワークまとめ
① なぜ複数のフレームワークが存在するのか
一口に「Javaのフレームワーク」と言っても、登場した時代や設計思想によって性格が大きく異なります。
-
2000年代に登場したレガシーなフレームワーク
- 当時の「Webアプリを効率よく作る」というニーズに応えて広まったもの。
- 代表例：Struts、JSF
-
2010年代に普及した、現在の事実上の標準フレームワーク
- 設定より規約を重視し、圧倒的なエコシステムを築いたもの。
- 代表例：Spring Boot
-
2010年代後半に登場した、クラウドネイティブ世代のフレームワーク
- コンテナ環境での高速起動・省メモリを最優先に設計されたもの。
- 代表例：Quarkus、Micronaut
今回は自分の経験に合わせて、この3つの世代を代表する5つのフレームワークを取り上げてみます。
② 各フレームワークの特徴・良いところ・悪いところ
Apache Struts
2005年前後にJavaのデファクトスタンダードとして一世を風靡した、MVCモデルのWebアプリケーションフレームワークです。Struts2ではアノテーションによる設定簡略化やDIコンテナ機能が導入され、Actionクラスも通常のJavaオブジェクト（POJO）として扱えるようになりました。
| 観点 | 内容 |
|---|---|
| 良いところ | ・MVCモデルによる責務分離で保守性が高い ・情報量・実績が豊富で、レガシー案件では今なお現役 ・XML設定とアノテーション設定を柔軟に併用できる |
| 悪いところ | ・OGNL（Object Graph Navigation Language）に起因する深刻な脆弱性が繰り返し報告されている ・Struts1系は2013年にサポート終了済み ・新規開発での採用はほぼなく、学習しても汎用性が低い |
脆弱性対応のため常にバージョンアップの追随が必要なフレームワークです。新規開発で選ばれることはほぼなく、既存の保守案件で出会うことが多い認識です。
JSF（JavaServer Faces / Jakarta Faces）
Java EE（現Jakarta EE）に組み込まれた、UI構築に特化したコンポーネントベースのフレームワークです。フォームやボタンなどの部品を組み合わせる感覚で画面を作れるのが特徴で、MVCモデルによりデータ処理・表示・制御が明確に分離されています。
| 観点 | 内容 |
|---|---|
| 良いところ | ・UIコンポーネントを組み合わせる直感的な開発が可能 ・入力バリデーションや状態管理、多言語対応が標準装備で生産性が高い ・デザインと処理ロジックの分離により、JSPよりも視認性が高い |
| 悪いところ | ・デフォルトでは画面状態をセッション領域に保持する仕組みのため、アクセス数が多いWebアプリには不向き（設定でクライアント側保存も選択可能） ・同時アクセスが増えるとサーバー負荷が増大しやすい ・SPAなどモダンなフロントエンド構成との相性が良くない |
JSFとJakarta Facesは、名前は違いますが同じ技術の延長線上にあるものです。 2017年にJava EEの管理をOracleからEclipse Foundationへ移管することが発表され、2018年に「Jakarta EE」へと改称されました。それに伴いJSF（JavaServer Faces）も「Jakarta Server Faces（Jakarta Faces）」へと名前を変え、パッケージ名も
javax.facesからjakarta.facesに変わっています。設計思想やコンポーネントベースという基本的な特徴は変わっていないので、「JSF＝旧称、Jakarta Faces＝現在の呼び方」くらいの認識で問題ありません。現在も法人向けの業務システムの基盤として広く使われています。
Spring Boot
現在のJava開発における事実上の標準と言えるフレームワークです。「設定より規約」の思想のもと、複雑な設定ファイルを大幅に削減し、組み込みTomcatによって単体で起動可能なアプリケーションを素早く構築できます。
近年のアップデートでは、コードベースのモジュール化による起動速度向上やREST APIバージョニング対応、Null安全性の強化など、開発体験の改善が継続的に行われています。
| 観点 | 内容 |
|---|---|
| 良いところ | ・圧倒的なエコシステムと情報量で、困ったときも解決策が見つかりやすい ・DI（依存性注入）やAOPにより疎結合で保守性の高い設計がしやすい ・Spring Data / Spring Securityなど周辺プロジェクトが充実しており、大抵の要件に対応できる |
| 悪いところ | ・通常のJVM実行では、リフレクションを多用する実行時DIのため起動がやや重くメモリ消費も大きめ（GraalVMネイティブイメージ対応により改善は可能） ・機能が豊富な分、学習コストが高い ・メジャーバージョンアップ時の破壊的変更への追随コストがかかることがある |
JSFやStrutsに慣れた身からすると、設定ファイルの少なさと開発体験の良さは新鮮に映るはず。一方で、コンテナ環境でのリソース効率を求められる場面では、後述のQuarkusやMicronautに軍配が上がることもあるようです。
Quarkus
Red Hatが開発した、「Kubernetesネイティブ Javaフレームワーク」を謳うクラウドネイティブ世代のフレームワークです。GraalVMによるネイティブイメージ生成に対応し、コンテナ環境での高速起動・省メモリを最優先に設計されています。
| 観点 | 内容 |
|---|---|
| 良いところ | ・ネイティブイメージ化により起動時間を大幅に短縮できる ・メモリ・CPU使用量が従来のフレームワークより少なく、クラウドコストを抑えやすい ・開発中のリアルタイムコード反映（ライブコーディング）で開発体験が良い |
| 悪いところ | ・比較的新しいフレームワークのため、Spring Bootと比べると情報量・実績がまだ少ない ・高スループット処理などでは、用途に応じた個別のチューニングが必要になる場合がある ・ネイティブビルドには専用の学習コストやビルド時間の増加が伴う |
Spring Bootからの移行によって、CPU・メモリ使用量や起動時間が大幅に改善したという事例も報告されています。マイクロサービスやサーバーレス用途で特に注目されている印象です。
Micronaut
Quarkusと同じくクラウドネイティブ世代のフレームワークで、コンパイル時に依存関係の解析を済ませておくAOT（Ahead-of-Time）コンパイルを採用しているのが最大の特徴です。実行時のリフレクション処理を最小限に抑えることで、高速起動・省メモリを実現しています。
| 観点 | 内容 |
|---|---|
| 良いところ | ・コンパイル時処理により起動時のオーバーヘッドがほぼない ・リフレクションを抑えた設計でメモリ消費量が少なく、マイクロサービスやサーバーレスに最適 ・アノテーションベースでSpring Bootに近い書き味のため、移行のハードルが低い |
| 悪いところ | ・エコシステムやサードパーティ連携の豊富さではSpring Boot・Quarkusにやや劣る ・日本語の情報や書籍が少なく、独学のハードルがやや高い ・採用実績がまだ相対的に少なく、案件でのメンバー確保が難しい場合がある |
Spring Bootに近い感覚で書けつつ、起動速度とリソース効率を追求したいときの選択肢という印象です。
③ フレームワーク比較まとめ表
| フレームワーク | 世代 | 起動速度 | 学習コスト | 新規開発での採用 |
|---|---|---|---|---|
| Struts | 2000年代 | 普通 | 低〜中 | ほぼなし（保守中心） |
| JSF | 2000年代 | 普通 | 中 | 少なめ（業務システム中心） |
| Spring Boot | 2010年代 | やや重め（ネイティブ化で改善可） | 中〜高 | ◎（事実上の標準） |
| Quarkus | 2010年代後半 | ◎ 非常に速い | 中 | 増加中 |
| Micronaut | 2010年代後半 | ◎ 非常に速い | 中 | 増加中 |
4. まとめ
結局のところ：
「案件の性質（レガシー保守か、新規のクラウドネイティブ開発か）」によって選ぶべきフレームワークが変わります。
- 既存のレガシー資産の保守が中心なら： StrutsやJSFの知識は引き続き必要。
- 新規のエンタープライズ開発で、情報量や安定感を重視するなら： 事実上の標準である Spring Boot が無難。
- コンテナ環境での起動速度・リソース効率を最優先するなら： Quarkus や Micronaut が有力候補。
JSFやStrutsといったレガシーなフレームワークしか実務で触れたことがなく、Spring Bootも名前くらいしか知らなかった自分にとって、その実像はもちろん、さらにその先にQuarkusやMicronautのようなクラウドネイティブ世代のフレームワークが存在することを知れたのは、良い気づきになりました。
同じJavaでも、時代ごとの設計思想の違いを比較してみると、なぜ今Spring Bootが標準として使われているのか、そしてなぜクラウドネイティブ世代のフレームワークが注目されているのか、その背景を理解できました。
※ 出典・参考リンク一覧
・Spring公式ブログ
・Quarkus公式サイト
・Micronaut Framework 公式サイト
・Apache Struts公式サイト
・Jakarta Faces Specifications | The Eclipse Foundation
・Apache Struts2 の脆弱性対策情報一覧 | IPA 独立行政法人 情報処理推進機構