---
title: "Tomcatバージョン一覧とサポート期限【2026年10月】9.0系は2027年3月末で終了・9.1系と11.0系への移行判断"
url: "https://www.issoh.co.jp/tech/details/18728/"
published: 2026-10-22
updated: 2026-10-22
categories: ["Java"]
publisher: "株式会社一創"
---
# Tomcatバージョン一覧とサポート期限【2026年10月】9.0系は2027年3月末で終了・9.1系と11.0系への移行判断
Apache Tomcat 9.0系のサポートは、2027年3月31日で終わります。公式は2026年2月11日にこの日付を確定として告知し、終了後は9.1系という延長用のブランチで2030年12月31日まで修正版を出すと発表しました。この記事では、2026年10月22日時点で現行の11.0・10.1・9.0系と、終了済み系列のEOL日を一覧にし、系列ごとに必要なJavaとServlet仕様を整理します。稼働中の版を確かめるコマンド、9.1系へ移る前に見直すコネクタ設定、javaxからjakartaへ変換する移行ツールの使い方まで、公式ドキュメントに沿ってまとめました。
## まとめ｜Tomcat 9は2027年3月末に終了、新規は11.0系で既存は移行を計画
サポート中の系列は11.0.x・10.1.x・9.0.xの3つで、最新版はそれぞれ11.0.27・10.1.61・9.0.123です（いずれも2026年10月12日リリース）。8.5系は2024年3月31日、10.0系は2022年10月31日に終了しており、これらで動くシステムには修正版が出ません。
取るべき行動は、置かれた状況で分かれます。**新規構築はJava 17以降を前提に11.0系**を選ぶ方針です。9.0系の既存システムは、依存ライブラリがjakarta対応版へ置き換えられるなら11.0系へ上げ、置き換えられない部品が残るなら9.1系で2030年末まで時間を稼ぐ判断になります。どちらを選ぶにしても、方針と予算は2027年3月より前に固めておく必要があります。
## 2026年10月時点のTomcatバージョン一覧と系列別のJava要件・Servlet仕様
### 現行3系列11.0・10.1・9.0の最新版と必要なJava・対応仕様の早見表
[公式の版一覧ページ](https://tomcat.apache.org/whichversion.html)によると、2026年10月22日時点でサポートされている系列と要件は次のとおりです。
| 系列 | 最新版 | Servlet | JSP | 対応する仕様群 | 必要なJava | サポート終了 |
| ------ | ------- | ------- | --- | ------------- | ------- | ---------- |
| 11.0.x | 11.0.27 | 6.1 | 4.0 | Jakarta EE 11 | 17以降 | 未発表 |
| 10.1.x | 10.1.61 | 6.0 | 3.1 | Jakarta EE 10 | 11以降 | 未発表 |
| 9.0.x | 9.0.123 | 4.0 | 2.3 | Java EE 8 | 8以降 | 2027年3月31日 |
系列が1つ上がるたびに、必要なJavaの下限も上がります。11.0系はJava 17未満では動かないため、版上げの前にJDKを入れ替える工程が必要です。[11.0系の移行ガイド](https://tomcat.apache.org/migration-11.0.html)でも、10.1系との差分の最初に「Java 17 required」が挙がっています。Tomcatの内部構造と系列の位置づけは、[Tomcatの仕組みと対応Java版の解説](https://www.issoh.co.jp/tech/details/18726/)で扱っています。
### サポート終了済みの10.0・8.5・8.0・7.0系の最終版とEOL日の一覧
同じ版一覧ページの「Unsupported Versions」に載っている、主な終了済み系列です。
| 系列 | 最終版 | 必要なJava | サポート終了日 |
| ------ | ------- | ------- | ----------- |
| 10.0.x | 10.0.27 | 8以降 | 2022年10月31日 |
| 8.5.x | 8.5.100 | 7以降 | 2024年3月31日 |
| 7.0.x | 7.0.109 | 6以降 | 2021年3月31日 |
| 8.0.x | 8.0.53 | 7以降 | 2018年6月30日 |
| 6.0.x | 6.0.53 | 5以降 | 2016年12月31日 |
公式は最終版について、これ以降のリリースは極めて考えにくいと注記しています。8.5系は9.0系と同じjavax名前空間なので、パッケージ名を書き換えずに9.0系へ移れます。ただし9.0系の残りは約5か月です。**8.5系の移行先に9.0系を選ぶと、半年以内にもう一度版上げの判断が来ます**。8.5系からは、11.0系への移行計画を最初から立てるほうが手戻りは少なく済みます。
## Tomcat 9のサポート期限2027年3月末と9.1系による2030年末までの延長
### 2026年2月の公式告知で確定した9.0系終了後に起きる変化の順序
9.0系の終了日は、2026年2月11日付の[9.0.xサポート終了の告知](https://tomcat.apache.org/tomcat-9.0.x-eos.html)で確定しました。版一覧ページには「2027年3月31日より前には終わらない見込み」という以前の表現が残っていますが、日付を決めたのはこの告知です。終了後は次の順に変わります。
1. 2027年3月31日の少し前：9.0系の最終リリースと、9.1系の最初のリリースが出る
2. 2027年3月31日以降：9.0系のリリースは極めて考えにくくなり、9.0系だけのバグは直されず、脆弱性報告も9.0系に照合されない
3. 2027年6月30日以降：9.0系のダウンロードリンク、ミラー上の最新版、tomcat.apache.org上のドキュメントへのリンクが外れる（アーカイブには残る）
2つ目の項目が実務では効きます。脆弱性情報の影響範囲に9.0系が書かれなくなるため、「載っていないから無関係」とは読めなくなります。9.1系への切り替えは、この日付までに済ませておく作業です。
### 9.1系で外れるAPR/nativeコネクタとserver.xmlで確かめる設定
9.1系と9.0系の違いは小さく、告知が挙げる変更は2点です。HTTP・HTTPS・AJPのAPR/nativeコネクタが無くなることと、Tomcat Native 1.3.xが対象外になることです（2.0.xは引き続き使えます）。Tomcat Nativeを使っていないか2.0.xを使っている環境なら、9.0系から9.1系への切り替えは通常のパッチ更新と変わりません。
見落としやすいのは、server.xmlに「Apr」と書いていなくてもAPRが使われている場合です。[9.0系のAJPコネクタの設定リファレンス](https://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html)によると、`protocol="AJP/1.3"`は自動切替で、Tomcat NativeのライブラリがPATHやLD\_LIBRARY\_PATHにあればAPR版が選ばれます。HTTPコネクタも、[HTTPコネクタの設定リファレンス](https://tomcat.apache.org/tomcat-9.0-doc/config/http.html)のとおり、ライブラリがあり`AprLifecycleListener`の`useAprConnector`がtrueならAPR版になります。
```
# server.xml で APR を明示しているか、自動切替の値を使っているかを見る
grep -nE 'Apr|protocol=' "$CATALINA_BASE/conf/server.xml"
# 起動スクリプトで Tomcat Native のライブラリパスを足していないかを見る
grep -n 'LD_LIBRARY_PATH' "$CATALINA_BASE/bin/setenv.sh"
# 9.1系へ移る前に、AJP は NIO 版を明示しておく（secret は前段と共有する値）
```
告知は、APR/native版のAJPとHTTPを使っている環境にNIO版への移行を強く勧めています。`protocol`をNIO版のクラス名で明示しておけば、9.1系へ切り替えた日に挙動が変わる心配はありません。
### 10.1系と11.0系の終了日は未発表、Spring Bootの組み込み版との対応
2026年10月22日時点で、10.1系と11.0系の終了日は版一覧ページに載っていません。決まっているのは9.0系と9.1系の日付だけです。10.1系はJakarta EE 10、11.0系はJakarta EE 11に対応する系列で、公式は11.0系を開発の中心と位置づけています。
Spring Bootで作ったアプリは、組み込みTomcatの系列がSpring Bootの版で決まります。[Spring Boot 4.1のシステム要件](https://docs.spring.io/spring-boot/system-requirements.html)では組み込みTomcatは11.0.x（Servlet 6.1）、[3.5系のシステム要件](https://docs.spring.io/spring-boot/3.5/system-requirements.html)では10.1（10.1.25以降）です。組み込み版の更新はSpring Bootの版上げと一体なので、サポート期限は[Spring Bootのバージョン一覧とサポート期限](https://www.issoh.co.jp/tech/details/5172/)で確認します。
## 稼働中のTomcatの版とJavaを確かめるコマンドとセキュリティ情報の読み方
### version.shの出力で系列・パッチ番号・実行中のJVMを確認する手順
版の確認は、Tomcatに同梱の`bin/version.sh`（Windowsは`version.bat`）で済みます。中身は`catalina.sh version`の呼び出しで、`setenv.sh`で指定したJAVA\_HOMEも読み込むため、本番の起動に使われるJavaが表示されます。
```
cd "$CATALINA_HOME"
./bin/version.sh
# 出力のうち確認する行（ServerInfo.java の出力項目）
# Server version: Apache Tomcat/（系列とパッチ番号）
# Server number: （末尾に .0 を足した4つの数字の版番号）
# JVM Version: （起動に使う Java の版）
# APR loaded: true または false
```
出力項目は[9.0.xブランチのServerInfo.java](https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/catalina/util/ServerInfo.java)で定義されています。現行のソースでは`APR loaded`の行も出るため、9.1系の前提を満たしているかの確認にも使えます。古い9.0系の版ではこの行が出ないことがあるので、その場合は前の項のgrepで判断してください。
OSのパッケージで入れたTomcatは、配布元が独自に修正を当てて版番号を付けていることがあります。その場合のサポート期限はApacheの日付ではなく、OSディストリビューション側の告知に従います。
### security-9.htmlのAffects欄で自分の版が影響範囲かを判定する読み方
版が分かったら、[9.0系のセキュリティ情報](https://tomcat.apache.org/security-9.html)と突き合わせます。2026年10月20日に公表された9.0.123の修正分を例にすると、Affects欄の幅は脆弱性ごとに大きく違います。
- CVE-2026-101296（Important）：JNDIRealmにGSSAPI以外のSASL認証を設定していると、正しいパスワード無しで認証を通せる。Affectsは9.0.0.M1〜9.0.122で、9.0系のほぼ全版が該当
- CVE-2026-101356（Important）：非同期サーブレットのHTTP/2処理でエラー後にリクエストと応答が利用者間で入れ替わる。Affectsは9.0.118〜9.0.122で、古い版は対象外
判定は「版がAffectsの範囲に入るか」と「その機能を使っているか」の2段で行います。JNDIRealmもHTTP/2も使っていない構成なら、上の2件の緊急度は低いという判断です。系列ごとの影響範囲と当て方の手順は[Apache Tomcatの脆弱性一覧と対応手順](https://www.issoh.co.jp/tech/details/15405/)にまとめています。
## 9.0系から10.1系・11.0系へ上げるjavaxからjakartaへの変換手順
### 移行ツール1.0.13でWARのjavaxをjakartaへ一括変換するコマンド
9.0系から10.1系以降へ上げるときの壁は、APIのパッケージ名が`javax.*`から`jakarta.*`へ変わったことです。Apacheはこの書き換えを自動で行う[Tomcat Migration Tool for Jakarta EE](https://tomcat.apache.org/download-migration.cgi)を配布しており、2026年10月22日時点の最新版は1.0.13です。
```
# 公式ダウンロードページの shaded jar を取得し、.sha512 の値と照合してから使う
curl -O https://dlcdn.apache.org/tomcat/jakartaee-migration/v1.0.13/binaries/jakartaee-migration-1.0.13-shaded.jar
sha512sum jakartaee-migration-1.0.13-shaded.jar
# 変換元（WAR・ディレクトリ・単体ファイル）と変換先を指定する
java -jar jakartaee-migration-1.0.13-shaded.jar app.war app-jakarta.war
```
[移行ツールのREADME](https://github.com/apache/tomcat-jakartaee-migration)によると、変換対象はクラス内の参照、文字列定数、設定ファイル、JSP、TLDまで及びます。一方で、WAR内のJARに付いた署名は外されます。`javax.*`のうちJava EEに属さないパッケージは変換されません。
このツールは「動かすための変換」であって、依存ライブラリの版上げの代わりにはなりません。jakarta対応版が出ているライブラリは、変換に頼らず新しい版へ差し替えるのが本筋です。
### legacyAppBaseに置いて配備時に自動変換させるHost設定
10.1系と11.0系には、Java EE向けのWARを配備時に変換する仕組みがあります。[Hostの設定リファレンス](https://tomcat.apache.org/tomcat-11.0-doc/config/host.html)によると、`legacyAppBase`で指定したディレクトリに置いたWARやディレクトリは、移行ツールの既定設定で変換されて`appBase`へ配置されます。既定値は`webapps-javaee`です。
```
# 9.0系向けのWARをそのまま置くと、変換後のものが webapps に配備される
cp app.war "$CATALINA_BASE/webapps-javaee/"
```
既定設定で変換できないアプリは、`$CATALINA_HOME/bin`の`migrate.sh`で細かい指定をして手動変換します。**この自動変換は検証環境で「動くかどうか」を早く確かめる用途に限り、本番の成果物はビルド工程で変換して固定する**のが安全です。本番で配備のたびに変換すると、障害時に「どの変換結果が動いていたか」を追えません。JDKやSpringの版上げを含めた移行の全体像は、[Javaマイグレーションの手順とJakarta移行](https://www.issoh.co.jp/tech/details/1314/)を参照してください。
## 9.1系で延命するか11.0系へ上げるかを決める判断基準と見送る条件
### 9.1系にとどまってよい条件と2030年12月末までに抱える負債
9.1系を選んでよいのは、次のどちらかに当てはまる場合に限られます。1つは、jakarta対応版が無く置き換え先も決まらない依存部品がある場合です。帳票や認証の古い商用ライブラリ、Tomcat 9上での動作しか保証しないパッケージ製品が典型例に当たります。もう1つは、2027年3月までに移行と検証を終える体制がどうしても組めない場合です。
9.1系は時間を買う選択です。Java EE 8の仕様に固定されるため、Servlet 6.1を前提にするSpring Boot 4系などの新しいフレームワークは載りません。終了日の2030年12月31日には、結局jakartaへの移行が残ります。**9.1系を選ぶなら、移行完了の目標を2029年中に置いて計画に書き込みます**。目標の無い延命は、2030年に同じ判断をもっと短い期限で迫られるだけです。
### Java 17を用意できるなら11.0系へ直行し10.1系を経由しない理由
javaxからjakartaへの書き換えは、10.1系へ上げても11.0系へ上げても共通の作業です。大きな差は必要なJavaで、10.1系はJava 11、11.0系はJava 17から動きます。それ以外の差分は移行ガイドに列挙されており、版上げの前に一覧で確認できます。Java 17を用意できるなら、開発の中心にある11.0系へ直接上げる方針です。10.1系を経由すると、終了日が発表された時点でもう一度版上げが必要になります。
10.1系を選ぶのは、OSやミドルウェアの都合でJavaを11に固定せざるを得ない場合だけです。逆に、**2027年3月以降も9.0系のままインターネットに公開したシステムを動かす選択は採りません**。脆弱性が公表されても9.0系への影響が確認されず、修正版も出ないからです。依存部品の棚卸しから版上げ後の回帰テストまでを外部に任せたい場合は、[保守運用・内製化支援](https://www.issoh.co.jp/service/system/maintenance/)で既存システムの版上げ計画から相談を受けています。
## よくある質問
Tomcatのサポート期限と版の選び方について、検索の多い質問に答えます。
### Tomcat 9はいつまで使えますか？
9.0系の公式サポートは2027年3月31日までです。その後は9.0系のリリースが極めて考えにくくなり、脆弱性報告も9.0系に照合されません。2027年6月30日以降はダウンロードリンクとドキュメントへのリンクも外れます。延長ブランチの9.1系は2030年12月31日までリリースが続くため、Tomcat 9として使える期限は9.1系に移れば2030年末までです。
### Tomcat 9.1とは何ですか？
9.0系の終了直前にリリースが始まる、Tomcat 9の延長サポート用のブランチです。9.0系との違いはAPR/nativeコネクタが無くなることとTomcat Native 1.3.xが対象外になることで、セキュリティ修正やバグ修正の取り込みは9.0系と同じように続きます。ただし公式は、9.1系にとどまるより新しい版へ上げることを強く勧めています。
### Tomcatの最新バージョンはいくつですか？
2026年10月22日時点の最新版は11.0.27で、2026年10月12日にリリースされました。同日に10.1.61と9.0.123も出ています。Tomcatは系列ごとに修正版が並行して出るため、「最新」は使っている系列の最新パッチを指すと考えてください。最新の番号は公式の版一覧ページで確かめられます。
### Tomcat 8.5を使い続けるとどうなりますか？
8.5系は2024年3月31日に終了しており、最終版は8.5.100です。以降に公表された脆弱性は8.5系への影響が確認されず、修正版も出ません。8.5系は9.0系と同じjavax名前空間なのでパッケージ名を書き換えずに移れますが、9.0系も2027年3月に終わります。移行先は11.0系か、事情があれば9.1系を選びます。
### Tomcat 10と11はどちらを選べばよいですか？
10.0系は2022年10月31日に終了しているため、候補は10.1系か11.0系です。Java 17以降を使えるなら11.0系を選びます。jakartaへの書き換えはどちらでも必要で、11.0系のほうが開発の中心にあるためです。Javaを11に固定する事情があるときだけ10.1系にします。Spring Boot 4系の組み込みTomcatも11.0系です。
## 関連記事
- [Tomcatとは？サーブレットコンテナの仕組みと対応Java版・Apacheとの分担を実装目線で解説](https://www.issoh.co.jp/tech/details/18726/)：Tomcatの内部構造と系列の選び分けの全体像
- [Apache Tomcatの脆弱性一覧【2026年10月】最新版11.0.27・10.1.61・9.0.123とCVE-2026-59083ほかの影響確認・対応手順](https://www.issoh.co.jp/tech/details/15405/)：系列ごとの影響範囲と修正版の当て方
- [Spring Bootバージョン一覧とサポート期限（EOL）【2026年10月】最新版は4.1、4.0の無償サポートは12月末終了](https://www.issoh.co.jp/tech/details/5172/)：組み込みTomcatの系列を決めるSpring Bootの期限
- [Javaマイグレーションの進め方｜JDK 8→21/25の手順とSpring Boot・Jakarta移行](https://www.issoh.co.jp/tech/details/1314/)：Tomcat 9から11へ上げる前のJDKとjakarta移行
- [JSF（Jakarta Faces）とは？仕組み・使い方と最新版4.1をTomcat 11で動かす手順](https://www.issoh.co.jp/tech/details/3967/)：Tomcat 11上でJakarta EEの画面技術を動かす例
---
出典: [Tomcatバージョン一覧とサポート期限【2026年10月】9.0系は2027年3月末で終了・9.1系と11.0系への移行判断]()（株式会社一創）