オラクルのライセンス・フレームワークは、複雑で常に進化していることで有名です。IT資産管理(ITAM)の実務家にとって、コンプライアンスの罠や予期しないコストを回避するためには、オラクルのルールに遅れずについていくことが重要です。
このガイドでは、2025年のオラクル・ライセンスの実用的な概要を、技術製品、アプリケーション、クラウド・サービス、および実際のシナリオで説明します。一般的なライセンス指標、仮想化の落とし穴、クラウドとSaaSに関する考慮事項、契約上の重要事項、ベストプラクティスについて説明します。
目標は、ITAMの専門家がOracleライセンスをプロアクティブに管理し、監査リスクを回避するための知識を身に付けることです。オラクルの監査が多額のペナルティにつながる可能性のある環境では、これらのトピックをしっかりと把握することが不可欠です。すべてのITAM実務家が理解すべきOracleライセンスの主要領域について詳しく見ていきましょう。

オラクルの主要なライセンス・メトリック(指名ユーザー・プラス、プロセッサ)
オラクルは、主にテクノロジー製品(データベースやミドルウェアなど)を、NUP(Named User Plus)とProcessorという2つのコアメトリックでライセンス供与しています。これらのメトリクスを理解し、それぞれが適切なタイミングで理解することは、適切なライセンス管理の基礎となります。

• Named User Plus(NUP):このユーザーベースのメトリックでは、Oracleソフトウェアにアクセスする一意のユーザーまたはデバイスごとにライセンスが必要です。ソフトウェアの使用を許可されたすべての個人は、同時にソフトウェアを使用するかどうかにかかわらず、指定ユーザーとしてカウントされます。オラクルでは、ライセンスをユーザー間で共有できないという厳格な定義があります。NUP ライセンスは、ユーザー数が限られている、または識別可能な環境でよく使用されます。ただし、Oracle では、多くの製品でプロセッサあたりの最小 NUP 数量が強制されます (たとえば、Database Enterprise Edition では通常、サーバーのプロセッサ コアあたり少なくとも 25 の NUP ライセンスが必要です)。これにより、強力なサーバーでライセンスが不足しているユーザー数が少なくなるのを防ぐことができます。

• プロセッサ: このメトリックはハードウェアベースです。Oracle ソフトウェアがインストールされているサーバー上のプロセッサ (CPU コア) のライセンスは、ユーザーとして付与されます。これは、物理コアをカウントし、CPU タイプの “core factor” (Oracle の Core Factor Table から) を掛けて計算されます。たとえば、Intel x86 コアの係数は 0.5 で、実質的には 2 つのコアが 1 つのライセンスとしてカウントされます。プロセッサ ライセンスでは、そのサーバー上のソフトウェアに無制限の数のユーザーがアクセスできるため、ユーザー数が多いシナリオや予測不可能なシナリオ (公開アプリケーションや企業全体のシステムなど) に最適です。
各メトリクスを使用する状況:
ユーザーベースが小さく、明確に定義されている場合、NUP ライセンスは費用対効果が高く、そのユーザーセットに対してのみ支払います。たとえば、Oracle を使用する 20 人の開発チームには、20 NUP のライセンスが付与されます (最小要件が適用されます)。対照的に、ソフトウェアが個々のユーザーをカウントすることが現実的でない広範な人口 (または外部ユーザー) をサポートしている場合、プロセッサ ライセンスはより安全です。
このため、多くの組織では、Web アプリケーションを支えるデータベースを Processor によってライセンスしています。常に損益分岐点を評価してください:ユーザー数が増えると、NUPのコストがプロセッサのコストを超える可能性があります。また、製品の使用量が内部 (ユーザーをカウント可能) か外部 (匿名または無数のユーザーにプロセッサ ライセンスが必要) かも検討してください。

インストールされているソフトウェアと実行中のソフトウェア:
Oracleの重要なルールは、実際の使用状況に関係なく、すべてのインストールにライセンスを付与する必要があるということです。オラクルの標準的な契約言語には、サーバー上に「インストールおよび/または実行」されているプログラムのすべてのインスタンスにライセンスが必要であると記載されています。つまり、マシンにOracleソフトウェアをインストールするだけで(サービスがシャットダウンされている場合でも)、ライセンス可能なデプロイメントとしてカウントできます。
よくある間違いは、アイドル状態またはバックアップのインストールにはライセンスが必要ないと思い込んでいることですが、Oracleの目から見れば、実行する準備ができている場合はカバーされるべきです。ITAMの実践者は、アクティブな使用だけでなく、環境全体でインストールされたバイナリを追跡する必要があります。たとえば、DBAがOracle Databaseをテスト・サーバーにインストールしたが、起動しなかった場合でも、監査人がライセンスを取得すると予想されるデプロイメントを構成します(有効な試用またはフェイルオーバーの許容量に従って非常に短期間で削除されない限り)。

コンプライアンスに関するよくある間違い:
よくあるエラーの 1 つは、Named User Plus ライセンスを過小評価することです。組織ではアクティブ・ユーザーまたは同時ユーザーのみがカウントされることがありますが、オラクルでは、アクセス権を持つすべての指名された個人にライセンスが必要です。たとえば、50人がOracleデータベースへのログイン資格情報を持っている場合、一度に5人しか使用しない場合でも、50人全員がNUPライセンスを必要とします。プロセッサあたりの最小NUP(最小NUP)要件を満たさないことも別の落とし穴です – たとえば、最小がコアあたり25(合計100 NUP)のときに、4コアサーバーに30のNUPライセンスをライセンスすると、準拠しなくなります。プロセッサ ライセンスでは、多くの場合、コア係数を誤って適用したり、サーバー上のすべてのプロセッサ コアにライセンスを付与しなかったりします。
常にオラクルの公式コア係数テーブルを使用し、オンプレミスハードウェアの仮想CPUだけでなく物理コアをカウントします。また、同じ環境でメトリクスを混在させると、問題が生じる可能性があります。Oracleでは、通常、特定のインストールが一貫して1つのメトリックでライセンス供与されることを想定しています。
複数のデプロイメントがある場合は、それぞれに異なるメトリクスを使用できますが (たとえば、NUP の 1 つのテストサーバーと Processor ライセンスの本番クラスター) が、使用量を分離する必要があります。最後に、Oracleライセンスはフローティングまたは同時使用ではなく、「Named User Plus」は同時使用ユーザーライセンスではないことに注意してください。実際の各人には独自のライセンスが必要ですが、その人がオフラインのときには他のユーザーが共有することはできません。

仮想化におけるテクノロジー製品のライセンス
仮想化は、Oracleのライセンス・リスクの主な原因です。Oracle のポリシーでは、仮想マシンのハードウェアの分割に関して、ソフト パーティショニングとハード パーティショニングを区別しています。ITAMの実務家は、仮想化環境での予期せぬライセンスの驚きを避けるために、この違いを理解する必要があります。

• ソフトパーティショニング: これは、オラクル社が ライセンスの範囲を制限する有効な手段として認識していない仮想化テクノロジまたは方法を指します。Oracleの見解では、ソフトパーティショニングには、VMware ESXi(vSphereクラスタを含む)、Microsoft Hyper-V、KVMなどの最も一般的なハイパーバイザが含まれます。これらは、共通の構成で使用される場合です。ソフト パーティション分割の特徴は、VM へのリソース割り当てを簡単に変更できること、または VM がホスト間で移動できることです (たとえば、VMware vMotion がサーバー間で VM を移動するなど)。Oracleのポリシーでは、ソフト・パーティションを使用してライセンス要件を減らすことはできません。 Oracleソフトウェアが実行される可能性のある物理環境全体にライセンスを付与する必要があります。たとえば、Oracle データベース VM が 10 台のホストの VMware クラスタで実行されている場合、Oracle は、VM が通常は 1 台のホストでのみ実行されている場合でも、10 台のホストすべて (それらのホスト上のすべてのコア) にフル ライセンスが必要であると主張します。監査では、Oracleは、Oracle VMが理論的にホストに移動したり、ホスト上で実行したりできる場合、そのホストにライセンスが必要であるというスタンスをとっています。これは、ライブ マイグレーションが広く有効になっている場合、VMware vCenter またはデータセンター クラスター内のすべてのサーバーに拡張できます。ここでのコンプライアンスリスクは膨大で、企業はVMに割り当てられたvCPUのみをカウントし、大規模なクラスタはカウントしなかったため、ライセンス不足に陥っています。ソフト パーティション分割環境での安全なアプローチは、多くの場合、Oracle ワークロードを専用のホストまたはクラスタに物理的に分離し、VM の移動性を制限することです (たとえば、Oracle 専用の別の VMware クラスタを作成し、vMotion をそのクラスタに制限します)。そうしないと、すべての潜在的なホストのライセンスを取得するための予算を立てる必要があり、コストが大幅に増加する可能性があります。

• ハードパーティショニング:これらは、オラクルがライセンスをマシンのサブセットに制限する方法として受け入れているテクノロジーまたは構成です。ハード・パーティション化には、通常、静的ハードウェア・パーティショニングまたはOracleが承認したコアのキャッピング方法が含まれます。例としては、ピン留めされた CPU で構成された Oracle 独自の Oracle VM (OVM) ハイパーバイザー、ハード cgroups を使用した Oracle Linux KVM (文書化されたケースもあります)、コアが上限された IBM の論理パーティション (LPAR)、またはプロセッサ上限が固定された Solaris ゾーンなどがあります。Oracleは、ハード・パーティション化と見なされる方法をリストしたパーティション化ポリシー・ドキュメントを定期的に公開しています。これらの承認済み方法のいずれかを使用する場合、Oracleに割り当てられたサーバーの一部のみをライセンスできます。たとえば、Oracle VMを使用すると、OracleデータベースVMをホスト上の特定の2つのCPUコアに固定し、サーバー全体ではなく、その2つのコアのみのライセンスを購入できます(コア係数を適用)。したがって、ハードパーティショニングは、ライセンス可能なフットプリントを制限することでコスト削減を実現できます。重要: パーティションは、ハードウェアによって強制されるか、オペレータによって簡単に変更できない方法で構成する必要があります。そうしないと、Oracle が依然としてソフトと見なす可能性があります。「Oracle Trusted Partition」は、Oracle Enterprise Managerがパーティション分割を制御する場合に、Oracleがサブキャパシティ・ライセンスを付与する概念であり、通常はOracle独自の仮想化エコシステムでのみ使用できます。

仮想化プラットフォームと監査への影響:
VMwareは、Oracleの目から見たソフトパーティショニングの最も一般的な例です。OracleにはVMwareに関する正式な契約条項はありませんが、監査慣行では、Oracleソフトウェアを実行できるすべてのホストの完全なライセンスを要求しています。たとえば、ある企業がVMwareファームに単一のOracle VMを持っていて、クラスタ内の32のホストすべて(数百のコア)にライセンスが必要であるという監査結果に直面しました。その結果、一部の組織では、スコープを封じ込めるために、他のクラスターに接続せずに Oracle を別々の VMware クラスターに分離することを選択します。一方、Oracle VM(OVM)は、Oracleが推奨するハイパーバイザーであり、ハードパーティショニングで認識されているため、OVMを使用すると、Oracleを特定のコアに制限できる可能性があります。ただし、OVM構成がOracleのガイドラインに従っていることを確認してください(たとえば、OVM CPUピニングを使用し、ライセンスのないサーバーへのライブマイグレーションを許可しないでください)。KVMなど:Oracleのスタンスは、一般的に、Oracle Linux KVMでOracleの特定のハードパーティション方法を使用しない限り、汎用のLinux KVMはソフトパーティションとしてカウントされるというものです。Microsoft Hyper-V もソフト パーティションとして扱われます。パブリッククラウド上のOracleは、独自のルールを持つ少し異なるシナリオ(以下のクラウドセクションで説明)です。

監査リスクとベスト・プラクティス: 仮想化環境では、常にオラクルが可能な限り最大のフットプリントを見ることを想定してください。リスクを軽減するには:
• Oracle VMを実行できる場所を文書化し、適用します。アフィニティ ルールまたは専用クラスターを使用します。
• VMwareを使用している場合は、OracleワークロードをOracle以外のワークロードと混在させないように専用クラスタに保持し、承認されていないホストへの自動移行を無効にします。一部の企業は、Oracleの解釈をなだめるために、Oracleクラスター用に個別のvCenterインスタンスを維持しています。
• ライセンスを制限するために、オンプレミスのハード・パーティション・テクノロジーを検討してください (例えば、Oracle データベースを Solaris で上限付きゾーンで実行する場合や、IBM Power で専用 LPAR を実行する場合) は、それらがインフラストラクチャーに合っている場合です。
• パーティション構成とOracleの承認またはポリシーの記録を保持します。Oracleのパーティション分割ポリシーは ポリシーであり(ライセンス契約には明示的に含まれていない)、強制力についての議論につながりますが、実際には、監査では、顧客は訴訟ではなく交渉することになることがよくあります。したがって、コンプライアンス計画は、コストのかかる紛争に巻き込まれないように、ポリシーに従う必要があります。
要約すると、仮想化は慎重に扱います。ソフト パーティショニングは、誤った節約感を与える可能性がありますが、コンプライアンスのギャップにつながる可能性があります。可能な場合はハードパーティションを作成し、疑わしい場合は、Oracleを実行できるすべての物理容量のライセンスが必要であると想定してください。

ライセンス プロダクション、非プロダクション、テスト＆開発環境

オラクルのライセンス要件は、本番環境の有無にかかわらず、一部の例外を除き、すべての環境に広く適用されます。
一部のベンダーとは異なり、オラクルは開発システムまたはテストシステムに対して無料または割引価格のライセンスを自動的に提供しません(契約契約で取り決められていない限り)。ITAMの実践者は、本番環境、開発、テスト、および災害復旧(DR)セットアップでのライセンスを計画する必要があります。

プロダクション vs 非プロダクション:
デフォルトでは、非本番環境にインストールされている任意のOracleソフトウェア(開発、テスト、QA、ステージングなど) プロダクションと同様にライセンスが必要です。運用サーバーのみのライセンスを取得するという誤解がよくありますが、これはOracleでは誤りです。特別な契約またはライセンスタイプがない限り、テストに使用されるデータベースは、NUP ライセンスまたはプロセッサ ライセンスのいずれかでカバーする必要があるデータベース展開です。
たとえば、本番環境のOracle DatabaseとQA用のデータベースの別のテスト・インスタンスがある場合、通常は両方のライセンスを購入する必要があります(または、既存のライセンスをそれらに分割する必要があります)。オラクルは、Oracle Technology Network(OTN)開発者ライセンスの下で無料のソフトウェアダウンロードを提供していますが、このライセンスは個人的な開発とプロトタイピングのみを目的としており、企業のテスト環境やマルチユーザーテストでの使用を目的としたものではありません。したがって、組織全体のQAまたはトレーニングシステムにOTNダウンロードを使用することは、オラクルの条件に違反します。各環境にライセンスが考慮されていること、または非運用使用権限を明示的にネゴシエートすることを常に確認してください。

Oracle の 10 日間ルール (フェールオーバー/DR): Oracle のポリシーの注目すべき例外の 1 つは、ディザスター リカバリー シナリオです。Oracle では、ライセンスのないスペア・サーバーをフェイルオーバー環境で使用することを、年間累積合計 10 日間まで許可しています。これはよく「10日ルール」と呼ばれます。これは通常、プライマリシステムに障害が発生したときにのみアクティブになるコールドスタンバイシステムまたはパッシブスタンバイシステムに適用されます。
このルールでは、真のスタンバイ サーバーに対して別途ライセンスを購入する必要はありません。ただし、そのサーバーが正規のフェイルオーバー イベントまたはディザスター リカバリー テスト中にのみ使用され、使用量が暦年の 10 日を超えない限りは、そのサーバーに対してライセンスを別途購入する必要はありません。DRサーバーがアクティブ化される毎日(または1日の一部)は、10日間の合計にカウントされます。10 日間の許容量を超える場合 (たとえば、停止が長引く場合や、拡張テストのために DR ノードを実行する場合)、そのサーバーには完全なライセンスが必要です。
また、これはプライマリ クラスタごとに 1 つのフェイルオーバー ノードに適用されることに注意してください。複数のスタンバイ ノードや、より複雑な HA セットアップ (アクティブ/アクティブ クラスタなど) がある場合、ルールはそれらをカバーしない可能性があります。通常は、フル ライセンスが必要です。ITAMは、スタンバイデータベースの使用を追跡する必要があります:DRドリルまたはフェイルオーバーの日付を記録して、10日間の制限に準拠していることを確認します。
他のタイプのスタンバイおよびバックアップ構成の場合、オラクルのポリシーでは、スタンバイ・データベースがオープン/読み取り可能である場合、または本番ワークロード(読取り専用レポートを含む)に使用されている場合は、 ライセンスを取得する必要があると規定されています。
そのため、継続的に同期され、読み取り用に開いている Data Guard の物理スタンバイや、同期して実行されているクラスター フェールオーバー ノードは、実際には “アイドル状態” ではないため、通常はライセンスが必要です。10 日間のルールは、主に、バックアップが通常電源オフになっているか、インシデントが発生するまで Oracle サービスを実行していないシナリオを対象としています。

テストおよび開発システムのライセンス:
Oracleライセンスはデフォルトでは環境を区別しないため、多くの組織は、多数の非本番インスタンスのライセンス取得に高いコストに直面しています。オラクルは、特定のケースでいくつかの救済を提供します。
• 一部のお客様は、割引された開発/テストライセンスまたはユーザーパックを交渉します。オラクルは、テスト/開発用の特別なライセンスSKUを低価格で提供していることが知られていますが、これらには厳しい制限が伴います(非本番環境での使用のみ)。Oracleの担当者が「開発ライセンス」を提供している場合は、契約でその範囲が明確に定義されており、実際に低コストであることを確認してください。これらは価格表の標準ではありませんが、エンタープライズ契約に含まれている場合があります。
• Oracle Cloudは、コスト効率の高い開発/テストの手段を提供します:たとえば、オラクルのAutonomous Databaseを短期的に使用したり、小規模な開発データベースにAlways Freeクラウド層を使用したりすることで、これらの目的でのオンプレミス・ライセンスを回避できます。
• 別のアプローチは、永久ライセンスが必要ない場合は、非本番環境の期間ライセンス(1年または3年のライセンス)を活用することで、初期費用を削減できますが、有効期限を管理することを忘れないでください。
よくある落とし穴:
典型的な間違いは、開発環境に完全なOracleソフトウェアをデプロイすることです。「本番環境ではないので問題ない」と想定しています。監査人は、これを本番環境での使用と同じように扱います。もう一つの落とし穴は、10日ルールの誤用です – 例えば、ライセンスのないサーバーで毎月1日のDRテストを実行するなどです。
毎月12回のテストを行うと、1年間で合計12日間の使用となり、許容量を破ります。このような場合、そのDRサーバは遡及的にライセンス(およびバックサポート料金)が必要になります。DR テストは常にカウントして制限するか、環境にライセンスを付与する準備をしてください。高可用性が必要な場合、一部の企業は、スタンバイ サーバーのライセンスを完全に取得して無制限に使用できるようにすることを選択します (特に、より頻繁な切り替えを行ったり、スタンバイをレポートに使用したりする場合)。
ベスト プラクティス: 開発/テスト サーバーは、契約上の例外が書かれている場合を除き、ライセンス数では運用環境と同様に扱います。非本番環境を必要なスケールに保つ – たとえば、各 CPU にはライセンスが必要なため、テスト データベースに必要以上の CPU を割り当てないでください。
特定の非本番環境の場合(ワークロードが十分に小さい場合)にはOracle Database Standard Editionを安価な代替手段として使用するか、無料だが制限のあるOracle XE(Express Edition)の使用を検討してください。また、明確な環境ラベルとコントロールを維持して、「環境クリープ」(テストインスタンスが誤って本番データに使用され、ライセンスの必要性が曖昧になる)を防ぎます。最後に、ITAMに通知されない限り、Oracleソフトウェアをどこにもインストールしないという内部ポリシーを維持することで、善意の開発者がライセンスを取得せずにOracleインスタンスをテスト用にスピンアップすることを防ぎます。

アプリケーション・ライセンス・メトリック(アプリケーション・ユーザー、従業員、エンタープライズ収益)
データベースやミドルウェア以外にも、オラクルのエンタープライズ・アプリケーション(E-Business Suite、PeopleSoft、JD Edwards、Oracle Fusion Appsなど)は、さまざまなライセンス・メトリックを使用します。
主要な指標には、アプリケーションユーザー、従業員、およびさまざまなエンタープライズ指標(収益など)が含まれます。これらのメトリクスは、技術的なデプロイ対策ではなく、ビジネス指標と一致しています。

• アプリケーション・ユーザー・ライセンス: アプリケーション・ユーザーは、通常、特定のOracleアプリケーション・モジュールの使用を許可された一意の人間のユーザーです。これは名前付きユーザーに似ていますが、Oracle Applicationsのコンテキストでは、定義をアプリケーション内のロールに関連付けることができます。たとえば、Oracle E-Business Suiteでは、財務モジュールのアカウントを持つ各ユーザーに対してアプリケーション・ユーザー・ライセンスが必要な場合があります。この指標は、ERP、CRM、および同様のシステムによく適用されます。重要な点は、アプリケーションが間接的(ミドルウェアやポータルなど)でアクセスされる場合でも、Oracleはすべてのエンドユーザーがカウントされることを想定しているということです。よくある落とし穴: システムにアクセスするすべてのユーザーをカウントするわけではありません。たとえば、CRMシステムが社内スタッフと外部パートナーの両方によって使用されている場合、それらすべての個人がライセンスを取得する必要がある可能性があります。また、1人のユーザーが複数のモジュール(たとえば、財務とサプライチェーンの両方)を使用する場合があります。オラクルのライセンスによっては、個別のモジュールユーザーライセンス、またはそのユーザーに必要なすべてのモジュールをカバーするアンブレラライセンスが必要になる場合があります。ベストプラクティスは、アプリケーションのユーザーリストとライセンスを定期的に調整することです(特に、従業員が参加、退職、または役割を変更する場合)。

• 従業員メトリック: オラクルは、組織内の従業員の総数 (場合によっては請負業者も含む) に基づいてアプリケーションのライセンスを取得することがあります。この指標は、オラクルのHuman Capital Management(HCM)またはHRソフトウェアで一般的であり、すべての従業員が積極的に使用しているわけではない場合でも、すべての従業員のデータがシステムに保存されます。ホストされた従業員または完全なエンタープライズ従業員メトリックでは、ライセンス数 = 合計人員数です。オラクルの定義には、通常、フルタイム、パートタイム、臨時従業員、さらにはデータがシステム内にある請負業者やアウトソーシング業者も含まれます。基本的に、あなたの会社に5,000人の従業員がいる場合、従業員ベースのライセンスでは、実際にソフトウェアを使用する人事スタッフの数に関係なく、5,000人全員に支払う必要がある場合があります。その利点は、現在および将来のすべてのユーザーを対象としていることです。個々のユーザーライセンスを管理する必要はありませんが、幅広い範囲に対して料金を支払うことになります。よくある落とし穴: 従業員数の変更が欠落している。従業員数が増加すると、ライセンスされた従業員数を超え、契約の調整が必要になる可能性があります。オラクルは通常、注文書に、人員がライセンス数を超えた場合にライセンスを調整するように要求する条項を挿入します。もう一つの落とし穴は、請負業者が重要であることを認識していないことです。たとえば、5,000人の直接従業員に加えて500人の請負業者がいる場合、Oracleはライセンスとして「名前付き従業員」の合計を5,500と見なす場合があります。また、従業員指標を使用する場合は、M&A活動を慎重に検討する必要があります – より多くの従業員を抱える会社を買収すると、その新入社員がシステムを使用したり、システム内で追跡されたりした場合、突然コンプライアンス違反になる可能性があります。

• エンタープライズ収益またはその他のカスタム・メトリック: 場合によっては、オラクルは、年間収益、顧客数、その他の業界固有の数値などのビジネス・メトリックに基づいてアプリケーションのライセンスを取得します。たとえば、Oracle Siebel (CRM) には、価格設定が企業の収益または顧客レコードの数に関連付けられているオファリングがありました。別の例を挙げると、オラクルの公益事業の請求システムは「メーター接続数」でライセンスされ、金融サービスアプリでは「運用資産」でライセンスされている場合があります。これらのエンタープライズメトリクスでは、基本的にユーザー数に制限はありませんが、価格はビジネスの規模に合わせて調整されます。一般的な落とし穴: これらのメトリクスでは、メトリクス自体を入念に追跡する必要があります。収益ごとにライセンスされ、収益が年々増加している場合、契約上、その報告が義務付けられ、追加のライセンス容量を購入する可能性があります(または、メトリックがサブスクリプション条件で使用されている場合は、少なくとも更新が高くなります)。メトリックの定義が契約書で明確であることを確認してください(たとえば、収益の場合、全世界の総収益か、ビジネスユニットのみか、どの会計年度かなど)。もう一つのリスクは、無制限の使用が無制限の機能を意味すると仮定することですが、それでもライセンスがカバーするモジュールや機能に注意する必要があります。

• カスタム・アプリケーション・バンドル: オラクルでは、1つのメトリックで複数の製品のパッケージを頻繁に販売しています。たとえば、「Oracle E-Business Suite Enterprise Bundle」では、特定の数のユーザーに対して多数のモジュールを使用できる場合や、エンタープライズ・メトリックに基づいて多数のモジュールを使用できる場合があります。これらのバンドルは、紙の上でのライセンスを簡素化できますが(1つの指標で多くのことをカバーします)、どの製品が含まれているかを正確に把握していることを確認してください。よくある間違いは、バンドルでカバーされていないモジュールを使用することです。また、ユーザーごとにライセンスされたバンドルでは、それらのユーザーがバンドルごとに個別にカウントされているか、他のカウントと重複しているかどうかを確認します。
例とシナリオ:
例えば、Oracle PeopleSoft HRのライセンスを従業員メトリックで取得している企業を想像してみてください:従業員数が3,000人で、ホスト型従業員ライセンスを3,000個購入しています。1年後、会社は3,500人の従業員に成長しました。コンプライアンスを維持するために、彼らは成長をカバーするために、通常は同じ従業員あたりの価格で、追加の500ライセンス(またはOracleがそれらを販売するユニット)を迅速に調達する必要があります。そうしないと、監査で 500 ライセンスが不足していると判断されます。
別のシナリオ: ある公益事業会社は、Oracle Customer Care & Billingに100万の「サービス・ポイント」(従量制の顧客)のライセンスを持っています。顧客基盤は 110 万人に拡大し、再びライセンスの更新が必要になりました。アプリケーションユーザーメトリクスの場合、一般的なシナリオはユーザーの離職率です。100人のOracle CRMユーザーにライセンスを付与したとします。10人が退会し、15人が新たに参加した場合、常に100人のアクティブな名前付きユーザーを超えないようにする必要があります(名前付きユーザーの総数<= 100)であれば、古いアカウントを無効にして新しいアカウントを追加するだけで問題ありません)。しかし、営業部門がITAMに通知せずにさらに20人のアクセスを許可することを決定した場合、ライセンス数を20人上回ることになります。

ITAMの主なポイント:
アプリケーションユーザーを名前付きシート数のように扱う – 人事またはITセキュリティと協力して、利用可能なライセンスに対する新しいユーザーの追加を承認するプロセスを実装します。従業員ベースのライセンスの場合は、関連する指標(人員、収益など)の定期的な監査(四半期ごとまたは年次)を確立して、調整のニーズを予測します。また、紛争を避けるために、これらのメトリクスがどのように定義されているかについて、常にOracleからのドキュメントを保持してください。アプリケーション・ライセンスのコンプライアンス違反のコストは、データベース・ライセンスと同じくらい高くなる可能性があります。オラクルは、アプリケーション・ユーザーの過剰デプロイメントやエンタープライズ・メトリックが見つかった場合、バックサポートとライセンス料を請求します。

Oracle Cloudライセンス
組織がオラクルのワークロードをクラウドに移行するにつれて、ライセンスモデルも適応しています。ITAMの実務家は、BYOL(Bring Your Own License)の規定、クラウド固有の計算、Universal Cloud Credits(UCC)などの新しいオラクルプログラムに対応する必要があります。このセクションでは、主要なクラウド(AWS、Azure、Google Cloud)とオラクル独自のクラウド製品でのオラクルライセンスの仕組みについて説明します。
AWS、Azure、GCP、OCIへのBYOL化: オラクルは、お客様が既存のオンプレミスライセンスを承認されたクラウドプラットフォームで使用できるようにしており、これがBYOLの本質です。AWS、Microsoft Azure、Google Cloud Platform(GCP)、そしてもちろんOracle Cloud Infrastructure(OCI)は、オラクルのポリシーでは「認定クラウド環境」とみなされます。オラクルは、インフラストラクチャが仮想化されているため、これらの環境でのライセンスのカウントに関するルールを公開しています。主なルールは次のとおりです。

• オラクルのプロセッサ・コア・ファクターは、 パブリック・クラウドには適用されません。かわりに、Oracleはより単純なvCPUベースのカウントを使用します。Enterprise Edition データベースと AWS/Azure/GCP 上のほとんどのミドルウェアの場合: 2 vCPU = 1 Oracle プロセッサ ライセンス (通常、2 つの vCPU がハイパースレッディングの 1 つの物理コアに対応するため)。クラウド・インスタンスがハイパースレッディングを使用しない場合、1 vCPU = 1 ライセンスです。例: Oracle Database Enterprise Edition を 8 vCPU の AWS EC2 インスタンスで実行する場合、4 つのプロセッサ ライセンス (8 vCPU / 2) が必要です。

• クラウドVM上のStandard Editionデータベースの場合、Oracleは特定のvCPUマッピングも定義します。クラウドの Standard Edition 2 (SE2) は、多くの場合、インスタンスごとに 1 つのライセンスとしてカウントされ、最大 8 個の vCPU がカウントされます (SE2 には技術的な使用制限があるため、2 つのライセンスで最大 16 個の vCPU を使用できます)。実際には、AWS と Azure は SE2 BYOL を 4 vCPU あたりのライセンスが必要であるものとして扱います (SE2 はハイパースレッディングで 16 スレッド = 8 コア = 16 vCPU に制限されているため)。正確なマッピングについては、常に最新のOracleクラウド・ポリシー・ドキュメントを確認してください。

• Oracle Middleware (WebLogic など) も、承認されたクラウドのライセンスあたり 2 vCPU のルールに従います。
ライセンスをクラウドに持ち込む場合は、ライセンスにアクティブなサポートがあることを確認します(オラクルでは、特にパッチやヘルプを受け取りたい場合は、クラウドの使用について最新のサポートが必要です)。また、BYOLは、所有するライセンスの数を超えることはできないことを意味します – Oracle DBの4つのプロセッサライセンスがある場合、複数のクラウドインスタンスを実行する可能性がありますが、任意の時点で使用されているvCPUの合計は、比率に応じてそれらの4つのライセンスに対応する必要があります。ITAMチームの仕事は、クラウドチームがより多くのインスタンスを簡単にスピンアップできるため、そのバランスを抑えることです。

BYOLをクラウドサービスにマッピングする:
一部のクラウド サービスは、BYOL を許可する “管理” オファリングです。たとえば、AWS RDS for Oracle には BYOL オプションがあり、AWS がデータベースを管理しますが、Oracle ライセンスはユーザーが提供します。同様に、Azure には、ライセンスを使用する Azure VM 用の Oracle データベース イメージがあります。Oracle Cloud(OCI)は、ほとんどのデータベース・サービスをBYOLとライセンス・インクルーデッドの2種類で提供しています。OCIのAutonomous DatabaseまたはOracle DBaaSでBYOLを選択した場合、すでにライセンス権限があると仮定すると、サービスからより低いレートで請求されます。
これらのサービスにライセンスをマッピングするには、所有しているエディションとオプションを理解する必要があります。たとえば、Oracle Database Enterprise Editionとパーティション化オプションをオンプレミスで所有している場合は、それらをOCI Autonomous DatabaseにBYOLできますが、パーティショニングを所有していない場合にAutonomous Data Warehouse(デフォルトでパーティショニングを含む)を使用しようとすると、BYOLの下では適切にライセンスされません。
ライセンス込みのクラウドオプション(AWSおよびAzure):
AWS では、BYOL を使用しない場合は、Amazon の RDS Oracle の License Included オプションを使用できます。その場合、RDSインスタンスの時間料金は、Oracleライセンスをカバーしているため(OracleはAWSからカットを取得します)、より高くなります。これは、ライセンスがない場合や、迅速な一時的なデプロイが必要な場合に便利です。ただし、ライセンス込みの料金は、特に安定した使用がある場合、永久ライセンスを所有する場合と比較して、時間の経過とともに高額になる可能性があります。
Microsoft Azure には、ネイティブの Oracle マネージド サービスはありません。通常、Azure にライセンスが含まれるということは、Oracle Marketplace イメージをデプロイすることを意味し、価格にはパートナーを介して Oracle ライセンスがバンドルされる可能性がありますが、Oracle と Microsoft は現在、Azure 上の Oracle Database Service も提供しています (実際には、Azure に接続された Oracle のクラウドに Oracle Autonomous Database をデプロイします)。そのシナリオでは、そのサービスに対してOracleに支払うか(ライセンス込み)、オプションに応じてBYOLを使用します。
OCI Universal Cloud Credits(UCC)は次のように説明している。
オラクルのクラウド購入モデルでは、ユニバーサル・クレジットを使用しており、さまざまなクラウド・サービスを柔軟に利用できます。UCCを使用すると、顧客は特定の支出を約束する場合があります(たとえば、OCIサービスで年間使用できる100,000ドル)。 ライセンスへの影響: Oracle PaaS/IaaSにUCCを使用する場合、多くの場合、サービスがBYOLであるか、ライセンスが含まれているかを選択します。たとえば、Oracle Autonomous Transaction Processingインスタンスは、BYOL (1時間あたりのクレジットコストが少ない)または「License Included」として作成(1時間あたりのクレジットコストが高い)として作成できます。サポート対象のオンプレミス ライセンスの大規模なプールがある場合、BYOL はクラウドの消費コストを削減することで、クラウドでの価値を最大化できます。
そうしないと、ライセンスのレンタル料を支払うために、より多くのUCCを燃やすことになります。UCC自体はオンプレミスライセンスを自動的にカバーするわけではなく、従来のライセンスとは別のものです。ただし、オラクルは、OCIを頻繁に使用すると、オンプレミスのサポートコストを相殺するためのクレジットを獲得できるサポートリワードなどのプログラムを開始しました(これは注目に値します:OCIで1ドルを費やすごとに、サポート料金に対して0.25ドル以上のクレジットを獲得できる場合があります。これは、クラウドの取り込みを誘うプログラムです)。
クラウドでオラクルを管理する際には、 消費量を綿密に追跡します。AWS/Azure BYOL で、各インスタンスをインベントリ内の使用可能なライセンスにマッピングします。OCIで、Oracleのレポート・ツールを使用して、使用しているBYOLのOCPUの数と権限を確認します。
また、オンプレミスとクラウド間でのライセンスの移動には柔軟性がありますが、Oracleはライセンスをクラウドに再割り当てすることを許可していますが、「ダブルディッピング」(たとえば、一度に1回ライセンスをカウントする)しないように注意してください。
通常、Oracle には他のベンダーのように厳密な 30 日間の再割り当てルールはありませんが、ライセンスを一時的に移動する場合は、ドキュメントを用意しておき、そのライセンスがクラウドで使用されている間にオンプレミスの使用が中止されるようにする必要があります。

Oracle SaaSライセンス
オラクルのSoftware-as-a-Service製品(Oracle Fusion Cloud ERP、HCM、CXなど)には、オンプレミス・ソフトウェアとは異なる独自のライセンス・モデルがあります。これらは通常、サブスクリプションベースであり、ホストされた指定ユーザーまたはホストされた従業員のメトリックなどによって測定されます。ITAMにとって、SaaSの管理とは、ユーザー数を管理し、サブスクリプションに含まれるテスト環境を含む何の権利があるかを理解することを意味します。
ホスト型名前付きユーザー・モデル: オラクルのSaaSコンテキストでは、ホスト型名前付きユーザーは、特定の1人の個人がクラウド・サービスにアクセスするためのサブスクリプションです。各ユーザーには、独自のサブスクリプションが必要です。たとえば、50人の従業員がOracle ERP Cloud(財務モジュール)にアクセスする必要がある場合、そのモジュールに対して50のホスト型指定ユーザー・サブスクリプションを購入します。このモデルは、特定のロール (財務、調達、販売など) のみを使用するモジュールで一般的です。通常、ユーザーあたりのコストは従業員ベースのメトリクスよりも高くなりますが、数量を制限します。オラクルは、対話型ユーザーと、統合またはAPIを介して間接的にサービスにアクセスするユーザーの両方を考慮することに注意することが重要です。外部パートナーまたは請負業者がログインする場合、または彼らのアクションがシステム内でトランザクションを引き起こす場合は、彼らもライセンスを取得する必要があります。 落とし穴: アクセスが不要になったユーザーを削除しない – スタッフの変更によりアクティブになっているのに、50人のユーザーに支払いを続けると、オーバーサブスクライブになる可能性があります。もう一つは、アカウントの共有が許可されていると仮定することですが、そうではありません。実際の各人には、固有のユーザーライセンスが必要です(2人が1つのアカウントをジョブシェアする場合でも、それは技術的には規約で許可されていません)。
ホスト型従業員モデル: これは、企業全体のOracle SaaSオファリング、特にHCM(HR)または場合によってはERPコア財務に使用されます。ホストされた従業員メトリックは、前に説明したように、組織内の従業員ごとに請求されます。SaaSサブスクリプションでは、これは多くの場合、従業員あたりの月額価格として現れます。たとえば、Oracle HCM CloudのコアHRの価格は、従業員あたり月額$Xになる場合があります。従業員が 1,000 人の場合は、毎月 1,000 * $Xを支払います。実際にシステムにログインした人数に関係なく、すべての従業員がカウントされます。これは、給与計算や人事システムなど、すべての従業員のデータがOracle Cloudに存在するシナリオを対象としています。 影響: このモデルは、ユーザー管理を簡素化します (名前付きユーザー リストを管理する必要はなく、必要に応じてすべての従業員がシステムを使用できます) が、大規模な組織ではコストがかかる場合があります。Oracleは通常、最低額を設定します(たとえば、従業員が非常に少ない場合でも、最低でも100人または1000人の従業員相当のサブスクリプションが必要になる場合があります)。また、請負業者やアウトソーシングされた人員に注意してください: これらのサブスクリプションに対するオラクルの「従業員」の定義には、多くの場合、システム内で追跡されている人やシステムを使用している人 (直接の給与計算の従業員でなくても) が含まれます。
SaaSオファリングへのモデルの適用: オラクルは、製品に応じてどちらかのモデルを使用する場合があります。

• Oracle HCM Cloud は、多くの場合、従業員ごとにライセンスされます。
• Oracle ERP Cloud モジュールは、財務、調達などのユーザーごと(通常はこれらの部門ユーザーのみがアクセスする必要があるため)ですが、すべてのユーザーのデータに影響を与える場合は、一部の基本要素が従業員ごとである可能性があります。
• Oracle Customer Experience(CX)Cloud (CRM、営業、サービス)は、通常、指名ユーザーごと(システムを使用する営業担当者やエージェントごとなど)です。メトリックの特定のクラウド サービスの説明を常に確認してください。ハイブリッド(たとえば、従業員ごとの基本料金とユーザーごとのアドオンモジュール)を持つことが可能です。

SaaS のテスト環境:
オラクルのSaaSサブスクリプションには、通常、追加料金なしで少なくとも1つの非本番環境が含まれています。通常、サブスクライブすると、Oracleは本番インスタンスと1つのテスト(ステージ)インスタンスをプロビジョニングします。テストインスタンスは、設定の試行、更新のテスト、トレーニングなどを目的としています。通常、生産能力は生産を反映していますが、ライブ使用には適していません。含まれるもの:Fusion Applicationsには1つのテスト環境が標準です。
含まれないもの: 追加の環境 (たとえば、別の開発サンドボックスや統合テスト用の 2 番目のテスト環境) が必要な場合、多くの場合、追加のサブスクリプション コストがかかります。
Oracleでは、オプションの明細項目として追加のテスト環境を提供しています。ITAMは、組織に含まれるテストインスタンスの数を把握し、必要に応じて追加のテストインスタンスの予算を立てるようにする必要があります。また、これらのテスト環境は、本番環境と同じユーザー指標で使用するためのものです。それらに個別のユーザーライセンスは必要ありません。サブスクリプションのユーザーは prod と test の両方を使用できることを前提としています。
もう1つのニュアンス: SaaSの更新と環境 – Oracle Cloudアプリケーションは定期的な更新(四半期ごとなど)を受け取ります。オラクルは、これらの更新をずらして、まずテスト環境に適用し、お客様が新機能を評価できるようにしてから、本番環境に導入します。
そのため、そのテスト環境を持つことが重要です。この目的のためにサービスに含まれています。ただし、含まれているテスト環境には、高可用性やディザスター リカバリーなどが付属していない場合があります。アップタイムの長い非本番環境 (トレーニングやデモ用) が必要な場合、それは別のコストになる可能性があります。
シナリオ例: ある会社が、20人のユーザーに対してOracle ERP Cloud for Financialsをサブスクライブし、さらに500人の従業員に対してOracle HCM Cloudをサブスクライブします。ERP には 20 の指定ユーザー サブスクリプションと HCM の 500 の従業員サブスクリプションがあります。オラクルは、これらのサービスごとに1つの本番インスタンスと1つのテスト・インスタンスを提供します(多くの場合、ERPとHCMは、統合されたFusionスイートの場合、同じ環境に存在します)。
会社が専用のトレーニング環境 (更新テストに使用する 1 つのテスト環境とは別の) が必要であることを決定した場合、追加のテスト環境サブスクリプションを購入する必要があります。これがないと、すべての非運用アクティビティに対して、提供された 1 つのテスト インスタンスを使用する必要があります。ITAMは、SaaSユーザーライセンスの数が実際のユーザー数と一致していることを定期的に確認する必要があります。たとえば、ERP Cloudユーザーのうち15人だけがシステムを積極的に使用している場合、更新時のサブスクリプションを15人に減らすことができるかもしれません(Oracle SaaS契約では、更新時や追加注文の調整が認められていることがよくありますが、中期的な削減は容易ではありません)。逆に、財務ユーザーを 5 人追加した場合、コンプライアンスを維持するためには、さらに 5 つのサブスクリプションを購入する必要があります。
要約すると、Oracle SaaSの場合、他のSaaSと同様に管理します:アクティブなユーザー/従業員を追跡し、オーバーサブスクライブ(多すぎる支払い)またはサブサブスクライブ不足(購入したものよりも多くを使用する)がないことを確認します。そして、そのテスト環境を利用することは、あなたが支払っているものの一部ですが、それはテスト/開発目的のみであり、本番環境のトランザクションではないことを忘れないでください。

Oracle Ordering Documents and Contracts(オラクル・オーダー・ドキュメントおよび契約)
オラクルのライセンスは、技術的なデプロイメントだけでなく、契約によって管理されています。お客様の権利を定義するのは、Oracle Master Agreement(OMA)と注文書(OD)の2つの主要なドキュメントです。これらの契約の階層と内容を理解することは、ITAMにとって不可欠であり、サポート更新がどのように機能するかを知ることも重要です。

Oracle Master Agreement(OMA):
OMAは、お客様とオラクルとの関係に関する一般的な契約条件を定める包括的な契約です。企業がOracleの顧客になると、通常、OMA(または以前はOLSA – Oracle License and Services Agreement)に署名します。
OMAには、定義(「処理者」の意味、「指名ユーザープラス」の意味など)、使用権、制限、オラクルの監査権、責任条項などが含まれています。ルールブックと考えてください。OMA自体には、特定の製品や数量がリストされておらず、汎用的です。多くの場合、特定の領域の添付ファイルまたはスケジュールがあります (サポート ポリシーの添付ファイル、クラウド サービスが含まれている場合はクラウド ポリシーなど)。OMAは、一度導入されると、交換または修正されない限り、通常、今後のすべての注文に対して有効です。

オラクル注文書(OD): 購入(ライセンス取得またはクラウド・サブスクリプション)ごとに、オラクルは注文書を発行します。これは、購入するもの(製品名、指標、数量、その注文に関する特別な条件)を正確にリストアップした取引契約です。たとえば、ODには、Oracle Database Enterprise Editionのプロセッサ・ライセンスが2つと、Diagnostics Packのプロセッサ・ライセンスが2つあり、サポートありで、価格がこれこれの価格設定であると表示されます。OMAは日付で参照されるため、OMAの一般条件が適用されます。
ODは、その取引に関する特定の合意または譲歩が表示される場所です。たとえば、オラクルがソフトウェアを複数の国にデプロイできることに同意した場合、または特別割引や特定の使用制限(「DR使用のみ」または「ビジネスユニットXに限定される」)がODまたは添付の修正に書き込まれます。

契約階層 – OD は OMA に優先します: Oracle の契約構造では、広範な OMA と特定の注文ドキュメントとの間に競合がある場合、その購入には注文ドキュメント (およびその修正) が優先されます。
基本的に、ODは特定の標準用語を上書きできます。たとえば、OMAは、Oracleソフトウェアを使用してサードパーティにサービスを提供できないと述べているかもしれませんが、ODで特定のホスティングユースケースを許可する例外を交渉した可能性があります。そのデプロイメントには、そのOD条項が適用されます。
ODはすべてを変更することはできませんが(通常はOracleのコア保護は残ります)、用語を追加したり明確にしたりすることはできます。 OMA(またはOracleの公式用語集)の「ライセンス定義とルール」セクションを、OD脚注の注記と併せて必ずお読みください。

Oracle Supportの更新について、次のように説明されています。
オラクルのテクニカルサポート(別名:Software Update License & Support)は、新規ライセンス(通常は年間ライセンス料の22%)の必須アドオンであり、毎年更新されます。
ITAMは、サポートに関するいくつかの重要なポイントを知っておく必要があります。

• コストと増加: サポートの初年度は、通常、正味ライセンス料から計算されます。その後の数年間、オラクルはインフレ率の上昇を適用することがよくあります(通常は年間約3〜4%ですが、地域やケースによっては、5%やインデックスにリンクされているなど、より高くなる可能性があります)。上限や凍結を交渉しない限り、支援費用は毎年上昇することが予想されます。ODで複数年のサポート条件や上限を交渉することは可能ですが(たとえば、「3年間サポート価格の引き上げなし」など)、それを書面で取得する必要があります。

• 復活: ライセンスのサポートを失効させ、後で更新する場合、オラクルは失効した期間のサポート料金に加えてペナルティを請求します(これは非常に高額になる可能性があります)。したがって、一般的に、Oracleライセンスを所有すると、サポートの支払いを続けるか、特定のバージョンでそれらのライセンスが凍結されたと考えます。コストを節約するためにサポートをやめるのは、アップグレードやサポートが必要な場合、再加入には費用がかかるため、リスクが伴います。

• 簡単に部分的なキャンセルができない: オラクルのサポートポリシーには、「価格改定」と呼ばれる概念があります。ライセンスの一部をサポートから削除し、他のライセンスは保持しようとした場合、オラクルは残りのサポートの価格を現在の定価で再設定する権利を留保します。たとえば、100 個のライセンスを持っていたが、そのうち 20 個のライセンスでサポートを終了し、80 個を保持するとします。オラクルは、残りの80のサポートに対する割引を削除する可能性があり、節約の多くが事実上無効になります。これは、お客様が使用頻度の低いライセンスのサポートをトリミングするのを防ぐためです。その結果、多くのお客様は、すべてのライセンスをサポート対象のままにするか、または本当に一部のライセンスが必要ない場合は、それらのライセンスを完全に終了します(ライセンスの使用権と将来の更新を放棄します)。

• サポート更新プロセス: オラクルは毎年更新見積を送信します。ITAMは、更新の数量と製品が展開され必要なものと一致していることを相互検証する必要があります。使用されていない古いライセンスがまだサポートされていることは珍しくありません – それらは終了の候補になる可能性があります (本当に必要ない場合、および今後それらを使用しないことを受け入れることができる場合)。ただし、割引バンドルの一部であった場合の価格改定については、上記の点を覚えておいてください。

• Oracle Master Agreementおよびサポート: OMAは、サポート条件をオラクルのテクニカル・サポート・ポリシー・ドキュメントに拘束します。この文書(オラクルのWebサイトで定期的に更新)には、オラクルがどのようにサポートを提供するか、製品がプレミアからエクステンデッド、サステイニングサポートに移行する場合などについて詳しく説明しています。ITAMは、主要なサポートタイムラインの問題に注意する必要があります(たとえば、「データベースバージョンは来年プレミアサポートから除外されます。拡張サポートにアップグレードしたり、追加料金を支払う必要がありますか?」など)。

• クラウド・サブスクリプションのサポート: Oracle SaaSまたはCloudでは、通常、サポートはサブスクリプション価格に含まれています(個別のサポート項目はなく、Oracle Cloudサポートとしてバンドルされています)。そのため、サポートの更新は、主にオンプレミスライセンスまたはOracle Cloud@Customerサブスクリプションに関係します。
シナリオ例(サポート): ABC社は、5年前に購入したOracle Databaseライセンスを持っています。彼らはサポートを支払っており、それは$100kライセンス(22%)で年間22kドルから始まりました。2025年までに、年間わずかな増加で、おそらく彼らは年間約26kドルを支払っているでしょう。ABCがコスト削減のために2026年にサポートを更新しないことを決定し、その後2027年に重要なパッチまたはアップグレードが必要になった場合、オラクルは2026年の料金と150%のペナルティなど、つまり、おそらく26,000ドル+39,000ドル=65,000ドルの回復を要求し、その後、再び継続的なサポートを要求する可能性があります。明らかに、将来の使用が予想される場合は、サポートを維持する方がよいでしょう。あるいは、一部の企業は、サポートがサステイニングモードに移行した後で、コストを削減するためにサードパーティのサポートプロバイダーを検討します(オラクルの直接サポートやアップグレードがないというトレードオフがあります)。

契約管理のベストプラクティス: すべてのOracle Ordering Documentsと修正のリポジトリを常に保持します。これらの文書は、監査の最終段階です。オラクルの監査人は、デプロイした内容(データベースのプロセッサ4つ、EBSの100ユーザーなど)とODが所有していると主張するものを比較します。特別な用語を理解していることを確認してください:たとえば、一部のODは特定の国またはエンティティに使用を制限している場合があります。あなたの会社が再編成され、新しい子会社でオラクルを使用したい場合は、契約の更新が必要かどうかを確認してください。また、リストされているライセンス メトリックも確認してください。OD の脚注に “Named User Plus, minimum 25 per Processor” のような文言が表示されることがあります。使用量が一致していることを確認してください。不明な点がある場合は、オラクルに書面で説明を求めることができます(できれば監査中ではなく、契約交渉中に)。
最後に、オラクルの契約には通常、オラクル契約の条件が、お客様側の発注書やその他の文書の矛盾する条件に優先すると記載されていることに注意してください。したがって、調達チームが「XYZの権利を想定する」などのものをPOに入れた場合、Oracleが承認しない限り、それは保持されない可能性があります。OMA、OD、および公式の修正のみがカウントされます。

エンジニアリングシステム&Cloud@Customer
オラクルのエンジニアド・システム(Exadata、Oracle Database Applianceなど)およびCloud@Customer製品では、ライセンスに関する特別な考慮事項が導入されています。これらは、Oracle が提供するハードウェア、または Oracle ソフトウェアを最適に実行するように設計された管理対象システムです。ITAMは、これらのシステム上の従来のライセンスまたはオラクルのサブスクリプションモデルを介してライセンスを管理する必要があります。

Exadataのライセンス(オンプレミス):
Oracle Exadataは、独自のコンピュート・ノードとストレージ・ノードを備えた高パフォーマンスのデータベース・マシンです。オンプレミス用にExadataを購入する場合は、ハードウェアを購入(またはリース)し、そのハードウェア上で実行されるOracleソフトウェア(データベース、オプションなど)のライセンスを個別に取得する必要があります。Exadataマシンには多くのコアがあります – たとえば、Exadataラックにはノードあたり数十のCPUコアがあり、複数のノードがある場合があります。オラクルは、キャパシティ・オン・デマンド(CoD)ライセンスでコストの課題に対処します。CoD では、特定の数のコアを無効にし、残りのアクティブなコアのみにライセンスを付与できます。たとえば、Exadataに64個のコアが使用可能であるが、32コア相当のDBライセンスの予算しかない場合、Oracleにリクエストして(またはソフトウェアを使用して自分で行う)、コアの半分を非アクティブ化できます。
その後、32 個のアクティブ コアのみにライセンスを付与する必要があります。これにより、小規模から始めて、後で追加のライセンスを購入するときにより多くのコアを有効にすることができます。コアを有効にすると、すぐにライセンスを取得することが期待されます – 追加の電力のためにコアを一時的にオンにして、それらに対して支払わないようにすることはできません。オラクルは通常、特定の時間にCoDの変更を許可します(そして、コアを有効にすることは、ライセンス義務の観点からは一方通行です)。
ITAMの観点からは、各Exadataで有効になっているコアの数を文書化し、監査人がこれをライセンスと照合します。また、Exadata環境内では、すべて同じデータベース・ライセンス・ルール(プロセッサ・メトリック、オプション・ライセンス、NUPの最小値(該当する場合))が引き続き適用されます。
よくある間違いの1つは、Exadataで一部の機能が無料であると思い込むことです。たとえば、Exadataはマシンに付属していますが、RAC(Real Application Clusters)やパーティショニングなどのオプションを使用する場合は、Oracle契約またはExadataが特定のオプションを明示的にバンドルしていない限り、それらを使用する場合はライセンスが必要です。

Exadata Cloud@Customer (ExaCC): これは、オラクルがデータセンターにExadataをインストールするサービスですが、クラウドサービスとして消費されます。ExaCCのライセンスには、次の2つの方法でアプローチできます。

• BYOLモデル: Oracle Databaseライセンスをすでに所有している(およびサポートを支払っている)場合は、これらをExadata Cloud@Customerに適用できます。サブスクリプションでは、Oracleは、ソフトウェア・ライセンスの権限を持参した場合に、インフラストラクチャと管理に対してより低い金額を請求します。これにより、既存のライセンスが効果的に活用され、Oracleがハードウェア/更新を管理できるようになります。

• ライセンス込みモデル: 独自のライセンスを使用しない場合、オラクルはデータベースライセンスをCloud@Customerサブスクリプション料金に含めます(通常は「Enterprise Edition Extreme Performance」ライセンスが含まれていますなど)。この料金は、ExaCCでOracleソフトウェアを使用する権利をカバーしているため、高くなります。オラクルのUniversal Cloud Creditsは、これらのサブスクリプションに使用でき、ハードウェア・サービスとデータベース・ソフトウェアの使用の両方をカバーするクレジットをコミットします。
Cloud@Customer では、サブスクリプションであるため、コアをカウントする概念が少し異なります。特定の構成をサブスクライブします(例: 32 OCPUが有効になっているExadata)。BYOL の場合、コンプライアンスを維持するためには、プール内に少なくともその数のプロセッサ ライセンスを所有している必要があります。ライセンスが含まれている場合は、所有する必要はありません – オラクルは基本的にサービスの一部としてライセンスをレンタルしています。ExaCCにライセンスが含まれている利点の1つは、Oracleがサービス階層に応じてすべてのデータベースオプション(RAC、マルチテナント、インメモリなど)をバンドルできるため、これらのオプションを個別に購入しなくてもフル機能セットを取得できることです。

その他のエンジニアド・システム: Oracle Database Appliance(ODA)は小規模なエンジニアド・システムであり、ODAのライセンスは簡単で、オンプレミス・ボックスであり、標準ライセンスを使用できます。また、キャパシティ・オン・デマンドもサポートしています (コアを制限できます)。
Oracle ZFS StorageまたはRecovery Appliancesは、通常、レプリケーションソフトウェアなどを除き、個別のソフトウェアライセンスを含みません。オラクルがエンジニアリングされたシステムに特別なライセンスを提供したかどうかを常に確認してください – オラクルは、ハードウェアと一緒に限定使用ライセンスを販売しました (たとえば、そのマシンに限定された「データベースアプライアンスバンドル」ライセンス)。
ライセンス割り当てモデル: この用語は、多くの場合、ハードウェアまたはユーザーにライセンスを指定する方法を指します。エンジニアリング システムおよびCloud@Customerでは、BYOL を使用している場合は、ライセンスのセットをそのシステムに効果的に “割り当てる” ことができます。Oracleは、一度割り当てられたライセンスは、そのシステム(または環境)に関連付けられたままで、他の場所で同時に使用されないことを想定しています。
これを内部で文書化する必要があります(例:「この日付の時点で、Oracle DB Enterprise Editionの50プロセッサ・ライセンスがExadataマシンXYZに割り当てられています」)。動的なクラウドのようなシナリオでは、これらのライセンスを後で再利用する予定がある場合 (ExaCC から移行するなど) は、 二重使用を避けるために、再利用する前に ExaCC での使用を終了してください。
例: ある会社では、Oracle Database Enterprise Edition のプロセッサ ライセンスが 100 件サポートされています。50 OCPUのExadata Cloud@Customerをサブスクライブします。彼らはコストを節約するためにBYOLを選択しています。次に、100のライセンスのうち50をそのExaCCに割り当てます。
Oracleの契約では、通常、ExaCCで使用している間、これらのライセンスのサポートを維持する必要があることが記載されています。一方、他のオンプレミスシステム用に50のライセンスが残っています。ITAMは、すべてのシステム(オンプレミスおよびExaCC)へのデプロイの合計が、常に100ライセンス相当のプロセッサを超えないようにする必要があります。後でフルクラウドを含めることを決定した場合、それらのライセンスを他の場所で再利用するか、場合によってはギブバックを交渉することができます。
エンジニアリング・システムと監査: 監査人は、コア数が多いため、Exadataデプロイメントに重点を置くことがよくあります。有効にされたコアの数と、それらに十分なライセンスがあることが表示されるように準備してください。ExaCCなどのOracle Cloudサービスを使用する場合は、BYOLか含まれているかの書類を管理してください。Oracleはこれらの詳細を知っていますが、実際にサブスクリプションを利用しているときにライセンスが必要だと誤って考えないように、整合性を確保する必要があります(またはその逆も同様です)。

ライセンスの移行と割り当て
「ライセンス移行」と「ライセンス譲渡」は、組織変更や契約変更の際に出てくる用語です。これらは、異なるメトリック、製品、またはエンティティ間でライセンスを移動することを指します。
オラクルの契約に準拠するためには、これらを適切に処理することが重要です。
ライセンスの移行 (ライセンスの変換): これは通常、ライセンスの種類または範囲を変更することを意味します。
例：

• メトリックの移行: Named User Plus ライセンスから Processor ライセンスへの (またはその逆) 変換。オラクル社では、換算率をネゴシエートする場合、これを許可する場合があります。たとえば、最初にデータベース用に100 NUPを購入し、後でプロセッサモデルの方が適していると判断した場合(ユーザー数が爆発的に増加した可能性がある)、Oracleは、契約修正を通じて、これらの100 NUPをたとえば2つのプロセッサライセンス(単なる比率の例)に変換することを許可する場合があります。これは通常無料ではありません – オラクルは、既存のライセンスにいくらかのクレジットを付けた新規購入として扱う場合があります。

• エディションまたは製品の移行: 製品のアップグレードまたはスワップ (Oracle Database Standard Edition ライセンスから Enterprise Edition ライセンスへの移行など)。オラクルにはガイドラインがあります(多くの場合、基本的にコストの差額を購入します)。または、Oracle が製品をマージしたときに、古い Oracle Internet Application Server ライセンスから WebLogic Suite ライセンスに移行します。

• オンプレミスからクラウドへの移行: オラクルは、オンプレミス・ライセンスの価値をクラウド・サブスクリプションに適用するプログラムを導入しました。たとえば、オラクルの「Bring Your Own License」は簡単に使用できますが、一部のお客様は、Oracle Cloudサービスの割引と引き換えに、特定のオンプレミスライセンスを終了するように交渉します。別のシナリオは、無制限ライセンス契約(ULA)で、ULAの終了時に使用が証明され、それが永久ライセンスになります。その後、クラウドに移行すると、それらをクラウド契約に「移行」し、クラウドクレジットの永続ライセンスを事実上放棄する可能性があります。これらは、オラクルの関与を必要とする複雑な取引です。
ライセンスの割り当て (別のエンティティへの転送):
オラクルのライセンスは、通常、 オラクルの同意なしに譲渡することはできません。つまり、あなたの会社(Alpha Corpと呼びましょう)がOracleのライセンスを所有していて、企業イベント(合併、買収、売却)がある場合、Oracleが同意しない限り、それらのライセンスを別の会社や場合によっては別の子会社に渡すことはできません。

• 内部転送: 再編成を行い、同じ企業ファミリー内の子会社から別の子会社にライセンスを移動したい場合、オラクルは通常それを許可しますが、割り当てレターを通じて文書化することを好みます。通常、ライセンスは同じ OMA の下に残りますが、新しいエンティティの名前で承認されたユーザーとして記載されます。ソフトウェアを使用して法人を変更する場合 (たとえば、スピンオフ後に Alpha Corp から新しい法人 Beta Corp に業務が移行する場合) は、Oracle が関与していることを確認してください。

• 合併/買収:他の会社があなたのライセンスを買収した場合、通常、存続する事業体がライセンスを使用できます(Oracleの契約では、ライセンシーの完全な買収/合併の場合に譲渡が認められていることがよくあります)。ただし、会社が別の会社を買収している場合、そのOracleライセンスは自動的にプールに「参加」しません。これらは、オラクルがお客様の契約に基づいてそれらを統合または譲渡することに同意しない限り、買収された事業体に残ります。簡単に言うと、A社がB社を買収した場合、B社のOracleライセンスは、Oracleが割り当て/更改を承認しない限り、A社の他の部門が自由に使用することはできません。多くの場合、企業はライセンスを別々に使用し続けるか、エンタイトルメントを組み合わせるために新しい契約を交渉します。

• 売却: 会社の部門を他の誰かに売却し、その部門がOracleソフトウェアを使用している場合、通常、Oracleの承認なしに、売却の一部としてそれらのライセンスを買い手に譲渡することはできません。Oracleは、新しい会社に新しいOMAに署名するように要求する場合があり、必要なライセンスを新しい会社に転送するためのライセンス割当契約に署名します。オラクルは、転送手数料を請求するか、コンプライアンスの問題を修正する機会として使用する場合があります。
契約上のトリガー:
OMA の割り当て条項を常に確認してください。通常、オラクルの同意なしに契約またはライセンスを第三者に譲渡することはできないとされていますが、これは会社全体の合併または買収の一部である場合を除きます。これは基本的に、説明されたことを体系化しています。
したがって、Oracleの関与が必要なトリガーには、次のようなものがあります。

• ビジネスユニットを売却したり、オラクルを運営するプロバイダーに機能をアウトソーシングしたりすることは、割り当てや少なくとも書面による例外が必要な場合があります(または、ASFU/ホスティング契約が必要な場合もあります)。
• 別々のOracle契約を結んでいたコングロマリット内のエンティティを統合する場合、1つのOMAに統合したい場合があります。オラクルは、契約更新を通じてそれを支援します。

• アーキテクチャの変更により、あるライセンス指標から別のライセンス指標に切り替える(例:仮想化し、ユーザーライセンスではなくプロセッサライセンスに移行したい場合)。コンバージョンを交渉します。

• 下取りで1つのOracle製品を別のOracle製品に置き換える – 古いOracle製品から新しい製品(Hyperion On-PremからOracle EPM Cloudなど)に移行すると、Oracleは古いライセンスをクレジットする場合があります。これは、ある製品ラインから別の製品ラインへのライセンス移行の一形態です。

実例(課題):
あなたの会社が 2 つの独立した会社に分割されると想像してください。元の会社名で 50 の Oracle データベース ライセンスがあります。ここで、A社とB社の両方がOracleを使用する必要があります。Oracleは、2つのうちの1つ(たとえばB社)が独自のライセンスを調達することを要求する可能性があります。
超過した場合、オラクルは、譲渡書類(基本的には、XライセンスがB社の下に存在し、元の契約のすべての条件が拘束力を持つことを示す契約)を通じて、一部をB社に譲渡することに同意する可能性があります。処理しない場合、B社がA社のライセンスでOracleを使用することは非準拠になります(B社は契約のライセンシーではありません)。

記録を保持する:
ライセンスの移行または割り当てが発生した場合は、それを承認するOracleからのすべての通信とドキュメントを保管してください。監査時やライセンスの調整時には、例えば、「これらの10社のプロセッサライセンスはもともと契約ABCに基づいていたが、Oracleの日付の書簡に従って契約XYZに基づいて子会社に割り当てられていた」ことを示す必要があります。また、メトリックの変更を反映するように内部ライセンス インベントリを更新します (100 NUP を 4 プロセッサに変換した場合、NUP カウントを廃止して新しいプロセッサ カウントを表示するなど)。
要するに、ライセンスを購入した組織に関連付けられた法的資産として扱います。その組織が形態を変更したり、ライセンスの使用方法を変更する必要がある場合は、Oracleを関与させ、文書化してください。これにより、ライセンスを不適切に使用しているというオラクル社からの後の主張を回避できます。

Oracle ライセンスの管理
オラクルのライセンス管理は、技術的な追跡と契約上の認識を組み合わせた継続的なプロセスです。このセクションでは、オラクル独自の監査スクリプトの使用、サードパーティのSAMツール、特にハイブリッドクラウド環境でのライセンス追跡戦略など、ツールとプラクティスについて説明します。
Oracle LMS収集スクリプト: オラクルのライセンス管理サービス(LMS)は、特別なスクリプトを使用して顧客の使用状況を監査します。これらのスクリプト(Oracle Collection ToolまたはLMSスクリプトと呼ばれることが多い)は、システムから詳細なデータを収集します。

• Oracle Databaseの場合、スクリプトは通常、データベースにクエリを実行して、インストールされているオプションとパック、機能の使用統計、ユーザー数、スキーマ情報などを一覧表示し、サーバーのOracleバイナリとCPU情報もスキャンします。パーティション分割、Advanced Compression、Tuning Packなどが使用されているかどうかは、DBA_FEATURE_USAGE_STATISTICSなどのビューを確認することで検出できます。また、ホスト名、プロセッサ数、およびその他の環境の詳細も収集します。

• ミドルウェア(WebLogic、Oracle Application Server)の場合、スクリプトは構成ファイル、ドメイン情報、JVMが実行されているコア数などを収集し、WebLogicインスタンスが実行されているかどうか、およびどのエディション/機能(たとえば、JMSまたはMQの使用)が別のライセンスが必要であるかを確認します。

• アプリケーションの場合、Oracle はスクリプトではなく、データ抽出 (EBS からのユーザーリストやモジュールのアクティベーション情報など) を使用する場合があります。

• Javaの場合(必要な場合)、OracleにはOracle JDKの使用状況をスキャンするための別のツールがあります。
これらの LMS スクリプトは、多くの場合、監査中に提供されますが、お客様は積極的に自己評価を依頼することもできます。それらを内部で(制御された方法で)実行すると、ライセンスのないものを誤って使用しているかどうかが明らかになります。たとえば、Oracle DBの「Advanced Security」暗号化機能が使用されていることを示している場合がありますが、別のライセンスが必要であることに気づかなかったことがあります。ITAMチームは、DBAと協力して、Oracleの使用状況クエリを定期的に実行する必要があります(Oracleには、dba_feature_usage_statistics、v$optionなどの組み込みビューもあり、DBAはいつでもどの機能がオンになっているかを確認できます)。LMSスクリプトは、権限に応じて解釈が必要な生データを出力します – オラクルは公式の監査レポートでその解釈を行います。内部的には、正しく解析するための専門知識が必要になる場合があります。
スクリプトがキャプチャするもの: 基本的に、デプロイされたものとライセンスされたものを比較するために必要なすべてのもの:

• ホスト識別子とインスタンス識別子 (Oracle が個別のインストールをカウントできるようにするため)。
• ソフトウェアのエディション(StandardとEnterpriseなど)。
• 使用されるオプション/パック(多くの場合、Oracle Enterprise Managerを介してOracle Diagnostics Packを使用するには、そのパックのライセンスが必要です)。
• ユーザー数 (アプリまたはデータベースの名前付きユーザー数の場合 – ただし、これを “名前付きユーザー” にマッピングするには、どのアカウントがスキーマまたは実際のエンドユーザーであるかを知る必要があります)。
• 仮想化されたセットアップでは、スクリプトはハイパーバイザーの手がかり(VMwareツールの存在や特定のデバイスシグネチャなど)をキャプチャでき、Oracleはそれを使用して環境のスコープについてさらに問い合わせることができます。
サードパーティのSAMツールと制限:
多くの組織では、Oracle ライセンス管理モジュールを備えたソフトウェア資産管理ツール (Flexera、Snow、ServiceNow SAM など) を使用しています。これらのツールは、Oracle のインストールを自動的に検出し、場合によってはデータベースに接続して使用状況データを取得できます。これらは継続的な監視に非常に役立ちますが、制限があります。

• 正確性と完全性: オラクルのライセンスルールは、微妙すぎる場合があります。たとえば、SAM ツールが Oracle データベースを検出し、10 個のインストールをカウントする場合があります。ただし、これらの 10 個が、すべてのホストのライセンスが必要な VMware クラスタの一部であることが適切に説明されていない可能性があります。このようなコンテキストは、手動入力なしでは見逃される可能性があります。

• オプション検出: 一部のツールでは、すべての Oracle オプションの使用が完全に検出されないか、誤検出/否定がスローされる場合があります。Oracle 独自のスクリプトは監査中に「信頼できる情報源」と見なされるため、SAM ツールで「パーティション分割オプションを使用しない」と表示されていても、Oracle のスクリプトがどこかでパーティション化されたテーブルを見つけた場合、Oracle はその証拠を使用します。

• ユーザーベースのライセンス追跡: Named User PlusまたはApplication Userライセンスの場合、SAMツールはシステム内のユーザーアカウントの数を一覧表示できますが、最小数や2つのアカウントが1人のユーザー(適切に文書化されている場合は1人の名前付きユーザー)に属しているかどうかなどのライセンスルールはわかりません。ユーザーリストをクリーンアップするには、人間による分析が必要です(たとえば、人間のユーザーではないサービスアカウントを除外します – オラクルは通常、それが本当に人間以外の操作である場合に許可します)。

• ライセンス・ルールの更新: Oracleがポリシー(クラウドvCPUのカウント方法など)を変更し、SAMツールのロジックが更新されないと遅れて、クラウド・デプロイメントの計算ミスにつながる可能性があります。
制限はありますが、SAMツールはインベントリを取得し、潜在的な問題を強調するのに役立ちます。これらを使用して、Oracle製品がインストールされている場所にフラグを立てたり、基本的な使用状況メトリックを収集したり、コンプライアンス・チェックをシミュレートしたりします。ただし、重要な検出結果は常に手動またはオラクルのクエリを使用して検証します。
また、オラクルは、SAMツールからの出力を公式の監査で決定的なものとして受け入れません – 彼らは独自のプロセスを主張します – しかし、あなたが内部でSAMプラクティスを持っていることを示すことは、時にはあなたの勤勉さを示すことができ、監査の頻度を減らす可能性があります。
クラウドでのBYOLデプロイメントの追跡: 新たな課題の1つは、動的なクラウド環境でのライセンスの追跡です。たとえば、開発チームが短期間のプロジェクトのためにAWSでOracleデータベースをスピンアップする場合、BYOLを選択した場合、ライセンスの1つがそれをカバーしていると主張していることになります。ITAMは利用可能なライセンス数を見つけて減らしますか?これを管理するには、次のようにします。

• ガバナンス・プロセス: クラウド運用と連携してチェックリストを実装する: Oracle AMIまたはサービスが起動されるたびに、BYOLが選択されている場合は承認を受ける必要があります。AWS の AWS License Manager サービスを使用すると、AWS License Manager で Oracle ライセンスのプールを定義でき、プールで許可されている (または少なくともレポートする) よりも多くのインスタンスの起動を防ぐことができます。

• タグ付け: 「Oracle-License-ID」や「BYOL-used」などのタグをクラウドリソースに付けて、OracleインスタンスのクラウドアカウントをスキャンしてBYOLかどうかを確認できるようにします。

• 定期的な監査: クラウドアカウント(AWS、Azure、GCP)で、Oracleソフトウェアの使用状況を定期的に監査します。これには、AWS で Oracle RDS インスタンス (ライセンスが含まれている場合または BYOL の場合あり) の確認、Azure で使用中の Oracle データベース イメージの確認、そしてもちろん Oracle Cloud を使用している場合は OCI の使用状況を確認することが含まれます。オンプレミスの使用量と比較し、合計がエンタイトルメントと一致していることを確認します。

• クラウドからオンプレミスへの相乗効果: ワークロードをオンプレミスからクラウドに (BYOL を使用して) 移動する場合は、レコードを更新して、それらのライセンスがクラウドに割り当てられ、オンプレミスで解放された可能性があることを示します (オンプレミスの使用量を廃止したと仮定します)。また、クラウドを本国に送還またはスケールダウンする場合は、その逆も同様で、誤ってライセンスを2回カウントしないように注意してください。
LMSスクリプトを内部と外部で使用する: 一部の組織は、正式な監査の外部でOracleのLMSツール自体(おそらくOracle LMSまたはサードパーティのOracleライセンススペシャリストの助けを借りて)を実行することにより、「友好的な監査」を行っています。これは、問題を早期に発見するための良い方法です。不足が見つかった場合は、オラクルがノックする前に、追加のライセンスを購入するか、使用量を調整することで対処できます。必要なライセンスについてOracleに積極的にアプローチする方が、監査に巻き込まれて罰金を支払うよりもはるかに優れています。
トレーニングと知識: 技術チーム(DBA、システム管理者、クラウド・アーキテクト)がオラクルのライセンス・トリガーを認識していることを確認します。たとえば、DBAは、Enterprise ManagerでOracleのチューニングパックを有効にするのは無料ではなく、ライセンスが必要であることを知っておく必要があります。クラウド アーキテクトは、Oracle EE データベースを 16 vCPU の Azure VM にデプロイするには 8 つのプロセッサ ライセンスが必要であることを知っておく必要があります。この認識は、偶発的なコンプライアンス違反を防ぐのに役立ちます。
要約すると、オラクルのライセンス管理は、テクノロジーの追跡と契約管理の一部です。自由に使えるツールを使用しますが、常にオラクルの公式ルールと特定の契約条件をオーバーレイします。定期的な内部レビュー、Oracleエントリを含む優れたCMDBまたはSAMデータベース、ITAMとDB/クラウドチーム間のオープンなコミュニケーションラインは、コンプライアンスを維持し、ライセンス使用を最適化するのに大いに役立ちます。

Oracleソフトウェアの購入方法
Oracleソフトウェアの入手方法は、価格設定とコンプライアンスに関する考慮事項に影響を与える可能性があります。オラクルの販売モデルには、直接販売だけでなく、認定再販業者のネットワークも含まれています。
さらに、特殊なシナリオでは、オラクルはパートナー(ESL、ASFU、PAH)を通じて組み込みライセンスまたは制限付きライセンスを提供しています。ITAMの実務家は、これらの調達ルートとその影響を理解する必要があります。
直接購入と再販業者を通じての購入:

• オラクルから直接購入する場合は、オラクルの営業担当者と価格と条件を交渉します。オラクルには公式の価格表(非常に高い定価)がありますが、一般的には割引が適用されます。取引の規模、関係性、タイミング(四半期末のプレッシャー)がディスカウントに影響を与える可能性があります。直接取引では、非標準的な条件を交渉する余地が広がります(オラクルは、大規模な直接取引に対して契約の変更や特別な譲歩をより容易に承認できるため)。

• リセラーまたはオラクル・パートナーを通じて購入する場合、パートナーは基本的にオラクル・ライセンスを、多くの場合、事前に合意した割引で再販します。オラクル社は引き続きオーダー・ドキュメントを発行します(お客様をエンド・カスタマーとして指定します)が、販売はパートナーを通じて予約されます。パートナーは、顧客に約30%の標準割引を提供する場合がありますが、この数字は異なる場合がありますが、一般的なベンチマークです。舞台裏では、オラクルがリセラーにおそらく40〜50%オフのリスト(パートナーレベルによって異なります)で販売し、リセラーはその一部(たとえば20〜30%)をあなたに渡します。残りはマージンとして保持されます。多くの日常的な購入では、リセラーを利用することで調達を簡素化できます(特に、パートナーが優先サプライヤーリストまたは政府の調達フレームワークに含まれている場合)。

• どちらを選ぶべきですか? 大幅な割引やカスタム条件が必要な場合は、直接の方が良いかもしれません – オラクルは戦略的な取引のために価格をさらに引き上げることをいとわないかもしれません。ただし、オラクルのチャネルパートナーは、インセンティブがあるため、小規模な取引に対して同等またはそれ以上の割引を提供できる場合があります。また、優れた再販業者は、コンサルティングサービスをバンドルしたり、取引の一部としてライセンスアドバイザリーを提供したりできます。
1つの注意点:リセラーがOracleのライセンスをよく理解していることを確認してください。パートナーがOracleライセンスを誤って販売したケース(メトリックが間違っている、数量が不十分)がありますが、コンプライアンスの責任は依然として顧客にあります。

リセラーからの購入とサポート:
リセラー経由で購入する場合でも、通常、サポート契約はオラクル社と直接締結されます。オラクルからサポート更新通知を受け取り、オラクルに支払うか、場合によってはリセラーを通じて支払うかを選択できます。
ライセンスの条件(OMA/OD)は、リセラーの条件ではなく、Oracleの標準条件のままです。したがって、コンプライアンスの観点からは、直接購入するのとほぼ同じです-商業割引のルートが異なるだけです。
ISVおよびオラクル組み込みライセンス(ESL、ASFU、PAH): オラクルは、オラクルのテクノロジーを自社の製品やサービスに組み込む独立系ソフトウェアベンダー(ISV)またはソリューションプロバイダー向けの特別なプログラムを用意しています。

• 組み込みソフトウェアライセンス(ESL): これは、ISVがソフトウェアにバンドルできる非常に制限されたライセンスです。Oracle ソフトウェア (Oracle Database など) は、ISV のアプリケーションの背後に完全に隠されています。エンドユーザーは通常、オラクルのソフトウェアを直接操作することさえしません。ESLライセンスは、通常、Oracleがボリュームを期待し、ISVが主要なサポートを提供するため、リストから大幅に割引されます。エンド・ユーザーは、ISVのアプリケーションの実行以外の目的でOracleソフトウェアを使用することはできません。たとえば、ヘルスケアソフトウェアベンダーは、Oracle Databaseを自社の製品に埋め込む場合があります。ソリューションを購入した病院は、その一部としてOracle DBを取得しますが、そのDBをカスタムアプリケーションに使用する権利や、ベンダーのアプリの外部でSQLクエリを実行する権利はありません。

• 特定用途向けフルユース (ASFU): ESL よりも制限が若干緩和されています。ここでは、Oracle ソフトウェアは、名前付きアプリケーション (ISV アプリや Oracle 独自のアプリの特定の使用法) と組み合わせて使用されます。お客様は、Oracle ライセンスを所有していることを認識していますが、契約上、指定されたアプリケーションでのみ使用するように関連付けられています。たとえば、SAPはこれまで、OracleデータベースライセンスをASFUとして販売し、SAPのソフトウェアでのみ使用していました。お客様はデータベースを直接管理できますが、そこに存在できるのは SAP アプリケーションのデータのみです。ASFUライセンスもフルユースと比較して割引されており、通常、ベンダーまたはリセラーがサポートを提供します(少なくとも第一線)。

• プロプライエタリ・アプリケーション・ホスティング(PAH): ホスティング・ライセンスとも呼ばれるこのモデルは、エンド・カスタマー向けのOracleベースのアプリケーションをホストするサービス・プロバイダ向けです。オラクルは、パートナーがオラクルソフトウェアのライセンスを取得して、それをサービス(オラクル独自のクラウドではなく、パートナーのサービス)として提供することを許可します。たとえば、ある企業が独自のソフトウェアを持っていて、それをOracleデータベース上で実行される複数のクライアントにSaaSとして提供したい場合、そのマルチテナントの使用を法的に許可するPAHライセンスを取得することになります。PAHがない場合、通常のOracleライセンスは内部使用のみを目的としており、外部クライアントへのサービス提供には使用できません。PAH契約では通常、パートナーが使用状況を報告する必要があり、場合によっては異なる価格設定スキーム(使用状況の月次レポート、またはホスティングに含まれるものの制限)があります。

これらのモデルの制限:
お客様にとっての主な制限は、柔軟性の欠如です。ベンダーを通じてESLまたはASFU Oracleライセンスをお持ちの場合、それを他の目的に使用することはできません。使用量を拡大する場合、またはベンダーの範囲外でアップグレードを行う場合は、完全なOracleライセンスを購入する必要があります。
また、これらのサポートは通常、オラクルが直接行うのではなく、ISVまたはパートナーによって提供されます。オラクルサポートに自分で電話することはできません(オラクルがベンダーに紹介します)。これは、ISV が倒産した場合や、パッチの提供が遅い場合にリスクになる可能性があります。法的には、使用上の制約に違反した場合 (たとえば、ASFU ライセンスの Oracle DB を別のアプリケーションに使用する場合)、Oracle のコンプライアンスに違反していることになります。
ITAMの観点からは、 これらのライセンスを個別に追跡します。多くの場合、Oracleサポートの更新には表示されません(サポートがISVを通じてバンドルされている場合)。また、オラクルの監査では、オラクルがISVを通じてオラクル製品があるかどうかを尋ねることがあります。これは、ISVは、スコープを超えて使用していないことを確認したいと考えています。
そのような使用が適切なASFU/ESLライセンスでカバーされているという契約または証拠を示す準備をしてください。インベントリ内のこれらのインストールにベンダー名とライセンスタイプをタグ付けし、技術チームがそのインスタンスを他のタスクに再利用しないように認識するようにすることをお勧めします。
シナリオ例: 組織では、ドキュメント管理にサードパーティ製ソフトウェアを使用しており、そのソフトウェアには内部にOracle Databaseが含まれています。ベンダーは、「Oracle Database Standard Edition 2 – XYZ DocumentManagement Appでのみ使用制限付き」のOracle ASFUライセンスを提供しました。ここで、ある IT 管理者が Oracle データベースがあることに気付き、その中に別の内部アプリ用に追加のスキーマを作成しようとしたとします。これはライセンス条項に違反します。それを停止するか、個別にライセンスを取得する必要があります。
別の例として、ESLライセンスのOracle DBが製造システムの一部としてある場合、ベンダーが提供しない限り、そのデータベースを新しいバージョンにアップグレードすることはできません(ESLは、アプリケーションがサポートする特定のバージョンにユーザーを関連付けることがよくあります)。個別にアップグレードする場合は、フルユースライセンスに変換する必要があるかもしれません(OracleはESLからのクレジットを新規購入に許可する場合がありますが、ケースバイケースです)。
リセラー割引体系(標準30%):
前述のように、再販業者は多くの場合、小規模な取引についてあまり交渉することなく、約20〜30%オフを提供します。これは、交渉するべきではないという意味ではありません – 特に複数の再販業者が競合している場合や、彼らのサービスとバンドルしている場合は、交渉することができます。
また、大きな買い物(たとえば$ 1M +)を行っている場合は、再販業者を通じても、再販業者を通じてOracleからの特別割引を交渉することができます(再販業者はOracleと調整してより良い取引を確保し、それをあなたに渡しますからマージンが少なくなります)。常に見積もりを精査する:オラクルの価格表は公開されているため、定価を確認できます。再販業者の見積もりがリストから10%オフの場合、それはおそらく大した取引ではありません(それが非常に少額の購入であるか、Oracleがその製品の割引に非常に固執している場合を除く)。標準サポート価格(正味の22%)は、得られる正味価格と一致します。
ISV モデルに関する考慮事項:
ISVである場合、またはプロバイダ側からオラクルの「埋め込み」に遭遇した場合は、オラクルがISVに別の契約(ASFU/ESL補遺を含むオラクルパートナー契約)に署名することを要求し、多くの場合、年間最低額または収益レポートを設定することを知っておいてください。お客様は、これらのライセンスが存在することを認識し、ISV との契約で、ソリューションに必要な Oracle ライセンスが提供されていることを明確にしていることを確認してください。
まとめると、 調達に関するヒントは、 日常的な購入や、サービスに関するワンストップ・ショップが必要な場合には、オラクルのパートナーを利用し、複雑な交渉や大規模な交渉には、オラクルとの直接の契約を利用します。サードパーティを通じて取得する場合は、常に、取得するOracleライセンスの種類(フル使用か制限付きか)を明確にします。そして、更新に注意してください。パートナーがサポート更新の管理を申し出、場合によってはわずかな休憩や追加サービスを提供する場合がありますが、最終的にはオラクルが基本更新コストを設定します。

________________________________________
ITAM実務家への提言

プロアクティブなライセンス管理:
Oracleのライセンスは、決して一度設定しておけば忘れられるような作業であってはなりません。Oracleのデプロイメント(オンプレミスおよびクラウド)を継続的に監視し、購入した権限と一致していることを確認します。オラクルのスクリプトまたはSAMツールを使用して、少なくとも年に一度は内部監査を設定し、コンプライアンスのギャップを早期に発見します。不足や意図しない使用にすぐに対処する – 監査後に多額の調整料金を支払うよりも、必要なライセンスを積極的に購入する方が良いでしょう。

契約を理解する:
Oracle OMAとすべての注文ドキュメントを常に明確に理解してください。メトリクス(ユーザー、プロセッサなど)の定義と、交渉した特別な条件を把握します。オラクルの標準ポリシーに、仮想化やDR権限など、環境にとって重要なものがある場合は、契約で明示的に対処するようにしてください。たとえば、VMwareを頻繁に使用する場合は、ライセンスの境界を構成するものについて条項を交渉するか、Oracleの声明を書面で作成します。すべての契約文書を整理し、参照できるようにアクセスできるようにします。

教育とコミュニケーション:
オラクルのコンプライアンスは、テクノロジーだけでなく、人にも関わるものです。技術チーム (DBA、システム エンジニア、クラウド アーキテクト、開発者) に Oracle ライセンスの基本について教育します。開発者が小規模なプロジェクトのために、Express EditionまたはStandard Edition(または無料の代替品)で十分なのにOracle Enterprise Editionインスタンスをスピンアップするなど、単純な認識でコストのかかるミスを防ぐことができます。コンテナ化された環境やCI/CDパイプラインなど、Oracleソフトウェアのデプロイメント前にITAMに通知される通信チャネルを確立します。
ライセンスの最適化: ライセンスの使用を最適化する機会を探します。
• 小規模なOracleデータベースが多数ある場合は、プロセッサ・ライセンスの数を減らすために、それらをより少ないサーバーに統合することを検討してください(パフォーマンスに注意してください)。
• 使用していないOracleソフトウェアの電源を切るかアンインストールします – インストールされていない場合は、ライセンスは必要ありません。これは、仮想環境やテスト環境で特に重要です。
• エディションをニーズに合わせる: Standard Editionが機能するOracle Enterprise Editionを使用せず、どうしても必要な場合を除いて有料オプションを有効にしないでください。
• 大幅な成長が見込まれる場合は、オラクルの無制限ライセンス契約(ULA)のような代替ライセンスプログラムを検討しますが、ULAには慎重に取り組み、使用量を測定して適切に終了する計画を立ててください。
• オラクルのクラウド・プロモーションがお客様の戦略に合致している場合は、そのプロモーションを活用してください(たとえば、OCIのサポート・リワード・プログラムでは、一部のワークロードをOCIに移行した場合、サポート請求額を効果的に削減できます)。

ポリシーの最新情報を入手: クラウド、仮想化、およびその他の領域に関するオラクルのライセンス・ポリシーは変更される可能性があります。オラクル(および評判の良いオラクルのライセンスアドバイザリー会社)からの最新情報を毎年レビューすることを習慣にしてください。たとえば、2025年には、クラウドプロバイダーやJavaライセンスに対するオラクルのスタンスは、過去とは異なる可能性があります。常に最新の情報を入手することで、古い仮定に基づいて意思決定を行うことがなくなります。

従業員数とユーザー数の監視: ユーザーまたは従業員ベースのライセンスについては、人事部と IT 部門と協力してプロセスを実装し、これらのメトリックを追跡します。従業員ベースのライセンスをお持ちの場合は、人事部門の人員レポートと関連付けてください。指名ユーザライセンスをお持ちの場合は、ユーザのオンボーディング/オフボーディングにライセンスの割り当てまたは再利用手順が含まれていることを確認してください。これにより、コンプライアンスが維持されるだけでなく、離脱したユーザーのためにサブスクリプションを過剰に購入しないことで、コストを節約できます。
サポート・コストの管理: Oracleサポートは高額であるため、積極的に管理してください。展開されていないライセンスにサポートを支払っているかどうかに注意してください – シェルフウェアがある場合は、サポートを再交渉するか、それらのライセンスを必要な領域に再割り当てすることを検討するかもしれません。また、サポートの増加のための予算。購入時に可能であれば、上限を交渉してください。また、オラクル製品を廃止(交換またはシステムの廃止)する予定がある場合は、コストを節約するために、サポートが意図的に失効するようにタイムラインを考慮に入れてください(ただし、計画が変更された場合の復活手数料を避けるために、それを十分に計画してください)。

監査対応: オラクルは、比較的短期間で監査を行うことができます。常に、慌てずに監査に対応できる姿勢で臨む。これは、次のものを持つことを意味します。

• 更新されたデプロイメント・インベントリ(サーバー、CPU、Oracle製品バージョン、オプションの使用方法)。
• 所有するライセンスへのデプロイメントの明確なマッピング。
• 特別な権利の文書化(割り当てレターやOracleからの何かを承認する電子メールなど)。
• グレーゾーンを見つけた場合は、監査の前にOracleまたはサードパーティのOracleライセンス専門家に相談して明確にすることを検討してください。

必要に応じて専門家の助けを借りる: トリッキーなシナリオ (複雑な仮想化やマルチクラウド展開など) について、オラクルのライセンス専門家に相談することをためらわないでください。彼らの洞察は、コストのかかる間違いからあなたを救い、オラクルとの交渉にも役立ちます。同様に、契約を交渉する際には、オラクルやITAMの経験を持つ調達チームと法務チームを巻き込み、お客様の環境にとって現実的な条件を導き出します。

変更の計画: 会社が変更 (クラウド移行、合併、Oracle フットプリントの縮小など) を受けている場合は、そのためのライセンス管理計画を作成します。たとえば、クラウドに移行する場合は、BYOLで再利用するライセンスとオンプレミスのままにするライセンス、およびその移行を追跡する方法を決定します。古いオラクル製品についてサードパーティのサポートプロバイダー(リミニストリートなど)を検討する場合は、コンプライアンスへの影響を比較検討してください(古いバージョンに固執し、オラクルはサポートへの再登録を容易に許可しない可能性があります)。
これらのベストプラクティスに従うことで、ITAMの実践者は、コンプライアンス違反のリスクを大幅に軽減し、Oracle資産の管理における不要なコストを回避できます。Oracleのライセンスは複雑かもしれませんが、勤勉さと情報に基づいた戦略により、効果的に制御できます。

参照：Redress Compliance: https://www.linkedin.com/newsletters/6861995756513988609/