TL

Cloud Service

OCI Cost and Usage Reports

請求明細を行レベルで深掘りできる。Cost and Usage Reports はテナンシのコスト・使用量を詳細 CSV として日次で Object Storage に自動出力し、BI や外部分析に取り込める。AWS の Cost and Usage Report(CUR)に相当。

中級コスト最適化運用上の優秀性
最終更新: 2026-06-28公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.リソース・タグ単位の詳細明細を CSV として日次で自動生成する。
  • 2.Oracle 側テナンシのバケットに出力され、namespace に bling を指定して読む。
  • 3.業界標準フォーマットの FOCUS 形式でも出力でき、マルチクラウド横断分析に向く。

解決する課題

コンソールの集計画面(Cost Analysis)では足りない「行レベルの明細」を機械可読な形で取得し、独自の粒度で分析・配賦できるようにします。請求書の合計だけでは見えない、リソースごと・タグごとの内訳まで掘り下げられます。

  • どのリソースが、いつ、どれだけのコストと使用量を生んだのかを明細レベルで知りたい
  • Cost Analysis のグラフでは表現しきれない自由な軸で集計・ピボットしたい
  • BI ツールや Autonomous Database に取り込み、社内のカスタムダッシュボードを作りたい
  • チーム/プロジェクトへの**チャージバック(実費配賦)**の根拠となる生データが欲しい
  • 複数クラウドのコストを統一フォーマットで並べて横断分析したい

主要概念と用語

  • Cost and Usage Reports(コスト・使用状況レポート): テナンシのコストと使用量の詳細明細を CSV として定期生成し、Object Storage バケットに出力する機能。AWS の Cost and Usage Report(CUR)に相当する
  • Cost Report(コストレポート): 各明細行に**コスト(金額)**情報を含むレポート。請求・配賦の分析に使う
  • Usage Report(使用量レポート): 各明細行に**使用量(数量)**情報を含むレポート。コストとは別に消費リソース量を見る用途に使う
  • bling バケット: レポートが出力される Object Storage の場所。利用者テナンシではなく Oracle 側が管理するテナンシのバケットに出力され、参照時は namespace に bling、バケット名にテナンシ OCID を指定する
  • FOCUS(FinOps Open Cost and Usage Specification): FinOps Foundation が策定したコスト・使用量データの業界標準フォーマット。OCI もこの形式でレポートを出力でき、他クラウドのデータと共通スキーマで突き合わせられる
  • コスト追跡タグ(Cost-Tracking Tag): 定義済みタグに「コスト追跡」属性を付けたもの。レポートの明細にタグ列として現れ、タグ単位の配賦に使う
  • Cost Analysis: 同じ課金データをコンソール上で集計・可視化する読み取り系の機能。レポートは「生の明細」、Cost Analysis は「集計済みの可視化」という役割分担になる

仕様・制限・クォータ

  • 出力形式は CSV(圧縮された形で出力されるのが一般的)。各行が利用明細の 1 レコードに対応し、リソースやサービス、課金期間、コストまたは使用量などの列を持つ
  • 生成は概ね日次で、前日までの利用分が追記されていく。リアルタイムではなく、当日のごく直近の利用は反映途中のことがある
  • 出力先は Oracle 側テナンシの bling バケットで、利用者は読み取りのみを行う。レポートの保管・生成自体は OCI 側で行われる
  • コストデータには反映の遅延がある。レポートに明細が現れるまで時間差があるため、即時の支出監視には向かない
  • FOCUS 形式は別系統のレポートとして取得でき、列構成が業界標準スキーマに沿う。標準のネイティブ CSV とは列の定義が異なる
  • タグ列はコスト追跡属性を付けた定義済みタグが対象。タグ付け前に発生したコストは遡って分類されず、明細にも反映されない
  • 参照には専用の権限が必要。テナンシ全体の明細は機微情報のため、付与先を限定する

内部の仕組み

OCI の課金エンジンが各サービスの使用量を継続的に計測・集計し、その結果を Cost Analysis(可視化)・Budgets(予算評価)・Cost and Usage Reports(明細出力)という複数の出口に供給します。レポートはこのうち「最も粒度の細かい明細」を担います。

  • 計測 → 集計 → 明細出力の流れで、課金システムが日次で前日までの明細を CSV にまとめ、bling バケットへ追記・出力する
  • 出力先は利用者テナンシのバケットではなく Oracle 側が管理するバケットで、利用者は Object Storage の API・CLI で bling namespace を指定して読み取る。レポートの生成・保管に利用者の Object Storage 料金は基本的にかからない
  • 明細行にはコスト追跡タグがキー列として展開され、タグの付いたリソースのコストはそのタグ値で分類できる。タグなしのコストは「タグなし」として扱われる
  • 詳細分析では、出力された CSV を Autonomous Database や外部 BI ツールに取り込み、SQL やダッシュボードで自由に集計するのが定石。Oracle は分析向けのテンプレートも提供している
  • FOCUS 形式を選ぶと、同じ課金データが業界標準スキーマに変換されて出力され、他クラウドの FOCUS データと同一の列定義で突き合わせられる
バケットの場所と反映遅延に注意

レポートは自分のテナンシのバケットではなく、Oracle 側テナンシの bling バケットに出力されます。CLI で読むときは namespace に bling、バケット名にテナンシ OCID を指定します。自分のバケットを探しても見つかりません。 また、明細には反映の時間差があるため、レポートは「即時の支出ブロック」ではなく「日次の詳細分析」用途として設計します。

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

  • 可視化と明細を使い分ける: ざっくりした傾向把握は Cost Analysis、リソース単位の精密な配賦や独自集計は Cost and Usage Reports と役割を分ける
  • 取り込みを自動化する: 日次で増える CSV を定期的に取り込むパイプライン(Functions やスケジューラ)を組み、Autonomous Database や BI に自動ロードする
  • コスト追跡タグを早期に標準化: CostCenterProjectEnvironment などの定義済みタグをコスト追跡対象にし、IaC(Terraform 等)でタグ付けを強制する。後付けは遡れないため初期が肝心
  • 配賦の単位を設計に織り込む: コンパートメントとコスト追跡タグの両軸で明細を集計し、ショーバック(見える化)かチャージバック(実費請求)かに応じてレポートの集計軸を決める
  • マルチクラウドなら FOCUS: 他クラウドのコストと横断比較する基盤を持つなら、ネイティブ CSV より FOCUS 形式で揃えると突き合わせが楽になる
  • 保持ポリシーを決める: 取り込んだ後の明細データを社内ストレージに長期保管するかは、監査要件と分析要件に応じて方針を決める

運用・監視

  • レポートが見つからない: 自分のテナンシのバケットを探していないか確認する。namespace は bling、バケット名はテナンシ OCID を指定する
  • 明細が当日分まで揃わない: 反映には時間差があるのが正常。前日までの分は揃うが、当日のごく直近は反映途中のことがある
  • タグ列が空・想定と違う: コスト追跡属性を付けた定義済みタグを使っているか、リソースに実際にタグが付与されているか、タグ付け前の期間ではないかを確認する
  • 取り込み先で列が合わない: ネイティブ CSV と FOCUS 形式は列定義が異なる。どちらのレポートを取得しているかを取り込み側のスキーマと照合する
  • 権限不足で読めない: 後述の IAM ポリシー(使用量レポート読み取りの権限)が付与されているかを確認する
  • 集計で十分なら: 行レベルの明細が不要なら、無理にレポートを取り込まず Cost Analysis の集計と Budgets のアラートで運用を軽くする

コスト

Cost and Usage Reports の生成・出力機能そのものは、基本的に追加料金なしで利用できるのが一般的です。レポートが出力される bling バケットは Oracle 側が保持するため、その保管に対して利用者の Object Storage 料金は通常かかりません。

課金されるのは分析対象であるクラウドリソースの利用料が中心です。ただし、ダウンロードした CSV を自分のバケットに保管する場合のストレージ料や、取り込み先の Autonomous Database・BI ツールの稼働費、定期取り込みを担う Functions の実行分など、周辺で費用が生じる場合があります。レポートの価値は、これらを使って本体のリソース費用を最適化する点にあります。

セキュリティ

  • 明細は機微情報として扱う: テナンシ全体のコスト・使用量明細は組織の支出構造を露わにするため、ファイナンスや配賦担当など限定したグループにのみ読み取り権限を付与する
  • IAM ポリシーで read を絞る: 使用量レポートの読み取り(read usage-report 相当)を専用グループに割り当て、最小権限にする
  • 取り込み先の保護: CSV を取り込む Autonomous Database や BI、保管用バケットへのアクセスも同様に絞り、明細データが横展開されないようにする
  • タグの整合性を保つ: コスト追跡タグはタグ名前空間(Tag Namespace)で一元管理し、自由記述タグの乱立で配賦が壊れないようガバナンスを効かせる
  • 取得経路の監査: 誰がいつレポートを取得・取り込みしたかは OCI Audit で追跡できるようにし、明細へのアクセス自体を記録する
役割分担を押さえる

「ざっくりいくらか」は Cost Analysis、「行レベルの明細が欲しい」は Cost and Usage Reports、「超えそうなら知らせる」は Budgets、「これ以上作らせない」は Compartment Quota。 レポートは可視化ではなく生データの供給が役割、と割り切って設計します。

関連サービス・比較

OCI のコスト管理は、可視化(Cost Analysis)、予算とアラート(Budgets)、そして詳細明細の出力(Cost and Usage Reports)で役割が分かれています。明細出力という点で最も近いのは Cost Analysis であり、両者の違いを押さえると使い分けが明確になります。

観点Cost and Usage ReportsCost Analysis
主な役割行レベルの明細を CSV で供給集計済みコストをコンソールで可視化
出力形式CSV(ネイティブ/FOCUS)グラフ・表(画面上)
粒度リソース・タグ単位の明細サービス・コンパートメント等の集計
取り込み先BI・Autonomous Database 等へコンソール内で完結
出力場所Oracle 側の bling バケットなし(画面表示)
AWS の相当Cost and Usage Report(CUR)Cost Explorer

ハンズオン / CLI例

# 1) レポートが出力される bling バケットの中身を一覧する
#    namespace は固定で "bling"、bucket-name はテナンシ OCID を指定する
oci os object list \
  --namespace "bling" \
  --bucket-name "$TENANCY_OCID"

# 2) 接頭辞でコストレポート/使用量レポートを絞り込む
#    reports/cost-csv はコスト、reports/usage-csv は使用量の明細が置かれる
oci os object list \
  --namespace "bling" \
  --bucket-name "$TENANCY_OCID" \
  --prefix "reports/cost-csv"

# 3) 特定のレポートファイル(圧縮 CSV)をローカルにダウンロードする
oci os object get \
  --namespace "bling" \
  --bucket-name "$TENANCY_OCID" \
  --name "reports/cost-csv/0001000000123456.csv.gz" \
  --file "./cost-report.csv.gz"

# 4) ダウンロードした圧縮 CSV を展開して中身を確認する
gunzip -k ./cost-report.csv.gz

# 5) 参考: Cost Analysis 相当の集計は usage-api で要求できる
#    詳細明細はレポート、即時の集計クエリはこの API、と使い分ける
oci usage-api usage-summary request-summarized-usages \
  --tenant-id "$TENANCY_OCID" \
  --time-usage-started "2026-06-01T00:00:00Z" \
  --time-usage-ended "2026-06-28T00:00:00Z" \
  --granularity "DAILY"

OCI Service

OCI Cost and Usage Reportsを実務で読む

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

解決すること

管理・ガバナンス

比較で見る軸

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

導入後に効く点

Oracle 側テナンシのバケットに出力され、namespace に bling を指定して読む。

先に潰すリスク

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

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

判断チェックリスト

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

次に確認する観点

管理・ガバナンスcostoperational