Cloud Service
OCI Cost and Usage Reports
請求明細を行レベルで深掘りできる。Cost and Usage Reports はテナンシのコスト・使用量を詳細 CSV として日次で Object Storage に自動出力し、BI や外部分析に取り込める。AWS の Cost and Usage Report(CUR)に相当。
- 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 で
blingnamespace を指定して読み取る。レポートの生成・保管に利用者の 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 に自動ロードする
- コスト追跡タグを早期に標準化:
CostCenter・Project・Environmentなどの定義済みタグをコスト追跡対象にし、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 Reports | Cost 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、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。