Jettyのシステム開発は、要件整理とJettyの構成検証から始め、設計・開発、テスト、稼働、定着の順に進めるのが基本です。
この順に進めると、稼働後の運用まで見通した業務Webシステムにつながります。Jettyの役割や費用の内訳も、あわせて押さえておくと判断に役立ちます。
▼全体ガイドの記事
・Jettyのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Jettyのシステム開発の全体像
Jettyのシステムは、ブラウザや外部APIからのリクエストを受け、Javaの業務アプリを実行する仕組みです。
典型的な構成は「利用者→CDN／WAF→ロードバランサー→Jetty→Javaアプリ→DB・外部業務システム」です。Jettyの設定だけでは足りず、業務ルール、データ、セキュリティ、運用体制も一体で決める必要があります。
Jettyの位置づけ：業務機能を支える実行基盤
販売管理や在庫管理、申請・承認などの業務機能は、Spring Boot、Jakarta EE、独自Javaアプリで実装します。
Jettyは、HTTP通信、Servletの実行、セッション、WebSocketなどを担当します。業務機能は別に実装するため、Jettyを導入した時点では業務システムは完成しません。
RFPや提案書の冒頭で、この役割分担を明確にしておきます。明確にしないと、アプリ開発、DB、クラウド、保守の費用が見積もりから漏れやすくなります。
採用判断の軸：性能と運用条件
Jettyは、メモリ効率や拡張性を重視したWebサーバー／Servletコンテナで、HTTP/1.1、HTTP/2、HTTP/3、WebSocketに対応します（出典: Eclipse Jetty公式ドキュメント、2026年8月確認）。
Jettyの構成は、新規アプリの配布形態と既存WARの移行方式を踏まえて選び分けます。
- 新規アプリ：Spring Bootでは`spring-boot-starter-jetty`でEmbedded Jettyを選べます。
- 配布形態：Embedded Jetty+実行可能JAR+Dockerの組み合わせは、新規システムに適します。
- 既存アプリ：既存WARは、スタンドアロンJetty+WARで段階的に移行できます。
組み込み型とスタンドアロン型のどちらにするかは、既存資産と運用スキルを含めて判断します。
バージョンは原則としてJetty 12系から検討します。12.1.xと12.0.xを使うには、Java 17が必要です。
互換表によると、12.1.xはJakarta EE 11・10・9・EE 8に、12.0.xはJakarta EE 10・9・EE 8に対応する安定系列です。
Jetty 11、10、9.4はEOLです。既存環境では、Java 17への対応や`javax.servlet`から`jakarta.servlet`への移行、JSPや認証ライブラリの互換性を、先に調べておきます。
Jettyのシステム開発の進め方と6つのフェーズ
先にJettyを導入し、業務仕様をあとから考えると、認証、連携、性能、移行の問題が後になって起きます。
まず業務目的と非機能要件を決め、Jettyの構成を小さく検証します。そのうえで検証の範囲を段階的に広げ、本番に近づけていきます。各フェーズの成果物と、発注者の判断基準も確認しておきましょう。
フェーズ1：業務と非機能の要件整理
業務フローには、誰が担当するか、いつ使うか、どのデータを使って何を判断するかを書き込みます。業務機能と運用条件を一緒に洗い出すと、Jettyに求める範囲がはっきりします。
- 機能：ログイン、権限、申請・承認、検索、CSV、帳票、通知、外部API
- 負荷：利用者数、ピーク時の同時接続数、応答時間
- 運用：稼働時間、停止許容時間、データ保持期間、監査ログ
- 現場業務：Excel、紙、FAX、手入力で行っている例外と、標準化できる作業
業務フロー図は部門ごとに用意します。画面・帳票・連携の一覧と、マスタの責任者もあわせて決めておきます。
同時利用者数とピーク時間は、性能要件の前提になるため測っておきます。障害時にどこを手作業で補うか、個人情報や機密データをどう扱うかも決める必要があります。
要件定義書には、Jettyだけでなく、JDK、Servlet／Jakarta EE、DB、リバースプロキシを記載します。監視とバックアップも記載の対象です。
フェーズ2：Jettyの構成と代替案の比較
Jettyが合うかどうかは、アプリの形態や拡張の仕方に応じて構成ごとに比べて判断します。既存資産と運用の単位に合う選択肢を、あわせて確認しておきましょう。
- 新規Spring Boot：Embedded Jetty + 実行可能JAR + コンテナ
- 既存Servlet／JSP：スタンドアロンJetty + WAR
- 複数サービス：自動拡張が必要ならコンテナ基盤
- 代替案：Tomcat、クラウド標準ランタイム、SaaS、パッケージ
まず、Jettyでなければ満たせない条件を明らかにします。応答時間に加えて、想定リクエスト数と同時接続数をPoCで測ります。WebSocket数とメモリ使用量も、同じ検証で確かめます。
`$JETTY_HOME`と`$JETTY_BASE`を分けて、環境ごとの設定を管理できるかを確かめます。また、HTTP/2やTLSをロードバランサーとどう分担するか、ログを何日保管するかも決めます。
Jettyの直接の実績がない会社の場合は、担当者の経験、脆弱性対応、ソースコードと設定の引き渡し範囲を、面談で確かめます。
フェーズ3：設計・開発での役割分担と設定の確定
基本設計では、画面、API、DBの全体像を定めます。権限と外部連携は、この段階で詳しく決めます。エラー処理と監視も、同じ段階で扱います。
Jettyの設定は、コードや構成管理の仕組みで管理します。開発、検証、本番の違いを表にしておくと、食い違いの確認に使えます。
TLS証明書と秘密情報、セッションについては、責任者と変更手順を決めます。アクセスログ、JMX、ヘルスチェックにも、責任者を置きます。タイムアウトとコネクションプールについては、変更手順を先に決めておきます。
全機能を一度に作らず、まずはログインから1業務の登録・承認・検索までを通すスライスを実装します。小規模のPoCでは、Jetty、JDK、Spring Bootを接続します。DB、認証、リバースプロキシも、そこに加えます。
PoCは、実データ量に近い条件で動かします。既存のJettyから12系へ移る場合は、互換性の確認事項を先に洗い出しておきます。
- 名前空間と依存関係：`javax`／`jakarta`、依存ライブラリ
- Web機能：JSP、フィルター、セッション
- 独自実装：カスタムHandler
互換性の問題を実装の後まで持ち越さないために、これらの調査結果を設計に反映します。
フェーズ4：機能・性能・安全性のテスト
テストは、単体、結合、総合、受入の順に進めます。Jettyの動作確認では、負荷や障害時を含めて、次の項目を確かめます。
- 通信・接続：同時接続、長時間WebSocket、HTTP/2、TLS
- 障害時：タイムアウト、異常切断、再起動
- 運用：ログ出力、バックアップからの復旧
目標値は、測定できる数値で定めます。たとえば、ピーク時の同時利用者数や95パーセンタイルの応答時間があります。エラー率やCPU・メモリ上限も、数値で示します。
セキュリティでは、認証・認可、Cookie、CSRFを確認します。入力値検証や秘密情報の扱い、不要なHTTPヘッダーも対象です。ログのマスキングと脆弱性スキャンも、確かめておきます。
2026年4月、Jetty公式はCVE-2026-5795などの修正版として、12.0.34や12.1.8を案内しました（出典: Eclipse Jetty Security、2026年4月）。
開発中の版に問題がなくても、稼働後の更新手順と緊急パッチの判断基準を決めていなければ、運用上のリスクは残ります。
フェーズ5：稼働時の移行と障害対応
本番移行の準備では、データの整合性、切り替え時の確認、障害時の担当を順に決めていきます。
- リハーサル：本番の前に、データ移行を少なくとも1回行い、データの整合性を検証
- 並行稼働：新旧を一定期間並べて動かす場合は、正とするデータと二重入力の防ぎ方を運用手順に定める
- 切り替え当日：作業時刻、担当者、確認項目を書き込んだチェックシートを使う
- 完了の判断：Jettyの起動ではなく、代表ユーザーのログインや主要業務で判断
- 障害時の一次切り分け：Jetty、JDK、アプリ、DB、ネットワーク、クラウドごとに、誰がどこまで担うかを明記
判定者と異常時の連絡先は、このシートに記します。完了時には、外部連携、帳票、監視通知、ログ保存、バックアップも、あわせて確かめておきます。
移行データは、件数、欠損、重複、文字コード、日付を確かめます。金額と権限の確認も欠かせません。
マスタ登録の責任者と移行対象外のデータを決めます。切り戻しの条件や停止時間も、あらかじめ定めておきます。利用者への告知と問い合わせ窓口は、切り替え前に用意します。
フェーズ6：定着と保守性の向上
稼働後は、画面が使えるかだけでなく、業務が以前より正確に、短い時間で進むようになったかを確かめます。月次で追う指標には、次のようなものがあります。
- 利用と問い合わせ：問い合わせ件数、ログイン率
- 業務品質：入力エラー、処理時間、承認の滞留
- 修正と改善：CSV修正件数、現場の声
現場の声は、改善バックログに反映します。操作マニュアルに加えて、業務ルールと権限申請の手順を整えます。障害時の代替手順やデータ修正の承認ルートは、あらかじめ用意しておきます。
保守台帳には、JettyとJDKの版、依存ライブラリを記録します。コンテナイメージや設定ファイル、SBOMも、あわせて残します。
保守の周期は、月次の脆弱性確認、四半期の更新計画、年次の復旧訓練として決めておきます。EOLの何か月前から次期版の評価を始めるかも、発注者と開発会社で合意します。
IPAの「中小企業の情報セキュリティ対策ガイドライン第4.0版」は、2026年3月に公開され、重要な取り組みを整理しています（出典: IPA、2026年）。
Jettyの設定だけでなく、組織の運用ルールとしてセキュリティを定着させます。
Jettyのシステム開発費用相場とコストの内訳
Jettyは、Eclipse Public License v2またはApache License v2のもとで、商用利用と配布ができるOSSです。そのため、Jetty本体の商用ライセンス購入費は原則0円です。
ただし、業務アプリの設計・実装、DB、クラウドは、別途必要になります。監視、診断、移行、保守、商用サポートも、費用として考えておきます。Jettyが無料でも、システム全体が無料になるとは限りません。
規模別の初期費用：300万〜1億円超の幅
初期費用は、機能数や連携数に加えて、移行データ、可用性、試験範囲によっても変わります。規模ごとの想定額を比べるときは、見積もりの前提をそろえておきましょう。
- 小規模：社内向けで300万〜800万円
- 中規模：業務Webで800万〜2,000万円
- 大規模：基幹連携や高可用性を含み2,000万〜1億円超
これは、Jetty専用の公定価格ではありません。要件定義から導入、非機能試験までを含めた、編集上の推定値です。
2026年公開の国内相場情報では、小規模の業務ツールは100万〜300万円です。
また、単一業務のカスタムシステムは100万〜500万円、基幹系は1,000万〜3,000万円以上です（出典: Cataly Design、SIAなどの2026年公開相場情報）。
小規模では、ログインや申請・承認、一覧・検索を想定します。CSVや簡易管理画面を含め、期間は2〜4か月程度が目安です。
中規模では、顧客・商品・権限、帳票、外部APIを含みます。既存DBと監査ログも含まれ、期間は4〜8か月程度を見込みます。
ERPやWMSとの連携、24時間運用を伴う案件は、8〜18か月以上かかる可能性があります。冗長化やデータ移行、段階リリースを行う案件も、この期間を見ておく必要があります。
納期と金額は、現行資料の状態や、発注者側の意思決定の速さによっても変わります。
開発費と運用費を分けた総額の比較
初期費用は、工程別の配分を仮のチェック基準として使い、どの作業が含まれ、どの作業が別料金かを確かめます。
- 要件定義・基本設計：要件定義10〜15%、基本設計15〜20%
- 詳細設計・実装・単体テスト：詳細設計10〜15%、実装・単体テスト30〜40%
- 結合・総合テスト、移行・導入：結合・総合テスト15〜20%、移行・導入5〜10%
割合は案件の特性によって変わります。そのため、割合だけで適正価格かどうかは判定できません。
Jetty固有の追加項目には、HTTP/2・HTTP/3やWebSocketの負荷試験があります。TLS証明書・鍵管理やリバースプロキシも、追加項目です。旧版からの移行と脆弱性調査も、そこに含まれます。
小〜中規模の運用費は、月額5万〜50万円程度が推定レンジです。クラウド、監視、ログ保管、バックアップの費用を含めた数字です。
24時間監視や冗長化、商用サポートを含めると、月額50万〜数百万円になる可能性もあります。データ量が増える場合は、この上振れも想定しておきます。
開発費3,000万円に保守比率15〜20%を当てると、年間450万〜600万円が参考になります。
Jettyのパッチとアプリ改修は、分けて提示してもらいます。OS・JDK更新とクラウド利用料も、別々の金額で示してもらいます。
Jettyのシステム開発で見積もりを取る際のポイント
安さだけで選ぶより、同じ前提条件で比べられる見積もりをそろえることが大切です。Jettyの導入費だけを見ると安く見えても、業務要件、連携、移行、性能試験、運用設計が別途扱いになれば、その分が追加費用になります。
RFPには、機能一覧と非機能要件を含めます。情報が不足している箇所を、提案会社がどう扱ったかも記録しておきます。
見積書に載せる要件・成果物・前提条件
依頼内容と既存環境を同じ観点でそろえておくと、調査範囲や納品後の運用まで比べやすくなります。
- 見積依頼で渡す資料：業務フロー、画面・帳票の一覧、外部連携先
- 既存環境の確認：Java・Jettyの版、WARか組み込みか、`javax`の利用や設定、依存ライブラリ
見積依頼時には、データ件数、利用者数、権限、ピーク時間も、あわせて伝えます。応答目標、稼働時間、バックアップ要件、セキュリティ基準は、運用の条件として示します。既存環境では、ログや既知障害も、あわせて洗い出します。
情報が足りない場合は、調査やPoCを先行するフェーズに分けて、見積もりを立てます。
成果物には、要件定義書、構成図、画面・API仕様、DB定義を含めます。Jetty・JDKの版一覧や設定、ソースコードも、成果物に入れます。
テスト仕様と性能試験の結果を確かめます。移行・運用手順や監視設計、バックアップ・復旧手順も見ておきます。SBOMと脆弱性対応手順も、そこに含めます。
実行ファイルだけが納品されると、担当が替わったあとに設定変更や障害対応が難しくなります。ベンダーロックインの原因にもなります。
発注先の選び方：Jettyの経験と業務・運用への対応力
発注側は、候補会社の技術力と運用責任を、過去の実績や納品後の対応を具体的に尋ねて見極めます。
- 技術経験：Jetty更新、Java 17・Jakarta移行、HTTP/2・WebSocket負荷試験
- 保守対応：脆弱性通知と修正時間、障害時の一次対応、SLA
- 納品と費用：コード・設定・SBOMの範囲、クラウド費と保守費の分離
- 移行分担：データ移行で発注者に求める作業
「Jetty対応可能」という説明だけでは判断せず、担当者と過去の構成を確かめます。障害時の一次対応とSLAも、契約前に確認しておきます。
Jettyコアの調査や商用サポートを重視する場合は、Webtideのような専門事業者が候補になります。
要件定義から移行、クラウド運用まで任せたい場合は、Java／Spring Bootとクラウドに実績がある国内SIerや開発会社と比べます。
公開情報だけでは、Jettyの直接案件を確認できないことがあります。そのため、専門会社との協業か自社保守かを聞き、契約上の責任の範囲を明記してもらいます。
追加費用につながりやすいリスク
追加費用につながるリスクは、仕様、技術、データの準備状況に分けて、早めに確かめます。
- 仕様変更：要求追加、外部APIの変更、性能要件の後出し
- 技術・移行：マスタ未整備、古いJDK・Jettyの移行、診断後の改修
- データ品質：移行データの不備
リスクごとに、発生条件や影響範囲、予備費を表に書き出します。意思決定者と対応期限も、同じ表に入れておきます。マスタの整備には、発注者の業務知識が欠かせません。
コストを抑えたいときは、テストや監視を削らないまま、初回リリースの範囲を絞ります。まずは1部門・1業務で、認証から主要処理、ログ、バックアップまでを通します。
利用状況を見てから、連携や高度な分析を加えます。PoC、開発、検証、本番の環境差分を小さくし、設定をコードで管理すると、将来の調査・更新費を抑えられます。
Jettyのシステム開発でよくある質問
Jettyの技術選択や費用、既存システムとの互換性、運用責任について、よくある質問に答えます。
Jetty本体のライセンス費用はいくらですか？
Jettyは、EPL v2またはApache License v2で商用利用と配布ができるOSSです。本体の商用ライセンス購入費は、原則0円です。
開発やクラウド、監視は別途必要です。脆弱性対応や保守、商用サポートも、別途かかる費用です。Jetty単体ではなく、業務システム全体の初期費用と運用費で比べます。
JettyとTomcatはどちらを選べばよいですか？
どちらか一方が常に優れているわけではありません。既存資産と開発者の経験、運用体制で選びます。必要なプロトコルも、判断の材料にします。
Spring Bootは、Embedded JettyとEmbedded Tomcatの両方に対応しています。そのため、新規開発では、同じアプリの一部を切り替えてPoCを行えます。
WebSocketや組み込み性、メモリ効率を重視するなら、Jettyを候補にします。一方で、既存の運用標準やライブラリ互換性を優先するなら、Tomcatも比べます。
古いJetty 9・10・11を使い続けても問題ありませんか？
Jetty公式の互換表では、9.4、10、11がEOLとされています。長期運用を前提に使い続けるなら、慎重に判断する必要があります。
すぐに切り替えられない場合は、影響するCVEや依存ライブラリを整理します。JDKやServlet APIの版、保守契約、移行期限も、あわせて確かめます。
隔離や監視、緊急パッチ、段階移行でリスクを管理します。12系へ上げる場合は、Java 17への対応と`javax`から`jakarta`への変更があり得るため、先に互換性のPoCを行います。
Jettyのシステム開発はどの会社に依頼すればよいですか？
Jettyコアの調査や商用サポートが必要な場合は、開発やサポートを手がける専門事業者が候補になります。
要件定義や既存連携、データ移行まで任せる選択肢もあります。クラウド運用や利用定着まで含めて任せる場合は、Java／Spring Bootと業務システム開発に実績がある国内SIerや開発会社を比べます。
会社名だけで決めず、担当者や、CVE発生時の通知・評価・修正時間、設定やSBOMの納品範囲を確かめます。
まとめ：運用まで逆算するJettyのシステム開発
Jettyは業務機能と混同せず、業務要件とJavaアプリを一つの計画にまとめます。データ、インフラ、保守も、同じ計画に含めます。
要件整理では業務フローと非機能要件を決め、選定ではEmbeddedかスタンドアロンかを比べます。設計・開発では、版と設定を管理します。
負荷・障害・セキュリティの試験や移行リハーサルは、見積もりに含めます。切り戻しと利用定着も、同じ見積もりに入れておきます。
着手前に確認する5つの項目
着手前に確認する項目は、次の5つです。
- 範囲：Jettyと業務アプリの役割
- 版：Java、Jetty、Jakarta EE
- 負荷：ピーク負荷と停止許容時間
- 移行：データ移行とマスタの責任者
- 運用：脆弱性対応、監視、バックアップの担当
5項目が曖昧なまま進むと、開発の終盤に仕様変更や追加費用が起きやすくなります。
最初の一歩：1業務のPoC
Jetty本体の費用と、業務システム全体の予算は分けて把握します。そのうえで、規模に応じた推定額を確かめます。
- Jetty本体：ライセンス費用は原則0円
- 小規模：300万〜800万円
- 中規模：800万〜2,000万円
- 基幹連携・高可用性：2,000万〜1億円超
金額は、要件や連携、移行、試験、運用条件によって変わります。同じ前提で複数社に見積もりを依頼し、更新責任や脆弱性対応、クラウド費を分けて比べます。障害対応と納品文書の範囲も、比較の対象にします。
まず、現行業務と利用者数、ピーク負荷を洗い出します。Jetty・JDKの版、外部連携、移行データも、あわせて整理します。1業務のPoCを行うと、判断の材料がそろいます。
Jetty 12系やJava 17、Jakarta EEへの移行が関わる場合は、互換性の調査を初期工程に置き、段階的なリリースを計画します。
▼全体ガイドの記事
・Jettyのシステム開発の完全ガイド
▼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を創業。