OCI License Manager

解決する課題

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

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

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

主要概念と用語

• ライセンスレコード（License Record）: 保有しているライセンスの実体を登録する単位。製品名、保有数（コア／プロセッサ数など）、サポート終了日（EOL）といった購入済みライセンスの情報を表す
• 製品ライセンス（Product License）: 管理対象のソフトウェア製品ごとに作る入れ物。ライセンスの種別（BYOL かライセンス込みか）や単位、保有上限などを定義し、配下に複数のライセンスレコードを束ねる
• BYOL（Bring Your Own License）: 自社購入済みライセンスをクラウドに持ち込む形態。License Manager の主な管理対象
• ライセンス込み（License Included）: クラウド利用料にライセンス料が含まれる形態。BYOL と区別して扱う
• 消費量（Consumed）: 対象リソースが実際に使っているライセンス量。OCI 側のリソース利用状況から自動的に集計される
• しきい値（Threshold）: 製品ごとに設定する警告ライン。消費量がここを超えると超過として可視化・通知できる
• イメージ（Image）との関連付け: 製品ライセンスを特定のプラットフォームイメージなどに紐づけ、そのイメージから起動したリソースの消費を自動カウントさせる仕組み

仕様・制限・クォータ

• 管理の中心は 製品ライセンスと、その配下に登録するライセンスレコードの二階層。保有量はレコードの合計、消費量は実リソースから集計される
• 消費量はテナンシ全体（複数コンパートメント・リージョン）を横断して集計される。リージョンごとにツールを分ける必要がない
• しきい値は製品ライセンス単位で設定でき、保有上限に対する超過や接近を監視できる
• 管理できるのは主に BYOL 形態のライセンスで、ライセンス込みのリソースとは区別して扱う
• ライセンスレコード数や製品ライセンス数にはテナンシ単位のサービス制限が掛かる場合があり、上限はサービスリクエストで引き上げを申請する
• 消費量の集計は対象リソースの種類やイメージとの関連付けに依存する。関連付けが無いリソースは自動カウントされないことがある

内部の仕組み

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

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

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

• 購入と同時にレコード登録: ライセンスを買ったら速やかにライセンスレコードへ反映し、保有量を常に最新に保つ
• 製品ごとにしきい値を設定: 保有上限の手前にしきい値を置き、超過する前に気づけるようにする
• イメージと関連付けて自動集計: 対象製品を特定のプラットフォームイメージに紐づけ、手計算ではなく自動カウントで消費量を取る
• EOL（サポート終了）を管理に含める: ライセンスレコードのサポート終了日を活用し、更新やリプレース計画を前倒しで立てる
• Notifications で通知を運用に組み込む: しきい値超過などのイベントをEvents / Notifications に流し、担当者へ自動連絡する
• 定期レビューを習慣化: 監査前だけでなく定期的に消費量と保有量を見直し、過剰購入・不足の両方を抑える

運用・監視

• 製品ライセンスのダッシュボードで、保有量・消費量・超過状況を一覧で確認する。監査時の証跡としても使える
• しきい値超過などの状態変化を Events で捕捉し、Notifications へ通知して担当者にエスカレーションする
• 「誰がライセンスレコードや製品ライセンスを変更したか」は OCI Audit で追跡する
• 消費量が想定とずれる場合は、イメージや対象リソースの関連付けが正しいかを点検する（関連付け漏れは過小集計の原因）
• 監査・契約更新のタイミングに合わせ、保有量の棚卸しと不要リソースの整理を定期的に行う

コスト

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

セキュリティ

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

関連サービス・比較

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

なお OCI 内では、超過などの通知連携に Events / Notifications、操作監査に 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 "OCPU" \
  --images '[{"productId":"OracleDatabaseEE"}]'

# 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 summarize \
  --compartment-id "$TENANCY_OCID" --output table