Tomcatのシステム開発の発注/外注/依頼/委託方法について

Tomcatのシステムの発注は、現状調査、業務と非機能の要件整理、契約と見積もりの比較を順に進めるのが全体の流れです。この順で進めると、安全な開発や移行、その後の運用につながります。

全体像は、Tomcatのシステム開発の完全ガイドでも確認できます。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Tomcatのシステム発注の全体像

「Tomcatのシステム」は、Tomcat単体の商品ではありません。通常は、Tomcat上でWebアプリケーションを動かし、データベースや外部サービスと連携させる形になります。

Tomcatの設定だけを外注するのか、業務アプリの開発や改修まで委託するのかで、必要な会社も費用も大きく変わります。

Tomcatの役割は実行基盤

Apache Tomcatは、Java ServletやJakarta Servlet、JSPなどのWebアプリケーションを動かす、サーブレットコンテナです。

• 業務機能：販売管理、在庫管理、申請、顧客管理は、Tomcat上で動くJavaアプリとして実装します。
• 見積依頼：画面、業務ルール、データ、連携先、利用者、運用時間を、見積もりの前提として伝えます。
• 典型構成：ブラウザからWAFやロードバランサ、Apache HTTP ServerまたはNginxを経て、Tomcatへ接続する形になります。

典型的な構成では、TomcatにRDBMSやファイルストレージ、外部APIを接続します。また、Tomcatを複数台置く場合は、負荷分散、セッション共有かステートレス化、障害時の切り替えも、発注範囲に含まれることがあります。

発注範囲の開発・基盤・運用への分け方

委託したい業務は、アプリケーションとインフラを中心に、データや品質保証、運用保守に分けて整理します。

• 既存Tomcatの更新：WARやJARの解析、JDKと依存ライブラリの確認、設定の再作成、回帰テスト、切り戻しを含めます。
• 新規開発：画面やAPIに加えて、権限、ログ、バックアップ、監視、リリース手順も対象になります。
• 社内に業務知識と技術者がいる場合：アプリ開発だけを委託できます。
• 担当者不足や資産のブラックボックス化が課題の場合：現状調査から運用引き継ぎまでを委託します。

依頼範囲が曖昧なまま相見積もりを取ると、各社が前提にする条件が食い違うため、金額だけでは比べられません。

Tomcatのシステムの発注形態の選び方

発注側は、完成させたい範囲と社内の体制に合わせて、個別開発、既存システムの移行、保守運用のどこを外注するかを決めます。新規開発なら要件定義からリリースまでを委託し、既存環境ならアセスメントと小規模な検証から始めると安全です。

新規開発の一括委託と段階委託

業務フローや画面要件が固まっていれば、要件定義からリリースまでを一つのプロジェクトとして発注できます。

• 一括委託：窓口が一本化されて管理しやすい反面、仕様が固まっていないと、変更のたびに納期と費用の調整が増えます。
• 段階委託：複雑な業務や既存資産がある場合は、現状分析と要件定義の成果をもとに、本開発を再見積もりします。

たとえば、NECのJavaアプリケーション・モダナイズアセスメントは、Tomcatを対象に含みます。2026年3月改定の基本料金は1システム35万円からです（出典: NEC WebOTX、2026年）。ただし、これは本開発全体の相場ではなく、既存資産を解析して移行の判断をする個別サービスの目安です。

移行・更新・保守の発注単位

Tomcat 9から10.1や11へ移す案件で、Tomcatの入れ替えだけを依頼すると、作業漏れが起こります。なお、Tomcat 10以降は、Java EE系のjavax.*からJakarta EE系のjakarta.*へ変わるため、アプリに影響する場合があります。

• 対応バージョン：サポート対象の9.0.x、10.1.x、11.0.xは、Java 17で動作します。
• 設定変更：メジャー更新では、旧設定をコピーせず、新しい既定設定から調整します。
• アプリ互換性：名前空間の変更が、既存アプリに与える影響。
• 移行確認：JDK、Servlet API、JSP、SpringやStruts、JDBC、認証、セッション、文字コード、外部連携を確認します。

リリース後も、脆弱性パッチやログ監視、証明書更新、障害対応が必要なら、開発契約とは別に保守範囲とSLAを定めます。

移行は、Apacheの公式移行ガイドが示すJava 17の条件と設定変更の方針に沿って進めます（出典: Apache Tomcat Migration Guide、2026年）。

RFPと要件の整理と外注先への伝え方

RFPは外注先に提案を依頼するための文書です。最初から立派な仕様書を書く必要はありません。

目的、対象業務、現状の課題をまとめ、希望時期と予算の考え方、提案範囲も書いておくと、見積もりを比べやすくなります。

既存システムの場合は、TomcatとJDKのバージョンを中心に、OSやDB、フレームワーク、WARやJARの数を書きます。外部連携やバッチ、認証方式、障害履歴も、可能な範囲で書き添えます。

業務要件の書き方

入力画面の数だけでなく、誰がどのデータを、どの順で承認し、完了後に何を判断するかまで書くと、設計の前提を共有できます。

• 業務フロー：利用者、開始条件、例外処理、承認権限を、流れに沿って洗い出します。
• 必要な機能：帳票、通知、検索条件、データ保持期間を書き出します。
• 現場の作業：Excelやメールでの作業を、業務フローに含めるかどうかを決めます。

決め切れない要件は、未確定事項としてRFPに残します。たとえば「将来はスマートフォン対応を検討する」と書いておくと、外注先から確認事項や選択肢を得られます。

「既存データは5年分を移行する可能性がある」といった条件も書き添え、決定期限と判断者を定めます。未確定事項を伏せたままにすると、後から仕様変更になりやすいためです。

非機能要件の数値と運用条件

Tomcatのシステムでは、非機能要件も費用を左右します。そのため、接続数や目標応答時間、稼働時間、RTOなどの復旧目標を、数値で定めておきます。

個人情報や決済情報を扱うなら、安全管理の対策も要件に含めます。

• 性能・稼働：接続数、ピーク時のリクエスト数、目標応答時間、稼働時間を、測れる形で定めます。
• 復旧・保管：RTO、RPO、バックアップ世代数、ログ保管期間、監視時間帯を決めます。
• 安全管理：WAF、TLS、二要素認証、管理画面の接続制限、最小権限、監査ログを、要件の中に入れます。
• 運用対応：バックアップ暗号化、脆弱性診断、インシデント時の連絡先を取り決めます。

「速く」のままでは測定できないため、通常時の95パーセンタイルで3秒以内など、測定できる条件で定めます。たとえば、平日9時から18時は30分以内に一次対応するといった運用条件も書き添えます。

個人情報保護委員会の指針は、個人データを扱う情報システムの技術的安全管理措置を示しています（出典: 個人情報保護委員会「通則編」、2025年施行版）。

法令対応には、Tomcatの設定に加えて、組織・人的・物理的な対策と責任分界も必要です。

Tomcatのシステム開発の契約形態

契約形態によって、金額の決め方や成果物、責任範囲、検収基準が変わります。そのため、契約名だけでなく、業務内容と成果物を確かめます。

• 請負：要件が固まった開発を、成果物と検収条件に基づいて進めます。
• 準委任：調査や専門人材による支援を、一定期間行います。
• 保守契約：リリース後の監視や障害対応を、継続して担います。

請負契約の成果物と検収

請負契約は、合意した成果物を完成させて、発注側が検収する進め方に向いています。たとえば、基本設計書、詳細設計書、ソースコードなどを納品物として一覧化します。

• 納品物：設計書、ソースコード、テスト仕様書と結果、環境定義書、運用手順書、移行計画書を一覧にまとめます。
• 検収条件：主要業務の受入テスト通過や重大不具合の解消など、確認できる条件にしておきます。
• 発注側の協力：データ提供、レビュー、受入テスト、アカウント発行、既存ベンダー調整を、責任事項として明記します。
• 仕様変更：申請、再見積もり、納期への影響、緊急時の承認者を決めます。

検収は納品日だけで判断せず、あらかじめ定めた確認可能な基準で行います。発注側の協力不足も進行に響くため、契約書で責任範囲を確かめます。

準委任契約の調査・伴走・専門支援での使いどころ

準委任契約は、一定期間の業務支援や技術者の稼働に対して、報酬を支払う形です。開始時点で成果物や作業量を決めきれない業務に適します。ただし、成果物が不要になるわけではありません。

• 対象業務：Tomcat調査、RFP作成支援、移行方針の検討、設計レビュー、開発チームの補完に適します。
• 残す記録：月次報告、課題一覧、調査レポート、設計レビュー記録などを定めます。

保守契約では、監視対象や受付時間、一次回答と復旧の目標、障害の重要度を具体的に決めます。さらに、パッチの方針や軽微改修の月間枠、対象外の作業も定めます。

Apache Tomcatのセキュリティページには、2026年にも複数の脆弱性修正が掲載されています（出典: Apache Tomcat 10 Security、2026年）。そのため、脆弱性の情報収集や検証、適用、報告を誰が担うかを、契約前に確かめます。

Tomcatのシステム発注費用相場と内訳

TomcatはOSSなので、本体のライセンス購入費は原則として不要です。一方で、開発会社への支払いは、設計・実装や解析、構築、テストといった開発の対価です。そこに、移行や監視、保守の対価が加わります。

Tomcatが無料であることと、システム開発の費用が安いことは、別の話です。

既存Tomcatの解析・更新の費用目安

調査や移行アセスメントの費用は、対象アプリの数や、ソースや設計書の有無、依存ライブラリの数で変わります。現行版やテスト環境も、金額に響きます。

• アセスメント：NECの公開価格は、2026年3月改定で35万円からです。
• 更新・改修込み：50万円から200万円程度を仮置きし、調査後に再見積もりします。
• 調査に時間がかかる条件：古いStrutsやJSP、独自認証、手作業の設定、テストデータ不足です。

これは、一般的な案件条件に基づく推定で、固定価格ではありません。調査結果を踏まえて、あらためて再見積もりします。

調査を省いて更新だけを依頼すると、リリース直前に互換性の問題が見つかり、追加の改修費が発生する可能性があります。そこで、アセスメント費用は、失敗を防ぐための初期投資として比較します。

新規開発の規模別の費用幅（500万円から数億円まで）

社内向けのCRUD、申請、台帳システムで、10から30画面、RDB、権限、帳票、基本的な外部連携を想定します。初期検討のレンジは、500万円から1,500万円程度です。

• 中規模：受発注、顧客、在庫など複数部門で使い、基幹連携、データ移行、性能試験を含む場合は、1,500万円から5,000万円程度が目安です。
• 大規模：複数拠点、24時間運用、冗長化、監査、段階移行、教育を含むと、5,000万円から数億円になることがあります。

これらは、Tomcat単体の統計ではありません。一般的なJava業務Webシステムの規模条件から置いた、推定のレンジです。

クラウドの初期構築は、コンテナ化やネットワーク、WAF、CI/CD、監視、データ移行の内容によって、300万円から2,000万円程度を別枠で検討します。

費用は、Tomcatの台数よりも、画面数や業務ルール、連携、データ、非機能要件で決まります。

クラウド費用と保守費用

クラウド利用料は、サーバーやDB、ストレージ、ログなどの利用内容で変わります。また、バックアップやWAF、監視、データ転送も、金額に影響します。

• クラウド費：3環境で小規模は月3万円から30万円、中規模は月30万円から150万円程度が仮置きの目安です。
• 保守費：開発費の年10から20パーセント程度を仮置きするケースがあります。
• 保守範囲：監視、24時間365日の障害対応、軽微改修、脆弱性対応、OS・JDK・Tomcat更新の有無で変わります。

アクセス数や可用性によって、金額は大きく変動します。

AWS Elastic Beanstalkでは2026年もTomcatを含むAmazon Linux 2023の更新が続いています（出典: AWS Elastic Beanstalk Release Notes、2026年）。マネージド基盤でも、ランタイム更新と互換性試験は必要です。

たとえば開発費が3,000万円の場合、保守費は年300万円から600万円程度です。

見積書では、月額だけでなく、対象時間や対応レベル、作業回数、含まれない費用も確かめます。

委託先の選定と見積比較で確認するポイント

委託先は、Java開発だけでなく、Tomcat構築や性能試験、データ移行を任せられるかで選びます。さらに、脆弱性対応やログ監視、障害対応についても、同じように確かめます。

営業担当だけで決めず、実際に担当するエンジニアと現行構成やリスクを話し合い、質問への回答が具体的かどうかを確かめます。

技術実績の確認範囲

Javaの実績に加えて、Tomcat 9、10.1、11のどれを扱ったか、Java 17や21などのJDKに対応できるかを確かめます。

• 技術経験：Spring、Struts、JSP、Jakartaへの移行経験も、あわせて確かめます。
• 担当範囲：アプリとインフラの担当会社、負荷試験・障害試験の担当者を明確にします。
• 既存資産の調査：設計書が不足している場合の調査や、バイナリやログからの構成把握、検証環境の用意ができるかを質問します。

たとえば、2026年のJSTのJ-STAGE調達でも、Spring、Struts、Tomcat更新、環境設定、改修、動作確認テストを一体で求めています（出典: 科学技術振興機構「J-STAGEシステムSpring FrameworkのEOL対応業務」、2026年）。

委託先を評価する出発点は、移行をTomcatの交換だけでなく、システム全体の作業として捉えることです。

見積書の工程・工数・前提条件の比べ方

見積書は、要件定義から基本・詳細設計、実装、テストまでを工程ごとに分けて比べます。さらに、性能・セキュリティ試験や移行、教育、リリース、保守が、どの工程に入っているかを見ます。

• 前提条件：画面、API、連携、データ、環境、想定ユーザーの数をそろえます。
• 比較項目：成果物、担当者の経験、予定、発注側の作業、追加費用条件を表にします。
• 金額差：安い場合は工程の別料金か、高い場合は必要な品質への費用かを見ます。

「システム開発一式」という書き方では、検証や移行が含まれないこともあります。

納品物・引き継ぎ・責任分界の確認

納品物は、ソースコードや設計書、API仕様、DB定義を確かめます。環境設定やCI/CD定義、テスト結果も、納品物に含まれるかを確認します。

• 運用資料：監視設定、バックアップ手順、障害対応手順も納品対象にします。
• 引き継ぎ：第三者が再構築できる情報のほか、管理者アカウントや証明書が発注側に移るかを確かめます。
• 責任分界：クラウド、ネットワーク、DB、アプリ、セキュリティ監視の分担を、図にまとめます。
• 契約終了時：脆弱性情報の確認頻度、データ返却、引き継ぎ条件を定めます。

文書が不足していると、次回の更新や別の会社への引き継ぎで、再調査の費用が発生します。

障害原因を切り分ける手順や連絡先がないと、復旧までの時間が延びます。そのため、担当エンジニアや代替要員、保守窓口も確かめておきます。

よくある質問（FAQ）

Tomcatの発注では、ライセンス、移行、費用、会社選びについて質問が寄せられます。外注前に判断しやすいよう、それぞれ答えます。

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

Tomcat本体はOSSなので、原則としてライセンス購入費は不要です。ただし、業務アプリの設計や開発、サーバー構築、テストには費用がかかります。

さらに、移行や監視、脆弱性対応、保守にも費用がかかります。無料なのはソフトウェアの利用部分で、安全に使い続けるための作業は含まれません。

Tomcat 9から10や11へすぐに更新すべきですか？

サポート状況や脆弱性、JDK、アプリの互換性、業務上止められる時間を見て判断します。

メジャー更新では、設定やServlet API、依存ライブラリ、認証、セッションを確かめ、テスト結果も見ます。また、検証環境で切り戻しも試します。

旧版を使っている場合は、本番更新の前に、現状のアセスメントと移行検証を依頼すると安全です。

Tomcatの外注先は何社に見積もりを依頼すべきですか？

要件と比較条件をそろえたうえで、3社程度に依頼すると、提案と費用の差を把握しやすくなります。

価格だけでなく、担当範囲や実績、テスト、納品物、保守、発注側の作業も比べます。

既存資産が不明な場合は、通常開発とアセスメントの見積もりを分けて、各社の前提を比べます。

まとめ

Tomcatの発注では、Javaアプリや外部連携、移行を業務として整理します。さらに、DBや性能・セキュリティ試験、監視、保守も、同じように一覧に入れます。

まずは、TomcatやJDK、OS、DBなどの構成を洗い出します。そのうえで、フレームワークやWARやJAR、運用手順も含め、業務要件と非機能要件をRFPにまとめます。

発注前の契約と費用の前提

要件が固まった開発は請負、調査や伴走は準委任、監視や脆弱性対応は保守契約に分けて、成果物と責任範囲をはっきりさせます。

アセスメントや更新、新規開発、クラウド初期構築、運用、保守は、分けて見積もります。そのうえで、工数やテスト、移行、納品物、発注側の協力条件も比べます。

小さな調査から始めて安全に委託する進め方

既存システムの構成や互換性が分からないなら、本番移行をすぐに契約せず、アセスメント、検証環境、代表機能の移行テストの順に進めます。

1. アセスメントで、構成と互換性を調べます。
2. 検証環境を用意し、代表機能の移行テストを行います。
3. 技術実績と運用体制を確かめた委託先に、移行などを任せます。

この流れは、Tomcat 9から10.1や11への更新や、新規のJava業務システム、クラウド移行にも活用できます。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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