CLAUDE LABEN
CODE — Claude Codeに大型の品質・信頼性アップデート。/rewindでの巻き戻し、MCPレジリエンス向上、OAuthハンドリングの安定化が入りましたCODE — ストリーミングと長時間セッション中のCPU・メモリ使用量が削減され、長く回す自動運用が安定しますADMIN — 組織向けモデル制限が追加され、管理者が利用可能なモデルを制御できるようになりましたMCP — 構造化出力・リモートMCP・セッション再開(resume)の信頼性が向上しましたMODEL — Claude Fable 5が一般提供。100万トークン文脈・常時アダプティブ思考・128K出力が特徴ですLINEUP — 主力はOpus 4.8・Sonnet 4.6・Haiku 4.5。用途に応じて使い分けられますCODE — Claude Codeに大型の品質・信頼性アップデート。/rewindでの巻き戻し、MCPレジリエンス向上、OAuthハンドリングの安定化が入りましたCODE — ストリーミングと長時間セッション中のCPU・メモリ使用量が削減され、長く回す自動運用が安定しますADMIN — 組織向けモデル制限が追加され、管理者が利用可能なモデルを制御できるようになりましたMCP — 構造化出力・リモートMCP・セッション再開(resume)の信頼性が向上しましたMODEL — Claude Fable 5が一般提供。100万トークン文脈・常時アダプティブ思考・128K出力が特徴ですLINEUP — 主力はOpus 4.8・Sonnet 4.6・Haiku 4.5。用途に応じて使い分けられます
記事一覧/API & SDK
API & SDK/2026-06-27上級

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

LLMの自己修復ループは「直し続ければいつか通る」という幻想で破綻します。エラーを4つに分類し、クラスごとに再試行予算を引く設計を、動くTypeScriptと実測コストで解説します。

Claude API89自己修復リトライ設計エラーハンドリング5本番運用32

プレミアム記事

深夜、無人で回している生成パイプラインのコストが、前日の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-06-23
同じモデルが環境ごとに別名になる問題 — Claude をマルチプロバイダーで呼ぶ識別子リゾルバの設計
Fable 5 が API・Bedrock・Vertex で同時に使えるようになった結果、同じモデルが環境ごとに別の識別子を持つようになりました。ハードコードした model 文字列が移行を阻む問題を、論理モデル名・能力フラグ・起動時検証を備えた識別子リゾルバで畳み直す実装を整理します。
API & SDK2026-06-21
service_tier で優先枠をユーザー応答だけに振り向ける
Priority Tier を契約しているのにピーク時だけユーザー向け応答が遅くなる——その原因を service_tier の auto と standard_only の挙動から切り分け、背景ジョブを優先枠から隔離する構成を、自動運用の実例とともにまとめました。
API & SDK2026-06-20
サブエージェントの並列実行で、1つの失敗が全体を巻き込まない設計
複数のサブエージェントを並列に走らせる fan-out / fan-in 構成を、トークン予算・結果コントラクト・部分失敗の扱いまで含めて設計します。1つのブランチが落ちても全体を止めない実装と実測値を共有します。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →