Oracleライセンス

クラウド上でのOracle BYOL完全ガイド

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

オンプレミスで保有するOracleライセンスをクラウド上で活用するBYOL(Bring Your Own License)は、クラウド移行コストを大幅に削減できる有力な手段です。しかし適用できるクラウド環境や条件はOracleが厳格に定めており、誤った理解で運用するとライセンス違反・追加請求のリスクを招きます。本稿では実務経験に基づき、AWS・Azure・OCIそれぞれの適用ルールと最適化戦略を体系的に解説します。

Oracle BYOLとは:オンプレミスライセンスをクラウドで使う仕組み

BYOL(Bring Your Own License)とは、すでに企業が保有するOracleソフトウェアライセンスをクラウド上の仮想マシンで使用する権利です。クラウドプロバイダーが提供する「ライセンス込み」の価格モデルとは異なり、インフラコストのみを負担することでTCOを削減できる点が最大のメリットです。

Oracleのライセンスポリシーでは、BYOLを利用できるクラウド環境を「Authorized Cloud Environment(ACE)」として認定しています。2026年5月時点において、ACEに認定されているパブリッククラウドはAWS、Microsoft Azure、Google Cloud Platform、Oracle Cloud Infrastructure(OCI)、IBM Cloudなど主要プロバイダーが含まれますが、認定状況はOracleの公式サイト「Oracle Software on Third-Party Public Cloud Platforms」で随時確認することが必要です。

BYOLの適用にあたっては、オンプレミスと同等のライセンスメトリック(Processor / Named User Plus)が求められます。クラウド上のvCPUをProcessorライセンスに換算する際には、OracleのCore Factor Tableを適用する必要があります。例えばAWSのEC2やAzureのVMで使用されるIntelプロセッサ系の場合、vCPU 2つ=Processorライセンス1本という換算が適用される環境が多いですが、インスタンスタイプや世代によって異なるケースもあるため、個別確認が不可欠です。

AWS・Azureでの適用条件とAuthorized Cloud Environmentリスト

AWS上でのOracle BYOLは、EC2インスタンスへの直接デプロイを前提としています。Dedicated Host(専用ホスト)オプションを使用することで、物理コアベースのライセンス計算が可能となり、コストを最適化できる場合があります。一方、Shared Tenancy(共有テナント)の場合はvCPU単位でのカウントが基本となります。

Microsoft Azureでは、Dedicated Host(Azure専用ホスト)の活用が特に有効です。Azureの専用ホストを使用すると、そのホスト上の物理コア数に基づいてライセンスをカウントできるため、高密度の仮想マシン配置を行う場合にライセンスコストを大幅に削減できます。なお、AzureのVMware Solution(AVS)はACEには含まれていないため、BYOLは適用できないことに注意が必要です。

ACEリストに含まれているか否かは、ライセンスコンプライアンス上の重大な分岐点です。OracleはACE外での自社ソフトウェア使用を「ポリシー違反」として監査対象とします。自社が利用しているサービス(例:AWS EKS、Azure AKS上のコンテナ環境)が対象かどうかも含め、コンテナ・マネージドサービスへの展開についてはOracleの最新ドキュメントを参照し、不明点は専門家に確認することを強く推奨します。

OCIでのOracle BYOLの特別ルール

Oracle Cloud Infrastructure(OCI)は、自社製品との親和性から他クラウドに比べてBYOL優遇措置が充実しています。OCI上でのBYOLは「Universal Credits」と組み合わせることで、インフラコストのみに集中できる料金体系となっており、ライセンスコストとインフラコストを明確に分離できます。

最大の特徴は「Bring Your Own License(BYOL)モデル」に加えて「License Included」モデルとの柔軟な切り替えが可能な点です。また、OCI上でのOracle Databaseに関しては、Exadataインフラを利用した際のライセンス換算方法がAWS・Azureとは異なる計算式(OCPUベース)を採用しています。1 OCPU=2 vCPUですが、ライセンス計算ではOCPUをそのままProcessorライセンスにマッピングするため、他クラウドより有利に働くケースがあります。

さらにOCIではOracle Database Exadata Cloud Service(ExaCS)やAutonomous Databaseを活用することで、追加のライセンス節約が見込める場合があります。ただし、OCIへの移行はアーキテクチャ上の制約を伴うことも多く、既存アプリケーションの互換性評価を先行させることが移行成功の鍵です。

クラウド移行時のライセンス最適化戦略

クラウド移行においてBYOLを最大限活用するには、まず現状のライセンス保有状況を正確に把握することが出発点です。特に、Support(サポート)の有効期限と利用権の範囲を確認し、未使用または過剰に購入したライセンスを棚卸しします。

次に、移行先クラウド環境でのインスタンスサイジングを慎重に設計します。BYOLではCPUコア数がライセンスコストに直結するため、必要以上に大型のインスタンスを選択しないこと、かつ将来のスケールアップを見越したバッファを適切に確保することのバランスが重要です。Reserved InstanceやSavings Planなどのコミットメント型割引とBYOLを組み合わせることで、インフラコストのさらなる削減が実現できます。

また、Oracle LMSやGLAS監査においてBYOL使用状況が問われる場合に備え、使用実績のログ(CPU使用率、インスタンス稼働記録、ライセンス割り当て記録)を継続的に保管しておくことが不可欠です。クラウド移行直後は特に監査リスクが高まる傾向があるため、移行前後でライセンスの証跡管理体制を整備しておくことを強く推奨します。

BYOL適用でよくあるミスと対策

実務でよく見られる第一のミスは「ACE外の環境でBYOLを適用しているケース」です。例えば、VMware Cloud on AWSやNutanixなどの特定のサービスはACEに含まれておらず、そこにBYOLを適用するとOracle社から追加請求を受けるリスクがあります。利用するクラウドサービスが最新のACEリストに掲載されているかを事前に確認することが基本です。

第二のミスは「vCPUとライセンス本数の換算誤り」です。Core Factor Tableの適用を忘れたり、プロセッサタイプの識別を誤ったりすることで、実際より少ないライセンス本数で運用してしまうケースがあります。特にAWSのm系・c系・r系など複数のインスタンスファミリーを混在利用している場合には、ファミリーごとに係数を確認する必要があります。

第三のミスは「Supportの有効期限切れのままクラウドで稼働させるケース」です。BYOLはライセンスを保有していることが前提ですが、Supportを失効させた場合、そのライセンスをクラウド上で使用する権利も失効するという点を見落としている企業が少なくありません。サポート契約の管理とBYOLの権利確認は一体で行う必要があります。

Oracle BYOLについて専門家に相談する

クラウド移行におけるOracle BYOLの適用可否やライセンス本数の試算、監査リスクの評価まで、Oracle License Masterが実務ベースでサポートします。まずは現状ヒアリングからお気軽にご相談ください。

無料相談を申し込む →