LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

WebLogic・WebSphereとは？基幹システムを支える商用Javaアプリケーションサーバー

Oracle WebLogic ServerとIBM WebSphere Application Serverは、Java EE（現Jakarta EE）仕様に基づく業務アプリケーションを稼働させる商用アプリケーションサーバーです。金融・製造・公共分野の基幹システムなど、長期の安定稼働が求められる領域で採用されてきました。

両製品とも、トランザクション管理・クラスタリング・高可用性構成といった企業向け機能を備え、ベンダーの有償サポートを前提に運用されてきました。一方でライセンス費用や旧バージョンのサポート状況は年々変化しており、情シス部門や基幹Java運用の担当者にとって、現行バージョンのサポート状況を定期的に確認する作業が欠かせません。

Oracle WebLogic Serverのサポート終了時期とライセンスの考え方

Fusion Middleware 12cのPremier Support終了は2026年12月

Oracleの公式サポート方針「Oracle Lifetime Support Policy（Oracle Fusion Middleware）」は、Oracle Fusion Middleware 12c（12.2.x系・WebLogic Server 12cを含む製品群）についてPremier Supportが2026年12月に終了し、続くExtended Supportも2027年12月に終了する予定であると示しています^*1。同方針によれば、この期限を過ぎるとOracleはアップデートやセキュリティ修正を提供しなくなり、技術支援はOracle Lifetime Support Policyに基づいて提供されるとされています^*1。

本稿執筆時点（2026年7月）でPremier Support終了まで残り半年程度であり、現行バージョンを使い続ける企業は、アップグレードまたは移行の計画を具体的に検討する段階に入っていると言えるでしょう。Extended Support期間中は追加費用と引き換えにセキュリティ修正が継続される一方、期限後の対応方針は公式情報で改めて確認する必要があります^*1。

ライセンス費用はエディション・契約内容によって異なる

WebLogic Serverのライセンス費用は、プロセッサ数やエディション区分（Standard Edition・Enterprise Edition等）、契約内容によって大きく異なります。具体的な金額は個々の契約に依存するため、本稿では確定額を示さず、費用の見積もりはOracleまたは販売代理店への確認をおすすめします。年間の保守費用はライセンス体系に連動する仕組みが一般的であり、旧バージョンを使い続けるほど、支払う費用に対して得られるサポート範囲が狭まっていく可能性がある点は押さえておきたいポイントです。

IBM WebSphere Application Serverのサポートライフサイクルの特徴

Enhanced Support Lifecycle Policyとフィックスパックの5年ルール

IBM公式サポートページによると、WebSphere Application Server traditional（V8.5.x・V9.0.x）は「Enhanced IBM Software Support Lifecycle Policy」に準拠して運用されています^*2。同ページは、一般提供から5年を超えるフィックスパックについて「significant challenges for support（サポート対応上の大きな課題）」が生じると明記しており^*2、インターフィックス（緊急修正）は一般提供から2年以内のフィックスパックに限り、IBMの裁量で提供されると案内されています^*2。

つまりWebSphere Application Serverには、製品全体の終了日とは別に、フィックスパックの世代交代というもう一つのサポート制約が存在します。最新のフィックスパックへ追随できていない環境は、製品全体のサポートが継続していても、実質的な保守対応力が低下している可能性があるでしょう。

主要バージョンの現状：明確な終了日がない一方、地域限定の延長は終了済み

IBM公式のライフサイクル照会ページでは、WebSphere Application Server Network Deployment 9.0.x（一般提供開始：2016年6月24日）について、ライフサイクルポリシー区分は「Other」とされ、一律のサポート終了日は明示されていません^*3。同ページの備考欄には、SolarisおよびHP-UX向けの拡張サポートがバージョン9.0.5・8.5.5に限り2022年10月1日から2025年9月30日まで提供されたと記載されており^*3、この期間はすでに終了しています。稼働環境のOS・バージョンによってサポート条件が異なるため、自社の環境については公式情報で個別に確認することが欠かせません。

なぜ今、移行を検討すべきか

WebLogic・WebSphereともに、旧バージョンほどサポートの実効性が下がっていく構造は共通しています。Oracle側はPremier Support終了という具体的な期限が2026年12月に迫っており^*1、IBM側は明確な終了日がなくても、フィックスパックの5年ルールという形で実質的な制約を抱えています^*2。いずれの場合も、期限が来てから対応を始めるのではなく、期限や制約を前提にあらかじめ計画を立てる姿勢が求められます。

あわせて、ライセンス費用も移行検討の材料になります。商用アプリケーションサーバーには、プロセッサ数やエディションに応じたライセンス費用と、それに連動する保守費用が継続的に発生する体系が一般的です。オープンソース系やクラウドサービスへ移行すれば、こうしたライセンス費用の構造自体を見直す余地が生まれます。ただし移行には別の技術的リスクや構築コストが伴うため、費用比較だけで判断できるものではありません。

移行先の選択肢①：Tomcat・WildFlyなどオープンソース系

Apache Tomcat公式サイトは、TomcatについてJakarta EE（旧Java EE）技術の一部を実装したオープンソースソフトウェアであると説明しています^*4。裏を返せば、TomcatはServlet・JSPを中心としたWebコンテナであり、WebLogic・WebSphereが備えるトランザクション管理（JTA）やメッセージング（JMS）、EJBといったJava EE/Jakarta EEのフル仕様を代替するものではありません。移行先としてTomcatを選ぶ場合は、アプリケーション側がどの仕様に依存しているかの棚卸しが前提になるでしょう。

一方、WildFly公式サイトは、WildFlyを「モジュール式で軽量なアプリケーションサーバー」と位置づけ、最新版がJakarta EEおよびMicroProfileの仕様に対応していると案内しています^*5。WildFlyはRed Hatが主導するオープンソースプロジェクトであり、EJBやJTAを含むフル仕様のJakarta EEに対応する点で、WebLogic・WebSphereからの移行先候補として挙がりやすい製品です。ソフトウェア自体にライセンス費用は発生しませんが、商用サポートを受けるにはRed Hat JBoss EAP等の商用ディストリビューションを選ぶという判断も出てきます。

移行先の選択肢②：クラウド（コンテナ・マネージドサービス）

もう一つの移行先候補が、コンテナ化やマネージドサービスを活用したクラウド環境です。アプリケーションをコンテナイメージへパッケージ化し、コンテナオーケストレーション基盤で運用する構成であれば、WildFlyやTomcatをコンテナ上で稼働させながら、スケーリングや可用性確保の仕組みをクラウド側の機能に委ねられます。

各クラウドベンダーはコンテナ実行環境やマネージドKubernetesサービスを提供していますが、対応するJavaランタイムやミドルウェアの仕様はサービスごとに異なります。自社アプリケーションが依存する独自機能や設定内容と、移行先サービスの対応範囲を突き合わせる作業には、オンプレミスの内製構築とは異なる専門知識が求められます。

移行の技術的リスク：Java EE/Jakarta EEの差異と独自機能依存

javaxからjakartaへの名前空間変更

Java EEは、その後Eclipse Foundationへ移管され、Jakarta EEという名称で開発が続けられています^*6。Eclipse Foundationが公開するJakarta EEの公式FAQには「javax.*名前空間はどうなったか」という項目が設けられており^*6、パッケージの名前空間がjavax.*からjakarta.*へ変更された経緯が周知されています。対応バージョンによってはソースコードの修正やビルド設定の見直しが避けて通れない論点です。

ベンダー独自機能への依存という隠れたリスク

WebLogic・WebSphereには、それぞれ固有の管理コンソール機能や拡張API、クラスタリング方式が存在します。長期間運用してきたシステムほど、こうしたベンダー独自機能に暗黙のうちに依存しているコードが積み重なっている場合があるでしょう。移行前の設計フェーズでこの依存関係を洗い出さないまま作業を進めると、移行後の本番環境で想定外の不具合が発生する事態につながりかねません。仕様書や設定情報の棚卸しは、移行計画の初期段階に組み込むべき工程です。

内製移行と外注委託のコスト構造比較

WebLogic・WebSphereからの移行は、内製で進める場合と外部パートナーへ委託する場合とで、費用構造や必要スキルの重心が異なります。以下の表に主な違いを整理しました。

まとめ：WebLogic/WebSphere移行を判断する3つの軸

本稿ではOracle WebLogic ServerとIBM WebSphere Application Serverについて、サポートライフサイクルと移行先の選択肢を公式情報に基づいて整理しました。要点は次の3つに集約できるでしょう。第一に、Oracle Fusion Middleware 12c（WebLogic Server含む）はPremier Supportが2026年12月に終了する予定であり^*1、WebSphere Application Serverは明確な終了日がなくてもフィックスパックの5年ルールという実質的な制約を抱えています^*2。第二に、移行先にはTomcat・WildFlyといったオープンソース系とクラウド（コンテナ・マネージドサービス）があり、いずれもJava EE/Jakarta EEの名前空間変更や独自機能依存というリスクへの対応が求められます^*4*5*6。第三に、ライセンス費用の見直しと技術的リスクの両方を踏まえると、内製と外注のどちらで進めるかは費用構造・専門知識・運用体制という3つの軸から判断する必要があります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Oracle「Oracle Lifetime Support Policy: Oracle Fusion Middleware」（https://www.oracle.com/us/assets/lifetime-support-middleware-069163.pdf）
2. *2　出典：IBM公式サポート「Lifecycle Policy: WebSphere Application Server traditional」（https://www.ibm.com/support/pages/lifecycle-policy-websphere-application-server-traditional）
3. *3　出典：IBM公式「Product lifecycle – Product details」（WebSphere Application Server Network Deployment 9.0.x）（https://www.ibm.com/support/pages/lifecycle/details/?q45=WebSphere+application+server）
4. *4　出典：Apache Tomcat公式サイト「Which Version Do I Want?」（https://tomcat.apache.org/whichversion.html）
5. *5　出典：WildFly公式サイト（https://www.wildfly.org/）
6. *6　出典：Jakarta EE公式サイト（Eclipse Foundation）「Frequently Asked Questions」（https://jakarta.ee/about/faq/）

Tweet