Claude Fable 5.1移行｜tool_choice廃止など3つの注意点とNext.js実装

「Fable 5をやっと本番に載せたばかりなのに、もう5.1が出た。また移行検証からやり直しか」——AIモデルの更新サイクルが月単位になった2026年、Next.jsアプリにClaude APIを組み込んでいる開発チームからよく聞く悩みです。

2026年9月1日（米国時間）、AnthropicはClaude最上位モデルの改良版「Claude Fable 5.1」を発表しました（公式発表）。本記事では、Next.jsアプリケーションにClaude APIを組み込む立場から、claude-fable-5 からの移行で押さえるべき仕様変更と実装パターンを整理します。モデルの位置づけや料金の全体像は、経営者向けの解説記事（zetlinker.com）にまとめているので、本記事は実装の話に絞ります。

先に要点を3つにまとめます。

• 基本はモデルIDを claude-fable-5-1 に差し替えるだけ。APIの形式・基本料金（入力10ドル／出力50ドル）・トークナイザーはFable 5と同じで、キャッシュ読み取りは1ドル→0.25ドルの4分の1に値下げ
• ただしbreaking changeが実質3つある：①tool_choice の強制指定（any/tool）が400エラー、②thinkingブロックが生成モデルに紐づく、③会話履歴を編集するとthinkingブロックが無効化（2026年8月31日以降に作成したアカウントでは400エラーが強制）
• エージェント実装では並列ツールコールが減る・進捗テキストがthinkingブロック側に寄るなど挙動変化があり、プロンプトと thinking.display の調整で対処する

何が変わったのか？──実装者向けの変更点サマリー

Fable 5.1は「同じ料金・同じAPI・性能向上＋キャッシュ値下げ」の改良版で、既存のMessages API呼び出しコードの大半はそのまま動きます。

（2026年9月2日時点。出典：公式ドキュメント・移行ガイド）

トークナイザーも同一なので、トークン数の再見積もりは基本的に不要です。Anthropicの説明では、キャッシュ読み取りの値下げにより一般的なワークロードで約25%、キャッシュ依存度の高いエージェント型ワークロードで最大45%のコスト削減になります。システムプロンプトや参照資料をキャッシュして毎ターン読ませるNext.jsのチャット実装・エージェント実装ほど、恩恵が大きい変更です。

移行3つの注意点──400エラーを踏む前に洗い出す

① tool_choice の強制指定が400エラーになる

Fable 5.1では tool_choice: { type: "tool", name: "..." } と { type: "any" } がサポート外になり、400エラーが返ります（Fable 5では使えていた指定です）。Messages APIだけでなく、Batches APIとトークンカウントAPIでも同じチェックが入ります。

構造化データの抽出でツール強制を使っていた実装は、auto ＋ 明示的な指示 ＋ strict: true に置き換えます。

// NG：Fable 5.1では400エラー
await client.messages.create({
  model: "claude-fable-5-1",
  max_tokens: 16000,
  tools: [recordSummaryTool],
  tool_choice: { type: "tool", name: "record_summary" }, // any / tool は不可
  messages: [{ role: "user", content: doc }],
});

// OK：auto + 指示文 + strict: true で同等の確実性を得る
await client.messages.create({
  model: "claude-fable-5-1",
  max_tokens: 16000,
  tools: [{ ...recordSummaryTool, strict: true }],
  tool_choice: { type: "auto" },
  messages: [
    { role: "user", content: `次の文書を record_summary ツールで必ず記録してください。\n\n${doc}` },
  ],
});

そもそも「JSONを確実に受け取りたい」だけであれば、ツール強制ではなく構造化出力（output_config.format のJSONスキーマ指定）への置き換えが正攻法です。スキーマ通りの出力が保証されるため、Zodでのバリデーションとも相性が良い方法です。

② thinkingブロックが「生成したモデル」に紐づく

Fable 5.1が生成したthinkingブロックは、旧モデル（Fable 5・Opus 5など）では読めなくなりました。 逆方向は問題なく、旧モデルの会話をFable 5.1に引き継ぐことはできます（一方通行）。

実害が出るのは、リトライやフォールバックで会話が旧モデルに切り替わるケースです。API側が読めないブロックを自動的に削除してくれるため（削除分の課金なし）、リクエスト自体は成功しますが、切り替え直後のターンは推論の文脈を失って再計画が走るため、コストとレイテンシが一時的に増えます。従来通り「thinkingブロックは受信したまま毎ターン送り返す」実装にしておけば、コード変更は不要です。

③ 会話履歴の編集でthinkingブロックが無効化される

Fable 5.1のthinkingブロックは、そのブロックより前の system・tools・会話履歴に対して有効性が検証されるようになりました。 過去ターンの書き換え・システムプロンプトの再構築・クライアント側での履歴圧縮などを行うと、以降のthinkingブロックが無効になります。

注意すべきはアカウントによって挙動が違う点です。2026年8月31日以降に作成されたAPIアカウントではこのチェックが強制され、履歴を編集したリクエストは400エラーで拒否されます。 それ以前のアカウントでは記録のみで動作は変わりませんが、Anthropicは将来のモデルで全アカウントに強制する方針を明言しています。自社ツールを顧客のAPIキーで動かすSaaSの場合、「自分のアカウントでは動くのに、新規顧客のアカウントでは400になる」という形で先に顧客側が踏むため、いま対応しておくべき項目です。

// エラーで落とさず「無効ブロックを自動削除して続行」する設定（ベータ）
await client.beta.messages.create({
  model: "claude-fable-5-1",
  max_tokens: 16000,
  betas: ["thinking-binding-controls-2026-08-01"],
  thinking: {
    type: "adaptive",
    block_binding: { prefix_mismatch_behavior: "drop_block" }, // 既定は "error"
  },
  messages,
});

根本対応は、会話履歴を追記専用（append-only）に保つことです。途中で指示やツールを変えたい場合は、履歴を書き換えるのではなく role: "system" のメッセージ追加（ツール変更は tool_addition / tool_removal ブロック）で行います。これはプロンプトキャッシュのヒット率を保つ実装パターンとも一致するので、キャッシュ読み取りが4分の1になった今回、二重に効きます。

Next.jsではどう組み込むか？──モデルIDの環境変数化が最初の一歩

モデル更新が3ヶ月ごとに来る前提で、モデルIDはコードに直書きせず環境変数へ逃がしておくのが実務的です。

Next.js 16のApp Router＋公式TypeScript SDK（@anthropic-ai/sdk）での最小構成です。

// app/api/ai/route.ts
import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();
const MODEL = process.env.CLAUDE_MODEL ?? "claude-fable-5-1";

export async function POST(req: Request) {
  const { prompt } = await req.json();

  const stream = client.messages.stream({
    model: MODEL,
    max_tokens: 64000,
    system: [
      {
        type: "text",
        text: SYSTEM_PROMPT, // 固定文言はキャッシュ対象に（読み取り$0.25で効く）
        cache_control: { type: "ephemeral" },
      },
    ],
    messages: [{ role: "user", content: prompt }],
  });

  return new Response(stream.toReadableStream());
}

ポイントは2つです。まず、Fableラインはthinkingが常時ONで単一リクエストが数分に及ぶことがあるため、ストリーミングを標準にすること（Vercelのタイムアウト対策としても必須です）。次に、システムプロンプトに cache_control を付けてキャッシュ読み取り値下げの恩恵を確実に取ることです。

また、Fableラインは安全分類器によるリクエスト拒否（stop_reason: "refusal"）があり得ます。Fable 5.1では誤検知が大幅に減りましたが、ハンドリング自体は引き続き必要です。fallbacks: "default"（ベータ）を指定すると、拒否時にAnthropic推奨のモデル（Opus 5またはOpus 4.8）へサーバー側で自動リトライされるため、自前のリトライ実装より簡潔に済みます。

エージェント実装での挙動変化──プロンプト側で調整する3点

breaking changeではありませんが、Fable 5から挙動が変わる点が3つ公表されています。

• 並列ツールコールが減る：長いエージェントループで1ターン1ツールコールになりやすく、ターン数（＝コストとレイテンシ）が増えることがある。独立した読み取り処理をまとめて実行するよう、バッチ実行を促す指示文を追加する
• ツールコール間の進捗テキストが減る：進捗表示をUIに出している場合は、thinking.display を "updates"（ベータ）または "summarized" にして、thinkingブロック側から進捗を拾う
• 低effortでは検索ツールを呼ばず記憶で答えやすい：RAG・検索前提の実装では、該当リクエストのeffortを上げるか「必ず検索してから答える」指示を明示する

effortのデフォルトは high のままで、5段階（low〜max）すべて使えます。公式は「Fable 5用にチューニングした設定を持ち越さず、改めて計測し直す」ことを推奨しています。5.1の伸びしろは xhigh・max で最大になる一方、思考時間も延びるため、品質が要る処理だけ引き上げるのが定石です。

まとめ

• Claude Fable 5.1は2026年9月1日発表。基本料金・API形式・トークナイザーはFable 5と同じで、キャッシュ読み取りが4分の1（$0.25）になった
• 移行の要点は3つ：tool_choice の強制指定が400エラー、thinkingブロックのモデル紐づけ、履歴編集による無効化（新規アカウントは400が強制）
• 会話履歴を追記専用に保つ設計は、エラー回避とキャッシュヒット率の両方に効く。モデルIDの環境変数化とストリーミング標準化とあわせて、モデル更新に強い土台になる
• エージェント実装の挙動変化（並列コール減・進捗テキスト減・低effortの検索減）は、プロンプトと thinking.display で調整する

私たちは、Next.js構成でのClaude API組み込みを、モデル選定からPoC実装・本番移行まで一貫してお手伝いしています。「既存実装をFable 5.1に安全に移行したい」「エージェント実装のコストを見直したい」という段階からのご相談を歓迎します。Next.js × AIでのPoC開発について、15分のカジュアルな相談も受け付けています（事例・要件が固まっていなくても大丈夫です／営業はしません）。

※本記事に記載したモデルの仕様・料金・提供条件は、2026年9月2日時点の公開情報（Anthropic公式発表・公式ドキュメント）に基づく整理です。AI関連の状況は変化が速いため、実装・導入の判断にあたっては必ず公式情報で最新の内容をご確認ください。本記事はNext.js 16.x時点の情報です。