Servletのシステム開発は、業務と既存資産を整理し、技術と開発会社を選んだうえで、設計から定着までを段階的に進めることで、運用できる仕組みに仕上げます。
費用は規模や要件で大きく変わるため、工程ごとの作業と見積もりの確認点を押さえておく必要があります。
▼全体ガイドの記事
・Servletのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Servletのシステム開発の全体像
Servletは、HTTPリクエストを受け取り、処理結果を返すサーバーサイドAPIです。
業務システムは、画面や業務ロジック、DBといった要素を組み合わせて作ります。認証認可や帳票も、その一部です。
外部API、監視、コンテナも、同じく組み合わせる要素です。
技術名とシステム全体を分けて考えると、作業や見積もりの漏れを減らせます。
Servlet・コンテナ・フレームワークの役割の分担
Servletの周辺では、Servlet本体、コンテナ、フレームワーク、画面とデータの技術が処理を分担しています。
構成を見積もる際には、どの技術が何を受け持つかを先に分けておく必要があります。
- Servlet：HTTP処理の共通ルールを提供する部分です。
- コンテナ：TomcatやJettyは、ライフサイクルやURL、セッションを担います。
- フレームワーク：Spring MVCやSpring Bootでも、Servletコンテナを実行基盤にした構成が少なくありません。
- 画面とデータ：JSPは画面表示、JDBCやJPAはデータアクセスの役割です。
Cookieやエラー処理、FilterやListenerも、コンテナの役割です。
開発範囲は、画面やデータアクセスの役割も含めて判断します。
新規開発と既存Servlet資産の刷新の判断軸の違い
既存システムでは、画面やURL、web.xmlなどの構成を洗い出します。
認証や直接SQL、バッチ、手作業のデプロイも対象に含め、古い設定や画面ごとの業務ロジックを見落とさないように調べます。
- 新規開発：保守性、クラウド、API連携、権限の方針を決め、必要ならSpring Bootを採用します。
- 既存資産：保守を続ける案と、Java・コンテナを更新する案を候補にします。
- 刷新方法：javaxからjakartaへの移行、段階的な再設計、全面再構築の比較です。
Jakarta Servlet 6.1はJava SE 17以上を最低要件とします（出典: Eclipse Foundation「Jakarta Servlet 6.1」）。そのため、移行対象のJavaバージョンが条件を満たすかを確認します。
Servletのシステム開発の進め方・流れ
Servlet開発は、要件整理から定着までを六つの段階に分けて進めます。段階ごとに区切ると、判断の抜けに気づきやすくなります。
各段階の完了条件を決めてから次へ進みます。
特に刷新では、要件整理やテストを短く済ませると、後工程で手戻りが起きやすくなります。
1. 要件整理で業務と既存資産を見える化
要件整理では、利用者、対象業務、達成したいことを定義します。
たとえば受注管理なら、受注登録から請求、取消までの流れを利用者と確かめます。在庫引当や承認、出荷は、その流れのどこで起きるかを確認します。
画面数に加えて、処理の分岐と権限も洗い出します。
あわせて、Java、Servlet、JSP、コンテナ、DBのバージョンを一覧にしておきます。
- 業務と利用者：現行と将来の業務フロー、利用者、権限。
- データと連携：ピーク時の同時接続数、データ件数と増加量、連携先と方式、保存期間を整理します。
- 運用と完了条件：監査ログ、復旧目標、未確定事項の担当者と期限、優先順位を決めます。
仕様書がないときは、ソースコードやDB定義、アクセスログから事実を確かめます。担当者への聞き取りや実画面も使います。そのうえで、推測と確定事項は分けて管理します。
調査対象は、URLマッピングやFilter、Listenerなどの仕組みです。外部連携やバッチ、帳票も対象に入ります。ログやバックアップ、デプロイ方法も見ておきます。
2. 開発会社と技術の比較表による選定
要件を整理したら、複数社に同じ資料を渡して比較します。確認する項目をそろえておくと、各社の提案の違いが見えてきます。
- 技術と移行：JavaのLTS運用やTomcat・Jettyの更新、javaxからjakartaへの移行に対応できるかを確認します。
- 業務と体制：類似する業務・規模・移行難易度の実績、担当者経験、再委託、障害連絡体制を比べます。
- 対応範囲：クラウド、認証認可、データ移行、性能試験、運用監視のどこまでを扱うかです。
会社の規模よりも、自社の業務や移行難易度に合う実績と体制を重視します。そのうえで、担当予定者の経験も確認します。
独自性の高い業務はJavaで実装する一方で、標準的な申請や会計機能はSaaSやパッケージに寄せる方法もあります。
Servletを直接使う範囲と、フレームワークに任せる範囲を決めます。
移行では、影響範囲を絞った一部の機能でPoCを行います。
PoCでは、新しい環境でビルドや認証、DB接続が動くかを確かめます。セッションとファイル処理も対象に含めます。
3. 業務ルールと非機能の実装への落とし込み
基本設計では、画面遷移やURL、APIを決めます。権限やデータモデル、外部連携、エラー時の動作も、この段階で定めます。
詳細設計では、トランザクション境界と同時更新を定義します。タイムアウトやリトライ、文字コードも決めます。さらに、ファイル上限、セッション切れ、ログ項目も定義します。
画面クラスに業務ルールとSQLが混在している既存システムでは、画面、サービス、データアクセスの役割を分けることで保守性が高まります。
- 運用設計：可用性や性能、バックアップ、監視、運用手順を決めます。
- セキュリティ：CookieにSecure・HttpOnly・SameSiteを設定し、CSRF、SQLインジェクション、XSS、認可漏れも確認します。
- 情報と移行：秘密情報と個人情報の扱い、Jakarta名前空間への変更範囲を見ます。
秘密情報の管理と個人情報のマスキングは、レビューの対象に含めます。
Jakartaへの変更は、ライブラリや設定ファイルにも及びます。
依存関係やweb.xml、ビルド定義は、テスト環境を含めてソースコードと合わせて管理します。
4. テストによる正常系・異常系・移行後の差分の確認
テストは単体から始めて、結合、総合へと進みます。性能、セキュリティ、障害復旧の確認も続きます。各テストは、目的と合格基準を明確にしておく必要があります。
- 利用と権限：認証後の権限や、二人が同じデータを更新する場合を確かめます。
- 異常時の処理：外部APIの遅延、通信切断、不正なCSV文字、セッション失効を試します。
- 刷新後の整合性：画面の差分、移行件数、金額・日付、帳票、バッチ、ロールバックを確認します。
刷新時は、画面表示に加えてデータや処理順も含めて、旧新の差を検証します。
安全要件を確認する基準として、OWASP ASVS 5.0をRFPや受入条件で参照できます（出典: OWASP Application Security Verification Standard）。
不具合は、件数に加えて、重要度や再現条件、修正期限、再テスト結果まで記録します。
5. 稼働時の段階リリースと戻し方の決定
稼働前には、リリース手順と分担、停止時間を合意します。DBのバックアップや移行リハーサル、監視、問い合わせ窓口の準備も整えます。ロールバックの条件は、このときに決めておきます。
- 段階リリース：部門や機能ごとに分けて、順に公開します。
- 並行稼働：旧新システムを一定期間併用します。
- カナリアリリース：限定した利用者から新システムを使います。
これらは利用者が多い場合に検討します。
切替後に問題が起きたときは、誰がどの判断で旧環境へ戻すかを決めておきます。
本番では、ロードバランサーやWAF、TLS証明書の設定を確認します。
DBや外部API、監視の設定も見ておきます。
Tomcatの公式ページには、2025年以降も認証やTLS、リクエスト処理、アップロードなどの修正が掲載されています（出典: Apache Tomcat 9.x vulnerabilities）。
Tomcat 9.0.xは2026年2月11日にサポート終了が案内されています。そのため、対象バージョンとパッチ適用の責任を契約に明記します（出典: Apache Tomcat 9.0.x End of Support）。
6. 定着期の利用状況の把握と運用改善
稼働後の定着には、利用者への支援と継続的な業務改善の両方が必要です。
- 利用支援：研修、マニュアル、問い合わせ、権限申請、障害連絡、定期メンテナンスを整えます。
- 業務改善：旧業務を続ける理由を調べ、入力項目や承認フローを見直します。
- 利用状況の確認：アクセス状況、エラー率、処理時間、問い合わせ、未利用機能から改善テーマを決めます。
- 委託運用：保守範囲、脆弱性通知期限、初動時間、復旧目標、復元テスト、更新方針の取り決めです。
- 内製化：担当者が実際に変更・リリースできるまで伴走を依頼します。
引き継ぎでは、ソースコードや設計書、テスト証跡を受け取ります。加えて、CI/CDやInfrastructure as Code（IaC）、監視設定、アカウント一覧も必要です。
改善テーマは月次または四半期ごとに決めます。
Servletのシステム開発の費用相場とコストの内訳
Servlet単体で決まった公定価格はありません。
費用は、要件整理の難しさや画面・帳票数、利用者数で変わります。データ量や外部連携、移行範囲も、費用を動かす要因です。
性能やセキュリティの要件、運用体制も、人月や各種費用に影響します。
以下に示すのは、公開相場とリサーチノートの人月前提に基づく目安です。個別案件の確定金額ではありません。要件や条件をそろえて、見積もりを取ります。
規模別の費用の幅（300万円台〜1億円超）
小規模・MVPは、1部門、5〜15画面、ログイン、基本登録・検索、単一DB、簡易帳票を想定します。
小規模の期間は、要件が固まっていて外部連携や移行が少ない場合の目安です。
中規模は、複数部門、15〜50画面、権限・承認、CSVやAPI連携、総合テストを含みます。
大規模刷新は、全社利用や50画面超、複数DB、基幹連携、旧Servletとデータの移行を含みます。さらに、冗長化や監査、並行稼働も想定します。
- 小規模・MVP：300万〜800万円、2〜4か月、5〜10人月が目安です。
- 中規模：800万〜2,500万円、4〜8か月、12〜25人月を見込みます。
- 大規模刷新：2,500万円〜1.5億円以上、8〜18か月以上、30〜100人月超となることがあります。
ここに示した費用や期間の幅は、人月の前提から推定したものです。ただし、画面数が少なくても、複雑な権限や厳しい性能要件、データクレンジングがあると、費用は上振れします。
費用の内訳（人件費・基盤費・移行費・保守費）
見積もりでは、開発人員の単価と、基盤や移行などの費用を分けて確認します。
- 人件費：PM、アーキテクト、要件定義、設計、Java開発、テスト担当が中心です。
- 単価：エンジニア50万〜200万円／人月、PM・アーキテクト130万〜250万円／人月です（出典: 株式会社ripla「Java開発の完全ガイド」）。
- 基盤費：クラウドやDB、LB、WAF、監視、バックアップ、証明書、脆弱性診断、ライセンスに関わる費用です。
- 付帯費：データ移行、研修、マニュアル、保守を見積もりに含めます。
単価だけでなく、参加人数と期間、レビューや管理工数の有無を確認します。
AWSのT3で例にとると、t3.mediumは2 vCPU・4GiBです。掲載されている料金は、米国東部のLinux例です（出典: AWS「Amazon EC2 T3 インスタンス」）。
東京リージョンやEBS、データ転送、RDSなどの料金は別途です。そのため、クラウド費用は構成と稼働時間から見積もります。
保守と運用の予算化（初期費用とは別）
継続費用は、保守の作業範囲と月々の運用条件を分けて見積もります。
- 保守費：初期開発費の年15〜25％程度を仮置きする方法があります。
- 月額運用費：24時間監視、厳しい復旧目標、複数環境、データ増加があれば別途提示を依頼します。
- 総保有コスト：初期費、クラウド・保守月額、追加・更新単価、終了時の引き継ぎ費を3年程度で比べます。
保守範囲は、障害対応や機能追加、脆弱性対応がどこまで含まれるかを確認します。OSやJavaの更新、監視、問い合わせ、定例会も同じ確認の対象です。
安価な見積もりでは、稼働後のパッチ適用や障害調査が別料金となる場合があります。
Servletのシステム開発で見積もりを取る際のポイント
開発会社に「Javaで一式」とだけ伝えると、見積もりの前提がばらつきます。対象範囲と受入条件をそろえて伝えます。
現行調査から保守まで、工程別に分けて確認します。工程は、現行調査、要件定義、設計、実装の順に進みます。
そのあと、各テスト、移行、リリース、研修、保守と続きます。あわせて、成果物と前提条件も確かめます。
価格に差があるときは、単価だけでなく、含まれる作業と除外される作業を比べます。
RFPに書く画面数以外の条件
RFPには、対象業務や利用者と権限、画面・帳票・APIを書きます。
同時接続数やピーク時間、データ件数、保存期間も記載します。
連携先や認証方式、旧システムのバージョン、移行対象、希望リリース日も示します。未確定の要件は、その旨をはっきり書きます。さらに、要件整理フェーズの成果物と追加見積もりの条件を、開発会社に提示してもらいます。
- 性能と稼働：月間稼働率、応答時間、同時利用者数を示します。
- 復旧と記録：バックアップ頻度、復旧時間、ログ保管期間を決めます。
- 安全と連絡：診断、暗号化、監視時間、障害連絡期限を指定します。
特に、ファイルアップロードや認証認可、個人情報、API再送、DB復元は、後付けで設計変更が大きくなりやすい項目です。
開発会社の技術力・体制・成果物の比較
候補会社は、技術経験に加えて、実績の確かめ方と契約後の体制も比べます。
- 技術経験：案件規模、Java・コンテナの版、javaxからjakartaへの移行の有無を確認します。
- 体制：担当者、レビュー、テスト自動化、クラウド運用、障害対応の進め方。
- 実績：会社名や業界名だけでなく、画面・連携・人数、課題、期間を聞き、匿名資料も確認します。
- 成果物：コード、設計書、テスト結果、CI/CD、IaC、データ定義について、権利と引き渡し範囲。
- 契約と知見移転：再委託、交代、検収、追加単価、遅延、保守終了時の移管を確かめます。定例会やレビュー参加、運用手順の演習も見積もります。
見積のリスクの抑え方（前提・除外・変更ルール）
見積もりの不確定要素は、前提条件と変更時の手続きを明記して管理します。
- 想定リスク：仕様のブラックボックス化、古い依存、セッション過多、直接SQL、連携不足、移行不整合、性能試験不足です。
- 見積条件：未確定事項、顧客作業、既存環境、データ整備の責任、追加費用の条件の明記。
- 初回リリース：優先業務を選び、希望機能を一度にすべて実装しないようにします。
- 変更管理：目的、影響、工数、納期、費用、受入条件を記録して承認する手順。
- 検証：サンプルデータの件数・金額・関連キーを照合し、性能はピーク時と遅延時も合格基準にします。
Servletのシステム開発でよくある質問
新規開発と既存刷新では、判断の仕方が変わります。現行資産や業務の独自性、将来の運用体制を踏まえて確認します。
Servletのシステムとは何ですか？
Servlet APIとコンテナを使い、ブラウザや他システムのリクエストを処理する業務Webシステムです。
Servletは業務パッケージそのものではなく、業務を組み立てる要素の一つです。画面や業務ロジック、DBを組み合わせて作ります。認証、帳票、外部連携、監視も、その周りに加わる要素です。
古いjavax.servletのシステムはjakarta.servletへ移行できますか？
移行できる可能性はありますが、判断には関連資産の調査が必要です。文字列の置換だけで済むとは限りません。
調査対象は、ソースコードや依存ライブラリ、web.xml、JSPです。Filterや認証、テスト環境、アプリケーションサーバーも含みます。
そのため、PoCでビルドや起動、主要業務、外部連携が動くかを確かめます。そのうえで、Javaとコンテナの対応範囲を決め、段階移行か再設計かを比べます。
Servletのシステム開発にはいくらかかりますか？
小規模・MVPは300万〜800万円程度、中規模は800万〜2,500万円程度、大規模刷新は2,500万円〜1.5億円以上が目安です。
これは、画面数や連携、移行、非機能の前提に基づく推定です。Servlet固有の定価ではありません。
要件整理の後に、人月やクラウド、移行、テスト、保守を分けて見積もります。そのうえで、前提と除外を確認します。
開発会社を選ぶときに最も確認すべきことは何ですか？
Java経験だけでなく、業務理解から既存資産の調査、移行、テスト、運用まで担えるかを確認します。
担当者や再委託、成果物を確認し、ソースコードとIaCの引き渡しや脆弱性対応、障害体制、保守終了時の移管条件も確かめておくと、稼働後の依存を減らせます。
Servletのシステム開発の進め方まとめ
Servletを単独の製品とせず、業務、アプリ、実行基盤、データ、運用を一体で設計します。
要件整理で現行資産を把握し、選定では移行方針とパートナーを比べます。
そのあと設計開発、テスト、段階稼働と進み、利用定着までつなげます。
発注前に確認する六つの完了条件
発注前には、六つの工程それぞれの完了条件をそろえておきます。未確定事項や担当者が曖昧な工程は、次へ進む前に合意しておきます。
- 要件整理では、未確定の業務フローや現行資産、非機能の事項に、担当者と期限を付けておきます。
- 選定では、移行からテスト、運用までの対応範囲を比べます。
- 設計開発では、権限や連携、エラー、ログを仕様の形にまとめます。
- テストでは、移行後の差分や性能、復旧、セキュリティごとに合格基準を定めます。
- 稼働では、バックアップとロールバックを事前にリハーサルします。
- 定着では、研修や問い合わせ、改善の役割分担を定めます。
最初に取り組む現行調査と要件整理
最初に現行環境を把握し、調査の進め方と支援体制を整えます。
- 現行調査：詳細見積もりの前に、画面、URL、Java・コンテナ・DB、連携、データ、運用手順を整理します。
- 計画：短い調査を先に依頼すると、計画の精度が上がります。
- パートナー選定：新規・刷新を問わず、業務整理からテスト、定着まで支援し、費用の前提を説明できる相手を選びます。
▼全体ガイドの記事
・Servletのシステム開発の完全ガイド
▼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を創業。