Jettyのシステム開発は、Jettyを業務アプリそのものと考えず、Javaアプリケーションを安全に動かすWebサーバー/Servletコンテナとして設計することが出発点です。
本記事では、Jettyを採用した業務Webシステムの進め方を、要件整理、技術選定、設計・開発、テスト、稼働、定着の6フェーズに分けて解説します。費用相場、見積書で確認すべき項目、Jetty 12・Java 17・Jakarta EEへの移行判断、発注者側のチェックリストまで、実務で使える形に整理します。
▼全体ガイドの記事
・Jettyのシステム開発の完全ガイド
Jettyのシステム開発とは?まず全体像を把握します

Jettyのシステムとは、利用者のブラウザや外部APIから届いたリクエストを受け付け、Javaで作った業務アプリケーションを実行する仕組みです。典型的には「利用者→CDN/WAF→ロードバランサー→Jetty→Javaアプリ→データベース・外部業務システム」という構成になります。Jettyの採用判断だけでなく、業務ルール、データ、セキュリティ、運用体制を一体で決めることが重要です。
Jettyは業務パッケージではなく実行基盤です
販売管理、在庫管理、申請・承認、予約、社内ポータルといった業務機能は、Spring Boot、Jakarta EE、独自Javaアプリケーションなどで実装します。JettyはHTTP通信、Servlet実行、セッション、WebSocketなどを担当するため、「Jettyを入れればシステムが完成する」という関係ではありません。この役割分担をRFPや提案書の冒頭で明確にしないと、アプリ開発費、データベース費、クラウド費、保守費が見積もりから抜けやすくなります。
採用判断は性能だけでなく運用条件で決めます
Jettyはメモリ効率やスケーラビリティを重視したWebサーバー/Servletコンテナで、HTTP/1.1、HTTP/2、HTTP/3、WebSocketに対応します(出典: Eclipse Jetty公式ドキュメント、2026年8月確認)。Spring Bootでは`spring-boot-starter-jetty`を使って組み込み型サーバーを選べるため、実行可能JARやDockerで配布する新規システムに向いています。一方、既存のWARを段階移行したい場合はスタンドアロンJettyを使うなど、既存資産と運用スキルを含めて判断する必要があります。
バージョンは、原則としてJetty 12系を起点に検討します。Jetty公式の互換表では、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:要件整理で業務と非機能を言語化します
最初に、誰が、いつ、どのデータを使い、どの判断を行うのかを業務フローで整理します。ログイン、権限、申請・承認、検索、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でなければ満たせない条件を明確にします。
選定時は、1秒未満などの目標応答時間を置くだけでなく、想定リクエスト数、同時接続数、WebSocket接続数、メモリ使用量をPoCで測定します。`$JETTY_HOME`と`$JETTY_BASE`を分けて設定を環境ごとに管理できるか、HTTP/2やTLSをロードバランサーとどう分担するか、ログを何日保管するかも確認します。Jettyの直接実績がない会社に依頼する場合は、担当者の経験、脆弱性対応の手順、ソースコードと設定の引き渡し範囲を面談で確かめます。
フェーズ3:設計・開発で役割分担と設定を固定します
基本設計では、画面・API・DB・権限・外部連携・エラー処理・監視の全体像を定めます。Jettyの設定はコードや構成管理に置き、開発、検証、本番で何が変わるかを表にします。TLS証明書、秘密情報、セッション、アクセスログ、JMX、ヘルスチェック、タイムアウト、コネクションプールなどを「初期設定のまま」にせず、責任者と変更手順まで決めることが重要です。
実装は、最初から全機能を作るのではなく、ログインから1業務の登録・承認・検索までを縦に通すスライスを作ります。小規模なPoCでJetty、JDK、Spring Boot、DB、認証、リバースプロキシを接続し、実際のデータ量に近い条件で動かします。既存Jettyから12系へ移行する場合は、`javax`と`jakarta`の名前空間、依存ライブラリ、JSP、フィルター、セッション、カスタムHandlerを一覧化し、互換性問題を実装後まで持ち越さないようにします。
フェーズ4:テストで機能・性能・安全性を検証します
テストは単体、結合、総合、受入の順に進めます。Jetty案件では、通常の画面テストだけでなく、同時接続数を増やした負荷試験、長時間のWebSocket接続、HTTP/2やTLSの設定、タイムアウト、異常切断、再起動、ログ出力、バックアップからの復旧を確認します。目標値は「速い」ではなく、ピーク時の同時利用者数、95パーセンタイルの応答時間、エラー率、CPU・メモリ上限など、測定可能な数値で定義します。
セキュリティでは、認証・認可、Cookie、CSRF、入力値検証、秘密情報の保護、不要なHTTPヘッダー、アクセスログのマスキング、脆弱性スキャンを確認します。Jetty公式のセキュリティ情報では、2026年4月に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、クラウド、監視、セキュリティ診断、移行、保守、商用サポートが総額を決めます。
規模別の初期費用は300万〜1億円超まで幅があります
Jettyを組み込んだJava業務Webシステムの初期費用は、機能数、連携数、移行データ、可用性、試験範囲によって大きく変わります。目安として、小規模な社内向けで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のシステム開発では、安い見積もりを選ぶより、同じ前提条件で比較できる見積もりを作ることが重要です。Jettyの導入作業だけを切り出すと安く見えますが、業務要件、連携、移行、性能試験、運用設計が別途になると、後から追加費用が増えます。RFPには、機能一覧と非機能要件を含め、提案会社が不足情報をどのように扱ったかも記録します。
要件・成果物・前提条件を見積書に反映します
見積依頼時には、業務フロー、画面一覧、帳票一覧、外部連携先、データ件数、利用者数、権限区分、ピーク時間、目標応答時間、稼働時間、バックアップ要件、セキュリティ基準を渡します。既存システムがある場合は、Javaのバージョン、Jettyのバージョン、WARか組み込みか、`javax`利用の有無、設定ファイル、ログ、依存ライブラリ、既知の障害を棚卸しします。情報が足りない場合は、調査・PoCを先行するフェーズを見積もりに分けます。
成果物は、要件定義書、構成図、画面・API仕様、DB定義、JettyとJDKのバージョン表、設定ファイル、ソースコード、テスト仕様書、性能試験結果、移行手順、運用手順、監視設計、バックアップ・復旧手順、SBOM、脆弱性対応手順まで確認します。納品物が「実行ファイル一式」だけでは、担当者が交代したときに設定変更や障害対応ができず、ベンダーロックインの原因になります。
発注先はJettyの経験と業務・運用の対応力で選びます
候補会社には、(1)Jettyのバージョンアップ実績、(2)Java 17とJakarta移行経験、(3)HTTP/2・WebSocketの負荷試験経験、(4)脆弱性情報の通知と修正時間、(5)ソースコード・設定・SBOMの納品範囲、(6)クラウド費と保守費の分離、(7)データ移行で発注者に求める作業を質問します。「Jetty対応可能」という一文ではなく、実際の担当者、過去の構成、障害時の一次対応、SLAを具体的に確認します。
Jettyコアの調査や商用サポートを重視するならWebtideのような専門事業者が候補になります。国内で要件定義、業務連携、移行、クラウド運用まで任せたい場合は、Java/Spring Bootとクラウドに実績があるSIerや開発会社を比較します。ただし、公開情報からJettyの直接案件まで確認できるとは限りません。提案時にJettyを専門会社と協業するのか、自社で保守するのか、契約上の責任分界を明記してもらいます。
追加費用になりやすいリスクを先に洗い出します
見積もりが膨らみやすいのは、要件凍結後の追加要求、マスタ未整備、外部APIの仕様変更、性能要件の後出し、古いJDKやJettyの移行、セキュリティ診断での改修、データ移行の品質問題です。各リスクについて、発生条件、影響範囲、予備費、意思決定者、対応期限を表にします。特にマスタデータは発注者側の業務知識が必要なため、開発会社だけで整備できる前提にしないことが大切です。
コストを抑えるときは、テストや監視を削るのではなく、最初のリリース範囲を絞ります。まず1部門・1業務で認証、主要処理、ログ、バックアップまで通し、利用状況を確認してから連携や高度な分析を追加します。PoC、開発、検証、本番の環境差分を小さくし、設定をコード管理することも、将来の障害調査と更新費用を抑える有効な方法です。
Jettyのシステム開発でよくある質問

最後に、Jettyのシステム開発を検討する企業からよく寄せられる質問に回答します。技術の選択だけでなく、費用、既存システムとの互換性、運用責任を判断する材料としてご覧ください。
Jetty本体のライセンス費用はいくらですか?
JettyはEPL v2またはApache License v2で商用利用・配布できるOSSのため、Jetty本体の商用ライセンス購入費は原則0円です。ただし、開発、クラウド、監視、脆弱性対応、保守、商用サポートは別に必要です。費用はJetty単体ではなく、業務システム全体の初期費用と運用費で比較します。
JettyとTomcatはどちらを選べばよいですか?
どちらが常に優れているわけではなく、既存資産、開発者の経験、必要なプロトコル、運用体制で決めます。Spring BootはEmbedded JettyとEmbedded Tomcatの両方をサポートしているため、新規開発では同じアプリの一部を切り替えてPoCできます。WebSocketや組み込み性、メモリ効率などが重要ならJettyを候補にし、既存の運用標準やライブラリ互換性を優先するならTomcatも比較します。
古いJetty 9・10・11を使い続けても問題ありませんか?
Jetty公式の互換表では、Jetty 9.4、10、11はEOLとされているため、長期運用を前提に使い続けるのは慎重な判断が必要です。直ちに切り替えられない場合は、影響するCVE、JDK、Servlet API、依存ライブラリ、保守契約、移行期限を整理し、隔離、監視、緊急パッチ、段階移行でリスクを管理します。Jetty 12系へ上げる場合はJava 17化と`javax`から`jakarta`への変更が発生し得るため、先に互換性PoCを実施します。
Jettyのシステム開発はどの会社に依頼すればよいですか?
Jettyのコア技術に関する調査や商用サポートが必要なら、Jettyの開発・サポートに関わる専門事業者を候補にします。業務要件定義、既存システム連携、データ移行、クラウド、利用定着まで一括で任せたい場合は、Java/Spring Bootと業務システム開発の実績がある国内SIerや開発会社を比較します。会社名よりも、誰がJettyを担当し、CVE発生時に何時間以内に通知・評価・修正するのか、設定やSBOMを納品するのかを確認することが重要です。
まとめ:Jettyのシステム開発は運用まで逆算して進めます

Jettyのシステム開発を成功させるポイントは、Jettyを業務機能と混同せず、業務要件、Javaアプリ、データ、インフラ、保守を一つの計画にまとめることです。要件整理では業務フローと非機能要件を決め、選定ではEmbeddedかスタンドアロンかを比較し、設計・開発ではバージョンと設定を管理します。さらに、負荷・障害・セキュリティ試験、移行リハーサル、切り戻し手順、利用定着までを見積もりに含めます。
着手前に確認する5つの項目をそろえます
着手前は、(1)Jettyが担う範囲と業務アプリの範囲、(2)Java・Jetty・Jakarta EEのバージョン、(3)ピーク負荷と停止許容時間、(4)データ移行とマスタの責任者、(5)脆弱性対応・監視・バックアップの担当を確認します。この5項目が曖昧なまま進めると、開発終盤に仕様変更や追加費用が発生しやすくなります。
最初は1業務のPoCから始めて判断します
Jetty本体のライセンス費用が原則0円でも、システム全体の費用は小規模300万〜800万円、中規模800万〜2,000万円、基幹連携・高可用性で2,000万〜1億円超というように幅があります。金額は推定レンジであり、要件、連携、移行、試験、運用条件によって変わります。複数社から同じ前提で見積もりを取り、Jetty・JDKの更新責任、脆弱性対応、クラウド費、障害対応、納品ドキュメントを分けて比較することが、将来の追加費用とベンダーロックインを防ぎます。
まずは現行業務の流れ、利用者数、ピーク負荷、既存JettyとJDKのバージョン、外部連携、移行データを棚卸しし、1業務を対象にPoCを行うと判断しやすくなります。Jetty 12系、Java 17、Jakarta EEへの移行が関係する場合は、互換性調査を初期工程に置き、無理のない段階リリース計画を立てます。
▼全体ガイドの記事
・Jettyのシステム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>


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