1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

お題は不問！Qiita Tech Festa 2026で記事投稿！
Qiita Tech Festa20262026年7月13日まで開催中！
@tetsuya-ooooo
in

FOCUS データ分析の道しるべ - FinOps で迷わないための見方を整理してみる

1
Last updated at Posted at 2026-07-03

はじめに

FinOps や FOCUS の概念を理解すると、次に必ずぶつかる壁があります。

「で、実際このデータどう見ればいいの？」

FOCUS は非常に優れたデータモデルですが、構造がしっかりしている分、「どこから手をつければいいか分からない」 という状態になりやすいと思います。

本記事では、FOCUS データを分析するときに迷わないための 「思考の順番 (道しるべ)」 を整理します。

これは FOCUS の仕様を説明する記事ではなく、Azure の実データをベースに、実務で迷わないために「どの順番でどう判断すべきか」を整理した分析ガイドです。

  • どの軸から見るべきか
  • どの分類を先に分けるべきか
  • どのコスト指標を使うべきか

といった「分析の流れ」を明確にすることで、FOCUS データを扱う際の混乱を減らし、実務で使える形に落とし込みます。

1. FOCUS データの全体構造を理解する

FOCUS データを分析するうえで、最初に押さえておきたいのは、「購入」「使用量」「Azure リソース」の関係がどのようにつながっているか です。

この構造を正しく理解していないと、分析の途中で次のような典型的な迷いが発生します。

  • 「RI の未使用分 (Committed (Unused)) が ResourceId でリソースに紐づかないのはなぜ？」
  • 「購入 (Purchase) と使用量 (Usage) の関係が分からない...」
  • 「使用量 (Usage) と 購入 (Purchase) を混ぜるとコストが合わなくなる...」

FOCUS の基本構造

FOCUS では、次のような関係が成り立っています。

  • 使用量データ (Usage)
    → Azure リソースに紐づく
  • コミットメント割引の購入データ (Purchase (RI1/Savings Plan2))
    → 使用量データに配分される
  • コミットメント割引の未使用分 (Committed (Unused))
    → Azure リソースに紐づかない (＝どのリソースにも割り当てられなかった)

この構造を知らないと、分析の途中で「なぜこのレコードは ResourceId が空なの？」という疑問が必ず出ます。

なぜこの構造が重要なのか

FOCUS を初めて扱う人が最もつまずくポイントは、「使用量 (Usage) と購入 (Purchase) を同じものとして扱ってしまう」 ことです。

たとえば、

  • RI の購入金額が使用量 (Usage) に混ざってしまう
  • 未使用分 (Committed (Unused)) をリソース別に分析しようとして ResourceId が空で困る
  • コストが二重計上されてしまう

これらはすべて、「購入 → 使用量 → リソース」 という流れを理解していないことが原因です。

このステップの目的

この「全体像」の理解は、この後のステップである

  • 期間の軸を決める
  • コストの種類を分ける
  • 使用量を分解する
  • 購入を理解する
  • リソースとの紐づきを見る
  • コスト指標を選ぶ

といった分析の流れを 正しく進めるための前提 になります。

FOCUS は構造がしっかりしているからこそ、「どこが紐づいていて、どこが紐づかないのか」 をあらかじめ押さえておくことが重要です。

2. 「期間」を決める

FOCUS データを分析する際、最初に決めるべき軸が 「期間」 です。
このステップを曖昧にしたまま進めると、請求書の金額と分析結果が一致しないという典型的な問題が発生します。

使用するカラム

  • ChargePeriodStart : 課金期間の開始
  • ChargePeriodEnd : 課金期間の終了

FOCUS の日付カラムはすべて ISO 8601 形式・UTC 基準で記録されています。ここだけ聞くと「当たり前だ」と思うかもしれませんが、この UTC 管理が「月次集計のズレ」を生む最大の原因 になります。

なぜ「期間」が重要なのか

たとえば、4 月の請求を分析したい場合でも、FOCUS の ChargePeriodStart が 2025-03-31T15:00:00Z (UTC) のように前月の UTC 時刻で始まっていることがあります。

これは FOCUS が「課金期間の境界」を UTC で管理しているため、ローカルタイム (JST) で月次を捉えると、月の境界が 9 時間ズレることがあります。

このズレが、

  • 月次集計が請求書と一致しない
  • Power BI の月次グループ化がズレる
  • RI/Savings Plan の使用率が月をまたいで誤計算される
  • 「4 月のコスト」を見ているつもりが、実際には 3 月末の使用量データが混ざっている

といった実務上の問題を引き起こします。

そのため、分析の最初のステップとして、「どの期間を対象にするか」を明確にすることが非常に重要 です。

よくある落とし穴

  1. 請求書の「4 月」と FOCUS の「4 月」が一致しない
    請求書はローカルタイム (JST)、FOCUS は UTC。
    この違いを理解していないと、「FOCUS の集計結果が請求書と合わない」という典型的な誤解が生まれます。
  2. Power BI の月次グループ化がズレる
    Power BI で日付をローカルタイム (JST) として扱うと、FOCUS の UTC 時刻と月の境界がズレることがあります。よって Power Query でタイムゾーンを変換してから月次集計する必要があります。
  3. RI/Savings Plan の使用率が月をまたいで誤計算される
    RI/Savings Plan の使用率は「期間の境界」が非常に重要です。UTC のまま計算すると、コミットメント割引の未使用が別月に飛ぶことがあります。

このステップの目的

期間を正しく決めることで、この後の分析がすべて安定します。

  • コストの種類を分ける
  • 使用量を分解する
  • 購入を理解する
  • リソースとの紐づきを見る
  • コスト指標を選ぶ

これらはすべて 「どの期間を見ているか」 が前提になります。

3. 「コストの種類」を分ける

FOCUS データを分析する際、まず行うべき作業が 「コストの種類を分ける」 ことです。

このステップを曖昧にしたまま進めると、実務で次のような典型的な誤解が発生します。

  • 使用量 (Usage) の分析に RI/Savings Plan の購入 (Purchase (RI/SP)) が混ざる
  • コストが二重計上される
  • 「RI を買ったらコストが増えた」という誤解が発生する
  • 調整 (Adjustment) が使用量 (Usage) に紛れ込み、数字が不自然になる

これらはすべて、ChargeCategory (料金の種類) を分けていないことが原因です。

FOCUS のコストは大きく 3 種類

種類 フィルター 意味
使用量
(Usage) 		ChargeCategory = "Usage" 実際に利用・消費した分
購入
(Purchase) 		ChargeCategory = "Purchase" サービスや権利の購入
(RI/Savings Plan・サードパーティ製品など)
調整
(Adjustment) 		ChargeCategory = "Adjustment" 返金・補正などの調整
(利用や契約の「価格」とは直接関係しない)

なぜ最初に分ける必要があるのか

  1. Usage と Purchase を混ぜると「コストが増えた」ように見える
    RI/Savings Plan を購入した月は Purchase が発生します。これを Usage と混ぜると、「最適化したのにコストが増えた」 という誤解が生まれます。
  2. Usage の分析に Purchase が紛れ込む
    RI/Savings Plan の購入は「利用」ではありません。Usage に混ざると、リソース別のコスト分析が壊れます。
  3. Adjustment が Usage に混ざると数字が不自然になる
    返金や補正は「利用のコスト」ではないため、Usage に混ざると日次・月次のグラフが乱れます。

:point_up: ポイント

  • Purchase は「コスト」ではなく「契約の購入」
    RI/Savings Plan の購入は Usage と性質が異なります。Usage と同じ軸で扱うと分析が壊れます。
  • Adjustment は「利用のコスト」ではない
    返金・補正は Usage の増減とは関係ありません。Usage に混ぜると日次のグラフが乱れます。
  • Usage の分析は Usage のみで行う
    Purchase や Adjustment を混ぜると、リソース別・サービス別の分析が正しくできません。

このステップの目的

この「分類」をまず行うことで、この後の分析がすべて安定します。

  • 使用量 (Usage) の内訳（Standard / Committed / Dynamic）
  • RI/Savings Plan の使用分 (Committed (Used))・未使用分 (Committed (Unused))
  • リソースとの紐づき
  • コスト指標（EffectiveCost / ContractedCost / BilledCost）の使い分け

FOCUS の分析は Usage → Purchase → Adjustment の順に分けてから進めるという流れが基本になります。

4. 「使用量 (Usage)」を分解する

FOCUS データの分析で最も重要なのが、使用量 (Usage) を正しく分解することです。

Usage は一見「全部同じ利用コスト」に見えますが、実際には 3 つのまったく性質の異なる課金方式 が混在しています。

この違いを理解していないと、次のような典型的な誤解が発生します。

  • Standard と Committed を同じ単価で扱ってしまう
  • RI/Savings Plan の「使用分 (Committed (Used))」と「未使用分 (Committed (Unused))」を混ぜてしまう
  • リソース別のコストが不自然になる
  • 「RI を買ったのにコストが増えた」という誤解が発生する

Usage の分解は、後続の分析 (RI/Savings Plan、コスト指標、リソース紐づき) の土台になります。

Usage の 3 分類 (ここを理解すると FOCUS が一気に分かる)

4-1. 通常課金 (Standard)

  • フィルター
    PricingCategory = "Standard"
  • 特徴
    • 単価が固定 (定価)
    • コストは「単価 × 数量」で算出
    • 最もシンプルな課金方式
  • 実務でのポイント
    • ResourceId 値はリソースに紐づくため、リソース別の分析が可能
    • Standard は 「そのままの利用コスト」 なので、EffectiveCost と BilledCost がほぼ一致する

4-2. コミットメント割引 (Committed)

  • フィルター
    PricingCategory = "Committed"
    CommitmentDiscountType = "Reservation" or "Savings Plan"
  • 内訳 (ここが重要)
    • 区分 フィルター 意味
      使用分
      (Used)       		CommitmentDiscountStatus = "Used" 割引が適用された利用
      未使用分
      (Unused)       		CommitmentDiscountStatus = "Unused" 割引が使われなかった分
      (無駄)
  • 実務でのポイント
    • Committed (Used)
      • 「割引が適用された利用」
      • ResourceId 値はリソースに紐づくため、リソース別の分析が可能
        ただし、Standard や Dynamic と性質が異なるため、同じ扱いをしてしまうと分析がズレる
    • Committed (Unused)
      • 「使われなかったコミットメント」
      • リソースとは紐づかない
  • コミット指標との関係
    • 実態を見る → EffectiveCost
    • 割引効果を見る → ContractedCost
    • Committed (Unused) は「無駄コスト」として最適化対象

4-3. スポット課金 (Dynamic)

  • フィルター
    PricingCategory = "Dynamic"
  • 特徴
    • 市場価格に応じて単価が変動
    • Standard と違い、単価が一定ではない
    • ただし、Usage としては Standard と同じく「利用コスト」
  • 実務でのポイント
    • ResourceId 値はリソースに紐づくため、リソース別の分析が可能

なぜこの分解が重要なのか

  • Usage は「全部同じ利用コスト」ではない
    Standard や Dynamic と Committed は性質がまったく異なります。ここを混ぜると、RI/Savings Plan の効果が正しく見えません。
  • Committed の「Used」と「Unused」は別物
    • Committed (Used) は「割引が適用された利用」 → 最適化されている利用
    • Committed(Unused) は「使われなかったコミットメント」 → 無駄コストとして最適化対象
      → リソースに紐づかないため、リソース別分析に混ぜてはいけない
  • EffectiveCost の意味は Usage の分解を理解しないと分からない
    EffectiveCost を正しく理解するには、Usage を Standard / Committed / Dynamic に分解して性質の違いを押さえることが前提になります。
    ※EffectiveCost の詳細は後述の「7. コスト指標を選ぶ」で説明

このステップの目的

Usage を Standard / Committed / Dynamic に分解することで

  • RI/Savings Plan の使用率が正しく計算できる
  • 無駄 (Committed (Unused)) が明確に見える
  • リソース別のコストが正しく分析できる
  • コスト指標の使い分けが自然に理解できる

FOCUS の分析は Usage の分解から始まると言っても過言ではありません。

5. 「購入 (Purchase)」を理解する

使用量 (Usage) と購入 (Purchase) は、名前が似ているため同じ軸で扱ってしまいがちですが、FOCUS の分析ではまったく別物として扱う必要があります。

Purchase は「利用のコスト」ではなく、サービスや権利を「買った」という契約情報です。

この違いを理解していないと、次のような典型的な誤解が発生します。

  • 使用量 (Usage) の分析に RI/Savings Plan の購入 (Purchase (RI/SP)) が混ざる
  • コストが二重計上される
  • 「RI を買ったらコストが増えた」という誤解が発生する
  • サードパーティ製品の購入 (Purchase (Vendor)) がリソース別分析に紛れ込む

Purchase は Usage と性質が異なるため、Usage と混ぜて分析してはいけません。

5-1. コミットメント割引の購入 (Purchase (RI/SP))

  • フィルター
    x_PublisherCategory = "Cloud Provider"
    CommitmentDiscountType = "Reservation" or "Savings Plan"
    CommitmentDiscountId != (空欄)
  • 特徴
    • RI/Savings Plan を「購入した」という契約情報
    • Usage とは別レコード
    • Usage とは x_SkuOrderId 値で紐づく
    • 購入レコード単体では意味がない
    • 必ず Usage とセットで見る必要がある
  • 実務でのポイント
    • 「契約の購入」であり、利用のコストではない

:point_up: ポイント

RI/SP の購入レコードにも ResourceId に値が入っていますが、これは Azure リソース (VM・SQL・Storage など) ではありません。RI の場合は「Reservation Order (予約契約)」、Savings Plan の場合は「Savings Plan 契約」を指す ID が入ります。

5-2. サードパーティ製品の購入 (Purchase (Vendor))

  • フィルター
    x_PublisherCategory = "Vendor"
  • 特徴
    • サードパーティ製品 (Marketplace) の購入
    • Usage と紐づかない
    • リソースとは紐づかない (ResourceId は空欄)
  • 実務でのポイント
    • 「契約の購入」であり、利用のコストではない
    • サードパーティ製の購入は、Usage とまったく関係がない

なぜ「購入」を理解する必要があるのか

  1. Usage と Purchase を混ぜるとコストが二重計上される
    RI/Savings Plan の購入は契約であり、利用ではありません。Usage と同じ軸で扱うと、コストが増えたように見えます。
  2. リソース別分析が壊れる
    コミットメント割引の購入 (Purchase (RI/SP)) の ResourceId には Reservation Order ID / Savings Plan 契約 ID が入っています。一方、サードパーティ製品 の購入 (Purchase (Vendor)) の ResourceId は空欄です。
    いずれの場合も、Usage のように Azure リソースへ紐づくものではないため、リソース別分析に混ぜると数字が不自然になります。
  3. RI/Savings Plan の効果が正しく見えなくなる
    RI/Savings Plan の効果は「Usage の Committed (Used/Unused)」で見るべきであり、Purchase を混ぜると分析がズレます。

このステップの目的

Purchase を Usage と分離することで

  • RI/Savings Plan の効果を正しく評価できる
  • 無駄 (Committed (Unused)) が明確に見える
  • リソース別のコストが正しく分析できる
  • コスト指標 (EffectiveCost / ContractedCost) の意味が腹落ちする

FOCUS の分析では、Usage → Purchase → Adjustment の順に分けてから進めるという流れが基本になります。

6. リソースとの紐づきを理解する

FOCUS の分析では、「どのレコードが Azure リソースに紐づくのか」 を正しく理解することが重要です。

同じ ResourceId という名前 (カラム) でも、Usage・Purchase・Adjustment では 意味がまったく異なるため、ここを誤解するとリソース別分析が壊れます。

6-1. Usage の ResourceId (Azure リソースに紐づく)

Usage レコードの ResourceId は、VM・SQL・Storage などの Azure リソースを指す ID です。

例
/subscriptions/{Subscription}/resourceGroups/{ResourceGroupName}/providers/Microsoft.Compute/virtualMachines/{ResourceName}

Usage の ResourceId は リソース別分析の基盤 になります。

6-2. Committed (RI/SP) の ResourceId (契約オブジェクト)

コミットメント割引の Usage > Committed には 2 種類あります。

種類 ResourceId 意味
Committed (Used) Azure リソースの ResourceId 割引が適用された利用
Committed (Unused) 空欄 割引が使われなかった分 (無駄)

:point_up: ポイント

Committed (Unused) は ResourceId を持たないため、リソース別分析に混ぜてはいけません。

Committed (Unused) は「使われなかったコミットメント」であり、Azure リソースに紐づく利用ではありません。

6-3. Purchase の ResourceId (Azure リソースではない)

Purchase レコードは Usage と性質が異なります。

種類 ResourceId 意味
Purchase (RI/SP) RI: Reservation Order の ID
SP: Savings Plan 契約の ID		 契約オブジェクト
(Azure リソースではない)
Purchase (Vendor) 空欄 サードパーティ製品の購入

:point_up: ポイント

コミットメント割引の購入レコードに入っている ResourceId は Azure リソースではありません。RI の場合は「Reservation Order（予約契約）」、Savings Plan の場合は「Savings Plan 契約」を指す ID が入ります。

また、サードパーティ製品の購入は ResourceId が空欄です。

→ どちらもリソース別分析に混ぜてはいけません。

6-4. Adjustment は ResourceId を持たない

Adjustment は返金・補正などの調整であり、Azure リソースの利用とは関係ありません。
よって、ResourceId は空欄です。

→ Usage に混ぜると日次・月次のグラフが乱れます。

まとめ: リソースとの紐づき

カテゴリ ResourceId の意味 リソース別分析に使える？
Usage > Standard Azure リソース :white_check_mark: 使える
Usage > Dynamic Azure リソース :white_check_mark: 使える
Usage > Committed (Used) Azure リソース :white_check_mark: 使える
Usage > Committed (Unused) 空欄 :x: 使えない
Purchase (RI/SP) 契約オブジェクト :x: 使えない
Purchase (Vendor) 空欄 :x: 使えない
Adjustment 空欄 :x: 使えない

Usage の Standard、Dynamic、Committed (Used) 以外は、Azure リソースに紐づくものではないため、リソース別分析に混ぜると数字が不自然になります。

このステップの目的

ResourceId の意味を正しく理解することで

  • リソース別のコストが正しく分析できる
  • Committed (Unused) が正しく見える
  • Purchase を Usage に混ぜてしまう誤りを防げる
  • RI/Savings Plan の効果が正しく評価できる

FOCUS の分析は ResourceId の意味を正しく理解することが前提になります。

7. コスト指標を選ぶ

FOCUS には複数のコスト指標があり、どれを使うかによって分析結果が大きく変わります。

特に、RI/Savings Plan (Committed) の分析では、EffectiveCost / ContractedCost / BilledCost の違いを理解していないと、「最適化したのにコストが増えた」という誤解が発生します。

7-1. EffectiveCost (実態コスト)

  • 何を表す指標か
    コミットメント割引 (RI/Savings Plan) を按分した「実態の利用コスト」 を表します。
    • RI/Savings Plan の割引効果を Usage に按分している
    • Committed (Used/Unused) の影響を含む
    • 実際の利用に近いコスト感を把握できる
  • どんな場面で使うべきか
    • リソース別の実態コストを見たいとき
    • RI/Savings Plan の効果を「利用側」で評価したいとき
    • 最適化の成果を確認したいとき

:point_up: ポイント

EffectiveCost は「請求額」ではありません。あくまで利用の実態を表す指標です。

7-2. ContractedCost (契約コスト)

  • 何を表す指標か
    クラウドベンダーとの契約で定められた契約単価をベースに算出されたコストを表します。
    • 契約単価 × 数量 で算出
    • 契約単価とは、
      • クラウドベンダーとの契約で確定している従量課金単価のこと
      • たとえば、標準の従量課金制で契約した場合は「定価通りの従量課金単価」となる
  • どんな場面で使うべきか
    • クラウドベンダーとの個別契約 (EA 契約など) によるディスカウント全体の効果を測定したいとき
    • RI/Savings Plan の割引効果を、その手前の「契約ベースの単価」と比較して評価したいとき
    • RI/Savings Plan の購入前後の単価比較をしたいとき
    • 結んでいる契約の妥当性 (割引率・単価) を判断・レビューしたいとき

:point_up: ポイント

ContractedCost は「実際の請求額」ではありません。契約で定義された契約単価を、利用数量に適用して算出した計算上のコスト (評価値) です。

7-3. BilledCost (請求コスト)

  • 何を表す指標か
    請求書に記載されるコスト (課金額) を表します。
    • Standard や Dynamic の利用コスト
    • RI/Savings Plan の購入 (Purchase (RI/SP))
    • サードパーティ製品の購入 (Purchase (Vendor))
    • 調整 (Adjustment)
  • どんな場面で使うべきか
    • 請求書と FOCUS の突き合わせ
    • 部門別の請求配賦
    • 予算管理・財務報告

:point_up: ポイント

BilledCost は Usage の実態を表しません。RI/Savings Plan の割引効果は EffectiveCost に按分されるため、BilledCost だけを見ても最適化の効果は見えません。

どの指標を使うべきか

分析目的 使うべき指標 理由
リソース別の実態コストを知りたい EffectiveCost 通常課金に加え、RI/SP の割引分や未使用分も含めて、すべてのリソースの「実質的なコスト」が正しく配分されて見えるため
RI/SP 単体での割引効果 (金額) を評価したい EffectiveCost と
ContractedCost の両方		 割引前の基準となるコスト (ContractedCost) と、適用後のコスト (EffectiveCost) を引き算 (比較) することで、RI/SP でいくら得したかが可視化できるため
RI/SP の「無駄」を管理したい EffectiveCost コミットメント割引の未使用分 (Committed (Unused)) が「無駄コスト」として明確に実費計上されるため
請求書とデータを突き合わせたい BilledCost ベンダーから実際に請求された金額 (課金額) そのものが記録されているため、1 円単位での財務的な一貫性を検証できる
部門別の請求配賦 (社内請求・実費精算) をしたい BilledCost 会計上・財務上のリアルな「支払い実績 (生データ)」をベースとして、社内の配賦ルールに則って各部門へコストを実費精算するため

このステップの目的

このステップの目的は、FOCUS にある複数のコスト指標の違いを整理し、分析の目的に応じて「どの指標を使うべきか」を判断できるようにすることです。

EffectiveCost / ContractedCost / BilledCost は似て見えますが、それぞれが表す意味は大きく異なります。

この違いを理解していないと、RI/Savings Plan の効果評価やリソース別分析がズレてしまうため、コスト指標の選択は FOCUS 分析の中でも重要なステップになります。

まとめ

FOCUS データ分析で重要なのは、次の順番で整理していくことです。

  1. FOCUS データの全体構造を理解する
  2. 期間を決める
  3. コストの種類を分ける
  4. 使用量を分解する
  5. 購入を理解する
  6. リソースとの紐づきを理解する
  7. コスト指標を選ぶ

:point_up: ポイントは、構造そのものではなく「分析の流れ」を踏まえて順番に判断していくことです。

最後に

FOCUS は単なるデータ形式ではなく、FinOps を実践するための共通言語です。

この「道しるべ」をベースに、

  • Power BI などでの可視化
  • コスト最適化の分析

へつなげ、実務の中で活用していただければ幸いです。

  1. Reserved Instances, RI: 予約インスタンス、リザーブドインスタンス ↩

  2. Savings Plan, SP: 節約プラン ↩

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?