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

Claude API のレスポンスを Cloudflare R2 にアーカイブする実装メモ — 監査・再現性・障害分析の3軸設計

Claude API のリクエストとレスポンスを Cloudflare R2 に保存して、監査・障害分析・本番リプレイの3つに使う設計を、Workers の waitUntil パターンと D1 メタデータインデックス込みで実装メモにまとめました。

Claude API128Cloudflare R2Workers監査ログ障害分析本番運用36

✦ プレミアム記事

Claude API を実運用に組み込んでいると、どこかのタイミングで「あのとき返ってきたレスポンスをもう一度見たい」という瞬間が必ず訪れます。ユーザーから「先週の出力がおかしかった」と問い合わせを受けたとき、429 が断続的に起きていた時間帯のリクエストを後追いしたいとき、プロンプトのリグレッションを疑ったとき。私の場合は、AdMob の eCPM 監視ボットがある朝だけ妙な出力を返していて、その原因を追うのに丸一日かかりました。console.log の断片しか手元になく、結局推測で再現を試みるしかなかったのです。

それ以来、Claude API の入出力は 必ず Cloudflare R2 にアーカイブする という方針で運用しています。個人開発のアプリとサイトのバックエンドで、いま動いている設計を実装メモとして残しておきます。読み終えたあと、すぐに Workers のソースに archiveResponse(...) の 5 行を足せる粒度を目標にしました。

なぜ Claude API のレスポンスをアーカイブするのか — 3つの実運用ニーズ

最初に整理しておきたいのは「何のために残すのか」です。アーカイブを目的なく集めても、ストレージ代を払い続けるだけのデータ墓場になります。私が R2 に保存するときは、次の 3 つのいずれかに合致するときだけ書き込むようにしています。

第一に 監査ログ。生成 AI が出力したテキストは、特に有料機能の裏側で動かしているとき、後日「本当に AI がそう書いたのか、こちらが改変したのか」を示す必要が出てきます。私のアプリでも、ユーザーレビュー返信機能の出力が「事実と異なる」と指摘されたことがあり、当時のレスポンス本体をそのまま提示できたことで誤解を解いた経験があります。stop_reason が refusal だったケースをあとから集計するときも、レスポンスそのものが残っていないと議論になりません。

第二に 再現性。プロンプトキャッシュを有効にしているプロジェクトでは、キャッシュヒット率の改善や、システムプロンプトの差分による出力変化を観測したくなります。インプットとアウトプットの両方がアーカイブされていれば、ゴールデンデータセットを後追いで構築できます。私は _documents/_quality_audit/ のリグレッションテストを R2 アーカイブから半自動で組み立てており、過去のレスポンスを tools/build_golden.ts に流して、Sonnet 4.6 → Opus 4.6 アップグレード時の品質変動を測りました。

第三に 障害分析。529 Overloaded が断続的に起こる時間帯のリクエスト傾向、max_tokens で打ち切られているケースの分布、ストリーミング途中で切れた接続の特徴。リアルタイムにアラートを出すための observability は別途必要ですが、根本原因を突き詰めるときには「あのとき本当に何が送られて、何が返ってきたか」のフル本文が手元にあるかどうかで作業時間が桁違いに変わります。

この 3 つのうち、自分のプロジェクトで該当するものが 1 つでもあるならアーカイブの価値があります。逆に、すべてが「いまの自分には不要」だと感じるなら、まだ書き込む必要はありません。

アーカイブのデータモデル設計 — キー戦略とパーティション粒度

R2 はオブジェクトストレージなので、ディレクトリの概念は実体としては存在せず、キー名がそのまま検索のすべてです。ここを雑に設計すると、後日「先週の特定ユーザーのレスポンスだけ取り出したい」というときに、全件 LIST して舐めることになって悲しい気持ちになります。

私が運用しているキー命名規則はこうです。

claude-archive/
  {YYYY}/
    {MM}/
      {DD}/
        {HH}/
          {request-id}.json

例えば claude-archive/2026/05/24/02/req_01HXYZ.json のように展開されます。日時のパーティショニングを 1 時間粒度で切るのは、後述するライフサイクル管理(古いものを Infrequent Access に落とす)と、R2 の LIST 上限(1000 件 / リクエスト)を意識した結果です。1 日 1 ディレクトリに集めると 24 時間ぶんが一気に増え、月 100 万リクエスト規模になると 1 ディレクトリ 3.3 万件で LIST が面倒になります。1 時間粒度なら平均 1400 件で、たいていは 1 回の LIST で収まる範囲です。

request-id は Anthropic のレスポンスヘッダー request-id(または x-request-id を環境によって名乗ります)から取り、それをそのままキーに使います。これによって、ユーザーから「サポート対応で送られた req_01HXYZ... の出力を見たい」と頼まれたら、年月日時さえ分かれば一発で引けます。request-id が手元にないときは、後述する D1 のメタデータインデックスから引きます。

オブジェクト本体には、リクエストとレスポンスを JSON でまとめて入れます。最低限保存するフィールドは次の通りです。

{
  "schema_version": "v1",
  "request_id": "req_01HXYZ...",
  "ts": "2026-05-24T02:00:13.412Z",
  "model": "claude-sonnet-4-6",
  "request": {
    "system": "<masked or hashed>",
    "messages": [...],
    "tools": [...],
    "max_tokens": 4096,
    "metadata": {"user_id": "u_abc"}
  },
  "response": {
    "id": "msg_01HXYZ...",
    "stop_reason": "end_turn",
    "usage": {
      "input_tokens": 1234,
      "cache_read_input_tokens": 800,
      "output_tokens": 567
    },
    "content": [...]
  },
  "headers": {
    "anthropic-organization-id": "org_...",
    "retry-after": null
  },
  "client": {
    "site": "claudelab",
    "version": "2026.05.24-abc1234"
  }
}

schema_version を最初から入れておくのは、ほぼ確実に「あとでフィールドを足したくなる」からです。私のプロジェクトでは v1 → v2 で cache_read_input_tokens を後追いで足したことがありました。最初に v1 と書いておけば、リプレイ側で「このフィールドが無いのは古い形式」と判断できます。これを入れ忘れて、4 ヶ月後にメタデータの後方互換で痛い目を見たので、本当に最初の段階で入れておくのをお勧めします。

✦

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

この記事の続きを読む

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

この記事で得られること
✦Claude API のレスポンスを非同期で R2 に保存する Workers 実装と、リクエストレイテンシをほぼ増やさない waitUntil パターン
✦障害時に request-id 1つでアーカイブを引き出す D1 メタデータインデックスの設計と、リプレイ手順の具体例
✦PII マスキング・ストレージ階層・Class A 操作回数まで含めた、月数十万リクエスト規模の R2 コスト試算
Stripe による安全な決済 · いつでもキャンセル可能
✦

この記事を購入する

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

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

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

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

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

関連記事

⬡ API & SDK2026-05-04
Bun × Claude API で本番運用するエッジAIサービス — Node.js移行の判断軸と落とし穴を回避する実装パターン
Claude APIをBun上で本番運用するための実装ガイド。Node.jsからの移行判断軸・組み込みSQLite/WebSocketの活用・ストリーミング最適化・典型的な落とし穴の回避策まで、動作するコードと実測値で解説します。
⬡ API & SDK2026-04-30
Claude API で多言語翻訳 SaaS を本番運用する設計ガイド — 用語集・スタイル・ドメイン適応の実装
多言語翻訳SaaSをClaude APIで本番運用するための設計を通しで解説します。タグやプレースホルダーを失わせない前処理、用語集の注入と強制、スタイルガイドによるトーン制御、Few-shotでのドメイン適応、品質ゲートとコスト最適化まで、具体的なコードと運用ノウハウでまとめました。
⬡ API & SDK2026-10-16
Make から Claude API に 40 行流すと 14 行目で止まる — 429 を待ち時間の計算で避ける
表計算の行を1件ずつ Claude API に渡すノーコード自動化が、途中で 429 になる理由と直し方です。模擬バケットで7通りの間隔を比べ、Sleep の秒数を 60÷上限−応答時間 で決める式と、失敗行を落とさない設定を示します。