LASSIC Media らしくメディア
Tomcatバージョンアップの進め方｜サポート期限と移行の確認点
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- Tomcatのバージョンアップには、同じ系列の中の更新と、9から10.1や11へ大きな版をまたぐ移行の2種類があります。
- 8.5系はすでにサポートが終わり、9.0系も2027年3月31日に終了する予定と公式が公表しています。
- 大きな版をまたぐときは古い設定を写さず新しい版の初期設定から始め、検証と切り戻しの手順を用意します。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
社内システムを動かしているTomcatの版が古いと指摘されたが、上げると何が壊れるのか分からない。前任者が入れたまま、どの版が動いているのかも確かめていない——。Javaで作った業務システムを長く使っている会社では、こうした状況が起こりがちです。Tomcat（トムキャット）は、Jakarta EE（Javaで業務用のWebシステムを作るための標準仕様。旧称Java EE）の一部を実装したオープンソースのソフトウェアで、Javaで作ったWebアプリケーションを動かす土台になります。
版を上げれば、修正済みの脆弱性への対策が入り、公式のサポートの範囲にとどまれます。ただし万能ではなく、上げ方によってはアプリケーションの作り直しに近い作業が要ることもあります。本記事では、古いTomcatを保守している情報システムの担当者に向けて、版ごとのサポート期限、使い続けるか上げるかの判断、バージョンアップの進め方、そして外部に頼むときに確認したい点を整理します。
目次
Tomcatのバージョンアップとは
Tomcatの版は「9.0.123」のように、数字を点で区切って表します。公式の移行ガイドは、9.0.29から9.0.30のような同じ大きな版の中の更新と、9から10のように大きな版をまたぐ移行を分けて説明しています。*5 同じバージョンアップでも、この2つでは作業の重さがまったく違います。
- 同じ系列の中の更新（例：9.0系の中で新しい番号へ）：設定ファイルは引き継げますが、既定値が変わっていないか、新しい設定項目が増えていないかを確かめます
- 大きな版をまたぐ移行（例：9から10.1や11へ）：古い設定ファイルをそのまま写さず、新しい版の初期設定から始めて必要な分だけ直すよう、公式は勧めています
- 9から10以降へ上がるとき：アプリケーションが使う部品の名前（Javaのパッケージ名）がjavaxからjakartaに変わるため、アプリケーションを新しい名前に合わせて作り直す（再コンパイルする）必要があります*6
版ごとのサポート期限
Tomcatの公式サイトは、版ごとのサポートの状態と、動かすのに必要なJavaの版を一覧で公開しています。*1 2026年10月時点の内容を整理すると、次のとおりです。
| 版 | サポートの状態 | 必要なJavaの版 |
|---|---|---|
| 11.0系 | サポート中 | 17以降 |
| 10.1系 | サポート中 | 11以降 |
| 9.0系 | サポート中（2027年3月31日に終了予定と公表）*2 | 8以降 |
| 10.0系 | 2022年10月31日に終了 | 8以降 |
| 8.5系 | 2024年3月31日に終了 | 7以降 |
| 7.0系 | 2021年3月31日に終了 | 6以降 |
サポートが終わると何が変わるのかは、8.5系の終了の告知に書かれています。終了日を過ぎると、その系列の新しい版はまず出ず、その系列だけの不具合は直されず、脆弱性の報告もその系列に当てはまるかどうかを確かめなくなります。*3
また公式は、ごく一部の例外を除いて、脆弱性ごとの修正プログラムは作らず、修正が入った版へ上げるよう案内しています。*4 版を上げないかぎり脆弱性の修正は手に入らない、と考えておく必要があります。
使い続けるか版を上げるか
IPA（情報処理推進機構）の中小企業向けガイドラインは、ソフトウェアのサポート期限を定期的に確かめ、「利用の継続が必要なものについてはサポート期限が切れる前に更改を実施しましょう」としています。*7 Tomcatでも、いまの版がどこにあるかで取るべき手が変わります。
- サポート中の系列で古い番号のまま：同じ系列の最新の番号へ更新します。作業は軽く、定期的な保守に組み込めます
- 9.0系：2027年3月31日の終了予定に向けて、10.1系か11.0系へ上がる計画を立てます
- 8.5系以前：すでにサポートが終わっています。外部から接続できる範囲を確かめたうえで、早めに移行の計画を立てます
- アプリケーションの作り直しが重い場合：9.0系の中で更新を続けながら、作り直す範囲と予算を先に見積もります
移行先は、Javaの版とセットで考えます。10.1系は11以降、11.0系は17以降のJavaを必要とします。*1 公式は、サポート中の9.0系・10.1系・11.0系のどれもJava 17で正しく動くとしています。*5 Javaの版上げも同時に進めるなら、Java 8のサポート終了への対応もあわせて確かめてください。
バージョンアップの進め方
大きな版をまたぐバージョンアップは、次の4つの段階で進めると、切り替えの当日に慌てずに済みます。
- ステップ1：いま動いている版を棚卸しする（Tomcatの版、Javaの版、載っているアプリケーション、設定を変えた箇所）
- ステップ2：移行先の版を決める（サポートの期限と、必要なJavaの版から選ぶ）
- ステップ3：新しい版の初期設定に、必要な設定だけを移す（古い設定ファイルはそのまま写さない）
- ステップ4：検証用の環境で業務の操作を試し、元に戻す手順を用意してから本番を切り替える
つまずきやすいのはステップ3とステップ4です。9から10以降へ上がる場合、アプリケーションをjakartaの名前に合わせる必要があります。公式は古いアプリケーションを変換する移行ツール（Apache Tomcat migration tool for Jakarta EE）を用意しており、配置するときにTomcatに自動で変換させることもできます。*6 変換後の動作は、検証用の環境で業務の操作を一通り試して確かめます。
外部に頼むときに確認しておきたい点
Tomcatの版上げは、入れ替えの作業よりも、アプリケーションと設定の確認に手間がかかります。構築や移行を外部に頼むときは、見積もりの前に次の点を確かめておきます。
- どこまで頼むか：棚卸し、移行先の版の選定、アプリケーションの変換、検証、本番の切り替えのうち、どれを任せるか
- 検証の範囲：どの業務の操作を、誰が、どの環境で試すか。合格の基準を先に決めておくか
- 切り戻し：切り替えた後に不具合が出たとき、元の版に戻す手順と、戻すかどうかを判断する人を決めているか
- Javaとの関係：Javaの版上げも同時に行うか、時期を分けるか
- 切り替え後の保守：同じ系列の新しい番号が出たとき、誰がいつ更新するか。次の終了日をどこで追うか
特に切り替え後の保守は、決めないまま運用に入りやすい点です。商用のアプリケーションサーバーからTomcatなどへ移す場合の考え方はWebLogic/WebSphere移行でコスト最適化にまとめています。
まとめ：Tomcatのバージョンアップで確かめておきたい3つの点
Tomcatのバージョンアップを進めるうえで、確かめておきたい点は3つに整理できます。第一に、いま動いているTomcatとJavaの版を棚卸しし、公式のサポート期限と照らし合わせること。第二に、同じ系列の中の更新か、大きな版をまたぐ移行かを分けて、作業の重さを見積もること。第三に、検証の範囲と切り戻しの手順、切り替え後の更新の担当を、作業の前に決めておくことです。この3点を踏まえておけば、「版を上げたら業務の画面が動かなくなった」という事態を避けやすくなります。移行の計画や検証の進め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
同じ系列の中の小さな更新でも確認は必要ですか
必要です。公式は、9.0.29から9.0.30のような同じ大きな版の中の更新では設定ファイルを引き継げるとしつつ、既定値の変更や新しい設定項目が無いかを確かめるよう求めています。*5 変更点は、版ごとに公開される変更履歴で確かめられます。
サポートが終わった版の脆弱性は調べられますか
公式サイトは、サポートが終わった8.x系や7.x系などについても、修正された脆弱性の一覧を公開しています。*4 ただし終了日の後に報告された脆弱性は、その系列に当てはまるかどうかが確かめられません。*3 一覧に載っていないからといって、問題が無いとは言い切れません。
9.0系から11.0系へ一気に上げてもよいですか
一気に上げることもできますが、間の版の変更点も確かめる必要があります。公式の移行ガイドは、9.0系から10.0系、10.0系から10.1系、10.1系から11.0系というように、大きな版ごとに変更点をまとめています。*5 また11.0系はJava 17以降が必要なので、Javaの版上げも同時に進めることになります。
Tomcatのバージョンアップのご相談
古いTomcatの棚卸しから、移行先の版の選定、アプリケーションの変換と検証、切り替え後の保守まで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：The Apache Software Foundation「Apache Tomcat Versions（Which Version Do I Want?）」（https://tomcat.apache.org/whichversion.html）。出典：サポート中の版（11.0.x・10.1.x・9.0.x）と必要なJavaの版、サポートが終わった版（10.0.x・8.5.x・7.0.x）の終了日の一覧を参照（2026年10月確認）
- *2 参考：The Apache Software Foundation「Apache Tomcat」公式サイト トップページ（https://tomcat.apache.org/）。出典：Tomcat 9.0.123 のリリースのお知らせにある、9.0.x のサポート終了日（2027年3月31日）の公表を参照（2026年10月確認）
- *3 参考：The Apache Software Foundation「End of life for Apache Tomcat 8.5.x」（https://tomcat.apache.org/tomcat-85-eol.html）。出典：サポート終了後に新しい版が出ないこと、不具合が直されないこと、脆弱性の報告が確かめられないことの記述を参照（2026年10月確認）
- *4 参考：The Apache Software Foundation「Apache Tomcat Security Reports」（https://tomcat.apache.org/security.html）。出典：個別の脆弱性ごとの修正プログラムは原則作らず修正済みの版へ上げるよう求めていること、サポート終了版の脆弱性一覧の公開を参照（2026年10月確認）
- *5 参考：The Apache Software Foundation「Apache Tomcat Migration Guide」（https://tomcat.apache.org/migration.html）。出典：大きな版をまたぐときは古い設定ファイルを写さず新しい版の初期設定から始めること、同じ版の中の更新の扱い、サポート中の版がJava 17で動くこと、版ごとの移行ガイドの一覧を参照（2026年10月確認）
- *6 参考：The Apache Software Foundation「Migration Guide – Tomcat 10.0.x」（https://tomcat.apache.org/migration-10.html）。出典：javaxからjakartaへのパッケージ名の変更、再コンパイルの必要、Apache Tomcat migration tool for Jakarta EE による変換の記述を参照（2026年10月確認）
- *7 参考：独立行政法人情報処理推進機構（IPA）「中小企業の情報セキュリティ対策ガイドライン 第4.0版」（https://www.ipa.go.jp/security/guide/sme/about.html）。出典：サポート期限の切れたOS及びソフトウェアの利用停止及び更改についての記述を参照（2026年10月確認）
