Jakarta EEは、販売管理や基幹連携など長期運用が求められる業務システムに使われる、企業向けJavaの標準仕様群です。開発会社は、次の観点で比べると選びやすくなります。
- 技術の対応範囲：標準仕様の対応、既存資産の移行、認証、外部との連携
- 案件と費用：向いている案件、質問、費用の確認事項
全体ガイドでは、Jakarta EEのシステム開発の完全ガイドをご覧ください。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
▼全体ガイドの記事
・Jakarta EEのシステム開発の完全ガイド
Jakarta EEのシステム開発でパートナー選びが重要な理由
Jakarta EEのシステム開発では、アプリケーションの実装と実行基盤、移行・保守の設計を切り離せません。そのため、パートナー選びが結果を大きく左右します。
Servlet、REST、CDI、Persistence、Transactions、Security、Messagingなどの標準APIを使えても、組み合わせが合わなければ、本番運用で問題が起きます。組み合わせの対象は、Javaのバージョンやアプリケーションサーバー、データベースのほか、認証基盤や監視にも及びます。
適切なパートナー選定が成否を分ける理由
Jakarta EEは単体の業務パッケージではなく、アプリケーションを動かすための仕様とAPIの集まりです。そのため、要件定義の段階で業務フローを分解し、画面、REST API、バッチなどのどこに標準機能を使うかを決めておく必要があります。
開発会社がJava対応を掲げていても、Jakarta EEのProfile、対象サーバー、Java 17またはJava 21まで確認しなければ、見積もり後に担当者や構成が変わる可能性があります。コンテナ運用の経験も、あわせて確かめてください。
特に既存のJava EE 7・8から移行する場合は、Jakarta EE 9以降でパッケージ名がjavaxからjakartaへ変わった点が大きな論点です。ソースコードに加えて、依存ライブラリ、XML設定、テストデータまで確認すると、移行の抜けを減らせます。そのうえで、回帰テストと移行リハーサルを計画できる会社を選ぶことが大切です。
発注前に確認すべきポイント
発注前には、既存資産の有無、想定利用者数、同時接続数を1枚にまとめておきます。データ量や処理時間、外部システムの数を書き添えておきます。稼働時間と許容停止時間も入れると、見積もりの前提がそろいます。
新規開発か移行か、オンプレミスかクラウドかをそろえてから、2〜3社へ同じRFPを渡してください。Web ProfileかPlatformか、データベースやメッセージングまで含めるかも、事前に決めておくと比べやすくなります。
見積もりは、要件定義、設計、実装、テストの工程ごとに示してもらいます。データ移行、性能試験、脆弱性診断など、工程とは別の項目も分けて出してもらいます。保守契約には、バージョンアップ、脆弱性情報への対応、障害受付時間などまで含めてもらうと、初期費用だけでは分からない差が見えます。
株式会社ripla｜コンサルから開発まで一気通貫で支援
riplaは、コンサルティングから開発まで一気通貫で支援できる企業です。IT事業会社として社内DXを推進してきた経験を活かし、ビジネスへの成果創出とシステムの定着支援に強みがあります。
営業・顧客・生産・販売管理など、幅広い基幹システムの構築・導入実績があります。また、企業の業務要件に合わせて柔軟に対応できる体制を整えています。
特徴と強み
Jakarta EEのシステムでは、技術選定より先に業務の境界を整理する必要があります。riplaでは、利用部門がどの業務を改善したいのか、既存のExcelや基幹システムにどのような二重入力があるのか、導入後に誰が運用するのかを確認します。そのうえで、業務要件とシステム要件をつなげて考えます。
標準APIを活用する領域と、独自の画面・承認・帳票を作り込む領域を分けておくと、将来の保守性も検討しやすくなります。また、既存のJava資産をそのまま延命するのか、Jakarta EEへ移行するのか、別のクラウドサービスと組み合わせるのかを、費用と事業効果の両面から比較できます。
技術名だけで開発範囲を決めず、PoCでAPIや認証、データ登録の動きを確かめたい企業に向いています。監査ログや障害時の復旧まで含めて確認したい場合にも適しています。
得意領域・実績
営業・顧客・生産・販売管理などの基幹業務を、現場の運用に合わせて構築・導入したい企業が相談しやすい候補です。たとえば、顧客情報と受注情報を統合する、販売と在庫を連携する、部門別の承認をオンライン化するなど、複数部門をまたぐテーマを一つの業務フローとして設計できます。
Jakarta EEの実行サーバーやJavaのバージョンを指定する場合は、問い合わせ時の確認が欠かせません。Jakarta EE 11のどのProfileを使うか、Java 17・21のどちらを前提にするかは、確かめてください。IBM、Oracle、Red Hat、Payaraなどのどの基盤を比較できるかも、あわせて確認してください。
riplaの業務整理・開発支援の範囲と、基盤ベンダーのライセンス・製品サポートの範囲を分けて見積もることが、費用の透明化につながります。
富士通株式会社｜大規模SIと企業向けJava基盤を重視する企業向け
富士通株式会社は、公共や金融、製造などの大規模システムを支援してきた総合IT企業です。
企業向けJavaアプリケーションサーバーとして、FUJITSU Software Enterprise Application Platformを提供しています。公開マニュアルでは、Jakarta EE 10互換の基幹システム向けサーバーと、MicroProfile 5互換の軽量フレームワークを案内しています。
特徴と強み
富士通は、2018年にIBM、Oracle、Payara、Red Hat、TomitribeなどとともにJakarta EE Working Groupの設立を準備したと、公式発表しています（出典: 富士通「Jakarta EEをサポートするワーキンググループがEclipse Foundation内に設立」、2018年）。
同社は、Eclipse Foundation内のステアリング委員会、仕様策定委員会、マーケティング委員会にStrategic memberとして参加したとしています。
- 標準仕様への追随：標準仕様の動向を追いながら、既存のInterstageやJava資産、クラウド移行を含めて検討できる点が特徴です。
- 公開情報の世代：Enterprise Application Platformの公開情報は、Jakarta EE 10互換の説明が中心です。
- 確認事項：対応製品のバージョン、Java 17・21のサポート、利用可能なProfile。
- 資料の読み方：資料の対応世代を最新情報として断定せず、既存アプリの移行支援範囲も確かめてください。
Jakarta EE 11を前提にする案件では、見積もりの前に、対応状況が自社の条件と合うかを確かめておくことが欠かせません。
得意領域・実績と確認事項
長期稼働する基幹システム、複数拠点・複数部門の業務、公共・金融のように可用性と監査が重要な案件で比較しやすい会社です。オンプレミスからコンテナやクラウドへ段階的に移行する場合は、現行システムの依存関係やデータ移行、並行稼働、障害復旧を含む計画を作ってもらいます。
見積もり前には、担当する法人・部門や開発を担う体制を確認してください。標準製品と個別開発の境界、ライセンス費、24時間運用の有無も、あわせて押さえておくと見積もりの条件がそろいます。
富士通の製品を採用する場合でも、契約先がアプリケーション開発やクラウド基盤、データベースで分かれることがあります。そのため、責任分界表を作り、どこまでを誰が受け持つかを一覧にします。
日本アイ・ビー・エム株式会社｜Open Libertyによるクラウドネイティブ化
日本アイ・ビー・エム株式会社は、企業向けのクラウド、アプリケーション、データ、セキュリティを支援するITベンダーです。
IBMのOpen Libertyは、軽量なJavaランタイムとしてJakarta EEアプリケーションをコンテナやクラウドで動かす構成を検討しやすい製品です。IBMの公式ドキュメントでは、Jakarta EE 11のPlatform、Web Profile、Core Profileを含む対応表が公開されています。
特徴と強み
Open Libertyは必要な機能だけを組み合わせる構成を取りやすく、従来の大きなアプリケーションサーバーから、サービス単位・コンテナ単位へ段階的に見直したい企業に向いています。ただし、Jakarta EEの仕様対応と、アプリケーション開発・移行・運用の請負範囲は別に確認する必要があります。
Jakarta EE 11の対応範囲をAPI単位で確認できるため、REST、JPA、CDIなど、自社アプリで使う機能の互換性を先に検証できます。
IBMへ相談する際は、Open Libertyを使うチームの経験、既存WebSphereやJava EE資産からの移行方法、Kubernetesの設計を一つの提案に含められるかを聞いてください。ログやメトリクス、脆弱性対応も同じ提案に入るかを確かめておくと、比較が進みます。
得意領域・実績と確認事項
既存のJavaアプリケーションを活かしながら、コンテナ、Kubernetes、CI/CD、監視を整えてクラウドネイティブ化したい企業が候補に挙がります。全体を一度に作り直すのではなく、利用頻度の高いREST APIや一つの業務機能を切り出し、性能、デプロイ時間、障害時の切り戻しを検証する進め方が現実的です。
Open Libertyの対応表は製品の技術情報であり、すべての機能が同じエディションや構成で使えるとは限りません。見積もりでは、ランタイムのサポートやクラウド利用料、アプリ改修を分けて示してもらってください。
Kubernetes基盤、テスト自動化、運用監視も分けて見積もり、オープンソースであることだけを理由に総額が安いと判断しないことが大切です。
日本オラクル株式会社｜WebLogicとOracle製品群の組み合わせ
日本オラクル株式会社は、Oracle Database、Oracle Cloud Infrastructure、WebLogic Serverなどを提供する企業向けITベンダーです。
Oracle WebLogic Serverは、オンプレミスとクラウドの両方でJavaのエンタープライズアプリケーションを実行する基盤として案内されています。Kubernetes上の運用やOracle Databaseとの連携も検討できます。
特徴と強み
Oracle製品を中心に基幹システムを運用している企業は、データベースや認証、バックアップなどを一つの構成として検討しやすいです。WebLogicの公式ページでは、Jakarta EEの標準API、クラスタリング、管理・診断などへの対応が案内されています。コンテナやKubernetesへの対応も、あわせて示されています。
- 対応範囲：最新の製品世代を読むときは、対応済みの仕様とロードマップを区別してください。
- 製品の対応：Oracleの公式発表では、WebLogic 15.1.1版がJakarta EE 9.1とJava SE 17・21に対応しています。
- 今後の方針：2026年に予定される次期メジャーリリースでJakarta EE 11をサポートする方針も示されています。
- 出典：Oracle「The Future of WebLogic Server and Coherence」、2026年
- 契約時の確認：契約時点で実際に利用できるバージョンを確認することが必要です。
得意領域・実績と確認事項
Oracle Databaseを中心とした受発注や会計などの業務基盤、既存WebLogic資産のクラウド移行を検討する企業に適しています。Oracleが紹介するCERNの事例のように、WebLogicをKubernetesで運用する構成も公開されていますが、公開事例の性能や費用を自社へそのまま当てはめないことが大切です。
見積もりでは、WebLogicのライセンスやOracle DatabaseおよびOCIの利用料、アプリ改修、データ移行などを分けてください。既存のJava EEアプリがjavax名前空間を使っている場合は、Jakarta EE 9以降への移行で必要なコード・ライブラリ変更と、旧環境との並行稼働期間を明確にする必要があります。
レッドハット株式会社｜JBoss EAPとOpenShiftによる標準化
レッドハット株式会社は、Linuxやコンテナ、Kubernetesなどを提供するオープンソース系の企業向けベンダーです。
Jakarta EEの実行基盤として、JBoss Enterprise Application Platform（JBoss EAP）を持っています。OpenShiftと組み合わせると、アプリケーションの配備・運用を標準化する構成を検討できます。
特徴と強み
Red Hatの公式サポート情報では、JBoss EAP 8.0と8.1がJakarta EE 10、JBoss EAP 7.4がJakarta EE 8に対応すると整理されています（出典: Red Hat「JBoss Enterprise Application Platform Supported Standards」、2025年）。
このように、同じJBoss EAPでも世代によって対応仕様が異なるため、製品名だけでなく、サーバーのメジャー・マイナーバージョンとJavaランタイムを指定して比較することが欠かせません。
OpenShiftを使う場合は、コンテナイメージやレジストリ、ネットワークポリシーを一つの運用設計にまとめやすくなります。Secretsや監視に加え、バックアップやパッチ適用も、同じ設計で扱えます。ただし、アプリの機能開発や業務移行は別のSIパートナーが担う場合もあるため、レッドハットの製品サポートと開発会社の役割を分けて確認してください。
得意領域・実績と確認事項
既存のJBoss EAP資産を持つ企業、複数クラウドやオンプレミスで配備先を標準化したい企業、運用部門がコンテナの更新・監視・脆弱性対応をまとめたい企業に向いています。業務システムを移行する場合は、EARやWARの構成、JNDI、トランザクションなどを洗い出してから、PoCを行います。
問い合わせ時には、JBoss EAP 8.1など対象バージョンの対応仕様と、Java 17・21のサポートを確認します。OpenShiftの契約やクラスタ運用、アプリ開発パートナー、障害時の一次窓口も、あわせて確かめます。標準仕様へ合わせる範囲と、旧環境固有の設定を残す範囲を決めると、移行後の保守費用を低く保つことにつながります。
Payara Services｜Jakarta EEの専門性と商用サポート
Payara Servicesは、Jakarta EEランタイムのPayara ServerやMicroProfile対応の基盤を提供する専門ベンダーです。
大手SIerのように業務システム全体を請け負う会社とは役割が異なるため、Payaraの製品サポートや移行支援、アプリ開発を、どの契約先へ依頼するかを分けて考える必要があります。
特徴と強み
Payaraの公式リリースノートでは、Payara Platform Community 7.2026.5の対応範囲が示されています（出典: Payara Community「Release notes 7.2026.5」、2026年）。
- 対応仕様：Jakarta EE 11とMicroProfile 6.1、Jakarta EE 11アプリケーションをサポートするとされています。
- 適合性の公開：同社はPayara Server 7.2026.2について、Jakarta EE Platform 11のTCK結果も公開しています。
- 軽量な基盤の選択：仕様への適合性を確認しながら、Java基盤やマイクロサービスを検討できる点が特徴です。
- 運用の費用：Community版の利用費が低くても、本番環境では、アップデートや脆弱性対応、障害解析などに人員と費用がかかります。
- 脆弱性対応：2026年のリリースノートにCVEへの対応が記載されています。採用時は、脆弱性情報の監視役とパッチの期限を契約に書いておくことが必要です。
得意領域・実績と確認事項
標準仕様を重視してベンダーロックインを抑えたい企業、既存のGlassFish系資産を移行したい企業、Jakarta EE 11とMicroProfileを使ったAPI・マイクロサービスを小さく始めたい企業に向いています。Payaraの顧客事例は参考になりますが、業務量や可用性、データベースが自社と同じとは限らないため、PoCで確認してください。
相談時は、Payara Serverの対象エディションやJava 17・21・25の対応状況を確認します。Jakarta EE 11の利用Profileや商用サポートの受付時間、既存のjavax資産からの移行範囲も、質問に含めます。
コンテナイメージやパートナーによる日本語支援についても、質問に入れておくと確認が進みます。製品を選ぶ会社と業務アプリを作る会社が別になる場合は、障害の切り分け方法と費用負担も先に決めてください。
Jakarta EEのシステム開発会社を選ぶポイント
6社は、業務範囲や既存資産、必要な可用性、社内の運用要員といった自社の条件に合わせて比べます。
Jakarta EE 11が公開された後も、各社の製品対応時期やサポート範囲は異なるため、公開ページを読んだうえでRFPに具体的な質問を入れることが必要です。
実績と経験の確認方法
実績は「Javaの開発経験があります」という説明だけで判断せず、対象の仕様と運用条件を確認します。Java EE 7・8からJakarta EE 9以降へ移行した件数や、javaxからjakartaへの変更、利用したアプリケーションサーバーを質問してください。
可能であれば、自社と同じ業界や利用者数に近い事例を聞いてください。課題や期間、移行データ量、稼働後の保守体制まで確かめると、事例の中身が見えてきます。ベンダーの公開事例は、導入企業名だけでなく何を改善した事例かを読みます。
OracleのCERN事例やPayaraの顧客事例のように、公式発表には技術構成が書かれることがありますが、実際の性能・費用・期間は契約条件と業務量で変わります。必要なら秘密保持契約を結び、匿名化したサンプルデータで移行と性能の検証を依頼します。
技術力と専門性の評価
技術評価では、次の3点を確かめると、移行のしやすさを比べられます。
- 仕様の範囲：Jakarta EE 11のPlatform、Web Profile、Core Profileのどれを使うかと、API単位の対応表
- 構成図：Java 17・21、アプリケーションサーバー、データベース、キャッシュ、メッセージングを一つの図にまとめたもの
- 標準仕様との区別：標準仕様とベンダー固有機能を色分けしたもの
構成図には、Maven依存関係やSSO、WAF、ログ基盤も同じ図にまとめてもらいます。
Jakarta EE 11は2025年6月26日に一般提供され、Jakarta Data、TCKの改善、Java 21のVirtual Threadsなどが強化されました（出典: Eclipse Foundation「Jakarta EE 11 Release」、2025年）。
ただし、仕様が新しくても既存ライブラリや周辺製品まで一度に対応するとは限りません。単体や結合、性能の各テストを、どの環境で誰が実施するかまで確認します。
プロジェクト管理体制と費用の確認
費用はJakarta EEを採用するだけでは決まらず、業務の複雑さや画面数、API数、連携先、データ移行などで変わります。初期費用の目安は、小規模Web業務アプリで300万〜1,000万円、中規模業務システムで1,000万〜5,000万円、大規模・基幹システムで5,000万円〜1億円以上です。
既存Java EEからの移行は500万〜5,000万円以上、期間は4〜18か月程度が参考レンジです。いずれもJakarta EE専用の公的統計ではなく、業務システムの一般的な条件を読み替えた予算検討用の目安です（出典: NotebookLM「業務システム全般_17」Q&A整理、2026年）。
要件定義10〜12%、設計・環境構築22〜24%、実装48〜50%、テスト15〜17%という配分で見積もりを分けると、テストや移行を削った見積もりかどうかを確認しやすくなります。保守運用は初期開発費の年15〜25%または月15万〜80万円程度が一般的な目安です。24時間監視やSLA、脆弱性対応を含むかで変わるため、5年間の総額で比べます。
よくある質問（FAQ）
Jakarta EEのシステム開発会社を比べるときに多い質問を取り上げます。技術の新しさだけでなく、既存資産の移行、費用、運用責任をセットで確認すると、判断しやすくなります。
Jakarta EEのシステム開発費用はいくらですか？
小規模Web業務アプリなら300万〜1,000万円、中規模なら1,000万〜5,000万円、大規模・基幹なら5,000万円〜1億円以上が初期予算の参考です。Java EEからの移行は、対象アプリの数、javax依存、データ量、サーバー切替、回帰テストで大きく変わるため、500万〜5,000万円以上という幅で見ておく必要があります。
クラウド、ライセンス、保守、監視、バックアップは開発費とは別に見積もってください。
Java EEからJakarta EEへ移行できますか？
移行できますが、Java EE 8以前の資産をJakarta EE 9以降へ移す場合は、javaxからjakartaへの名前空間変更が基本的な確認事項です。
アプリのソースや依存ライブラリ、XML、テストコードを洗い出します。サーバー固有設定や認証、JNDI、メッセージングも対象に入れ、段階移行と回帰テスト、旧環境との並行稼働を計画してください。
Jakarta EEとSpringはどちらを選べばよいですか？
選ぶ基準は、既存資産、標準仕様の重視度、チームの経験、実行基盤、運用方針です。どちらが常に優れているとは限らないため、この5点で比べます。
Jakarta EEはアプリケーションサーバーと標準APIの互換性、トランザクション、認証、移植性を重視する企業システムに向き、Springは既存の開発体制や周辺ライブラリを活用しやすい場合があります。
候補会社に同じ業務要件で両案を出してもらい、5年間の開発・保守・移行費用と運用リスクを比較します。
まとめ
Jakarta EEのシステム開発会社を選ぶときは、riplaと、富士通、IBM、日本オラクル、レッドハット、Payaraを、同じRFPで比べます。riplaは業務整理から開発・定着まで伴走する会社で、ほかの5社は実行基盤や大規模SI、専門ランタイムに強みを持つベンダーです。
Jakarta EE 11はJava 17以上を前提に、Jakarta DataやJava 21の機能を取り込みながら進化していますが、自社の既存資産と運用要件に合うかを検証することが先です。
6社の違いを自社条件に当てはめる
業務要件を整理しながら柔軟に開発を進めたい場合はripla、大規模SIと企業向けJava基盤を重視する場合は富士通が候補になります。Open Libertyでコンテナやクラウドネイティブ化を進めたい場合はIBM、WebLogicやOracle製品群を活用する場合は日本オラクルです。
JBoss EAPとOpenShiftで運用を標準化する場合はレッドハット、Jakarta EE 11の専門ランタイムと商用サポートを比べる場合はPayaraが候補になります。
これは順位ではなく、公開情報をもとに整理した、適合しやすい条件です。
発注前にそろえる資料
発注前には、現行アプリの構成、Java・サーバーのバージョン、DBと外部連携をそろえてください。利用者数や同時接続数、処理量、必要な稼働時間も、資料に書き添えておきます。移行対象データや認証・権限、保守時間まで並べると、候補会社の提案を比べやすくなります。
候補会社には「Jakarta EE 11のどのProfileを使うか」「標準機能と固有機能の境界はどこか」「5年間の総額はいくらか」「脆弱性対応と契約終了時のデータ返却を誰が担うか」を、同じ条件で質問します。
まずは1業務・1連携・1環境のPoCで、認証やデータ登録、トランザクションを確認し、その結果を本番見積もりに反映させてください。技術仕様だけでなく、利用部門が使い続けられる業務設計と、運用担当者が無理なく保守できる体制まで含めて選ぶことが、Jakarta EEのシステム開発を成功させる近道です。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。