WebSphereのシステム開発の完全ガイド

WebSphereのシステム開発は、業務アプリを動かす実行基盤と周辺の基盤を組み合わせ、実行環境、互換性、可用性の要件を整理することから始まります。

種類と構成、進め方、費用、選び方を、診断から運用までの流れに沿って見ると、全体像を判断できます。

Webサービス開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。

WebSphereのシステムの概要

WebSphereのシステムは、業務アプリを実行するアプリケーションサーバーに、インフラや連携機能を組み合わせた仕組みです。

画面や業務ロジックを持つアプリはWASに配備します。WASは利用者の要求を受け付け、DBや外部システムとの処理を安全に完了させます。

WASの位置づけ（実行基盤）

WASは、WARやEAR形式のJavaアプリを配備し、トランザクション、接続プール、セッション管理を扱う実行基盤です。

認証・認可、TLS通信、ログ出力もWASが管理します。ただし、WASだけでは業務システムは完成しません。

具体的には、受注、契約、在庫、会計などの業務ルールや画面、データモデル、外部連携を、別のアプリとして設計・開発します。

企業向けシステムで採用される理由

WebSphereは、可用性や運用管理を重視する業務に必要な機能を、実行基盤として体系的に備えています。

複数のサーバーで処理を分散し、障害時には切り替えられます。さらに、DBやメッセージング基盤との接続も集中して管理できます。

特に、金融、保険、公共、製造など停止時間や監査の要件が厳しい環境では、既存のJava資産と運用ノウハウを活かせる点が利点になります。

WebSphereの種類とシステム構成

基盤同士の接続をまとめて把握できます。

WebSphereには、大規模業務システムを支えるtraditional WASと、必要な機能を選んで軽量に動かすLibertyがあります。

Open Libertyも含め、オンプレミス、仮想マシン、コンテナ、ハイブリッド環境を比べられます。

まず互換性、可用性、運用体制、将来の変更頻度を基準に整理し、そのうえで種類を選びます。

traditional WASの特徴

traditional WASは、Java EEを使う既存アプリとの互換性や、豊富な管理機能を重視する場合に向いています。

Base：単一サーバーに近い構成で使う方式です。
Network Deployment：複数サーバーのクラスター、集中管理、高可用性を組み合わせた構成です。

既存のJNDI、JMS、証明書、バッチ、監視手順を大きく変えずに、運用を続けやすい方式です。

古いJavaやOS、独自の設定が残っている場合は、更新の前に一覧にして洗い出す必要があります。

LibertyとOpen Libertyの特徴

Libertyは、必要な機能だけを有効にして動かすランタイムで、少ないメモリで起動しやすいのが特徴です。

コンテナ運用：Kubernetes、CI/CDとの親和性が高く、アプリ分割や環境構築のコード化に適します。
Open Liberty：オープンソース系の選択肢の一つです。

採用の前に、必要なJava EE・Jakarta EE・MicroProfile機能が使えるか、既存アプリと互換性があるかを確かめます。あわせて、商用サポートと障害時の問い合わせ先も確認します。

周辺基盤を含めた構成

実際の構成には、利用者からの入口にあたるロードバランサーやWebサーバーを含めます。さらに、WASクラスター、業務アプリ、DB、メッセージングも組み合わせます。

認証基盤、監視・ログ、バックアップも構成に入れます。一方、外部API、ホスト、ファイルとの連携では、境界の条件を設計する必要があります。

境界の障害は、WAS設定だけを見ていると見落としやすくなります。そのため、タイムアウト、再送、重複実行、文字コード、障害時の復旧順序を決めておきます。

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

診断結果を後続の設計と移行へつなげます。

開発では、まず業務要件と現行資産を整理し、そのあとで技術を選びます。設定ファイルや担当者の経験に頼っている処理も、あわせて調べます。

診断、設計、実装、試験、移行、運用引き継ぎは、一つの流れとして計画します。

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

要件定義と現状診断

要件定義と現状診断では、まず業務条件と現行資産を分けて整理します。

業務条件：目的や対象ユーザー、処理量、許容停止時間を定めます。RTO、RPO、個人情報や決済情報の有無も定義します。
実行環境：WASのバージョン、Java SDK、WAR・EAR、フレームワークの一覧です。
連携・運用資産：JNDI、JMS、接続先DB、証明書、バッチ、外部APIの情報を控えます。監視、バックアップ、ソースコードと設定ファイルの所在も記録します。

現状診断では、アプリケーション一覧に加えて、互換性リスク、不要機能、性能ボトルネック、運用の属人化も記録します。

移行後に再現できない設定は、別に分けて記録しておきます。また、調査は4〜8週間で行い、次の工程へ進むかを判断するアセスメントとして発注する方法もあります。

設計・構築・アプリ改修

設計とアプリ改修では、基盤構成とアプリの依存関係を、それぞれ分けて確かめます。基盤設計では、メッセージング、ログ、バックアップも併せて決めます。そのほか、認証・認可、監視、障害通知も決めます。

基盤設計：ネットワーク分離、サーバー台数、クラスター、セッション管理、DB接続を決めます。
Liberty・コンテナ：server.xmlなどのコード管理、イメージ作成、脆弱性検査、環境差分、ロールバックを扱います。
アプリ依存：非推奨API、古いJDK、独自クラスローダー、JNDI名を調べます。JMSキュー、証明書、ファイルパスも確認対象です。

サーバーを入れ替えるだけで済む場合もあります。ただし、Liberty再配置やJakarta EE対応では、設定や依存ライブラリの変更が起きがちです。そのため、変更点は画面単位ではなく、処理・連携・データの単位で管理します。

テスト・移行・リリース

テスト、移行、リリースは、品質の確認から切替準備までを、この順に進めます。

テスト：画面の正常系、連携、負荷、障害切り替え、復元を確かめます。
データ照合：件数、金額・数量の合計、文字コード、時刻を突き合わせます。
切替準備：段階移行、並行稼働、切り戻しの条件を決めたうえで、リハーサルにより所要時間を測ります。

セキュリティと運用手順も検証し、重複、欠損、再送、監査証跡も照合します。さらに、DB停止、MQ滞留、認証失敗、通信遅延、証明書切れ、片系停止を実際に再現します。監視で検知する人、復旧を担当する人、期限、手順も併せて確かめます。

初回リリースでは、全機能を一度に切り替えず、利用部門や業務領域ごとに分けて展開します。そうすると、問題の影響範囲を抑えやすくなります。

ポイント

現状診断で現行資産を洗い出しておくと、設計、テスト、移行の工程を見積もる前提がそろいます。診断の範囲を先に決めておくと、後の工程で手戻りが増えにくくなります。

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

費用は、ライセンスのほか、診断、アプリ改修、基盤構築を含めて考えます。さらに、データ移行、テスト、運用設計も費用に入れます。

国内に一律の標準価格表はありません。そのため、次の金額は、一般的な業務システムの工数とWebSphere特有の作業をもとにした、初期検討用の推定レンジとして見てください。

正式な予算は、アプリ数、連携数、可用性、データ量、停止可能時間を開発会社に伝えて、見積もってもらいます。

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

規模別の開発費と期間

開発費と期間には幅があり、診断から大規模基幹の移行まで、対象範囲によって変わります。

診断：現状診断・移行アセスメントは100万〜300万円程度、4〜8週間が目安です。
小規模構築：単純な業務アプリ1〜数本なら300万〜700万円程度、3〜6か月程度です。
再配置：traditional WASからLiberty・コンテナへの移行は500万〜2,000万円程度、3〜9か月程度です。
複数業務・拠点：DB、メッセージング、外部API、権限、監査ログ、データ移行を伴う場合は1,000万〜3,000万円程度、6〜12か月程度です。
大規模基幹：24時間365日運用で多重化、災害対策、性能限界試験、段階切替が必要なら3,000万円〜1.5億円以上、9〜24か月に及ぶことがあります。

開発・テスト環境、認証、監視、バックアップ、基本的な自動化まで含めると、費用はWASのインストールだけの場合より大きくなります。

ライセンス費とランニングコスト

製品提供元のWebSphere Hybrid Edition公式価格ページには、Standard subscriptionの表示があり、「Starting at USD 759.00」と記載されています。

この表示は国・税・提供条件で変わる参考表示で、契約期間や課金単位、日本向けの価格を示すものではありません（出典: 製品提供元の公式価格ページ、2026年8月確認）。

換算の扱い：1ドル150円なら約11.4万円ですが、年間料金や案件総額とは断定できません。
別途費用：仮想マシン・コンテナ、OS、DB、ネットワークが発生します。バックアップ、監視、ログ保管、転送量、サポート契約も別途かかります。
保守費：初期開発費の年15〜25％程度を仮置きします。

保守費は、問い合わせ、障害対応、脆弱性修正の範囲を分けて見積もります。そのほか、Java・OS更新、性能改善、定期リハーサルも対象です。初期費用だけでなく、3〜5年の総保有コストで比べます。

ポイント

規模は、アプリ数や連携数、可用性の要件、停止可能時間で大きく変わります。見積もりを頼む前にこれらを整理して伝えると、比べやすい見積もりが集まります。

継続・移行・クラウド化の選び方

選択肢には、既存WASの継続、Liberty再配置、コンテナ化、主要クラウドへのIaaS移行、パッケージ活用、Javaでのスクラッチ開発があります。

業務停止リスク、変更頻度、運用人材、将来の拡張性を合わせて判断します。流行の技術に置き換えるかどうかも、これらを踏まえて決めます。

既存WASを継続するケース

既存WASの継続は、アプリ変更を最小限にして短期間で安定運用を続けたい場合に向いています。

サポート状況：8.5.5と9.0.5に計画された終了日はないと案内されています（出典: 製品提供元のサポート情報、2025年7月更新）。
関連製品：Java、OS、DB、周辺ミドルウェア、個別の修正レベルまで、継続利用できるとは限りません。
運用確認：現行バージョンと修正レベル、脆弱性対応期限、担当者、障害復旧手順を確認します。

設定が担当者の記憶に頼っている、開発環境を再構築できない、古いJDKに依存している。こうした状態なら、継続しても問題を先送りするにすぎません。

Liberty・コンテナへ段階移行するケース

Libertyやコンテナへの移行は、既存資産を活かして起動時間、環境再現性、自動化、リリース頻度を改善したい場合に適しています。

依存関係が少なく、テストしやすい業務から再配置します。
効果と互換性を確認してから、次へ進みます。
代表的な処理でPoCを行い、改修量、性能、運用負荷、切り戻し方法を確かめます。

移行支援ツールは、APIや設定の候補を見つける補助として使えます。ただし、業務仕様、外部連携、性能、障害時の挙動、監査要件までは保証しません。

クラウドやパッケージを組み合わせるケース

クラウド、パッケージ、スクラッチを組み合わせる場合は、移行の方式と業務要件を分けて比べます。

IaaS移行：置き場所だけを変えるリフト、WASをLibertyなどへ再配置するリホスト、アプリ改修を伴うリファクタリングを区別します。
費用比較：クラウド化で必ず安くなるとは限りません。ライセンス、DB、ネットワーク、バックアップを含めて比べます。加えて、監視、転送量、運用体制も含めます。
事例の扱い：公開事例ではCPUコア54％、メモリ33％の削減結果があります。ただし、特定構成の実績なので、自社の削減率としてはそのまま使えません。
業務機能：パッケージでは標準機能を優先し、アドオンを増やしすぎないようにします。独自業務が競争力の中心なら、スクラッチが適する場合もあります。

WASは実行基盤にすぎません。そのため、業務要件や画面、DB、APIは別途設計します。権限、監査、保守も設計の対象になります。

ポイント

継続、移行、クラウド化のどれにするかは、業務停止リスクと変更頻度、運用人材を並べて比べると絞り込みやすくなります。

セキュリティと運用の確認項目

複数の対策を組み合わせて保護します。

安全性は、製品を導入したあとも、システム全体で確保する必要があります。そのため、管理コンソール、アプリ、ネットワーク、認証基盤、DB、ログを、一つのシステムとして設計します。パッチや委託先の運用も対象に含めます。

個人データを扱う場合は、法令やガイドラインの要求を、具体的な対策に落とし込む必要があります。たとえば、アクセス制御と認証、監査ログ、暗号化が挙げられます。バックアップや委託先管理も含みます。

認証・認可・管理画面の分離

管理画面、権限、多要素認証、アカウント管理は、それぞれ分けて確認します。

管理画面：業務画面から分離し、管理ネットワークや踏み台経由に限定します。
権限：利用者・運用担当者・開発担当者・監査担当者を分け、不要な管理権限は与えません。
認証・アカウント：多要素認証の既存ID基盤連携と、異動・退職時の無効化自動化を確かめます。

公的ガイドラインでは、担当者と扱うデータの範囲を限定するアクセス制御や、不正アクセス・不正ソフトウェアから守る仕組みが示されています（出典: 個人情報保護に関する公的ガイドライン、2025年以降確認）。

WASのロールだけでなく、DB、ログ、バックアップ、運用端末まで権限を確かめます。

TLS・脆弱性・ログの継続管理

TLS設定では、暗号スイートとプロトコルを決めます。あわせて、証明書の保管場所、更新担当、期限切れ通知、外部連携との相互接続性も決めます。

TLS基準：ガイドラインの3区分を確認し、要件に応じた設定を選びます。
脆弱性対応：影響を調べ、適用から業務テストまで管理します。
ログ管理：必要な操作を記録し、保存・検索の条件を決めます。

TLS暗号設定ガイドラインは、第3.1.1版が2025年4月25日に公開されています（出典: TLS暗号設定ガイドライン、第3.1.1版、2025年4月25日）。

同版は、高セキュリティ型、推奨セキュリティ型、セキュリティ例外型の3区分を示しています。

特別な要件がなければ、推奨設定を基準にします。そのうえで、対象バージョン、影響範囲、修正パック、適用手順、再起動、業務テストを管理します。

Liberty 26.0.0.7は2026年7月14日付で、9件中4件がセキュリティAPARです（出典: 製品提供元のLiberty修正一覧、2026年7月14日）。

手順には、検証環境、緊急時の適用判断、適用後のログ確認も含めます。ログには、認証、権限変更、管理操作、重要データへのアクセスを記録します。

エラー、外部連携、バッチの開始と終了も記録対象です。そのうえで、保存期間、改ざん防止、時刻同期、検索権限、個人情報のマスキングを決め、障害調査と監査に使います。

ポイント

導入後の運用まで含めて安全性を見るため、権限、TLS、ログ、脆弱性対応を要件に入れておくと、後からの追加対応を減らせます。

開発会社/ベンダーの選び方

発注先には、製品名の知識だけでなく、Javaアプリ、基盤、クラウド、テスト、運用を一体で扱える力があるかを確認します。

移行案件では、WAS設定の担当とアプリ依存関係の解析担当が別々だと、責任範囲の境界で問題が起きやすくなります。

問い合わせ前に現行環境の資料を整理し、同じ条件で複数の提案を比べます。

経験と技術範囲の確認

「WASを構築できます」という回答があっても、実際の力は見えにくいものです。導入年数に加えて、対象技術と類似案件の経験を確認します。

技術範囲：WebSphereの現行版やJava基盤、コンテナ、DB、認証、性能試験の経験を確認します。
類似案件：業界、ユーザー数、ピーク負荷、連携数、停止制約が近い案件と担当工程を聞きます。公開できない場合は、匿名化した構成図、課題、資料の例を確認します。
担当体制：設定解析、移行可否の判定、アプリ改修を誰が担うかを確かめます。さらに、性能限界試験、障害切り分け、パッチ適用、運用引き継ぎの担当も確かめます。

技術範囲には、Java EE・Jakarta EE、Liberty・Open Liberty、Kubernetes、メッセージングも含めます。

また、不足する専門性をどのパートナーが補うかも、提案書に記載してもらいます。

見積もりの前提と成果物の比較

見積額の前提、成果物、契約条件は、分けて比べます。

費用内訳：要件定義、アセスメント、設計、環境構築に分けてもらいます。アプリ改修、データ移行、テスト、リリース、運用設計も、項目ごとに示してもらいます。
見積前提：「一式」に含まれる対象アプリ・環境・テストケース数を確認します。移行リハーサルの回数、夜間切替、障害対応時間、追加変更の単価も押さえます。
成果物：契約前に、引き渡しの範囲を確かめます。
契約条件：ライセンス、クラウド、機器、保守は開発費と分けます。著作権・翻案、第三者ライブラリ、脆弱性修正、サポート時間、復旧目標、再委託は明文化します。

契約前には、設計書、構成管理情報、server.xmlなどの設定、IaCについて、引き渡しの範囲を確かめておきます。

テスト仕様書と結果報告書、運用手順は、引き渡しの対象に含めます。ソースコード、ビルド手順、アカウント情報も対象です。

提案時に聞くべき質問

提案では、移行リスク、性能・障害対応、引き渡し後の自立運用を質問します。

移行リスク：WAS継続のリスク、Libertyへ移行できない機能、移行前に確認するログや設定は何か。
試験と保守：性能試験の同時接続数・合格基準、障害時の一次対応チーム、修正パックの適用判断者は誰か。
引き渡し：引き渡し後に自社で環境を再構築できるか。
提案比較：価格・納期・技術方式だけでなく、提案全体を評価します。

価格、納期、技術方式を比べたうえで、リスクを先に示しているか、前提条件が明確かも確認します。

検証期間、運用担当者の教育、将来の変更費用を抑えられる成果物があるかも、総合的に比べます。

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

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

ポイント

発注先は、製品の知識に加えて、移行から運用引き継ぎまで一体で任せられるかで比べます。同じ前提で複数の提案を取ると、比べやすくなります。

よくある質問

製品の古さ、代替の可否、移行費用、保守の範囲は、疑問が集まりやすい部分です。導入前に確認しておきたい質問に、回答します。

WebSphereは古いシステムなので、すぐに廃止すべきですか？

すぐに廃止する必要はありません。8.5.5と9.0.5には、計画されたサポート終了日がないと案内されています。

Java、OS、周辺製品、修正パック、運用人材まで含めて、継続してよいかを判断します。診断でリスクを数値化したうえで、継続、更新、Liberty移行を段階的に選びます。

WebSphereはTomcatなどの軽量サーバーで代替できますか？

要件によっては代替できますが、単純な置き換えではありません。トランザクション、JNDI、JMS、認証・認可、クラスターを比較します。

管理や監査、既存APIとの互換性も確認したうえで、不足する機能は別の仕組みで補います。停止の影響が大きい場合は、代表アプリのPoCと性能・障害試験を行ったあとに判断します。

Libertyへ移行すれば必ず費用を下げられますか？

必ず下がるとは限りません。必要な機能だけを動かすことで、サーバーや運用を効率化できる可能性はあります。

一方で、アプリ改修、互換性検証、コンテナ基盤、CI/CD、監視、教育には、初期費用がかかります。そのため、ライセンス、クラウド、保守、障害対応を含めた複数年の総額で比べます。

移行にソースコードや設定ファイルは必要ですか？

互換性と改修範囲の調査には、ソースコード、ビルド手順、依存ライブラリ、設定ファイルが必要です。さらに、DB定義、外部連携仕様、テストデータも必要です。

すべてそろっていなくても診断はできますが、不明点が多いほど、予備調査と見積もりの不確実性が増します。

契約時には、引き渡しの範囲と知的財産の扱いを確認します。あわせて、将来の再構築に必要な情報も残しておきます。

まとめ

WebSphereは、Java業務アプリを支える実行基盤です。DBやメッセージング、認証、監視だけでなく、バックアップや運用手順まで含めて設計します。

traditional WASの継続、LibertyやOpen Libertyへの再配置、コンテナ化、クラウド移行は、現行資産と業務要件を診断して選びます。

失敗を防ぐための要点

費用は、ライセンスや診断、改修、構築に分けて把握します。移行、非機能試験、保守も、それぞれ分けて見ておきます。

2026年時点の修正情報は継続して確認します。そのうえで、管理画面の分離、最小権限、TLS、監査ログ、バックアップ復元、ロールバックを要件に含めます。

発注時は、対象範囲、成果物、契約上の権利、脆弱性対応、運用引き継ぎを明確にします。

最初に行うべき準備

現状診断を依頼する前に、現行環境の情報を一覧にまとめておきます。

基盤と業務：WASのバージョン、Java、アプリ数、ピーク負荷、停止可能時間を記録します。
連携環境：DB・メッセージング、外部連携、運用体制を整理します。
管理資料：ソースコードと設定の所在を記録し、その資料をもとに現状診断を依頼します。

継続、移行、クラウド化の複数案を同じ前提で比べると、過大な改修や予期しない追加費用を抑えやすくなります。

▼開発を相談する前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
 ・【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を創業。