Jakarta EEのシステム開発でおすすめの開発会社/ベンダー6選と選び方

Jakarta EEのシステム開発会社を選ぶなら、標準仕様への対応だけでなく、Java EEからの移行、認証・データ連携、クラウド運用まで一貫して確認できる会社を選ぶことが重要です。

Jakarta EEは、販売管理、受発注、会員管理、基幹連携、決済、社内ポータルなど、長期運用と可用性が求められる業務システムに活用される企業向けJavaの標準仕様群です。本記事では、株式会社riplaを最初に、大規模SI・実行基盤に強い富士通、IBM、日本オラクル、レッドハット、Jakarta EE専門ベンダーのPayaraを、計6社として紹介します。各社の公開情報、向いている案件、確認すべき質問、費用の考え方を整理します。

▼全体ガイドの記事
・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枚にまとめます。新規開発か移行か、オンプレミスかクラウドか、Web ProfileかPlatformか、データベースやメッセージングをどこまで含めるかをそろえてから、2〜3社へ同じRFPを渡してください。

見積もりでは、要件定義、設計、実装、テスト、データ移行、性能試験、脆弱性診断、監視、バックアップ、教育、保守を分けてもらいます。保守契約には、Javaやサーバーのバージョンアップ、脆弱性情報への対応、障害受付時間、復旧目標、契約終了時のソースコードとデータの扱いまで含めると、初期費用だけでは分からない差が見えます。

株式会社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の設立を準備し、Eclipse Foundation内のステアリング委員会、仕様策定委員会、マーケティング委員会にStrategic memberとして参加したと公式発表しています（出典: 富士通「Jakarta EEをサポートするワーキンググループがEclipse Foundation内に設立」、2018年）。標準仕様の動向を追いながら、既存のInterstageやJava資産、クラウド移行を含めて検討できる点が特徴です。

一方、Enterprise Application Platformの公開情報はJakarta EE 10互換の説明が中心です。Jakarta EE 11を前提にする案件では、対応製品のバージョン、Java 17・21のサポート、利用可能なProfile、既存アプリの移行支援範囲を個別に確認し、資料に記載された対応世代を最新情報として断定しないことが重要です。

長期稼働する基幹システム、複数拠点・複数部門の業務、公共・金融のように可用性と監査が重要な案件で比較しやすい会社です。オンプレミスからコンテナやクラウドへ段階的に移行する場合は、現行システムの依存関係、データ移行、並行稼働、障害復旧を含む計画を作ってもらいます。

見積もり前には、担当する法人・部門、開発を担う体制、標準製品と個別開発の境界、ライセンス費、24時間運用の有無を確認してください。富士通の製品を採用する場合でも、アプリケーション開発、クラウド基盤、データベース、監視の契約先が一つとは限らないため、責任分界表を作ると比較しやすくなります。

日本アイ・ビー・エム株式会社｜Open Libertyでクラウドネイティブ化を進める

日本アイ・ビー・エム株式会社は、企業向けのクラウド、アプリケーション、データ、セキュリティを支援するITベンダーです。IBMのOpen Libertyは、軽量なJavaランタイムとしてJakarta EEアプリケーションをコンテナやクラウドで動かす構成を検討しやすく、IBMの公式ドキュメントではJakarta EE 11のPlatform、Web Profile、Core Profileを含む対応表が公開されています。

Open Libertyは必要な機能だけを組み合わせる構成を取りやすく、従来の大きなアプリケーションサーバーから、サービス単位・コンテナ単位へ段階的に見直したい企業に向いています。Jakarta EE 11の対応範囲をAPI単位で確認できるため、REST、JPA、CDI、Security、Messagingなど、自社アプリで使う機能の互換性を先に検証できます。

ただし、Jakarta EEの仕様対応と、アプリケーション開発・移行・運用の請負範囲は別に確認する必要があります。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 Server and Coherence 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、トランザクション、メッセージング、認証、外部DB接続を棚卸ししてから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がJakarta EE 11とMicroProfile 6.1、Jakarta EE 11アプリケーションをサポートすると記載されています（出典: Payara Community「Release notes 7.2026.5」、2026年）。さらに、同社は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の顧客事例のように、公式発表には技術構成が書かれる場合がありますが、実際の性能・費用・期間は契約条件と業務量で変わります。必要なら秘密保持契約を結び、匿名化したサンプルデータを使って移行と性能の検証を依頼してください。

技術評価では、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のシステム開発会社を比較するときに多い質問へ回答します。技術の新しさだけでなく、既存資産の移行、費用、運用責任をセットで確認することがポイントです。

小規模Web業務アプリなら300万〜1,000万円、中規模なら1,000万〜5,000万円、大規模・基幹なら5,000万円〜1億円以上が初期予算の参考です。Java EEからの移行は、対象アプリの数、javax依存、データ量、サーバー切替、回帰テストで大きく変わるため、500万〜5,000万円以上という幅を持たせます。クラウド、ライセンス、保守、監視、バックアップは開発費とは別に見積もってください。

移行できますが、Java EE 8以前の資産をJakarta EE 9以降へ移す場合は、javaxからjakartaへの名前空間変更が基本的な確認事項です。アプリのソース、依存ライブラリ、XML、サーバー固有設定、認証、JNDI、メッセージング、テストコードを棚卸しし、段階移行、回帰テスト、旧環境との並行稼働を計画してください。

どちらが常に優れているということではなく、既存資産、標準仕様の重視度、チームの経験、実行基盤、運用方針で選びます。Jakarta EEはアプリケーションサーバーと標準APIの互換性、トランザクション、認証、移植性を重視する企業システムに向き、Springは既存の開発体制や周辺ライブラリを活用しやすい場合があります。候補会社に同じ業務要件で両案を出してもらい、5年間の開発・保守・移行費用と運用リスクを比較してください。

まとめ

Jakarta EEのシステム開発会社を選ぶときは、riplaのように業務整理から開発・定着まで伴走する会社と、富士通、IBM、日本オラクル、レッドハット、Payaraのように実行基盤や大規模SI、専門ランタイムに強みを持つベンダーを、同じRFPで比較してください。Jakarta EE 11はJava 17以上を前提に、Jakarta DataやJava 21の機能を取り込みながら進化していますが、自社の既存資産と運用要件に合うかを検証することが先です。

業務要件を整理して柔軟な開発を進めたい場合は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のシステム開発を成功させる近道です。

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