LINEコスト予測が9倍になっていた話 - 予測対象を間違えた設計の落とし穴

モニタリングシステムのコストレポートを確認していたときのことです。LINEの予測コストが140,000円と表示されていました。でも待てよ、LINEの月額基本料金は15,000円のはずです。なぜ9倍以上の予測値になっているのでしょうか。

この違和感から始まった調査で、予測ロジックの設計に根本的な問題があることがわかりました。そして、その問題を解決しようとする過程で、さらに別の問題が見つかりました。

問題の発見：140,000円という違和感

コストモニタリングシステムが出力したレポートには、こんなデータが含まれていました。

{
  "service": "LINE",
  "current_cost": 15000.0,
  "forecast": 140000.0,
  "period_start": "2026-02-01",
  "period_end": "2026-02-03",
  "message_count": 220,
  "monthly_fee": 15000.0,
  "message_cost": 0.0
}

3日間で220通のメッセージを送信し、現在のコストは15,000円。ここまではいいのですが、月末予測が140,000円になっています。

LINEのスタンダードプランは月額15,000円で、30,000通までは無料です。220通なら確実に無料枠内に収まるはずなので、月末の着地も15,000円前後になるはずです。なぜこんな予測値になっているのでしょうか。

第一の調査：現状のロジックを読み解く

monitoring/cost_monitor.py の実装を確認してみました。コスト予測は、標準的な日割り計算を使っていました。

forecast = (current_cost / days_passed) * days_in_month

この式に実際の値を当てはめると：

forecast = (15000 / 3) * 28
forecast = 5000 * 28
forecast = 140000

謎が解けました。このロジックは「毎日5,000円かかっている」という前提で予測を立てていたのです。しかし、15,000円は月額固定費であり、月初に1回だけ課金されるものです。日割りで計算してはいけない性質のコストでした。

第二の調査：もっと直接的な方法はないか？

この問題を解決するにあたって、まずLINE Messaging APIのドキュメントを確認しました。金額を直接取得できるエンドポイントがあれば、予測計算そのものが不要になるかもしれません。

調査の結果、以下のことがわかりました：

現在の実装は日別APIを複数回呼んでいましたが、月間合計のエンドポイントを使えばAPI呼び出し回数を削減できることがわかりました。ただし、これは効率化にはなっても、予測ロジックの問題を解決するものではありません。

メッセージ数から料金を計算するしかない、という制約の中で設計を考える必要がありました。

第一の問題：段階的料金体系の複雑さ

LINEの料金ページを確認したところ、予想以上に複雑な料金体系であることがわかりました。

最初は「4段階くらいだろう」と思っていたのですが、実際には15段階の従量課金制でした。

しかも、現在の実装は固定単価3.0円で計算していました。大量配信のケースでどれくらいの誤差が出るか計算してみます。

150万通配信の場合：

現在の実装（固定単価3.0円）：

1,500,000通 × 3.0円 = 4,500,000円

正しい計算（15段階の料金体系）：

月額基本料: 15,000円
無料分: 30,000通 → 0円
課金対象: 1,470,000通

・50,000通 × 3.0円 = 150,000円
・50,000通 × 2.8円 = 140,000円
・100,000通 × 2.6円 = 260,000円
... (中略) ...
・470,000通 × 1.4円 = 658,000円

合計: 2,733,000円

差額：約177万円（40%の過大評価）

この段階的料金体系への対応が必要だと気づき、課題管理ツールにIssueを作成しました。

第二の問題：予測ロジックの根本的誤り

段階的料金への対応を考えていたとき、さらに根本的な問題に気づきました。そもそも予測の仕方自体が間違っているのです。

最初のアプローチ：固定費と変動費を分離

当初、こんな実装を考えました：

# 固定費を除外して変動費だけ予測
monthly_fee = 15000
variable_cost = current_cost - monthly_fee
forecast_variable = (variable_cost / days_passed) * days_in_month
forecast = monthly_fee + forecast_variable

このアプローチなら、月額固定費を何度もカウントすることは避けられます。でも、これで本当に正しいのでしょうか。

正直ここで詰まりました。何かしっくりこない感覚がありました。

転換点：「いや、そうじゃなくて」

そこで方針を変えました。コストを予測するのではなく、メッセージ数を予測してから料金を計算する。

このアプローチが自然な理由は、LINEのビジネスモデルにあります：

だとすれば：

# 誤ったアプローチ
forecast_cost = f(current_cost, days)  # コストからコストを予測

# 正しいアプローチ
forecast_message_count = g(current_message_count, days)  # メッセージ数を予測
forecast_cost = f(forecast_message_count)  # 予測メッセージ数から料金を計算

予測すべきはコストではなくメッセージ数だったのです。

正しい予測ロジックの設計

新しいロジックの実装イメージはこうなります：

def _get_cost_data(self, config, context):
    # ① 現在のメッセージ数を取得
    message_count = self._fetch_monthly_message_count(...)

    # ② 現在のコストを計算（実績）
    current_cost_result = self._calculate_line_cost(message_count, config)
    current_cost = current_cost_result["total_cost"]

    # ③ 予測を計算
    if context["is_current_month"] and context["days_passed"] > 0:
        # メッセージ数を予測
        forecast_message_count = (
            message_count / context["days_passed"]
        ) * context["days_in_month"]

        # 予測メッセージ数から料金を計算
        forecast_cost_result = self._calculate_line_cost(
            int(forecast_message_count),
            config
        )
        forecast = forecast_cost_result["total_cost"]
    else:
        forecast = current_cost

    return CostData(...)

_calculate_line_cost() メソッドは、メッセージ数から段階的料金を計算します：

def _calculate_line_cost(self, message_count, config):
    monthly_fee = float(config.get("monthly_fee", 15000))
    free_messages = int(config.get("free_messages", 30000))

    # 無料枠を超えた分を計算
    billable_messages = max(0, message_count - free_messages)

    # 段階的料金テーブル（15段階）
    tiers = [
        (50000, 3.0),
        (100000, 2.8),
        (200000, 2.6),
        # ... 15段階すべて
    ]

    # 段階的に料金を計算
    message_cost = 0
    remaining = billable_messages
    prev_threshold = 0

    for threshold, unit_price in tiers:
        if remaining <= 0:
            break

        tier_messages = min(remaining, threshold - prev_threshold)
        tier_cost = tier_messages * unit_price
        message_cost += tier_cost

        remaining -= tier_messages
        prev_threshold = threshold

    total_cost = monthly_fee + message_cost

    return {
        "total_cost": total_cost,
        "monthly_fee": monthly_fee,
        "message_cost": message_cost,
        "billable_messages": billable_messages
    }

計算例の比較

ケース1：無料枠内（実際のデータ）

3日で220通 → 月末予測：約2,053通

ケース2：有料段階に入る場合

3日で10,000通 → 月末予測：約93,333通

月額基本料: 15,000円
課金対象: 93,333 - 30,000 = 63,333通

・最初の50,000通: 50,000 × 3.0円 = 150,000円
・次の13,333通: 13,333 × 2.8円 = 37,332円

合計: 202,332円

このように、メッセージ数を予測してから料金を計算することで、段階的料金体系も正しく反映されます。

2つの問題の関係性

振り返ってみると、今回発見した2つの問題は別々のように見えて、根は同じでした。

どちらもLINEの料金モデルを正しく理解していなかったことが原因です。

問題を解決しようとして調査を進めるうち、別の問題が見つかる。このプロセス自体は、よくあることだと思います。重要なのは、データの違和感に気づき、立ち止まって考えることでした。

なぜこの問題が起きたか

日割り計算によるコスト予測は、一般的には正しいアプローチです。実際、同じシステム内のAWSコスト予測では直近4日間の平均を使った日割り計算が機能しています。

問題は、予測対象を間違えていたことです。

LINEの料金モデルは「固定費 + 従量課金」の構造を持っています：

cost = monthly_fee + f(message_count)

この構造では、コストを直接予測すると固定費の扱いが不自然になります。一方、メッセージ数を予測すれば、料金計算の関数 f() にそのまま渡すだけです。

意外とここが肝です。ビジネスモデルの構造を理解していれば、自然と正しい予測対象が見えてきます。

また、API調査で「金額を直接取得できない」という制約がわかったことも、設計の方向性を決める重要な情報でした。制約があるからこそ、その中で最適解を見つける必要があります。

まとめ：予測ロジック設計の原則

今回の経験から学んだことをまとめます：

コスト予測という一見シンプルな機能でも、ビジネスモデルへの理解が浅いと根本的な間違いを犯してしまいます。今回の140,000円という予測値は、そのことを教えてくれた良い事例でした。