Oracle HTTP Server／WebLogic Proxy Plug-in：使用コンポーネントとパッチ適用状況の確認表

『WebLogicは更新済み』だけでは、前段のプラグインまで確認できません。 サービスの入口から順に、どのホストのどのコンポーネントが動いているかを記録しましょう。本稿は管理者が確認結果を引き継ぐためのチェックリストです。特定のパッチを一律に適用する手順ではありません。

2026年9月7日にOracleの公開資料を確認しました。OPatchの例はFusion Middleware 12.2.1.4の資料を対象とします。14cなど別リリースでは、そのリリースの手順と取得したパッチのREADMEを照合してください。実環境でのコマンド実行・パッチ適用は未検証です。

1. リクエストの通り道を棚卸しする

• ▸入口のWebサーバ：Oracle HTTP Server（OHS）、Apache HTTP Server、IISのどれか。複数あればホストごとに記録する。
• ▸中継コンポーネント：OHSに含まれるプラグインか、別途導入したWebLogic Server Proxy Plug-inか。Webサーバの設定で参照するファイルと導入記録を確認する。
• ▸転送先：WebLogic Serverのホスト・ドメイン・担当者を記録する。前段の管理担当者と同一とは限らない。
• ▸確認対象：本番だけでなく待機系、別ノード、旧環境も記録し、利用中・停止中・不明を分ける。停止中の環境は再稼働前の確認担当を決める。

Oracleの14.1.2の概要資料では、OHS向けはOHS配布に含まれ、Apache向けはZIPで提供されます。Apache向けの設定例にはLoadModuleとmod_wl_24.soが登場します。展開したフォルダがあるだけでなく、設定がどのファイルを参照しているかを確認します。IISにはApacheの設定名を当てはめず、導入した版の資料と構成記録を使ってください。

2. Oracle Homeごとに適用履歴を残す

OPatchで管理されるOracle Homeでは、対象HomeのOPatchからversionとlsinventoryを実行します。次の例はLinux／UNIXのシェル用です。ORACLE_HOMEが対象の絶対パスを指していることを先に確認してください。これらはパッチの適用コマンドではありませんが、ログファイルは作成されます。

# Linux / UNIX: use the Oracle Home you intend to inspect
"$ORACLE_HOME/OPatch/opatch" version
"$ORACLE_HOME/OPatch/opatch" lsinventory

Windowsでは対象HomeのOPatchディレクトリにあるopatch.batを使用します。例はコマンドプロンプト用で、PowerShell構文ではありません。出力のOracle Homeが意図した場所かを確認してから結果を採用します。

REM Windows Command Prompt: ORACLE_HOME must identify the target home
"%ORACLE_HOME%\OPatch\opatch.bat" version
"%ORACLE_HOME%\OPatch\opatch.bat" lsinventory

• ✓出力にあるOracle Home、OPatchの版、実行日時、ログ保存先を記録した。
• ✓対象製品、適用パッチID、適用日時を控え、パッチのREADMEと対応付けた。
• ✓別のHomeや別ノードを同じ結果で済ませていない。
• ✓コマンドが失敗した場合は『未確認』と記録した。エラーを『パッチなし』や『対象製品なし』と読み替えていない。

ZIP展開した独立プラグインを、別のOracle Homeのlsinventoryだけで確認済みにしないでください。配布物の識別情報、導入・置換記録、設定の参照先をそろえます。証跡がなく版を特定できない場合は、推測で埋めず保守担当へ確認します。

3. 修正要件と照合し、更新後も確認する

製品名と基本バージョンだけで適用済みと判断せず、該当するOracleのアドバイザリとMy Oracle Supportのパッチ資料に、記録したパッチIDを対応付けます。後続パッチで修正を取り込んだと判断する場合も、対象版と包含関係の根拠を残します。My Oracle Supportの認証が必要な個別READMEやパッチIDは本稿では確認していません。

• ✓作業前：対象Home・プラグイン・ノード、READMEの要件、停止範囲、バックアップと復旧手順を担当者間で確認する。
• ✓作業後：適用ログと履歴を保存し、READMEが求める再起動・追加手順の完了を記録する。
• ✓設定確認：更新したプラグインを設定が参照しているか、旧ファイルや別パスを参照していないか確認する。
• ✓サービス確認：担当者が決めた疎通、認証、主要画面、転送先への接続を確認し、時刻と結果を記録する。
• ✓残課題：エラーや不審なログは別途調査する。ページが表示できたことだけで、修正完了や侵害なしを証明しない。

4. 社内担当者へ渡す確認表

以下は編集部が用意した記録テンプレートです。コンポーネント・ノードごとにコピーし、未確認欄には担当者と確認期限を入れてください。ログや構成には内部情報が含まれるため、社内の指定された保管先で共有します。

確認日時／確認者：
サービス名／環境（本番・待機・検証）：
ホスト／ノード：
入口Webサーバと版：
プラグインの種類・版／配布物の識別情報：
Oracle Home またはプラグイン配置先：
設定が参照するプラグインのパス：
WebLogic転送先／担当部署：
参照アドバイザリ／パッチREADME：
OPatchの版／適用パッチID／適用日時：
後続パッチの包含関係の根拠（該当時）：
作業前後のログ・履歴の保管先：
停止・再起動・追加手順の実施結果：
疎通／認証／主要画面の確認結果：
状態（確認済み・対応待ち・未確認・対象外）：
判定の根拠：
残課題／担当者／期限：

『対象外』にも根拠が必要です。資料が不足している場合は『未確認』にします。運用担当が証跡を集め、セキュリティ担当が修正要件との対応を確認できる状態を、このチェックリストの完了条件にしてください。