Oracle DatabaseとE-Business Suite（オラクルの基幹業務パッケージ）を本番で動かし、パッチ適用をSIerとの保守契約で年数回の作業枠に収めている。数千人規模の日本企業では珍しくない体制だ。そのインフラ担当と情報システム部門にとって、2026年8月の更新は作業内容よりも前提の話になる。
Oracleは2026年8月18日、943件のセキュリティパッチを含むCritical Security Patch Update（CSPU）を公開した[1]。Oracleの説明では、CSPUは「targeted, high-priority security fixes in a smaller, more focused format, making them easier to apply with minimal disruption」を提供する形式とされる[1]。四半期ごとのCritical Patch Update（CPU）を置き換えるものではない。
Oracleは両者の関係を「Critical Security Patch Updates complement Oracle’s existing quarterly cumulative Critical Patch Updates (CPUs)」と記している[1]。補完が意味するのは、四半期に加えて毎月が増えるという一点だ。リリース日は毎月第3火曜日に固定されている。
年4回のCPUだけを想定して組んだ年間保守計画は、評価の発生頻度が四半期から毎月に変わる前提で組み直すことになる。本記事では943件の内訳が示す負荷の偏り、四半期前提の計画が破綻する箇所、そして固定日という性質を保守契約に織り込む方法を順に整理する。
予備知識
- CPU（Critical Patch Update）: Oracleが四半期ごとに出す累積型のセキュリティ修正。中央処理装置の略ではないので、社内文書では毎回展開して書くほうが誤読が少ない。
- CSPU（Critical Security Patch Update）: 高優先度の修正だけを絞り込んで配る形式。毎月第3火曜日にリリースされる。
- CVSS: 脆弱性の深刻度を0.0から10.0の数値で表す共通指標。10.0が最大。
- Premier Support / Extended Support: OracleのLifetime Support Policyにおけるサポートフェーズ。この2つのいずれかにある製品にのみセキュリティパッチが提供される。
パッチ適用の影響範囲を判断する前提となるOracle Databaseの構成と管理作業を体系的に押さえられる
Oracle CSPU 943件の内訳は、パッチ負荷がアプリケーション層に偏っていることを示す
943件の内訳を製品ファミリー別に見ると、負荷はデータベース本体ではなくその上のアプリケーション層に集中している。
最も多いのはOracle Fusion MiddlewareとOracle Hyperion（EPM）で、いずれも262件で並ぶ[1]。次いでOracle E-Business Suiteの120件だ。この3ファミリーだけで644件、全体の約68%にあたる[1]。一方でOracle Database Productsは17件にとどまり、そのうちDatabase Server本体は6件である[1]。
この偏りは作業の重さに直結する。DBAだけで完結する作業は少なく、アプリケーション基盤とパッケージの担当者、そして業務部門の回帰テストが必要になるからだ。
今回はCVSS 10.0が3件ある[1]。CVE-2026-61241はOracle Internet DirectoryのOID LDAP Serverが対象でLDAPプロトコル経由、残る2件はHyperion Data Relationship ManagementとHyperion Financial Managementが対象だ[1]。ディレクトリサービスもEPM基盤も複数の業務システムが参照する共通基盤にあたるため、影響は1製品の中で閉じない。
つまり943という総数よりも、自社が使っている製品ファミリーがどこに位置するかのほうが判断材料になる。Fusion MiddlewareとE-Business Suiteを持つ企業と、Database Productsだけの企業では、同じCSPUでも作業量が一桁違う。
月次のリリースを定期作業と臨時作業に切り分ける変更管理の考え方を整理できる
四半期CPU前提の年間保守計画が月次CSPUで崩れる構造
崩れるのは適用作業そのものではなく、評価と承認のサイクルが年4回で足りるという前提のほうだ。
Oracleが公開している今後のリリース予定を並べると、この4か月で4回の判断機会が発生する。
| 日付 | 種別 | 性格 |
|---|---|---|
| 2026年9月15日 | CSPU | 高優先度修正の絞り込み |
| 2026年10月20日 | CPU | 四半期の累積更新 |
| 2026年11月17日 | CSPU | 高優先度修正の絞り込み |
| 2026年12月15日 | CSPU | 高優先度修正の絞り込み |
従来のCPU前提であれば、この期間に対応するのは10月20日の1回だけだった。残る3回は計画に存在しない。
問題は費用ではなく人の時間に出る。943件のうち自社に関係する範囲を切り出す作業は、パッチを当てない月にも発生するからだ。何もしないという結論を出すためにも、毎月の読み込みは避けられない。
もう一つの前提崩れはサポートフェーズにある。パッチが提供されるのはPremier SupportまたはExtended Supportのフェーズにある製品に限られる。この条件を満たさない製品は月次の恩恵を受けないため、資産台帳の棚卸しが月次対応の前提作業になる。
Oracleは「Oracle therefore strongly recommends that customers remain on actively-supported versions and apply security patches without delay」と明記している[1]。遅滞なくという表現は、四半期に一度まとめて当てる運用を前提にしていない。
数千人規模の従業員を抱え、基幹業務システムにRDS for MySQL（Amazonが管理するリレーショナルデータベースサービス）を使い、四半期ごとに内部監査を受けている企業のDB運用担当者は、2026年8月以降、毎月の請求書に見慣れない[…]
毎月第3火曜日という固定日を保守契約の作業枠にどう織り込むか
固定日であることは負担であると同時に、契約交渉に使える数少ない材料でもある。日付が事前に確定しているため、作業枠の予約が可能だからだ。
現実的な設計は、評価と適用を分離することにある。評価は毎月必ず行い、適用は選別する。
| 項目 | 従来型（四半期前提） | 月次込みの設計 |
|---|---|---|
| 評価の頻度 | 年4回 | 毎月（第3火曜日起点） |
| 適用の頻度 | 年4回 | 定期枠＋臨時枠の2系統 |
| 契約上の作業枠 | 年4回で固定 | 定期枠に加え臨時枠をn回分確保 |
| 判断の記録 | 適用実績のみ | 見送り判断も証跡として残す |
見送りの記録を残す点が実務では効いてくる。監査で問われるのは適用したかどうかではなく、判断の根拠が残っているかだからだ。
トリアージの基準はシンプルなほうが回る。稼働製品かどうか、サポートフェーズ内かどうか、深刻度と外部公開の有無、この3段で十分に絞れる。
臨時枠を年何回分確保するかは、契約更改の場で決める数字になる。今回のようにCVSS 10.0が3件出た月に枠がなければ、稟議から始めることになるからだ。
640-507、640-801、640-802。この番号を見て「ああ」と思う人は、それだけで世代がわかります。私が通信キャリアでネットワークエンジニアをしていた2000年代前半、Ciscoの認定試験はまだ番号で呼ばれていて、参考書の巻末に[…]
保守契約の作業回数が固定された日本企業でOracle月次CSPUをどう回すか
同じ状況は日本企業でも起きる。ただし詰まる場所が違う。海外企業で議論になるのが適用の速度だとすれば、日本企業で議論になるのは作業枠と検証環境の調達だ。
違いは主に4点に整理できる。
| 論点 | 一般的な前提 | 日本企業の実情 |
|---|---|---|
| 作業の実施主体 | 社内チームが適用 | SIerが保守契約に基づき実施 |
| 作業回数 | 必要に応じて追加 | 契約で年間回数が固定 |
| 検証環境 | 常設または随時作成 | 確保に稟議と費用計上が必要 |
| 判断の記録 | チーム内で完結 | 監査と内部統制の証跡が必須 |
既存システムの稼働年数も効いてくる。10年以上動いているE-Business Suite環境では、カスタマイズが積み重なって回帰テストの範囲が読みにくい。テスト工数が見積もれないと作業依頼そのものが出せない。
IT部門の判断は、次回の契約更改までに臨時枠の単価と発動条件を書面化しておくことに尽きる。決裁側の判断は、検証環境の常設費用を月次対応の固定費として認めるかどうかで、これを認めない限り稟議の往復が毎月の遅延要因として残る。
ガーミンは「値上げ」せずに、どうやって1台あたりの単価を上げたのか 結論を先に言えば、ガーミンは既存モデルの定価を横並びで引き上げるのではなく、その上に「より高い上位ティア」を新設し、購入者の選好を上へずらすことで平均単価（ASP）を押し[…]
よくある質問（FAQ）
Q. CSPUを毎月適用すれば、四半期のCPUは不要になりますか。
なりません。OracleはCSPUをCPUを補完するものと位置付けており、置き換えとは記していません。10月20日のCPUは予定どおりリリースされます。
Q. 943件すべてに対応する必要がありますか。
ありません。943件は全製品ファミリーの合計で、自社が保有していない製品のパッチは対象外です。まず資産台帳と製品ファミリーの突き合わせから始めることになります。
Q. サポート期間が切れた古いバージョンにもパッチは出ますか。
出ません。パッチが提供されるのはPremier SupportまたはExtended Supportのフェーズにある製品に限られます。該当しない場合はバージョンアップか延長サポート契約の判断になります。
まとめ
今回の変化の核心は943という数字ではなく、判断の周期が四半期から毎月に移ったことにある。943件のうちFusion MiddlewareとHyperionが各262件、E-Business Suiteが120件という内訳は、負荷がDBAではなくアプリケーション基盤側にかかることを示している。
IT部門担当者の次の一手は、資産台帳と製品ファミリーの突き合わせだ。自社が該当する製品ファミリーを確定させれば、毎月の読み込み対象は943件からかなり小さい集合に絞れる。あわせて各製品のサポートフェーズを確認しておくと、パッチが提供されない製品を先に切り分けられる。
決裁側の判断材料は3つに整理できる。費用としては臨時作業枠と検証環境の常設をどこまで固定費として認めるか。リスクとしては見送り判断の証跡を監査に耐える形で残せているか。時期としては、次のリリースが2026年9月15日、その次が10月20日のCPUである以上、契約更改を待たずに暫定運用を決める必要がある。
固定日であることは、計画に織り込める余地があるという意味でもある。第3火曜日という一点が確定している以上、後は枠を先に押さえるかどうかの問題になる。
出典
- Oracle, “Oracle Critical Security Patch Update Advisory – August 2026” https://www.oracle.com/security-alerts/cspuaug2026.html
