月々のクラウド費用を顧客・注文・取引あたりの費用に変える方法

単位コストはクラウド費用を有効な価値単位で割った値

月額のクラウド請求額が3,000万ウォンから4,000万ウォンに増えたという事実だけでは、費用効率が悪化したとは言えません。同じ期間に注文が倍増していれば、1件を処理する費用は下がった可能性があります。逆に請求額が同じでも、アクティブ顧客や処理件数が減れば費用構造は悪化していると考えられます。

月次のCloud Billが示すのは費用の総量です。製品の成長に対して費用がどの速さで増えるかを知るには、顧客・注文・取引・業務などのValue Metricで割ります。最も単純な式は、クラウド単位コスト = 同じ期間・範囲に含めたクラウド費用 ÷ 同じ期間・範囲で発生した有効な価値単位です。

前提は三つあります。費用と価値単位が同じ製品・期間・環境を指すこと、通貨と為替基準が一致すること、成功・重複・取消条件を適用した有効単位だけを分母に含めることです。除外対象も三つです。会計上の売上原価や営業費用全体、範囲の異なる製品・期間の費用、定義していないテスト・再試行・内部利用量です。

式は単純でも、実務の中心は分子と分母の定義です。FinOps Foundationも、全組織に共通する単一のUnit Metricはなく、利用者の実際のWorkflowにできるだけ近い指標を選ぶべきだと説明しています。^[4]

まず何を1単位とするかを決める

顧客当たり費用が常に最適とは限りません。利用量の差が大きいB2B SaaSで顧客数だけを分母にすると、大口顧客と小口顧客の費用差が見えなくなります。注文当たり費用も、完了前の検索・カート・決済失敗の費用をどう扱うかが未定では解釈できません。Value Metricは、いま必要な意思決定から選びます。

Token当たり・GB当たり費用は、エンジニアリングの最適化に役立つResource Efficiency Unit Metricです。顧客・取引・解決したCase当たり費用は、製品や経営判断に近いBusiness Unit Metricです。AIも最初はToken当たり費用を見ても、最終的には採用された結果や完了した業務当たりへ広げる方が実際の価値に近づきます。

先にMetric Contractを書く

Value Metricでは名称より計算の取り決めが重要です。コマース製品の例では、metric_idはORDER_FULFILLED_V1、decision_questionは「注文増に対してインフラ費用が効率よく拡張するか」、scopeはcommerce-product-a / production / KRです。denominator_nameは出荷完了注文、business_eventはorder_fulfilled、success_conditionはfulfillment_status = completed、dedupe_keyはorder_idとします。

denominator_exclusionsには取消注文、テスト注文、重複Event、内部運用アカウント、不正と確定した注文を書きます。periodはcalendar_month、timezoneはAsia/Seoul、late_event_policyは「翌月第3営業日まで前期間を再計算」とします。ownerはbusiness_definitionをProduct、event_qualityをData Engineering、cost_definitionをFinOpsまたはPlatformに分けます。

この定義に基づく分母は、有効な価値単位 = 成功条件を満たす一意のBusiness Event数です。dedupe_keyが同じ単位を安定して識別し、期間終了後に成功状態が確定し、遅着Eventの再計算方針があることを前提とします。単純なAPI呼出数、自動再試行、重複メッセージ、テスト・内部Traffic、成功が未確定のEventは除外します。

分母の定義を変更したら、過去値も同じVersionで再計算するか、Metric Versionを分けます。

請求額と運用コストの基準を分ける

2026年8月22日時点の最新FOCUS Specificationは1.4です。^[6] FOCUSは提供者ごとに異なるBilling Dataの用語とSchemaを正規化します。現在は四つのDatasetを定義していますが、単位コスト計算の中心はCost and Usage Datasetです。^[2]

分子には通常、BilledCostとEffectiveCostの二つの見方があります。本稿では分析目的に応じてCost MetricとPeriod基準を組み合わせます。EffectiveCostを使っても、財務諸表の発生主義費用や売上原価に自動的になるわけではありません。FOCUSは運用・Billing分析の標準であり、企業の会計方針を定めるものではありません。

最新FOCUS VersionとCSPが実際に出力するVersionも区別します。現在の公式Adoption情報では、AWS・Azure・Google Cloudは主にFOCUS 1.2相当をサポートしています。内部Data Modelにはsource_provider、source_export_name、source_focus_version、ingested_atを保持します。charge_period_start/end、billing_period_start/end、billed_cost、effective_cost、billing_currency、service_category、service_name、resource_id、sub_account_id、region、tags、allocated_method_id、allocated_resource_idも残します。内部Canonical Schemaの目標をFOCUS 1.4にしても、原本にない1.4 Fieldを収集済みのように埋めてはいけません。

BilledCost

実際のInvoiceと照合する費用です。請求書検証、支払額、月次現金支出の説明に適します。

EffectiveCost

資源利用や約定消費の時点に費用を配分した値です。前払・約定費用を実利用Rowへ反映でき、製品別配賦や消費傾向分析に適します。

製品・サービスの運用単位コスト

EffectiveCostを使い、ChargePeriodStart/Endを期間基準にします。

Invoice・支払額の整合

BilledCostを使い、BillingPeriodStart/Endを期間基準にします。

Commitment・Unused分析

Charge Period単位でEffectiveCostとCommitment状態を確認します。

会計報告

Finance承認の別Mappingを使い、会計方針に従います。

費用をDirect・Shared・Idle・Unallocatedに分ける

費用Rowの分類では二つの軸を混ぜないことが重要です。第一は誰に帰属するかで、Direct、Shared、Idle、Unallocated、Excludedの五状態があります。第二は技術費用の種類で、Compute、Storage、Data·Network、Database、AI·Accelerator、Observability·Security、その他Platformに分けます。

Database費用はDirectにもSharedにもなります。AI API費用も特定顧客の要求に直結する場合と、複数製品が共用するModel Endpointの費用があります。Database・Network・AIをDirect・Sharedに上乗せすると二重計上になります。各費用Rowに帰属状態を一つ、技術区分を一つ付けます。

分析範囲の総費用 = Direct + Shared + Idle + Unallocated + Excluded。各Rowが一つの帰属状態だけに属し、全金額の期間・通貨・Cost Viewが同じで、Credit・Refund・Correctionを同じ方針で反映することが前提です。Billing Export外の人件費・決済手数料・減価償却、未収集の別Vendor費用、別製品・環境の費用は除外します。この式はBilling Dataの欠落を確認するReconciliation用です。すべてを単位コストの分子に入れるという意味ではありません。

帰属単位コストと整合単位コストを分ける

配賦できる費用だけの値と、未配賦費用を方針に従って分散した値は分けます。帰属費用 = Direct Cost + Allocated Shared Cost + Included Idle Cost。帰属単位コスト = 帰属費用 ÷ 有効な価値単位。共有費・遊休費の算入方針を文書化し、費用と価値単位のScopeをそろえ、分母が0の期間は計算せず別状態にすることが前提です。配賦基準のないUnallocated Cost、明示的な除外費用、会計上のCOGSだけに含む非クラウド費用は除きます。

帰属単位コストは、製品・エンジニアリング部門が現時点で説明できる費用です。未配賦費用は別に、未配賦率 = Unallocated EffectiveCost ÷ 分析範囲のTotal EffectiveCostで管理します。分子と分母のCost View・Scopeをそろえ、Excluded Costを分母から除き、Tag・Owner Mapping失敗を一貫してUnallocatedに分類することが前提です。方針上中央予算に残すShared Cost、InvoiceだけにあるTax、Billing Export外の費用は除きます。FinOps Foundationも、分類・配賦できない費用の割合をCost Allocation KPIとしています。^[1]

全費用を製品別に集計する報告では、別途整合値を設けます。整合単位コスト =（帰属費用 + 方針上配賦したUnallocated Cost）÷ 有効な価値単位。配賦判断と責任者を記録し、配賦前後で全額を一致させ、過去にも同じ方針を適用するかVersionを分けることが前提です。原因不明のまま任意に均等配分した費用、別組織・製品の費用、Excluded Costは除外します。

帰属単位コストと整合単位コストを併記すると、費用効率とAllocation Data Qualityを分けて評価できます。

Shared Costは発生原因に近い基準で配賦する

基本式は、対象別Shared Cost配賦額 = Shared Cost Pool × 対象のAllocation Key ÷ 全対象のAllocation Key合計です。Keyが費用発生と合理的に結び付き、全対象のKeyを同じ期間・単位で収集し、Poolごとの配賦率合計が100%になることを前提とします。Keyのない対象、収集漏れが大きい期間、配賦しても意思決定上の価値が乏しい中央共通費は除外します。

FinOps FoundationはAccount・Project・TagなどのBilling Metadataに加え、CMDB、Observability、Utilization Dataを使った詳細な共有費配賦を説明しています。^[1] Shared Costごとに固定比率、比例配賦、Proxy、中央予算維持を選べます。便宜的な基準ではなく原因に近いKeyを選ぶ例を下表に示します。

Data·Network、Database、AI·Acceleratorの費用

Network費用は転送量だけでは判断できません。Internet Egress、リージョン間・可用性ゾーン間転送、NAT·Gateway Processing、CDN Origin Transferなど、経路で費用が変わるためです。^[3] 可能ならsource_scope、destination_scope、traffic_class、bytes_transferred、request_count、transfer_cost、processing_cost、business_event_idの粒度を残します。注文・取引に直接結び付かない大量BatchやReplication Trafficは、注文数で割る前にJobやデータ製品へ帰属させます。

Tenant専用DatabaseはDirect Costにしやすい一方、Shared DatabaseをQuery数だけで分けると、軽い参照と大規模Scanが同じ費用に見えます。可能ならQuery Runtime、CPU、Read・Write I/O、Storage、Backup、Replica利用量を組み合わせます。観測費用が配賦精度の価値を上回るなら、主なCost Driverに絞り限界を記録します。

Managed Model APIではModel、Input Token、Output Token、Cached Token、Retry、Batch利用がCost Driverになります。自前GPUではAccelerator占有時間、実演算時間、Memory割当、Batch Throughput、遊休時間を分けます。AI機能全体の単位コストにはModel Callだけでなく、業務に必要なEmbedding、Vector Database、Retrieval、Tool Call、Moderation、Logging、再試行も範囲に応じて含めます。ただしTokenは資源消費単位です。成功した相談、採用文書、完了したAgent Actionなど、結果に近いBusiness Metricを併用する方が適切です。

Idle Costをすべて無駄と呼ばない

未使用容量がすべて削減対象とは限りません。障害・Traffic Burstに備えるHeadroom、復旧用Warm Standby、未消化の約定容量、Scale-outの最小Node、開発・検証環境の基本容量、Owner不在のOrphan ResourceはいずれもIdleです。

HeadroomとWarm Standbyは、Reliability要件に基づく計画費用の場合があります。一方、未使用約定やOrphan Resourceは別途改善対象にできます。FOCUSではCommitmentDiscountStatus = Unusedなどの状態で未使用約定費用を識別します。^[2]

Idle Costには下記三方針のいずれかを適用します。方針未定のIdle Costを黙って注文・顧客数に配分すると、製品効率と組織の調達・容量計画の問題が混ざります。

製品帰属

製品の信頼性・復旧要件で確保した容量に適用し、Included Idle Costと表示します。

中央効率Pool

複数製品が共同で責任を持つ未使用約定に適用し、別のIdle KPIで示します。

原因Ownerへの帰属

特定Team・製品の過剰Provisioningが明確な場合に、その対象へ配賦します。

Fixed・Variable・Step-fixedを区別する

従量課金のクラウドでも、全費用が完全なVariable Costではありません。費用の挙動を四種類に分けます。

Variable Unit Cost = Variable Cost ÷ 有効な価値単位。Fixed Cost Absorption =（Period-fixed Cost + Step-fixed Cost）÷ 有効な価値単位。Total Unit Cost = Variable Unit Cost + Fixed Cost Absorption。同期間で費用挙動が一定で、Step-fixed容量が増える閾値を記録し、One-time Costを反復費用から分離することが前提です。次回増設後の将来単価、未契約の割引、会計上の固定費・変動費分類は除外します。

平均単位コストと次の注文1件の限界費用も異なります。余剰容量がある間は注文増でも費用がほぼ変わらず、NodeやDB Tierを上げた時点で単位コストが跳ねることがあります。成長時の補助式は、増分単位コスト = 期間間のIncluded Cost増分 ÷ 期間間の有効価値単位増分です。Architecture・価格・Allocation Versionが比較可能で、単位増分が正であり、Correctionと為替影響を別途除去または説明することが前提です。Migration・大量再処理などのOne-time Cost、製品Mixが大きく変わった期間、Reliability・品質条件が異なる期間は除外します。

Variable Cost

要求、実行時間、転送量、Tokenなど、単位増に比較的連続して反応する費用です。

Step-fixed Cost

DB Instance、最小Node、専用Clusterなど、一定範囲では固定で閾値で増える費用です。

Period-fixed Cost

当該期間の基本Support料や固定Platform費用です。

One-time Cost

Migration、初期Backfill、大規模Reindexなど反復しない費用です。

月次比較ではPeriodを正規化する

単位コストを計算しても、期間基準が違えば傾向を誤読します。下記十項目を正規化します。

FOCUS 1.4はCorrection HandlingとBilling Period状態を明示的に扱いますが、実際のExport対応はVersionと実装で異なります。^[6] 収集時に原本のCorrection方式とData Completenessを確認します。

時間帯

費用とBusiness Eventを同じTimezoneに変換します。

部分月

完全な日付だけを比較するかPartial Periodと表示します。

ChargeとBilling Period

運用分析はCharge Period、Invoice整合はBilling Periodを使います。

Currency

一つの通貨へ換算しFX Source・Dateを記録します。

Credit・Refund

元の利用期間をRestateするか発生月に反映するかを決めます。

遅着Event

再計算期限とSnapshot Versionを記録します。

Commitment

購入時BilledCostと消費時EffectiveCostを混在させません。

One-time作業

反復Run-rateと分離します。

税

基本Cloud Unit Costに含めるかを明示します。

品質

成功率・遅延・エラー率の変化と併せて解釈します。

成長とCohortを見なければ平均に惑わされる

全体の顧客当たり費用が下がっても、低利用顧客が増えただけかもしれません。逆に単位コストの上昇が、大口顧客や高コスト機能の利用増による場合もあります。少なくとも下記六つのCohort軸を分けます。

Cohort別単位コストを単純平均してはいけません。全体単位コスト = 全Cohort費用合計 ÷ 全Cohort有効単位合計。重複のないCohortが全Scopeを構成し、Metric DefinitionとCost View・通貨・期間が一致することが前提です。単位コストの算術平均、分母が違うMetricの合算、成功条件が異なるCohortは除外します。FinOps Foundationも、組織全体同士の単純比較より、製品・Cohort・定義したScope内での時系列管理を示しています。^[4]

変化の理由を七つのDriverに分けます。提供者のRate・Discount、単位当たり利用量、顧客・製品Mix、Architecture、Idle・Headroom、Shared Cost Allocation、Tag・Business EventのData Qualityです。費用が下がっただけで最適化成功とは判断できません。遅延、エラー率、可用性、セキュリティ、結果品質のGuardrailも維持する必要があります。

新規・既存顧客

Onboarding・初期データ投入費用が高いか確認します。

料金プラン・顧客規模

大口顧客の利用量と費用を価格に反映しているか確認します。

Region

データ移動・地域別Architectureの差を確認します。

製品Version

新機能で単位コストが変化したか確認します。

利用量帯

小口顧客とHeavy UserでCost Driverが異なるか確認します。

AI Model・品質Tier

高性能Modelの選択と結果改善が釣り合うか確認します。

Cloud Unit Economics Template

TemplateはMetric Contract、Cost Pool Register、期間別結果Dataset、必須整合性検査の四部構成です。Metric Contractでは下記十一組のFieldを記入します。

期間別結果Datasetはperiod、scope、cohort、metric_version、valid_value_unitsから始めます。続いてdirect_effective_cost、allocated_shared_cost、included_idle_cost、attributed_cost、unallocated_cost、excluded_cost、total_effective_costを置きます。次にattributed_unit_cost、reconciled_unit_cost、variable_unit_cost、fixed_cost_absorption、unallocated_rateを置き、allocation_version、source_focus_version、currency、availability_guardrail、latency_guardrail、quality_guardrail、data_closed_atで締めます。

Metric識別

metric_id、metric_version、decision_question、target_readerを記入します。

scope

product、environment、region、customer_segment、included_servicesを記入します。

value_metric

denominator_name、business_event、success_condition、dedupe_key、exclusions、late_event_policyを記入します。

period

grain(daily | weekly | monthly)、timezone、charge_period_rule、billing_period_ruleを記入します。

cost_view

operational_numeratorをEffectiveCost、invoice_numeratorをBilledCostとし、source_focus_version、billing_currency、fx_policyを記入します。

cost_inclusions

direct、shared、idle、data_network、database、ai_acceleratorの算入可否を記入します。

cost_exclusions

tax、one_time、non_cloud、otherの除外項目を記入します。

allocation

version、shared_pool_rules、idle_policy、unallocated_policyを記入します。

restatement

correction_handling、close_date、historical_recalculationを記入します。

guardrails

availability、latency、error_rate、quality、securityの条件を記入します。

owners

business_metric、billing_data、allocation、approvalの責任者を記入します。

必須の整合性検査

各期間の結果を出す前に下記九検査を通します。一つでも失敗した期間は別状態を付け、単位コストの傾向比較から除外します。

Cost Reconciliation

Direct + Shared + Idle + UnallocatedがTotal EffectiveCostと一致すること。

Shared Allocation

各Shared Poolの配賦率合計が100%であること。

Metric Completeness

Event Sourceと集計有効単位数が一致すること。

Scope Alignment

費用と分母のProduct・Environment・Regionが一致すること。

Period Alignment

CostとEventが同じ期間・Timezoneを使うこと。

Version Control

Metric・Allocation・FOCUS Source Versionを記録すること。

Unallocated Disclosure

未配賦金額と比率を隠さないこと。

Guardrail

費用改善前後のReliability・Quality条件を比較すること。

Restatement

Correction後の過去値変更を記録すること。

計算例

計算構造を示すための例示値です。periodは2026-07、scopeはProduct A / Production / KR、value_metricは出荷完了注文、valid_value_unitsは120,000件です。direct_effective_costは18,000,000 KRW、allocated_shared_costは5,400,000 KRW、included_idle_costは1,200,000 KRW、unallocated_effective_costは1,800,000 KRW、excluded_invoice_itemsは600,000 KRWです。

帰属費用 = 18,000,000 + 5,400,000 + 1,200,000 = 24,600,000ウォン。帰属注文当たりCloud Unit Cost = 24,600,000ウォン ÷ 120,000件 = 205ウォン/件。すべて2026年7月Charge PeriodのEffectiveCostで、注文は同期間・Asia/Seoul基準の出荷完了注文とします。重複・取消・テストを除き、共有費配賦は事前承認済みAllocation Versionを使うことが前提です。未配賦1,800,000ウォン、Invoice-only除外600,000ウォン、人件費・決済手数料・顧客支援費、会計上のCOGS調整は除外します。

未配賦率 = 1,800,000ウォン ÷ 26,400,000ウォン ≈ 6.8%。Total EffectiveCostはDirect・Shared・Idle・Unallocated合計の26,400,000ウォンで、Invoice-only除外項目は分母に入れません。税・非クラウド費用、別製品・環境の費用も除外します。

Finance・Product・Engineeringが未配賦1,800,000ウォン全額の製品帰属を承認した場合、整合値を別途計算できます。整合注文当たりCloud Unit Cost = 26,400,000ウォン ÷ 120,000件 = 220ウォン/件。帰属値205ウォンと整合値220ウォンを併記すると、説明可能な製品運用費用とAllocation Data Qualityの問題を区別できます。

Cloud Unit Costを会計上の原価と混同しない

Cloud Unit Costは技術費用を製品価値単位につなぐ運用・管理指標です。価格設定・収益性分析の重要な入力でも、それ自体が会計上の売上原価や売上総利益ではありません。FinOps FoundationもMargin・Pricing・Forecasting判断を支援すると説明しつつ、財務指標とは役割を区別しています。^[4]

会計原価では企業方針に応じ、顧客支援・運用人件費、決済・メッセージング・外部SaaS手数料、自社設備の減価償却、無形資産・開発費、契約上のCredit・Commitment、税、共通管理費を追加したり別の方法で認識したりします。^[5] 財務部門の承認なしに名称だけCOGS per CustomerやGross Marginへ変えてはいけません。

両指標を結ぶ場合は別のMappingを置きます。operational_metricをCloud Unit Cost、finance_metricをCloud COGS per Unit、mapping_statusをFinance approval required、cloud_cost_sourceをFOCUS EffectiveCostとし、additional_cogs_items、excluded_cloud_items、accounting_period、accounting_policy_ownerを記録します。

月額請求より単位コストが変わった理由を見る

Cloud Unit Economicsの目的は、すべてのクラウド費用を無条件に下げることではありません。注文当たり費用が増えたら、Model品質改善、大口顧客増、Database非効率、Network経路、未使用約定のどれが原因かを見分けます。費用増でも、より多くの価値を高品質で提供できれば合理的な投資です。逆に請求額が減ってもエラー率や遅延が悪化すれば、良い最適化とは言いにくくなります。

最初から全社費用を完全に配賦する必要はありません。一製品、一Value Metric、一か月のデータから始められます。ただし四点は初めから守ります。分母の成功・重複・除外条件を文書化し、Direct・Shared・Idle・Unallocatedを区別し、未配賦費用を隠さず、費用傾向をGrowth・Cohort・Reliabilityと併読します。

単位コストは一つの数字ではなく、製品の成長とインフラ費用の関係を説明する運用モデルです。