CLAUDE LABEN
FORK — Claude Code 2.1.212で/forkの挙動が変わりました。会話を新しいバックグラウンドセッションへ複製し、作業を続けたまま並走できます。従来のセッション内サブエージェントは/subtaskに移りましたLIMITS — WebSearchの呼び出しがセッション単位で既定200回に制限されました。サブエージェントの起動も既定200回が上限で、暴走した検索・委譲のループを止められますMCPBG — 2分を超えるMCPツール呼び出しは自動的にバックグラウンドへ移り、セッションが固まらなくなりました。しきい値はCLAUDE_CODE_MCP_AUTO_BACKGROUND_MSで調整できますPLANFIX — プランモードがtouchやrmといったファイルを変更するBashコマンドを、許可プロンプトもcanUseToolコールバックも通さずに実行してしまう不具合が修正されましたSONNET5 — Claude Sonnet 5は導入価格として入力100万トークンあたり2ドル、出力10ドルで提供中です。8月31日を過ぎると3ドルと15ドルに戻りますIPO — Anthropicが早ければ10月の株式公開を視野に、引受銀行が投資家との面談を組み始めたと報じられていますFORK — Claude Code 2.1.212で/forkの挙動が変わりました。会話を新しいバックグラウンドセッションへ複製し、作業を続けたまま並走できます。従来のセッション内サブエージェントは/subtaskに移りましたLIMITS — WebSearchの呼び出しがセッション単位で既定200回に制限されました。サブエージェントの起動も既定200回が上限で、暴走した検索・委譲のループを止められますMCPBG — 2分を超えるMCPツール呼び出しは自動的にバックグラウンドへ移り、セッションが固まらなくなりました。しきい値はCLAUDE_CODE_MCP_AUTO_BACKGROUND_MSで調整できますPLANFIX — プランモードがtouchやrmといったファイルを変更するBashコマンドを、許可プロンプトもcanUseToolコールバックも通さずに実行してしまう不具合が修正されましたSONNET5 — Claude Sonnet 5は導入価格として入力100万トークンあたり2ドル、出力10ドルで提供中です。8月31日を過ぎると3ドルと15ドルに戻りますIPO — Anthropicが早ければ10月の株式公開を視野に、引受銀行が投資家との面談を組み始めたと報じられています
記事一覧/API & SDK
API & SDK/2026-05-24上級

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

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

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

プレミアム記事

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

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

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

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

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

第二に 再現性。プロンプトキャッシュを有効にしているプロジェクトでは、キャッシュヒット率の改善や、システムプロンプトの差分による出力変化を観測したくなります。インプットとアウトプットの両方がアーカイブされていれば、ゴールデンデータセットを後追いで構築できます。私は _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-07-12
Claude API の 413 request too large を設計で避ける — 送信前サイズ見積もりと分割の実装
長文と画像と tool_result を1リクエストに詰めすぎると Claude API は 413 request too large で落ちます。32MB の壁・base64 の膨張・処理段階で起きる隠れた上限を実測し、送信前にサイズを見積もって安全に分割する設計をコード付きでまとめました。
API & SDK2026-07-07
Claude API が本番で突然 429 を返し始めたとき — レート制限の余白をヘッダから計測して枯渇前に絞る運用メモ
429 が出てから慌ててリトライを入れるのは後手です。Claude API のレスポンスヘッダには残量が毎回書かれています。余白を継続計測し、枯渇する前に自分から絞る運用メモを、実装フックと計測ログの読み方でまとめます。
API & SDK2026-07-01
Claude API のドキュメント抽出が「自信満々に間違える」とき — 沈黙する誤りを不変条件で捕まえる運用メモ
請求書や契約書の構造化抽出で一番怖いのは、クラッシュではなく「スキーマも通り信頼度も高いのに値だけ間違っている」沈黙の誤りです。不変条件・二段抽出・フィールド単位の誤り率で運用する実装メモを共有します。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →