2026.10.22 Java

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・対応仕様の早見表

公式の版一覧ページによると、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系の移行ガイドでも、10.1系との差分の最初に「Java 17 required」が挙がっています。Tomcatの内部構造と系列の位置づけは、Tomcatの仕組みと対応Java版の解説で扱っています。

サポート終了済みの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サポート終了の告知で確定しました。版一覧ページには「2027年3月31日より前には終わらない見込み」という以前の表現が残っていますが、日付を決めたのはこの告知です。終了後は次の順に変わります。

2027年3月31日の少し前：9.0系の最終リリースと、9.1系の最初のリリースが出る
2027年3月31日以降：9.0系のリリースは極めて考えにくくなり、9.0系だけのバグは直されず、脆弱性報告も9.0系に照合されない
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コネクタの設定リファレンスによると、protocol="AJP/1.3"は自動切替で、Tomcat NativeのライブラリがPATHやLD_LIBRARY_PATHにあればAPR版が選ばれます。HTTPコネクタも、HTTPコネクタの設定リファレンスのとおり、ライブラリがあり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 は前段と共有する値）
<Connector protocol="org.apache.coyote.ajp.AjpNioProtocol" port="8009"
           address="127.0.0.1" secretRequired="true" 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のシステム要件では組み込みTomcatは11.0.x（Servlet 6.1）、3.5系のシステム要件では10.1（10.1.25以降）です。組み込み版の更新はSpring Bootの版上げと一体なので、サポート期限はSpring Bootのバージョン一覧とサポート期限で確認します。

稼働中の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で定義されています。現行のソースではAPR loadedの行も出るため、9.1系の前提を満たしているかの確認にも使えます。古い9.0系の版ではこの行が出ないことがあるので、その場合は前の項のgrepで判断してください。

OSのパッケージで入れたTomcatは、配布元が独自に修正を当てて版番号を付けていることがあります。その場合のサポート期限はApacheの日付ではなく、OSディストリビューション側の告知に従います。

security-9.htmlのAffects欄で自分の版が影響範囲かを判定する読み方

版が分かったら、9.0系のセキュリティ情報と突き合わせます。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の脆弱性一覧と対応手順にまとめています。

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を配布しており、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によると、変換対象はクラス内の参照、文字列定数、設定ファイル、JSP、TLDまで及びます。一方で、WAR内のJARに付いた署名は外されます。javax.*のうちJava EEに属さないパッケージは変換されません。

このツールは「動かすための変換」であって、依存ライブラリの版上げの代わりにはなりません。jakarta対応版が出ているライブラリは、変換に頼らず新しい版へ差し替えるのが本筋です。

legacyAppBaseに置いて配備時に自動変換させるHost設定

10.1系と11.0系には、Java EE向けのWARを配備時に変換する仕組みがあります。Hostの設定リファレンスによると、legacyAppBaseで指定したディレクトリに置いたWARやディレクトリは、移行ツールの既定設定で変換されてappBaseへ配置されます。既定値はwebapps-javaeeです。

<!-- conf/server.xml（legacyAppBase は省略時も webapps-javaee） -->
<Host name="localhost" appBase="webapps" legacyAppBase="webapps-javaee"
      unpackWARs="true" autoDeploy="true">
</Host>

# 9.0系向けのWARをそのまま置くと、変換後のものが webapps に配備される
cp app.war "$CATALINA_BASE/webapps-javaee/"

既定設定で変換できないアプリは、$CATALINA_HOME/binのmigrate.shで細かい指定をして手動変換します。この自動変換は検証環境で「動くかどうか」を早く確かめる用途に限り、本番の成果物はビルド工程で変換して固定するのが安全です。本番で配備のたびに変換すると、障害時に「どの変換結果が動いていたか」を追えません。JDKやSpringの版上げを含めた移行の全体像は、Javaマイグレーションの手順とJakarta移行を参照してください。

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系への影響が確認されず、修正版も出ないからです。依存部品の棚卸しから版上げ後の回帰テストまでを外部に任せたい場合は、保守運用・内製化支援で既存システムの版上げ計画から相談を受けています。

よくある質問

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系です。