CLAUDE LABEN
SCIENCE — Claude Scienceがベータ公開され、研究ツールを統合し監査可能な成果物を生成するワークベンチが使えますMODEL — Claude Opus 4.7のfast modeが7月24日に廃止され、Opus 4.8のfast modeへの移行が必要になりますCODE — Claude Code v2.1.195でフルスクリーン時のマウス操作を無効化できるトグルが追加されましたCODE — ハイフン入りのhook matcherが部分一致ではなく厳密一致になるよう修正されましたAGENT — Claude Scienceは調整役エージェントが専門エージェントを呼び出し、引用や計算をレビューする多段構成ですCLOUD — ClaudeがMicrosoft Foundry(Azure)で一般提供され、Azureネイティブで利用できますSCIENCE — Claude Scienceがベータ公開され、研究ツールを統合し監査可能な成果物を生成するワークベンチが使えますMODEL — Claude Opus 4.7のfast modeが7月24日に廃止され、Opus 4.8のfast modeへの移行が必要になりますCODE — Claude Code v2.1.195でフルスクリーン時のマウス操作を無効化できるトグルが追加されましたCODE — ハイフン入りのhook matcherが部分一致ではなく厳密一致になるよう修正されましたAGENT — Claude Scienceは調整役エージェントが専門エージェントを呼び出し、引用や計算をレビューする多段構成ですCLOUD — ClaudeがMicrosoft Foundry(Azure)で一般提供され、Azureネイティブで利用できます
記事一覧/API & SDK
API & SDK/2026-07-01上級

モデルは残るのにパラメータだけ期限切れになる — Claude API リクエストの廃止を日付で先回りする設計

モデル名は有効なまま、指定していたパラメータだけが廃止日を迎えてバッチが落ちることがあります。リクエストを部品に分解し、部品ごとに廃止期限を持たせて起動前に先回りする設計を、TypeScript の動くコードと運用の実測でまとめました。

Claude API98デプリケーションプリフライト自動運用4TypeScript20

プレミアム記事

夜間に回している自動投稿のうち一本だけが、ある朝から静かに 400 を返すようになりました。

モデル名は変えていません。claude-opus-4-7 はドキュメント上もまだ生きています。それなのに落ちる。ログを追うと、原因はモデルではなく、私がずっと付けていた speed: "fast" の一語でした。モデルは残したまま、その上で使えるパラメータの組み合わせだけが、告知されていた廃止日をまたいでいたのです。

モデルの引退を見張る仕組みは、以前この場で書きました。起動時にモデルへ一度プローブを打ち、引退・撤回・地域制限を見分けて実行設定を書き換える、という話です。ただ今回の件は、その網の目をすり抜けました。プローブは「そのモデルが応答するか」を確かめるだけで、「そのモデルに、いま指定しているパラメータを添えて呼んでよいか」までは見ていなかったからです。

ここからは、リクエストを「モデル・パラメータ・ヘッダ」という部品の集まりとして捉え直し、部品ごとに廃止期限を持たせて起動前に先回りする設計を組んでいきます。個人開発で Dolice Labs の複数サイトを無人で回していると、こういう「一部品だけの期限切れ」がいちばん気づきにくく、いちばん静かに損失を出します。そこを塞ぐための、小さくて確実な仕掛けの話です。

モデルの寿命と、リクエストの部品の寿命は別物です

多くのプリフライトは、暗黙に「リクエスト = モデル」と見なしています。モデルIDが有効なら通す、無効なら差し替える。この前提は、モデルが丸ごと引退する場合には正しく働きます。

ところが実際の廃止は、もっと粒度が細かい形で来ます。

廃止の種類具体例モデル引退プローブで捕まるか
モデルIDの引退claude-opus-4-7 自体が撤回される捕まる
パラメータの廃止モデルは残るが speed: "fast" がエラーになる捕まらない
ベータヘッダの引退anthropic-beta の特定機能が GA 昇格して消える捕まらない
既定値の変更省略時の挙動が変わり、暗黙依存が崩れる捕まらない

問題は下の3行です。モデルは応答するのでプローブは緑を返し、けれどリクエスト全体としては拒否される。この「部分だけの死」を見張るには、監視の単位をモデルからリクエストの部品へ下げる必要があります。

考え方はシンプルです。ひとつのリクエストを、独立して寿命を持つ部品の束として表現します。そして、それぞれの部品に「いつから使えなくなるか」という日付を紐づけた台帳を、コードの外ではなくコードの中に持ちます。

部品と廃止カレンダーを型で表す

まず、リクエストから「寿命を持つ部品」を取り出す表現を決めます。ここでは部品を kind(種類)と value(値)の組で表します。

// 寿命を持つリクエストの部品
type RequestPart =
  | { kind: "model"; value: string }        // 例: "claude-opus-4-7"
  | { kind: "param"; value: string }        // 例: "speed=fast"
  | { kind: "beta"; value: string };        // 例: "anthropic-beta: code-execution-2026"
 
// 廃止カレンダーの一行
interface DeprecationEntry {
  part: RequestPart;
  // 廃止が発効する瞬間(ISO 8601・タイムゾーン付きで書く)
  effectiveAt: string;      // 例: "2026-07-24T00:00:00-07:00"
  // 移行先のヒント。人間が読む用ではなくログに出して自己記録する
  migrateTo: string;        // 例: "Opus 4.8 の fast mode(speed=fast on claude-opus-4-8)へ"
  // 情報源。あとで裏取りできるように必ず残す
  source: string;
}

effectiveAt を必ずタイムゾーン付きで書く点が肝心です。廃止告知は提供側のタイムゾーンで語られることが多く、これを素朴に「日付だけ」で持つと、あとで比較するときに自分の環境のタイムゾーンで解釈され、境界が半日ずれます。私は以前、ログの日付をタイムゾーン抜きで扱って前日分を上書きしたことがあり、それ以来「時刻を持つものは必ずゾーンごと持つ」を自分の中の鉄則にしています。

廃止カレンダーは、この一行の配列にすぎません。散らばった知識を一箇所に集めることが目的なので、正本はこのファイルひとつと決めます。

// これが唯一の正。廃止告知を見たら、ここにだけ追記する
const DEPRECATION_CALENDAR: DeprecationEntry[] = [
  {
    part: { kind: "param", value: "speed=fast" },
    // ただしこの行は「特定モデル上での」廃止なので、対象モデルも束ねる(後述)
    effectiveAt: "2026-07-24T00:00:00-07:00",
    migrateTo: "claude-opus-4-8 の fast mode へ移行(speed=fast on 4.8 は継続)",
    source: "anthropic changelog 2026-07-01",
  },
];

ここで一段だけ丁寧にします。speed=fast はどのモデルでも一律に廃止されるわけではなく、「claude-opus-4-7 の上では」廃止され、claude-opus-4-8 の上では続きます。つまり実際に見張りたいのは単独の部品ではなく、部品の共起です。カレンダーの一行を「複数部品の組が同時に揃ったとき」に発効する条件へ広げます。

interface DeprecationEntry {
  // 「これらの部品が同時に揃ったら」発効する
  when: RequestPart[];
  effectiveAt: string;
  migrateTo: string;
  source: string;
}
 
const DEPRECATION_CALENDAR: DeprecationEntry[] = [
  {
    when: [
      { kind: "model", value: "claude-opus-4-7" },
      { kind: "param", value: "speed=fast" },
    ],
    effectiveAt: "2026-07-24T00:00:00-07:00",
    migrateTo: "claude-opus-4-8 に載せ替える(4.8 上の speed=fast は継続)",
    source: "anthropic changelog 2026-07-01",
  },
];

これで「モデルは残るが、この組み合わせだけが死ぬ」を正確に表現できるようになりました。

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

この記事の続きを読む

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

この記事で得られること
モデルIDの引退監視だけでは捕まらない「パラメータ単位の廃止」を、リクエストを部品に分解して日付つきで先回りする実装
廃止日の N 日前から警告し、当日以降は起動を止める warn-ahead / fail-on-date の判定ロジックと、JST/UTC の日付境界を取り違えないための実装
廃止カレンダーを唯一の正とし、CI で「期限切れ設定を含んだままデプロイできない」状態を作るテスト設計
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

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

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

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

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

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

関連記事

API & SDK2026-07-01
Claude API のドキュメント抽出が「自信満々に間違える」とき — 沈黙する誤りを不変条件で捕まえる運用メモ
請求書や契約書の構造化抽出で一番怖いのは、クラッシュではなく「スキーマも通り信頼度も高いのに値だけ間違っている」沈黙の誤りです。不変条件・二段抽出・フィールド単位の誤り率で運用する実装メモを共有します。
API & SDK2026-07-01
新モデルが増えてもコスト集計をズラさない Claude API 単価レジストリと fail-closed 設計
Opus 4.8 と Haiku 4.5 が Messages API に加わったとき、コード中に散らばった単価がコスト集計を静かに狂わせます。単価を1か所に集約し、未知モデルを fail-closed で弾く実装を、実コード付きで紹介します。
API & SDK2026-06-26
同じモデル名で挙動が変わったとき — 無人パイプラインに起動時カナリアを置いて差分を捕まえる
Opus クラスの無言の上方更新で出力が変わっても、無人の自動投稿は気づきません。起動時に小さなカナリアを走らせ、挙動の差分を捕まえてバッチを止める設計を、実測値とともに紹介します。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →