相談する

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

JBossのシステム開発は6フェーズで進めます。まず要件整理と選定を行い、設計・開発から定着までを順に進めます。現行資産の整理から定着まで一つの流れで管理すると、移行と運用の課題を抑えられます。

全体像の詳細は、JBossのシステム開発の完全ガイドもご覧ください。

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

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

JBossのシステム開発の全体像

JBoss EAPの機能をWeb実行基盤、業務処理とデータ、連携と制御、管理機能の4層で示した図解
アプリ実行から管理まで、役割ごとに整理できます。

ここでいう「JBossのシステム」は、Javaの業務アプリを動かすアプリケーションサーバーやミドルウェアを指します。企業向けではRed Hat JBoss Enterprise Application Platform（JBoss EAP）が中心になります。無償のコミュニティ系WildFlyとは、サブスクリプションやサポートが付くかどうかで区別して考えます。

業務アプリを動かす実行基盤としてのJBoss

JBoss EAPは、Webからの受付、業務処理とデータ、連携と制御、運用管理の層で業務アプリを動かします。構成は、システムの規模と停止の許容度で選びます。

  • Web実行基盤：Undertow、Servlet、JAX-RS
  • 業務処理とデータ：EJB・CDI、JPA・Hibernate
  • 連携と制御：JMS・ActiveMQ Artemis、JDBCデータソース・接続プール、トランザクション、Elytron
  • 管理機能：管理コンソールやManagement CLIでデプロイ、設定、ログ、状態を管理
  • 構成：単一の社内システムはStandalone、停止できない受発注・会員・金融・基幹業務は複数ノードで、監視、バックアップ、復旧まで設計

典型的な構成では、ブラウザや外部APIからの接続が、ロードバランサーとWebサーバーを経てJBoss EAPへ届きます。JBoss EAPは、業務データベース、メッセージング基盤、外部サービスとも連携します。

JBoss EAP・WildFly・再構築の違い

製品ごとのサポート範囲と移行時の負担は、比べると次のような違いがあります。

  • JBoss EAP：既存Java EE・Jakarta EE資産、サブスクリプション、検証済み構成、パッチ、サポートを重視
  • WildFly：OSSとして導入しやすい一方、パッチ選別、互換性検証、障害切り分け、商用サポートを自社または支援会社が担う
  • 軽量構成：新規の小規模APIではSpring BootやQuarkusも候補になる場合がある
  • 再構築の注意：EJB・JMS・JPA、分散トランザクション、既存運用手順を捨てると移行費用が発生
  • 判断方法：障害・脆弱性対応を含む総コストと、現行資産の活用範囲を要件整理で比較

現行資産を活かすのか、業務ロジックも含めて作り直すのかを先に分けておくと、後からの費用増加を防げます。

ポイント

JBoss EAPとWildFlyのどちらを選ぶかは、商用サポートを受けるか、パッチや障害対応を自社で担うかで考えます。現行資産を活かすか作り直すかは、製品選定の前に分けておくと、判断の軸が定まります。

JBossのシステム開発の進め方と6フェーズ

JBoss開発の要件整理、選定、設計・開発、テストを順に並べた4つの工程パネル
各工程の完了条件を先に決めると、次の作業へ移りやすくなります。

JBossのシステム開発は6フェーズで進みます。要件整理と選定で方針を固めたあと、設計・開発からテストを経て、稼働と定着へ進みます。

サーバー構築だけなら短期間で終えられることもありますが、既存アプリの移行やクラスタ、認証、外部連携が加わると、事前の調査が必要になります。

データ移行や運用設計を含め、本番後の改善まで一つの計画で管理します。そのうえで、各フェーズの成果物と、次のフェーズへ進むための完了条件を事前に決めておきます。

フェーズ1：要件整理による目的と現行資産の洗い出し

最初に、JBoss上で何を動かすのかをはっきりさせます。

  • アプリと実行環境：WAR・EAR、JavaとJBossのバージョン
  • 技術資産：`javax.*`・`jakarta.*`、EJB、JPA、JMS、DB、JDBCドライバー
  • 連携と運用：認証、バッチ、外部API、帳票、ファイル連携
  • 設定類：起動スクリプト、環境変数、証明書、ジョブ、監視設定

業務側の条件として、発注側は利用者数、ピーク時の同時接続数、処理量、繁忙期、監査要件、データ保存期間を確認します。許容停止時間、目標復旧時間（RTO）、許容できるデータ損失（RPO）も決めます。これらは、障害時の復旧の設計に関わる値です。

成果物には、業務フロー、機能・非機能要件、現行資産・連携一覧を含めます。権限表と移行対象表も作ります。課題・前提条件一覧も作り、「載せ替え」「一部改修」「業務再設計」それぞれの範囲を明記します。

完了条件は、対象業務と環境、利用者、データ、連携の内容について承認を得ることです。性能・可用性・セキュリティの基準についても、承認を得ておきます。

たとえば、要件定義を省くと、クラスタや管理画面の公開条件が後になって問題になることがあります。また、古いJDBCドライバーの不具合が判明し、追加の開発や再テストが必要になることもあります。

フェーズ2：選定によるEAP・WildFly・基盤方式の比較

選定では、製品・実行環境と基盤方式をまとめて比べます。

  • 製品候補：JBoss EAP、WildFly、既存環境の継続、Spring Boot・Quarkusへの段階的再構築
  • 比較軸：資産再利用率、Jakarta EE、Java・DB・ドライバー互換性、サポート、パッチ、クラスタ、運用スキル、将来のクラウド移行、5年程度の総保有コスト
  • 基盤候補：オンプレミス、クラウド上のVM、コンテナ、OpenShift
  • 方式ごとの条件：オンプレミス・VMは機器更新と冗長化を自社で担い、OpenShiftはサブスクリプション・クラスタ運用・設計スキルが必要
  • PoCと会社選定：代表アプリで認証や連携、負荷・復旧を試し、対応範囲と経験構成を確認

検証では、DB接続、EJB・JMS、バッチなどの業務処理を中心に確かめます。ファイル出力、ログ、デプロイ自動化も対象に含めます。そのうえで、開発会社には、標準機能、設定での対応、追加開発、対応不可に分けて提案してもらいます。

既存のデータセンターや閉域網を活かしたい場合は、オンプレミスやVMが候補になります。また、OpenShiftでは、Operatorによる複数インスタンスの管理や、安全なトランザクション回復を使えます。

Red Hat資料では、EAP Operatorがレプリカを減らす前にトランザクションの完了を確認すると説明されています（出典: Red Hat「Using JBoss EAP on OpenShift Container Platform 8.1」、2026年確認）。

フェーズ3：設計・開発での可用性・権限・運用の作り込み

設計・開発では、可用性や権限を中心に、環境差分と移行時の互換性も定めます。

  • 基盤設計：論理・ネットワーク図、データフロー、配置、環境、権限、バックアップ
  • 管理と可用性：管理通信を業務通信と分離し、権限、TLS、秘密情報、監査、接続制限、パッチ、クラスタを設計
  • アプリ設計：データソース、接続プール、トランザクション境界、キュー、タイムアウト、リトライ、エラー処理、ログ項目
  • 変更管理：開発・検証・ステージング・本番の設定差分を管理し、可能ならIaC・CI/CDで再現。変更履歴と承認者も記録
  • EAP移行調査：EAP 8.1への移行影響を開発前に確認

複数ノードでは、セッションと負荷分散を設計し、共有ストレージやヘルスチェックも対象に含めます。障害時の切り離しやトランザクション回復についても、あらかじめ決めておきます。

EAP 8.1はJakarta EE 10に対応するため、`javax.*`から`jakarta.*`への変更を確認します。非推奨のAPI、ライブラリ、サーバー設定も調査の対象です。

管理コンソールを手作業で変更し続けると、障害時に正しい設定が分からなくなります。そのため、変更管理が必要です。

EAP 7から8.1では、コードや設定の変更が必要になる場合があります（出典: Red Hat「JBoss EAP 8.1 Migration Guide」、2026年確認）。同ガイドは、MTAやJBoss Server Migration Toolについても案内しています。

フェーズ4：テストでの互換性・性能・障害復旧の検証

テストでは、互換性、性能、セキュリティ、復旧を確かめます。

  • テスト工程：単体、結合、システム、受入、移行リハーサル
  • 機能・移行確認：主要機能と連携を試し、旧新環境の処理結果を比較
  • 性能測定：負荷条件と資源を測り、処理量・応答・エラー・復旧の目標を設定
  • セキュリティ：管理ポート、認証・認可、TLS、脆弱性、秘密情報のログ出力、権限外参照、監査ログの改ざん耐性を確認
  • 復旧と互換性：DB・設定・デプロイ資産のリストアを試し、Java 17・21を含むサポート対象構成を検証

画面・APIと業務処理（EJB、JPA、JMS）を中心に、外部連携と異常系を試験します。バッチや帳票、ファイル、認証、権限も対象に含めます。

同じ入力を使い、旧環境と新環境の結果を比べます。DB更新やメッセージの順序、ログ、処理時間も見比べます。

性能試験は、平常、ピーク、急増、長時間の各条件で行います。CPU、メモリ、ヒープ、GC、スレッドのほか、接続プール、DB待ち、キュー滞留も測ります。

目標の指標には、同時接続数、毎分の処理件数、95パーセンタイル応答時間を使います。あわせて、エラー率と復旧時間も数値で決め、監視項目を用意します。監視で得た値をもとに、ボトルネックがJBoss、DB、ネットワークのどこにあるかを切り分けます。

EAP 8.1のリリースノートでは、Java 11が非推奨で、サポート終了の扱いが示されています（出典: Red Hat「JBoss EAP 8.1 Release Notes」、2026年確認）。

バックアップは、取得だけでなく、DB、設定、デプロイ資産を復旧する手順として試験します。トランザクションやメッセージの復旧手順も使い、リストア試験まで行います。

フェーズ5：稼働での切替・切り戻し・連絡体制の決定

稼働では、切替の前後に確認する事項と、切り戻しを判断する条件を定めておきます。

  • 事前確認：移行データ、デプロイ物、設定、証明書、DNS、ロードバランサー、監視、バックアップ、利用者アカウント
  • 切替計画：開始・終了時刻、担当・判断者、作業順、確認項目、利用者告知、問い合わせ窓口、障害時のエスカレーション
  • 旧環境と展開：停止時期や参照用に残す期間はデータ整合性と費用で決定し、対象部門・時間帯を限る段階稼働も検討
  • 切替後の確認：ログイン、主要業務、DB更新、外部連携、バッチ、性能、監視通知、バックアップ
  • 切り戻し条件：重大障害、データ不整合、権限逸脱、目標性能未達などを事前合意し、感覚だけで判断しない

フェーズ6：定着での運用改善とパッチ対応

稼働後も運用を続け、監視、パッチ、訓練、定期報告を通じて改善します。

  • 継続監視：サーバー状態、CPU、メモリ、GC、スレッド、接続プール、DB、キュー、エラー、ログ容量、証明書期限
  • パッチ適用：EAP、JDK、RHEL、DB、Webサーバー、外部ライブラリの情報を確認し、検証環境で互換性を確かめて本番適用
  • 実機訓練：起動停止、デプロイ、ロールバック、ログ・接続プール調査、障害一次切り分け、バックアップ復元、セキュリティ事故時の連絡
  • 月次確認：障害件数、復旧時間、パッチ状況、性能、容量、問い合わせ、未解決課題を確認し、業務責任者と優先順位を決定
  • 契約・購入：サポート範囲、購入経路、保守契約、将来の移行支援を発注前に確認

保守会社任せにせず、社内でも改善を進めます。

2025年、Red Hatはミドルウェアの製品・エンジニアリングチームをIBM組織へ移す方針を発表しました。一方で、既存顧客はRed Hatとパートナーから購入でき、既存の関係に変更はないと説明しています（出典: Red Hat「Evolving our middleware strategy」、2025年）。

ポイント

既存アプリの移行を含む案件では、要件整理の段階で現行資産の範囲を決めておくと、後からの手戻りを防ぎやすくなります。各フェーズは、完了条件を満たしてから次へ進めます。

JBossのシステム開発にかかる費用相場とコストの内訳

既存Javaアプリの1環境構築、小〜中規模の新規業務Web・API、既存JBoss等からの移行、基幹・大規模案件の初期費用レンジを比較する横棒図
案件の規模や移行範囲によって、企画時の金額幅が広がります。

費用は、サーバー製品の料金だけでは決まりません。現行調査やアプリ改修、互換性の検証、基盤構築、クラスタ、データ移行などの作業を合算した額になります。

テストや監視、バックアップも対象です。さらに、サブスクリプション、クラウド基盤、教育、保守の費用も含まれます。

Red Hatは、JBoss EAPの日本向け定価を一律には公開していません。契約形態、環境数、CPU、サポートレベル、OpenShiftやRHELの有無によって、正式な見積もりが変わります。

企画段階で使える初期費用のレンジ

ここに示す金額は、業務システムの費用情報とJBoss案件の作業を組み合わせた、2025〜2026年時点の企画用の推定です。

  • 既存Javaアプリの1環境構築：300万〜800万円程度。EAP、JDK、DB接続、認証、デプロイ、基本テストを含む
  • 小〜中規模の新規業務Web・API：800万〜2,000万円程度。要件定義、Javaアプリ、画面・API、DB、CI/CD、運用設計を含む
  • 既存JBoss等からの移行：1,500万〜5,000万円程度。`javax`から`jakarta`への改修、クラスタ、負荷試験、移行リハーサルを含む場合
  • 基幹・大規模案件：複数拠点・複数システム連携、DR、監査、教育、段階リリースを伴う場合は5,000万円〜数億円規模

この金額は、予算の仮置きや相談範囲を決めるための目安として使います。ただし、Red Hatや開発会社が示す正式な定価ではありません。

既存資産の品質、連携数、可用性、データ移行量によって、金額は大きく変わります（出典: NotebookLM「JBossのシステム」リサーチノート、2026年）。そのため、不確実な点が残る場合は、調査やPoCを本開発から切り離して先に行うことをおすすめします。

クラウド・サブスクリプション・保守の費用の切り分け

クラウド利用料と運用・保守費は、掲載条件や契約範囲ごとに分けて確認します。

  • AWS掲載例：m5.xlargeは1時間0.244米ドル。730時間稼働なら約178米ドル／月
  • 掲載例に含まれない費用：EC2以外のRHEL、EBS、ロードバランサー、DB、バックアップ、監視、通信、為替、構築費、Red Hat契約費
  • クラウドの積算対象：検証環境1台、本番の複数台、バックアップ、ログ、待機系
  • 運用・保守の目安：初期開発費の年15〜20％。2,000万円なら年300万〜400万円、月25万〜33万円程度
  • 契約範囲：24時間365日対応、パッチ検証、性能改善、復旧訓練、監視、オンサイト対応の有無で変わるため、契約費・クラウド費・社内工数を分ける

AWSの金額は掲載された利用例で、総額ではありません（出典: AWS Marketplace「Red Hat JBoss Enterprise Application Platform」、2026年8月確認）。

ポイント

予算は、製品料金に加えて移行、テスト、保守の作業まで含めて考えます。Red Hatの定価は一律に公開されていないため、本記事の金額は企画用の目安として扱います。

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

見積もりが「環境構築一式」「移行一式」「保守一式」のようにまとめて書かれていると、JBoss案件どうしを比べにくくなります。開発会社には、要件整理や現行調査、PoCから、構築、テストまでを工程ごとに分けて出してもらいます。

データ移行や切替、保守などの費用も、製品契約やクラウド費と分けて確認します。作業の数量と完了条件を確かめたうえで、安い見積もりでは、対象外になっている作業がないかも確認します。

RFPに記載する現行環境と要件のチェック項目

見積もりの条件を揃えるため、現行環境と非機能要件を候補の会社へ共有します。

  • 環境・資産：JBoss・EAP、Java、OS、DB、Webサーバーのバージョン、WAR・EARの数と容量、EJB・JPA・JMS、外部連携
  • 業務量・運用資料：利用者・同時接続数、ピーク時間、データ量、バッチ時間、停止可能時間、設定ファイル、起動停止、監視、障害履歴、既知課題、保守期限
  • サービス水準・安全性：稼働率、RTO・RPO、応答時間、バックアップ世代、ログ保持、TLS、認証、権限、監査ログ、脆弱性対応・パッチ時間、24時間対応の要否
  • クラスタ条件：常時稼働台数、障害時の継続台数、セッションとトランザクションの扱い

発注先のJBoss経験の構成単位での確認

経験、得意分野、納品範囲、責任分界は、会社の知名度とあわせて確かめます。EAP 7から8.1への移行や、Jakarta EE、Java・DB互換性に関する経験を確認します。OpenShiftやクラウドVMでの経験も確かめます。

HA・DR、性能試験、監視、24時間運用、障害対応についても、担当者の役割と合わせて確認します。

  • 技術経験：製品・基盤と障害対応の経験を、担当役割と合わせて確認
  • 会社の得意分野：製品ベンダー、総合SIer、Javaミドルウェア専門会社、監視・性能支援会社の違いを踏まえ、役割分担も検討
  • 納品物：設計書、構成図、設定、IaC、ソースコード、テスト仕様書・結果、運用手順書、教育資料
  • 契約条件：追加変更単価、前提、顧客作業、ライセンス購入者、障害一次切り分け、再委託先、終了時の引き継ぎ

追加費用になりやすいリスクの事前解消

追加費用の原因になりやすい点を、提案の段階で確かめておきます。

  • 互換性・資産：棚卸し不足、古いライブラリ、`javax`から`jakarta`への改修、DB・JDBCドライバー非互換
  • 基盤・移行：性能不足、認証接続、データ移行、クラスタ共有設計、バックアップ復元試験、ユーザー受入の遅れ
  • 不確実性への対応：提案段階で確定できなければ調査・PoCを先行発注し、本開発へ進む条件を設定
  • 運用・契約範囲：顧客側作業として残る項目と、保守契約の対象外を確認

「本番で動けばよい」という見積もりは避けます。パッチ適用、証明書更新、ログ容量への対応は、稼働後に必ず必要になります。加えて、障害時の切り離しや切り戻し、監査資料の作成、運用担当者の教育も必要です。

提案書にない作業が顧客側へ回されていないか、保守契約の対象外になっている作業はないかを確認してください。

ポイント

見積もりは、工程・移行・契約・運用に分けて提出してもらうと比べやすくなります。「一式」の金額しか示されない場合は、対象外になっている作業の洗い出しから始めます。

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

JBossの導入や移行でよく聞かれる疑問を、現行資産、サポート、互換性、運用体制の観点から取り上げます。

JBoss EAPとWildFlyはどちらを選べばよいですか？

商用サポート、検証済み構成、パッチ、障害時の窓口を重視する企業には、JBoss EAPが候補になります。パッチ選定や障害対応を自社で担える組織であれば、WildFlyも検討できます。

比較には、ライセンス費に加えて、5年分の運用工数と責任分界も含めてください。

古いJBossからEAP 8.1へそのまま移行できますか？

古いJBossからEAP 8.1へは、そのまま移行できるとは限りません。

  • 互換性確認：EAP 7から8.1ではJakarta EE 10に伴い、`javax.*`から`jakarta.*`への変更が必要な場合がある
  • 調査対象：アプリコード、依存ライブラリ、サーバー設定、認証、DBドライバー
  • 移行計画：代表アプリでPoCを行い、改修量とテスト範囲を確定してから本番移行を計画

JBossのシステム開発費用はどのくらいですか？

費用は規模と移行範囲によって異なります。次に示す金額は、企画用の目安です。

  • 既存Javaアプリの1環境構築・設定：300万〜800万円程度
  • 小〜中規模の新規業務Web・API：800万〜2,000万円程度
  • 既存環境の移行・冗長化：1,500万〜5,000万円程度
  • 正式見積もり：製品契約、クラウド、アプリ改修、データ移行、テスト、保守の範囲を確認し、現行調査と要件定義を踏まえて算出

クラウドやOpenShiftへ移すと開発期間を短縮できますか？

クラウドやOpenShiftへ移すことで期間が短くなるかどうかは、構成やチームの状況で判断します。

  • 効率化の可能性：標準化や自動化で構築・デプロイを効率化できる場合がある
  • 必要な設計：クラスタ、永続ストレージ、ネットワーク、認証、トランザクション回復、監視、運用スキル
  • 判断・運用：停止条件とチーム経験を踏まえ、レプリカ削減やPod削除による未完了トランザクション・データ不整合の可能性も含めて手順を検証

まとめ

JBoss開発は、必要な業務アプリと可用性・性能・セキュリティを整理するところから始まります。現行資産は一覧にして、EAP・WildFly・再構築の選択肢と、オンプレミス・VM・OpenShiftの基盤を比べます。

6フェーズの完了条件による進行管理

要件整理から定着まで、6フェーズのそれぞれで成果物と完了条件を決めて進めます。EAP 8.1への移行では、Jakarta EE 10や`javax`から`jakarta`への変更を先に検証します。そのうえで、Javaのサポート対象のほか、DBやJMS、クラスタなどの構成も確認します。

作業・契約・運用に分けた費用の比較

費用の目安を把握したうえで、作業・契約・運用を分けて見積もります。

  • 既存Javaアプリの1環境構築・設定：300万〜800万円程度
  • 新規の小〜中規模業務Web・API：800万〜2,000万円程度
  • 移行・冗長化：1,500万〜5,000万円程度
  • 見積もり範囲：サブスクリプション、クラウド、アプリ改修、テスト、保守、社内工数を分け、調査・PoCで不確実性を減らしてから本開発へ進む

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

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