Claude API（Anthropicが提供するLLMのAPIサービス）を使ってエージェント型のバッチ処理やCI/CD連携ツールを運用しているエンジニアに向けた話です。Anthropicは2026年9月1日に、長時間稼働するエージェント型コーディングや研究タスク向けの新モデル「Claude Fable 5.1」（claude-fable-5-1）を公開しました。SREの視点で見ると、料金は前バージョンと同じでも、モデル切り替え時に既存のリトライ設計や監視ロジックが壊れる可能性がある変更が含まれています。
価格自体はClaude Fable 5と同じ、入力$10・出力$50（1メガトークンあたり）です。変わったのは、プロンプトキャッシュ（同一の入力を再利用してコストと遅延を削減する仕組み）のキャッシュ読み取り価格です。従来は基本入力価格の0.1倍でしたが、Claude Fable 5.1とProject Glasswing参加者向けのClaude Mythos 5.1では0.025倍、$0.25/MTokまで下がっています。キャッシュ書き込みの価格は変わりません。
何が変わったのか、段階的に見る
最初に確認したいのは、コンテキストウィンドウ（モデルが一度に処理できる入力と出力の合計トークン数）です。両モデルともデフォルトで100万トークン、最大出力は128kトークンです。長大なコードベース全体をコンテキストに載せてリファクタリングを依頼するような使い方では、この上限が実質的なボトルネックになります。事前にトークン数を見積もる際は、Anthropicが提供するトークンカウント用エンドポイントで実測しておくと安全です。
次に大きいのが「常時オンの適応的思考（always-on adaptive thinking）」です。これはモデルが応答前に内部で推論ステップを行う機能で、以前は明示的にthinkingパラメータを指定する運用でした。Claude Fable 5.1では常時有効化されているため、レイテンシ（応答までの待ち時間）のばらつきが増える可能性があります。SLO（サービスレベル目標）にレスポンスタイムのp95・p99を設定している基盤では、この変更を境に基準値の見直しが必要です。
もうひとつの重要な変更が、思考ブロック（thinking blocks、モデルの推論過程を表すレスポンス要素）の保持ルールです。Claude Fable 5.1が生成した思考ブロックは、同モデルか、それより新しいモデルにしか渡せません。古いモデルにリプレイ（再送信）すると、APIは思考ブロックを自動的に破棄します。さらに、2026年8月31日以降に作成された新規アカウントでは、システムプロンプトやツール定義、それより前のメッセージが変更された状態で思考ブロックを再送すると400エラーが返る仕様になりました。
これはマルチターンのエージェントを組んでいる場合に地味に効きます。たとえば、ツール定義をA/Bテストで動的に切り替えるような設計をしていると、履歴の整合性チェックに引っかかってエラーが増える可能性があります。ベータヘッダー thinking-binding-controls-2026-08-01 を付けると、破棄されたブロックを input_transformations フィールドで検知できるほか、prefix_mismatch_behavior でエラーにするか破棄にするかを選べます。
既存の運用設計との比較で見る影響範囲
ツール呼び出しの制御でも変更があります。tool_choice の any と tool タイプが未サポートとなり、400エラーになります。auto と none は変わりません。スキーマに厳密に従うツール入力を強制したい場合は、strict tool use（厳格なツール使用モード）か構造化出力機能を使う設計に切り替える必要があります。従来 tool_choice で特定ツールを強制していた実装があれば、事前に洗い出しておくべきポイントです。
コスト最適化の観点では、キャッシュ読み取り価格の低下は歓迎できる変化です。ただし、Turn-scoped system messages（ターン限定のシステムメッセージ、ベータ機能）や、Per-message effort changes（メッセージ単位で推論の労力を変更する機能、ベータ機能）はいずれもベータヘッダーが必要です。ベータ機能は本番のSLA（サービス品質保証）の対象外になっている場合が多く、Terraformなどで管理しているAPI設定やIaC（Infrastructure as Codeの略、インフラ定義をコードで管理する手法）のテンプレートに、恒久的な依存として組み込む前に社内のリスク許容度を確認しておくのが無難です。
今日確認できること
まず、使用中のモデルIDが claude-fable-5-1 または旧 claude-fable-5 のいずれかを、APIリクエストログやIaCのモジュール変数から確認してください。Terraformでモデル名を変数化している場合は、terraform plan を実行する前に model_id の差分を必ず目視で確認する運用が安全です。
続いて、オブザーバビリティ（可観測性、システムの内部状態を外部から把握できるようにする設計）の観点から、レイテンシのダッシュボードを見直します。常時オンの適応的思考によって応答時間の分布が変わるため、アラート閾値を過去のベースラインのまま使い続けると誤検知や検知漏れが起きやすくなります。移行後1〜2週間はp50・p95・p99を並べて記録し、SLOの再設定に使えるデータを蓄積しておくと判断しやすくなります。
最後に、思考ブロックを扱うマルチターンのエージェントを運用しているなら、thinking-binding-controls-2026-08-01 ベータヘッダーを一度ステージング環境で有効化し、input_transformations にどの程度のブロック破棄が記録されるか確認しておくと安心です。特定ツールの強制指定を使っている箇所も、コード検索で洗い出しておきましょう。
まとめ
Claude Fable 5.1は価格面では大きな変更がない一方、思考ブロックの保持ルールとツール制御の仕様変更が、既存のエージェント基盤の振る舞いに影響します。
対応の優先順位としては、モデルIDの棲み分け確認、レイテンシ計測に基づくSLOの再調整、tool_choice の使用箇所の洗い出しの3点が現実的な出発点です。
ベータ機能への依存は本番導入前にリスクを見極め、段階的に取り込む姿勢が安心につながります。