Tomcatのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Tomcatのシステム開発は、Tomcatを導入するだけでは完了せず、Java業務アプリケーションとデータベース、認証、ネットワーク、運用監視を一体で設計することが成功の条件です。

既存システムの保守期限や脆弱性、クラウド移行をきっかけにTomcatを調べている場合、先に現行資産と業務要件を整理し、要件整理から定着までを六つのフェーズに分けて進めると判断しやすくなります。この記事では、要件整理、技術選定、設計開発、テスト、稼働、定着の順に、実務で使える確認項目、2026年時点の移行論点、費用相場、見積書の比較方法を解説します。

▼全体ガイドの記事
・Tomcatのシステム開発の完全ガイド

Tomcatのシステムとは何ですか？全体像を理解する

Tomcatのシステムとは、Apache Tomcatを実行基盤としてJavaで作られた業務アプリケーションを動かすWebシステムです。Tomcat自体に販売管理や在庫管理の業務機能が入っているわけではないため、開発範囲をTomcat本体だけと考えないことが重要です。

TomcatはJava Servlet、Jakarta Servlet、JSPなどのWebアプリケーションを受け付け、処理を実行するサーブレットコンテナです。HTTPリクエストの受付、ServletやJSPの実行、セッション管理、JNDI経由のデータベース接続、認証連携、ログ出力、アプリケーションの配備などを担います。画面、業務ルール、帳票、バッチ、マスタ、外部APIはアプリケーション側で設計するため、見積もりではTomcatの台数よりも業務機能と連携数を先に数えます。

典型的な構成は、利用者のブラウザからWAFやロードバランサを経由し、Apache HTTP ServerまたはNginxなどのリバースプロキシ、Tomcat、RDBMS、ファイルストレージ、外部APIへ接続する多層構造です。Tomcatを前段のWebサーバーから分離すると、TLS終端、静的ファイル配信、負荷分散、アクセス制御を役割ごとに設計しやすくなります。小規模なら一台構成も可能ですが、停止が許されない業務では複数Tomcat、データベース冗長化、バックアップ、切り替え手順まで必要です。

新規開発では、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を対応系統として案内しています。Tomcat 9以前のJava EE系アプリを10以降へ移す場合は、javax.*からjakarta.*への変更、Servlet API、JSP、認証、JDBCドライバー、依存ライブラリを確認します。Tomcat 11はJava 17以降が必要です（出典: Apache Tomcat Migration Guide、Tomcat 11.0.x Migration Guide、2026年）。

Tomcatのシステム開発の進め方｜6フェーズで整理

Tomcatのシステム開発は、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズで区切ると、責任範囲と成果物を管理しやすくなります。特に既存環境では、いきなり新バージョンを本番へ入れるのではなく、現状調査と小さな検証を先に置くことが費用と障害リスクを抑えます。

最初に、Tomcat、JDK、OS、データベース、フレームワーク、WARやJAR、依存ライブラリ、設定ファイル、バッチ、外部連携、認証方式、ログ、監視、設計書、ソースコード、運用手順を一覧化します。既存担当者しか知らない手動作業や、夜間バッチの再実行方法も対象です。ソースコードがない場合でも、WARやJAR、実行ログ、サーバー設定から資産解析を始められます。

業務側とは、誰が、いつ、どのデータを使い、どの例外を処理するかを業務フローに落とします。同時接続数、ピーク時間、目標レスポンスタイム、稼働時間、障害時の復旧目標であるRTO、失ってよいデータの範囲であるRPO、ログ保管期間、個人情報の扱い、受入テストの担当者も決めます。要件整理の完了条件は、画面一覧だけでなく、非機能要件とユーザー側の準備物まで合意できていることです。

要件整理のチェックリスト：現行バージョン、依存ライブラリ、データ件数、外部連携、認証、権限、ピーク負荷、バックアップ、障害通知、受入担当、マスタ整備、切り戻し条件を一枚の確認表にまとめます。ここが空欄のまま選定へ進むと、後工程の追加見積もりになりやすいです。

選定では、既存Tomcatを継続するか、Tomcat 9から10.1または11へ移行するか、Spring Bootの組み込みTomcatへ寄せるか、コンテナ化するかを比較します。Tomcat 9から10以降への移行では名前空間変更による改修が発生する可能性が高いため、まず検証環境で代表的な画面、認証、帳票、バッチ、外部連携を動かします。JDKだけを先に更新して動かなくなる状況を避けるため、JDK、Tomcat、フレームワーク、アプリの組み合わせで評価します。

オンプレミス、AWS Elastic Beanstalkなどのマネージド基盤、ECSやKubernetesなどのコンテナ、既存サーバー継続の差は、初期費用だけでなく運用負担、障害対応、可用性、ロックイン、データ移行の難しさで比べます。AWS Elastic Beanstalkでは2026年の対応プラットフォームにCorretto 17・21・25とTomcat 9・10・11の組み合わせが掲載されていますが、既存アプリがそのまま動く意味ではありません。セッション、ファイル保存、ログ、ネットワーク、データベースの再設計を含めて判断します。

選定時の質問：対応できるTomcatとJDKの組み合わせ、javax.*依存の調査方法、性能試験の条件、脆弱性対応のSLA、監視設計、障害時の一次切り分け、設計書とソースコードの納品範囲を確認します。営業担当だけでなく、設計と運用を担当するエンジニアが説明できるかも判断材料です。

設計では、アプリケーション、リバースプロキシ、Tomcat、データベース、ストレージ、外部サービスの接続を構成図にします。Tomcatについては、コネクター、スレッド、コネクションプール、JNDI、セッション、アクセスログ、エラーログ、管理画面、AJP、TLS終端の責任者を決めます。複数台構成では、ロードバランサーのヘルスチェック、セッション共有またはステートレス化、デプロイ方法、片系停止時の挙動も設計します。

アプリ開発では、画面、API、業務ルール、権限、帳票、バッチ、データ移行プログラムを機能単位で分け、単体テストの観点まで先に作ります。移行案件では、古いJSPやStruts、独自認証、文字コード、日付処理、ファイルパス、外部APIのタイムアウトなど、実機でしか判明しない差分を洗い出します。仕様変更の受付期限、追加要望の扱い、障害と仕様変更の判定方法を決めておくと、費用の膨張を抑えられます。

設計開発の成果物：要件定義書、基本設計書、詳細設計書、画面・API仕様、データ定義、インフラ設計、セキュリティ設計、テスト計画、移行計画、運用手順、障害対応手順を納品対象にします。成果物の一覧とレビュー承認者を契約に入れ、納品後に自社で変更できる状態を確保します。

テストは単体、結合、総合、受入の順に進めます。Tomcat更新では、画面が表示されるだけで合格にせず、ログイン、権限、登録・更新・取消、帳票、ファイルアップロード、バッチ、メール、外部API、文字コード、タイムゾーン、セッション切れまで確認します。既存データを複製した検証環境で、実際のデータ量と本番に近いネットワーク条件を再現します。

非機能テストでは、ピーク時の同時接続数、目標レスポンスタイム、CPU・メモリ・スレッド・DB接続数、ログローテーション、バックアップ復元、障害通知、フェイルオーバー、脆弱性診断を確認します。個人情報を扱うシステムでは、認証強度、最小権限、TLS、WAF、管理画面の接続元制限、監査ログ、保存期間をテスト項目に含めます。IPAはApache Tomcatの製品・脆弱性情報を週1回程度更新しているため、テスト開始時だけでなくリリース直前にも確認します（出典: IPA「サーバ用オープンソースソフトウェアに関する製品情報およびセキュリティ情報」、2026年8月更新）。

合格基準のチェック：重大障害がゼロであること、未解決課題に回避策と期限があること、業務部門が受入結果を承認していること、バックアップから復元できること、切り戻し手順をリハーサル済みであることを確認します。テスト結果を口頭で済ませず、証跡として保存します。

稼働前には、移行対象データ、移行停止時間、最終バックアップ、データ照合方法、DNSやロードバランサーの切り替え、証明書、監視、連絡網を確定します。移行リハーサルでは、予定時間内にデータ抽出、変換、投入、件数照合、アプリ接続確認まで終わるかを測ります。業務部門には、切り替え後に最初に行う確認操作と、異常時に操作を止める基準を渡します。

本番切り替えは、変更を凍結した時間帯に実施し、作業者、承認者、監視担当、業務確認者を分けます。切り替え直後は、ログイン数、エラー率、レスポンス、DB接続、キュー、外部連携、バッチの状態を重点監視します。重大な不具合が起きた場合に旧環境へ戻す条件と判断者を事前に決めることが、現場の迷いを減らします。

稼働後の定着では、利用者教育と運用引き継ぎを別々に考えます。利用者には業務変更点、エラー時の一次対応、問い合わせ先を説明し、運用担当にはTomcatの起動停止、デプロイ、ログ確認、バックアップ復元、証明書更新、脆弱性パッチ、障害時のエスカレーションを実機で訓練します。手順書は作って終わりにせず、初回障害や月次作業の後に更新します。

保守契約では、監視対象、受付時間、復旧目標、脆弱性情報の確認頻度、OS・JDK・Tomcatの更新、依存ライブラリの棚卸し、軽微改修の範囲、月次報告、設計書更新の責任者を明記します。保守費用を開発費の年10〜20％程度で仮置きする場合も、何が含まれるかによって実額が変わるため、時間外対応や大規模バージョンアップを別項目に分けます。

定着の確認：担当者が一人休んでも運用できること、アラートを見て一次切り分けできること、復元テストを定期的に実施していること、脆弱性対応の記録が残ること、利用部門が改善要望を優先順位付きで提出できることを確認します。定着までを開発プロジェクトの成果に含めると、導入後の使われないシステム化を防げます。

Tomcatのシステム開発にかかる費用相場と内訳

Tomcat本体はOSSのため、原則としてライセンス購入費はかかりません。ただし、業務アプリの要件定義、既存コード解析、アプリ改修、サーバー構築、データベース、クラウド利用料、性能試験、脆弱性診断、移行、教育、保守には費用がかかります。以下はTomcat単体の統計ではなく、リサーチノートと公開サービス情報、一般的なJava業務Web開発の規模を組み合わせた目安です。

既存JavaやTomcatの資産解析・移行アセスメントは、35万円からが一つの公開事例です。NECの「Javaアプリケーション モダナイズアセスメントサービス」は、2026年3月改定後の基本料金を35万円からとし、WAR、JAR、EARなどの解析に対応しています（出典: NEC公開サービス情報、2026年）。ただし、アプリケーション数、ソースコードの有無、追加の実機検証によって費用は変わるため、35万円で移行作業全体が完了する意味ではありません。

小規模な脆弱性対応、JDKやTomcat更新、設定変更であれば、影響調査、依存ライブラリ更新、回帰テスト、リリースを含めて50万〜200万円程度を仮置きします。社内向けのCRUD、申請、台帳システムで画面数が10〜30程度なら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のJ-STAGE調達では、Spring FrameworkとApache Struts、Apache Tomcatを更新し、Tomcat 11上で正常動作するための環境設定、プログラム改修、動作確認テストを一体で求めています。この事例からも、Tomcatのバージョン変更だけを単独作業として見積もらず、フレームワーク、アプリ、設定、テストをまとめて評価する必要があると分かります（出典: 科学技術振興機構「令和7年度 J-STAGEシステムSpring FrameworkのEOL対応業務」、2026年）。

Tomcatのシステム開発でよくある質問（FAQ）

ここでは、Tomcatのシステム開発を検討する企業から寄せられやすい質問に回答します。費用、バージョンアップ、クラウド化の判断を先に整理すると、開発会社への相談内容も具体的になります。

TomcatはOSSのため、原則としてライセンス購入費は不要ですが、業務アプリの開発、構築、テスト、データ移行、セキュリティ、監視、保守には人件費と環境費がかかります。無料なのは実行基盤のライセンス部分であり、要件整理や業務機能まで無料になるわけではありません。見積書ではライセンス費、開発費、インフラ費、保守費を分けて確認します。

技術的には可能な場合がありますが、既存アプリの互換性を調査せずに一度で切り替えるのは危険です。Tomcat 9以前のJava EE系アプリを10以降へ移すと、javax.*からjakarta.*への変更や、Spring、Struts、JSP、認証、JDBCドライバーの改修が発生することがあります。まず現行資産を解析し、代表機能を新環境で動かす検証を行い、段階移行か一括移行かを決めます。

クラウドが常に最適とは限りません。アクセス変動、自動復旧、複数拠点、運用担当者の不足が課題なら、マネージド基盤やコンテナで負担を減らせる可能性があります。一方で、セッション、ファイル、ネットワーク、データベース、ログ、監視を再設計する必要があり、移行費用と月額費用、障害時の責任分界、契約終了時のデータ移行まで含めて5年程度のTCOで判断します。

TomcatやJavaの開発経験だけでなく、既存資産の解析、Tomcat 9・10.1・11の移行、JDK更新、性能試験、脆弱性対応、監視、データ移行、受入、保守まで担当できるかを確認します。見積書の一式表記を避け、成果物、前提、対象外、追加条件、切り戻し、納品後の保守SLAを質問します。実際に設計と運用を担当するエンジニアが、リスクと対策を説明できる会社が望ましいです。

まとめ：Tomcatのシステム開発は要件と運用まで一体で進めます

Tomcatのシステム開発では、Tomcatを業務機能と混同せず、Javaアプリケーション、データベース、ネットワーク、認証、監視、データ移行を含む一つの業務システムとして考えます。進め方は、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズに分け、各フェーズの完了条件と成果物を確認します。

費用はTomcatのライセンスではなく、現行資産の解析、アプリ改修、業務機能、外部連携、非機能要件、テスト、移行、クラウド、保守で決まります。移行前はTomcat・JDK・フレームワークの組み合わせを調べ、javax.*依存、セッション、認証、データ、ログ、切り戻しを検証します。見積もりでは金額の安さだけでなく、作業範囲、追加条件、納品物、運用SLA、ユーザー側の役割まで比較します。

まずは現行構成図、資産一覧、業務フロー、データ項目、非機能要件、移行・切り戻し計画、保守確認表を作成します。その資料をもとに、Tomcatの構築だけでなく、業務の定着まで伴走できる開発会社へ相談すると、公開後の障害や属人化を抑えやすくなります。

▼全体ガイドの記事
・Tomcatのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。