SaaSの価格設計とメータリング
概要
価値指標の選び方、プラン設計、計測（メータリング）と請求のつなぎ込みを、最小構成で解説。
イベント設計のスニペットつき。
はじめに
SaaSの価格は**“価値の表現”**だ。複雑な料金表より、**1つの価値指標（Value Metric）**で“使うほど価値が上がる”状態を目指す。ここでは、プラン→計測→請求の順で組み立てる。
価値指標（Value Metric）の選び方
・顧客の成果と直結（例：送信メール数・席数・処理ジョブ数）
・拡張が滑らか（小さく始めて大きく育つ）
・測定が容易（不正・誤差に強い）
プラン設計の最小マトリクス
・Free/Trial：価値体験に十分な範囲（期限 or 制限）
・Standard：大多数向け。サポートSLOを明確化
・Pro：拡張枠とSLA、監査ログ、SAML/OIDC
・Enterprise：ボリュームディスカウント、専用サポート
計測（メータリング）の設計
JSON
{
"event_id": "ulid_01H...",
"occurred_at": "2025-10-16T05:32:11Z",
"tenant_id": "tnt_123",
"user_id": "usr_456",
"metric": "job.executed",
"value": 1,
"context": { "region": "ap-northeast-1", "source": "api" },
"signature": "HMAC(...)" // 改ざん検知用（オプション）
}集計テーブル（例：PostgreSQL）
SQL
CREATE TABLE usage_events (
event_id text primary key,
occurred_at timestamptz not null,
tenant_id text not null,
user_id text,
metric text not null,
value numeric not null,
ctx jsonb
);
-- 日次集計ビュー
CREATE MATERIALIZED VIEW usage_daily AS
SELECT tenant_id, metric, date_trunc('day', occurred_at) AS day,
SUM(value) AS total
FROM usage_events
GROUP BY tenant_id, metric, date_trunc('day', occurred_at);アプリからの発火（Node例）
JavaScript
async function emitUsage(tenantId, userId, metric, value = 1) {
await fetch(process.env.METER_URL + '/events', {
method: 'POST',
headers: { 'Content-Type': 'application/json', 'Authorization': 'Bearer ' + process.env.METER_TOKEN },
body: JSON.stringify({ tenant_id: tenantId, user_id: userId, metric, value, occurred_at: new Date().toISOString() })
});
}請求とのつなぎ込み（最小手順）
1. 締め日を固定（例：毎月末）
2. 集計→料金計算（単価×使用量、階段/逓減も可）
3. ドラフト請求書を作成（顧客確認の導線）
4. 支払い失敗時の再試行（dunningルール：1日/3日/7日）
5. 領収書と税計算（居住国・税区分の取り扱い）
課金計算の疑似コード
Python
def calc_amount(usage, pricing):
# usage: {"metric":"job.executed", "total": 1234}
# pricing: 階段課金 [{"upto": 1000, "unit": 10}, {"upto": 5000, "unit": 8}, {"upto": None, "unit": 6}]
remain = usage["total"]
amount = 0
prev = 0
for tier in pricing:
cap = tier["upto"] or remain
qty = max(0, min(remain, cap - prev))
amount += qty * tier["unit"]
prev = cap
return amount表示とコミュニケーション
・価格ページは“選びやすさ”優先：プラン比較は3–4列、主な差は3項目だけ。
・ダッシュボードで“今月の使用量”を即表示。超過の手前で事前アラート。
・規約：返金・キャンセル・SLA・データ保持を簡潔に。
失敗あるある
・メトリクスが増えすぎる（分析は増やしてOK、請求は1–2個に絞る）
・“改定の理由”を出せない（原価・価値の変化を事前に説明）
・トライアルが弱い（価値に触れる前に終わる）
まとめ
価格は“約束の形”。価値指標→計測→請求を一本の線でつなぎ、まずは運べる最小構成から始めれば、後の拡張にも耐えられる。
