Jakarta EEのシステム開発の完全ガイド

Jakarta EEのシステムは、Web画面・API、業務データ処理を組み合わせて作ります。長期運用や高可用性が求められる業務に活用できます。

全体は、構成、Java EEからの移行、開発工程、費用、発注先の選び方の順に押さえられます。各テーマの詳しい内容は、次の関連記事でご覧いただけます。

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

Jakarta EEのシステムの全体像

Jakarta EEは、旧Java EEを引き継ぐ企業向けJavaの標準仕様群です。画面やAPIに加え、業務ロジック、データ永続化、認証・認可の共通APIを定めています。さらに、トランザクションや非同期処理、メッセージングの共通APIも含まれます。

仕様と実行基盤の違い

Jakarta EEが指すのは、標準APIと実行モデルです。業務システムそのものや、特定のアプリケーションサーバーを指す言葉ではありません。

開発時には、対応する実行基盤、Javaランタイム、データベースを組み合わせます。認証基盤や監視基盤も、そこに加わります。そのため、仕様に準拠する部分と基盤固有の設定を分けておくと、サーバー変更やクラウド移行を比べやすくなります。

向いている業務システム

採用の判断は、業務の内容に加えて、長期運用や環境移行の要件にも左右されます。Jakarta EEが向いている業務は、性質の異なる4つの場面に分けられます。

業務管理：販売、顧客・会員、受発注、在庫、決済。
社内・基幹等：社内ポータル、基幹連携、公共・金融系の大規模業務アプリ。
一貫した処理：複数業務を一つのトランザクションで管理したい場合。
長期運用・移行：長期保守や複数環境への移行余地を重視する場合。

短期のキャンペーンサイトや、データ登録がほとんどない小規模な画面なら、全機能を採用しなくても構いません。

Web ProfileやCore Profileのように必要な仕様だけを選ぶと、学習範囲と運用負担を抑えやすくなります。

Jakarta EEのシステムの種類と主な構成要素

業務の中心に合わせて、使う機能やProfileを選び分けます。

システム構成は、業務規模に加えて、Profileや画面とAPIの比重、既存システムとの連携方式、データ量、可用性といった業務要件で決まります。

開発では、最初から全仕様を組み込まず、業務要件から必要な機能を逆算して選びます。

Web画面・REST API中心の業務システム

社内ポータルや申請・承認、顧客管理、受発注画面などを構築する構成です。

Servlet、Pages、Facesといった画面向けの仕様と、RESTful Web ServicesやJSON処理といったAPI向けの仕様を組み合わせます。Validationなどの入力検査も加わります。

画面の利用者と外部システムの両方がある場合は、画面用の処理とAPI用の処理を分けます。APIでは、バージョン管理とエラー形式を決めておきます。加えて、タイムアウトと再送条件の決め方も確認しておきます。

データ・トランザクション中心の基幹システム

受発注や在庫、請求の処理では、Persistence、Transactions、Validation、CDIなどを中心に構成します。決済や会計連携も、この構成で扱います。複数テーブルを正確に更新する業務に使います。

一つのトランザクションに含める処理や、失敗時に戻す範囲、二重登録の防ぎ方は、業務ルールに沿って決めておきます。

大量処理や定時処理にはBatch、Messaging、Concurrencyを使います。また、処理の再実行や途中再開も設計します。

Profileと実行基盤の選び方

画面やAPIの用途に合うProfileを選び、必要な仕様と運用負担のバランスを取ります。

Web Profile：Web画面やAPIを中心とする比較的軽量な構成。
Core Profile：マイクロサービスやAPIなど、必要最小限の機能に絞る場合の候補。
Platform相当：既存企業システムとの互換性や高度な業務処理を重視する構成。

実行基盤は、オンプレミスや仮想マシン、コンテナなどから選びます。Kubernetesやマネージドコンテナも候補に入ります。判断には、開発費以外の運用条件も含めます。

障害時の切り分けを誰が担当するか、ログを何日保存するかを決めておきます。バックアップの復元確認をどの頻度で行うか、基盤のサポート期限はいつかも確認します。

ポイント

業務の中心が画面・APIか、データ処理や基幹の更新かで、使う機能とProfileの組み合わせが変わります。既存システムとの連携方式とデータ量も、構成を決める材料になります。

Jakarta EE 11の最新動向とJava EEからの移行ポイント

Jakarta EE 11は2025年6月26日に一般提供されました。公式リリース情報では、Java SE 17以上を前提としています。

Jakarta EE 11には、Java 21のVirtual Threadsを活用するConcurrencyの強化や、データアクセスを簡素化するJakarta Dataが含まれます。また、互換性の検証は、JUnit 5とMavenを中心に整理されています。

新規開発をするなら、2026年時点では実行基盤の対応状況を確認して候補に加えます。

Jakarta EE 11で確認したい機能と互換性

Jakarta EE 11では、新しく追加・強化された機能と、利用する実行基盤での提供状況を分けて見ます。

Jakarta Data：CRUD、ページング、リポジトリを共通化し、定型コードを減らします。
Persistence：Java Recordsや日時型の扱いが強化されました。
SecurityManager：依存が整理されています。

新機能があっても、どの実行基盤でも同じように提供されるとは限りません。そのため、採用前に対応ProfileとJavaのバージョンを確かめ、互換性検証の範囲や利用予定のAPIも確認します。

2025年のJakarta EE Developer Surveyは、1,700人超を対象にした調査です。Jakarta EEの利用率は58%と示されています（出典：The State of Enterprise Java: 2025 Jakarta EE Developer Survey Report）。また、Springの利用は56%、EE 11の採用は18%と報告されています。

これは回答者ベースの調査で、市場全体のシェアを示すものではありません。ただし、Jakarta EEが企業向けJavaの選択肢として更新されていることを確かめる材料にはなります。

Java EEから移行するときの注意点

Java EE 7や8から移行する場合は、名前空間の変更と周辺の資産を確認し、段階的に動作を検証します。

javax.*からjakarta.*への変更を確認し、影響範囲を調べます。
単純な文字列置換で完了とせず、利用しているAPIと実行基盤を一覧化します。
現行環境をバックアップし、依存関係を固定して、小さな業務機能から起動を確認します。認証、トランザクション、帳票、バッチ、外部連携、性能は回帰テストします。
切り戻し条件、旧環境とのデータ同期、段階リリースの順番を決めて、移行当日のリスクを抑えます。

この変更は、ソースコードや依存ライブラリ、XML設定、アノテーションに及ぶ場合があります。テストコードのほか、認証連携や監視エージェントにも影響することがあります。

ポイント

Jakarta EE 11を候補に入れる場合は、Java SEのバージョンと実行基盤の対応状況を先に確かめます。新機能を採用する前に、互換性検証の範囲と利用予定のAPIを照らし合わせることが大切です。

Jakarta EEのシステム開発の進め方

各段階を連続して計画すると、技術と運用の課題を早く確かめられます。

開発の成否は、業務要件と非機能要件をどこまで具体化できるかで決まります。そのため、画面やAPIからデータ、認証、連携、運用まで、一体で計画します。

要件定義から移行リハーサルまでは、一続きの工程として進めます。

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

要件定義・企画フェーズの決定事項

利用者数や処理頻度、利用データの量は、数値で押さえておきます。数値で押さえる観点は、処理規模、機能範囲、データ管理の3つです。

処理規模：利用者数、ピーク時間、同時実行数、データ量。
機能範囲：外部連携数、帳票数、権限の種類。
データ管理：保存期間と個人データの扱い。

業務目的とKPIも定めておくと、処理時間の短縮や入力ミスの削減、締め処理の早期化などを測れるようになります。

非機能要件では、可用性と復旧時間、バックアップ、監査ログを決めます。ネットワーク分離とサポート時間も、非機能要件として書き出します。さらに、Must・Should・Couldに分けておくと、限られた予算で先に実装する範囲が明確になります。

既存のJava EE資産がある場合は、移行、廃止、再構築のどれにするかを業務機能ごとに分けます。

設計・PoC・実装フェーズ

基本設計では、業務機能の境界、データモデル、APIを定義します。そのうえで、認証方式とエラー処理を決め、トランザクションの境界や外部連携、監視項目も定めます。

代表的な業務フローでPoCを行い、業務処理と運用基盤の技術的不確実性を確かめます。

業務処理：REST API、データアクセス、認証、監査ログ。
運用基盤：コンテナへのデプロイ、障害時のログ確認。

PoCでは、画面の見た目よりも、将来の運用で問題になりやすい箇所を検証します。

実装では、Mavenの依存関係、Javaランタイム、実行基盤の設定、コンテナイメージを再現できる状態にします。また、コードレビューと単体テストを、静的解析や脆弱性スキャンとあわせてCI/CDに組み込みます。

標準APIで実装する領域と、基盤固有の機能を使う領域を記録しておくと、後の移行判断に役立ちます。

テスト・リリース・運用引き継ぎ

単体試験から移行リハーサルまで、段階を追って試験を行います。試験では、次の場面を想定します。

処理異常：タイムアウト、重複送信、途中失敗、権限不足。
連携・復旧：外部サービス停止、DB復旧後の再処理。

性能試験では、平均値だけでなくピーク時の応答時間を記録します。加えて、エラー率やスループット、CPU・メモリの使用量も残します。

リリース前には、切り替え手順と切り戻し条件を確定します。連絡網や監視アラート、問い合わせ窓口も、この時点で決めておきます。

政府の「サイバーセキュリティ2025」は、経営層の責任やサプライチェーンを含む継続的な対策を示しています。そのため、開発の完了を安全対策の終点にしないことが大切です。

運用開始後は、脆弱性情報やJavaと実行基盤のサポート期限を、定例で確認します。ログ保存とバックアップ復元、権限の見直しも、定例の対象に加えます。

ポイント

工程ごとの判断は、要件定義の段階で非機能要件まで具体化できているかを基準に置くと整理しやすくなります。可用性や復旧時間、運用の条件は、設計に入る前に決めておきます。

Jakarta EEのシステム開発費用相場とコストの内訳

実装の配分が最も大きく、設計やテストにも費用を見込む構成です。

費用は、画面数や業務ルール、API・外部連携の数で変わります。Jakarta EEを採用するかどうかだけで決まるわけではありません。移行の難しさやデータ量、可用性、セキュリティ、テスト範囲、保守体制も、費用を左右します。

示す数字は、業務システム全般の相場を、Jakarta EEを使う企業向けシステムに読み替えた初期予算の目安です。

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

規模別の開発費用と期間の目安

初期予算を立てるときは、規模ごとの費用と期間の参考レンジを比べます。

小規模：300万〜1,000万円程度、3〜6か月。
中規模：1,000万〜5,000万円程度、6〜12か月。
大規模・基幹：5,000万〜1億円以上、12か月から2年以上。
Java EEからの移行：500万〜5,000万円以上、4〜18か月程度。

小規模は、1部門で基本的な登録と検索を行う構成で、権限と帳票は少数です。外部連携は、なしから少数までです。

中規模は、複数部門での利用や承認、REST API、バッチを含みます。データベース連携や既存システムとの連携も入ります。

大規模は、高可用性や複数拠点、大量データ、監査、複数の基幹連携、24時間運用を求める場合です。Java EEからの移行では、古いライブラリや独自拡張、テスト不足があると、追加の調査費用が必要です。

費用を左右する項目と見積書の見方

費用配分の目安は、要件定義が10〜12%、設計・環境構築が22〜24%、実装が48〜50%、テストが15〜17%程度です。ただし、案件の性質によって変わるため、参考値として見ます。

実装費ばかりが大きく、移行や性能試験、運用設計が見えない見積もりには注意が必要です。見積書では、次の作業が別々の項目になっているかを確認します。

データ移行：移行対象と実施作業。
品質確認：脆弱性診断と負荷試験。
引き継ぎ：教育、運用引き継ぎ、リリース立ち会い。

人月単価は、担当者の経験や上級SEやPMの比率で変わります。セキュリティや移行の専門性、契約形態によっても変わります。

総額だけでなく、機能一覧と工数、単価を分けて提示してもらいます。前提条件や除外事項、変更時の精算方法も示してもらいます。

請負契約では、仕様変更が追加費用に直結しやすいため、変更管理を契約書やプロジェクト計画書に明記します。

クラウド・ライセンス・保守のランニングコスト

ランニングコストは、基盤の利用料に加えて、運用や保守の対象範囲ごとに分けて見積もります。

基盤費：実行基盤、データベース、ストレージ、通信。
運用費：ログ、監視、バックアップ。
保守費：脆弱性対応、サポート契約。

東京リージョンのマネージドコンテナ料金表では、アクティブなコンテナの料金が0.081米ドル／vCPU時間、0.009米ドル／GB時間とされています。待機中メモリは0.009米ドル／GB時間です（出典：サービス公式料金表、2026年8月確認）。

0.5 vCPU・1GBのコンテナ1台を30日稼働させた場合の単純計算では、vCPUとメモリだけで約35.64米ドルです（0.081×0.5×24×30＋0.009×1×24×30）。ただし、この試算にはデータベースやログ、通信、バックアップ、為替は含まれません。

保守運用費は、初期開発費の年15〜25%程度、または月15万〜80万円程度が業務システムの参考レンジです。金額は、監視のみか障害の一次対応までか、24時間365日かで変わります。脆弱性修正や軽微な改修を含むかどうかでも変わります。

開発費やクラウド費、サポート費、追加改修費は分けたうえで、3年から5年の総保有コストで比べます。

ポイント

初期の開発費だけで比べると、運用費の差を見落としがちです。見積もりは総額と内訳を同じ形でそろえ、3年から5年の総保有コストで見ます。

Jakarta EEの開発会社・ベンダー・サービスの選び方

発注先は、Java対応の有無だけで決めず、Profileや Javaのバージョン、認証・認可、データ移行まで確認します。さらに、クラウド・コンテナ、性能試験、長期保守への対応も見ておきます。

実績が「Java開発」のみの場合は、仕様のバージョンや実行基盤、業務範囲について質問します。運用期間や障害対応体制も、あわせて質問します。

技術適合性と移行実績

提案依頼書には、採用する仕様と環境を具体的に書きます。技術条件として、次の項目を含めます。

仕様・実行環境：Jakarta EEのバージョン、Java 17またはJava 21、Profile。
利用機能：API、データベース、認証方式、メッセージング。
配置先：デプロイ先と実行環境。

既存Java EEからの移行では、javax.*の影響調査や依存ライブラリ更新を提案に含められるか確認します。XML設定、回帰テスト、切り戻し計画も確かめます。

標準仕様と固有の拡張の境界を説明できる会社は、将来の環境変更にも対応しやすい傾向があります。

開発体制とプロジェクト管理

開発から運用までどこまでを誰が受け持つかを照らし合わせ、提案チームの役割と実務経験を確認します。

企画・開発：PM、アーキテクト、アプリケーション開発。
基盤・品質：インフラ、データ移行、セキュリティ、テスト。
運用：運用担当と障害対応の責任範囲。

窓口だけが提案に参加し、実装担当の経験が不明な場合は、PoCや技術面談で体制を確かめます。

進捗報告の頻度や課題管理、品質指標を決めると、認識のずれを減らせます。さらに、レビュー方法や仕様変更の承認者も決めておきます。

保守・セキュリティ・契約条件

保守の責任、データ管理、契約条件を確認し、見積もりと運用体制を同じ基準で比べます。

脆弱性・障害対応：情報確認者、パッチ検証者、障害時の連絡先。
契約・サポート：SLA、受付時間、一次切り分け、復旧目標、バックアップ復元、対象Java・実行基盤、終了時の移行支援。
個人データ：委託先・再委託先、データ所在、削除方法、事故時の報告。
会社比較：技術適合性、業務理解、移行実績、品質管理、運用体制、費用透明性、将来の拡張性。
費用比較：見積もりの対象・対象外作業と、3年から5年の運用費。

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

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

ポイント

発注先は、Java対応の有無だけで決めず、移行実績や障害対応、契約上の責任範囲を同じ質問で比べます。標準仕様と固有拡張の境界を説明できるかも、判断の材料になります。

Jakarta EEのシステムに関するよくある質問

採用の判断や発注の前に寄せられやすい質問を取り上げます。既存の資産、業務の重要度、チームの運用能力を前提に判断します。

Jakarta EEとSpringはどちらを選ぶべきですか？

どちらか一方が常に優れているわけではありません。業務要件や既存資産、チームの経験、標準仕様をどこまで重視するかで決まります。

Jakarta EEは、企業向けの共通機能を標準APIで揃えやすく、長期運用や実行基盤の選択肢を重視する案件に向いています。

Springも比べたうえで、必要な機能や運用費、移行のしやすさ、採用後の教育コストをPoCで確かめます。

Jakarta EEのシステムはクラウドで運用できますか？

運用できます。仮想マシン、コンテナ、Kubernetes、マネージドコンテナなどから、実行形態を選びます。

クラウドに置いたからといって、クラウドネイティブになるわけではありません。可用性やオートスケール、ログ、監視、DB冗長化を設計します。バックアップやネットワーク、秘密情報管理も対象で、障害時にどこまでを誰が受け持つかも決めます。

古いJava EEのシステムは移行したほうがよいですか？

判断は、サポート期限や脆弱性、OSやDBの更新予定、開発者の確保、クラウド移行計画を見て行います。

いきなり全面移行へ進むのではなく、まずは資産の洗い出し、依存ライブラリの調査、互換性のある小規模機能での検証を行います。回帰テストの見積もりも、先に行います。

業務停止のリスクが高い場合は、段階移行や新旧環境の並行稼働を含めて計画します。

少人数のチームでもJakarta EEを運用できますか？

可能です。ただし、仕様を絞り、運用を自動化して、サポート窓口を明確にしておく必要があります。Web ProfileやCore Profileを使えば、不要な機能を減らせます。

CI/CD、監視、バックアップ復元、脆弱性スキャンは、標準化しておきます。特定の担当者だけが設定を理解している状態を避けるため、構成図や手順書、障害対応記録、サポート対象一覧を更新します。

まとめ：自社の業務と運用に合うJakarta EEのシステム

Jakarta EEは、画面やAPIだけでなく、データや認証、トランザクションから、バッチや外部連携、実行基盤、運用までを含む企業向けアプリケーションの設計基盤です。

新規開発では、必要なProfileと標準APIを選びます。既存のJava EEから移行する場合は、javax.*への対応、依存ライブラリ、認証、データ、回帰テストを先に確認します。

導入判断で押さえるポイント

導入前に整理する条件は、業務の重要度、既存資産、必要な可用性、運用人員、将来の移行方針です。

一度に刷新せず、PoCや段階リリースで不確実性を減らし、導入効果と運用負担を数字で確かめます。

発注前に確認するポイント

費用を抑えるには、要件を曖昧なまま実装へ進めないことが大切です。そのうえで、開発費とクラウド・保守費を分けて把握し、PoCで技術的不確実性を減らします。

発注先は、Java対応だけで判断しないようにします。Jakarta EEのバージョンやProfile、移行実績、セキュリティ、障害対応、契約上の責任範囲を、同じ質問で比べます。

▼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を創業。