CLAUDE LABEN
VERSION — 8月10日に v2.1.227 が出ていました。新機能はなく、プラン判定と CI まわりの不具合修正が中心ですAUTO — 8月14日の既定化まで残り2日です。Pro・Max・Team で Claude Code の auto モードが既定で有効になりますCI — claude-code-action で allowed_non_write_users を指定すると GitHub ホストランナー上の Bash が全て失敗していた問題が直りましたBILLING — 期限切れトークンで開始したセッションが加入プランを取り違え、Max 利用者に使用クレジットの有効化を促していた不具合も解消していますSUNSET — 旧 Workbench と実験的プロンプトツール API の廃止は8月17日で、残り5日ですPRICE — Sonnet 5 のプロモ価格 $2/$10 per Mtok は8月31日までで、9月1日から $3/$15 per Mtok になりますVERSION — 8月10日に v2.1.227 が出ていました。新機能はなく、プラン判定と CI まわりの不具合修正が中心ですAUTO — 8月14日の既定化まで残り2日です。Pro・Max・Team で Claude Code の auto モードが既定で有効になりますCI — claude-code-action で allowed_non_write_users を指定すると GitHub ホストランナー上の Bash が全て失敗していた問題が直りましたBILLING — 期限切れトークンで開始したセッションが加入プランを取り違え、Max 利用者に使用クレジットの有効化を促していた不具合も解消していますSUNSET — 旧 Workbench と実験的プロンプトツール API の廃止は8月17日で、残り5日ですPRICE — Sonnet 5 のプロモ価格 $2/$10 per Mtok は8月31日までで、9月1日から $3/$15 per Mtok になります
記事一覧/API & SDK
API & SDK/2026-06-27上級

自己修復ループに「諦める条件」を設計する — エラーを4分類して再試行予算を割り当てる

LLMの自己修復ループは「直し続ければいつか通る」という前提で組むと破綻します。エラーを4つのクラスに分類し、クラスごとに再試行予算を割り当てて諦める条件を明示する設計を、動くTypeScriptの分類器実装、コスト天井の置き方、構造化した試行ログ、フォールバックの段構えとともに解説します。

Claude API116自己修復リトライ設計エラーハンドリング7本番運用36

プレミアム記事

深夜、無人で回している生成パイプラインのコストが、前日の3倍に跳ねていました。

落ちていたわけではありません。むしろ逆で、すべての処理が「最終的に成功」と記録されていました。原因を追うと、ある一本の処理が同じ出力を27回作り直していました。検証に通らない出力を、ループが律儀に「もう一度」と投げ続けていたのです。

LLMの自己修復ループには、静かな落とし穴があります。「直せば通る」という前提でループを書くと、直しようのないエラーに対しても永遠に直そうとします。本番で効くのは、修復の巧みさよりも、いつ修復をやめるかの判断です。

ここでは、エラーを4つに分類し、クラスごとに再試行予算を割り当てる設計を扱います。コードはコピーして動く形で示します。

なぜ「素朴な再試行」は本番で壊れるのか

最初に書きがちなのは、こういうループです。

// アンチパターン: 通るまで直し続ける
async function generateUntilValid(prompt: string) {
  while (true) {
    const out = await callClaude(prompt);
    if (validate(out).ok) return out;
    prompt = `${prompt}\n\n前回の出力は検証に失敗しました。修正してください。`;
  }
}

このコードは、対話的に人が見ている場面では問題になりません。数回で諦めて手で直すからです。

壊れるのは無人運用です。検証ロジックのバグ、満たせない制約、モデル側の一時的な不調 — これらはすべて「修正してください」では解決しません。それでもループは回り続け、トークンを焼き続けます。

問題の本質は、再試行を「一律」に扱っていることにあります。一時的な過負荷(429や529)と、構造的に満たせない制約とでは、取るべき行動がまったく違います。前者は待てば直り、後者は何度投げても直りません。

エラーを4つに分類する

実運用で再試行の判断に効くのは、次の4分類です。原因の所在ではなく「どう対処すべきか」で分けるのがポイントです。

クラス典型例正しい対処再試行予算の目安
transient(一時的)429 / 529 / タイムアウト / ネットワーク断指数バックオフで待って再送。プロンプトは変えない5〜7回(バックオフ込み)
repairable(修復可能)JSON崩れ / スキーマ不一致 / 必須フィールド欠落エラー内容を添えて1〜2回だけ作り直す2回まで
semantic-invalid(意味的に不正)事実誤り / 制約違反 / 品質ゲート不合格同じ依頼を繰り返さない。アプローチ自体を変える1回(別戦略で)
hard-fail(恒久的失敗)401 / 400(入力不正)/ モデル未存在 / 満たせない制約即座に中断。人手かフォールバックへ0回

この4分類の価値は、「諦める条件」がクラスごとに自然に決まることです。hard-fail は0回、semantic-invalid は別戦略で1回。同じ依頼の単純リトライが意味を持つのは、実は transient だけです。

repairable と semantic-invalid の違いが、設計上いちばん大切です。repairable は「形が壊れている」だけなので、エラーを見せれば直ります。semantic-invalid は「中身が要件を満たしていない」ので、同じ頼み方を繰り返しても堂々巡りになります。冒頭の27回は、semantic-invalid を repairable と取り違えていた典型でした。

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

この記事の続きを読む

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

この記事で得られること
エラーを transient / repairable / semantic-invalid / hard-fail の4クラスに分け、クラスごとに再試行予算を割り当てる判定器の実装(動くTypeScript)
「諦める条件」を明示しないと無人パイプラインのトークンコストが何倍にも膨らむ理由と、予算上限・コスト天井の引き方
修復ループが沈黙したまま回り続ける事故を防ぐ、試行ログとフォールバック(別アプローチへの切替・人手への委譲)の組み込み方
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-02
Message Batches に2万件投げたら41件だけ静かに欠けていたとき — 部分失敗を照合して再投入する運用メモ
Message Batches API の processing_status: ended は全件成功を意味しません。errored・expired が結果に静かに混ざる仕組みと、custom_id 台帳で欠落を照合し二重処理なく再投入する実装を、実運用の計測値とともに整理します。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →