Oracleライセンス

Oracleライセンスガイド(2026年版)

著者:イタムス株式会社 代表コンサルタント 武内烈(Oracle License Master / SLAM Master)|最終更新:2026年5月

Oracleライセンスは「世界で最も複雑なソフトウェアライセンス体系のひとつ」と評されます。メトリクスの種類、エディション別の制限、仮想化環境での適用ルール、クラウドへのBYOL(Bring Your Own License)まで、正確な理解なしに適切なライセンス管理は不可能です。本ガイドでは、Oracle DatabaseおよびMiddleware製品のライセンス体系を実務視点で体系的に解説します。

Oracleライセンスの基礎:主要メトリクスを理解する

Oracleライセンスの根幹を理解するには、まず「メトリクス(Metric)」の概念を正確に把握する必要があります。メトリクスとは、ライセンスのカウント方法を定義するものであり、どのメトリクスを選択するかによって必要ライセンス数が大きく変わります。

Processorメトリクス:製品が動作するサーバのCPUプロセッサ数に基づいてカウントします。ただしOracleの定義では、物理コア数にCPUタイプ別の係数(Core Factor)を乗じた値が使用されます。例えばIntel Xeon系プロセッサは係数0.5のため、8コアCPU×1ソケットの場合は4 Processor Licenseが必要です。Processorメトリクスはユーザー数に関係なく利用できるため、多人数が利用するシステムに適しています。

Named User Plus(NUP)メトリクス:システムにアクセスする個人ユーザー数に基づいてカウントします。ただしOracleの最低ライセンス数ルール(Processorあたり最低NUP数)が適用されるため、少人数利用の場合でも一定数以上の購入が必要です。Oracle Databaseの場合、Enterprise Editionは1 Processorあたり最低25 NUP、Standard Edition 2は1 Processorあたり最低10 NUPが必要です。

その他のメトリクス:Application User(特定アプリケーション経由のユーザー)、Employee、Device、Tenantなど、製品・オプションによってさまざまなメトリクスが存在します。Middleware製品(WebLogic Server等)ではProcessorメトリクスが一般的ですが、製品ごとにOracleの製品利用許諾条件(OLSA)を必ず確認することが重要です。

Oracle Databaseエディション別の特徴と選択基準

Oracle Databaseは複数のエディションが存在し、それぞれ機能範囲・制限・価格が異なります。エディション選択の誤りは、コンプライアンスリスクや過剰コストに直結します。

Enterprise Edition(EE):Oracle Databaseの全機能が利用可能なフラグシップエディションです。Real Application Clusters(RAC)、Advanced Compression、Data Guard等の高可用性・高性能機能も別途オプションとして購入可能です。ただしオプション機能は単体でも高額であり、「インストールされているだけで課金対象」となるケースが監査で頻繁に問題になります。EEで監査リスクが高いのは、このオプション機能の無断利用です。

Standard Edition 2(SE2):中小規模システム向けの廉価エディションです。最大2ソケット(16物理コア以下)のサーバでのみ使用可能という制限があります。メトリクスはNamed User Plusのみ使用可能であり、Processorメトリクスは選択できません。SE2にはRACに相当する機能はなく、クラスタリングについても制限があります。コスト面でのメリットは大きいですが、使用可能なサーバ規模と機能制限を十分確認した上で選択する必要があります。

Personal Edition(PE):開発・テスト目的の単一デスクトップ環境での使用に限定されるエディションです。本番環境での使用は契約違反となります。開発環境でPEを使用している場合、本番環境でどのエディションが必要かを明確に整理することが重要です。

仮想化環境でのOracleライセンスカウント方法

仮想化環境でのOracleライセンスは、最も複雑かつ監査で問題になりやすい領域です。Oracleのライセンスポリシー(「Oracle Partitioning Policy」)では、仮想化ソフトウェアの種類によってライセンスカウントのルールが大きく異なります。

「ハード・パーティショニング」と「ソフト・パーティショニング」:Oracleはライセンスカウントの際に、仮想化技術をハード・パーティショニング(物理的に分離されたリソース)とソフト・パーティショニング(ソフトウェアによる仮想化)に分類します。ハード・パーティショニングとして認められる技術は、Oracle VM(OVM)、LDom(Solaris環境)、IBM LPAR(AIX環境)等の一部に限られます。これらではOracle製品が動作するパーティションのリソースのみでライセンスをカウントできます。

VMware環境の問題:VMware(vSphere/ESXi)はOracleの定義ではソフト・パーティショニングに分類されます。そのため、VMware上でOracleを動作させる場合、原則として「そのVMwareクラスタ全体(または物理サーバ全体)の全CPUコア」に対してライセンスが必要です。仮想マシンに割り当てたvCPU数だけではなく、物理サーバの全コアが対象になります。これがVMware環境でOracleを稼働させる際の最大のライセンスリスクです。VMwareとOracleの組み合わせは非常に慎重な設計とライセンス計画が必要です。

コンテナ環境(Docker/Kubernetes):コンテナ環境でのOracleライセンスは、物理ホスト全体のコア数に基づくカウントが原則です。コンテナに割り当てたリソース数ではなく、ホストのリソース全体が対象となるケースが多く、クラウドのマネージドKubernetesサービス(AKS、EKS、GKE)上での利用は特に注意が必要です。

クラウド上でのOracleライセンス(BYOL・クラウドライセンス)

クラウド環境でのOracleライセンスには「BYOL(Bring Your Own License)」と「クラウドライセンス(インクルーデッドライセンス)」の2つのアプローチがあります。どちらを選ぶかで、コスト・柔軟性・コンプライアンスリスクが大きく変わります。

BYOLの仕組みと注意点:BYOLとは、既存のオンプレミスOracleライセンスをクラウド環境に持ち込んで利用するモデルです。AWS、Azure、Google Cloudいずれでも対応していますが、Oracleがそれらのクラウドプロバイダに対してどのようなライセンスポリシーを適用するかは複雑です。特にAWSおよびAzureに対しては、Oracleは「Authorized Cloud Environments」として一定の条件下でのみBYOLを認めています。クラウドプロバイダとOracleのポリシー文書を常に最新版で確認することが必要です。

Oracle Cloud Infrastructure(OCI)でのBYOL優遇:Oracleの自社クラウドであるOCI上でBYOLを利用する場合、他クラウドとは異なる優遇ルールが適用されます。例えばOCIではハイパースレッディング無効化オプション等によりコア係数を有利に計算できるケースがあります。Oracle担当営業はOCIへの移行を積極的に提案してきますが、TCO(総保有コスト)と業務要件を独立した観点で評価することが重要です。

クラウドライセンス(BYOL不使用):クラウドプロバイダが提供するOracle Databaseのマネージドサービス(Amazon RDS for Oracle等)をライセンス込みで使用するモデルです。ライセンス管理の煩雑さは軽減されますが、長期的なコストは高くなる傾向があります。Oracle Database Service for Azure等、OracleとMicrosoft・Googleの連携サービスも登場しており、最新の選択肢を定期的に評価することが推奨されます。

Oracle Support(年間保守)の仕組みと最適化

Oracle製品の永続ライセンスには、年間の保守料(Oracle Software Update License and Support)が紐づいています。この保守料の仕組みを正確に理解し、適切に管理することがライセンスコスト最適化の重要な鍵となります。

保守料の基本構造:Oracle Supportの年間費用は、購入時ライセンス価格の22%が標準レートです。ただし保守料はOracleのリスト価格から値引きが行われたライセンス価格に対してではなく、特定の計算ルールに基づいて算定されます。毎年の更新時にOracleはインフレ調整として一定の値上げを行う権利を持っており(現行契約上は年率最大8%等の上限が設定されているケースが多い)、長期的には保守料が大きなコスト負担になります。

未使用ライセンスの保守削除:使用していないライセンスの保守を「Termination」(解約)することでコスト削減は可能ですが、一度解約したライセンスを再度有効化する際は再購入が必要になります。また保守の一部だけを削除すると、Oracleとの関係性においてデメリットが生じる場合もあります。保守削除の判断は、将来の利用計画とのトレードオフを慎重に評価した上で行う必要があります。

保守モデルの代替:サードパーティの保守サービス(Rimini Street等)を利用することで、Oracle Supportコストを大幅に削減できるケースがあります。ただしセキュリティパッチの提供方法・サポート範囲・将来のアップグレード計画への影響を十分に評価した上で判断することが必要です。Oracle契約上のペナルティ条項についても事前確認が不可欠です。

自社のOracleライセンスを専門家に診断してもらう

Oracleライセンスは複雑で、一般的なIT担当者が全体を正確に把握することは困難です。Oracle License Masterの資格を持つ専門家が、貴社のライセンスポジションを診断し、最適化の方向性をご提案します。初回相談は無料です。

無料相談を申し込む →