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

WildFlyのシステム開発は、要件整理、移行検証、開発・試験、運用引き継ぎの順に進めると、委託範囲と費用を設計しやすくなります。工程ごとに決めることと担当を先に押さえておくと、開発会社との話も進めやすくなります。

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

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

WildFlyのシステムを発注・外注する全体像

WildFlyは、Java製のWeb画面、API、バッチ、外部連携を動かすアプリケーションランタイムです。業務アプリケーションそのものとは、役割が異なります。

そのため、発注側は業務と利用者、保護するデータや水準を先に決めておきます。委託範囲を定めるには、「WildFlyを入れてほしい」という依頼に業務内容を添える必要があります。

WildFly本体と開発・運用サービスの分け方

WildFlyはオープンソースなので、実行環境の製品ライセンス料は原則としてかかりません。一方で、要件定義や画面・API開発、Java・DB・ネットワーク設計は、本体とは別の作業です。

データ移行と性能試験も、本体の費用とは別に必要です。監視や脆弱性対応も、見込んでおく必要があります。OSSを無料と見て予算を組むと、後から開発工数やクラウド料がかかり、商用サポートや障害対応の費用も発生することがあります。

発注書やRFPでは、本体の導入費とアプリ開発費を分けて書きます。さらに、初期構築と移行、運用引き継ぎ、保守契約を別項目にしておくと、作業の含まれていない安い見積もりと比べたときの取り違えを減らせます。

WildFlyが向いている業務システム

WildFlyは、トランザクションや権限管理が要る業務と相性があります。たとえば、会員管理や受発注、在庫の業務が該当します。基幹連携や認証基盤、業務API、定期バッチとも相性があります。

WildFlyでは、Undertow、JPA/Hibernate、JTAなどを組み合わせられます。Jakarta REST、Jakarta Messagingも、同じ環境で使えます。そのため、Javaの企業向け開発資産も活かしやすい環境です。

一方、静的サイトや小規模な単機能ツールでは、構成や運用が過剰になる可能性があります。採用の前に、候補と判断軸を比べておきます。

• 候補：Spring Boot単体、Tomcat、SaaSやパッケージ
• 判断軸：可用性、認証、データ整合性、既存Java資産、将来の拡張性

WildFlyを採用すること自体を目的にせず、業務要件から採用理由を説明できるようにしておきます。

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

発注は、まず企画と現状調査から始まります。続いて要件定義と移行検証を行い、そのあと設計・開発と試験に進みます。最後は本番移行と運用引き継ぎで締めくくります。

既存のJava資産を使う新規開発でも、早い段階で互換性を検証しておくことが大切です。さらに、開発会社の経験だけでなく、検証結果を判断材料として残せます。

要件定義で固める業務・非機能・移行範囲

要件定義では、利用者と業務フロー、画面や帳票を整理します。API、バッチ、外部連携も、この段階で整理し、データ保持期間も決めます。さらに、非機能要件と移行範囲は、次の観点で具体化します。

• 性能・稼働：ピーク時の同時利用者数、応答時間、稼働時間。
• 復旧・保護：復旧目標のRTO、許容データ損失のRPO、監査ログ、バックアップ、権限分離。
• 現行資産：Javaの版、javax系・jakarta系、EJB・JPA・JMS、独自API、設定、JDBCドライバ、独自モジュール。
• 移行条件：コード量、外部連携数、データ件数、マスタの欠損・重複、切替時の停止可能時間。

数十人が使う社内システムと数万人向けの顧客APIでは、構成が変わります。ロードバランサーやクラスタの組み方が違ってきて、キャッシュや監視も見直しの対象になります。移行工数は画面数より移行条件を見て判断するので、整理した条件をRFPに記載します。

移行案件では、WebLogicやWebSphereなどの独自APIも洗い出します。

本開発前の移行アセスメントと技術検証

既存アプリの移行では、全機能を一度に移さず、代表的な画面やトランザクションを小さく選んで検証します。認証と外部連携も、その範囲に含めます。そのうえで、確認する論点は課題表にまとめておきます。

• 互換性：javaxからjakartaへの変更、独自API、古いライブラリ、JDKの差異。
• 動作条件：文字コード、セッション管理。
• 検証結果：互換性判定、修正箇所、未解決課題、想定工数、切替条件。

コンパイルが通ったあとに、問題が見つかる場合もあります。そのため、新規開発でも、WildFlyとJavaの版を先に固定しておきます。

2026年7月に公開されたWildFly 41は、標準版でJakarta EE 11のPlatform、Web、Core Profileに対応しています。Java SE 17および21で互換性が確認されています。さらに、MicroProfile 7.1にも対応し、クラウド向けのbootable JARも強化されています。

出典は、WildFly Project「WildFly 41 is released!」（2026年）です。

発注書には、WildFly 41を使うか、既存アプリの都合による別版にするかを明記します。あわせて、Preview版を本番で使わないことも記します。

試験・移行・運用引き継ぎの納品範囲

試験は、単体、結合、総合に加えて、性能や障害復旧まで設計します。権限やバックアップからのリストアも、試験の対象です。特に、連携試験では相手側の停止やタイムアウトも扱います。

重複送信や再実行時のデータ整合性も、確認の対象になります。性能試験では、想定負荷と測定条件を決めたうえで、ボトルネックや改善後の数値を記録します。その記録は、納品物にも含めます。

本番移行では、データクレンジングと移行リハーサルを行います。停止時間と切替担当、切戻し条件も、ここで決めます。さらに、利用者への周知も決めておきます。

納品物は、開発・構築と運用の二つの区分で明確にします。

• 開発・構築：ソースコード、設計書、WildFly設定、構築手順。
• 運用：監視項目、バックアップ・復旧手順、脆弱性対応窓口、バージョンアップ方針。

引き継ぎ後に別の会社へ保守を頼んでも運用できるよう、資料の細かさを揃えておきます。

WildFlyのシステム開発の契約形態の選び方

契約形態は、要件がどこまで決まっているか、発注者が管理業務を担えるか、納期と品質のどちらを優先するかで選びます。なお、工程ごとに契約を組み合わせる方法もあります。

• 要件定義・技術検証：準委任で進めます。
• 仕様が固まった製造：請負にする方法があります。

成果物と完成条件を明確にできる場合の請負契約

請負契約は、受託者が合意した成果物を完成させ、発注者が対価を支払う契約です。そのため、完成条件を発注前に定めておきます。

• 適する場面：仕様・検収基準が定まった新規開発や、移行対象と切替条件が明確な工程。
• 完成条件：画面・API仕様、テスト項目、性能条件、納品物、対象版、構築環境。
• 納品内容：設定のコード化、試験結果、手順書も成果物です。
• 仕様変更：発注者の業務都合による変更は、追加費用や納期変更に備え、承認者、見積単価、影響評価の期限を契約に定めます。
• 検収・瑕疵対応：受入テストと瑕疵対応の範囲、納品後の不具合と追加要望の境界

準委任契約が向く検証・移行支援

準委任契約は、専門知識や稼働時間を使って作業を進める形態です。調査や設計支援、技術検証のほか、プロジェクト管理や運用支援も含まれます。移行の可否がまだ分からない場合にも、使いやすい契約です。

発注者と受託者が一緒に要件を詰める場合にも、この契約に合います。費用は人月や稼働時間を基準にすることが多いです。このため、作業の進み具合を月単位で追っていきます。

• 月次確認：作業報告、成果物、課題一覧、次月計画。
• 役割確認：意思決定者、発注者が出す資料・環境、課題の優先順位を決める人。
• 常駐・再委託：アクセス権限、秘密保持、作業場所、ログ保存、退場時のアカウント削除。

準委任では、請負と同じ完成責任を期待せず、役割を契約と運用手順に落とし込みます。

保守契約の対応時間と責任分界

保守契約では、作業範囲と対応時間、脆弱性対応の責任者を具体的に決めます。

• 保守作業：問い合わせ、障害の一次切り分け・復旧支援、ログ調査、脆弱性確認、パッチ、証明書、Java・DB・WildFlyの更新。
• SLA：平日日中か夜間休日も含むか、重大障害の一次回答時間、復旧目標。
• 脆弱性対応：通知経路、影響調査の期限、修正版の検証、緊急パッチの判断者
• 責任分界：担当者を定め、問題発生時の押し付け合いを防ぎます。

IPAの2026年の製品開発者向け・製品利用者向けガイドは、自社開発だけでなく委託開発を含むシステムを対象にしています。また、脆弱性への対処状況を調達や運用で確認する考え方を示しています（出典: IPA「製品開発者向け・製品利用者向けガイド」、2026年）。

WildFlyのシステム開発の費用相場とコスト内訳

WildFly固有の受託価格を公開している会社は、多くありません。そこで、2026年の一般的なJava・業務システム相場と、基盤構築・移行・運用の作業量から推定した目安を示します。

実費は、画面数よりも既存コードの複雑さや外部連携、データ移行で大きく変わります。さらに、可用性やセキュリティの要件も、費用に影響します。納期や保守水準も、費用を動かす要素です。

案件規模別の費用レンジ

一般的な開発費の公開目安は、小規模100万〜300万円、中規模500万〜1,000万円、大規模1,000万円〜数千万円以上です。また、人月単価は60万〜200万円程度とされています（出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年）。

WildFly案件では、本体価格よりも工数が費用を左右します。費用を左右する工数には、Java開発や基盤、移行、テスト、運用があります。そこで、次の規模別の推定額を、予算を比べる目安として使います。

• 技術検証・移行アセスメント：50万〜150万円程度。
• 小規模な社内業務システム：300万〜800万円程度。
• 部門横断のAPI・業務システム：800万〜2,000万円程度。
• 既存Javaアプリの本格移行：1,000万〜3,000万円程度。
• 高可用性の基幹系：2,000万〜1億円以上の可能性。

これらは、作業範囲を前提にした推定値です。WildFlyの公開価格ではありません。そこで、発注前にアセスメントと複数社の見積もりで精度を上げます。

見積書の工数と環境費の内訳

見積書は、開発工程ごとの工数と環境費を分けて確認します。「開発一式」とまとめられていると、予算調整の対象を判断しにくくなります。

• 作業項目：要件定義、現状調査、設計、アプリ製造、WildFly構築、DB設計、外部連携、データ移行、試験、リリース、教育、進行管理。
• 環境費：クラウド・サーバー、バックアップ、監視、証明書、商用サポート、検証環境。
• 計上時期：環境費は初期費用と月額費用に分けます。

保守運用費は、初期開発費の年15〜20％程度を置く考え方があります。さらに、24時間監視や脆弱性調査は別契約になり得ます。オンサイト対応やクラウド料も、別契約になることがあります。

たとえば、開発費が1,500万円なら、年225万〜300万円が保守予算の一つの目安になります。これは一般的な考え方であり、WildFlyのサポート料金ではありません。

保守の見積もりでは、回答時間と対象版、ログ解析の範囲を確認します。緊急時の体制も見たうえで、TCO（総保有コスト）を比べます。

コストを抑える際の調整範囲

費用を調整するときも、品質に関わる作業は残したまま、機能や構成、将来費用を含めて判断します。

• 後続に回す機能：要件定義、セキュリティ、移行リハーサル、性能試験は削らず、優先度の低いものは次のフェーズに分けます。
• MVP：Minimum Viable Productとして認証、主要業務、必要なAPI、データ整合性を備え、利用状況を見て機能を追加します。
• 標準機能の活用：標準Jakarta EEや既存認証基盤を使い、独自モジュールを減らすと長期保守の工数を抑えられます。
• 追加費用の要因：短納期の増員、複雑な独自要件、複数DB連携、データクレンジング不足は費用を押し上げます。
• 総保有コスト：将来の更新や障害対応を自社で担えるかも含め、3年程度で比較します。

委託先の選び方と見積比較のポイント

委託先は、WildFlyの経験に加えて、アプリやDB、クラウドを一体で説明できるかを見ます。セキュリティや運用についても、同じ目線で確認します。会社の実績だけでなく、担当者自身の経験も尋ねます。

古い版の構築経験しかなく、Jakarta移行や障害対応の経験がない場合もあります。そのため、対象版と担当者、移行範囲を具体的に確認します。試験方法や保守窓口も、確かめておきます。

実績の作業範囲と成果物

候補会社には、実績の範囲と納品物を尋ねます。公開されている各社の情報も、自社案件に合うかを判断する材料として扱います。

• 技術範囲：WildFly・Javaの版、アプリ方式、DB、クラスタ、認証、監視、移行、リリース後保守。
• SCSK：JBoss EAPの構築、更新、他APサーバーからの移行、性能診断、運用設計。
• サイオステクノロジー：OSSよろず相談室でWildFly（JBoss）をサポート対象として掲載。
• NRI OpenStandia：WildFly情報とOSSサポートを案内。

各社の優劣は断定せず、自社の担当範囲に合うかを個別に確かめます。顧客名が非公開でも、匿名の構成図や課題があれば比べられます。担当範囲や納品物例も、比較の材料になります。

アプリ会社と基盤会社を分ける方法もあります。大規模なEAP移行やアプリ・DB移行では、クラウド基盤や長期保守と専門性が異なります。そのため、RFPで役割と責任分界を示します。

同じRFPと評価軸による相見積もり

相見積もりは2〜3社を目安に、同じ資料と質問で依頼します。RFPに記載する条件は、全社で揃えます。

• 対象と規模：目的、業務、利用者、画面・API・バッチ、データ量、外部連携。
• 技術と環境：WildFly・Javaの希望版、クラウドまたはオンプレミス。
• 運用と調達：稼働時間、RTO・RPO、納期、予算上限、保守、納品物、再委託条件。

未確定の項目は「未定」と記し、各社には前提とリスクを分けて示してもらいます。そのうえで、評価表では価格以外の条件も比べます。

• 提案・費用：要件理解、見積前提、工数、除外項目、追加費用の条件。
• 開発・運用：移行計画、試験範囲、担当経験、保守SLA。
• 契約・引き継ぎ：コード・設計書の権利、再委託先、契約終了時の受け渡し。

安価な見積もりでは、要件定義や性能試験が除外されていることがあります。監視や移行、教育も外れていないかを確かめます。このため、金額差の理由を尋ね、追加費用の条件を文書に残します。

提案面談で聞く障害時の対応

構築方法に加えて、障害時の対応も質問します。特に、一次窓口と判断者、連絡経路まで確認し、記録の残し方も聞きます。

• 基盤・DB：WildFlyノード停止時の切り分け、データベース障害時の復旧。
• 処理・証明書：メッセージ重複時の再処理、期限切れへの対応。
• 緊急時：脆弱性の緊急確認、クラウド障害時の連絡体制。

「担当者が確認します」で終わらず、対処の手順まで示せる会社なら、運用時の動きを判断しやすくなります。

発注者が提供する資料や人員も、確認しておきます。業務部門のレビューや旧仕様書、テストデータは、誰が担当するかを明確にします。移行元データの品質確認と受入テストの担当も、曖昧にしないようにします。

開発会社だけでは解決できない遅延を防ぐため、双方の作業と担当部署、期限を提案の段階で決めます。これが、納期と費用の安定につながります。

RFPに入れる要件と発注時のリスク対策

RFPは、要望を伝える書類であるだけでなく、提案と見積もりを同じ条件で比べる基準にもなります。要件が未確定でも、目的や範囲、制約などは書いておきます。

• 基本条件：対象範囲、制約、未決事項、候補技術、納期、予算。
• 成果物：期待する納品物と、WildFlyを採用する理由。
• 代替案：別の技術の提案を求めるかどうか。

採用理由と代替案の要否を示しておくと、技術ありきの提案を避けやすくなります。

セキュリティ要件の認証・脆弱性・委託先管理

セキュリティ要件には、通信の保護以外も含まれます。アクセス制御や認証、ログの扱いも、RFPに含めます。脆弱性対応も、要件に入れます。

• 認証・権限：HTTPS、管理画面の分離、管理者の多要素認証、Elytron、OIDC・Keycloak連携。
• 記録・検査：秘密情報の保管、監査・アクセスログと保存期間、脆弱性検査、依存ライブラリのSBOM。
• 更新・管理：パッチ適用期限、管理コンソール・CLIのアクセス経路を業務画面と分けます。

個人情報や機密情報を扱う場合は、委託先と再委託先、保管場所を定めます。持ち出し制限や事故報告期限、ログ提出も、あわせて決めておきます。契約終了時の返却と消去も、定めの対象です。

OSSや外部ライブラリを誰が監視するかも、決めておきます。さらに、脆弱性の影響判定と修正費用の負担者は、保守見積もりの段階で明確にします。

移行失敗とベンダーロックインへの契約上の備え

移行失敗には、互換性のほか、マスタ欠損や件数不一致が関係します。仕様書にない業務や切替時間の不足も、原因になり得ます。そのため、移行条件を契約範囲に含めます。

• 移行計画：対象の段階分け、データ変換仕様、件数照合、リハーサル。
• 切替・受入：切戻し条件と、利用者によるテスト。
• 例外データ：移行できないものの扱いを要件定義で決める。

会社が変わるときに備えて、コードや設定、インフラ定義の納品と利用権を確認します。テストや設計書、運用手順も、同じ確認の対象です。

ビルド設定やコンテナ定義、インフラコードも対象です。Galleonやbootable JARの設定も、そこに含まれます。そのうえで、Gitなどで変更履歴を管理し、別の会社でも環境を再現できるようにします。

契約終了時の引き継ぎ期間や資料、質疑応答の時間も、見積もりに含めます。特定の担当者だけが扱える手作業は、残さないようにします。

よくある質問（FAQ）

発注時には、無料で使えるか、既存Javaアプリを移行できるか、委託先をどう探すかといった質問が出ます。見積もりや契約で確かめたい点を、質問ごとに説明します。

WildFlyは無料で使えるため、開発も無料ですか？

WildFly本体のライセンス料は原則無料でも、開発や移行、基盤構築は有償です。試験や監視、保守にも費用がかかります。

さらに、商用サポートやクラウドにも費用がかかります。バックアップや24時間監視も、別途費用が必要です。

予算は、ランタイム価格の横に、必要な作業とサービスの総額を並べて考えます。

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

移行できる可能性はあります。ただし、javax系・jakarta系APIやJava版、独自APIの確認が必要です。設定やライブラリ、DB接続、認証方式も、確認の対象です。

まず代表機能で移行アセスメントを行い、修正箇所や工数を見ます。性能と切戻し方法も確かめてから、本開発へ進みます。検証を省いて一括で移行すると、課題が後半に集中しやすくなります。

WildFlyに詳しい委託先はどのように探せばよいですか？

構築実績だけでなく、対象版やJava・Jakarta EE移行の実績を確かめます。加えて、DBやクラウド、認証の経験を見ます。性能試験や障害対応、保守についても、経験を聞きます。

SCSK、サイオステクノロジー、NRI、KMD、Vineyard Works、Asian Bridgeなどは対応実績を公開しています。

WildFlyやJBossの内容、OSSサポート、Java基盤の情報を確認します。公開情報だけで優劣は決めず、同じRFPで提案と見積もりを比べます。

WildFlyのシステム開発はどれくらいの期間がかかりますか？

計画の目安は、技術検証・移行アセスメントが2〜6週間、小規模業務システムが3〜6か月です。部門横断システムは6〜12か月、本格的なJavaアプリ移行は6〜18か月を見込みます。

高可用性の基幹系や複数システムの連携は、12〜24か月以上になることもあります。期間は、要件の確定度やデータ移行、受入体制で変わるため、見積書に期間と前提を記します。

まとめ

WildFly本体がOSSであることと、業務システムを使い続けるための開発・移行・運用費は、分けて考えます。要件定義の段階で、業務機能と技術・運用の条件を固めます。

押さえる対象は、WildFly・Javaの版と、javax・jakartaの互換性です。DBや認証、性能も含まれます。

さらに、バックアップとRTO・RPOも対象です。脆弱性対応と移行データも、含めて考えます。

発注前に確認する項目一覧

発注前には、RFPや現行構成図、業務フロー、データ件数を揃えます。さらに、非機能要件と移行範囲、試験方針も整理します。納品物や保守SLA、再委託条件は、チェックリストにまとめます。

見積書では、要件定義や設計、製造の工程と、移行、試験、教育、保守の内訳を比べます。判断の軸は、安さよりも3年程度の総保有コストと、障害・更新に対応する体制です。

最初に行うアセスメントとRFP作成

本開発の前に既存資産を洗い出し、代表機能の移行検証を行うと、費用とリスクを見積もりやすくなります。WildFly 41などの選択肢を確認しつつ、既存システムとの互換性や将来の保守、引き継ぎを優先します。そのうえで、発注範囲を整理し、複数の委託先に相談します。

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