Jakarta EEのシステム開発の発注/外注/依頼/委託方法について

Jakarta EEのシステム開発を発注・外注するときは、技術名だけで会社を選ばず、業務範囲、Java EEからの移行有無、実行基盤、非機能要件、保守責任までをRFPと契約に落とし込むことが重要です。

本記事では、Jakarta EEのシステムを新規開発または既存Java EEから移行する企業に向けて、発注形態の選び方、要件整理、契約形態、費用相場、委託先の選定、見積比較の進め方を解説します。2026年時点で確認できるJakarta EE 11の動向も踏まえ、発注担当者が開発会社との認識違いを減らすための確認事項まで整理します。

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

Jakarta EEのシステムとは何を発注するのですか？

Jakarta EEのシステムは、業務パッケージそのものではなく、企業向けJavaアプリケーションを構築・運用するための標準仕様群を使った業務システムです。画面、REST API、認証・認可、データベース、トランザクション、バッチ、メッセージング、監査ログなどを、選定したアプリケーションサーバーやクラウド基盤の上で組み合わせます。したがって、発注対象は「Jakarta EEで作ること」だけではなく、実現する業務機能と運用サービス一式です。

Jakarta EEにはServlet、RESTful Web Services、CDI、Persistence、Transactions、Security、Messagingなどの仕様があります。必要な仕様だけを組み合わせるため、部門向けのWeb業務アプリにはWeb ProfileやCore Profileを使い、複雑な基幹連携や大量処理にはデータベース、キュー、バッチ、監視まで含めて設計します。ここを曖昧にして「Jakarta EE対応会社」という条件だけで発注すると、完成後に帳票や権限、障害復旧が別費用になりやすいです。

発注の出発点は、新規のスクラッチ開発か、既存Java EEアプリの移行か、SaaSやパッケージを組み合わせたハイブリッドかを決めることです。Java EEからの移行では、javax.*からjakarta.*への名前空間変更だけでなく、依存ライブラリ、XML設定、認証方式、アプリケーションサーバー、帳票、外部連携の互換性を確認します。既存資産を残すほど移行調査と回帰テストが重要になり、ゼロから作るほど業務要件とデータ移行の設計が重要になります。

発注形態はどのように選べばよいですか？

発注形態は、業務要件の確定度、社内にいるIT人材、既存システムの複雑さ、リリース時期、変更の多さで選びます。最初から開発会社に丸投げするのではなく、社内で決める事項と委託する事項を切り分けると、費用と責任範囲が見えやすくなります。

画面一覧、業務フロー、外部連携、性能目標、受入条件が固まっている場合は、設計からテストまでを一括請負で依頼しやすいです。成果物と納期を合意しやすく、社内の管理負担を抑えられる一方、発注前の要件が不足すると、仕様変更が追加費用や納期延長として現れます。Jakarta EEのProfileやサーバー製品を委託先の提案に任せる場合も、採用理由と将来の移行可能性を成果物に含めることが重要です。

現場ごとに業務が違う、Java EE資産の全体像が不明、関係部署の合意形成が必要という場合は、要件定義や現状調査を準委任で始める方法があります。委託先のエンジニアが社内担当者と作業時間を共有しながら、業務フロー、データ項目、連携仕様、移行対象を整理します。調査結果をもとに本開発だけを請負に切り替える二段階発注にすると、要件不確定のまま大きな契約を結ぶリスクを抑えられます。

販売管理や勤怠など標準化しやすい領域はSaaSを使い、固有の承認や基幹連携だけをJakarta EEで開発するハイブリッドも有力です。すべてをスクラッチにするより初期開発を抑えられる可能性がありますが、SaaSのAPI制限、データ所在、解約時のデータ返却、利用料改定、障害時の責任分界を確認する必要があります。比較対象には、開発費だけでなく5年程度の利用料、連携費用、運用担当者の工数を含めます。

RFPと要件整理では何を決めるべきですか？

RFPは機能一覧だけでなく、委託先が同じ前提で見積もれる情報を揃える文書です。回答書に「対応可」と書かせるだけでは不十分で、対象範囲、前提条件、除外項目、検収方法、追加変更の扱いまで指定します。特にJakarta EE案件では、仕様と実装製品が別物であるため、どのProfile、Javaバージョン、アプリケーションサーバー、データベース、コンテナ基盤を想定するかを明記します。

「画面20枚」といった数え方だけでは、承認経路、例外処理、権限、帳票、通知、締め処理の工数が伝わりません。RFPには利用者の種類、月間・ピーク時の処理件数、業務フロー、入力項目、承認条件、帳票、検索条件、通知先、外部連携を記載します。Must、Should、Couldの優先度も分け、初回リリースで必須の機能と将来拡張を分離すると、複数社の提案を比較しやすくなります。

Jakarta EE 11は2025年6月26日に一般提供され、Java SE 17以上を前提とし、Java 21ではVirtual Threadsを利用でき、Jakarta Dataも加わりました（出典: Eclipse Foundation「Jakarta EE 11 Release」、2025年）。RFPでは「Jakarta EE 11対応」とだけ書かず、Web ProfileかPlatformか、採用する仕様、Java 17または21、アプリケーションサーバーの製品名とバージョン、サポート期限、データベース、認証基盤、メッセージングを分けて記載します。仕様の互換性と製品の商用サポートを別々に確認することが大切です。

2026年8月時点でEclipse Foundationのリリース一覧ではJakarta EE 12は開発中とされているため、納期が先の案件でも「次期版に対応予定」という提案だけで採用を決めないことが大切です。正式に互換性が確認された製品、利用するJavaの長期サポート、既存アプリの移行計画を優先し、将来のアップグレード余地は別の評価項目として扱います（出典: Eclipse Foundation「Jakarta EE Releases」、2026年確認）。

可用性、応答時間、同時利用者数、バックアップ、復旧目標、監査ログ、脆弱性対応、監視時間帯を数値または条件で記載します。「速い」「止まらない」では会社ごとに解釈が変わるため、ピーク時の秒数、月間稼働率、RTO、RPO、ログ保存期間などに置き換えます。移行案件なら、現行のjavax.*利用箇所、依存ライブラリ、データ件数、文字コード、バッチ時間、切替可能時間、リハーサル回数、切戻し条件もRFPに含めます。

開発会社に任せる範囲は、リリースで終わるとは限りません。Javaやサーバーのパッチ適用、依存ライブラリの脆弱性確認、秘密情報の更新、監視アラート、障害一次対応、バックアップ復元、権限棚卸し、再委託先への連絡を誰が担当するか決めます。Jakarta SecurityのAPIを採用しても、秘密情報管理やネットワーク分離まで自動的に安全になるわけではありません。個人データを扱う場合は、個人情報保護委員会のガイドラインに沿った委託先管理や削除方法も確認します。

契約形態は請負と準委任のどちらがよいですか？

契約形態は、成果物を固定できるか、発注者と受託者がどこまで共同で要件を決めるかによって選びます。契約名だけで安全性が決まるものではなく、作業範囲、成果物、検収、変更管理、再委託、知的財産、損害賠償、保守への移行条件を具体化することが重要です。

請負契約は、合意した成果物を完成させ、検収を受ける形に向いています。基本設計書、詳細設計書、ソースコード、テスト仕様書、操作マニュアル、移行手順書などを成果物として列挙し、検収期間と不具合修正の扱いを定めます。ただし、要件が未確定の段階で全工程を請負にすると、追加変更の協議が頻発します。要件定義・調査は準委任、開発・テストは請負という分割も検討します。

準委任契約は、専門家としての調査、設計支援、開発支援などを一定期間依頼する形です。移行対象の棚卸し、現行環境の解析、PoC、技術検証、プロジェクト管理支援のように、作業を進めながら成果の方向を決める局面に適しています。作業時間や体制を基準に費用が決まることが多いため、月次の作業報告、稼働上限、優先順位の決定者、成果物の最低ラインを契約書や個別発注書に明記します。

Jakarta EEのバージョン、サーバー製品、DB、クラウド構成が途中で変わると、設計・試験・運用手順に影響します。変更要求の起票者、影響調査の期限、追加見積の計算方法、承認者、納期変更の条件を決めておくと、口頭依頼による認識違いを防げます。また、ソースコード、設定ファイル、CI/CD定義、テストデータ、設計書を誰が保有し、契約終了後にどの形式で引き渡すかも確認します。オープンソースのライセンスと商用サポート費も、開発費と分けて記載してもらいます。

Jakarta EEのシステム開発費用相場はいくらですか？

Jakarta EE専用の国内価格統計は一般に公開されていないため、以下は業務システム全般の相場を、企業向けJavaシステムの規模と工程に合わせて読み替えた初期予算の目安です。小規模Web業務アプリは300万〜1,000万円、中規模業務システムは1,000万〜5,000万円、大規模・基幹システムは5,000万〜1億円以上が目安になります。既存Java EEからの移行は、対象範囲と回帰テストの量によって500万〜5,000万円以上の幅で見ます。いずれも確定見積ではなく、要件・既存資産・連携数・可用性を前提にしたレンジです。

小規模の目安は、1部門で基本的な登録・検索・更新、限定的な権限、少数の帳票を扱うケースです。中規模になると、複数部門、承認、REST API、バッチ、既存DBや会計・在庫との連携が加わります。大規模では、複数拠点、大量データ、24時間運用、監査、障害時の切替、複数回の移行リハーサルが必要になるため、単純な画面数では予算を判断できません。見積依頼時は、開発費、データ移行費、性能・脆弱性試験費、教育費を別行にしてもらいます。

費用配分は案件によって異なりますが、業務システム全般の目安として、要件定義10〜12%、設計・環境構築22〜24%、実装48〜50%、テスト15〜17%程度で置くことがあります（出典: NotebookLMリサーチノート内「業務システム全般」の費用整理、2026年）。これはJakarta EE専用の統計ではないため、発注時の比較軸として使い、各社には工数と単価の根拠を確認します。移行案件では、現行調査、変換、データクレンジング、回帰テスト、切替リハーサルを実装費から分けると、安すぎる見積の理由も見抜きやすくなります。

運用費には、アプリケーションサーバーのサポート、Javaの保守、クラウドのコンテナ、データベース、ログ、監視、バックアップ、通信、脆弱性対応が含まれます。AWS App Runnerの東京リージョンでは、アクティブコンテナの料金例として0.081米ドル／vCPU時間、0.009米ドル／GB時間が示されています（出典: Amazon Web Services「AWS App Runner料金」、2026年確認）。0.5 vCPU・1GBを1台で24時間稼働させる単純計算では、コンテナ分だけ月約65米ドルですが、ログ、DB、通信、バックアップ、監視は別料金で、為替や利用量でも変わります。したがって、クラウド費用を月額固定で断定せず、構成と利用量を添えて試算します。

委託先選定と見積比較では何を確認しますか？

委託先は、Javaの経験年数や会社規模だけでなく、Jakarta EEを使った業務システムを運用まで成立させられるかで選びます。候補企業には同じRFPと見積フォーマットを渡し、機能・工数・単価・前提・除外・保守をそろえて回答してもらいます。価格の一番安い会社を選ぶのではなく、抜けている作業がないか、提案の前提が自社の業務に合うかを見極めます。

「Javaに対応できます」という回答だけでは不足しています。Jakarta EE 11のWeb Profile、Core Profile、Platform相当のどこを使うのか、Open Liberty、WildFly、Payara、WebLogicなどのどの実装を想定するのか、Java 17と21のどちらを採用するのかを聞きます。2025年のEclipse Foundation調査では、1,700人超の回答者のうちJakarta EE利用が58%、Springが56%、Jakarta EE 11採用が18%でした（出典: Eclipse Foundation「2025 Jakarta EE Developer Survey」、2025年）。この数字は市場全体のシェアではなく回答者ベースですが、企業向けJavaの選択肢として継続的に評価されていることを確認できます。

見積比較では、要件定義、基本設計、詳細設計、実装、単体・結合・総合・性能・セキュリティ試験、データ移行、教育、リリース、運用引継ぎを行単位で確認します。さらに、PMや上級SE、セキュリティ担当、インフラ担当が何人月含まれるか、レビューと品質管理が別料金かを確認します。A社の総額が安く見えても、移行リハーサルや監視設計が除外されていれば、後から追加費用が発生して比較できません。

候補を絞ったら、代表的な業務フローで短いPoCを依頼します。REST API、DBアクセス、認証・認可、監査ログ、エラー処理、コンテナへのデプロイ、ログ確認までを一通り動かすと、資料だけでは分からない設計力が見えます。既存Java EEからの移行なら、javax.*の変換、依存ライブラリ更新、サーバー設定、回帰テストの方針をサンプルコードで説明してもらいます。実績は会社名や件数だけでなく、利用したProfile、サーバー、Javaバージョン、運用体制まで質問します。

実行基盤の事例として、OracleはCERNがWebLogicをKubernetes上で活用する取り組みを公開しています。これは大規模環境でのコンテナ運用を考える際の参考になりますが、ベンダーが公開する事例の性能や構成を自社へそのまま当てはめず、利用者数、可用性、運用要員、データ所在、障害時の復旧条件を自社要件に置き換えて評価します（出典: Oracle「WebLogic Server」CERN事例、2026年確認）。

「標準機能で対応します」と言いながら対象の仕様が書かれていない、「クラウド費用込み」と言いながらDBやログが別、「移行可能」と言いながら切替リハーサルがない提案には注意します。質問への回答が担当者ごとに変わる、技術選定の理由がない、運用開始後の窓口やSLAがない場合もリスクです。提案書の評価では、技術適合性、業務理解、移行計画、品質管理、セキュリティ、運用、費用透明性を分けて採点し、価格だけで順位を決めないようにします。

よくある質問

Jakarta EEの発注では、技術選定だけでなく、既存資産、費用、契約、運用の範囲に質問が集まりやすいです。代表的な疑問に、発注前に確認すべき前提を添えて回答します。

Jakarta EEを採用しただけで高額になるとは限りません。費用は業務機能、連携数、データ量、可用性、既存資産の移行、商用サポート、保守体制で決まります。標準APIや既存部品を活用して範囲を絞れば抑えられる一方、基幹業務の高可用性や大規模移行を含めれば、一般的な小規模Webアプリより高くなります。

最初に、現行アプリのJava EEバージョン、javax.*の利用箇所、依存ライブラリ、アプリケーションサーバー、認証、DB、外部連携、帳票、バッチを棚卸しします。その後、移行対象と対象外を決め、サンプル機能で変換、ビルド、起動、テストを行います。いきなり本番全体を移行せず、回帰テストと切戻し条件を確かめてから段階的に進めると、発注費用とリスクを見積もりやすいです。

「どの案件で使ったか」だけでなく、Jakarta EEのバージョンとProfile、Javaのバージョン、実行サーバー、DB・認証・メッセージング連携、移行か新規か、リリース後の保守体制を聞きます。さらに、障害対応の時間帯、脆弱性情報の確認方法、サポート終了時の更新計画、ソースコードと設計書の引き渡し条件も質問します。実績を自社案件へ応用できる根拠を説明できる会社を候補に残します。

同じ会社に委託すると、設計意図や障害履歴を引き継ぎやすくなりますが、必須ではありません。別会社への切替可能性を残すなら、ソースコード、環境定義、テスト、監視設定、運用手順、ライセンス情報を発注者が取得できる契約にします。保守を同じ会社へ依頼する場合も、月額に含まれる対応時間、障害の優先度、脆弱性対応、追加開発の単価を明確にして比較します。

まとめ

Jakarta EEのシステムを発注するときは、技術名を指定して終わりにせず、業務機能、既存Java EE資産、Profile、Javaとサーバーのバージョン、非機能、データ移行、運用責任までを一つの要件として整理します。新規開発、移行、SaaSとのハイブリッドを比較し、要件が固まっている工程は請負、調査や要件定義は準委任というように、発注形態を使い分けます。

最後に、業務フローと優先度、画面・API・帳票・バッチ、利用者数とデータ量、外部連携、Jakarta EEのProfile、Javaと実行サーバー、認証・認可、性能・可用性、移行・切戻し、テスト、クラウド・ライセンス・保守費、契約と検収条件を確認します。複数社へ同じ条件で提示し、見積の総額だけでなく、前提と除外、工数、担当体制、リリース後の責任を比較すれば、発注後の追加費用と手戻りを減らせます。

すでにJava EEのシステムがある場合は、現行環境と依存関係を一覧化し、代表機能でJakarta EEへの移行可能性を検証します。新規開発でも、認証、DBアクセス、監査ログ、デプロイ、障害時のログ確認を含む小さなPoCを行うと、提案会社の技術力と運用の現実性を確かめられます。予算は本記事のレンジを出発点にし、RFPとPoCの結果を反映した正式見積へ進めることが安全です。

▼全体ガイドの記事
・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を創業。