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

WebSphereのシステムとは、WebSphere Application Server（WAS）を実行基盤として、Javaで作られた業務アプリケーションを安全かつ安定的に動かす企業向けシステムです。WASそのものが販売管理や顧客管理の業務ソフトではなく、アプリケーション、データベース、外部サービス、認証、メッセージングをつなぐ土台である点が重要です。

本記事では、WebSphereのシステムの全体像から、traditional WAS・Liberty・Open Libertyの違い、開発や移行の進め方、2026年時点の費用目安、セキュリティ、開発会社・ベンダーの選び方までをまとめます。既存環境を継続するべきか、クラウドやコンテナへ移行するべきか迷っている担当者にも、比較検討の軸が分かるように解説します。

WebSphereのシステムとは何ですか？

WebSphereのシステムは、業務アプリケーションを実行するアプリケーションサーバーと、その周囲のインフラや連携機能を組み合わせた仕組みです。画面や業務ロジックを持つアプリケーションをWASへ配備し、利用者からの要求を受け付け、データベースや外部システムとの処理を安全に完了させます。

WASは業務アプリではなく実行基盤です

WASには、WARやEAR形式のJavaアプリケーションを配備し、トランザクション処理、接続プール、セッション管理、認証・認可、TLS通信、ログ出力などを管理する機能があります。したがって、WASを導入しただけで業務システムが完成するわけではありません。受注や契約、在庫、会計などの業務ルール、画面、データモデル、外部連携は、別途アプリケーションとして設計・開発します。

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

WebSphereが長く使われてきた理由は、可用性や運用管理を重視する業務に必要な機能を、実行基盤として体系的に備えているためです。複数台のサーバーで処理を分散し、障害時に切り替え、データベースやメッセージング基盤との接続を集中管理できます。金融、保険、公共、製造など、停止時間や監査の要件が厳しい環境では、既存の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の機能、既存アプリとの互換性、商用サポート、障害時の問い合わせ先を確認してから採用します。

周辺基盤を含めた構成

実際のWebSphereシステムは、利用者、ロードバランサー、Webサーバー、WASクラスター、業務アプリ、データベース、メッセージング、認証基盤、監視・ログ、バックアップを組み合わせます。外部APIやホスト連携、ファイル連携がある場合は、タイムアウト、再送、重複実行、文字コード、障害時の復旧順序まで設計します。WASの設定だけを見ていると、周辺システムとの境界で起きる障害を見落としやすいです。

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

WebSphereの開発では、最初から製品設定に入るのではなく、業務要件と現行資産を整理してから技術選択を行います。特に移行案件では、動いているように見えるアプリでも、設定ファイルや運用担当者の経験に依存している処理が残っていることがあります。診断、設計、実装、試験、移行、運用引き継ぎを一つの流れとして計画します。

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

要件定義と現状診断

まず、業務の目的、対象ユーザー、処理量、許容停止時間、目標復旧時間（RTO）、目標復旧時点（RPO）、個人情報や決済情報の有無を定義します。続いて、WASのバージョン、Java SDK、WAR・EAR、フレームワーク、JNDI、JMS、接続先データベース、証明書、バッチ、外部API、監視、バックアップ、ソースコードと設定ファイルの所在を一覧化します。

現状診断の成果物は、アプリケーション一覧だけでは不十分です。互換性リスク、不要な機能、性能上のボトルネック、運用上の属人化、移行後に再現できない設定を分けて記録します。この調査を4〜8週間で行い、次の工程に進めるか判断するアセスメントとして発注する方法もあります。

設計・構築・アプリ改修

設計では、ネットワーク分離、サーバー台数、クラスター、セッション管理、データベース接続、メッセージング、認証・認可、ログ、バックアップ、監視、障害通知を決めます。Libertyやコンテナを採用する場合は、server.xmlなどの設定をコード管理し、イメージの作成、脆弱性検査、環境差分の管理、ロールバック方法まで含めます。

アプリケーション改修では、非推奨API、古いJDKへの依存、独自クラスローダー、JNDI名、JMSキュー、証明書、ファイルパスを確認します。サーバーを入れ替えるだけで済むケースもありますが、Libertyへの再配置やJakarta EE対応では、設定や依存ライブラリの変更が発生しやすいです。変更点を画面単位ではなく、処理・連携・データ単位で管理します。

テスト・移行・リリース

テストは、単体や画面の正常系だけでなく、連携、負荷、障害切り替え、バックアップ復元、セキュリティ、運用手順を確認します。DB停止、MQ滞留、認証失敗、通信遅延、証明書の期限切れ、片系停止などを再現し、どの監視が検知して、誰が、何分以内に、どの手順で復旧するかを確認します。

データ移行では、件数だけでなく、金額や数量の合計、文字コード、時刻、重複、欠損、再送、監査証跡を照合します。段階移行、並行稼働、切り戻しの条件を先に決め、リハーサルで所要時間を測定します。初回リリースから全機能を切り替えず、利用部門や業務領域を分けて段階的に展開すると、問題の影響範囲を抑えやすいです。

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

WebSphere案件の費用は、ライセンスだけでなく、現状診断、アプリ改修、基盤構築、データ移行、テスト、運用設計まで含めて考えます。国内のWebSphere開発に一律の標準価格表はないため、以下は業務システムの一般的な工数とWebSphere特有の作業をもとにした初期検討用の推定レンジです。正式な予算は、アプリ数、連携数、可用性、データ量、停止可能時間を伝えて見積もります。

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

規模別の開発費と期間

現状診断・移行アセスメントは、100万〜300万円程度、期間は4〜8週間が一つの目安です。小規模な環境構築と単純な業務アプリ1〜数本であれば、300万〜700万円程度、3〜6か月程度を想定します。開発・テスト環境、認証、監視、バックアップ、基本的な自動化まで含めると、WASをインストールするだけの費用より大きくなります。

traditional WASからLibertyやコンテナへ再配置する案件は、500万〜2,000万円程度、3〜9か月程度が目安です。複数業務・複数拠点でDB、メッセージング、外部API、権限、監査ログ、データ移行を伴う場合は、1,000万〜3,000万円程度、6〜12か月程度を見込みます。24時間365日の基幹システムで多重化、災害対策、性能限界試験、段階切替まで必要な場合は、3,000万円〜1.5億円以上、9〜24か月に及ぶことがあります。

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

製品提供元のWebSphere Hybrid Edition公式価格ページでは、Standard subscriptionが「Starting at USD 759.00」と表示されています。ただし、これは国・税・提供条件で変わる参考表示で、契約期間や課金単位、日本向けの価格を意味するものではありません（出典: 製品提供元の公式価格ページ、2026年8月確認）。1ドル150円で換算して約11.4万円になりますが、年間料金や案件総額と断定しないでください。

別途、仮想マシンやコンテナの利用料、OS、データベース、ネットワーク、バックアップ、監視、ログ保管、転送量、サポート契約が発生します。保守費は初期開発費の年15〜25％程度を仮置きし、問い合わせ対応、障害対応、脆弱性修正、Java更新、OS更新、性能改善、定期リハーサルをどこまで含むか分けて見積もります。安い初期費用だけでなく、3〜5年の総保有コストで比較します。

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

WebSphereの選択肢は、既存WASの継続、Libertyへの再配置、コンテナ化、主要クラウドのIaaSへの移行、パッケージ活用、Javaでのスクラッチ開発に分けられます。重要なのは、流行の技術へ置き換えることではなく、業務の停止リスク、変更の頻度、運用人材、将来の拡張性を合わせて判断することです。

既存WASを継続するケース

既存WASの継続は、アプリケーションの変更を最小限にし、短期間で安定運用を続けたい場合に向いています。サポート情報では、8.5.5と9.0.5に計画されたサポート終了日はないと案内されています（出典: 製品提供元のサポート情報、2025年7月更新）。ただし、WAS本体に終了日がなくても、Java、OS、データベース、周辺ミドルウェア、個別の修正レベルまで継続利用できるとは限りません。

継続を選ぶ場合は、現行バージョンと修正レベル、脆弱性対応の期限、担当者の確保、障害復旧手順を確認します。設定が担当者の記憶だけに依存している、開発環境を再構築できない、古いJDKに依存しているといった状態なら、継続は先送りであって解決ではありません。

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

Libertyやコンテナへの段階移行は、既存資産を活かしながら、起動時間、環境再現性、自動化、リリース頻度を改善したい場合に向いています。すべてのアプリを一度に分割するのではなく、依存関係が少なく、テストしやすい業務から再配置し、効果と互換性を確認して次へ進みます。

移行支援ツールを使う場合も、判定結果をそのまま採用してはいけません。ツールはAPIや設定の候補を見つける補助であり、業務仕様、外部連携、性能、障害時の挙動、監査要件を保証するものではないためです。代表的な処理を使ったPoCを行い、改修量、性能、運用負荷、切り戻し方法を確認します。

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

IaaSへ移す場合は、サーバーの置き場所が変わるだけのリフト、WASをLibertyなどへ再配置するリホスト、アプリを改修するリファクタリングを区別します。クラウド化すれば必ず安くなるわけではなく、ライセンス、データベース、ネットワーク、バックアップ、監視、転送量、運用体制を含めて比較します。公開された大規模事例では、CPUコアを54％、メモリを33％削減した結果が示されていますが、これは特定構成での実績であり、そのまま自社の削減率にはできません。

業務パッケージとWebSphereを組み合わせる場合は、標準機能を優先し、アドオンを増やしすぎないことが重要です。独自業務が競争力の中心ならスクラッチ開発が適する場合もありますが、WASは実行基盤にすぎないため、業務要件、画面、DB、API、権限、監査、保守を別途設計します。

セキュリティと運用で確認すべきこと

WebSphereの安全性は、製品を導入しただけで決まりません。管理コンソール、アプリケーション、ネットワーク、認証基盤、データベース、ログ、パッチ、委託先の運用を一つのシステムとして設計します。個人データを扱う場合は、法令やガイドラインの要求を、アクセス制御、認証、監査ログ、暗号化、バックアップ、委託先管理といった具体的な設定・手順へ落とし込みます。

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

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

個人情報保護に関する公的ガイドラインでは、担当者と取り扱うデータの範囲を限定するアクセス制御、外部からの不正アクセスや不正ソフトウェアから保護する仕組みが示されています（出典: 個人情報保護に関する公的ガイドライン、2025年以降確認）。WebSphere側のロールだけでなく、データベース、ログ、バックアップ、運用端末まで権限を確認します。

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

TLSは、暗号スイート、プロトコル、証明書の保管場所、更新担当、期限切れ時の通知、外部連携との相互接続性を決めます。公的なTLS暗号設定ガイドライン第3.1.1版は2025年4月25日に公開され、高セキュリティ型、推奨セキュリティ型、セキュリティ例外型の考え方を示しています（出典: TLS暗号設定ガイドライン、第3.1.1版、2025年4月25日）。特別な要件がなければ、推奨設定を基準に検討します。

脆弱性対応は、発表を読むだけでなく、対象バージョン、影響範囲、修正パック、適用手順、再起動の要否、業務テストを管理します。2026年7月14日付のLiberty 26.0.0.7では、9件のAPARのうち4件がセキュリティAPARとして掲載されています（出典: 製品提供元のLiberty修正一覧、2026年7月14日）。修正前の検証環境、緊急時の適用判断、適用後のログ確認を運用手順に含めます。

ログは、認証、権限変更、管理操作、重要データへのアクセス、エラー、外部連携、バッチの開始・終了を追跡できる粒度にします。保存期間、改ざん防止、時刻同期、検索権限、個人情報のマスキングを決め、障害調査と監査の両方で使える状態にします。

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

WebSphereの発注先は、製品名を知っているかだけでなく、Javaアプリケーション、基盤、クラウド、テスト、運用を一体で扱えるかを確認します。特に移行案件では、WASの設定を作る担当者とアプリの依存関係を解析する担当者が別々だと、責任範囲の境界で問題が起きやすいです。問い合わせ前に現行環境の資料を整理し、同じ条件で複数の提案を比べます。

経験と技術範囲を確認する

確認する実績は、WebSphereの導入年数ではなく、現行バージョン、Java EE・Jakarta EE、Liberty、Open Liberty、コンテナ、Kubernetes、データベース、メッセージング、認証、性能試験まで具体化します。自社と同じ業界、ユーザー数、ピーク負荷、連携数、停止制約を持つ案件で、どの工程を担当したかを聞きます。公開できない場合でも、匿名化した構成図や課題、成果物のサンプルを確認します。

「WASを構築できます」という回答だけでは判断できません。現行設定の解析、移行可否の判定、アプリ改修、性能限界試験、障害切り分け、パッチ適用、運用引き継ぎを誰が行うか、足りない専門性をどのパートナーで補うかを提案書に書いてもらいます。

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

見積書は、要件定義、アセスメント、設計、環境構築、アプリ改修、データ移行、テスト、リリース、運用設計に分けてもらいます。「一式」の金額には、対象アプリ数、環境数、テストケース数、移行リハーサル回数、夜間切替、障害対応時間、追加変更の単価が含まれているか確認します。ライセンス、クラウド、機器、保守を開発費と混ぜないことも大切です。

契約前には、設計書、構成管理情報、server.xmlなどの設定、IaC、テスト仕様書、結果報告書、運用手順、ソースコード、ビルド手順、アカウント情報の引き渡し範囲を確認します。著作権、翻案、第三者ライブラリのライセンス、脆弱性修正の責任、サポート時間、復旧目標、再委託の扱いも明文化します。

提案時に聞くべき質問

提案時は、「現在のWASを継続する場合のリスクは何ですか」「Libertyへ移行できない機能は何ですか」「移行前にどのログや設定を確認しますか」「性能試験の同時接続数と合格基準は何ですか」と質問します。さらに、「障害時にどのチームが一次対応しますか」「修正パックの適用を誰が判断しますか」「引き渡し後に自社で環境を再構築できますか」と聞くと、保守の実態が見えやすくなります。

提案内容は、価格、納期、技術方式の三つだけで決めません。想定リスクを先に書いているか、前提条件が明確か、検証期間が確保されているか、運用担当者の教育があるか、将来の変更費用を抑えられる成果物が残るかを総合的に比べます。

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

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

よくある質問

WebSphereのシステムを検討するときは、製品の古さ、代替可否、移行費用、保守範囲に疑問が集まりやすいです。ここでは、導入前に特に確認しておきたい質問へ直接回答します。

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

すぐに廃止する必要はありません。8.5.5と9.0.5には計画されたサポート終了日がないと案内されていますが、JavaやOS、周辺製品の状態、修正パック、運用人材を含めて継続可否を判断します。現状診断でリスクを数値化し、継続、更新、Libertyへの移行を段階的に選びます。

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

アプリケーションの要件によっては代替できますが、単純な置き換えではありません。トランザクション、JNDI、JMS、認証・認可、クラスター、管理、監査、既存APIの互換性を比較し、必要な機能を別の仕組みで補う必要があります。業務停止の影響が大きい場合は、代表アプリのPoCと性能・障害試験を終えてから判断します。

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

必ず下がるわけではありません。必要な機能だけを動かし、サーバーや運用を効率化できる可能性はありますが、アプリ改修、互換性検証、コンテナ基盤、CI/CD、監視、教育の初期費用が発生します。初期費用だけでなく、ライセンス、クラウド、保守、障害対応を含めた複数年の総額で比較します。

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

互換性と改修範囲を正確に調べるには、ソースコード、ビルド手順、依存ライブラリ、設定ファイル、DB定義、外部連携仕様、テストデータが必要です。すべてがそろわなくても診断はできますが、不明点が多いほど予備調査と見積もりの不確実性が増します。契約時に引き渡し範囲と知的財産の扱いを確認し、将来の再構築に必要な情報を残します。

まとめ

WebSphereのシステムは、Java業務アプリケーションを支える実行基盤であり、WAS単体ではなく、データベース、メッセージング、認証、監視、バックアップ、運用手順まで含めて設計します。traditional WASの継続、LibertyやOpen Libertyへの再配置、コンテナ化、クラウド移行のどれが適するかは、現行資産と業務要件を診断してから決めます。

失敗を防ぐための要点

費用はライセンスだけでなく、診断、アプリ改修、環境構築、データ移行、非機能試験、保守まで分けて把握します。2026年時点の修正情報を継続的に確認し、管理画面の分離、最小権限、TLS、監査ログ、バックアップ復元、ロールバックを要件に含めます。発注時は、対象範囲、成果物、契約上の権利、脆弱性対応、運用引き継ぎを曖昧にしないことが重要です。

最初に行うべきこと

最初の一歩は、WASのバージョン、Java、アプリ数、DB・メッセージング、外部連携、ピーク負荷、停止可能時間、運用体制、ソースコードと設定の所在を一覧にすることです。その資料をもとに現状診断を依頼し、継続・移行・クラウド化の複数案を同じ前提で比較すると、過大な改修や予期しない追加費用を抑えやすくなります。