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

WildFlyのシステム開発は、六つのフェーズで進めます。まず要件整理と技術検証を行い、次に設計・開発とテストに進みます。稼働と定着まで、この順に進めると、技術課題と業務課題を切り分けやすくなります。

WildFlyの全体像については、WildFlyのシステム開発の完全ガイドの記事も併せてご覧ください。

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

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

WildFlyはアプリとDBの間で処理を担います。

WildFlyは、Java製の画面やAPI、バッチ、企業間連携を動かす実行基盤です。業務アプリそのものとは役割が違います。

業務フローやデータ項目を実装するアプリと、そのアプリを安全に稼働させる基盤は、分けて考えます。分けておくと、見積もりの抜けを防ぎやすくなります。

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

代表的な構成は、利用者や外部システムからロードバランサー、ApacheやNginx、WildFly、DBの順に処理が続きます。この構成には、監視・ログ・バックアップも含まれます。

アプリ機能：Undertow、CDI、EJB、JPA、Hibernateを備えた構成。
連携機能：JTA、Jakarta REST、WebSocket、Jakarta MessagingとArtemisの組み合わせ。
受注処理：在庫・顧客・請求を一つのトランザクションで更新し、会計システムへ送る。
高可用性：複数ノード、セッション共有、分散キャッシュ、DB冗長化の設計。

OSSの無料性と商用サポートの違い

WildFlyはOSSのため、ランタイムのダウンロードや実行に製品ライセンス料は原則かかりません。

無料で使えることと、企業が安心して運用できることは、別に考える必要があります。

障害対応：ログ解析を担う担当者。
脆弱性対応：公開される情報を確認する担当者。
保守期間：対象バージョンを維持する期間。

JBoss EAPは、WildFlyを基に製品化・認証・長期サポートの考え方を加えた商用の選択肢です。また、Red Hat公式資料では、JBoss EAPはWildFlyを基盤とし、オンプレミスや主要クラウド、OpenShiftへの展開を支援するとされています。

コミュニティ版の自社運用、OSSサポート会社との契約、商用EAPへの移行は、要件定義の段階で比べておくと判断の材料になります。

2026年のバージョンとAPIの組み合わせ

2026年7月公開のWildFly 41は、Jakarta EE 11のPlatform・Web・Core Profileに対応します。また、MicroProfile 7.1もサポートします。

バリアント：標準版、WildFly EE 10、WildFly Preview。
テスト済みJava版：Java 25、21、17（出典: WildFly公式「WildFly 41 is released!」、2026年7月）。

既存アプリがJava EE時代のjavax系APIを使っている場合は、Jakarta EEのjakarta系APIへの移行が必要になる可能性があります。

開発を始める前に、WildFlyとJavaの版、標準版・EE 10・Previewの選択、既存アプリの互換性を決めておきます。

ポイント

業務アプリと、それを動かすWildFlyの基盤は別々に見積もるのが基本です。無料のOSSでも、障害対応や保守の担当は別途決めておく必要があります。

WildFlyのシステム開発の進め方

WildFly開発は六つのフェーズに分けて進めます。フェーズごとに区切ると、技術課題と業務課題を切り分けて考えられます。

既存Javaシステムを移行する場合は、互換性を先に調べておきます。最後にまとめて修正する進め方は避けます。

1. 要件整理フェーズでの業務・非機能・移行範囲の確定

要件整理では、次の観点で業務の流れ、非機能の条件、移行の対象を具体化します。

業務：利用者・頻度・データ、画面、権限、締め処理、承認、エラー対応。
選定理由：外部連携の方向と、トランザクション・Java資産・API・認証の要件。
非機能：ピーク同時利用者数、1時間あたりの処理件数、応答時間、稼働時間、RTO、RPO、保持期間。
認証・運用：監査ログ、バックアップ、障害通知、社内ID基盤やKeycloakとのOIDC、Elytron。
移行：Java・WildFly・JBossの版、デプロイ形式、JDBC、独自モジュール、設定、javax系・独自API。

移行、作り直し、廃止の対象は一覧にします。互換性が分からないものは、本開発の前に検証しておきます。

ここで決めた数値は、クラスタ、DB、監視、テスト工数の根拠になります。

2. 選定フェーズの小さな検証

新規開発では、構成を機能の多さよりも要件との適合性で比べます。

候補：Spring Boot単体、Tomcat、WildFly、WebLogic、WebSphere、JBoss EAP。
WildFlyが合いやすい要件：トランザクション、JPA、認証、メッセージング、既存Java EE資産。
別構成も候補となる要件：少数サービスで軽量なAPIを運ぶ場合。

社内の運用スキルが重視される場合も、WildFlyが合理的になりやすい一方で、別構成が適する場合もあります。

検証では、代表的な画面やAPI、認証、DBアクセス、外部連携を一つずつ選び、対象の版で動かして確かめます。なお、移行の場合は、javaxからjakartaへの修正、独自ライブラリの置換、設定差分、性能変化を課題表に記録します。

検証の結果は、未解決の課題、対応方針、追加工数、採用を中止する条件を含めてまとめます。

3. 設計開発フェーズでの基盤とアプリの一体設計

基盤とアプリは合わせて設計し、構成と実装方針を決めます。

配置：画面・API・バッチ、standalone・managed domain、ノード数。
基盤：ロードバランサー、セッション、DB接続プール、ログ、証明書、管理系の分離。
コンテナ：Docker・KubernetesでのGalleonやBootable JARとCI/CDの比較。
セキュリティ：Elytron、認証・認可・TLS、資格情報、管理ポート、秘密情報、監査ログ保持。
実装・設定：標準Jakarta EE APIの優先と、WildFly固有設定や独自モジュールの絞り込み。

監査ログの保持年数も決めておきます。なお、IPAの2026年ガイドでも、委託先の対策把握と脆弱性対応の確認が示されています（出典: IPA、2026年）。

管理CLI、設定ファイル、Infrastructure as Code、CI/CDで本番の設定を再現できるようにしておくと、開発環境との差や将来のバージョンアップの工数を抑えられます。

4. テストフェーズでの正常系以外の確認

テストは、正常に動く場合だけでなく、性能・障害・移行時の条件も含めて計画します。

試験区分：単体、結合、総合、性能、セキュリティ、障害復旧。
異常時：DB接続枯渇、ノード停止、外部API遅延、メッセージ重複、証明書切れ。
性能：ピーク応答、同時実行、CPU・メモリ・ヒープ、GC、DBロック、ログ量。
移行：匿名化した本番相当データでの変換、名寄せ、重複、欠損、文字コードの確認。
リハーサル：複数回の実施で確かめる所要時間、停止時間、切戻し条件、照合方法。

性能の測定値は、要件の同時利用者数、時間あたりの処理件数、許容応答時間と比べます。基準に届かない場合は、アプリ、WildFly、DB、ネットワークのどこを調整するかを切り分けます。

発注者側のマスタ整理やデータ提供が遅れると、開発会社の工数だけでは解決できません。そのため、発注者と開発会社の役割分担は、計画書と契約書に明記しておきます。

5. 稼働フェーズでの切替と切戻しの管理

切替の前に、本番環境と当日の判断に必要な手順や担当をそろえておきます。

構築・権限：本番構築手順書、アカウントと権限一覧。
運用準備：監視項目、バックアップ・リストア、障害連絡網、切替判定表。

リリース当日は、作業者、承認者、利用部門、データ移行担当、問い合わせ窓口の役割を分けておきます。

切替は次の順序で行います。

事前バックアップを取る。
最終データを抽出する。
データを移行する。
件数を照合する。
接続を確認する。
主要業務のスモークテストを行う。
利用開始を承認する。

移行が遅れた場合、重要データの照合に失敗した場合、性能基準に届かなかった場合は、あらかじめ決めた条件に基づいて旧環境へ戻します。

切戻しを事前に決めておかないと、判断が遅れ、業務の停止が長引きます。

6. 定着フェーズでの運用の自社化

運用を定着させるための手順、責任者、納品物は、開発会社から引き継ぎます。

日常対応：操作研修、業務判断を含む手順、受付、一次切り分け、ログ、連絡、再発防止。
保守：権限の棚卸し、証明書の更新、パッチ適用、バージョンアップの責任者。
設計資料：ソース、基本・詳細設計、構成図、WildFly設定、DB定義。
運用資料：テスト証跡、移行結果、監視設計、バックアップ・障害対応・リリース手順。
引き継ぎ：教育資料、課題一覧、自社で構成と復旧手順を説明できる状態。

ポイント

六つのフェーズの一つでも飛ばすと、技術課題と業務課題の切り分けが崩れるおそれがあります。移行案件では、互換性の確認を本開発より前に済ませているかを基準にしてください。

WildFlyのシステム開発にかかる費用相場

費目ごとに分けると、初期費用と運用費を整理できます。

WildFly固有の受託開発価格を公開している会社は少なく、ここに示すのは2026年の一般的なJava・業務システム相場からの推定です。

WildFlyの基盤構築・移行・運用の作業量も踏まえた目安です。本体のライセンス料は原則不要です。ただし、システム全体の費用は無料になりません。

予算は、アプリ開発、基盤、データ、テスト、運用、サポートの項目ごとに分けて考えます。

規模別の費用レンジと開発期間

移行範囲や可用性の要件によって案件規模が変わり、費用と開発期間にも幅が出ます。

技術検証・移行アセスメント：50万〜150万円、2〜6週間程度。
小規模な社内業務システム：300万〜800万円、3〜6か月程度。
部門横断システム・API基盤：800万〜2,000万円、6〜12か月程度。
既存Javaアプリの本格移行・刷新：1,000万〜3,000万円、6〜18か月程度。
高可用性の基幹系・大規模システム：2,000万〜1億円以上、12〜24か月以上の場合があります。

この金額は、要件定義、開発、移行を含めた推定です。さらに、DB、連携、冗長化、試験、教育、保守も含めています。WildFlyの価格表ではありません（出典: SIA株式会社「システム開発の費用・相場 2026年版」およびリサーチノートによるWildFly作業量の整理）。

費用を左右する主な項目

費用を最も左右するのは、画面数よりも業務ルールと連携の複雑さです。

業務の複雑さ：権限、承認、締め処理、在庫・請求、外部API、非同期処理。
データ・基盤：帳票、既存データ変換、クラスタ、セッション、負荷分散、監視、ログ、復旧。
人月単価：一般的な公開目安は60万〜200万円程度。
単価の条件：経験、地域、契約形態、PM・アーキテクトの関与、セキュリティ要件。
見積内訳：要件定義、設計、実装、試験、移行、教育、管理ごとの人月。

ランニングコストとサポート費の見積もり

初期開発費とは別に、運用保守とサポートの年間費用や契約条件も見積もっておきます。

保守費の目安：一般的なスクラッチ型では、初期開発費の年15〜20％程度を見込むことがあります。
金額例：開発費1,000万〜2,000万円の場合は、年150万〜400万円、月12.5万〜約33.3万円が一つの予算目安です。
別途費用：24時間監視、夜間対応、脆弱性調査、オンサイト、クラウド、バックアップ、商用支援。
契約条件：対象版、受付・回答時間、調査範囲、緊急連絡、修正版、SLA、再委託、終了後の引き継ぎ。

なお、これらはWildFly固有の料金ではありません。追加費用は契約内容によって異なります。また、対応体制がないと、業務停止の損失が大きくなります。

「無料」「問い合わせ可能」の表示だけで決めるのは避け、サポート条件を確かめます。

ポイント

予算を組むときは、本体のライセンス料だけでなく、運用保守とサポートの費用を初期費用とあわせて見積もれているかを基準にしてください。

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

3つの論点をそろえると各社の提案を見比べやすくなります。

見積もりの精度は、依頼先の技術力だけでなく、発注者が前提をそろえられるかでも決まります。依頼内容が曖昧なままだと、画面数、移行範囲、性能、保守の解釈が会社ごとに変わってしまいます。そのため、同じRFPを複数社へ渡し、見積もりの差が出た理由を確認します。

RFPに明記するバージョン・性能・移行範囲

RFPには、各社が同じ条件で見積もれるよう、対象範囲と要件を具体的に書きます。

対象業務・環境：利用者、権限、画面・API・バッチ数、既存構成、Java・WildFlyの現行版と希望版。
連携・移行：javax・jakarta、DB、外部連携、クラウド・オンプレ、新規・移行、対象、並行稼働、停止時間。
非機能要件：ピーク同時接続、処理件数、応答時間、稼働率、RTO・RPO、ログ、バックアップ、監査、診断、パッチ、連絡時間。
未確定事項：性能・可用性を見積もりに含めるか、先にアセスメントするかの区別。
納品物：ソース、設計、設定、CLI、テスト、移行、監視、バックアップ、運用、教育、ライセンス、SBOM、課題、引き継ぎ資料と形式。

未確定のまま一式で見積もると、後から追加費用になりがちです。そのため、確定していない前提は分けて書きます。

開発会社の比較：WildFly経験と担当体制

開発会社を比べるときは、WildFlyの技術経験に加えて、今回の担当者、委託の範囲、対応体制も見ておきます。

技術経験：WildFly版、Java 17・21・25、Jakarta EE、Elytron・OIDC、コンテナ、DB、LB、監視、障害対応。
担当体制：案件担当のアーキテクト・エンジニアと設計レビュー担当。
委託方法：基盤とアプリを一社へ、OSS支援と分担、クラウド・監視会社との組み合わせ。
公開情報の例：SCSKのJBoss EAP技術支援、サイオステクノロジーのOSSよろず相談室。
提案時の確認：対象版と担当体制の確認（公開情報のみで判断しない）。

NRI OpenStandiaのWildFly情報や、KMDのWildFly導入・DB移行事例もあります。

追加費用と責任分界の契約前の確認

見積もりの金額が安く見えるときは、作業の対象範囲を確かめ、契約前に責任分界と条件を具体化します。

含まれる作業：要件定義、データ整備、負荷試験、脆弱性診断、移行リハーサル、教育、監視、安定化支援。
一式項目：作業、成果物、完了条件、前提、対象外の別紙への記載。
責任分界：発注者データ・判断の期限、仕様変更、再委託、知的財産権、OSSライセンス。
事故・契約終了：秘密情報、脆弱性連絡、事故報告、サポート終了時の引き継ぎ。

IPAの2026年資料でも、委託先への要求の把握や、契約・第三者検証による対策が示されています（出典: IPA「製品開発者向け・製品利用者向けガイド」および委託時のセキュリティ実践資料、2026年）。

JUASの2026年調査では、2025年度の企業IT動向として、IT予算を増やす見込みの企業が約52.6％と紹介されています（出典: JUAS「企業IT動向調査2026」発表資料）。

予算が確保されやすい時期でも、増額分を機能追加だけに使わないようにします。移行、セキュリティ、運用定着に配分すると、長期的な費用の安定につながります。

ポイント

見積もりを比べる前に、RFPの前提と担当体制が各社で同じ条件になっているかを確かめてください。前提がそろわない見積もりは、金額の差を単純に比べられません。

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

採用や発注の際は、費用、製品の違い、移行の可否、保守の考え方を押さえておきます。

WildFlyは無料なので、システム開発も無料ですか？

いいえ。WildFly本体のライセンス料は原則不要ですが、システム開発の費用は無料になりません。

要件定義、アプリ実装、サーバーやDBの構築に、それぞれ費用がかかります。データ移行、試験、監視、バックアップも、費用の対象です。

クラウド利用、保守、商用またはOSSサポートの費用も発生します。

古いJBossやJava EEのシステムをWildFlyへ移行できますか？

移行できる可能性はありますが、現行環境のAPI、Java版、ライブラリ、設定、DB、認証方式を調べたうえで判断します。

互換性：javax系からjakarta系への変更。
既存依存：WebLogic・WebSphere独自API、古いJDBC、固定記述の設定。

代表的な機能を対象に、2〜6週間程度のアセスメントを先に行うと、後工程の不確実性を下げられます。

WildFlyはオンプレミスとクラウドのどちらに置くべきですか？

配置先は、社内統制、環境変更の速さ、運用責任、復旧要件を比べて決めます。

オンプレミス：社内ネットワーク、規制、機器統制、運用人員を重視する場合。
クラウド：環境の増減やバックアップ・冗長化の自動化を重視する場合は、AWS・Azure・GCPのIaaSやコンテナ基盤が候補になります。
運用責任：クラウドにしても、OS、WildFly、DB、ネットワーク、バックアップ、監視、費用管理は残ります。
判断材料：RTO、RPO、ピーク負荷、運用スキル、月額予算。

開発後のWildFly運用は誰に任せればよいですか？

運用を任せる先と、障害・保守の対応範囲は、契約で明確にしておきます。

担当候補：アプリ開発会社、基盤構築会社、OSSサポート会社、自社チーム。
障害調査：一次受付に加え、アプリ、WildFly、Java、DB、ネットワークの範囲。
保守条件：対象版、対応時間、脆弱性情報、パッチ、構成見直し、版上げ計画。

まとめ

WildFlyの開発では、業務アプリと、それを動かす基盤を一体で設計します。基盤では、Java・Jakarta EE、DB、ネットワークの構成を決めます。認証、監視、移行、運用も、この設計の中で扱います。

OSSの無料性は利点です。ただし、開発・移行・セキュリティ・保守の費用と責任は、別に見積もります。

発注前の六つのフェーズの確認

見積書に、六つのフェーズで必要な作業が含まれているかを確かめます。

要件整理：業務・非機能要件・移行範囲。
選定：対象版と技術検証。
設計開発：クラスタ・認証・監視・再現可能な設定。
テスト：性能・障害復旧・移行照合。
稼働・定着：切替と切戻し、手順書・教育・保守体制。

含まれていない項目は、見積もりの対象外として明示してもらいます。

最初の一歩となるアセスメントまたは要件整理

開発範囲を決める前に、既存移行か新規開発かに応じた準備を進めます。

既存Javaの移行では、全面刷新の見積もり前に代表アプリ、認証、DB、外部連携を対象にアセスメントを依頼します。
新規開発では業務フローと非機能要件を一枚にまとめ、同じ前提で複数社へ提案を依頼します。
WildFly 41やJava 25を採用する場合、互換性と保守体制を確認してから範囲を決めます。

この準備があれば、必要な構成、予算、開発会社の役割、運用後の責任を比べられます。

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

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