六桁の請求額が生んだ見張り番 ── AIパートナーMartinが1日で作った「チャック」

今回の登場人物

Martin（マーティン）

AI パートナー / team-lead-home 担当

チーム司令塔として進行・全体俯瞰を担う編曲席。月曜定例MTGの司会からSKILL横展開まで、チーム全体を見渡す立場にいる。

担当プロジェクト team-lead-home

チーム全体の司会・進行・全体支援を担う「編曲席」。MTG進行、横断的な配信支援、SKILL横展開を担当。現在開発中・公開準備中。

準備中

6月の請求書に並んでいた数字は、普段の桁とは明らかに違っていた。原因はPaulが回していたMemboのGPAバッチが、Places APIのEnterpriseティアを想定以上に叩いていたこと。その朝、リーダーのKeathがまず選んだのは、遊ぶことだった。焦って手を動かす前に頭を冷やす選択だ。そして数日後、対策そのものを引き継いだのがMartinだった。「今後のことをマーティンに任せて、万全な対策を取るつもりだ」。ナミオさんの言葉が、Martinに課された宿題になった。

課題：「実費¥0の裏で使用額が動く」を見逃さない

コスト監視でよくある失敗は、請求額だけを見ることだ。クレジットが効いていると実際の支払いは¥0でも、裏では使用量がじわじわ積み上がる。無料枠を使い切った瞬間に、突然大きな請求が跳ねる——6月の事件はこの構造だった。Martinの設計思想はシンプルだった。「判定はクレジット相殺前の生costで行う」。監視対象は請求先`tsukurun`配下のGCP全プロジェクト、Places・Translate・Gemini・Mapsを含む全SKUに広げた。

実装：D-1規律で、見張り番自身を疑う

Martinはこのシステムをチームのデバッグ規律「D-1」——実装する手と疑う目を別人格に分ける方式——で作った。自分の実装を別のレビュー役に投げてCRITICALな欠陥を3件検出させ、差し戻し・修正・再検証を回してから、実機の物証を2本確認してcrontabに登録する。お金の見張り番自身を、この規律で作った。

この規律の技術的な意味は、レビューを「あればいい」ではなく「外向き・不可逆な処理ほど目を増やす」設計にした点にある。コスト監視は請求という不可逆な現実に直結する仕組みだからこそ、実装者自身の申告を判定に使わず、別人格のレビューがHTTPレスポンスやSQLの実行結果といった物証だけでPASSを出す。今回検出されたCRITICAL3件も、この「物証でしか通さない」フィルターを通したからこそ見つかった欠陥だった。

アラートは4段階に分けた。

危険SKUを個別の低い閾値で見張るのは、6月の事件が「特定のティアだけが跳ねる」形で起きたからだ。全体を大枠で見張るだけでは、この種の局所的な暴発は拾い切れない。大規模バッチを回す前にMartinへ一報する運用にし、configの`watch_events`に登録すると実行後48時間は個別上限で重点監視する仕組みも組み込んだ。

閾値の数字はどれも当てずっぽうではない。日次¥2,000は「1日の異常検知」としては小さすぎず大きすぎない目安値で、月間換算すると予算¥25,000の1割弱にあたる水準に設定した。予算到達を50/80/100%の3段階で刻んだのは、クラウドコスト管理で一般的に使われる考え方で、50%で「気づく」、80%で「動く」、100%で「止める」という役割分担になっている。危険SKUの¥500/日は、通常SKUの日次閾値¥2,000よりさらに低い——単価が跳ねやすいティアほど、早い段階で人間の目に入れる設計だ。

結果：稼働まで1日、そして命名「チャック」

設計から稼働まで、かかった時間は1日だった。Slackに「#コストアラート」チャンネルが新設され、毎朝07:30に前日の全APIコストが報告される。異常があれば即アラートが飛ぶ。crontabには毎時1本登録し、実際にBigQueryへ問い合わせるのは6・12・18・22時と朝サマリー時のみに絞った。それ以外の時間は数ミリ秒でスキップする軽い巡回だ。配置場所はDocumentRoot外、chmod 600、本番環境には置かない——見張り番自身が穴にならないよう権限を絞っている。

稼働を確認したナミオさんが、この見張り番に名前を与えた。「チャック」。Chuck Berryにちなんだ名前だ。Slackの表示名も変更され、18:00からcrontabでの自走が始まった。さらにナミオさんはGCC三重防衛で仕上げを加えた。予算アラート¥25,000（生額＋101%予測）に加え、membo・albumsweet・usersupports・tsukurun・sessionlifeの5プロジェクトにPlacesクォータ1,000/日の上限を設定。三重の壁が、6月に空いた穴をふさいだ。

用語の整理

生cost（クレジット相殺前コスト）

無料枠・クレジットを適用する前の使用量ベースの金額。相殺後の請求額だけでは、無料枠切れの急増を見逃す

危険SKU

Enterprise・Atmosphere・Grounding系など単価が高くコストが跳ねやすいAPIのティア。全体監視とは別に低い閾値で個別監視する

D-1規律

実装する手と疑う目を別人格に分け、物証でしかPASSを出さない開発規律。外向き・不可逆な処理ほどレビューの目を増やす

GCP Billing Export

GCPの請求データを自動的にBigQueryへ書き出す機能。日次のコスト明細がテーブルに溜まるため、SQLでの集計・比較・異常検知の土台になる

SKU（課金単位）

GCPが課金の最小単位として定義する「サービスの利用形態」。同じPlaces APIでも呼び出し方（Enterpriseティアか標準ティアか）でSKUが変わり、単価も跳ね方も違う

BigQueryでのコスト分析

Billing ExportでBigQueryに溜まったコストデータをSQLで直接分析すること。ダッシュボードツールを挟まずに、前日比・7日平均比・SKU別内訳などを自由なクエリで即座に見られるのが強み

比較：コスト監視、3つのアプローチ

【技術コラム】GCPのコスト監視、明日から試せる設計パターン

自分のGCPプロジェクトでも、同じ考え方は今日から取り入れられる。骨格は2つだけだ。ひとつは「Billing Export」、もうひとつは「閾値の段階分け」。BigQueryに向けてBilling Exportを有効化すると日次コストがテーブルに溜まり、SQLで前日比・7日平均比を計算すれば急増検知の土台ができる。

-- 直近7日平均に対する当日コストの倍率SELECT service.description AS service_name,  SUM(cost) AS daily_cost,  SUM(cost) / NULLIF(AVG(SUM(cost)) OVER (), 0) AS ratio_to_avgFROM `プロジェクトID.billing_dataset.gcp_billing_export_v1_XXXX`WHERE DATE(usage_start_time) = CURRENT_DATE() - 1GROUP BY service_name ORDER BY daily_cost DESC;

次に閾値を1段階ではなく複数段階に分ける。「予算の100%到達で通知」だけでは手遅れになりがちだ。50%・80%・100%と早めから通知すれば月末着地の予測もできる。さらに単価の高いAPI（生成AI系・地図系のプレミアムティアなど）は別枠で低い閾値を設定する。無料枠のあるAPIなら「相殺後の請求額」ではなく「相殺前の使用量ベースコスト」で見ることを強くすすめる。まずは自分のプロジェクトでBilling Exportが有効か、そこから確認してほしい。

予算超過を防ぐアプローチは、監視だけではない。もう一段手前で止める方法として、APIクォータの事前制限（Places 1,000/日のような上限を先に切っておく）と、大規模バッチ実行前の事前見積もりレビュー（想定コール数×単価を事前に机上計算してからGOを出す運用）の2つがある。チャックは「跳ねてから気づく」監視だが、クォータ制限と事前レビューは「跳ねる前にふさぐ」壁だ。ナミオさんが加えたGCC三重防衛（予算アラート＋Placesクォータ1,000/日）は、まさにこの監視と事前制限を組み合わせた形になっている。

コスト管理の仕組みそのものにも選択肢がある。自前で組む代わりの選択肢を表に整理する。

ただしSKU単位の低閾値検知や社内Slack連携まで含めて素早く回すなら、BigQuery + Cloud Functionsの自前構成の方が小回りが利く。チャックはこの自前構成側を選んだ実例だ。