はじめに
前回の記事では、FinOps を「クラウド支出を価値の観点で評価し、意思決定に活かすための運用モデル」として整理しました。
FinOps を学び直す中で、次のような課題に心当たりがある方も多いのではないでしょうか。
- コストの増減理由が分からない
- 予算と実績が合わない
- エンジニアと財務で会話が噛み合わない
- 最適化の優先順位が決められない
これらの問題を考えていく中で気づいたのは、「コストをどう解釈するかの前提」が揃っていないと、どんな議論も成立しないということでした。
同じ「コスト」という言葉でも、
- 請求額を見ているのか
- 割引後の単価ベースなのか
- 実際の利用に基づく実効コストなのか
によって意味が大きく変わります。
この前提が揃っていない状態では、どれだけレポートを作っても、どれだけ議論しても、結論はブレてしまいます。
そこで重要になるのが、コストデータを共通の「言語」で扱うための仕様である FOCUS です。
FOCUS は「データ形式を揃える」だけでなく、コストの意味を揃えるための仕組みです。
FOCUS とは何か
FOCUS (FinOps Open Cost and Usage Specification) は、クラウド・SaaS・オンプレミスを含むコストデータを共通の形式で扱うためのオープン仕様です。
FOCUS は単なるデータ形式ではなく、「コストをどう理解するか」という前提を揃えるための仕様 です。これにより、クラウドや契約形態が異なっても、同じ意味でコストを比較できるようになります。
FOCUS によって、以下のような状態を実現できます。
- コストと使用量を一貫した構造で扱える
- クラウドや契約形態を跨いでも同じ意味で比較できる
- 実コスト (請求額) と実効コスト (償却後) を同時に扱える
つまり、FinOps における「共通言語」を提供するのが FOCUS です。
なぜ FOCUS が必要なのか
FOCUS が重要なのは、単にデータを揃えるためではなく、「コストの意味」を揃えるためです。
コストの定義がバラバラ問題
クラウドのコストには、少なくとも次のような種類があります (FOCUS で定義されている代表的なコスト分類)。
-
ListCost: 定価ベースのコスト -
ContractedCost: 契約割引後のコスト -
BilledCost: 実際の請求書に計上されるコスト。請求額 -
EffectiveCost: コミットメント割引を按分 (償却) した後の実効コスト
これらを区別せずに集計すると、
- 割引の効果が正しく見えない
- チャージバック1の金額がズレる
- コスト削減の議論が成立しない
といった問題が発生します。
「何に対する料金か」と「どう決まった価格か」は別の話
クラウドのコストを考える時に混乱しやすいのが、「何の料金なのか」と「どういう価格で計算されたのか」をいっしょに考えてしまうことです。
たとえば、身近な買い物で考えてみます。
- スーパーでりんごを買った (＝利用した)
- まとめ買い割引が適用された (＝割引された)
この時、
- 「りんごを買った」という事実 (何に対する料金か)
- 「割引されて安くなった」という価格の話 (どう決まった価格か)
は別の話です。
クラウドでも同じで、
-
"Usage": 使った分の料金 -
"Purchase": 予約 (Reservation) や節約プラン (Savings Plan) の購入
といった「料金の種類 (Charge)」と、
-
"Standard": 通常価格 -
"Committed": 予約割引など
といった「価格の決まり方 (Pricing)」は別の軸になります。
この 2 つを混ぜてしまうと、
- 購入と利用が区別できなくなる
- 割引の影響が見えなくなる
- 二重計上が発生する
といった問題が起きます。
FOCUS では、この2つを明確に分けて扱うことで、コストの構造をシンプルに理解できるようにしています。
「いくら払ったか」と「実際いくらで使えたか」は違う
もう一つ重要なのが、「実効コスト（EffectiveCost）」の考え方です。
これも身近な例で考えると分かりやすいです。
たとえば、月額 10,000 円のサブスクサービスを、年間一括払いで 120,000 円が割引されて 96,000 円で購入したとします。
この場合、
- 実際に支払った金額 → 年間 96,000 円 (請求額)
- サービスを利用した月に按分される価値ベースの金額 → 月あたり 8,000 円 (実効コスト)
つまり、
-
請求額 (
BilledCost) は「購入時に一括で発生」 -
実効コスト (
EffectiveCost) は「利用した月で按分される」
という関係になります。
クラウドでも同じことが起きています。
予約インスタンス (Reserved Instances) や節約プランなどのコミットメント割引を使うと、
- 請求としては「購入費用」が発生する
- その割引効果は「利用したリソース」に按分される
という構造になります。
そのため、
-
BilledCost(請求額) だけを見ると「高く見える」 -
EffectiveCost(実効コスト) を見ると「実際は安く使えている」
というズレが発生します。
つまり
-
BilledCost: いくら払ったか -
EffectiveCost: 実際いくらで使えたか
ということです。
特にチャージバックやコスト配賦2では、「誰がどれだけの価値を使ったか」を見る必要があるため、EffectiveCost が重要になります。
FOCUS の本質は「カラムの意味」を理解すること
FOCUS は「1 行＝ 1 つの課金データ (レコード)」として構成されています。ただし、重要なのはレコードそのものではなく、その中にある「カラム (列) の意味」です。
ここでは、「Learning FOCUS (Microsoft Community Hub)」を読みながら整理した、主要なカラムの考え方をまとめます。
1. コストは 4 種類で考える
FOCUS ではコストを以下の 4 つで整理します。
-
ListCost: 定価ベースのコスト -
ContractedCost: 契約割引後のコスト -
EffectiveCost: コミットメント割引を按分 (償却) した後の実効コスト -
BilledCost: 実際の請求書に計上されるコスト。請求額
「どのコストを見ているのか」を常に意識することが重要です。
これらは似ているようで役割が異なります。
例として、仮想マシンを利用しているケースで考えてみます。
- 定価：100 円/時間 (
ListCost) - 契約割引：20% → 80 円/時間 (
ContractedCost) - さらに節約プランにより実質 50 円/時間で利用 (
EffectiveCost)
この時、
-
ListCost: 100 円 × 使用量 → 割引前の理論上のコスト -
ContractedCost: 80 円 × 使用量 → 契約条件ベースのコスト -
EffectiveCost: 50 円 × 使用量 → 実際にどれくらいのコストで使えたか -
BilledCost: 購入費用などを含めた実際の請求額
となります。
たとえば、
- 「いくら払ったか」を知りたい場合 →
BilledCost - 「実際にどれくらいのコストで使えたか」を知りたい場合 →
EffectiveCost - 「どれだけ割引が効いているか」を知りたい場合 →
ListCostとContractedCostとの差分
といったように、目的によって使い分ける必要があります。
これを区別せずに集計すると、コスト削減の効果や実態を正しく把握できなくなります。
FOCUS は「コストを 1 つにまとめる」のではなく、「目的ごとに正しく使い分ける」ための設計になっています。
2. Charge × Pricing で整理する (最重要)
FOCUS の中核となる考え方が、「Charge（料金の性質＝料金の種類）」と「Pricing（価格の決まり方＝価格モデル）」を分けることです。
ChargeCategory : 料金の種類 (何に対する料金か)
-
"Usage"(使用量)
一定期間にクラウドサービスを実際に利用・消費した量に基づいて発生する料金- 例 : 仮想マシンの稼働時間、ストレージ使用量など
-
"Purchase"(購入)
サービスや権利を取得する際に発生する購入型の料金- 例 : 予約インスタンスや節約プランの購入など
-
"Credit"(クレジット)
クラウドプロバイダーから提供される割引や無償利用枠、インセンティブ -
"Tax"(税金)
法令や規制に基づき課される税金や公的手数料 -
"Adjustment"(調整)
上記のいずれにも直接当てはまらない調整目的の料金- 例 : 請求書との整合性を取るための補正や端数調整など
PricingCategory : 価格モデル (どのように単価が決まったか)
-
"Standard"(標準)
あらかじめ定められた単価で課金される 固定的な価格モデル -
"Committed"(コミット)
一定期間または一定金額の利用を事前に約束 (コミット) することで、割引が適用される価格モデル -
"Dynamic"(変動)
需給や市場条件などにより価格が変動する価格モデル -
"Other"
上記いずれにも当てはまらない例外的・独自的な価格モデル
Charge × Pricing のポイント
ポイントは、「何に対する料金か」と「どう決まった価格か」を分けることです。
これが重要なのは、混ぜてしまうとコストの意味が分からなくなるためです。
たとえば
- 仮想マシンを使った料金 (
ChargeCategory = "Usage") - 節約プランの購入 (
ChargeCategory = "Purchase")
は、そもそも性質が異なるコストです。
さらに、その ChargeCategory = "Usage" に対して
- 通常料金 (
PricingCategory = "Standard") - コミットメント割引適用 (
PricingCategory = "Committed")
といった価格の違いがあります。
これを分けずに集計してしまうと、
- 購入費用と利用料金が混ざる
- 割引の効果が見えなくなる
- コスト削減の評価ができない
といった問題が発生します。
Charge × Pricing の関係
「Charge (料金の種類)」と「Pricing (価格モデル)」の関係を下表で示します。
| Standard (標準) |
Committed (コミット) |
Dynamic (変動) |
|
|---|---|---|---|
|
Usage (使用量) |
通常利用料金 (例: VM 従量) |
割引適用利用 (RI3/SP4 適用) |
スポット利用など (例: Spot VM) |
|
Purchase (購入) |
ー | コミット購入 (RI/SP 購入) |
ー |
|
Credit (クレジット) |
価格モデルの 概念なし |
←同じ | ←同じ |
|
Tax (税金) |
価格モデルの 概念なし |
←同じ | ←同じ |
|
Adjustment (調整) |
価格モデルの 概念なし |
←同じ | ←同じ |
-
上表の見方
-
縦軸 (
ChargeCategory) : 何に対する料金か-
"Usage"→ 実際に使った分 -
"Purchase"→ 買ったもの (予約インスタンスなど) -
"Credit"/"Tax"/"Adjustment"→ 補助的なもの
-
-
横軸 (
PricingCategory) : どういう価格で計算されたか-
"Standard"→ 普通の従量課金 -
"Committed"→ 予約インスタンス／節約プランの割引適用 -
"Dynamic"→ 市場価格 (スポット利用など)
-
-
縦軸 (
-
上表で読み取って欲しいこと (例)
-
"Usage"×"Standard"→ 従量課金での利用 -
"Usage"×"Committed"→ コミットメント割引が適用された利用 -
"Purchase"×"Committed"→ コミットメント割引を得るための購入
-
このように FOCUS では、
- 「何に対する料金か (Charge)」
- 「どういう価格で計算されたか (Pricing)」
を組み合わせて考えることで、コストの意味を正しく分解できるようになっています。
この 2 つの軸を分けて考えることで、「何にお金を使っているのか」 と 「なぜその金額になっているのか」 を別々に説明できるようになります。
3. 数量と単価を分けて考える
FOCUS では「数量 (Quantity)」と「単価 (UnitPrice)」を明確に分けて考えます。
数量 (Quantity)
数量には目的ごとに複数の種類があります。
-
PricingQuantity: 課金計算に使われる数量 -
ConsumedQuantity: 実際に消費した使用量
一見すると同じように見えますが、クラウドではこの 2 つが一致しないことがあります。
たとえば、仮想マシンを 24 時間利用した場合でも、「100 時間単位で課金される」ようなサービスでは、
-
ConsumedQuantity: 24 時間 (実際の使用量) -
PricingQuantity: 0.24 (課金単位ベースの数量)
となります。
つまり、「実際に使った量」と「課金の計算に使われる量」は別物です。
このように、「実際の使用量」が「課金ルールに基づいた数量」に変換されることで、最終的なコストが計算されます。
FOCUS では、コスト計算では ConsumedQuantity ではなく、PricingQuantity を使用する点も重要です。これは、実際の課金が「課金単位」に基づいて行われるためです。
この関係を図で表すと次のようになります。
このように、FOCUSでは「使用量」そのものではなく、「課金のルールに基づいた数量」を使ってコストを計算します。
単価 (UnitPrice)
単価にも用途ごとに複数の種類があります。
-
ListUnitPrice: 定価 -
ContractedUnitPrice: 契約ベース (契約割引後) の単価 -
x_EffectiveUnitPrice: コミットメント割引を反映した実効単価 -
x_BilledUnitPrice: 請求書ベースの単価
特に重要なのはこの違いです。
-
ContractedUnitPrice: 比較用の基準 -
x_EffectiveUnitPrice: 実際の結果 (コミットメント割引適用後)
数量 × 単価でコストを理解する
これらを組み合わせることで、
- 「どれだけ使ったか (数量)」
- 「いくらだったか (単価)」
を分解して理解することができます。
FOCUS では「コスト」を単純な結果として扱うのではなく、「数量 × 単価」 という構造に分解して考えることが前提になっています。これにより、「なぜそのコストになったのか」を数量と単価の両面から説明できるようになります。
Quantity × UnitPrice と Cost 列の関係
| 観点 | 正しい方法 | 理由 |
|---|---|---|
| コストの構造を理解したい | Quantity × UnitPrice | コストの生成ロジックを理解するため |
| 実務で分析したい |
Cost 列 (EffectiveCost など) |
按分・割引・購入費用などが反映されているため |
| RI/SP の効果を測りたい | EffectiveCost |
自前で計算できないため |
| 請求額を知りたい | BilledCost |
実際の支払い額だから |
実務での使いどころ
FOCUS の考え方は、そのまま実務に直結します。
たとえば Power BI でレポートを作る場合：
- チャージバック →
EffectiveCostを使用 - 削減効果 →
ContractedCostとEffectiveCostの差分 - 利用傾向分析 →
ChargeCategory = "Usage"のみを集計
といったように、実務では、FOCUS のカラムを「どの分析でどれを使うか」という判断基準として使えることが重要です。
さらに Azure Cost Management の FOCUS データセットでは、ChargeCategory や PricingCategory をそのまま Power BI に取り込めます。
これにより、次のような「実務判断」が明確になります。
- 利用料金だけを分析したい →
ChargeCategory = "Usage"でフィルター - コミットメント割引の効果を測りたい →
EffectiveCostを使用 - 契約割引の効果を見たい →
ListCostとContractedCostの差分 - 請求書ベースで予算管理したい →
BilledCostを使用
このように、FOCUS のカラムは「概念を理解するため」だけでなく、どの指標を使えば正しい議論になるかを判断するための実務ツールとして機能します。
同じコストデータでも、
-
BilledCostを使うと「いくら支払ったか」が分かり -
EffectiveCostを使うと「実際にどれくらいのコストで利用できたか」が分かる
といったように、使う指標によって意味が大きく変わります。
また、
- 予約インスタンスや節約プランの効果測定
- コストの責任分解 (チーム別コスト配賦)
- 異常検知やトレンド分析
といったユースケースでも、FOCUS のカラム設計がそのまま活きてきます。
FOCUS は「データを揃えるための仕様」ではなく、目的に応じて正しく使い分けるための設計であることが分かります。
まとめ
FOCUS は単なるデータ仕様ではなく、「コストをどう解釈するかの前提」を揃えるための仕組みだと感じました。
FinOps を実践する上で重要なのは、
- コストを正しく「測る」こと
- そして、同じ意味で「理解できる状態」を作ること
です。
その基盤となるのが FOCUS です。
これまで「なんとなく」扱っていたコストも、FOCUS の視点で整理することで、その意味を明確に説明できるようになると感じました。
参考文献