Jettyのシステム開発の完全ガイド - ブログ

Jettyのシステムとは、JettyをWebサーバーまたはServletコンテナとして組み込み、Javaアプリケーションで業務機能を動かすWebシステムです。Jetty自体が販売管理や在庫管理の業務パッケージではないため、業務要件、アプリケーション、データベース、運用設計までを一体で考えることが重要です。

本記事では、Jettyの役割と種類、Tomcatなどとの違い、業務システムの構成、開発の進め方、2026年時点の費用相場、開発会社・ベンダーの選び方、移行・セキュリティ・保守の注意点までを完全ガイドとして解説します。Jettyを採用すべきか迷っている方や、既存のJavaシステムを刷新したい方が、発注前に確認すべき項目まで整理できます。

Jettyのシステムとは何ですか？

Jettyのシステムは、利用者からのHTTPリクエストを受け付け、Javaで作られた業務アプリケーションへ渡し、処理結果をブラウザや外部サービスへ返す仕組みです。Jettyが担当するのは通信、Servletの実行、セッション、WebSocketなどのWeb実行基盤であり、受注、承認、在庫、請求といった業務ルールはアプリケーション側に実装されます。

Jettyは業務アプリケーションを動かす実行基盤です

業務システムを建物にたとえると、Jettyは人が操作する画面そのものではなく、受付や通路、処理室を動かすための基盤にあたります。画面はHTMLやJavaScript、業務処理はJavaやSpring Boot、データはデータベースが担い、JettyがそれらをHTTPで利用者に届けます。そのため、Jettyを採用するだけで業務システムが完成するわけではありません。

Jetty公式ドキュメントでは、Jetty 12は高いスケーラビリティとメモリ効率を重視したWebサーバー・Servletコンテナとして説明されています。HTTP/1.1、HTTP/2、HTTP/3、WebSocketに対応し、単独サーバーとしてWARを配備する方法と、アプリケーションのライブラリとして組み込む方法を選べます（出典: Jetty公式ドキュメント、2026年8月確認）。

Tomcatと比べるときは性能だけでなく運用条件を見ます

JettyとTomcatのどちらが常に優れているという関係ではありません。TomcatはServletコンテナとしての採用事例が多く、既存の運用手順や知見を活かしやすい場合があります。一方、Jettyは必要なモジュールだけを有効化しやすく、組み込み型の構成やWebSocketを使うリアルタイム画面、複数のHTTPプロトコルを扱う構成で候補になりやすいです。

比較では、ベンチマークの数字だけで決めず、利用者数、ピーク時の同時接続数、レスポンスの許容時間、JDKのバージョン、既存ライブラリ、運用担当者の経験を並べます。同じアプリケーションでも、データベースの遅延や外部APIの応答時間がボトルネックになることがあるため、Jettyだけを変えても体感性能が改善しないケースがあります。

Jettyを使った業務システムの種類と構成

Jettyは特定の業務領域に限定されないため、社内ポータル、申請・承認、予約、顧客管理、販売管理、現場報告、リアルタイムダッシュボードなどに組み込めます。選択のポイントは、Jettyをどう配置するかと、業務データをどのシステムと連携するかを切り分けることです。

Embedded Jettyは小さく始める業務Webシステムに向きます

Embedded Jettyは、JavaアプリケーションにJettyをライブラリとして組み込み、実行可能なJARやコンテナイメージとして配備する方式です。申請画面、簡易な管理画面、社内向けAPI、予約受付など、アプリケーションと実行基盤を一つのデプロイ単位で管理したい場合に適しています。

Spring Bootでは、標準の組み込みサーバーをJetty用のスターターへ差し替えられます。公式ドキュメントでも、Servletアプリケーション向けに組み込みTomcatとJettyの両方をサポートしていると説明されています（出典: Spring Boot公式リファレンス、2026年8月確認）。ただし、JSPの利用や既存WARの移植では、実行可能JARではなくWAR配備が必要になる場合があるため、画面技術と配備方式を早めに確認します。

スタンドアロン型は複数環境と既存WARを管理しやすいです

スタンドアロン型では、Jettyをサーバーとして稼働させ、その上にWAR形式のWebアプリケーションを配備します。既存のServletアプリケーションを段階的に移行したい場合や、開発・検証・本番でアプリケーションとサーバー設定を分けたい場合に使いやすい方式です。

Jettyでは、バイナリや標準設定を置く`$JETTY_HOME`と、環境ごとの設定やWebアプリケーションを置く`$JETTY_BASE`を分離できます。分離しておけば、Jettyを更新するときに本番固有のポート、TLS、ログ、配備設定を上書きしにくくなります。設定ファイルをバージョン管理し、差分をレビューできる状態にしておくことが、長期運用の重要なポイントです。

基本構成は利用者からデータベースまでを一続きで設計します

典型的な構成は、利用者、CDNやWAF、ロードバランサー、Jetty、Javaアプリケーション、データベース、外部の業務システムという流れです。認証はアプリケーションだけに任せず、ネットワーク境界、管理画面のアクセス制御、セッション管理、監査ログまでを一つの設計として扱います。

リアルタイム通知を使う場合はWebSocketの接続数、切断時の再接続、複数台構成でのセッション共有を確認します。HTTP/2やHTTP/3を有効にする場合も、ブラウザからJettyまでのすべての経路が対応しているとは限らないため、ロードバランサー、TLS終端、監視ツールを含む実環境に近い検証が必要です。

Jettyのシステム開発の進め方

Jettyを採用する案件では、サーバーの選定を先に決めすぎないことが大切です。業務の現状、データ、利用者、連携先、停止許容時間を整理し、その条件を満たす実行基盤としてJettyを評価します。以下の順序で進めると、サーバー選定と業務要件の食い違いを抑えられます。

▶ 詳細はこちら：Jettyのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

要件定義では業務フローと非機能要件を固めます

最初に、誰が、いつ、どのデータを使い、どの判断をするのかを業務フローにします。申請の差し戻し、在庫の引き当て、締め処理、権限変更、例外的な手入力など、通常業務から外れる処理を後回しにしないことが重要です。現場で使われている表計算、CSV、メール、紙の記録も確認すると、移行対象や自動化の範囲を正しく見積もれます。

同時に、利用者数、ピーク時同時接続数、1時間あたりの処理件数、レスポンスタイム、稼働時間、障害復旧目標、データ保持期間を数値化します。Jettyの設定を決めるには、通常時ではなく月末やキャンペーン時などのピーク条件が必要です。認証方式、監査ログ、バックアップ、暗号化、脆弱性対応の責任分界も要件定義書に記載します。

PoCと設計で採用理由を実測します

要件が整理できたら、重要なリスクを小さなPoCで検証します。たとえば、既存のJavaライブラリがJetty 12と動くか、`javax.servlet`から`jakarta.servlet`への移行でどの範囲が変わるか、WebSocketを複数台で扱えるか、外部APIの遅延が画面にどう影響するかを確認します。

設計書には、利用者からデータベースまでの構成図、通信経路、ポート、TLS証明書、認証・認可、ログ、バックアップ、監視項目を残します。クラウド、コンテナ、Kubernetesを使う場合は、Jettyの設定だけでなく、イメージの更新、Secretの管理、Ingress、ネットワークポリシー、オートスケールの条件まで設計対象に含めます。

テスト・移行・リリースを分けて段階稼働します

テストは機能テストだけで終わらせず、負荷、長時間稼働、障害復旧、脆弱性、権限、ログ、バックアップ復元を行います。WebSocketを使う場合は、接続数が増えたときのメモリ使用量、再接続、サーバー切り替え後の状態を確認します。HTTP/2やHTTP/3を使う場合も、通信方式を有効にした状態で測定します。

データ移行では、発注者側が持つマスタの重複、表記揺れ、欠損、過去データの扱いを先に決めます。本番移行の前に、件数照合、金額照合、権限照合、業務担当者によるサンプル確認を含むリハーサルを実施します。リリース後は一度に全社展開せず、対象部門を限定し、問い合わせと性能を確認してから段階的に広げる方法が安全です。

Jettyのシステム開発にかかる費用相場

Jetty本体はオープンソースで、公式ドキュメント上はEclipse Public License v2またはApache License v2により商用利用・配布が可能です。そのため、Jettyの商用ライセンス購入費は原則として0円ですが、業務システム全体が無料になるわけではありません。開発、データベース、クラウド、監視、セキュリティ対策、移行、保守が費用の中心になります。

▶ 詳細はこちら：Jettyのシステム開発の見積相場や費用/コスト/値段について

初期費用は規模と連携数で大きく変わります

Jettyを含むJava業務Webシステムの初期費用は、次のレンジを目安にすると検討しやすいです。小規模の社内向けシステムは300万〜800万円程度で、ログイン、申請・承認、一覧・検索、CSV出力、簡易管理画面を想定します。開発期間は2〜4か月程度です。

中規模の業務Webシステムは800万〜2,000万円程度で、顧客・商品・権限管理、帳票、外部API、既存データベース連携、監査ログ、複数ロールを含む想定です。開発期間は4〜8か月程度です。ERP、WMS、会計、決済などの基幹連携や高可用性を求める場合は、2,000万円〜1億円超、8〜18か月以上になる可能性があります。

2026年に公開された国内の業務システム開発費用情報では、小規模なスクラッチ開発を100万〜300万円、中規模を300万〜800万円、中〜大規模を800万円〜数千万円とする目安も示されています（出典: 2026年公開の国内業務システム開発費用相場情報）。本記事のレンジは、Jettyの実行基盤に加え、Java 17対応、認証、監査ログ、負荷試験、クラウド運用、既存システム連携まで含む発注を想定した編集上の推定です。

見積書では開発費と運用費を分けて確認します

初期費用の内訳は、要件定義10〜15%、基本設計15〜20%、詳細設計10〜15%、実装・単体テスト30〜40%、結合・総合テスト15〜20%、移行・導入5〜10%を一つの確認基準にできます。実際の割合は案件によって異なりますが、実装費だけが大きく、要件定義や移行が極端に少ない見積書には注意が必要です。

Jetty特有の費用として、HTTP/2・HTTP/3やWebSocketの負荷試験、TLS証明書と鍵の管理、リバースプロキシやロードバランサーの設定、古いJettyからの移行、`javax`から`jakarta`への変換、脆弱性調査が挙げられます。これらを「サーバー設定費」にまとめず、作業内容と成果物を明記してもらうと、複数の見積もりを比較しやすくなります。

運用費は、クラウド、監視、ログ保管、バックアップを含めて小〜中規模なら月額5万〜50万円程度が一つの推定レンジです。24時間監視、冗長化、大量データ、商用サポートを含めると月額50万〜数百万円になる場合もあります。開発費3,000万円に保守比率15〜20%を適用すると、年間450万〜600万円が初期検討の目安になりますが、脆弱性対応、障害対応、JDK更新、アプリ改修、クラウド利用料を分けて見積もることが重要です。

開発会社/ベンダーの選び方

Jettyに対応できるという説明だけでは、業務システムを安全に稼働させられるとは限りません。Javaアプリケーションの設計、データ移行、クラウド、監視、脆弱性対応、障害時の連絡体制までを一貫して確認し、提案内容と担当者の経験を見極めます。

JettyとJava移行の実績を具体的に確認します

確認したいのは、単にJavaを使った経験があるかではありません。Jettyのバージョンアップ、Java 17への移行、Servlet APIの変更、`javax`から`jakarta`への切り替え、既存WARの移植、WebSocketやHTTP/2の試験を、誰がどの範囲まで担当したかを聞きます。実績を出せない場合は、PoCや技術検証を契約前の有償作業として提案できるかも判断材料になります。

Jetty公式のバージョン表では、Jetty 12.0.xはJava 17およびJakarta EE 10・9・8に対応する安定系列とされ、12.1.xはJava 17およびJakarta EE 11・10・9・8に対応する系列として整理されています。Jetty 9.4、10、11はEOLとされているため、既存システムのバージョン表と依存ライブラリを提出して評価できるパートナーを選びます（出典: Jetty公式ドキュメント、2026年8月確認）。

提案書は技術・費用・引き継ぎを同じ条件で比べます

複数の提案を比較するときは、機能一覧だけでなく、前提条件、対象外、想定利用者数、性能目標、移行件数、テスト範囲、納品物、保守時間を同じ様式で並べます。安い提案でも、負荷試験や運用設計が対象外なら、稼働直前に追加費用が発生する可能性があります。

RFPには、Jettyのバージョンと選定理由、JDK、Servlet API、配備方式、コンテナ利用の有無、TLS終端の場所、ログの保存期間、CVE発生時の通知時間、パッチ適用の承認者を記載します。さらに、ソースコード、設定ファイル、依存関係一覧、SBOM、テスト結果、運用手順、障害時の連絡網を納品対象に含めると、特定の担当者に依存しにくくなります。

保守範囲とSLAを契約前に決めます

保守契約では、「Jettyの保守」という一言を分解します。脆弱性情報の監視、影響判定、パッチ作成、検証環境への適用、本番適用、障害の一次切り分け、JDKやOSの更新、アプリケーション改修、クラウド費用が、それぞれ含まれるかを確認します。重大度ごとの初動時間、復旧目標、夜間休日の受付、再委託の有無も明文化します。

2026年には、Jetty公式のセキュリティ情報で、4月11日公開の高リスク脆弱性について12.0.33以前や12.1.7以前などが影響対象とされ、12.0.34および12.1.8などが修正版として示されました（出典: Jetty公式セキュリティ情報、2026年8月確認）。OSSはライセンス費用を抑えられても、更新情報を受け取り、検証し、止めずに適用する体制が必要です。

▶ 詳細はこちら：Jettyのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：Jettyのシステム開発の発注/外注/依頼/委託方法について

運用・セキュリティで失敗しないチェックポイント

Jettyのシステムは、公開後の運用設計によって安全性と費用が大きく変わります。開発時に動いたことだけを確認するのではなく、更新、障害、バックアップ、監査、担当者交代までを日常業務として回せる状態にします。

バージョンと脆弱性を継続的に管理します

本番環境のJetty、JDK、OS、コンテナイメージ、Java依存ライブラリを一覧化し、担当者、現行バージョン、更新期限、検証環境を紐づけます。EOL版を使っている場合は、短期的な延命、計画的なメジャーアップデート、商用の長期サポートのどれを選ぶかを、業務停止の許容度と費用で比較します。

外部公開する場合は、TLSの設定、不要なHTTPメソッドの制限、管理用ポートの分離、認証失敗の監視、アクセスログの改ざん防止を確認します。IPAの2026年版中小企業向けガイドラインでは、従来の対策に加えてバックアップや安全なWebサイト運用、サプライチェーンを意識した対策が拡充されています（出典: IPA「中小企業の情報セキュリティ対策ガイドライン」第4.0版、2026年）。Jetty単体の設定だけでなく、組織の運用ルールまで整えることが大切です。

監視とバックアップは復旧手順まで試験します

監視項目は、プロセスが動いているかだけでは不十分です。HTTPの応答、エラー率、レスポンスタイム、CPU、メモリ、スレッドプール、接続数、データベース接続、ディスク、証明書の有効期限を、利用者への影響と結びつけて監視します。アラートの通知先と一次対応者を決め、誤通知が多い項目は定期的に見直します。

バックアップは取得した事実ではなく、復元できることが重要です。データベース、設定ファイル、秘密情報の復旧方法を分けて記録し、目標復旧時間と目標復旧時点を満たすかを定期的に確認します。障害時に誰が判断し、どの機能を止め、どの順番で復旧するかを手順書にし、担当者が変わっても訓練できる状態にしておきます。

よくある失敗を先回りして防ぎます

失敗例の一つは、Jettyの採用を先に決め、業務フローやデータ移行を後回しにすることです。要件凍結後に例外処理が大量に追加されると、画面だけでなく権限、データ構造、テスト範囲が広がります。最初から現場担当者を交えて、標準化できる業務と残すべき例外を分けます。

二つ目は、OSSの費用が無料であることを、保守不要と誤解することです。バージョンアップ、CVEの影響確認、依存ライブラリの更新、ログ監視、障害復旧には継続的な作業が発生します。三つ目は、設定やソースコードの納品が不十分で、担当者が退職した後に変更できなくなることです。ドキュメント、SBOM、手順書、テスト結果を契約と受け入れ条件に組み込むことで防ぎやすくなります。

よくある質問

最後に、Jettyのシステムを検討する方から寄せられやすい質問に回答します。採用判断では、Jetty単体の機能だけでなく、既存資産、将来の更新、業務停止の許容度、社内の運用体制を合わせて判断します。

Jettyは商用システムで無料で使えますか？

Jettyは公式に定められたオープンソースライセンスの範囲で、商用利用・配布が可能です。ただし、業務アプリケーションの開発費、クラウド費、監視、セキュリティ対応、保守費は別に発生します。利用する追加ライブラリのライセンスも確認し、システム全体の一覧を作成してください。

既存のJetty 9・10・11から移行したほうがよいですか？

既存環境の業務影響を確認したうえで、原則としてEOL版を長期利用し続けない計画を立てます。Jetty 12ではJava 17やJakarta EEへの対応が関係するため、依存ライブラリ、JSP、認証、独自拡張、テストコードを棚卸しし、まず検証環境で移行可否を確認します。すぐに移行できない場合も、期限、暫定的な脆弱性対応、予算、段階移行の責任者を決めることが重要です。

Jettyのシステムはクラウドやコンテナで運用できますか？

運用できます。実行可能JARやコンテナイメージとして配備し、ロードバランサー、監視、ログ、Secret、バックアップをクラウド側のサービスと組み合わせる構成が一般的です。PaaSを使う場合は、対応Javaバージョン、Servletの世代、WARとJARの制約、ランタイムの更新期限を確認します。PaaSの標準ランタイムに任せる範囲と、Jettyを自分で管理する範囲を明確にしてください。

小規模なJettyのシステムはいくらで作れますか？

社内向けのログイン、申請・承認、検索、CSV、管理画面に限定するなら、初期費用300万〜800万円、開発期間2〜4か月程度が一つの目安です。ただし、既存データの移行、複数システムとの連携、厳格な監査ログ、24時間運用、WebSocketの高負荷対応が加わると上振れします。要件と対象外を明確にしたうえで、複数の見積もりを同じ条件で比較してください。

まとめ

Jettyのシステムは、JettyをWebサーバーまたはServletコンテナとして採用し、Javaアプリケーションで業務機能を実現する仕組みです。Jetty本体のライセンス費用は抑えられますが、業務要件、データ連携、認証、性能、移行、クラウド、保守を含めた総額で判断する必要があります。

採用判断では業務要件と技術要件を一緒に確認します

新規開発では、Embedded Jetty、スタンドアロン、コンテナ、PaaSなどを、利用者数と運用体制に合わせて比較します。既存システムでは、JettyとJDKのバージョン、`javax`と`jakarta`、依存ライブラリ、WARやJSP、認証、監視を棚卸しし、PoCで移行リスクを確かめます。Jettyを選ぶ理由を、メモリ効率、組み込み性、WebSocket、既存Java資産などの具体的な条件で説明できる状態にします。

発注前に見積条件と保守責任を文書化します

費用は小規模で300万〜800万円、中規模で800万〜2,000万円、基幹連携や高可用性を含む大規模で2,000万〜1億円超を一つの推定目安にできます。最終的な金額は、連携数、データ移行、非機能要件、テスト、運用時間で変わります。見積書ではJettyの設定、脆弱性対応、JDK更新、障害対応、クラウド費、納品ドキュメントの範囲を分け、稼働後の責任分界まで確認してください。