APサーバーの選び方と主要製品比較｜Tomcat・JBoss・WildFly・GlassFishを徹底検討

APサーバー選定が「後から変えられない判断」になる理由

JavaベースのWebシステムを新規開発または刷新する際、見落とされがちな判断がAPサーバーの選定です。フレームワークやデータベースの選定に比べると注目度が低くなりやすい領域ですが、実態としてはシステムの根幹を支えるインフラであり、一度決定すると後から変更するコストが極めて高くなります。

APサーバーはアプリケーションの実行環境そのものです。業務ロジック・セッション管理・トランザクション処理・セキュリティ機能など、システムの中核機能がAPサーバーの仕様と密接に絡み合って構築されます。そのため、稼働後に別製品へ移行しようとすると、アプリケーションコードの大規模な改修が避けられないケースがほとんどです。システム刷新・新規開発のタイミングこそ、APサーバー選定を丁寧に検討すべき理由がここにあります。

APサーバーとは何か — Webサーバーとの違いから整理する

APサーバー（アプリケーションサーバー）とは、業務アプリケーションの処理を実行するためのミドルウェアです。HTTPリクエストの受け付けや静的ファイルの配信を担うWebサーバー（ApacheやNginxなど）とは役割が異なります。

具体的には、以下のような機能をAPサーバーが担います。

• JavaサーブレットやJSP（JavaServer Pages）の実行
• データベース接続のプーリング管理
• トランザクション制御
• 認証・認可などのセキュリティ処理
• 複数サーバーにまたがるクラスタリング管理

Webサーバーが「入口の受付」だとすれば、APサーバーは「業務処理を行うバックオフィス」と考えると整理しやすいです。両者は連携して動作しますが、担う責務はまったく異なります。

本記事で解説する内容の全体像

本記事では、APサーバー選定を検討している情報システム担当者・経営層・事業開発担当者に向けて、判断に必要な情報を体系的に整理します。具体的には、選定で見るべき5つの判断軸を示したうえで、Tomcat・JBoss・WildFly・GlassFishという主要4製品の特徴と位置づけを解説します。さらに選定基準別の比較表、プロジェクト類型ごとの選定シナリオ、見落とされがちなリスク、そして外部のシステム開発会社に選定を委ねる際の確認ポイントまでを網羅します。

技術的な網羅性よりも、意思決定に直結する判断軸と根拠の整理を重視して解説しています。

APサーバー選定で見るべき5つの判断軸

製品の機能一覧を比べる前に、まず自社の選定基準を明確にしておく必要があります。判断軸が曖昧なまま製品比較に進むと、スペック上は優れていても実運用に合わない製品を選んでしまうリスクがあります。以下の5つの軸を順に確認し、自社の要件に照らし合わせてください。

①Jakarta EE準拠の範囲 — フルプロファイルかWeb Profileか

Jakarta EE（旧Java EE）には、すべての仕様を実装した「フルプロファイル」と、Webアプリケーションに必要な機能を絞り込んだ「Web Profile」があります。

大規模な業務システムでEJB（Enterprise JavaBeans）やJMSなどのエンタープライズ機能を使う場合はフルプロファイルへの対応が必要です。一方、REST APIやServletを中心とした構成であれば、Web Profileで十分なケースが少なくありません。必要以上の仕様を含む製品を選ぶと、起動の重さや設定の複雑さが運用負荷につながるため、現行システムの機能要件を先に棚卸しすることをお勧めします。

②商用サポートの有無とSLAの必要性

障害発生時に製品ベンダーから迅速な回答を得られるかどうかは、システムの安定稼働に直結します。金融・医療・製造など、ダウンタイムが業務損失に直結する業種では、SLA（サービスレベル合意）を伴う商用サポート契約が実質的に必須となります。

OSSのAPサーバーであっても、Red HatによるJBoss Enterprise Application Platform（EAP）のように、有償の商用サポートが提供されている製品があります。「OSSだからサポートがない」とは限らないため、製品ごとのサポート提供元と対応範囲を個別に確認してください。

③ライセンス形態 — OSS・無償・有償サポートの組み合わせを把握する

APサーバーのコスト構造は「ソフトウェア本体の費用」と「サポート費用」の組み合わせで決まります。Tomcatのように本体・サポートともに無償のものから、製品本体はOSSだが商用サポートは有償というモデル、あるいは製品ライセンス自体に費用が発生するものまで、形態は様々です。

初期費用だけでなく、年間の保守費用・バージョンアップ対応費用を含めた総保有コスト（TCO）で比較することが重要です。特に5年以上の長期運用を想定する場合、ライセンス形態の違いがトータルコストに大きく影響します。

④運用・監視のしやすさ — 管理コンソールとドキュメントの充実度

APサーバーは導入後も継続的な設定変更・パフォーマンス監視・トラブル対応が発生します。GUIベースの管理コンソールが整備されているか、公式ドキュメントが日本語または十分な英語で提供されているかは、運用担当者の負荷に直結します。

特に内製エンジニアが少ない組織では、CLIのみで操作する製品は運用難易度が高くなりがちです。製品選定の段階で、実際の管理画面を確認しておくことをお勧めします。

⑤コンテナ・クラウド環境への対応度

Kubernetes上でのコンテナ運用やクラウドネイティブなアーキテクチャへの移行を視野に入れる場合、APサーバーがDockerイメージを公式提供しているか、軽量起動に対応しているかが選定の重要な要素になります。

WildFlyのMicroProfileサポートやQuarkusとの統合のように、クラウド対応を積極的に進めている製品がある一方、従来型のモノリシック構成を前提とした製品ではコンテナ化に追加の工数がかかるケースがあります。将来的なインフラ方針と照らし合わせて判断してください。

主要APサーバー4製品の特徴と位置づけ

JavaベースのWebシステムを構築する際、APサーバー（アプリケーションサーバー）の選択肢は大きく4製品に絞られます。それぞれ成り立ちも得意領域も異なるため、「どの文脈で語られる製品か」を先に把握しておくことが、選定判断の精度を高める出発点になります。

Apache Tomcat — 軽量・シンプル、Servlet/JSP特化の定番

Apache Software Foundationが開発・管理するオープンソースのAPサーバーです。Servlet（サーブレット）とJSP（JavaServer Pages）の実行に特化しており、Jakarta EE（旧Java EE）が定めるフル仕様のうち必要最小限の機能だけを実装しています。

その分、起動が速く、メモリ消費が少ないため、小〜中規模の社内業務システムや、Spring Bootを使ったマイクロサービス構成との相性が良いです。実際、Spring Bootはデフォルトの組み込みサーバーとしてTomcatを採用しており、追加設定なしで動作する手軽さが選ばれる理由の一つです。

一方で、エンタープライズ向けの機能（トランザクション管理やメッセージング連携など）はTomcat単体ではカバーしきれないため、それらが必要な場合は別途ライブラリやフレームワークで補う構成を検討する必要があります。

JBoss EAP — Red Hatの商用サポート付きエンタープライズ製品

JBoss EAP（Enterprise Application Platform）は、Red Hatが提供する商用APサーバーです。Jakarta EEの仕様をフルサポートしており、トランザクション管理・メッセージング・クラスタリングなど、大規模システムに求められる機能を一通り備えています。

最大の特徴は、Red Hatによる長期サポート（LTS）と脆弱性対応の保証が受けられる点です。金融機関や官公庁、製造業の基幹システムなど、「動き続けることが求められる」システムで採用されるケースが多いです。ライセンスコストは発生しますが、有償サポートが調達要件に含まれる組織では、むしろ標準的な選択肢として位置づけられています。

WildFly — JBoss EAPのアップストリームにあたるOSS版

WildFlyは、JBoss EAPの機能開発が行われる上流（アップストリーム）のOSSプロジェクトです。Red Hatがコミュニティ版として公開しており、最新のJakarta EE仕様への対応が早い点が特徴です。

JBoss EAPと同等の機能を無償で利用できるため、コスト制約のある開発環境や検証環境で使われることが多いです。また、新技術の評価目的でWildFlyを採用し、本番稼働時にJBoss EAPへ移行するという段階的アプローチをとるプロジェクトも少なくありません。ただし、商用サポートはなく、最終的な問題解決はコミュニティへの依存が前提になります。

GlassFish（Eclipse GlassFish） — Jakarta EEリファレンス実装としての位置づけ

GlassFishは、Jakarta EE仕様の「リファレンス実装（参照実装）」として開発されたAPサーバーです。もともとSun Microsystems（後にOracle）が主導していましたが、現在はEclipse Foundationがオープンソースとして管理しています。

Jakarta EEの標準仕様に最も忠実に準拠しているため、仕様の動作確認や教育用途での利用が主な採用シーンです。商用プロジェクトへの採用実績はTomcatやJBoss EAPと比べると限られており、長期運用を前提とした本番システムへの採用は慎重に検討する必要があります。「Jakarta EEの標準を学ぶ」「仕様の挙動を確認する」といった場面では有力な選択肢になります。

4製品を横並びで比較する — 選定基準別の一覧表

比較表：Tomcat・JBoss EAP・WildFly・GlassFishを5軸で整理

前節で整理した5つの判断軸をもとに、4製品の特性を一覧表として整理します。社内での製品選定会議や稟議資料に転用しやすいよう、評価を簡潔な言葉でまとめています。

• Jakarta EE準拠範囲：フルスペックの仕様に準拠しているか、それとも一部のみか
• 商用サポート：ベンダーによる有償サポート契約が提供されているか
• ライセンス：導入・運用にかかるライセンスコストの有無と形態
• 管理コンソール：GUIベースの管理画面が標準提供されているか
• コンテナ対応：DockerやKubernetesなどのコンテナ環境での運用実績・対応状況

表の読み方と補足 — 数値では表れない選定上の注意点

この表は「どの製品が優れているか」を示すものではなく、「どの製品が自社の要件に合うか」を判断するための出発点として活用してください。

特に注意が必要な点を3つ補足します。

「商用サポートあり」はJBoss EAPのみです。金融・医療・公共系など、インシデント発生時にベンダーへ問い合わせできる体制が求められる案件では、この1点だけで選択肢が絞られるケースが少なくありません。

TomcatはJakarta EEのフル準拠ではないため、EJB（Enterprise JavaBeans）やCDI（Contexts and Dependency Injection）など、エンタープライズ仕様の機能を使う設計には向きません。既存システムの仕様書にこれらの用語が登場する場合は、事前に確認が必要です。

GlassFishはリファレンス実装としての位置づけが強く、本番運用よりも検証・学習用途に使われることが多い製品です。長期的な商用利用を前提とする場合、コミュニティの活発さや今後のロードマップも含めて評価することをお勧めします。

プロジェクト類型別の選定シナリオ — どの製品が合うか

APサーバーの選定基準を整理しても、「では自社のプロジェクトにどれが合うのか」という判断は容易ではありません。ここでは、プロジェクトの規模・要件・運用体制を4つの類型に整理し、それぞれに適した製品と選定理由を示します。

小規模・スピード重視のシステムにはTomcat

社内業務ツールや部門向けWebアプリケーションなど、機能範囲が限定されていてリリースまでのスピードが優先されるプロジェクトには、Tomcatが最も現実的な選択肢です。

Tomcatは軽量で起動が速く、設定項目も少ないため、開発・検証・本番の各環境を短期間で整えやすい特徴があります。Jakarta EE（旧Java EE）のフルスタック機能は必要なく、サーブレットとJSPが動けば十分というケースであれば、余分な機能を持つ製品を選ぶ理由はありません。運用担当者のJava経験が浅い場合でも、ドキュメントや事例が豊富なため、トラブル対応のハードルが低い点も選定理由の一つになります。

エンタープライズ要件・商用SLAが必要な場合はJBoss EAP

金融・医療・製造など、システム停止が事業に直結するミッションクリティカルな領域では、Red Hatが提供するJBoss EAPが有力な選択肢になります。

JBoss EAPの最大の強みは、Red Hatによる商用サポートとSLA（サービスレベル合意）の取得が可能な点です。障害発生時のベンダーエスカレーションルートが明確に確保されており、情報システム部門が社内の監査や稟議で「サポート体制」を説明しなければならない場面で有効に機能します。また、既存のRed Hat製品群（RHEL、OpenShiftなど）と統合している環境では、管理コストの一元化も期待できます。

OSSでフルスタックを使いたい場合はWildFly

Jakarta EEの全機能（EJB、JPA、JMSなど）を使いたいが、ライセンスコストは抑えたいというプロジェクトには、WildFlyが適しています。

WildFlyはJBoss EAPのコミュニティ版に相当し、フルスタックのJakarta EE実装をOSSで利用できます。技術スタックの幅が広く、マイクロサービス化を見据えたクラウドネイティブ移行のステップとして採用するケースも見られます。ただし、商用サポートは原則としてコミュニティベースになるため、社内にJavaの深い知見を持つエンジニアがいることが前提条件になります。

仕様検証・PoCフェーズではGlassFishが有効な選択肢になる

新技術の評価やアーキテクチャ検討を目的としたPoC（概念実証）フェーズでは、GlassFishを短期的に活用する方法があります。

GlassFishはJakarta EEのリファレンス実装として位置づけられており、仕様に最も忠実な動作を確認できます。「この機能はJakarta EE仕様として保証されているのか、それとも製品固有の挙動なのか」を切り分けたい場面で参照用途として役立ちます。ただし、本番運用に向けた商用サポートが存在しないため、PoCを経て本番環境に移行する際には別製品への乗り換えを前提に計画を立てることが一般的です。

選定時に見落とされがちな3つのリスク

APサーバの選定基準として機能・性能・コストが重視される一方、選定後に顕在化するリスクが稟議・上申の段階で見落とされるケースは少なくありません。以下の3点は、導入後に追加コストや再検討を迫られる原因として頻出するものです。

①EOLとサポートライフサイクルの確認を怠るリスク

APサーバーには製品ごとにEOL（End of Life：サポート終了）の予定があります。EOLを迎えると、セキュリティパッチの提供が終了するため、システムを稼働させ続けるリスクが高まります。

たとえば商用サポートを付帯しない構成でWildFlyを採用した場合、コミュニティの方針変更によってサポート期間が想定より短くなる可能性があります。システムの稼働期間が5〜10年を超えるケースでは、APサーバーの選定時点でEOLスケジュールと、その後の有償サポート移行コストまで試算しておくことが重要です。

②Java EEからJakarta EEへの移行で生じる仕様ギャップ

2019年以降、Java EEはEclipse FoundationへのOSSの移管にともない「Jakarta EE」として仕様が引き継がれました。この移行は単なる名称変更ではなく、パッケージ名が「javax.*」から「jakarta.*」へ変更されるなど、ソースコードレベルでの修正が必要な変更を含んでいます。

既存システムをJava EEベースで構築している場合、Jakarta EE対応のAPサーバーに移行する際には想定外の改修コストが発生します。APサーバー選びの際は、現行システムが依存するAPIのバージョンと、対象製品が準拠する仕様バージョンの整合を事前に確認することが欠かせません。

③クラウド・Kubernetes環境での動作検証が不十分なまま選定するリスク

オンプレミス前提で選定したAPサーバーを、後からクラウドやKubernetes環境へ移行しようとすると、コンテナへの対応不足が障壁になる場合があります。たとえばセッション管理やクラスタリングの仕組みが、コンテナの水平スケールと相性が悪いケースがあります。

特に従来型の商用APサーバーは、コンテナ環境での運用を想定した設計になっていないものも存在します。将来的なクラウド移行やマイクロサービス化の可能性が少しでもある場合は、選定段階でコンテナ対応の動作実績と、Kubernetes上での運用事例を確認しておくことが望ましいです。

APサーバー選定をシステム開発会社に委ねる際の確認ポイント

APサーバーの選び方は、開発会社に一任してしまうケースが少なくありません。しかし、選定基準が開発会社の都合や慣れ親しんだ技術スタックに偏ると、発注側が長期的なコストやリスクを負う結果になります。委ねる場合でも、発注側として最低限押さえておくべき確認ポイントがあります。

選定理由と採用実績を書面で確認する

「使い慣れているから」「前のプロジェクトでも使ったから」という理由だけで製品が選ばれているケースは珍しくありません。発注側は、なぜその製品が自社のシステム要件に合致するのかを、書面で説明させることが重要です。

確認すべき内容は以下の3点です。

• 選定製品が要件（負荷特性・認証要件・可用性など）とどう対応しているか
• 同規模・同業種での採用実績があるか
• 採用を見送った製品と比較した理由が明示されているか

APサーバー選定基準を文書化させることで、後から「なぜこの構成になったのか」を検証できる状態を作っておくことができます。

移行・保守コストを含めたTCO（総所有コスト）で評価する

初期構築費用だけを比較していると、将来の保守・バージョンアップ・移行コストが見えなくなります。開発会社には、選定製品のライフサイクルを踏まえた中長期コストの試算を提示させてください。

特に確認が必要な項目は、サポート終了時期と延長サポートの有無、メジャーバージョンアップ時の改修規模の見積もり、他製品への移行が必要になった場合の概算費用の3点です。CLANEが手がけた支援事例でも、TCOベースで製品を比較した結果、当初の候補とは異なる製品に切り替えた事例があります。初期費用が安くても、5年・10年単位で見ると総コストが逆転するケースは少なくありません。

商用サポートの調達責任を契約前に明確にする

Red Hat JBoss EAPのような商用製品を採用する場合、サポート契約の調達責任が曖昧になりやすい点に注意が必要です。開発会社が調達して費用を請求するのか、発注側が直接契約するのかを、プロジェクト開始前に契約書に明記しておくことが求められます。

サポート契約の名義・費用負担・更新判断の主体が不明確なまま稼働に入ると、インシデント発生時の対応に遅れが生じるリスクがあります。APサーバーの選び方として製品スペックに目が向きがちですが、サポート体制の契約上の整理もAPサーバー選定基準の一部として扱うことを推奨します。

まとめ — APサーバー選定の判断フローを整理する

APサーバーの選び方は、製品スペックの比較だけで完結しません。要件の整理から始まり、リスクの確認、開発・運用を担うパートナーの確認まで、一連の判断フローを順に踏むことが重要です。以下に、選定の流れをステップ形式で整理します。

1. 要件を整理する

   システムの規模・同時接続数・トランザクション量・可用性要件を数値で把握します。「なんとなく大規模」ではなく、ピーク時のアクセス数やダウンタイム許容時間を具体化することが出発点です。

2. 判断軸の優先順位を付ける

   パフォーマンス・スケーラビリティ・ライセンスコスト・Jakarta EE準拠度・サポート体制のうち、自社にとって最も妥協できない軸はどれかを先に決めます。すべてを最高水準で満たす製品は存在しないため、優先順位の明確化が製品選定のブレを防ぎます。

3. 製品をスクリーニングする

   判断軸に照らして候補を絞ります。軽量・低コストを優先するならTomcat、Jakarta EE完全準拠が必要ならWildFlyまたはGlassFish、商用サポートと統合管理を重視するならJBoss Enterprise（Red Hat）が選択肢に挙がります。

4. 見落としやすいリスクを確認する

   ライセンス変更・バージョンアップ時の互換性・ベンダーロックインの3点は、選定後に顕在化しやすいリスクです。採用前に移行コストと代替手段を想定しておくことが、長期運用の安定につながります。

5. 開発・運用パートナーの対応力を確認する

   選定した製品に対して、委託先が十分な導入実績と運用ノウハウを持っているかを確認します。製品自体の優劣よりも、パートナーの習熟度がプロジェクト品質を左右するケースは少なくありません。

APサーバーの比較検討は、この5ステップを順に進めることで、判断の根拠が明確になります。要件整理の精度が低いまま製品比較に入ると、選定後に「想定外のコスト」や「運用上の制約」が生じやすくなります。意思決定の早い段階で要件と優先軸を固めることが、APサーバー選定における最大のリスク管理といえます。