CLAUDE LABEN
BILLING — 6/15の課金変更が本日発効。Agent SDK・headless・GitHub Actions・他社エージェントがサブスク上限から外れ、別枠の月次クレジット($20/$100/$200・full APIレート・繰越なし)へ移行しましたRETIRED — 本日6/15、Sonnet 4とOpus 4がAPIから引退。旧世代モデルを参照しているスクリプトは最新世代(Opus 4.8など)へ切り替えが必要ですEXPORT — Claude Fable 5・Mythos 5が米政府の輸出管理指令を受け全外国籍ユーザー向けに停止中(6/12)。Anthropicは誤解に基づくとして早期復旧を目指すと表明しましたSAFE — 停止対象は新Mythosクラス2モデルのみで、Opus 4.8など他の全モデルは通常どおり稼働していますSUBAGENTS — Claude Codeでサブエージェントが自身のサブエージェントを生成可能に(最大5階層)。Dynamic workflowsもリサーチプレビューで登場しましたINCIDENT — 6/5にclaude.ai・API・Claude Code・Coworkで広範なエラー率上昇が発生。自動運用ではリトライとフォールバック設計が改めて重要ですBILLING — 6/15の課金変更が本日発効。Agent SDK・headless・GitHub Actions・他社エージェントがサブスク上限から外れ、別枠の月次クレジット($20/$100/$200・full APIレート・繰越なし)へ移行しましたRETIRED — 本日6/15、Sonnet 4とOpus 4がAPIから引退。旧世代モデルを参照しているスクリプトは最新世代(Opus 4.8など)へ切り替えが必要ですEXPORT — Claude Fable 5・Mythos 5が米政府の輸出管理指令を受け全外国籍ユーザー向けに停止中(6/12)。Anthropicは誤解に基づくとして早期復旧を目指すと表明しましたSAFE — 停止対象は新Mythosクラス2モデルのみで、Opus 4.8など他の全モデルは通常どおり稼働していますSUBAGENTS — Claude Codeでサブエージェントが自身のサブエージェントを生成可能に(最大5階層)。Dynamic workflowsもリサーチプレビューで登場しましたINCIDENT — 6/5にclaude.ai・API・Claude Code・Coworkで広範なエラー率上昇が発生。自動運用ではリトライとフォールバック設計が改めて重要です
記事一覧/API & SDK
API & SDK/2026-06-15上級

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

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

claude-api61architecture7resilience7model-migration2production74fallback6

プレミアム記事

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

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

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

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

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

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

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

みっつ目は 過負荷(overload) です。429 Too Many Requests529 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-06-03
Claude API のモデル抽象レイヤー設計 — 世代交代に業務ロジックを巻き込まない内部アーキテクチャ
モデル文字列を業務コードに直書きすると、世代交代のたびに本番が静かに壊れます。論理ロールと物理モデルIDを切り離す anti-corruption layer を、TypeScript と Python の動くコード・移行コスト・実運用の判断軸とあわせて設計します。
API & SDK2026-05-26
Claude API のグレースフル・デグラデーション設計 — AI 機能が静かに動き続ける 4 階層フォールバック
Claude API を本番運用すると、モデル単位のフォールバックだけでは守りきれない時間帯が必ず出てきます。SLI 連動の 4 階層デグラデーション設計を、Python と TypeScript のコード・SLO バーンレート・実運用の判断軸とあわせて整理しました。
API & SDK2026-04-23
Claude API の高可用性設計 — Sonnet / Haiku / Opus マルチモデルフォールバックを本番で成立させる
Claude API を単一モデル前提で組むと、障害やレート制限の瞬間にサービス全体が止まります。Sonnet・Haiku・Opus を段階的にフォールバックする本番実装を、コード・Circuit Breaker・ストリーミング対応まで含めて整理しました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →