Jakarta EEのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Jakarta EEのシステム開発は、業務要件を整理してから対応するProfile・Javaのバージョン・アプリケーションサーバーを決め、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズで進める方法が基本です。費用はJakarta EEという技術名だけで決まらず、画面数、API、バッチ、外部連携、既存Java資産、可用性、移行範囲、運用体制によって大きく変わります。

本記事では、Jakarta EEのシステムを新規開発またはJava EEから移行する担当者に向けて、各工程で決めること、判断基準、確認すべきチェック項目、費用相場、見積書の読み方までをまとめます。2026年時点のJakarta EE 11の動向や、クラウド費用・セキュリティの見落としやすい点も含めて、発注前から稼働後まで使える実務的な進め方を解説します。

▼全体ガイドの記事
・Jakarta EEのシステム開発の完全ガイド

Jakarta EEのシステム開発の全体像

Jakarta EEは、販売管理や受発注などの業務パッケージではなく、企業向けJavaアプリケーションを作るための標準仕様群です。Web画面、REST API、認証・認可、データベースアクセス、トランザクション、バッチ、メッセージングなどを、対応するアプリケーションサーバー上で組み合わせて使います。したがって、開発の最初に「Jakarta EEを使う」とだけ決めるのではなく、どの業務をどの品質で支えるシステムなのかを先に定義することが重要です。

Jakarta EEとは、旧Java EEを引き継いだ、企業向けJavaアプリケーションの標準仕様です。仕様と製品は別物で、Jakarta EEのAPIや実行モデルに準拠した実装として、GlassFish、WildFly、Payara、Open Liberty、WebLogicなどを案件の条件に合わせて選びます。仕様に沿った構成を採ることで、業務ロジックを特定ベンダーの独自機能に過度に依存させず、将来のサーバー移行や保守会社の変更を検討しやすくなります。

2025年6月に一般提供されたJakarta EE 11は、Java SE 17以上を前提とし、Java 21のVirtual Threadsを活用できるほか、Jakarta DataやTCKの改善を含みます（出典: Eclipse Foundation「Jakarta EE 11 Release」、2025年）。ただし、対応を名乗る製品でも、Platform、Web、CoreのどのProfileに対応するかや、利用するJavaの組み合わせは異なります。提案書では「Jakarta EE 11対応」という一文だけで判断せず、Profile、実装製品、バージョン、JDK、データベース、認証方式をセットで確認します。

Jakarta EEは、長期運用、トランザクションの正確性、認証・認可、可用性、監査性が重要な業務システムに向いています。具体的には、販売管理、顧客・会員管理、受発注、社内ポータル、基幹連携、決済、公共・金融系の業務アプリケーションなどです。複数部門が同じデータを参照し、処理の整合性を守りながら段階的に機能追加する案件では、標準APIと実行基盤を組み合わせるメリットが出やすくなります。

一方で、単純なフォームや短期の試作であれば、Web ProfileやCore Profileで必要な仕様だけを使う方法が適しています。不要な機能まで含むPlatformを選ぶと、学習範囲、設定、試験項目、運用監視が増えて費用も膨らみます。小さく始める場合も、標準APIを使う領域と、サーバー固有の設定・拡張を使う領域を設計書に分けておくと、将来の拡張や移行の判断がしやすくなります。

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

Jakarta EEの開発工程は、技術選定から始めると失敗しやすくなります。まず現場の業務と経営上の目的を合わせ、次に必要な仕様と実行基盤を選び、設計・実装・試験へ進みます。ここでは、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズを、成果物と判断基準が分かるように分解します。

要件整理では、画面や機能の一覧だけでなく、業務の開始条件、担当者、承認経路、入力データ、連携先、例外処理、処理量、利用時間を明らかにします。発注側は「販売管理を作る」と書くのではなく、受注登録、在庫引当、出荷指示、請求確定、取消、締め処理のように業務イベントへ分解します。各イベントに対して、誰が、いつ、どのデータを参照・更新し、失敗したときにどう戻すかを確認します。

同時に、非機能要件を数値化します。平日日中の利用者数、ピーク時の同時接続数、1時間あたりの処理件数、許容レスポンスタイム、復旧目標時間、復旧時点目標、保守時間帯、保存期間、監査ログの対象を決めます。チェックの基準は「速く」「止まらず」ではなく、「ピーク時に何秒以内」「何分以内に復旧」「何世代のバックアップを残す」のように測れる表現にします。

要件を基に、Web画面やREST APIを中心とするならWeb ProfileまたはCore Profile、複雑なトランザクションやメッセージング、バッチを広く使うならPlatform相当の構成を候補にします。選定時は、Profileの対応範囲、Jakarta EEのバージョン、Java 17またはJava 21の動作実績、データベースドライバー、認証基盤、メッセージング製品、監視方法を一枚の比較表にまとめます。名称が似ていても、同じバージョンのAPIがすべて動くとは限らないためです。

新規開発では、標準APIと製品固有機能の境界をPoCで確認します。小さな業務フローを一つ選び、認証、DB更新、トランザクション、監査ログ、コンテナ化、デプロイ、障害時のログ確認までを実装します。既存Java EEからの移行では、まず依存ライブラリと設定ファイルを棚卸しし、javax.*からjakarta.*への変更、XML設定、JPAの挙動、認証方式、外部連携の互換性を確認します。PoCで解消できない不確実性は、見積書のリスク項目に残します。

設計では、業務フロー、画面、API、データモデル、権限、エラー処理、バッチ、外部連携、ログ、バックアップを一つの構成として考えます。Jakarta Persistenceで扱うエンティティ、トランザクション境界、排他制御、再実行の条件を先に決め、後から画面ごとに個別実装して整合性が崩れないようにします。非同期処理やメッセージングを使う場合は、重複配信、順序保証、タイムアウト、デッドレター、再処理の担当者まで設計書に含めます。

開発環境は、Mavenの依存関係、Javaランタイム、アプリケーションサーバー、コンテナイメージ、環境変数、秘密情報の扱いをコードと設定で再現可能にします。開発者のPCだけで動く状態を避け、CIでビルド、単体テスト、脆弱性スキャン、コンテナイメージ検査を行います。コードレビューでは、仕様にない独自拡張が増えていないか、障害ログに個人情報が出ないか、トランザクションをまたぐ処理が適切かを確認します。

テストは単体、結合、総合、受入の順に進めるだけでは不十分です。Jakarta EEのシステムでは、認証・認可、トランザクション、同時更新、外部APIのタイムアウト、バッチの再実行、帳票、監査ログ、バックアップ復元、性能、障害復旧、脆弱性を計画します。特にJava EEから移行する場合は、正常系が動くだけでなく、既存システムと同じ入力に対して同じ結果になる回帰テストを用意します。

性能試験では、平均値だけで合格にせず、ピーク時の95パーセンタイルやエラー率、DBのロック待ち、CPU・メモリ、キュー滞留を確認します。移行案件では本番相当データを匿名化し、データ件数、文字コード、日付、NULL、重複キーを含む移行リハーサルを複数回行います。テスト終了条件は「一通り確認した」ではなく、重大度ごとの未解決件数、性能基準、復旧時間、利用部門の受入サインで定義します。

稼働前には、リリース判定会議で機能、データ、性能、セキュリティ、運用の条件を確認します。切り替え方式は、一括移行、段階移行、並行稼働から業務の停止許容時間とデータの同期難易度に合わせて選びます。切り替え当日の作業を時刻順に並べ、バックアップ取得、書き込み停止、最終データ移行、疎通確認、利用部門の確認、告知、監視開始、問題時の切り戻しまで担当者と完了条件を割り当てます。

本番稼働後は、初日だけでなく1週間から1か月程度の安定化期間を計画します。ログイン失敗、APIエラー、処理時間、バッチの遅延、問い合わせ件数、データ不整合をダッシュボードで追い、異常の一次切り分けを決めます。切り戻し手順は文書化するだけでなく、リハーサルで実際に復旧できることを確認します。バックアップが存在することと、復元して業務を再開できることは別の確認です。

定着フェーズでは、利用部門が新しい業務手順を実行できることと、運用担当者が自力で日常作業を回せることを確認します。操作マニュアルだけでなく、権限申請、ユーザー追加、月次バッチ、障害連絡、ログ確認、バックアップ復元、脆弱性情報の確認、リリース承認の手順を整備します。外部の開発会社へ委託する場合も、どの障害を何分以内に受け付け、誰が原因調査と復旧判断を担うかをSLAや運用設計書に明記します。

定着後は、利用率、入力漏れ、処理時間、問い合わせ件数、障害件数、復旧時間、リリース頻度などのKPIを月次で確認します。機能追加は要望をそのまま受けるのではなく、業務効果、セキュリティ影響、データモデルへの影響、テスト範囲、費用を評価して優先順位を決めます。Javaやサーバーのサポート期限、依存ライブラリの脆弱性、クラウド料金の増減も定期的に見直し、完成後に放置されるシステムを避けます。

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

Jakarta EE案件の費用は、技術名だけから一意に算出できません。以下の金額は、業務システム全般の相場をJakarta EEを使う業務システム向けに読み替えた初期予算の目安であり、Jakarta EE専用の公的な価格統計ではありません。画面・API・バッチ・帳票・連携・移行・テスト・運用をどこまで含めるかで、同じ規模でも金額は変わります。

小規模Web業務アプリは、1部門、基本的な登録・検索・更新、少数の権限と帳票、外部連携がないか少数であれば、300万〜1,000万円、3〜6か月程度が目安です。中規模業務システムは、複数部門、承認、REST API、バッチ、データベース連携、既存システム連携を含み、1,000万〜5,000万円、6〜12か月程度を見込みます。いずれも要件を絞り、既存部品を活用する場合の下限であり、個別見積ではありません。

高可用性、複数拠点、大量データ、複数の基幹連携、厳格な監査、移行リハーサルを含む大規模・基幹システムでは、5,000万〜1億円以上、12か月から2年以上となる場合があります。既存Java EEからの移行は、500万〜5,000万円以上、4〜18か月程度が目安です（出典: NotebookLM「業務システム全般」のQ&Aを基にしたリサーチノート、2026年）。javax.*の置換だけでなく、依存ライブラリ、サーバー設定、認証、JPA、外部連携、回帰テスト、段階リリースが含まれるほど上限に近づきます。

開発費の比較では、要件定義、設計・環境構築、実装、テストの費用を分けます。リサーチノートの目安では、要件定義が10〜12%、設計・環境構築が22〜24%、実装が48〜50%、テストが15〜17%程度です。データ移行、性能試験、脆弱性診断、教育、運用引き継ぎは本体の開発費に含まれないことがあるため、別行で記載されているか確認します。

クラウド費は開発費とは別のランニングコストです。例えばAWS App Runner東京リージョンでは、プロビジョニングされたコンテナのメモリが0.009 USD／GB時間、アクティブなコンテナのvCPUが0.081 USD／vCPU時間と案内されています（出典: AWS「App Runnerの料金」、2026年確認）。ただし、ログ、データ転送、データベース、バックアップ、監視、WAF、ロードバランサー、環境数、可用性構成は別料金です。コンテナの単価だけで月額を断定せず、構成と利用量をAWS料金計算ツールなどで試算します。

保守運用は、初期開発費の年15〜25%程度、または月15万〜80万円程度が一般的な業務システムの目安です。ただし、平日日中の問い合わせ対応と24時間365日の障害対応では必要な体制が違います。保守費に含む範囲を、問い合わせ、障害一次対応、原因調査、脆弱性対応、OS・JDK更新、サーバー更新、機能改修、バックアップ復元、性能改善に分けて契約します。

Jakarta EEのシステム開発で見積もりを取る際のポイント

見積もりの精度を上げるには、技術名ではなく業務範囲と成果物を提示します。発注先が同じ前提で比較できるよう、機能一覧、業務フロー、利用者と権限、画面・帳票・API一覧、連携先、データ件数、移行対象、非機能要件、希望時期、保守条件をRFPに記載します。要件が未確定な部分は「未定」と隠さず、調査費や追加見積の条件を明示します。

見積依頼書には、最低限、要件定義書、基本設計書、詳細設計書、ソースコード、テスト仕様書・結果、移行計画、運用設計書、マニュアル、引き継ぎ資料の納品有無を書きます。画面数だけでなく、画面ごとの入力項目、検索条件、権限、帳票、外部API呼び出し、バッチの本数と頻度まで分けると、各社の工数差を説明しやすくなります。データ移行は、対象テーブル、件数、変換、クレンジング、照合、リハーサル回数を記載します。

非機能要件では、利用時間、ピーク負荷、可用性、バックアップ、復旧目標、ログ保存期間、暗号化、脆弱性診断、監査証跡、個人情報の取り扱いを確認します。セキュリティを「標準対応」とだけ書くと、認証・認可、秘密情報管理、TLS、依存ライブラリのスキャン、WAF、ネットワーク分離、インシデント報告のどこまで含むかが曖昧になります。要件ごとに検証方法と責任者まで割り当てます。

会社選びでは「Javaの開発経験が豊富」という説明だけでなく、使うProfileと実装製品、Java 17・21の対応、Java EEからの移行実績、DB・認証・メッセージング連携、コンテナやKubernetesの運用経験、障害対応体制を聞きます。過去事例は、業界名や画面数だけでなく、ピーク処理量、可用性、移行方式、稼働後の保守体制、予定外の課題と解決方法まで確認すると、自社との類似性を判断しやすくなります。

提案時には、実装候補の対応表とPoCの範囲を提出してもらいます。例えば、Jakarta EE 11のWeb ProfileでServlet、REST、Persistence、Securityを使い、Java 21と特定のアプリケーションサーバーで動作させる場合、各組み合わせの対応状況を証跡付きで示してもらいます。認証方式やサーバー固有設定が標準APIから外れる場合は、将来の移行コストと代替案も比較対象にします。

請負契約では、要件変更の扱いを決めます。変更要求の受付、影響調査、見積提示、承認、納期変更、テスト追加の手順がないと、開発後半で追加費用と納期遅延が起きやすくなります。特に、外部API仕様の変更、データ移行件数の増加、帳票の追加、認証要件の変更、24時間運用への変更は、工数に直結しやすい項目です。

オープンソースの実装を使う場合は、利用料がないことと保守費がないことを混同しません。脆弱性情報の監視、パッチ適用、サポート窓口、サポート対象バージョン、障害時のエスカレーション、ライセンス確認を誰が担うかを明記します。NISCの「サイバーセキュリティ2025」でも、委託先を含むサプライチェーンを通じてサービス停止や情報漏えいが波及するリスクが示されているため（出典: 国家サイバー統括室「サイバーセキュリティ2025」、2025年）、開発会社・クラウド・運用会社の境界を契約と運用手順でつなぎます。

Jakarta EEのシステム開発でよくある質問

最後に、発注前によく寄せられる疑問へ回答します。Jakarta EEの採用可否は、流行しているかどうかだけでなく、既存資産、業務の複雑性、運用体制、必要な可用性、将来の移行方針を合わせて判断します。

既存のJava EE資産、標準仕様への準拠、アプリケーションサーバーの運用、長期保守を重視するならJakarta EEが候補になります。チームの開発経験、利用したいライブラリ、クラウドネイティブ化の方針、採用する運用基盤まで含めて比較し、技術名だけで決めないことが大切です。2025年のEclipse Foundation調査では、回答者の58%がJakarta EEを利用し、Springは56%、Jakarta EE 11の採用は18%でした（出典: Eclipse Foundation「2025 Jakarta EE Developer Survey」、2025年）。これは1,700人超の回答者による調査で、市場全体のシェアを示す統計ではありません。

移行できますが、バージョンと依存関係を確認したうえで段階的に進めます。代表的な論点は、javax.*からjakarta.*への名前空間変更、JDKとアプリケーションサーバーの対応、XML設定、JPA、認証、外部ライブラリ、Webサービス、データ移行、回帰テストです。いきなり本番を変更せず、対象資産を棚卸ししてPoC、移行リハーサル、並行稼働または段階リリースへ進むと、停止リスクを抑えやすくなります。

Profile、対応する仕様、実装製品とバージョン、Javaのバージョン、データベース、認証基盤、コンテナ、TCKや互換性の確認方法を確認します。特に「Java 17以上」と「Java 21で本番運用できる」は同じ意味ではないため、開発・試験・本番の組み合わせを提案書に固定します。Jakarta Security 4.0は複数認証機構の基本APIや組み込みIdentity Storeを含み、Java SE 17以上が最低要件ですが（出典: Jakarta EE「Jakarta Security 4.0」、2026年確認）、APIがあるだけで秘密情報管理や監査設計まで完了するわけではありません。

クラウドのコンピューティング、データベース、ストレージ、通信、ログ、監視、バックアップ、WAF、証明書、商用サーバーのサポート、脆弱性診断、教育、保守運用が発生します。既存Java EEからの移行なら、調査、ライセンスやサポート契約の見直し、データ移行、回帰テスト、切り替えリハーサルも別枠で見積もります。見積書では「初期」「月額」「年額」「臨時作業」に分け、開発会社とクラウド事業者の責任範囲を確認してください。

まとめ

Jakarta EEのシステム開発は、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズで、業務と技術を往復しながら進めます。最初に業務範囲と非機能要件を数値化し、次にProfile、Java、アプリケーションサーバー、DB、認証、運用基盤の組み合わせをPoCで確認します。Jakarta EE 11対応という表記だけで判断せず、実際の実行環境と互換性を確かめることが重要です。

費用は小規模Web業務アプリで300万〜1,000万円、中規模で1,000万〜5,000万円、大規模・基幹で5,000万〜1億円以上、既存Java EEからの移行で500万〜5,000万円以上が初期予算の目安です。ただし、これはリサーチノートに基づく一般的なレンジであり、画面数、連携数、移行データ、可用性、試験、クラウド、保守の前提を揃えた個別見積が必要です。見積書では成果物、追加費用の条件、障害対応、脆弱性対応、サポート期限、責任分界まで確認してください。

発注前に、現行資産の棚卸しと業務フローの整理を始めるだけでも、比較できる見積に近づきます。特にJava EEからの移行や24時間運用を含む案件では、技術選定よりもデータ移行、回帰テスト、切り戻し、運用引き継ぎの具体性が成否を左右します。Jakarta EEを長期運用の基盤として活かすために、作って終わりではなく、定着後のKPIと改善責任まで含めて計画します。

▼全体ガイドの記事
・Jakarta EEのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

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