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

WebLogicのシステムは、業務要件、既存のJava資産、運用体制に合わせて構成を選ぶことで、業務に必要な可用性と整合性を実現できます。

構成の種類、開発の進め方、費用相場、移行時の注意点を順に取り上げます。各テーマの詳細は、次の関連記事で確認できます。

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

WebLogicのシステムの概要

画面、業務ロジック、データ管理を層ごとに整理します。

WebLogicを導入しただけでは、業務システムは完成しません。

WebLogicはアプリの実行、DB接続、トランザクション、メッセージング、認証を担う中間層で、業務ルールを定めるアプリやデータを保存するDBと組み合わせて使います。

WebLogicが担う役割

採用を判断するときは、WebLogicが担う実行基盤の機能と、業務要件を突き合わせて確認します。

アプリ実行：Java／Jakarta EEアプリを動かします。業務ルールはアプリ側、データはデータベース側に分けて管理します。
要求処理：ブラウザ、スマートフォン、他システムからの要求を受けて、Java業務処理を実行する機能です。
データ返却：必要なデータをデータベースから取得し、結果を返します。
実行機能：JDBCは接続管理、JTAは分散トランザクション、JMSは非同期処理を担います。
採用判断：同時実行数、復旧時間、処理整合性、既存Java資産が判断の基準です。

RESTやWebサービスを使えば外部と連携でき、認証・認可、SSL/TLS、ログ、監視も管理できます。

注文、在庫、請求、決済では、複数の処理の整合性を保つ仕組みが欠かせません。そのため、製品の知名度だけで採否を決めないようにします。

基本的な3層構成

3層構成では、各層の役割と通信経路を分けて設計します。

プレゼンテーション層：利用者の画面を担当する層です。
アプリケーション層：業務ロジックを実行する層です。
データ層：データを管理する層です。
通信経路：ファイアウォール、ロードバランサー、Webサーバーを経てWebLogicに届き、DBやAPI、ファイルサーバーへつながります。

層を分けると、画面とデータ管理の変更を切り分けやすくなります。一方で、ネットワーク遅延や接続プールなどの設定は増えるため、設計書に通信経路、ポート、データの流れ、障害時の切り替え先を図と一覧で残しておきます。

ドメイン、サーバー、クラスタの関係

ドメインとクラスタを設計するときは、管理と処理の役割、可用性の確認範囲を押さえます。

ドメイン：WebLogicの管理単位で、Administration Serverが設定を管理します。
Managed Server：アプリケーションを処理する役割です。
クラスタ：Managed Serverを複数台にすると、負荷分散、障害切替、ローリング更新を行えます。
可用性の検証：セッション共有、DB冗長化、ロードバランサーのヘルスチェック、ログ集約、バックアップ、切り戻しを動作確認します。

確認を終えて初めて、クラスタは業務上の可用性として機能します。サーバーの台数を増やすだけで、可用性が上がるとは限りません。

Administration Serverの管理ポートは、利用者向けネットワークへ公開しない設計が基本です。

WebLogicのシステムの種類

WebLogicのシステムは、設置場所、可用性、アプリケーションの作り方によって、複数の方式に分かれます。

新規開発ではクラウドを選びやすい一方、既存システムでは現行資産と運用負担のバランスを見ます。

オンプレミス型

オンプレミス型では、既存環境や運用要件に合わせて次の点を確認します。

設置場所：自社やデータセンターのサーバーにWebLogicを構築します。
既存環境：ネットワーク、認証基盤、専用機器、社内規程を活用しやすい方式です。
適用業務：低遅延や閉域網を重視する業務に向き、構成を細かく制御できます。
自社の運用責任：サーバー更新、予備機、電源・ネットワーク冗長化、OS・JDKパッチ、監視要員を自社で担います。

総保有コストは、ライセンス費だけでは見えません。そのため、保守や災害対策、夜間対応まで含めて、5年程度の費用と体制を試算します。バックアップ設備も、同じ試算に含めます。

クラウド型とBYOL／従量課金

クラウドでは、ライセンス方式と基盤費用を分けて見積もります。

基盤：仮想サーバー、ネットワーク、ロードバランサー、ストレージを組み合わせます。
BYOL：既存ライセンスを再利用し、主にコンピュート費を支払います。既存ライセンスとサポート契約が必要です。
従量課金：ライセンス相当額もOCPU時間に応じて課金されます。初期購入を抑えやすい一方、常時稼働や台数増加で月額が膨らみます。

費用の内訳には、ライセンスやコンピュートのほか、ストレージやバックアップ、通信、監視が含まれます。

従量課金型はOCPU時間に基づくライセンス料金とコンピュート料金を支払います（出典: WebLogic Server for OCI公式ドキュメント、2026年確認）。

Kubernetes上で運用する型

Kubernetes型は、コンテナ運用の自動化や構成管理を活用したい場合に検討します。ただし、採用だけで運用が簡単になるわけではありません。

運用自動化：デプロイ、スケール、宣言的な構成管理を活用できます。
Operator：WebLogic Kubernetes Operatorでドメインやクラスタを運用し、イメージの定期更新も設計できます。
管理対象：永続ストレージ、Pod配置、ノード障害、秘密情報、ロードバランサー、ログ、監視、ライセンス対象ノードを洗い出します。

既存システムをそのまま移す場合は、仮想マシン型のほうが短期間で安定することもあります。

採否は、自動化の効果が費用と複雑さを上回るかどうかで決めます。

ポイント

方式は、既存環境の制約と自社で担える運用の範囲で決まります。新規開発ならクラウドを、既存システムの移行なら仮想マシン型を先に比べるのが目安です。

WebLogicのシステムが向いているケースと注意が必要なケース

採否は、業務要件と既存資産を基準に判断します。可用性やトランザクションの整合性が必要な企業システムに適しますが、すべてのWebアプリに最適とは限りません。

採用に向いているケース

次のような要件があると、WebLogicの強みを活かしやすくなります。

処理の整合性：複数の業務処理を一つのトランザクションで扱います。
可用性：複数台構成で障害に備えます。
既存資産：Java EEアプリケーションを継続して使います。

基幹業務や金融関連など、停止やデータ不整合の影響が大きいシステムでは、運用機能と既存スキルも評価します。受発注や在庫、会員、請求などの業務も、この条件に当てはまります。

社内にWebLogicやJavaの知識があり、パッチ適用や監視、障害対応、証明書更新を続けられる場合にも向きます。

静的サイトや小規模APIで冗長化や高度な取引処理が不要なら、軽量な基盤で費用と運用負担を抑えられる可能性があります。

他の実行基盤と比較する視点

実行基盤は、アプリの規模や必要機能、移行方針に合わせて比べます。

Tomcat：Webアプリを軽量に動かしたい場合に選ばれます。
Spring Boot：アプリと実行環境をまとめやすく、サービス単位の開発や小さなチームに向く場合があります。
WebLogic：ドメイン、クラスタ、JMS、JTA、認証、監視、Java EE資産との互換性を企業基盤として扱えます。
比較条件：必要機能、担当者のスキル、サポート、既存ライセンス、5年間の総費用、移行リスクをそろえます。

新規アプリは別の方式で作り、既存のWebLogicとAPIやメッセージングでつなぐ段階移行も可能です。

すべてをWebLogicに載せ続けることが、唯一の正解とは限りません。

ポイント

採否は、停止やデータ不整合の影響と、既存のJava資産を生かせるかで見ます。静的サイトや小規模APIのように冗長化が要らない場合は、軽量な基盤も比べます。

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

代表処理の検証を本開発より前に置いた流れです。

先に製品を決めて業務を当てはめると、後工程で追加費用が出やすくなります。まず、現行資産と業務要件を一覧にします。そのうえで、非機能要件、移行対象、運用体制を洗い出します。

代表的な処理を小さく検証してから本開発に進むと、安全に進められます。工程ごとに確認する内容を、順に見ていきます。

1. 現行棚卸しと要件定義

棚卸しと要件定義では、移行対象と業務上の条件を次のとおり洗い出します。

現行環境：WebLogicの版、JDK、OS、DB、ドメイン数、Managed Server数、デプロイ方式を記録します。
連携・運用：JDBC、JMS、認証、外部連携、バッチ、帳票、監視、障害履歴を確認します。
アプリ依存：ライブラリ、javax.*・jakarta.*、古いJAX-RPC、SAML 1.1などを調べます。
業務条件：同時接続数、毎秒の処理件数、応答時間、稼働率、RTO、RPOを数値化します。

データの保持期間や監査ログ、バックアップ、許容停止時間も定めます。さらに、例外処理や表記揺れ、マスタデータの責任者も整理しておきます。

2. PoCと方式設計

PoCと方式設計では、代表処理の検証と基盤候補の比較を行います。

PoC範囲：登録・更新・検索、取引、JMS、バッチ、帳票、SSO、ファイル連携、タイムアウト、異常系を試します。
適合性：画面が完成しているかよりも、WebLogicの版、JDK、DB、クラウド、ネットワークが本番要件を満たすかを確かめます。
方式比較：オンプレミス、クラウド、Kubernetesを性能、可用性、セキュリティ、費用、責任分界、運用スキルで比べます。

クラウドでは、ライセンスを持ち込むか従量課金にするかを決めます。さらに、障害時に自社とサービス提供側が担う範囲を、設計書と契約書の両方に記しておきます。

3. 設計・実装・テスト

設計・実装・テストでは、基盤と業務アプリの両面を定義して検証します。

基盤設計：ドメイン、サーバー、クラスタ、セッション、データソース、JMS、認証、TLS、ログ、バックアップ、監視、デプロイを定めます。
アプリ設計：業務処理、データモデル、API、エラー、権限、再実行ルールを定義します。
テスト：単体、結合、総合、性能、障害、セキュリティ、移行リハーサルの各段階。
性能・異常系：応答時間、CPU、メモリ、GC、接続プール、DBロック、キュー滞留を確認します。

業務要件は、ミドルウェアの設定だけでは解決しきれません。試験では、クラスタ片系停止やネットワーク断、DB接続断のほか、証明書期限切れも扱います。

4. 移行・リリース・運用定着

移行、切り替え、稼働後の運用は、責任者と手順、納品物をそろえて進めます。

移行計画：環境更新、アプリ修正、データ変換、並行稼働、切り替え、ロールバックを分け、初回リハーサルで時間を測ります。
切り替え準備：2回目以降にデータ件数や停止時間の差を縮め、責任者、連絡網、利用者告知、失敗時の戻し方を決めます。
運用定着：四半期ごとのCPU・JDK更新、証明書、アカウント、脆弱性、復元、障害訓練を作業予定に登録します。
納品物：設計書、設定、ソース、テスト結果、IaC、運用手順、問い合わせ窓口を整えておき、知識の集中を防ぎます。

ポイント

先に製品を決めず、現行資産と業務要件を一覧にしてから方式を比べます。代表処理の検証を本開発の前に置くと、後工程で追加費用が出にくくなります。

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

開発費は、ライセンス費だけでは決まりません。アプリや基盤、クラウドの費用を中心に、DBや移行、テスト、監視、保守も分けて考えます。

ここで示すのは、一般的な業務システムの相場と、WebLogic固有の構築要素を合わせた目安です。契約条件や規模によって変わる、編集部の推定値です。

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

規模別の初期費用と期間

規模別の初期費用と期間の目安は、次のとおりです。契約条件や構成によって変わります。

PoC・開発環境：既存ライセンスや評価環境を使う前提で50万〜300万円、2〜8週間程度です。
小規模：画面・API、DB連携、Managed Server、認証、基本監視、試験、初期移行を含み、1,000万〜3,000万円、4〜9か月程度です。
中規模：クラスタ、ロードバランサー、SSO、複数連携、性能・障害試験、段階移行を含み、3,000万〜1.5億円、9〜18か月程度です。
大規模：複数拠点、基幹連携、大量データ、災害対策、組織変更を含み、1.5億〜数億円以上、18か月から数年かかる場合があります。

12c・Java 8の単一アプリ更新は、互換性調査と修正で500万〜3,000万円、3〜9か月程度が目安です。複数アプリの更新や、javax.*からjakarta.*への変更があると、修正範囲が広がります。さらに、古いJMS、JAX-RPC、独自ライブラリの修正も重なる場合、費用は3,000万〜1.5億円程度まで増える可能性があります。

ライセンス費の見方

公開価格は参考値として扱い、契約条件や対象環境を見積書で確認します。

見積条件：Processor単位と契約条件をそろえて比較します。
費用計上：初期費用と年額サポートを分けて予算化します。
為替前提：外貨価格を円換算する条件を明確にします。

米国向けの公式価格表には、Processorライセンスの参考価格が掲載されています。Standard Editionは10,000ドル、Enterprise Editionは25,000ドル、Suiteは45,000ドルです（出典: ミドルウェア製品の公式価格表、2025年3月版）。

年額のSoftware Update License & Supportは、Standard Editionが2,200ドルです。Enterprise Editionは5,500ドル、Suiteは9,900ドルです（出典: ミドルウェア製品の公式価格表、2025年3月版）。

1ドル150円で換算した初期費は約150万円、375万円、675万円で、年間サポートは約33万円、82.5万円、148.5万円です。

この価格は国内の確定見積ではなく、リスト価格です。Processor定義や係数、契約割引、税、為替、サポート条件は含まれていません。

実額は、Processor数や待機系、クラウド課金方式、DBや管理製品の有無で変わります。見積書で、ライセンス単位と対象環境を確認します。

人件費とランニングコスト

開発費の配分と運用費の内訳を分けて考えると、継続費用を比較しやすくなります。

要件定義・設計：要件定義10〜15%、設計25〜35%が配分目安です。
実装・試験：実装・単体試験30〜40%、結合・総合試験15〜20%が目安です。
移行・教育：5〜10%が目安ですが、移行が重い案件では移行・試験の割合が高まります。
運用・保守：継続的に発生する費用も見積もりに含めます。

ランニングコストには、WebLogicのサポートやクラウドのコンピュートに加えて、ストレージや通信の費用が含まれます。バックアップ、監視、ログ保管も、継続して発生する費用です。

運用では、証明書の更新や脆弱性診断、パッチ適用が続きます。障害対応や軽微な改修も、費用に含めておきます。

工程配分は業務システムの一般的な目安です（出典: 業務システム開発の一般的な工程配分、リサーチノート整理、2026年）。

保守費は初期開発費の年10〜20%程度を起点にできます。24時間365日対応や復旧目標の設定、予防保守、DR訓練などを含めると、保守費は上振れします。

ポイント

費用は、ライセンス費だけでなく、基盤、移行、テスト、保守まで含めた総額で比べます。見積もりは、ライセンス単位、対象環境、サポート条件をそろえて判断します。

12c・Java 8から15cへ移行するときのポイント

代表アプリで互換性を確かめてから全体へ広げます。

更新では、サーバーだけでなくJavaやJakarta EE、ライブラリも検証します。加えて、認証と連携方式も確かめます。

12.2.1.4とJava 8から、15.1.1とJava 17または21へ移す場合、互換性診断を先に行うと失敗回避につながります。

互換性診断の確認項目

互換性診断では、アプリ、環境設定、運用資産、移行先の対応範囲を確認します。

アプリ依存：Java版、コンパイル設定、ライブラリ、クラスローダー、JDBC、JMS、EJB、Webサービスを洗い出します。
連携・運用：認証、ファイル連携、帳票、バッチ、監視、ドメイン設定、デプロイ記録、スクリプトを確認します。
管理情報：証明書と秘密情報の保管方法も調べます。ソースコードだけでは問題を見落とすおそれがあります。

15.1.1は、Jakarta EE 9.1、Java SE 17・21、Spring Framework 6.x、Hibernate 6.6.xに対応します（出典: WebLogic Server 15.1.1公式発表、2025年）。

特に、javax.*からjakarta.*への変更や古いJAX-RPC、SAML 1.1、外部ライブラリの互換性は、個別に確認が必要です。

段階移行と自動変換の使い分け

一括移行と自動変換は、リスクとアプリ間の依存に応じて使い分けます。

段階移行：環境複製、代表アプリ移行、互換性修正、全体展開の順に進めます。
変換後の確認：ツールで変換した後、認証、例外処理、取引、文字コード、性能を人が確認します。
機能の切り出し：依存が少ない機能から新環境へ移し、既存WebLogicは安定稼働させたままにします。

自動変換は工数を減らす補助で、テストを省く手段ではありません。二重登録を防ぐため、データの正本と再送ルールを決めます。

リスクが高いアプリは、切り出しを段階的に進める方法もあります。

セキュリティとパッチ運用

セキュリティ運用では、管理経路、アプリの脆弱性、製品パッチを確認します。

管理経路：管理画面やポートを公開網から分離し、多要素認証、最小権限、TLS、キーストア、秘密情報管理を使います。
脆弱性対策：WAF、ロードバランサー、監査ログ、バックアップ、スキャンを組み合わせ、SQLインジェクション、XSS、CSRF、認可漏れも検査します。
パッチ・TLS：製品更新とTLS設定を定期的に確認します。

2025年10月の公式CPUには、HTTP/2の脆弱性が掲載されています。対象はWebLogic Server 14.1.1と14.1.2です（出典: WebLogic Serverの公式Critical Patch Update Advisory、2025年10月）。

CPUは、定期的に適用する必要があります。公開WebのTLSは、IPAの2025年4月版TLS暗号設定ガイドラインを参考にし、接続先との互換性も確認します。

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

WebLogicを扱える会社を選ぶ際は、インストールの経験があるかだけで判断しないことが大切です。

業務要件やJavaアプリ、DB、クラウドから、移行や性能試験、稼働後保守まで説明できるかを確認します。

実績と技術範囲の確認

開発会社の実績は、製品導入件数だけでなく担当領域や支援体制まで確認します。

類似実績：似た業務、ピーク負荷、DB、認証方式、WebLogic世代からの移行を尋ねます。
技術範囲：基盤、移行、連携、試験の実務経験を確認します。
担当体制：資料の担当範囲、期間、成果物、保守体制を見ます。別会社が保守する場合は、責任分界、一次窓口、共同対応を契約で定めます。

確認対象は、クラスタやDRの設計、稼働後の障害対応です。加えて、WebLogic 15.1.1や14.1.xへの対応も見ます。Java・Jakarta EE移行やOCI以外のIaaS、Kubernetes、DB連携、性能試験・障害試験の経験も対象です。

見積書と成果物の比較

見積条件と納品物をそろえると、提案の範囲や将来の運用負担を比較できます。

費目：要件定義、設計、実装、テスト、移行、教育、ライセンス、クラウド、監視、保守に分けます。
前提条件：サーバー・環境・アプリ数、データ件数、試験回数、稼働時間、納品物を明記し、変更管理も確認します。
成果物：設計書、構成図、設定、ソース、試験結果、移行・ロールバック手順、監視・運用手順、教育資料を確認します。

再構築できるコードやIaCが残らない契約は、担当者変更や災害復旧の負担になります。

初回相談で聞くべき質問

初回相談では、調査方法、検証方法、運用体制を具体的に確認します。

調査・互換性：現行版とJDKの調べ方、互換性リスクを見つける時期を尋ねます。
試験・障害対応：性能目標の証明方法、障害時の切り分け担当、パッチ時の停止時間を抑える方法を聞きます。
回答内容：調査方法、成果物、判断基準、体制が具体的かを確認します。
相談準備：アプリ棚卸し、ピーク負荷、SLA、移行データ、希望日、保守時間帯をそろえます。
比較評価：価格だけでなく、要件定義の精度、移行の再現性、運用体制、契約後の変更管理を評価します。

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

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

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

ポイント

開発会社は、インストールの経験だけでなく、移行や性能試験、稼働後の保守まで説明できるかで選びます。見積書は、費目と前提条件、成果物をそろえて比べます。

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

製品機能、移行、費用、クラウドの選択は、初期検討で判断を誤りやすいテーマです。よく寄せられる疑問に答えます。

WebLogicは業務システムそのものですか？

いいえ、WebLogicは業務システムを動かすアプリケーションサーバーです。業務アプリやDBと組み合わせて使います。ネットワーク、認証、監視、バックアップとあわせて構成します。

古いWebLogicとJava 8はすぐに廃棄すべきですか？

まずはサポート状況や脆弱性、アプリ互換性、事業停止リスクを調べ、計画を立てます。

短期的には、パッチの適用や管理ポートの分離でリスクを抑えます。

中期には、代表アプリの互換性診断と移行リハーサルを行ったうえで、段階的に更新する方法が現実的です。

WebLogicはクラウドへ移行できますか？

移行はできますが、仮想マシンへコピーするだけでは不十分です。BYOLと従量課金の別に加え、ネットワーク、DB、バックアップ、性能、監視も整理します。

障害時の責任分界も決めておきます。現行の機能だけでなく、運用手順をクラウドでも再現できるかを確かめます。

WebLogicのシステム開発費用はどのように抑えられますか？

現行資産と非機能要件を棚卸しして、PoCで互換性と性能の不確実性を減らします。費用は、ライセンスやクラウド、開発、移行、テスト、保守などに分けて見積もります。

不要な冗長化や過剰なカスタマイズは避けます。安い提案を選ぶより、追加費用が出る条件を事前に明確にしておくほうが、予算を管理しやすくなります。

まとめ

WebLogicはJava／Jakarta EEアプリケーションを支える中間層です。

業務アプリやDB、クラスタを一体で設計し、認証や監視、移行、保守まで含めて、可用性と整合性を実現します。

検討時に押さえるポイント

まず、現行のWebLogicやJDK、アプリ、連携、データ、運用を棚卸しします。そのうえで、ピーク負荷やRTO・RPO、応答時間、セキュリティ、希望切り替え日も数値にします。

PoCで互換性と性能を確かめたうえで、ライセンスや基盤、開発、移行、テスト、保守に費用を分けます。さらに、方式ごとに5年の総費用を比べます。

次に準備する資料

相談前には、現行構成図やアプリ一覧、WebLogicとJDKの版を準備します。あわせて、外部連携一覧、ピーク負荷、SLA、移行データも用意しておきます。

希望の切り替え日と保守時間帯も提示します。調査、成果物、体制、変更管理、障害時の責任分界を同じ条件で比べると、追加費用と移行リスクを抑えやすくなります。

▼開発を相談する前に読みたい無料ホワイトペーパー
・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を創業。