◉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-06-15上級

モデルが予告なく使えなくなる日に備える — 引退・撤回・過負荷を一つのステートマシンで扱うルーター設計

あるモデルが、技術的な障害ではなく外部都合で短時間のうちに使えなくなる。引退・撤回・一時的な過負荷という三種の「使えない」を一つの可用性ステートマシンで扱い、自動運用を止めないルーターを TypeScript と Python の動くコードで設計します。

claude-api83architecture7resilience8model-migration5production87fallback8

✦ プレミアム記事

朝、Dolice Labs の 4 サイトの自動投稿を回す前に、いつものように changelog と公式のお知らせを開きました。前日まで動作確認に使っていたモデルのうち一つが、技術的な障害ではない理由で、全外国籍ユーザー向けに短時間のうちに停止されていました。引退の予告メールが来ていたわけでも、429 が返り始めたわけでもありません。ただ、昨日まで応答していたモデル名が、今日は受け付けられなくなっていた。

私が個人開発で運用しているのは記事生成のパイプラインで、人命や決済が絡むものではありません。それでも、headless 実行で夜間に走る工程が「あるモデル名を前提に書かれている」という事実は、急に重く感じられました。フォールバックは一応書いてあったのですが、その分岐は 429 と 529、つまり一時的な過負荷だけを想定していたのです。恒久的な引退や、外部都合による突然の撤回は、同じ fallback() の中で十把一絡げに扱われていました。

この日に学んだのは、「使えない」には性質の違う複数の顔があり、それらを区別せずに一つの例外処理へ流し込むと、復旧の判断を誤る、ということでした。一時的な過負荷なら数分待てば戻ります。けれど撤回されたモデルを数分おきに叩き続けるのは、無駄な失敗を積み増すだけです。引退したモデルに至っては、待っても永遠に戻りません。ここから設計するのは、この三種類を別の状態として持ち、状態に応じて振る舞いを変える可用性ステートマシンと、それを土台にしたルーターです。

「使えない」には三つの顔がある

まず、自動運用を止める「使えない」を性質で分類します。私は次の三つに整理しました。

ひとつ目は 引退(retirement) です。ベンダーが事前に告知し、ある期日を境に恒久的に受け付けなくなるものです。今日、旧世代の claude-sonnet-4 と claude-opus-4 が API から引退しました。これは予測可能で、移行先も決まっています。待っても戻らないので、検知したら即座に後継へ切り替えるのが正解です。

ふたつ目は 撤回(withdrawal) です。技術的な障害ではなく、方針・法令・セキュリティ上の判断などの外部都合で、短時間のうちに一時停止されるものです。期日の予告はなく、復旧の見込みは「いずれ戻るかもしれない」程度の不確実性を持ちます。冒頭で触れたケースがこれにあたります。引退と違って後継が用意されているわけではないので、別の論理ロールへ横移動するか、その工程を一時的に縮退させる判断が要ります。

みっつ目は 過負荷(overload) です。429 Too Many Requests や 529 Overloaded のように、数分から数時間で自然に戻る一時的な不可用です。ここで恒久的な切り替えをしてしまうと、本来使いたかった上位モデルから不必要に降格したままになります。指数バックオフで待ち、回復したら元に戻すのが筋です。

この三つを一つの catch で扱うと、撤回されたモデルに過負荷向けのバックオフを延々と適用したり、過負荷のモデルを引退扱いで恒久降格したりという、判断の取り違えが起きます。状態を分けて持つ理由はここにあります。

論理ロールと物理モデルIDを切り離す

ステートマシンを設計する前に、土台となるレジストリを整えます。業務コードがモデル文字列を直接知っているうちは、撤回や引退のたびに数十箇所を書き換えることになります。私自身、最初はそれで痛い目を見ました。

そこで、コードが参照するのは 論理ロール(fast / balanced / deep)だけにし、論理ロールから物理モデルIDへの対応と、各モデルの可用性状態を一箇所に集約します。

// model-registry.ts
export type Role = "fast" | "balanced" | "deep";
export type Availability = "available" | "overloaded" | "withdrawn" | "retired";
 
interface ModelEntry {
  id: string;            // 物理モデルID
  inputPer1M: number;    // 入力トークン単価(USD / 1M tokens)
  outputPer1M: number;   // 出力トークン単価
  availability: Availability;
  // 撤回・引退時にこのロールで次に試す代替モデルID(同ロール内の縮退先)
  understudy?: string;
}
 
// ロールごとに「優先度順」の候補列を持つ。先頭が第一候補。
export const REGISTRY: Record<Role, ModelEntry[]> = {
  deep: [
    { id: "claude-opus-4-8", inputPer1M: 5.0, outputPer1M: 25.0, availability: "available" },
    { id: "claude-sonnet-4-6", inputPer1M: 3.0, outputPer1M: 15.0, availability: "available" },
  ],
  balanced: [
    { id: "claude-sonnet-4-6", inputPer1M: 3.0, outputPer1M: 15.0, availability: "available" },
    { id: "claude-haiku-4-5", inputPer1M: 1.0, outputPer1M: 5.0, availability: "available" },
  ],
  fast: [
    { id: "claude-haiku-4-5", inputPer1M: 1.0, outputPer1M: 5.0, availability: "available" },
  ],
};

業務コードは route("deep") のように論理ロールでモデルを要求し、物理IDを一切知りません。撤回されたモデルを全工程から外したいときは、REGISTRY の該当エントリの availability を 1 行書き換えるだけで済みます。これが「変更を 1 ファイルに閉じ込める」という設計の核です。

✦

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

この記事の続きを読む

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

この記事で得られること
✦「引退(予告ありの恒久廃止)」「撤回(短時間での一時停止)」「過負荷(数分〜数時間の 429/529)」を別状態として持つ可用性ステートマシンの遷移表と、状態ごとに振る舞いを変えるルーターの実装
✦論理ロール(fast / balanced / deep)と物理モデルIDを 1 ファイルに集約し、撤回されたモデルを 1 行の状態変更で全工程から外す ModelRegistry の設計(TypeScript / Python 両対応)
✦日次プリフライトで撤回を 1 回の軽量呼び出しで検知する probe と、フォールバック時にトークン単価を自動で付け替えてコスト記録を狂わせない計上ロジック
Stripe による安全な決済 · いつでもキャンセル可能
✦

この記事を購入する

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

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

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

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

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

関連記事

⬡ API & SDK2026-04-23
Claude API の高可用性設計 — Sonnet / Haiku / Opus マルチモデルフォールバックを本番で成立させる
Claude API を単一モデル前提で組むと、障害やレート制限の瞬間にサービス全体が止まります。Sonnet・Haiku・Opus を段階的にフォールバックする本番実装を、コード・Circuit Breaker・ストリーミング対応まで含めて整理しました。
⬡ API & SDK2026-03-27
Claude API プロダクション耐障害設計パターン — モデルルーティング・サーキットブレーカー・フォールバック戦略の実装ガイド
Claude APIを本番運用で支える耐障害設計の実装パターン。サーキットブレーカー、モデルルーティング、フォールバックチェーン、リトライ戦略、ディザスタリカバリをTypeScriptの実装コードと、運用で気づいた注意点を添えて整理しました。
⬡ API & SDK2026-05-26
Claude API の構造化レスポンスを本番で安定させる — tool_use と JSON Schema、多層検証の実装メモ
Claude API の応答を JSON で受け取る実装は数行で書けますが、本番運用では「形は正しいが意味が壊れている」レスポンスにどう備えるかが分かれ目になります。tool_use・JSON Schema・ドメイン検証を組み合わせた多層パイプラインを、壁紙アプリの分類処理での実体験を交えて整理しました。