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

JSFのシステムとは、JavaServer Faces（現在の正式名称はJakarta Faces）を画面層に使い、Javaの業務ロジック、データベース、認証、外部連携まで組み合わせて作る業務Webシステムです。新規開発では、JSFの知名度だけで決めず、既存資産、画面の複雑さ、移行方針、保守体制を含めて判断することが重要です。

この記事では、JSFの基本的な仕組みから、向いているシステムの種類、開発の進め方、2026年時点の費用相場、開発会社やサービスの選び方、クラウド移行・セキュリティ・契約の注意点までをまとめます。既存のJSFを継続するか、Jakarta Facesへ移行するか、別のフロントエンドへ段階的に刷新するかを検討している方にも役立つ内容です。

JSFのシステムとは何ですか？全体像を整理します

JSFは、ブラウザに表示する画面をJavaの業務処理と結び付けるためのサーバーサイドのUIフレームワークです。現在のJakarta Faces 4.1は、UIコンポーネント、状態管理、イベント処理、入力検証、画面遷移、国際化、アクセシビリティなどを仕様として定めています（出典: Jakarta Faces 4.1仕様、Jakarta EE、2024年公開）。つまり、JSFのシステムはJSF単体の商品ではなく、画面・業務ロジック・データ・実行基盤を一体で設計する業務アプリケーションです。

JavaServer FacesとJakarta Facesは何が違いますか？

両者は同じ系譜の画面技術です。Java EE時代のJavaServer Facesが、Jakarta EEへの移行にともなってJakarta Server Faces、通称Jakarta Facesへ名称変更されました。ただし、名称だけが変わったわけではありません。Jakarta EE 9以降ではAPIの名前空間が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の画面は、FaceletsというHTMLに近いテンプレートと、入力欄・一覧・ボタンなどのUIコンポーネントで構成されます。利用者が画面を送信すると、リクエスト受付、入力値の適用、型変換とバリデーション、モデルへの値反映、業務メソッドの呼び出し、HTMLの再生成というライフサイクルで処理されます。入力エラーを画面項目の近くに表示しやすく、業務ルールの多いフォームや承認画面を整理しやすい点が特徴です。

実務では、CDIで管理するBean、Jakarta Persistence（JPA）によるデータアクセス、Bean Validationによる入力検証、トランザクション管理、認証認可、帳票、バッチ、REST APIなどを組み合わせます。たとえば申請画面では、JSFが入力と表示を担当し、CDIのBeanが処理を受け、JPAが申請データを保存する構成です。この役割分担を最初に図にすると、画面の見た目だけを作って業務処理や運用設計が後回しになる失敗を防げます。

JSFのシステムの種類と、向いている業務を比較します

JSFは、画面を持つ業務システムであれば何でも適するわけではありません。入力項目、権限、承認、検索条件、一覧表示、業務上の例外処理が多いほど、サーバー側で画面と業務処理をまとめて管理できるメリットが出やすくなります。反対に、公開サービスで大量の同時接続を受ける画面や、スマートフォンでリアルタイムに変化する操作を中心にする場合は、別のフロントエンド構成も比較します。

JSFが向いているシステムは何ですか？

代表例は、社内ポータル、販売・在庫・購買管理、顧客・契約管理、申請・承認、マスタ管理、管理者向け画面です。特に、利用者の所属や役職によって表示項目と操作権限が変わるシステム、入力値の組み合わせで業務ルールが変わるシステムでは、変換・検証・エラーメッセージを画面の流れに組み込みやすい利点があります。Javaの既存ライブラリや業務ロジックを再利用できる場合は、全面的に作り直すよりJSFを継続する方が費用とリスクを抑えられることもあります。

公開されている国内事例では、カード決済関連のアプリケーション基盤にJava、Linux、DB2、JSFを組み合わせた例が紹介されています。掲載は2023年12月であり、2026年の新規導入実績とみなすことはできませんが、フォーム中心の業務画面と既存基盤の連携にJSFが使われてきたことを確認できます。金融、製造、物流など、処理の正確性と監査性を優先する業務では、画面の流行よりも既存資産との整合性を評価します。

JSF以外の構成を検討した方がよいケースは何ですか？

スマートフォン中心の公開サービス、ドラッグ操作やリアルタイム更新が多い画面、フロントエンドとバックエンドを別チームで独立開発したい場合は、React・Vue・AngularなどとJavaのREST APIを組み合わせる方式も有力です。画面を完全に分離すると、フロントエンドの自由度が上がる一方、API設計、認証、状態管理、エラー処理、テストを別途整備する必要があります。

判断基準は「JSFは古いか、新しいか」ではなく、既存のJava資産を再利用できるか、業務画面の入力と権限が複雑か、将来の内製体制があるか、クラウドでの拡張が必要か、3〜5年後にどの構成を保守したいかの5点です。新規開発でもJSFを選べる一方、技術選択の理由を要件と運用費で説明できない場合は、PoCを通じて比較することをおすすめします。

JSFのシステム開発はどのように進めますか？

JSFのシステム開発では、画面を先に作り始めると、後から権限、業務ルール、データ移行、性能要件が膨らみやすくなります。最初に現行調査と要件定義を行い、代表画面で技術検証を済ませてから設計・開発へ進む流れが安全です。既存システムの改修では、現行の実行環境とライブラリを一覧化する作業が新規開発以上に重要です。

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

既存システムでは、JSFの世代、javax系かjakarta系か、Javaのバージョン、JSF実装、UIコンポーネント、アプリケーションサーバー、データベース、認証方式、帳票、バッチ、外部APIを棚卸しします。さらに、画面ごとの利用者、利用頻度、障害履歴、改修頻度、セッションに保持するデータ量も確認します。仕様書だけでは分からない暗黙の業務ルールが、移行時の大きなリスクになりやすいためです。

新規開発では、業務フロー、権限マトリクス、画面項目、データ項目、承認ルール、ピーク時の同時利用者数、SLA、監査ログ、バックアップと復旧目標を決めます。要件定義に全体工期の約25%を配分する考え方もありますが、これは一律の正解ではありません。データ移行や複雑な承認がある場合は、開発工程を削って要件定義を急ぐより、先に業務の境界を決める方が結果的に手戻りを抑えられます。

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

新規のJakarta Faces 4.1を候補にする場合は、Java 17または21、CDI、JPA、Bean Validation、認証認可、データベース、実行基盤の組み合わせを決めます。既存JSFでは、現行維持、javaxからjakartaへの移行、JSF画面を残したAPI分離、画面単位の別フロントエンド化という複数案を比較します。全画面を一度に移行する方針は、事業影響と検証量が大きくなりやすいため、変更頻度が高く効果を測りやすい画面から段階化する方法も検討します。

PoCでは、単純な登録画面だけでなく、入力項目が多い画面、複雑な一覧、認証、権限、外部API連携を1つずつ選びます。特にJSFはサーバー側の状態保存を伴うため、画面遷移、ブラウザの戻る操作、複数タブ、セッション切れ、スケールアウト時の挙動を確認します。応答時間、ログの追跡性、テスト自動化、コンテナ化、障害時の復旧まで確認できれば、本開発後の設計変更を減らせます。

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

設計後は、画面、共通部品、業務ロジック、データアクセス、API、バッチを分けて実装し、単体・結合・総合テストへ進みます。テストでは正常系だけでなく、入力エラー、権限不足、二重送信、通信タイムアウト、外部システム停止、セッション切れ、大量データ、ピーク負荷を対象にします。JSFの画面テストは、表示の確認だけでなく、ライフサイクルの各段階で業務処理が正しく呼ばれるかまで確認します。

既存データを移行する場合は、移行前の項目変換、欠損値、重複、文字コード、履歴の扱いを決め、少なくとも1回はリハーサルを実施します。本番切り替えでは、停止時間、差分データの取り込み、ロールバック、問い合わせ窓口を決めます。リリース後は利用者教育、監視、バックアップ、脆弱性パッチ、障害対応、改修の優先順位まで引き継ぎ、開発完了を運用開始と混同しないことが重要です。

JSFのシステム開発費用相場と内訳はどのくらいですか？

JSFだけを切り出した公表価格はほとんどないため、以下は画面中心の業務Webシステムに、要件定義、テスト、移行、非機能要件を加味した計画用の推定です。2026年版の国内システム開発情報では、人月単価は60万〜200万円程度、小規模は100万〜300万円、中規模は500万〜1,000万円、大規模は1,000万円〜数千万円以上とされています（出典: 国内システム開発費用調査、2026年）。JSF案件では、画面数だけでなく、業務ルールと既存資産の複雑さが金額を左右します。

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

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

小規模は、1部門向けのCRUD、ログイン、検索・一覧、簡易帳票、外部連携0〜1本を想定し、5〜10人月、2〜5か月、400万〜1,200万円程度が一つの目安です。中規模は、複数部門、承認ワークフロー、権限、帳票、API・バッチ、データ移行を含み、15〜35人月、5〜10か月、1,500万〜5,000万円程度です。全社基幹、複数拠点、大量データ、SSO、監査ログ、複数連携を含む大規模では、50〜120人月、10〜24か月、5,000万円〜2億円以上になる可能性があります。

これらの金額はJSF固有の市場統計ではなく、類似する業務Webシステムからの推定です。たとえば10人月で人月単価80万〜150万円なら、開発作業だけで800万〜1,500万円になります。ここに要件定義、受入支援、クラウド構築、データ移行、教育、予備費を加えるため、同じ画面数でも見積もりに大きな幅が出ます。要件定義を省いた場合、仕様追加によって工数が当初の1.3〜1.5倍になるリスクもあるため、安い総額だけで発注先を決めないことが大切です。

保守・クラウドを含むTCOで比較する

初期開発後には、クラウド利用料、データベース、アプリケーションサーバーのサポート、監視、バックアップ、ログ保管、脆弱性診断、パッチ検証、障害対応、問い合わせ、軽微な改修が発生します。保守運用費を初期費用の年15〜25%程度と置く考え方がありますが、24時間監視や高い可用性、商用サポートを含めると上振れします。OSSを使う場合でも、誰がバージョンアップと脆弱性対応を担うのかを決めなければ、実質的な保守費が見えなくなります。

比較時は、初期費用だけでなく3〜5年の総保有コストを試算します。既存JSFを維持する場合は、現行環境の延命費、移行準備、技術者の引き継ぎ費を含めます。新しい画面構成へ刷新する場合は、API、認証、テスト基盤、二重運用、データ同期の費用を含めます。年額保守が安くても、改修のたびに特定の担当者へ依存するなら、将来の交代費用や障害リスクまで含めて評価する必要があります。

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

見積書は「開発一式」の一行ではなく、要件定義、業務フロー整理、画面設計、共通部品、業務ロジック、データアクセス、API、帳票、単体・結合・総合テスト、性能試験、脆弱性診断、データ移行、教育、運用引き継ぎに分けてもらいます。各項目の成果物、対象画面数、前提条件、除外事項、追加変更の単価を確認します。

さらに、JSFの実装世代、UIコンポーネントのライセンス、Javaと実行基盤のサポート範囲、セッションレプリケーション、ログの保存期間、バックアップ世代、障害時の復旧時間を見積もり条件に記載します。技術要素が見積書から消えていると、同じ金額でも含まれる品質や保守範囲を比較できません。金額と同時に、何を納品し、何を継続して支援するのかを確認することが重要です。

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

JSF案件の発注先は、単に「Javaが使える会社」ではなく、業務理解、JSFまたはJakarta Facesの実装知識、既存資産の移行、テスト、運用を一つの体制で扱えるかを見ます。JSF専門をうたう会社が多いかどうかより、対象バージョン、UI部品、実行基盤、認証、データ移行、クラウド運用を具体的に説明できるかが重要です。

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

候補先には、現在のJSFのバージョン、javaxからjakartaへの移行経験、Java 17または21への対応、利用するJSF実装とUIコンポーネント、アプリケーションサーバー、CDI・JPA・Bean Validationの設計方針を質問します。過去の実績を聞く際は、案件名だけでなく、画面数、利用者数、連携数、移行対象、テスト方法、リリース後の保守期間まで確認します。

回答を比較するため、候補先へ同じ小さな課題を渡す方法も有効です。複雑な一覧画面、権限による表示切り替え、二重送信防止、外部APIのタイムアウト処理を題材に、設計図とテスト観点を出してもらいます。コードの巧拙だけでなく、例外処理、ログ、監視、アクセシビリティ、将来の担当者が読める設計になっているかを評価します。

プロジェクト管理と保守体制を確認する

プロジェクト管理では、責任者、意思決定者、レビュー方法、課題管理、変更管理、受入基準、遅延時の報告方法を確認します。画面開発だけを別会社に任せる場合でも、業務側の責任者とデータ移行・運用の担当者を明確にし、仕様変更を誰が承認するかを決めます。契約方式が請負でも準委任でも、成果物と役割分担が曖昧なままだと、追加費用や納期の議論が後から発生しやすくなります。

納品後は、ソースコード、設計書、テスト結果、CI/CD設定、インフラ定義、運用手順、バックアップ手順、ライセンス一覧、脆弱性対応履歴を受け取れるか確認します。保守契約には、問い合わせ時間、障害の優先度、初動時間、復旧目標、パッチ検証、軽微改修の範囲、担当者交代時の引き継ぎを記載します。特定の担当者だけが分かる状態を残さないことが、JSFシステムを長く使うための重要な選定条件です。

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

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

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

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

業務システムの安全性は、ログイン画面があるかどうかだけで決まりません。入力値の検証、XSS、CSRF、セッション管理、権限分離、依存ライブラリ、監査ログ、バックアップ、復旧、運用担当者の権限まで、設計・実装・テスト・運用の各段階で確認します。JSFの状態管理は便利な一方、セッションサイズ、画面遷移、複数タブ、タイムアウトを要件に含める必要があります。

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

受入条件には、認証成功・失敗、パスワード再設定、権限のないURLへの直接アクセス、セッション固定、CSRFトークン、入力値のエスケープ、ファイルアップロード、エラー画面、ログへの個人情報出力を含めます。OWASP ASVS 5.0.0は、アーキテクチャ、認証、セッション管理、アクセス制御、入力検証などを検証する基準として2025年5月に公開されています（出典: OWASP Application Security Verification Standard 5.0.0、2025年）。このような基準をチェックリストに落とし込むと、担当者の経験だけに依存しにくくなります。

また、依存ライブラリの脆弱性スキャン、OSやJavaのパッチ適用、通信の暗号化、秘密情報の保管、監査ログの改ざん対策、バックアップからの復旧試験を計画します。クラウドへ移行する場合は、インターネット公開範囲、ネットワーク分離、WAF、監視、ログ保存、障害時の責任分界も確認します。開発会社に任せる部分と、自社の運用担当が担う部分を図にしておくことが重要です。

契約と納品物を曖昧にしない

契約前には、要件定義の成果物、設計書の粒度、ソースコードの範囲、第三者ライブラリのライセンス、データの帰属、再委託、秘密保持、障害対応、仕様変更の扱いを確認します。請負契約なら完成の判断基準、準委任契約なら作業範囲と報告方法を明確にします。情報システムのモデル取引に関する契約書でも、要件、役割、変更管理、検収、知的財産などの整理が重視されています（出典: 情報システム・モデル取引・契約書第二版、2025年更新）。

特に既存JSFの刷新では、旧システムのソースコードだけでなく、画面定義、DBスキーマ、ジョブ、運用手順、障害履歴、テストデータを扱います。移行後に不要になる資産と残す資産を分け、引き渡し時期と形式を決めておきます。納品物が不足すると、保守会社を変更したいときや、段階的に別の画面へ移行するときに、再調査費用が発生するためです。

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

JSFの採用判断では、技術の名前よりも既存資産、対象業務、費用、移行、保守の条件を合わせて見ることが大切です。ここでは、特に相談の多い疑問に直接回答します。

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

新規開発に使えないと一律に判断する必要はありません。現在はJakarta Faces 4.1がJakarta EE 11向けに提供され、Java SE 17以上を前提に仕様が整備されています。ただし、公開サービスの操作性やフロントエンドの独立性を優先する場合は、別構成の方が適することもあるため、代表画面のPoCで比較してから決めます。

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

移行できますが、APIの名前空間変更だけで完了するとは限りません。アプリケーションサーバー、JSF実装、UIコンポーネント、依存ライブラリ、設定ファイル、認証、テスト、デプロイ方法の互換性を確認し、代表画面で移行検証を行います。画面単位で段階移行する場合は、認証、データ、ログ、エラー処理を共通化してから進めると、二重運用の複雑さを抑えやすくなります。

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

移行できますが、JSFのセッション状態とファイル処理を先に検証する必要があります。セッションをどこに保持するか、複数インスタンスへ負荷分散したときに画面状態を維持できるか、アップロードファイルをどこへ保存するか、スケールアウトと障害復旧をどう実現するかを設計します。コンテナ化やマネージドサービスを採用する場合も、単にサーバーを移すのではなく、監視、バックアップ、ログ、パッチ、責任分界まで含めて移行計画を作成します。

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

最初に全機能を作るのではなく、利用頻度と事業効果の高い業務を絞り、代表画面のPoCと段階リリースを行う方法があります。既存の認証、帳票、マスタ、業務ロジックを再利用できるかも確認します。ただし、要件定義、セキュリティ、データ移行、テストを削ると、後から障害や追加改修として高くなるため、削減対象は画面の優先順位や不要な個別仕様に限定することが重要です。

まとめ：JSFのシステムは既存資産と保守体制で判断します

JSFのシステムは、入力や承認、権限、検索、帳票などが複雑な業務Webシステムと相性がよく、Javaの既存資産を活かせる場合に有力な選択肢です。現在のJakarta Faces 4.1やJava 17以上の前提を踏まえれば、新規開発や継続利用を検討できますが、javax系からjakarta系への移行、UI部品、実行基盤、セッション管理、テストを一体で確認することが欠かせません。

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

採用判断では、(1)既存Java・JSF資産をどれだけ再利用できるか、(2)業務画面の入力・権限・承認がどれだけ複雑か、(3)クラウドやスマートフォン対応で必要な操作性は何か、(4)3〜5年のTCOはいくらか、(5)移行後に保守できる体制があるかを整理します。費用は小規模400万〜1,200万円、中規模1,500万〜5,000万円、大規模5,000万円〜2億円以上を計画上の幅として置き、要件と人月に分解して見積もりを比較します。

次に行うべき準備

まずは、現行のJSF・Java・データベース・実行基盤・認証・外部連携を一覧にし、利用頻度と改修頻度の高い画面を3つ程度選びます。そのうえで、現行維持、Jakarta Facesへの移行、API分離、別フロントエンドへの段階移行を同じ条件で比較し、PoCの範囲と受入基準を決めます。発注時は、ソースコードや設計書の引き渡し、セキュリティ検証、データ移行、保守の交代可能性まで含めて確認すると、将来の選択肢を残せます。