Tomcatのシステム開発は、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズに分けて進めます。現行資産と業務要件を整理し、互換性を検証してから設計・移行へ進むと、障害や属人化を抑えやすくなります。
▼全体ガイドの記事
・Tomcatのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Tomcatのシステムの全体像
Tomcatのシステムは、Apache Tomcat上でJava製の業務アプリケーションを動かすWebシステムです。一方で、Tomcat自体には販売管理や在庫管理の機能がありません。
Tomcatの役割：業務機能を動かす実行基盤
TomcatはJava Servlet、Jakarta Servlet、JSPなどを受け付け、処理を実行するサーブレットコンテナです。
- リクエスト処理：HTTPの受け付け、ServletやJSPの実行、セッション管理を受け持ちます。
- 接続・認証：JNDI経由のDB接続と認証連携
- 運用：ログ出力とアプリケーションの配備
画面や業務ルール、帳票は、アプリ側で設計します。バッチやマスタ、外部APIも、アプリ側で設計する対象です。そのため、見積もりではTomcatの台数より、業務機能と連携数を先に数えます。
典型的な構成は、ブラウザからWAFやロードバランサー、リバースプロキシを経てTomcatへつながる多層構造です。Tomcatの先には、RDBMSやストレージ、外部APIが続きます。
前段にApache HTTP ServerやNginxを置くと、TLS終端や静的配信、負荷分散、アクセス制御を、Tomcatとは分けて設計できます。
小規模であれば1台構成も可能です。ただし、停止できない業務では、Tomcatの複数台化やDBの冗長化が必要になり、バックアップと切り替え手順も欠かせません。
新規開発と既存移行で異なる判断の観点
新規開発と既存移行では前提が違うため、比べる項目も変わります。既存移行では、更新範囲と段階的な移行方法が比べる中心になります。
- 新規開発：実行・配備方式の比較（Spring Boot組み込みTomcat、外部TomcatへのWAR配備、Jakarta EE基盤、コンテナ）
- 既存移行：更新範囲と進め方（Tomcat・JDKの段階更新、Tomcat 10.1・11への改修、コンテナ化、API分割）
- パッケージ：要件を満たせるなら、標準機能、追加開発、API連携、運用費の総額で判断
2026年時点のApache公式移行ガイドは、Tomcat 9.0.x、10.1.x、11.0.xを対応系統として案内しています。
特に、Java EE系のTomcat 9以前のアプリを10以降へ移す場合は、javax.*からjakarta.*への変更を確認します。さらに、Servlet APIやJSP、認証、JDBCドライバー、依存ライブラリも確認の対象になります。
Tomcat 11にはJava 17以降が必要です（出典: Apache Tomcat Migration Guide、Tomcat 11.0.x Migration Guide、2026年）。
Tomcatのシステム開発の進め方｜6フェーズの流れ
開発は、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズに分けると、各段階の責任範囲と成果物を管理できます。
既存環境では、現状調査と小さな検証を先に行うことで、費用と障害リスクを抑えられます。
フェーズ1：要件整理による現状とゴールの共有
まず、現行資産と運用を一覧にします。対象には、Tomcat、JDK、OS、DBなどの基盤に加えて、WAR・JAR、依存ライブラリ、設定ファイルも含めます。
- アプリ資産：バッチ、外部連携、認証方式、設計書、ソースコードの確認
- 運用資産：ログ、監視、運用手順、手動作業、夜間バッチの再実行方法の洗い出し
- 解析資料：ソースがなくても、WAR・JAR、実行ログ、サーバー設定から調査できます。
業務側の担当者と、誰がいつどのデータを使い、どの例外を処理するかを、業務フローに書き出します。
同時接続数とピーク時間、目標レスポンスタイムは、あらかじめ決めておきます。稼働時間も同じ段階で定め、障害からの復旧目標（RTO）と、許容するデータ損失の範囲（RPO）も合わせて決めます。
ログの保管期間や個人情報の扱い、受入テストの担当も、この段階で決めます。非機能要件とユーザー側の準備物まで合意できれば、要件整理は完了です。
現行バージョン、依存ライブラリ、データ件数は、確認表にまとめます。外部連携と認証、権限、ピーク負荷も、同じ表に書き込みます。
バックアップと障害通知、受入担当、切り戻し条件も、同じ表で確認します。空欄のまま選定へ進むと、追加見積もりになりやすくなります。
フェーズ2：技術と移行方針の選定
選択肢は、既存Tomcatの継続、Tomcat 9から10.1・11への移行、Spring Boot組み込みTomcat、コンテナ化です。これらを比べて方針を決めます。
Tomcat 9から10以降では、名前空間の変更による改修が発生する可能性が高いです。そのため、まず検証環境で代表機能を動かします。
- 機能検証：画面、認証、帳票、バッチ、外部連携の動作確認
- 互換性評価：JDK、Tomcat、フレームワーク、アプリの組み合わせごとに見る
- 基盤比較：オンプレミス、マネージド基盤、ECSやKubernetesなどのコンテナ、既存サーバーを並べて見る
JDKだけを先に更新すると動かなくなる恐れがあるため、版の組み合わせはまとめて検証します。
基盤は初期費用だけで選ぶと偏るため、運用負担や障害対応、可用性で比べます。ロックインやデータ移行の難しさも、あわせて見ます。
たとえば、AWS Elastic Beanstalkの2026年対応表には、Corretto 17・21・25とTomcat 9・10・11の組み合わせがあります。
対応表に載っていても、既存アプリがそのまま動くとは限りません。そのため、セッションやファイル保存、ログ、DBの扱いを含めて、再設計の要否から判断します。
選定の段階では、TomcatやJDKの対応範囲、javax.*の調査、性能試験の条件を確認します。脆弱性対応のSLAと監視設計も、このときに見ておきます。
開発会社には、障害時の一次切り分けや設計書・ソースコードの納品範囲も尋ねます。設計と運用を担う技術者が説明できるかどうかも、判断材料になります。
フェーズ3：設計と開発での担当範囲の確定
まず、アプリとTomcat、DB、外部サービスのつながりを構成図にまとめます。リバースプロキシやストレージも、同じ図に描いておきます。
- Tomcat設定：コネクター、スレッド、コネクションプール、JNDIの決定
- 運用設定：セッション、アクセス・エラーログ、管理画面、AJP、TLS終端の扱い
- 複数台構成：ヘルスチェック、セッション共有かステートレス化、デプロイ方法を決めます。
複数台構成では、片系が停止したときの挙動も設計します。また、各設定の担当者も明確にします。
アプリは、画面やAPI、業務ルールを分けて設計し、単体テストの観点も作ります。権限、帳票、バッチ、データ移行の部分も、設計の単位として分けます。
特に移行案件では、JSP・Struts、独自認証、文字コードの扱いを実機で調べます。日付処理やファイルパス、外部APIのタイムアウトも、実機で確かめます。
仕様変更の受付期限、追加要望の扱い、障害と仕様変更の判定方法を決めておくと、費用の膨らみを抑えられます。
納品対象には、要件定義書や基本・詳細設計書、画面・API仕様を含めます。加えて、データ定義とインフラ・セキュリティ設計も対象です。
テスト計画、移行計画、運用・障害対応の手順も、納品に入ります。さらに、成果物とレビュー承認者を契約に入れておくと、自社で変更できる状態を保てます。
フェーズ4：テストでの互換性と業務継続性の確認
テストは、単体、結合、総合、受入の順に進めます。合格の判断は、画面の表示ではなく業務機能の確認で行います。
- 業務操作：ログイン、権限、登録・更新・取消、帳票の確認
- 連携処理：アップロード、バッチ、メール、外部APIのつながった動作
- 実行条件：文字コード、タイムゾーン、セッション切れの扱い
特に、既存データを複製した検証環境では、実データ量と本番に近いネットワーク条件を再現します。
非機能テストでは、ピーク時の同時接続数と目標レスポンスタイムを確かめます。そのうえで、CPUやメモリ、スレッド、DB接続数の使用状況も測ります。
ログのローテーション、バックアップ復元、障害通知、フェイルオーバー、脆弱性診断も試します。
個人情報を扱う場合は、認証の強度や最小権限、TLS、WAFを確認します。管理画面の接続元制限や監査ログ、保存期間も、あわせて確認します。
IPAのTomcat製品・脆弱性情報は週1回程度更新されるため、テスト開始時とリリース直前に確認します（出典: IPA「サーバ用オープンソースソフトウェアに関する製品情報およびセキュリティ情報」、2026年8月更新）。
合格の判断では、重大障害がゼロか、未解決課題の回避策と期限が決まっているかを確認します。さらに、業務部門の受入承認とバックアップ復元も確認します。
切り戻し手順をリハーサルし、テスト結果を証跡として保存します。
フェーズ5：稼働での切り替えと切り戻しの管理
稼働前に、移行対象と停止時間、最終バックアップ、データ照合の方法を決めておきます。DNSやロードバランサーの切り替えも、あわせて準備します。
- 切替準備：証明書、監視、連絡網の確定
- 移行リハーサル：抽出、変換、投入、件数照合、接続確認にかかる所要時間の計測
- 業務確認：切替後の操作手順と、異常時に操作を止める基準を現場へ渡す
本番切替は、変更凍結の時間に行います。作業者、承認者、監視担当、業務確認者は、役割を分けます。
切り替え直後は、ログイン数やエラー率、レスポンスを重点的に監視します。DB接続やキュー、外部連携、バッチの状態も見ます。
重大障害のときに旧環境へ戻す条件と判断者を先に決めておくと、現場が迷う時間を減らせます。
フェーズ6：定着での運用の属人化防止
稼働後は、利用者教育と運用引き継ぎを分けて進めます。利用者には、業務の変更点、エラー時の一次対応、問い合わせ先を伝えます。
- 基本運用：Tomcatの起動・停止、デプロイ、ログ確認の訓練
- 復旧対応：バックアップ復元、証明書更新、脆弱性パッチを訓練します。
- 連絡手順：障害時のエスカレーションの実機確認
手順書は作成後も、初回障害や月次作業を終えるたびに更新します。
保守契約には、監視対象と受付時間、復旧目標を明記します。脆弱性確認の頻度やOS・JDK・Tomcatの更新も、契約に書き込みます。
依存ライブラリの棚卸しや軽微改修、月次報告、設計書の更新について、責任者を決めます。
保守費を開発費の年10〜20％程度で仮置きする場合でも、どこまでを含むかで実額は変わります。
時間外対応や大規模なメジャー更新は、別項目に分けておきます。担当者がいないときの運用や一次切り分け、復元テストも確認します。
脆弱性対応の記録を残すことや、利用部門が優先順位をつけて改善要望を出せることも確認します。定着まで成果に含めると、使われないシステム化を防げます。
Tomcatのシステム開発にかかる費用相場と内訳
Tomcat本体はOSSのため、原則としてライセンス購入費はかかりません。一方で、業務アプリの要件定義や改修、構築には別途費用が必要です。DBやクラウドの費用も、別に見込みます。
性能試験や脆弱性診断、移行、教育、保守にも費用がかかります。ただし、以下の金額はTomcat単体の統計ではなく、リサーチノートや公開サービス情報、一般的なJava業務Web開発の規模を合わせた目安です。
作業規模別の費用レンジ
既存Java・Tomcat資産の解析と移行アセスメントは、35万円からの公開事例があります。
たとえば、NECのサービスは2026年3月改定後、基本料金35万円からで、WAR、JAR、EARなどを解析します（出典: NEC公開サービス情報、2026年）。
ただし、アプリ数やソースの有無、実機検証によって費用は変わります。35万円は、移行作業全体の金額ではありません。
- 小規模改修：脆弱性対応、JDK・Tomcat更新、設定変更の場合は50万〜200万円程度を仮置きします。
- 社内システム：画面10〜30程度のCRUD、申請、台帳で、500万〜1,500万円程度が目安です。
- 中規模業務：基幹連携やデータ移行を含む受発注・顧客・在庫で、1,500万〜5,000万円程度です。
小規模改修の目安には、影響調査や依存ライブラリ更新、回帰テスト、リリースが含まれます。
各金額は案件条件で変わる推定の幅で、特定の金額を保証するものではありません。さらに、24時間運用や複数拠点、冗長化、監査、段階移行を伴う大規模基幹は、5,000万円から数億円となる場合があります。
期間は12〜24か月以上となる場合もあります。工数は、業務ルールや連携、データ移行によって増えます。可用性や性能、セキュリティの要件も、工数を押し上げます。
教育や並行稼働も、工数の要因になります。一方で、Tomcatの台数を増やしただけで高額になるとは限りません。
クラウド費用と保守費用の切り分け
クラウドのインフラ費は、開発費と分けて考えます。開発・検証・本番を合わせた月額の仮置きは、規模によって異なります。
- 小規模：月3万〜30万円程度です。
- 中規模：月30万〜150万円程度です。
- 大規模：高可用性や大量ログがあると、月100万円超の仮置きもあります。
月額は、アクセス数やDB性能、バックアップ世代で変わります。WAFや監視、ログ保管、データ転送も、費用を動かす要因です。
月額だけでなく、3〜5年の総保有コストで比較します。
保守費は、開発費の年10〜20％程度を仮置きできます。たとえば、開発費3,000万円なら年300万〜600万円程度です。
保守の範囲は、監視や障害対応、軽微改修を含めるかどうかで変わります。保守費を比べるときは、このほかに次の作業も見ておきます。
- 脆弱性対応：保守の範囲に含めるかどうか
- OS・JDK・Tomcat更新：基盤の版上げを保守に含めるかどうか
24時間365日の有人監視や時間外復旧、性能改善、大規模更新を含む場合は、契約の前提を分けて記載します。
Tomcatのシステム開発で見積もりを取る際のポイント
見積書は、合計金額だけでなく、含まれるフェーズと成果物をそろえて見ます。
「システム開発一式」では、要件整理やTomcat構築、アプリ改修、テストの扱いが分かりません。移行、教育、保守の抜けも、判断できません。
各社へ同じRFPか確認表を渡し、前提条件と対象外、追加料金の条件を並べます。
見積前の現行資産と業務範囲の資料化
見積依頼には、現行構成図と画面一覧を添えます。加えて、Tomcat・JDK・OS・DBの版と、WAR・JAR、依存ライブラリも書き添えます。
- 規模・機能：利用者数、データ件数、外部連携、帳票、バッチの記載
- 運用・資産：認証、ログ、障害履歴、設計書・ソースの有無を記します。
- 移行条件：脆弱性や保守期限、停止時間、残す機能と廃止する機能
非機能要件は、「速く」「止まらない」といった表現から、ピーク時同時接続数や95パーセンタイルの応答時間へ置き換えて書きます。
月間稼働率やRTO・RPO、ログ保管期間、バックアップ世代、復旧訓練の頻度も、数値で示します。
個人情報や決済情報を扱う場合は、WAFやTLS、二要素認証、アクセス制御、監査ログを要求します。
カード情報の非保持化と脆弱性診断の範囲も定めます。資料には、利用者や画面、データ件数、連携を明記します。
停止できる時間や受入担当、納品後の保守担当も記載します。未確定の項目は伏せずに、調査フェーズとして見積もってもらいます。
複数社の同条件での比較と、技術者の説明の確認
二社以上、できれば三社程度へ依頼します。見積もりは、要件整理や移行調査から保守までを、工程ごとに分けて出してもらいます。
- 価格の前提：現行資産を見ずに固定額を出していないかの確認
- 作業範囲：テスト工数の削りすぎや、移行・切り戻しの抜けの有無
- 技術体制：類似案件の規模、当時の版、担当工程、現在の保守体制を尋ねる
Tomcat 9・10.1・11、Java 17・21・25、SpringやJakartaの移行実績も、具体的に尋ねます。
性能試験やWAF・TLS、監視、障害対応について、どこまでを担当するかも確認します。データ移行と運用引き継ぎも、同じ確認項目です。
製品名だけを並べて説明し、切り戻しやユーザー側の作業に触れない場合は、注意が必要です。
契約による追加費用とベンダーロックインの防止
契約では、追加費用が発生する条件と、保守会社が変わっても運用を引き継げる条件を明確にします。
- 追加費用の要因（仕様）：画面追加、マスタ未整備、例外処理、旧ライブラリの互換性、データ不整合が挙げられます。
- 追加費用の要因（連携・検証）：想定外の連携、性能不足、受入テストの遅れも挙げられます。
- 契約条件：変更単価、再見積もりの取り決め、ユーザー作業、データ整備の責任、検収基準を明記します。
- 引き継ぎ資料：設計書、ソース、ビルド手順、設定値、依存ライブラリ、データ定義、監視設定、バックアップ手順、障害履歴を納品物に含めます。
- クラウドの出口：データ出力、別環境での復元、契約終了時の返却形式の確認
引き継ぎ資料がそろっていれば、保守会社が変わっても運用を続けられ、将来の競争力にもつながります。
2026年公開のJST調達では、Spring Framework、Apache Struts、Apache Tomcatを更新対象としています。加えて、Tomcat 11での動作に必要な環境設定も求めています。
プログラム改修と動作確認テストも、一体で求められています。版変更だけでなく、フレームワーク、アプリ、設定、テストをまとめて見積もります（出典: 科学技術振興機構「令和7年度 J-STAGEシステムSpring FrameworkのEOL対応業務」、2026年）。
Tomcatのシステム開発でよくある質問（FAQ）
Tomcat開発を検討する企業から寄せられやすい質問に、費用や更新、クラウド化の観点から答えます。
Tomcatは無料なのに、なぜシステム開発費がかかるのですか？
TomcatはOSSのため、原則としてライセンス購入費は不要です。一方で、アプリ開発や構築、テスト、移行には費用がかかります。
セキュリティや監視、保守にも、人件費と環境費が必要です。つまり、無料なのは基盤のライセンス部分だけで、要件整理や業務機能は含まれません。
見積書では、ライセンス、開発、インフラ、保守の費用を分けて確認します。
Tomcat 9から11へ一度にバージョンアップできますか？
技術的に可能な場合はありますが、互換性を調べず一度に切り替えるのは危険です。
- 名前空間：Java EE系アプリをTomcat 9以前から10以降へ移すと、
javax.*からjakarta.*への変更が生じることがあります。 - 改修範囲：Spring、Struts、JSP、認証、JDBCドライバーも対象になり得ます。
- 移行方法：資産を解析して代表機能を新環境で検証し、その結果から段階移行か一括移行かを決めます。
Tomcatのシステムはクラウドへ移行したほうがよいですか？
クラウドが常に最適とは限りません。アクセス変動や自動復旧、複数拠点、運用担当の不足が課題なら、負担を減らせる可能性があります。
クラウド化では、セッションやファイル、ネットワーク、DB、ログ、監視の再設計が必要になります。
移行費や月額費、障害時の責任分界、終了時のデータ移行を含めて、5年程度のTCO（総所有コスト）で判断します。
Tomcatに強い開発会社へ何を確認すればよいですか？
開発会社を選ぶときは、技術実績に加えて、運用範囲や契約後の引き継ぎまで確認します。
- 技術経験：Java開発、資産解析、Tomcat 9・10.1・11の移行、JDK更新、性能試験の実績
- 運用範囲：脆弱性対応、監視、データ移行、受入、保守まで担当できるか尋ねます。
- 契約条件：成果物、前提、対象外、追加費用の扱い、切り戻し、納品後の保守SLAの確認
- 担当者の説明：設計・運用担当の技術者が、リスクと対策を言葉で示せるかどうか
まとめ：Tomcatのシステム開発を要件と運用まで一体で進める考え方
Tomcat開発では、TomcatとJavaアプリの業務機能を分けて捉えつつ、DBやネットワーク、認証、監視、データ移行を一体で考えます。
進め方は、要件整理から定着までの6フェーズです。各段階で、完了条件と成果物を確認します。
費用は、ライセンスよりも資産解析や改修、業務機能、連携で決まります。加えて、非機能要件やテスト、移行、クラウド、保守も費用を左右します。
移行の前には、Tomcat・JDK・フレームワークの組み合わせを調べます。そのうえで、javax.*への依存やセッション、認証、データ、ログ、切り戻しを検証します。
見積もりでは、金額だけでなく範囲や追加条件、納品物を比べます。運用SLAとユーザー側の役割も、比べる対象に入ります。
現行構成図と資産一覧、業務フロー、データ項目を用意します。非機能要件や移行・切り戻し計画、保守確認表も、あわせて用意します。
その資料をもとに、構築から業務定着まで支援できる開発会社へ相談します。そうすることで、公開後の障害や属人化を抑えやすくなります。
▼全体ガイドの記事
・Tomcatのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。