クラウドサービス

OCI License Manager

BYOL ライセンスの権利数と要件を一元管理。OCI License Manager は製品ごとの保有権利と毎時算定する必要数を照合し、超過や期限を週次メールで知らせる。

基礎コスト最適化運用上の優秀性
最終更新: 2026-07-29公式ドキュメント
3つの要点
TL;DR
  1. BYOL 形態のライセンス権利数と資源が必要とする数量をテナンシ全体で可視化する。
  2. 製品ごとの権利数と毎時算定する要件を照合し、超過や期限を週次メールで知らせる。
  3. License Manager 自体は無料で、課金は対象リソース側にのみ発生する。

解決する課題

オンプレミスで購入済みのソフトウェアライセンスをクラウドに持ち込む BYOL(Bring Your Own License)運用では、「どの製品のライセンスを何コア分保有し、いま実際に何コア消費しているか」を把握しづらく、知らないうちに保有量を超過してコンプライアンス違反やライセンス監査での追加費用が発生しがちです。OCI License Manager は、この ライセンスの保有量と消費量を突き合わせて一元管理 することで課題を解決します。

  • 持ち込みライセンスの保有上限と実消費量を一覧で把握したい
  • 製品ごとのライセンス要件が保有権利を超過したら早めに気づきたい
  • 監査に備えてライセンスの利用状況をいつでも示せる状態にしたい
  • 複数コンパートメントやリージョンに散らばった消費を横断的に集計したい
  • ライセンス管理のためだけに追加コストや別ツールを増やしたくない

AWS で言えば AWS License Manager に相当する位置づけです。

主要概念と用語

  • ライセンスレコード(License Record): 保有しているライセンスの実体を登録する単位。製品名、保有数(コア/プロセッサ数など)、サポート終了日(EOL)といった購入済みライセンスの情報を表す
  • 製品ライセンス(Product License): 管理対象のソフトウェア製品ごとに作る入れ物。ベンダー、製品、契約上の指標を定義し、配下に複数のライセンスレコードを束ねる
  • BYOL(Bring Your Own License): 自社購入済みライセンスをクラウドに持ち込む形態。License Manager の主な管理対象
  • ライセンス込み(License Included): クラウド利用料にライセンス料が含まれる形態。概要画面では BYOL 資源と分けて件数を確認できる
  • 消費量(Consumed): 対象リソースが実際に使っているライセンス量。OCI 側のリソース利用状況から自動的に集計される
  • 権利(Entitlement)と要件(Requirement): 権利は有効なライセンスレコードの数量合計、要件は対象資源を契約指標へ換算した必要数。要件が権利を上回ると超過契約として表示される
  • イメージ(Image)との関連付け: 他社製品では、製品ライセンスを特定イメージに紐づけ、そのイメージから起動した資源の要件を集計する。対応する Oracle Database 製品はライセンスポータビリティ規則に基づいて算定される

仕様・制限・クォータ

  • 管理の中心は 製品ライセンスと、その配下に登録するライセンスレコードの二階層。保有量はレコードの合計、消費量は実リソースから集計される
  • 消費量はテナンシ全体(複数コンパートメント・リージョン)を横断して集計される。リージョンごとにツールを分ける必要がない
  • ライセンス要件は1時間ごとに再計算され、権利数との比較結果が製品ライセンスに反映される。任意の警告しきい値を設定する機能ではない
  • 対応する Oracle Database 製品・オプションに加え、他社製品の BYOL ライセンスも製品ライセンスとして登録できる
  • 通知先メールアドレスをサービス設定へ登録すると、超過契約とライセンス/サポート期限の要対応項目が週次の概要メールで届く
  • 他社製品の要件集計は対象イメージとの関連付けに依存する。関連付けがないと製品ライセンスが不完全と判定され、資源が正しく帰属しない
まず「保有量」を正しく登録する

License Manager の価値は、実消費量と保有量の突き合わせにあります。最初にライセンスレコードへ正確な保有数を登録しておかないと、超過判定の基準が定まりません。購入契約の単位(コア/プロセッサ/NUP など)を確認して登録してください。

内部の仕組み

横にスクロール

OCI License Managerについて、ライセンス記録と資源使用量を照合し、過不足を可視化する処理経路と利用者・サービスの責任境界を示す図
OCI License Manager の処理経路。算定結果は契約解釈や法的なライセンス監査の代替ではない

License Manager は、利用者が登録した保有量(ライセンスレコード)と、OCI が把握している実際のリソース消費を突き合わせて、製品ごとの利用状況を継続的に算出します。

  • 保有量は、ライセンスレコードに登録された数値の合計として決まる。利用者が購入実績に基づいて入力・更新する
  • 消費量は、製品ライセンスに関連付けたイメージや対象リソースの稼働状況から自動的に集計される。利用者がコア数を手計算する必要がない
  • 超過判定は、毎時算定した要件とライセンスレコードの権利数を比較して行い、結果をダッシュボードで可視化する
  • 集計はテナンシ内の複数コンパートメント・リージョンを横断して行われ、分散した消費を一つの製品ライセンスに合算する
  • License Manager は消費を制限したり起動をブロックしたりはしない。あくまで可視化と通知が役割で、是正は運用側で行う
可視化であって強制ではない

License Manager は超過契約を可視化して週次メールで知らせるツールであり、ライセンス超過時にリソースの起動を自動で止める仕組みではありません。超過を見つけたら、保有量の追加購入かリソースの削減かを運用判断で是正する必要があります。

設計パターン / ベストプラクティス

  • 購入と同時にレコード登録: ライセンスを買ったら速やかにライセンスレコードへ反映し、保有量を常に最新に保つ
  • 権利と要件を定期照合: 製品ライセンスの要件・権利・超過状態を確認し、毎時算定の遅延も踏まえて契約台帳と照合する
  • 他社製品はイメージと関連付ける: 対象製品を特定のプラットフォームイメージに紐づけ、手計算ではなく自動集計で要件を取る
  • EOL(サポート終了)を管理に含める: ライセンスレコードのサポート終了日を活用し、更新やリプレース計画を前倒しで立てる
  • 週次メールの受信者を管理: サービスの通知設定に契約担当・運用担当のメールアドレスを登録し、超過契約や期限の要対応項目を見落とさない
  • 定期レビューを習慣化: 監査前だけでなく定期的に消費量と保有量を見直し、過剰購入・不足の両方を抑える

運用・監視

  • 製品ライセンスのダッシュボードで、権利数・要件・超過状況を一覧で確認する。監査時の調査材料としても使える
  • サービス設定の通知先を保守し、超過契約と期限をまとめた週次メールを契約担当・運用担当の双方で受け取る
  • 誰がライセンスレコードや製品ライセンスを変更したか」は OCI Audit で追跡する
  • 要件が想定とずれる場合は、算定から最大1時間程度の時間差、対象資源の帰属、他社製品のイメージ関連付けを点検する
  • 監査・契約更新のタイミングに合わせ、保有量の棚卸しと不要リソースの整理を定期的に行う

コスト

License Manager サービス自体の利用料はかからず、課金されるのは管理対象である OCI リソース(Compute・Database など)と、それらが使うソフトウェアライセンスの契約費用です。License Manager の役割は、ライセンス費用を払い過ぎない/違反しないためのコスト最適化を支援することにあります。

費目考え方最適化のヒント
License Managerサービスの利用自体は追加料金なしコストを気にせずライセンス管理を徹底できる
BYOL ライセンス自社購入済みライセンスの契約費用消費量を可視化し過不足のない購入量に調整する
対象リソースCompute や DB など実体の従量課金不要なインスタンスを止め消費量も同時に下げる
監査リスク超過放置による追加請求や違反コスト要件と権利の超過を確認し是正して回避する

セキュリティ

  • IAM ポリシー+コンパートメントで、ライセンスレコードや製品ライセンスを閲覧できる人と編集できる人を分離する。保有量の改ざんを防ぐ
  • ライセンス情報は契約に関わる機微なデータであり、編集権限を最小限の担当者に絞る
  • 変更操作は OCI Audit に記録し、保有量の改変や不正な書き換えを後から追跡できるようにする
  • 消費量の集計対象範囲はテナンシ全体に及ぶため、閲覧権限を付与する範囲とコンパートメント設計を整合させる
アンチパターン

監査対策として保有量だけを実態より多く登録し、見かけ上の超過を消すのはコンプライアンス違反を隠すだけで、実際のライセンス監査では通用しません。保有量は購入契約に基づく正確な値を登録し、超過は登録値ではなくリソース側の削減や追加購入で是正してください。

関連サービス・比較

OCI License Manager と、相当する AWS のサービスである AWS License Manager を比較します。どちらも BYOL ライセンスの追跡を主目的とする点は共通です。

観点OCI License ManagerAWS License Manager
位置づけBYOL ライセンスの保有量と消費量を一元管理BYOL ライセンスの追跡と利用ルールを管理
主な対象BYOL 形態のソフトウェアライセンスBYOL 形態のソフトウェアライセンス
管理単位製品ライセンスとライセンスレコードライセンス設定(License Configuration)
集計範囲テナンシ内の複数コンパートメント・リージョン横断アカウント・リージョン横断
超過時の挙動可視化と週次メールで起動は止めないルール超過時に起動を制限する設定も可能
利用料サービス自体は無料サービス自体は無料

なお OCI 内では、License Manager の通知先設定で週次メールを送り、操作監査に Audit、コスト全体の可視化に Cost Analysis / Budgets を組み合わせて使います。

ハンズオン / CLI例

oci license-manager コマンドで、製品ライセンスやライセンスレコードの作成・確認が行えます。次は製品ライセンスを作成し、ライセンスレコードを登録して消費量を確認する例です。

# 1) 管理対象の製品ライセンスを作成する(BYOL 形態の例)
oci license-manager product-license create \
  --compartment-id "$COMPARTMENT_OCID" \
  --display-name "oracle-db-ee-byol" \
  --is-vendor-oracle true \
  --license-unit "PROCESSORS"

# 2) 購入済みライセンスをライセンスレコードとして登録する(保有量)
oci license-manager license-record create \
  --product-license-id "$PRODUCT_LICENSE_OCID" \
  --display-name "db-ee-contract-2026" \
  --license-count 64 \
  --is-unlimited false \
  --expiration-date "2027-03-31T00:00:00Z" \
  --is-perpetual false

# 3) 製品ライセンスの保有量・消費量サマリを確認する
oci license-manager product-license get \
  --product-license-id "$PRODUCT_LICENSE_OCID" --output table

# 4) テナンシ全体の概要指標を取得する
oci license-manager license-metric get \
  --compartment-id "$TENANCY_OCID" \
  --is-compartment-id-in-subtree true --output table

# 5) この製品に帰属した資源ごとのライセンス要件を確認する
oci license-manager product-license list-product-license-consumers \
  --compartment-id "$TENANCY_OCID" \
  --product-license-id "$PRODUCT_LICENSE_OCID" --output table

OCI Service

OCI License Managerを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

管理・ガバナンス

比較で見る軸

クラウド: OCI / カテゴリ: 管理・ガバナンス / 難易度: basic

導入後に効く点

製品ごとの権利数と毎時算定する要件を照合し、超過や期限を週次メールで知らせる。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
OCI
カテゴリ
管理・ガバナンス
難易度
basic
関連資格
設計柱
cost / operational

判断チェックリスト

  • 自社の用途が「管理・ガバナンス / cost」に近いか確認する。
  • 強みである「BYOL 形態のライセンス権利数と資源が必要とする数量をテナンシ全体で可視化する。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

管理・ガバナンスcostoperational