LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

DBライセンス費が膨らみやすい理由：コア・エディション・仮想化・クラウドの複雑さ

データベース（DB）ライセンスのコスト最適化とは、Oracle DatabaseやSQL Serverなどの主要DBMSを対象に、ライセンス費用の構成要素を正確に把握し、各ベンダーのライセンス規定に沿って費用を適正化する取り組みです。DBライセンスは多くの企業のITコストの中でも高額な費目の一つですが、その費用構造は複雑で、構成の違いによって同じ目的でも費用が大きく異なります。

DBライセンス費が膨らみやすい背景には、費用を決める変数が多いことがあります。ライセンス費用に影響する主な要素を以下に整理します。

• コア数・エディション：搭載するプロセッサのコア数とエディション（Standard/Enterprise等）によって費用の計算起点が変わります
• オプション機能：パーティショニング・Advanced Security・RAC（Real Application Clusters）などのオプションはエンタープライズ・エディションへの追加ライセンスが必要なものも多く、有効化した機能数により費用が積み上がります
• 仮想化環境：仮想化技術の種類と設定によって、ライセンスカウントの対象範囲（物理サーバー全体か割り当てvCPUのみかなど）が変わります
• クラウド移行：オンプレミスからクラウドへ移行した場合、ライセンスの計算方式が変わる場合があり、BYOL（Bring Your Own License）の適用可否が費用に影響します

これらの要素が組み合わさることで、同じDBMSを使っていても構成次第で費用が大きく異なります。インフラ担当が変わった、クラウド移行を実施したなどのタイミングで、構成とライセンスの乖離が生まれやすく、気づかないまま過剰なライセンス費を払い続けているケースがあります。

ベンダー監査のリスクと過剰・過少の両方向の問題

DBライセンスに関するリスクは「払いすぎ」と「足りていない（非準拠）」の両方向に存在します。OracleやMicrosoftなどの主要ベンダーはライセンス監査を実施する権限を契約上持っており、非準拠が発覚した場合には不足分のライセンス購入や遡及的な費用の請求が求められることがあります^*1。

一方、必要以上のライセンスを保有しているケース（過剰ライセンス）も費用増の原因になります。使われていないオプション機能や、サイズダウンすれば不要になるライセンスが放置されているケースでは、現状構成を正確に把握することで適正化の余地が見えてきます。

Oracleライセンスの基本：プロセッサ・コアファクター・クラウドのvCPUベース・BYOL

Oracle Databaseのライセンスには主に「プロセッサ・ライセンス」と「Named User Plus（NUP）ライセンス」の2種類があります。企業の基幹システムで広く使われているのはプロセッサ・ライセンスで、サーバーのプロセッサ数（コア数）に基づいて費用が計算されます。

オンプレミスのプロセッサ・ライセンス：コア×コアファクター

オンプレミス環境でのOracle Databaseのプロセッサ・ライセンス数は、「物理コア数 × プロセッサ・コア・ファクター」によって算出されます。コア・ファクターとは、プロセッサのアーキテクチャによって定まる係数で、Oracle社が公表している「Processor Core Factor Table」^*2に記載されています。

コア・ファクターはプロセッサの種類によって異なり、例えばIntel xeonなどでは一般的に0.5が適用されることが多いですが、正確な値は最新のOracle社の「Processor Core Factor Table」を参照することが重要です。プロセッサの種類や世代によって値が異なるため、構成を確定する前に原典を確認することが重要です。

ライセンス数の計算例としては、「8コアのサーバー × コア・ファクター = ライセンス数」という形になりますが、具体的な係数は構成によって変わるため断定的な数値は示せません。実際の算出は各ベンダーのライセンス規定に従って行うことが必要です。

パブリッククラウドでの計算方式：vCPUベースへの変化

Oracle公式のライセンス規定によると、Oracle認定クラウド環境（Authorized Cloud Environments）においてはコア・ファクターは適用されず、vCPU（仮想CPU）の数に基づくよりシンプルなカウント方式が採用されます^*3。これはオンプレミスの計算式とは異なる点で、クラウド移行を検討する際にはライセンス数の変化を事前に確認することが大切です。

認定クラウド環境の対象はOracle社が定める公式リスト（Authorized Cloud Environments）で確認でき、AWSやMicrosoft Azure、Google Cloudなどが含まれますが、適用条件や詳細は変更される場合があるため、最新の公式リストを参照してください。

BYOL（Bring Your Own License）の仕組みと注意点

BYOL（Bring Your Own License）とは、保有するオンプレミスのOracleライセンスをクラウド環境やPaaSに持ち込む方式です。Oracle社の規定では、有効なライセンスとSoftware Update License & Support（SULS）を保有していることがBYOLの前提条件となっています^*3。ライセンス込みのサービス（License Included）と比較して費用を抑えられる場合がありますが、適用条件・ライセンス数の計算方法は構成によって異なります。

BYOLを活用する場合は、以下の点を事前に確認することが重要です。

• 保有ライセンスの種類・数量・サポート状況（SULS有効期限）
• 対象クラウドが認定クラウド環境リストに含まれているか
• BYOL適用時のライセンス計算方式（vCPUカウントの考え方）
• モビリティ条件（ライセンスの移動に関する制約）

これらはOracle社のライセンス規定や認定クラウドドキュメントで確認できますが、内容が専門的で解釈が難しいため、外注の活用を検討する場面の一つになります。

仮想化環境とパーティショニング・ポリシー

仮想化環境（VMware・Hyper-V・KVMなど）でOracle Databaseを稼働させている場合、ライセンスのカウント方式がOracle社の「Oracle Partitioning Policy」（パーティショニング・ポリシー）によって規定されます^*4。特定の仮想化技術（Oracle VM・OVMなど）の認定環境では、割り当てたコアのみをライセンス対象とできる場合がありますが、非認定環境ではサーバー全体のコアをカウント対象とする必要があるケースがあります。

誤った仮想化設定は非準拠リスクに直結します。仮想化環境でOracleを使用している場合は、最新のOracle社パーティショニング・ポリシーを参照した上で設計・運用することが欠かせません。

最適化のアプローチ：エディション見直し・仮想化割り当て・SQL ServerのSA/Hybrid Benefit

DBライセンスのコスト最適化は「使っていない機能・ライセンスをなくす」「より実態に合った課金方式に切り替える」という2つの方向で進めます。主なアプローチを整理します。

エディションとオプション機能の見直し

Oracle Databaseには、Standard Edition 2（SE2）とEnterprise Edition（EE）という主要なエディションがあり、使える機能や費用が大きく異なります。Oracle社の規定によると、SE2には同時接続数（ソケット数）の制限がある一方で費用はEEより抑えられており、EEで必要とされる高度な機能（Advanced Securityや診断・チューニングパック等）が不要な用途であれば、SE2への移行で費用を適正化できる可能性があります。

また、EEのオプション機能は有効化しただけでライセンスが必要になる場合があり、実際には使っていないオプションが有効状態になっているケースがあります。使用状況のログ（Oracle License Management Services等のツールで確認可能）をもとに、実際に使っている機能だけにライセンスを絞ることが費用適正化のポイントです。

仮想化環境での割り当て最適化

Oracle社の認定仮想化環境（Oracle VM Serverなど）を使用している場合、DBが稼働するVMに割り当てる仮想CPUの数を実際の負荷に合わせて絞ることで、ライセンス対象コア数を適正化できる場合があります。ただし、この手法が適用できるかどうかはパーティショニング・ポリシーの最新版に依存するため、変更前にOracle社の公式ドキュメントを確認することが大切です。

非認定の仮想化環境（VMwareなど）で物理サーバー全体のコアをライセンス対象としている場合、認定環境への移行やクラウドへの移行が費用改善につながる可能性があります。移行の費用対効果は構成によって異なるため、移行前に試算することが重要です。

SQL Server：SAとAzure Hybrid Benefitの活用

Microsoft SQL Serverのコスト最適化では、Software Assurance（SA）とAzure Hybrid Benefitが主な手段になります。Microsoft社の製品ライセンス規定^*5によると、以下のような最適化の余地があります。

SQL Serverのライセンスは、利用するエディション（Standard/Enterprise等）・展開場所（オンプレミス/クラウド）・SAの有無によって選択肢が変わります。現状のライセンス状況を棚卸しした上で、各条件のメリットを比較検討することが重要です。

クラウド移行とライセンス方式の変更

オンプレミスからクラウドへ移行する際は、DBのライセンス方式が変わるケースがあります。OracleについてはBYOLとLicense Included（クラウドベンダーがライセンスを含む価格で提供）の比較を、SQL ServerについてはAzure Hybrid BenefitやManaged Instanceなどの選択肢をそれぞれ検討します。

ただし、クラウド移行はライセンス費だけでなく、インフラ運用コスト・アーキテクチャ変更の工数・移行後の性能要件など複数の要素に影響します。ライセンス費の観点だけで意思決定するのではなく、総合的なコスト試算の中で判断することが大切です。

進め方：棚卸し→使用状況の可視化→最適化案→規定適合確認→継続管理

DBライセンスの最適化は「現状把握」から始めます。以下の5ステップで進めることが基本的な流れになります。

ステップ1：ライセンス棚卸し（保有状況の全数把握）

まず、現在保有しているDBライセンスの種類・数量・エディション・オプション・契約形態（永続ライセンス・サブスクリプション等）・Software Assuranceの有効期限を一覧化します。複数のサーバーや環境（オンプレミス・クラウド・テスト環境など）を横断して台帳を整備することが出発点です。

棚卸しは、インフラチームだけでなく調達・経理・法務部門と連携して、契約書・発注書・ライセンス証書を突き合わせる作業になります。この段階で初めて「契約上の保有ライセンス数」と「現在の使用構成」が整合しているかどうかが見えてきます。

ステップ2：使用状況・構成の可視化

次に、各DBインスタンスの稼働サーバー仕様（コア数・仮想化技術・割り当てvCPU数）と実際のDB機能使用状況を把握します。Oracleの場合、Oracle Database Usage Tracking（Enterprise Editionのオプション）やOracle Management Packなどのツールを使って有効化されているオプション機能のログを確認することができます^*6。

実際に使っていないオプション機能が有効状態になっているケースや、稼働ピーク時のコア使用率と割り当てコア数に大きな乖離があるケースが発見されることがあります。この可視化のステップを省略して最適化案だけを先行させると、規定適合の観点から誤った判断につながるリスクがあります。

ステップ3：最適化案の策定と費用試算

棚卸しと可視化の結果をもとに、以下の観点から最適化の候補を検討します。

• エディションのダウングレード（EE → SE2など、機能要件を満たす場合）
• 不使用オプションの無効化とライセンス返還（可能な場合）
• 仮想化環境の認定環境への変更またはコア割り当ての見直し
• BYOLを活用したクラウド移行またはPaaS化
• SQL ServerのAzure Hybrid Benefit適用・SA活用

各案については、変更に必要な工数・移行コスト・リスクを合わせて試算します。ライセンス費だけを見た場合と、運用コスト・移行費込みの総コストを見た場合で優先順位が変わることがあります。

ステップ4：ベンダー規定との適合確認

最適化案を実行する前に、最新のベンダーライセンス規定と照合します。OracleはOracle Technology Network License Agreement（ONTLA）や各種ライセンスガイドを、MicrosoftはMicrosoft Product Terms（旧Product Use Rights）をそれぞれ定期的に改訂しています^*5。改訂によってBYOL条件・認定クラウドリスト・パーティショニング・ポリシーが変わることがあるため、実行前の確認が欠かせません。

特に重要なのが、計画しているアーキテクチャが「コンプライアンス上の問題がないか」という確認です。費用削減の観点から有望に見えるアプローチでも、規定上認められない構成であれば実行できません。疑義がある場合はベンダーに直接確認するか、ライセンス専門家への相談を検討することが重要です。

ステップ5：実行と継続管理の体制構築

最適化を実行した後も、インフラ構成変更のたびにライセンス台帳を更新し、年1回以上の定期棚卸しを行う体制を整えることが大切です。DBのバージョンアップ・クラウド移行・仮想化設定変更のたびにライセンス要件が変わる可能性があり、変更管理プロセスにライセンス確認を組み込んでおくことがコンプライアンス維持につながります。

外注の使いどころ：棚卸し・診断・構成設計の委託判断軸

DBライセンスの最適化を内製で進めることが難しい場面は複数あります。外注が有効な局面と、委託先を選ぶ際の判断軸を整理します。

内製が難しい理由：専門知識と工数の両方が必要

DBライセンスの最適化には、最新のベンダーライセンス規定の読み込み・仮想化技術の理解・インフラ設計の知識・コスト試算という複数の専門スキルが同時に必要です。インフラチームがDBライセンス規定の詳細まで習熟している企業は少なく、規定の解釈を誤ったまま構成変更を進めるとかえってコンプライアンスリスクが高まります。

また、棚卸しから最適化案策定・規定適合確認・体制構築まで一連の作業をこなすには、数人月規模の工数が発生することがあります。通常業務と並行して進める場合は、スケジュールや品質のリスクを考慮した上で内製か外注かを判断することが重要です。

外注が有効な場面

• 初回棚卸し・診断：社内に知見が蓄積されていない場合や、ライセンス台帳が整備されていない状態から始める場合は、外注の棚卸しサービスを活用することで短期間で現状把握ができます
• 大規模クラウド移行前のライセンス試算：移行前にBYOL適用可否・ライセンス数の変化・費用試算を外注で行うことで、移行後の費用超過リスクを事前に抑えられます
• ベンダー監査対応：Oracle監査やMicrosoft監査が通知された場合、準備から対応交渉まで外注のサポートを受けることで、内製対応では見落としがちな規定解釈のミスをカバーできます
• 継続的な管理体制の構築：管理台帳の整備・変更管理プロセスの設計・年次棚卸しの仕組みづくりを外注でスタートし、後から内製に移管するアプローチも有効です

委託先を選ぶ際の判断軸

DBライセンス最適化の委託先を選ぶ際は、以下の軸で確認することをおすすめします。

• ライセンス専門性：OracleやMicrosoftのライセンス規定に習熟しているか、資格（Oracle License Management等）や実績があるか
• インフラ知識：仮想化環境・クラウド（AWS/Azure/GCP）の設計経験があり、ライセンス観点での構成提案ができるか
• コンプライアンス重視：コスト削減だけを優先するのではなく、規定適合の確認を含めるプロセスを持っているか
• 成果物の明確さ：棚卸しレポート・最適化案・適合確認の結果など、具体的な成果物と納品基準が契約前に明示されているか
• ベンダーとの独立性：特定ベンダーの製品販売と結びついていない中立的な立場からアドバイスを受けられるか

DBライセンスの最適化は「一度やれば終わり」ではなく、インフラ変更のたびに継続的な確認が必要なテーマです。単発のスポット契約から始めるか、継続的な管理サポートを含む契約にするかは、社内の体制と変更頻度に合わせて判断することが重要です。

LASSICでは、ITシステムの保守・運用を元請（プライムベンダー）として受託する立場から、インフラ構成とライセンス管理の両方を視野に入れた支援体制を整えています。DBライセンスの棚卸しや構成設計のご相談は、お問い合わせフォームからお気軽にお声がけください。

まとめ：DBライセンスコスト最適化を進める3つの軸

本稿では、Oracle Database・SQL Serverを中心にDBライセンスのコスト最適化について整理しました。要点を3つに集約します。

第一に、DBライセンスの費用はコア数・エディション・オプション・仮想化技術・クラウド構成という複数の変数が組み合わさるため、構成の正確な把握なしに最適化を進めることはできません。まずライセンス棚卸しと使用状況の可視化を行い、「今の構成でいくら払うべきか」という実態を掴むことが出発点です。

第二に、BYOL活用・エディション/オプション見直し・仮想化環境の認定化・SQL ServerのAzure Hybrid Benefit活用など、複数のアプローチがありますが、いずれも実行前に最新のベンダーライセンス規定との適合確認が欠かせません。費用削減と規定コンプライアンスの両立が、リスクを抑えた最適化の前提条件です。

第三に、DBライセンスの管理は「一度整えれば終わり」ではなく、インフラ変更・クラウド移行・バージョンアップのたびに継続的な棚卸しと確認が必要です。内製での習熟が難しい場合は、初回棚卸しや大規模変更のタイミングで外注を活用することで、コンプライアンスリスクを抑えながら費用適正化を進めることができます。

よくある質問

OracleのBYOL（Bring Your Own License）とはどのような仕組みですか？

BYOLとは、オンプレミスで保有するOracleライセンスをクラウド環境やPaaSに持ち込み、クラウドベンダーが提供するライセンス込みサービスよりも費用を抑えられる場合がある仕組みです。Oracle公式のライセンス規定によると、利用できるクラウドや条件はOracleが定める「認定クラウド環境リスト」や契約内容によって異なります。BYOL適用の可否や計算方法は構成依存のため、最新のOracle社ライセンス規定と認定環境リストを確認することが大切です。

仮想化環境ではOracleライセンスの計算方法が変わりますか？

はい、仮想化環境では割り当て方によってライセンス対象範囲が変わります。Oracle社の規定によると、特定の仮想化技術（Oracle VM・OVMなど一部の認定環境）においては、割り当てた仮想CPUのみをライセンス対象とできる場合があります。一方、非認定の仮想化環境では物理サーバー全体のコアを対象とする必要があるケースもあります。誤った構成を選ぶと過剰ライセンスや非準拠リスクにつながるため、最新のOracle社パーティショニング・ポリシーを確認することが重要です。

SQL ServerのSoftware Assurance（SA）とはどのようなメリットがありますか？

Software Assurance（SA）は、Microsoftが提供するライセンスの維持・管理プログラムで、新バージョンへのアップグレード権やAzure Hybrid Benefitの利用権などが含まれます。Microsoft社の公式規定によると、SAを保有するSQL Serverライセンスはクラウド（Azure SQL等）でBYOL相当の活用ができるAzure Hybrid Benefitに適用でき、ライセンス込みサービスの費用と比較した場合にコスト差が生まれる可能性があります。詳細な条件は最新のMicrosoft製品ライセンス規定で確認することをおすすめします。

DBライセンスの棚卸しはどのくらいの頻度で行うべきですか？

サーバー構成変更・クラウド移行・仮想化環境変更・新規調達のタイミングで実施することに加え、定期的には年1回以上の確認が推奨されます。DBライセンスはバージョンアップやインフラ変更に伴ってライセンス対象範囲が変わる可能性があり、放置するとベンダー監査（ライセンス監査）で非準拠として指摘を受けるリスクがあります。変更のたびに棚卸しと規定確認を行うことが、コンプライアンス維持とコスト管理の両面で重要です。

DBライセンス最適化を外注する場合、どのような成果物を期待できますか？

外注の一般的な成果物は、現状のライセンス構成と使用状況の棚卸しレポート、最適化案（エディション変更・BYOL活用・クラウド移行案など）、ベンダー規定との適合確認、および継続管理のための管理台帳・手順書です。契約形態によっては、ベンダー監査対応の支援やライセンス再交渉のサポートが含まれることもあります。委託前にスコープと成果物の定義を明確にしておくことが、後工程のトラブル回避につながります。

著者：テレリモ総研編集部　鈴木 亮佑

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Oracle社「Oracle Technology Network License Agreement（ONTLA）」ライセンス規定全般（Oracle公式サイト・ライセンス関連ページ参照）
2. *2　出典：Oracle社「Processor Core Factor Table」（Oracle公式）
3. *3　出典：Oracle社「Licensing Oracle Software in the Cloud Computing Environment」（Oracle公式）
4. *4　出典：Oracle社「Oracle Partitioning Policy」（Oracle公式）
5. *5　出典：Microsoft社「SQL Server Licensing Resources」（Microsoft公式）
6. *6　出典：Oracle社「Oracle Database Documentation」（Oracle公式）