JSFのシステム開発の完全ガイド - ブログ

JSFのシステムは、業務画面の複雑さ、既存のJava資産、移行・保守体制を踏まえて構成を選ぶと、業務ルールと画面処理を一体で管理できます。

まず仕組みと向く業務を見たうえで、開発の進め方、費用、発注先の選び方を順に説明します。各テーマの詳細は、下の関連記事もご覧ください。

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

JSFのシステムの全体像

画面表示からデータ保存まで、役割ごとのつながりを俯瞰できます。

JSFは、ブラウザ画面をJavaの業務処理と結び付けるサーバーサイドUIフレームワークです。

現在のJakarta Faces 4.1は、UI部品や状態管理、画面遷移などの仕組みを定めています。さらに、イベントや入力検証についても定めています（出典: Jakarta Faces 4.1仕様、Jakarta EE、2024年公開）。

JSFで作るのは、画面と業務ロジック、データ、実行基盤を一体で設計した業務アプリケーションです。また、国際化やアクセシビリティも仕様に含まれます。

JavaServer FacesとJakarta Facesの違い

JavaServer FacesはJava EE時代の名称です。Jakarta EEへの移行に伴い、Jakarta Server Faces、通称Jakarta Facesへ名称が変わりました。

API名：Jakarta EE 9以降は、javax.*からjakarta.*へ変わりました。
移行確認：ソース、ライブラリ、設定、テスト、サーバーの対応を確かめる。
新規開発：Jakarta Faces 4.1はJava SE 17以上が前提です。

TCKでは2026年3月に4.1.2のファイルが公開されています（出典: Jakarta Faces TCK配布一覧、Eclipse Foundation、2026年3月）。そのため、JSFは完全に停止した技術とは言い切れません。一方で、既存のjavax系資産は新しい環境で動くとは限らないため、移行前に互換性を検証します。

JSFで画面が動く仕組み

JSF画面は、HTMLに近いテンプレートのFaceletsと、入力欄・一覧・ボタンなどのUI部品で構成します。

送信後の流れ：リクエスト受付、入力値の適用、型変換・バリデーション、モデル反映、業務メソッド呼び出し、HTML再生成の順に進みます。
周辺技術：CDI管理Bean、Jakarta Persistence（JPA）、Bean Validation、トランザクション、認証認可。
連携機能：帳票、バッチ、REST APIなどを必要に応じて組み合わせます。

この仕組みにより、入力エラーを項目の近くに表示できます。さらに、業務ルールの多いフォームや承認画面も整理しやすい点が特徴です。

たとえば、申請画面なら、JSFが入力と表示を担当し、CDIのBeanが処理を受け、JPAがデータを保存する構成です。また、役割分担を図にしておくと、業務処理や運用設計の後回しを防げます。

ポイント

既存のjavax系資産は新しい環境で動くとは限らないため、移行か新規開発かを決める前に互換性を確かめます。JSFの位置づけは、業務画面の複雑さと既存資産の有無で決まります。

JSFのシステムの種類と向いている業務

JSFは、業務の性質によって向き不向きが分かれます。サーバー側で画面と業務処理をまとめて管理できるため、入力項目や権限、承認が多い業務ほど、利点が出やすくなります。検索条件や一覧表示、業務上の例外処理が多い場合も、同じ理由で利点が出ます。

大量の同時接続を受ける公開画面や、スマートフォンでリアルタイムに変わる操作が中心なら、別のフロントエンド構成も比較します。

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

JSFが活用される業務画面には、次のようなものがあります。

管理画面：社内ポータル、マスタ管理、管理者向け画面。
業務管理：販売・在庫・購買、顧客・契約、申請・承認。
権限や入力が複雑な業務：所属・役職で表示や権限が変わる画面。

入力値の組み合わせでルールが変わる場合も、変換・検証・エラーメッセージを画面の流れに組み込みやすい点が利点です。

Javaの既存ライブラリや業務ロジックを再利用できれば、全面刷新より費用とリスクを抑えられる場合があります。

国内の公開事例には、カード決済関連の基盤にJava、Linux、DB2、JSFを組み合わせた例があります。ただし、これは2023年12月の掲載情報で、2026年の新規導入実績ではありません。

この事例は、フォーム中心の業務画面と既存基盤の連携に使われてきたものです。金融、製造、物流などでは、画面の流行より既存資産との整合性が評価されます。

JSF以外の構成を検討するケース

利用環境や開発体制に応じて、次の構成も候補になります。

公開・スマートフォン画面：React・Vue・AngularとJava REST APIを組み合わせる方式。
操作性：ドラッグ操作やリアルタイム更新が多い画面。
開発体制：フロントエンドとバックエンドを別チームで開発する場合。

画面を分離すると自由度は上がります。一方で、API・認証・状態管理を別途整備する必要があります。エラー処理やテストも、整備の対象に含まれます。そのため、構成変更の影響も含めて比べます。

判断では、Java資産の再利用性、入力や権限の複雑さを確認します。そのうえで、内製体制、クラウド拡張、3〜5年後の保守構成も見ます。

新規開発でもJSFは選択できますが、要件と運用費で理由を説明できない場合はPoCで比較します。

ポイント

JSFが向くかは、入力や権限、承認の多さと既存Java資産の再利用で判断します。大量の同時接続やスマートフォン中心の操作が主なら、画面を分けた別構成も比べます。

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

代表画面での検証を挟み、後工程へ順に進みます。

画面から作り始めると、権限や業務ルールが後から膨らみやすくなります。データ移行や性能要件も、後から追加されやすい項目です。そのため、現行調査と要件定義を行い、代表画面で技術検証してから設計・開発へ進みます。

既存システムの改修では、現行の実行環境とライブラリを一覧にすることが、新規開発以上に重要です。

現行調査と要件定義で確認する項目

現行環境と新規要件を分けて洗い出します。

バージョン：JSFの世代、javax系かjakarta系か、Javaの版。
実装・画面：JSF実装、UIコンポーネント。
利用実態：画面ごとの利用者・頻度、障害・改修履歴、セッション内データ量。
基盤・連携：アプリケーションサーバー、DB、認証方式、帳票、バッチ、外部API。
新規要件：業務フロー・権限・承認、画面・データ、ピーク利用者数、SLA、監査、バックアップと復旧目標。

仕様書にない暗黙の業務ルールは、移行時のリスクになりやすいものです。そのため、現場の担当者への確認が欠かせません。

全体工期の約25%を要件定義に配分する考え方もありますが、どの案件にも当てはまる基準ではありません。たとえば、データ移行や複雑な承認がある案件では、業務の境界を先に決めるほうが手戻りを抑えられます。

アーキテクチャ設計と小さなPoC

構成設計では、新規環境と既存資産、それぞれの移行案を決めます。

新規環境：Jakarta Faces 4.1、Java 17または21。
周辺構成：CDI、JPA、Bean Validation、認証認可、DB、実行基盤。
既存環境：現行維持、javaxからjakarta移行、API分離、画面ごとの別フロント化。
PoC対象：入力の多い画面、複雑な一覧、認証・権限、外部API連携。
状態検証：サーバー側の状態保存、画面遷移、戻る操作、複数タブ、セッション切れ、スケールアウト時の挙動。

一括移行は事業への影響と検証量が大きくなりやすいため、変更頻度が高く効果を測りやすい画面から進める案もあります。

応答時間やログ追跡、テスト自動化まで検証できれば、本開発後の設計変更を減らせます。さらに、コンテナ化や障害復旧まで加えると、減らせる範囲はいっそう広がります。

開発・テスト・移行・リリース

設計後は、実装と検証を経て移行し、引き継ぎを行ってから運用を始めます。

実装・テスト：画面、共通部品、業務ロジック、データアクセス、API、バッチを分けて実装し、単体・結合・総合テストを行う。
移行準備：項目変換、欠損、重複、文字コード、履歴を決め、少なくとも1回リハーサルする。
本番切替：停止時間、差分取込、ロールバック、問い合わせ窓口を定める。
運用引き継ぎ：利用者教育、監視、バックアップ、脆弱性パッチ、障害対応、改修の優先順位を渡す。

テストでは、入力エラーや権限不足、二重送信、通信タイムアウトを確かめます。外部停止やセッション切れ、大量データ、ピーク負荷も確認します。さらに、JSFの各段階の業務処理も対象です。

開発が終わっても、運用が自動的に始まるわけではありません。そのため、リリース後の担当と対応範囲を、引き継いでおく必要があります。

ポイント

画面より先に、現行環境の洗い出しと要件定義を済ませるのが判断の目安です。既存システムの改修では、実行環境とライブラリの一覧が特に重要になります。

JSFのシステム開発費用の相場と内訳

JSF単体の公表価格はほとんどありません。ここに示すのは、画面中心の業務Webシステムに要件定義、テスト、移行、非機能要件を加味した計画用の推定です。

2026年版の国内情報では、人月単価60万〜200万円とされています（出典: 国内システム開発費用調査、2026年）。

規模別では、小規模が400万〜1,200万円、中規模が1,500万〜5,000万円です（出典: 国内システム開発費用調査、2026年）。

大規模は1,000万円〜数千万円以上という幅です（出典: 国内システム開発費用調査、2026年）。なお、JSF案件では、画面数だけでなく、業務ルールと既存資産の複雑さも金額を左右します。

▶ 詳細はこちら：JSFのシステム開発の見積相場や費用/コスト/値段について

規模別に見た初期開発費の目安

規模ごとの目安は、機能範囲と工数をあわせて見る必要があります。対象は次の3区分です。

小規模：1部門向けCRUD、ログイン、検索・一覧、簡易帳票、外部連携0〜1本。
中規模：複数部門、承認、権限、帳票、API・バッチ、データ移行。
大規模：全社基幹、複数拠点、大量データ、SSO、監査ログ、複数連携。

小規模は5〜10人月、2〜5か月、400万〜1,200万円程度です。中規模は15〜35人月、5〜10か月、1,500万〜5,000万円程度が目安です。

大規模は50〜120人月、10〜24か月、5,000万円〜2億円以上になる可能性があります。ただし、これらはJSF固有の市場統計ではなく、類似業務Webシステムからの推定です。

10人月、人月単価80万〜150万円なら、開発作業だけで800万〜1,500万円です。要件定義や受入支援、クラウド構築、移行、教育、予備費を加えると、画面数が同じでも総額に幅が出ます。

要件定義を省くと、仕様追加で工数が当初の1.3〜1.5倍になるリスクがあります。そのため、総額の安さだけで発注先を決めないことが大切です。

保守・クラウドを含むTCOの比較

初期費用だけでなく、継続費用や構成ごとの追加費用を含めてTCOを比べます。

基盤・運用費：クラウド・DB、サーバー支援、監視・バックアップ・ログ、障害対応、問い合わせ・軽微改修。
保守率：初期費用の年15〜25%程度という考え方もあります。
上振れ条件：24時間監視、高可用性、商用支援、脆弱性診断、パッチ検証。
既存JSF維持：現行環境の延命、移行準備、技術者の引き継ぎ。
画面刷新：API、認証、テスト基盤、二重運用、データ同期。

OSSでも、バージョンアップや脆弱性対応の担当を決めておかないと、実質的な保守費が見えません。このため、初期費用に加えて3〜5年の総保有コスト（TCO）を試算します。

年額保守が安くても、特定担当者に依存するなら、交代費用や障害リスクを含めて評価します。

見積書で分けて確認する項目

画面数や技術条件を見積もりに反映するには、作業のまとまりごとに費用を分けます。

設計・実装：要件定義、業務フロー、画面、共通部品、業務ロジック、データアクセス。
連携・検証：API、帳票、各種テスト、性能試験、脆弱性診断。
移行・運用：データ移行、教育、運用引き継ぎ。

各項目について、納品物や画面数、前提、除外事項、追加変更の単価を確かめます。また、技術条件として、JSF世代、UI部品のライセンス、Javaと基盤のサポート範囲が、見積書に記載されているかを確認します。

さらに、セッション複製、ログ保存期間、バックアップ世代、障害時の復旧時間を確認します。何を納品し、何を継続支援するのかを、金額と併せて比べます。

見積書に技術要素の記載がないと、同じ金額でも品質や保守範囲を比べられません。

ポイント

費用は規模と機能範囲で幅が出るため、人月と要件に分けて見積もりを比べます。保守やクラウドを含む3〜5年のTCOで見ると、総額の安さだけで決めずに済みます。

JSFの開発会社・サービスの選び方

発注先は、Javaの開発力に加え、業務理解やJSF・Jakarta Facesへの対応、既存資産の移行、テスト、運用を扱える体制で選びます。具体的には、対象版やUI部品、実行基盤、認証、データ移行、クラウド運用について、どこまで説明できるかを確認します。

技術力と移行経験を確認する質問

候補先への質問は、技術環境、移行経験、過去の実績、設計力に分けると比較しやすくなります。

現行環境：JSFのバージョン、利用するJSF実装、UI部品、アプリケーションサーバー。
移行経験：javaxからjakartaへの移行実績、Java 17または21への対応。
設計方針：CDIやJPA、Bean Validationを使う設計について質問します。
実績：案件名、画面数・利用者数・連携数、移行対象、テスト方法、保守期間。
設計課題：複雑な一覧、権限別表示、二重送信防止、外部APIのタイムアウト処理。

同じ小さな課題を候補先に渡し、設計図とテスト観点を求める方法も有効です。

また、コードだけでなく、例外処理やログ、監視、アクセシビリティも評価します。加えて、将来の担当者が読める設計かどうかも確かめます。

プロジェクト管理と保守体制の確認

管理と保守の契約では、責任分担や引き継ぎを次の観点で確認します。

管理体制：責任者、意思決定者、レビュー、課題・変更管理、受入基準、遅延時の報告。
役割分担：画面を別会社へ委託する場合も、業務・移行・運用の担当と仕様変更の承認者を決める。
納品物：ソース・設計書、テスト結果、CI/CD・インフラ構成、運用・バックアップ手順、ライセンス、脆弱性履歴。
保守条件：問い合わせ時間、障害優先度、初動・復旧目標、パッチ、軽微改修、担当交代。

請負でも準委任でも、成果物と役割があいまいなままだと、追加費用や納期をめぐる議論が生じがちです。

特定の担当者しか把握していない状態を残さないことが、JSFを長く使ううえでの条件です。

▶ 詳細はこちら：JSFのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：JSFのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

▶ 詳細はこちら：JSFのシステム開発の発注/外注/依頼/委託方法について

ポイント

発注先は、Javaの開発力に加えて、移行経験と運用体制で比べます。候補先には技術環境や設計について質問し、保守の担当と交代の条件まで契約に残せるかで判断します。

JSFのシステムで失敗を防ぐセキュリティと契約の要点

四つの観点に分けると、確認漏れを見つけやすくなります。

安全性は、ログイン画面があるかどうかより、各段階での確認によって左右されます。入力検証やXSS、CSRF、セッションを確かめます。権限や依存ライブラリ、監査ログ、バックアップ、復旧、運用担当の権限も、各段階で確認します。

JSFの状態管理では、セッションのサイズや画面遷移、複数タブ、タイムアウトも要件に含めます。

受入テストに入れるセキュリティ要件

受入テストでは、認証・アクセス制御と、入力・セッション周りの安全性を確かめます。

認証・権限：成功・失敗、パスワード再設定、権限外URL、セッション固定。
入力・画面：CSRF、入力値のエスケープ、ファイルアップロード、エラー画面。
情報管理：ログの個人情報、脆弱性スキャン、OS・Javaのパッチ、通信暗号化、秘密情報。
監査・復旧：ログの改ざん対策、バックアップからの復旧試験。

OWASP ASVS 5.0.0は、認証やセッション、アクセス制御、入力検証などを確認するための基準です。2025年5月に公開されました（出典: OWASP Application Security Verification Standard 5.0.0、2025年）。

ASVSの確認項目をチェックリストに反映すれば、担当者の経験だけに依存しにくくなります。

クラウド移行時は、公開範囲、ネットワーク分離、WAF、監視、ログ保存、障害時の責任分担を確認します。また、開発会社と自社運用担当の役割を図にします。

契約と納品物の明確化

契約と納品では、成果物と役割、資産の帰属、引き渡し条件を明らかにします。

成果物・権利：要件定義の成果物、設計書、ソース範囲、第三者ライセンス、データ帰属。
契約管理：再委託、秘密保持、障害対応、仕様変更の扱い。
契約方式：請負は完成基準、準委任は作業範囲と報告方法を明確にする。
移行資産：ソース・画面定義、DBスキーマ、ジョブ、運用手順、障害履歴、テストデータ。

モデル契約書でも、要件、役割、変更管理、検収、知的財産の整理が重視されています（出典: 情報システム・モデル取引・契約書第二版、2025年更新）。

残す資産と不要な資産を分けて、引き渡しの時期と形式を決めます。なお、不足があると、会社変更や段階移行の際に再調査費用が発生します。

JSFのシステムに関するよくある質問

採用では、技術名だけでなく、既存資産や対象業務、費用、移行、保守の条件を合わせて判断します。よくある疑問への回答をまとめます。

JSFは古い技術なので新規開発に使えませんか？

新規開発でのJSFは、一律に判断せず、要件に照らして検討します。なお、Jakarta Faces 4.1はJakarta EE 11向けに提供され、Java SE 17以上を前提にしています。

一方で、公開サービスの操作性やフロントエンドの独立性を優先するなら、別構成が適する場合もあります。代表画面のPoCで比較して決めます。

既存のjavax系JSFをjakarta系へ移行できますか？

移行はできますが、名前空間の変更だけで済むとは限りません。サーバー、JSF実装、UI部品、ライブラリの互換性を確認します。さらに、設定や認証、テスト、デプロイ方法も確かめます。

代表画面で移行を検証します。また、画面単位で段階移行するなら、認証、データ、ログ、エラー処理を共通化してから進めると、二重運用を抑えやすくなります。

JSFのシステムをクラウドへ移行できますか？

移行はできますが、JSFのセッション状態とファイル処理を先に検証します。そのうえで、セッションの保存先や負荷分散時の画面状態、アップロード先、拡張と障害復旧を設計します。

コンテナ化やマネージドサービスを使う場合も、サーバーを移すことは移行の一部にとどまります。そのため、監視やバックアップ、ログ、パッチ、責任分担まで含めた計画を作ります。

JSFのシステム開発費用を抑える方法はありますか？

利用頻度と事業効果の高い業務に絞り、PoCと段階リリースを行う方法があります。また、既存の認証、帳票、マスタ、業務ロジックを再利用できるかも確認します。

要件定義やセキュリティ、データ移行、テストを削ると、障害や追加改修で費用が増えます。そのため、削減対象は画面の優先順位や不要な個別仕様に絞ります。

まとめ：既存資産と保守体制による判断

JSFは、入力、承認、権限、検索、帳票が複雑な業務Webシステムと相性がよく、Java資産を活用できる場合に有力です。

そのうえで、Jakarta Faces 4.1やJava 17以上を踏まえ、新規開発や継続利用を検討できます。また、javax系からjakarta系への移行、UI部品、実行基盤、セッション管理、テストは一体で確認します。

採用判断で押さえるポイント

採用時は、Java・JSF資産の再利用性、画面の複雑さ、クラウド・スマートフォン対応、3〜5年のTCO、移行後の保守体制を比べます。

計画上の費用幅は、小規模400万〜1,200万円、中規模1,500万〜5,000万円、大規模5,000万円〜2億円以上です。そのため、要件と人月に分解して見積もりを比較します。

次に行うべき準備

次の順で準備すると、移行案の比較と発注条件を具体化できます。

画面を選ぶ：利用・改修頻度の高い画面を3つ程度選ぶ。
構成を比べる：維持、Jakarta Faces移行、API分離、別フロント化を比べ、PoC範囲を決める。
受入基準を決める：比較条件に沿って検証の合格条件を定める。
発注条件を決める：納品、セキュリティ、移行、保守交代を確認する。

現行のJSF・Java・DB・実行基盤・認証・外部連携を一覧にします。

発注時は、ソース・設計書、セキュリティ検証、データ移行、保守担当の交代可能性を確認し、将来の選択肢を残します。

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