Tomcatのシステム開発の完全ガイド - ブログ

Tomcatのシステムとは、Tomcatそのものが業務機能を提供する製品ではなく、Javaで作った業務アプリケーションをWeb上で動かすための実行基盤を組み込んだシステムです。画面や業務ルール、データベース、外部サービス、運用設計まで含めて初めて、販売管理や申請、顧客管理などの業務システムとして機能します。

本記事では、Tomcatの役割と典型構成、SpringやJakartaとの関係、パッケージ・クラウド・スクラッチの選び方、2026年時点の費用相場、開発の進め方、バージョン移行、セキュリティ、開発会社やベンダーの選び方までをまとめて解説します。既存のJavaシステムを更新したい方にも、新しく業務Webシステムを企画する方にも、最初に整理すべき論点が分かる内容です。

Tomcatのシステムとは何ですか？

Tomcatのシステムは、JavaのWebアプリケーションを受け付けて実行するTomcatを中心に、Webサーバー、データベース、認証、外部連携、監視などを組み合わせた構成です。Tomcatを導入するだけで業務システムが完成するわけではない点が、最初に押さえるべき結論です。

Tomcatが担う役割

Tomcatは、HTTPまたはHTTPSで届いたリクエストを受け取り、ServletやJSPなどのJavaアプリケーションを実行し、処理結果をブラウザへ返します。セッション管理、アプリケーションの配備、アクセスログやエラーログの出力、JNDIを使ったデータベース接続なども担当します。ただし、受注計算、在庫引当、承認経路、帳票の業務ルールはアプリケーション側に実装されます。

そのため、提案書や見積書で「Tomcat構築一式」とだけ書かれている場合は注意が必要です。Tomcatのインストールと設定だけなのか、Javaアプリの改修、データベース構築、負荷試験、障害監視、パッチ適用まで含むのかで、費用も責任範囲も大きく変わります。

Javaアプリケーションとの関係

Tomcat上に配備される代表的な形式はWARファイルです。開発したJavaアプリケーションをWARとしてまとめ、Tomcatの所定の場所へ配備して動かします。新しい開発では、Spring Bootの組み込みTomcatを利用してアプリケーションと実行環境を一体化する方法もあります。既存システムでは外部TomcatへWARを配備する方式が残っていることも多く、方式の違いを理解せずに移行すると、起動オプション、環境変数、ログ出力先、セッションの扱いで問題が起きます。

また、Tomcat 10以降ではJakarta ServletのAPIが中心となり、Tomcat 9以前で使われるjavax.*からjakarta.*への名前空間変更が移行の大きな論点になります。これはサーバーの入れ替えだけで自動的に解決できる問題ではなく、ソースコード、依存ライブラリ、設定、テストコードまで確認する必要があります。

Tomcatのシステムはどのような構成ですか？

典型的な構成は、利用者のブラウザやスマートフォンからの通信を、WAFやロードバランサー、Apache HTTP ServerまたはNginxなどのリバースプロキシを経由してTomcatへ届けます。Tomcatはデータベース、キャッシュ、ファイルストレージ、外部API、基幹システムと連携します。小規模なら一台にまとめることもありますが、業務停止の影響が大きい場合は役割を分離します。

リバースプロキシとTomcatを分ける理由

リバースプロキシを前段に置くと、TLSの終端、静的ファイルの配信、アクセス制御、ロードバランシングをTomcatから切り離せます。Tomcatを複数台に増やす場合も、ロードバランサーがリクエストを振り分けるため、負荷分散や障害時の切り離しを設計しやすくなります。前段があるから安全になるのではなく、許可する通信、証明書の更新、管理画面への接続経路を適切に制限することが重要です。

複数台構成では、ログを集約し、セッションを共有するか、アプリケーションをステートレスにするかを決めます。片方のTomcatに保存されたセッションを別のTomcatが参照できないまま負荷分散すると、ログイン状態が突然失われることがあります。共有ストレージや分散キャッシュを使う場合は、性能と障害時の挙動まで負荷試験で確認します。

データベースと外部連携の設計

業務システムの品質を左右するのは、Tomcatの台数よりデータと連携の設計です。顧客、商品、在庫、受注などのマスタをどのシステムが正とするのか、外部APIが停止したときに再送するのか、二重登録をどう防ぐのかを業務要件として決めます。データベース接続数はTomcat側のコネクションプールとデータベースの最大接続数を合わせ、ピーク時の同時実行数を根拠に設定します。

ファイルをTomcatサーバーのローカルディスクだけに保存する設計も、複数台化や障害復旧で問題になりやすいです。ファイルストレージ、バックアップ、ウイルスチェック、保存期限、個人情報の暗号化を含め、アプリケーションの外側にある運用要件も最初から設計書へ反映します。

Tomcatのシステムにはどの種類がありますか？

Tomcatを使うシステムには、既存環境を維持する方法、新規アプリに組み込みTomcatを使う方法、コンテナやマネージド基盤へ移す方法などがあります。最適解はTomcatの好みで決めるのではなく、既存資産、開発速度、可用性、運用人員、将来の移行余地を比較して決めます。

既存Tomcatを継続利用する方式

既存のJavaアプリが安定稼働し、業務変更が少なく、現行の運用体制を維持できる場合は、TomcatとJDKをサポート対象へ段階的に更新する方法が現実的です。画面やデータベースを作り直さないため、全面再構築より短期間になりやすい一方、古いフレームワークや独自拡張が残るほど、将来の移行リスクは積み上がります。

継続利用を選ぶ場合も、現行のTomcat、JDK、OS、データベース、WARやJAR、依存ライブラリ、設定ファイル、バッチ、認証方式を一覧にします。担当者の記憶だけで運用している機能や、ソースコードがないバイナリ資産は、先にアセスメントの対象にして影響範囲を可視化します。

Spring Bootの組み込みTomcatを使う方式

新規開発では、Spring Bootのアプリケーションに組み込みTomcatを含め、JARとして起動する方式がよく検討されます。アプリと起動設定を一つの成果物として管理しやすく、コンテナ化やCI/CDとの相性も良いです。ただし、組み込み方式に変えるだけで品質が上がるわけではなく、ログ、設定の外部化、ヘルスチェック、メモリ、終了処理、監視を設計する必要があります。

外部TomcatへのWAR配備と組み込みTomcatのどちらが適切かは、既存の標準手順、運用チームのスキル、アプリごとの独立性、リリース頻度で判断します。複数アプリを一つのサーバーで共有している場合は、分離による運用のしやすさと、環境数が増えることによる管理負担を比較します。

クラウド・コンテナへ移行する方式

クラウドやコンテナへ移すと、環境構築の標準化、台数の増減、監視サービスとの連携を進めやすくなります。一方で、クラウドに置くだけでは自動的に安くなりません。セッション、ファイル、ネットワーク、データベース、ログ保管、バックアップ、証明書、権限をクラウドの前提に合わせて再設計する必要があります。

マネージドなTomcat基盤を利用すると、OSや一部ミドルウェアの管理を軽くできる場合があります。2026年には、Java 17・21・25とTomcat 10.1・11を組み合わせた環境が公開されており、運用基盤の選択肢は広がっています（出典: クラウド基盤の公式サポート対象一覧、2026年）。ただし、利用可能なバージョンやサポート期限は変わるため、採用時点の公式情報を確認します。

Tomcatのシステム開発はどのように進めますか？

開発では、Tomcatの設定から始めるのではなく、業務要件と非機能要件を先に決めます。特に既存システムの更新では、現状調査、影響分析、段階移行、受入テスト、切り戻しまでを一つの計画にします。次の三段階で進めると、見積もりとリスクを説明しやすくなります。

現状調査と要件定義

最初に、TomcatとJDKのバージョン、OS、データベース、フレームワーク、WARやJAR、依存ライブラリ、設定ファイル、バッチ、外部API、認証、ログ、監視、バックアップを棚卸しします。設計書やソースコードが揃っているか、担当者が不在でも復旧できるかも確認します。ブラックボックス化したアプリは、バイナリ解析や試験環境での挙動確認を含むアセスメントを先に実施します。

要件定義では、画面一覧だけでなく、同時接続数、通常時とピーク時の処理量、許容レスポンスタイム、稼働時間、障害復旧目標、データ保持期間、監査ログ、権限、バックアップ、メンテナンス時間を決めます。ユーザー側のマスタ整備、データ確認、受入テスト、現場教育の担当を曖昧にすると、開発会社だけでは解決できない遅延が起きます。

設計・実装・環境構築

基本設計では、ブラウザからデータベースまでの構成図、通信経路、認証方式、データモデル、外部連携、障害時の代替手順を定めます。詳細設計では、Tomcatのコネクタ、スレッド、接続プール、セッション、JVMメモリ、ログローテーション、ファイル権限を業務の負荷とセキュリティ要件に合わせます。初期値のまま本番運用せず、なぜその設定にしたかを設計書に残します。

実装では、業務ロジックとインフラ設定を分け、環境ごとの差分を管理します。開発、検証、本番で設定を手作業にすると、検証では動いたのに本番で動かない問題が起きます。コードレビュー、依存ライブラリの脆弱性確認、ビルド手順、ロールバック用の成果物を整備し、担当者が変わっても同じ手順で再現できる状態を目指します。

テスト・移行・リリース

テストは、単体テストと画面確認だけでは不十分です。旧環境と新環境の機能差を確認する互換性試験、ピーク時の性能試験、脆弱性診断、障害時のフェイルオーバー、バックアップからの復元、データ照合、権限テストを行います。移行後に利用者が実際の業務を完了できるか、業務部門が受入テストで確認することも重要です。

本番切り替えでは、停止時間、データの最終同期、実施担当、確認項目、切り戻しの条件と判断者を決めます。大規模なシステムは一括切り替えではなく、部門や機能を分けた段階移行も検討します。移行リハーサルを本番に近いデータ量で行い、想定外の文字コード、日付、採番、セッション、ファイル権限を洗い出します。

Tomcatのシステム開発費用相場はいくらですか？

Tomcat本体はOSSのため、原則としてライセンス購入費は発生しません。ただし、システム開発の費用はTomcatの料金ではなく、業務アプリの要件定義・開発、既存資産の解析、サーバーやデータベース、テスト、移行、監視、保守にかかります。以下の金額はTomcat単体の全国統計ではなく、業務WebシステムとJava資産移行の一般的な条件を組み合わせた概算です。画面数や連携数、非機能要件で大きく変わるため、予算検討の初期目安として使います。

▶ 詳細はこちら：Tomcatのシステム開発の見積相場や費用/コスト/値段について

規模別の費用と期間の目安

既存JavaやTomcatの資産解析・移行アセスメントは、35万円からが一つの公開価格例です（出典: Javaアプリケーションのモダナイズアセスメント公開料金、2026年3月改定）。小規模な脆弱性対応、JDKやTomcatの更新、設定変更は50万〜200万円程度、期間は1〜3か月が目安です。古いAPI、独自認証、未整理の依存ライブラリが多い場合は、調査と回帰テストの分だけ上振れします。

社内向けのCRUD、申請、台帳システムは500万〜1,500万円、期間は3〜6か月程度が一つの目安です。受発注、顧客、在庫など複数部門が使い、既存基幹連携やデータ移行を伴う中規模システムは1,500万〜5,000万円、6〜12か月程度を見込みます。大規模で24時間運用、冗長化、監査、段階移行、教育まで含む場合は5,000万円から数億円、12〜24か月以上になることもあります。

クラウド費用と保守費用

クラウドのインフラ費は、開発・検証・本番を合わせて小規模なら月3万〜30万円、中規模なら月30万〜150万円、大規模や高可用性が必要なら月100万円を超える場合があります。これはTomcatの台数だけでなく、データベース、ログ保管、バックアップ、WAF、監視、データ転送、ピーク時の処理量で決まります。見積もりでは月額だけでなく、5年間の総保有コストも確認します。

保守費用は、開発費の年10〜20％程度を仮置きすることがあります。たとえば開発費3,000万円なら、年300万〜600万円が一つの目安です。脆弱性パッチ、障害対応、監視、軽微改修、OS・JDK・Tomcat更新、問い合わせ対応のどこまで含むかで金額は変わります。契約書には受付時間、初動時間、復旧目標、対象外作業、バージョンアップの費用を明記します。

Tomcat 9から10.1・11へ移行するときの注意点は何ですか？

Tomcatのメジャーバージョン移行は、サーバーの置き換えではなく、アプリケーションと実行環境の互換性を検証するプロジェクトです。公式の移行ガイドでは、2026年時点でサポート対象としてTomcat 9.0.x、10.1.x、11.0.xが案内され、これらはJava 17で動作するとされています（出典: Apache Tomcat公式移行ガイド、2026年）。ただし、採用するバージョンのサポート条件と依存ライブラリは個別に確認します。

**javax.からjakarta.への変更**

Tomcat 9からTomcat 10系へ移行する場合、Servlet APIなどの名前空間がjavax.*からjakarta.*へ変更される点が中心課題になります。アプリケーションのimport文、web.xml、JSP、フィルター、リスナー、認証、依存ライブラリ、テストコードを確認し、対応版へ更新します。古いStrutsや独自ライブラリが残っていると、Tomcatだけを更新した段階でコンパイルや起動に失敗します。

Tomcat 10.1から11.0へ進む場合も、Javaの必要バージョン、ServletやJSPなどの仕様、内部API、設定差分を確認します。公式ガイドではTomcat 11.0系にJava 17以上が必要とされています（出典: Apache Tomcat 11.0.x移行ガイド、2026年）。JDKの更新とTomcatの更新を同時に行う場合は、原因を切り分けられるよう、段階的な検証環境を用意します。

移行前に確認するチェック項目

移行前は、まず現行環境の構成図と資産一覧を作ります。TomcatとJDKの版、OS、DB、WARやJAR、依存ライブラリ、フレームワーク、JDBCドライバー、認証、セッション、文字コード、URL書き換え、ファイル保存先、外部APIを確認します。次に、代表的な業務シナリオを選び、ログイン、登録、検索、更新、帳票、バッチ、エラー処理、権限変更までを新環境で再現します。

設定ファイルは旧環境からそのままコピーせず、新しいTomcatの標準設定を起点に必要な差分だけを反映します。これは公式移行ガイドでも推奨される考え方です。移行完了の条件を「起動した」ではなく、機能、性能、セキュリティ、運用、復元、切り戻しの確認まで含めて定義します。

Tomcatのセキュリティと運用で確認すべきことは何ですか？

Tomcatのセキュリティは、インストール時の設定だけで終わりません。脆弱性情報を定期的に確認し、適用可否を判断し、検証環境でテストしてから本番へ反映する運用が必要です。Tomcat公式のセキュリティ情報では、2026年にも設定やURL処理に関する脆弱性修正が公表されています（出典: Apache Tomcat公式セキュリティ情報、2026年）。利用中の版だけでなく、JDK、フレームワーク、ライブラリ、OSも同じ管理対象にします。

技術的な防御策

まず管理画面をインターネットへ公開せず、管理用ネットワークや踏み台経由に限定します。不要なコネクタやAJPを停止し、利用する通信だけを許可します。TLSは適切な暗号スイートと証明書更新を管理し、WAF、ネットワーク分離、最小権限、二要素認証、入力値検証、CSRF対策、セキュリティヘッダーをアプリケーションの要件として確認します。

ログは、アクセス、認証、権限変更、管理操作、アプリケーションエラー、外部連携エラーを対象にし、時刻を統一して集約します。ログを残すだけでなく、何を異常と判定し、誰が何分以内に確認し、どの手順で復旧するのかを決めます。個人情報を扱う場合は、閲覧権限、保存期間、マスキング、バックアップの暗号化、委託先との責任分界を要件に落とします。

保守運用と障害対応

運用設計では、Tomcatのパッチ情報、JDK更新、依存ライブラリの一覧、ソフトウェア部品表、証明書、ドメイン、アカウント、バックアップ、監視項目を台帳化します。メモリ使用量、ヒープ、GC、スレッド、セッション、DB接続プール、レスポンスタイム、エラー率を平常値として記録すると、障害の兆候を発見しやすくなります。

障害時にTomcatを再起動するだけの手順は、原因がデータベースや外部APIの場合に役立ちません。一次切り分け、ログの採取、影響範囲の確認、代替運用、復旧、利用者への連絡、再発防止の役割を分けます。ソースコード、設定、構成図、試験結果、復旧手順を納品物として受け取り、特定の担当者やベンダーにしか復旧できない状態を防ぎます。

Tomcatの開発会社・ベンダーはどのように選びますか？

Tomcatの開発会社を選ぶときは、Javaの開発実績だけでなく、実行基盤の構築、性能試験、脆弱性対応、データ移行、監視、障害対応まで任せられるかを確認します。Tomcatは無料でも、業務アプリと運用の責任は無料になりません。営業資料の技術用語より、自社の現行資産と業務課題を質問し、具体的な調査方法や成果物を説明できるかを見ます。

Tomcat・Java移行の経験を確認する

候補先には、Tomcat 9・10.1・11、Java 17・21以降、Spring、Jakartaへの対応経験を確認します。既存のStruts、JSP、独自認証、古いJDBCドライバー、ソースコードが不足したWARやJARを扱った経験があるかも重要です。実績を聞くときは「何を作ったか」だけでなく、移行前の課題、試験内容、障害時の対応、納品したドキュメント、保守の範囲まで質問します。

実際に担当する技術者と、現行構成を見ながら会話できるかも確認します。公開事例が少ない場合は、経験を推測して評価せず、匿名化された構成例、移行チェックリスト、テスト計画、アセスメントのサンプルを提示できるかで判断します。

見積もりと契約範囲を比較する

見積書は「システム開発一式」ではなく、現状調査、要件定義、基本設計、詳細設計、実装、単体・結合・総合テスト、性能試験、脆弱性診断、データ移行、教育、リリース、保守に分けて比較します。各工程の前提となる画面数、帳票数、外部連携数、データ量、環境数、同時接続数、納期、ユーザー側の作業も記載されている必要があります。

追加費用が発生する条件も、発注前に確認します。仕様凍結後の追加要望、マスタデータの整備不足、移行できないデータ、現行環境の想定外の独自改修、クラウドの利用料、証明書、監視、脆弱性対応、休日作業などを契約上の扱いにします。成果物として設計書、ソースコード、設定、テスト結果、運用手順、部品表を受け取れるかも確認します。

案件との相性と保守体制で決める

大規模な基幹システムと、社内向けの小規模な申請システムでは、必要な体制が異なります。業界知識、現場との要件整理、短いサイクルでの改修、24時間の障害対応、既存システムとの連携など、自社が重視する条件に優先順位を付けます。会社の規模だけで決めず、プロジェクト責任者、技術者、運用担当の役割と稼働予定を確認します。

最終的には、価格の安さだけでなく、移行後に自社が運用できるかで比較します。定例会議の頻度、課題管理、変更管理、障害時の連絡経路、SLA、引き継ぎ計画、保守終了時のデータとソースコードの扱いが明確なら、長期運用の不確実性を減らせます。

▶ 詳細はこちら：Tomcatのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：Tomcatのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

▶ 詳細はこちら：Tomcatのシステム開発の発注/外注/依頼/委託方法について

Tomcatのシステムに関するよくある質問

Tomcatのシステムを検討するときは、無料かどうか、Apache HTTP Serverとの違い、Spring Bootとの関係、移行の必要性について質問が多く寄せられます。ここでは、発注や更新の判断に直結する質問へ簡潔に回答します。

Tomcatは無料なのに、なぜシステム開発費用がかかるのですか？

Tomcat本体はOSSのため、原則としてライセンス購入費が不要だからです。一方で、業務画面、データベース、外部連携、インフラ、テスト、移行、監視、保守には人件費と利用料がかかります。無料なのは実行基盤の一部であり、業務を安全に止めずに動かすための設計と運用まで無料になるわけではありません。

Apache HTTP ServerとTomcatはどちらを使えばよいですか？

役割が異なるため、単純な二者択一ではありません。Apache HTTP ServerやNginxは、静的ファイル配信、TLS終端、リバースプロキシ、ロードバランシングに向き、TomcatはJavaのServletやJSPを実行します。両方を前後段で組み合わせる構成も一般的です。システムの通信要件と運用体制に合わせて分担を決めます。

Tomcat 9をすぐに11へ上げるべきですか？

すぐに全システムを上げるのではなく、サポート期限、脆弱性、JDK、フレームワーク、業務停止の許容度を確認して移行計画を立てます。Tomcat 9から10系・11系ではAPIの変更があるため、影響が大きいアプリは、現行版の安定運用、JDK更新、アプリ改修、Tomcat更新を段階的に検証します。緊急性と移行難易度を評価し、切り戻し可能な計画にします。

Tomcatのシステムをクラウドへ移すと安くなりますか？

必ず安くなるとは限りません。サーバーの調達や一部の運用作業を軽くできる一方、データベース、監視、バックアップ、WAF、ログ、通信、冗長化、データ転送の利用料が発生します。移行前に月額費用だけでなく、開発・移行費、運用人員、障害対応、5年間の総コストと、将来別基盤へ移す難易度まで比較します。

まとめ

Tomcatのシステムは、Tomcatという実行基盤だけでなく、Javaアプリケーション、データベース、外部連携、ネットワーク、セキュリティ、監視、保守を組み合わせて成立します。費用の中心はTomcatのライセンスではなく、業務要件の整理、アプリ開発、既存資産の解析、移行、テスト、インフラ、運用です。

検討を始めるときは、現行構成図、TomcatとJDKのバージョン、WARやJAR、依存ライブラリ、業務フロー、データ項目、外部連携、非機能要件、移行と切り戻しの条件を整理します。そのうえで、継続利用、組み込みTomcat、クラウド・コンテナ、別基盤への段階移行を比較し、見積もりは工程と前提条件を分解して取得します。

特にTomcat 9から10.1・11への移行では、javax.*からjakarta.*への変更、JDK、依存ライブラリ、認証、セッション、設定、性能試験を一体で確認します。脆弱性情報の定期確認、不要な管理経路の閉鎖、ログ監視、バックアップ復元、パッチ適用、障害対応、成果物の引き継ぎまで含めて計画することが、長く安全に使えるシステムにつながります。