◉CLAUDE LABEN
●2.1.301 — vim の % モーション、VS Code パネルでの LaTeX 数式表示、使用量上限待ちのリトライ監視の上限が入りました(10/15)●2.1.299 — 200K トークン超で約54分放置した会話はアイドル圧縮。MCP の許可ルールは名指ししたサーバーだけに一致します●SONNET 4.5 — Claude API での提供終了は 11/30、残り45日。移行先は Sonnet 5.5●WINDOWS — 日本語の環境でだけフックが黙って壊れる報告があり、文字コードの確認が呼びかけられています●FAST MODE — Opus 5.5 の Fast mode がリサーチプレビューを終え、ベータヘッダーが不要になりました(10/15)●NEW — Cowork に渡したフォルダの先頭に、十行の約束ファイルを置いてみました●2.1.301 — vim の % モーション、VS Code パネルでの LaTeX 数式表示、使用量上限待ちのリトライ監視の上限が入りました(10/15)●2.1.299 — 200K トークン超で約54分放置した会話はアイドル圧縮。MCP の許可ルールは名指ししたサーバーだけに一致します●SONNET 4.5 — Claude API での提供終了は 11/30、残り45日。移行先は Sonnet 5.5●WINDOWS — 日本語の環境でだけフックが黙って壊れる報告があり、文字コードの確認が呼びかけられています●FAST MODE — Opus 5.5 の Fast mode がリサーチプレビューを終え、ベータヘッダーが不要になりました(10/15)●NEW — Cowork に渡したフォルダの先頭に、十行の約束ファイルを置いてみました
記事一覧/API & SDK
⬡ API & SDK/2026-05-01上級

Claude API のテレメトリを ClickHouse に流して分析する — 本番環境のコスト・遅延・エラーを可視化する設計ガイド

Claude API のリクエスト単位でコスト・遅延・トークン使用量を ClickHouse に蓄積し、Materialized View でリアルタイムダッシュボードを構築する本番運用設計を解説します。

claude-api83clickhouseobservability15analytics3production87

✦ プレミアム記事

Claude API を本番投入してから半年経ったある月末、請求書を見て手が震えた経験があります。前月比で 4.2 倍。原因を切り分けるのに丸 2 日かかりました。あのときアプリ側にリクエスト単位のテレメトリ基盤があれば、おそらく 30 分で原因のエンドポイントを特定できていたはずです。

Claude API のリクエスト単位の使用量・コスト・遅延を ClickHouse に蓄積し、Postgres では実現しにくい高速な集計と異常検知を本番品質で組み立てる方法を順を追って整理していきます。Cloudflare Workers から ClickHouse Cloud に安全に書き込む実装、Materialized View でダッシュボードを 1 秒以内に返す設計、そしてハルシネーション疑い・リトライループといった「請求書には現れない損失」を SQL で検出するレシピまで、本番運用で実際に効いたパターンをまとめています。

なぜ ClickHouse なのか — Postgres / BigQuery / Snowflake と何が違うのか

最初に Postgres にテレメトリを書こうと考える方が多いはずです。私もそうでした。リクエスト 1 件あたり 1 行を events テーブルに INSERT すれば、SQL で集計できます。一見シンプルです。

しかし API 呼び出しが 1 日 100 万件を超えたあたりから、Postgres の限界が見えてきます。SELECT model, sum(input_tokens), sum(output_tokens) FROM events WHERE ts > now() - interval '1 day' GROUP BY model のような集計クエリが、インデックスを工夫しても 30 秒以上かかるようになります。Postgres は OLTP(行指向トランザクション)に最適化されているため、列方向の集計には根本的に不利なのです。

ClickHouse のテレメトリ用途で重要な強みを順に挙げると、まず列指向ストレージで集計が高速で、数億行を SUM / AVG / quantile() するクエリが秒単位で返ってきます。次に ReplacingMergeTree / AggregatingMergeTree などの専用エンジンが、重複排除や事前集計を宣言的に書けるよう設計されている点です。さらに Materialized View が「即時反映の集計テーブル」として機能し、ダッシュボードを 1 秒以内で返すための基盤になります。データ圧縮率も高く、テレメトリは似た値の繰り返しが多いため 1/10 以下になることも珍しくありません。

BigQuery や Snowflake も列指向ですが、レイテンシ(数秒〜十数秒のスロット起動)と料金体系(クエリ単価)の点で、ダッシュボードの「裏側で頻繁にクエリされる用途」には合いません。ClickHouse はリアルタイム分析の即応性に振り切った設計なので、運用ダッシュボード・アラート判定・社内向け Slack 通知のようなユースケースで真価を発揮します。

私はチーム規模・予算・運用負荷のバランスで「100 万件/日を超える Claude API 利用がある場合は ClickHouse を最初の選択肢にする」というルールを使っています。それ未満であれば Postgres + 適切な集計テーブルで十分なケースもあるので、規模感に合わせて選んでください。

計測すべきイベントと最低限のスキーマ

「とりあえず全部入れる」とスキーマが肥大化します。本番運用で実際に役立つ最小限のフィールドを最初に決める点が肝心です。

私が 4 つのプロダクトで運用した経験から、以下のスキーマを推奨します。

CREATE TABLE claude_api_events (
    -- 識別子
    event_id UUID,
    request_id String,        -- Anthropic の request-id ヘッダ
    user_id String,           -- アプリ側のユーザー識別子
    workspace_id LowCardinality(String),  -- マルチテナント対応
 
    -- 時刻・モデル情報
    ts DateTime64(3, 'UTC'),  -- ミリ秒精度
    model LowCardinality(String),
    api_version LowCardinality(String),
 
    -- リクエスト・レスポンス
    input_tokens UInt32,
    output_tokens UInt32,
    cache_read_tokens UInt32 DEFAULT 0,
    cache_write_5m_tokens UInt32 DEFAULT 0,   -- 5 分 TTL の書き込み(入力単価 x1.25)
    cache_write_1h_tokens UInt32 DEFAULT 0,   -- 1 時間 TTL の書き込み(入力単価 x2)
    stop_reason LowCardinality(String),
 
    -- パフォーマンス
    latency_ms UInt32,
    ttft_ms UInt32,           -- Time To First Token
    streaming UInt8,
 
    -- 結果
    success UInt8,
    error_type LowCardinality(String) DEFAULT '',
    http_status UInt16,
 
    -- アプリ層の文脈
    feature_id LowCardinality(String),  -- 「要約」「翻訳」など機能名
    prompt_template_id LowCardinality(String),
    prompt_version UInt32 DEFAULT 0,
 
    -- コスト計算(事前計算しておくとクエリが軽い)
    cost_usd Decimal64(6) DEFAULT 0,
    cost_source LowCardinality(String) DEFAULT 'priced',   -- priced / unpriced
    inference_geo LowCardinality(String) DEFAULT 'global'  -- global / us(us は全単価 x1.1)
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(ts)
ORDER BY (workspace_id, feature_id, ts)
TTL ts + INTERVAL 18 MONTH
SETTINGS index_granularity = 8192;

設計上の重要ポイントを 4 つだけ強調します。

第一に LowCardinality(String) を効かせる列を選ぶことです。model 名や feature_id のように値の種類が少ない列は LowCardinality で宣言します。圧縮率が上がり、GROUP BY も速くなります。私のプロダクトでは導入後にストレージが約 35% 減りました。

第二に ORDER BY の順序が性能を左右します。ClickHouse は ORDER BY の先頭から順に並んだプライマリキーで部分検索を高速化します。「テナント単位 → 機能単位 → 時刻」の順は、ダッシュボードのクエリ(「特定テナントの特定機能の直近 24 時間」)に最適化された順序です。

第三にコストは事前計算しておくことです。取り込み時点で cost_usd を計算しておくと、ダッシュボードクエリが SUM 一発で済みます。価格表が変わったときの再計算は、後述のように Materialized View で吸収できます。

第四にキャッシュ書き込みを TTL 別に分けて持つことです。ここを 1 列にまとめていた時期があり、私はそのまま半年ほど運用しておりました。Claude のプロンプトキャッシュは、5 分 TTL の書き込みが入力単価の 1.25 倍、1 時間 TTL の書き込みが 2 倍で、読み出しが 0.1 倍という別々の係数で課金されます。1 列に合算すると、どちらの係数で掛けても間違いになります。usage.cache_creation には ephemeral_5m_input_tokens と ephemeral_1h_input_tokens が分かれて返ってきますので、テーブル側も最初から 2 列にしておくのが安全です。

cost_source と inference_geo の 2 列は、後半のリコンサイル(請求突き合わせ)で効いてきます。前者は「この行の金額を信じてよいか」を、後者は「1.1 倍の係数が乗る経路を通ったか」を残すための列です。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
✦「先月の API 請求がいきなり 3 倍になっていた」という事故を防げる、リクエスト単位のコスト追跡基盤を手に入れられます
✦Postgres でテレメトリを保存していてクエリが詰まっていた人が、ClickHouse + Materialized View で 1 秒以内に集計を返せる構成に切り替えられます
✦ハルシネーション疑い・リトライループ・レイテンシ急増を SQL で検出する具体的なクエリパターンを習得し、ユーザーから報告される前に異常を能動的に検知できるようになります
Stripe による安全な決済 · いつでもキャンセル可能
✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Claude Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • ✦コピー&ペーストで使える実装コード付き
  • ✦毎日新しい上級ガイドを追加
  • ✦¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

⬡ API & SDK2026-04-29
Claude API のセマンティックキャッシュを本番投入する — 類似プロンプト判定としきい値設計、汚染防止
類似プロンプトへの応答を再利用するセマンティックキャッシュをClaude APIの本番に組み込む設計を一気通貫で解説します。embeddingと類似度しきい値の決め方、マルチテナント分離、キャッシュ汚染を防ぐガード層、フォールバックと劣化モード、プロンプトキャッシュとの重ね方、効果を測る観測性の指標まで踏んだ地雷とともに紹介します。
⬡ API & SDK2026-05-26
Claude API の構造化レスポンスを本番で安定させる — tool_use と JSON Schema、多層検証の実装メモ
Claude API の応答を JSON で受け取る実装は数行で書けますが、本番運用では「形は正しいが意味が壊れている」レスポンスにどう備えるかが分かれ目になります。tool_use・JSON Schema・ドメイン検証を組み合わせた多層パイプラインを、壁紙アプリの分類処理での実体験を交えて整理しました。
⬡ API & SDK2026-05-22
Claude API の tool_result could not be submitted が再発しないための回復ハンドラ設計
Claude API でエージェントを長時間動かしていると、ある日突然 'tool_result could not be submitted' が連発し始めることがあります。再試行しても直らない、ストリーミング途中で死ぬ、そして次のセッションでもまた出る — 常時稼働のエージェント基盤で実際に踏み抜いた4種類の原因と、TypeScript で書いた回復ハンドラの実装を整理しました。