Claude Opus 5.5への移行手順｜Next.jsアプリの保守としてAIモデル更新に追従する

Next.jsアプリにAIを組み込むと、フレームワークのバージョンアップとは別に、モデルの更新という保守項目が増えます。 Next.js本体が年に数回のセキュリティリリースを出すのと同じように、AIモデルも数ヶ月おきに新版が出て、そのたびに移行の判断が発生します。

2026年9月22日に発表されたClaude Opus 5.5は、その典型例です。単価は下がりましたが、Opus 5向けに書いたコードがそのままでは400エラーで落ちる変更を4つ含んでいます。

本記事は「Opus 5.5とは何か」の解説ではなく、すでに稼働しているNext.jsアプリを、どう安全に新モデルへ移すかという運用の話です。モデルの特徴や料金の考え方そのものは経営者向けの解説記事（zetlinker.com）にまとめています。

先に結論です。

• モデル更新はNext.jsの保守運用の一部として扱う。モデルIDを環境変数に逃がし、検証環境で先に踏み、切り替え後に計測する、という3点が土台になる
• Opus 5.5には破壊的変更が4つある。該当コードがあるかを事前に洗い出せば、本番で400エラーを踏まずに済む
• いちばん実害が出やすいのは破壊的変更ではなく、effort の既定値が high から medium に下がったこと。エラーにならないまま品質が変わる

モデル更新を保守運用としてどう組み込むか？

先に運用の土台を作っておくと、次のモデルが出たときの作業が「調査」ではなく「確認」で済みます。

Next.jsアプリにClaude APIを組み込む場合、最低限この3つを押さえておくと移行コストが下がります。

① モデルIDをコードに直書きしない

モデル名をソースコードに埋め込むと、切り替えのたびにコード修正とデプロイが必要になります。環境変数に逃がしておけば、切り戻しも環境変数の変更だけで済みます。

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

const client = new Anthropic();
// 環境変数で切り替える。未設定時のみ既定値を使う
const MODEL = process.env.CLAUDE_MODEL ?? "claude-opus-5-5";

これにより、検証環境だけ新モデル・本番は旧モデル、という並行運用ができます。問題が出た場合の切り戻しも、デプロイを伴わずに実施できます。

② 破壊的変更を検証環境で先に踏む

モデル更新の告知には移行ガイドが付きます。本番を切り替える前に、移行ガイドに挙がっている変更点が自社コードに該当するかを検索で洗い出します。 後述の4点は、いずれも文字列検索で該当箇所を特定できます。

③ 切り替え後に品質とコストを計測する

モデルを変えると、エラーにならないまま挙動が変わることがあります。Opus 5.5の effort 既定値の変更がまさにこれです。切り替え前後で、同じ入力に対する出力と請求額を比較できる状態を作っておきます。

Opus 5.5で何が変わったのか

エンドポイント・リクエスト形式・トークナイザーはOpus 5と同じです。 トークン数の再見積もりは不要で、変わるのはthinkingとツール指定まわりの前提です。

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

Amazon Bedrockでは anthropic.claude-opus-5-5、Google Cloud・Microsoft Foundryでは claude-opus-5-5 を指定します。

移行前に洗い出す4つの破壊的変更

この4点は本番切り替え前に検索で確認します。 該当がなければ、モデルIDの差し替えだけで移行できます。

① thinkingが無効化できない

検索するもの：thinking: を含む箇所

thinking: { type: "disabled" } と thinking: { type: "enabled", budget_tokens: N } は、どちらも400エラーになります。Opus 5では high 以下のeffortに限って無効化できましたが、Opus 5.5では選択肢そのものがなくなりました。

トークン削減のためにthinkingを切っていた実装は、thinking フィールドを削除して output_config.effort を下げる形に置き換えます。

// NG：Opus 5.5では400エラー
await client.messages.create({
  model: "claude-opus-5-5",
  max_tokens: 16000,
  thinking: { type: "disabled" }, // "thinking.type.disabled" is not supported
  messages: [{ role: "user", content: prompt }],
});

// OK：thinkingは常時ON。effortで推論量を制御する
await client.messages.create({
  model: "claude-opus-5-5",
  max_tokens: 16000,
  output_config: { effort: "low" },
  messages: [{ role: "user", content: prompt }],
});

あわせて、レスポンスが必ず thinking ブロックから始まる点にも注意が必要です。検索するもの：content[0] のように先頭ブロックを決め打ちで読んでいるコードは、type で絞り込む形に直します。

const text = message.content
  .filter((b): b is Anthropic.TextBlock => b.type === "text")
  .map((b) => b.text)
  .join("");

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

検索するもの：tool_choice

tool_choice: { type: "tool", name: "..." } と { type: "any" } がサポート外になりました。トークンカウントAPIでも同じチェックが入ります。

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

// OK：auto + 指示文 + strict: true
await client.messages.create({
  model: "claude-opus-5-5",
  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ブロックがモデルと会話に紐づく

検索するもの：フォールバック・リトライでモデルを切り替えている箇所

Opus 5.5が生成したthinkingブロックを読めるのは、Claude API上ではFable 5.1とMythos 5.1だけです。逆方向、つまりOpus 5以前のOpus・Sonnet・Haikuの会話をOpus 5.5へ引き継ぐことはできます（Fable・Mythos系からは引き継げません）。

実害が出るのは、リトライやフォールバックで会話が別モデルに切り替わるケースです。そのターンは推論の文脈を失って再計画が走るため、コストとレイテンシが一時的に増えます。

あわせて、会話履歴を途中で編集すると、以降のthinkingブロックが無効になります。2026年8月31日00:00 UTC以降に作成されたアカウントでは、編集後にthinkingブロックを送り返すと既定で400エラーになります。 根本対応は、会話履歴を追記専用（append-only）に保つことです。指示やツールを変えたい場合は、過去ターンを書き換えるのではなくメッセージの追加で行います。これはプロンプトキャッシュのヒット率を保つ実装とも一致します。

④ computer_20251124 が使えない

検索するもの：computer_20251124

Computer useを使っている場合、tools に computer_20251124 を入れると400エラーになります。新しいツールセットを宣言する形に変わりました。

// OK：ベータヘッダ不要、name や画面サイズの指定も不要
await client.messages.create({
  model: "claude-opus-5-5",
  max_tokens: 4096,
  tools: [{ type: "computer_toolset_20260801" }],
  messages: [{ role: "user", content: "..." }],
});

エージェントループ側も変更が必要です。操作の種類は input.action ではなく tool_use ブロックの name に入り、1ターンに複数個返ることがあります。結果を返すときは toolset_name を毎回添えます。なおAmazon Bedrockでは computer_20251124 が引き続き動くため、提供先によって対応が分かれます。

エラーにならないまま品質が変わる：effort既定値の変更

破壊的変更ではないぶん、これがいちばん気づきにくい変更です。

effort を明示していないリクエストは、Opus 5では high 相当だったものが、Opus 5.5では medium で動きます。モデル名を差し替えただけで「速くなったが品質が落ちた」と見える場合、多くはこの既定値の差です。エラーは出ないため、計測していなければ気づけません。

low / medium / high / xhigh / max の5段階があり、output_config.effort で指定します。

const stream = client.messages.stream({
  model: MODEL,
  max_tokens: 64000,
  output_config: { effort: "medium" }, // 既定値でも明示しておく
  system: [
    {
      type: "text",
      text: SYSTEM_PROMPT, // 固定文言はキャッシュ対象に（読み取り$0.20）
      cache_control: { type: "ephemeral" },
    },
  ],
  messages: [{ role: "user", content: prompt }],
});

既定値であっても明示的に書いておくのが、運用上のポイントです。次のモデルで既定値がまた変わったときに、コードを見れば意図が分かる状態になります。

単価が下がっても、effortを上げれば出力トークンが増えて総額は戻ります。請求額は移行後に必ず再計測してください。

また、thinkingが常時ONで単一リクエストが長くなるため、ストリーミングを標準にすることも実務上は必須です（Vercelのタイムアウト対策としても効きます）。

移行後に気づきやすい2つの挙動変化

ツールコール間の進捗表示が消える

Opus 5ではツールコールの合間のテキストが text ブロックで返っていましたが、Opus 5.5ではFable 5.1と同じく thinkingブロック側（progress update）に移りました。 既定の thinking.display は "omitted" で、この場合 thinking フィールドは空文字列になります。進捗をUIに流している実装は、切り替えた瞬間に無言になります。

復旧するには display を設定し、thinkingブロックから読みます。"updates"（ベータヘッダ thinking-display-updates-2026-08-18）は進捗更新のみ、"summarized" は推論の要約も含めて返します。

拒否レスポンスの種類が増えた

Opus 5.5は stop_reason: "refusal" を返すことがあり、stop_details.category はOpus 5より広く、"cyber" に加えて "bio" や "reasoning_extraction" が返ります。サイバーセキュリティ関連のタスクは安全策としてOpus 4.8へルーティングされる仕様もあるため、該当領域を扱う場合は挙動を検証環境で確認してください。サーバー側フォールバックを設定できますが、"reasoning_extraction" による拒否は再試行されず、そのまま返ります。

Opus 5.5とFable 5.1、どちらを使うか

公式ドキュメントは、まずOpus 5.5から検証することを案内しています。 多くのワークロードではOpus 5.5を使い、要求の厳しい推論や長時間のエージェント処理、あるいはOpus 5.5を高いeffortで評価しても品質が足りない場合にFable 5.1を検討する、という順番です。

単価もOpus 5.5が入力4ドル／出力20ドル、Fable 5.1が入力10ドル／出力50ドルと差があります。Fable 5.1側の移行時の注意点はClaude Fable 5.1移行｜tool_choice廃止など3つの注意点とNext.js実装に整理しています。

まとめ

• モデル更新はNext.jsの保守運用の一部。モデルIDの環境変数化・検証環境での事前確認・切り替え後の計測という3点を用意しておくと、次のモデルでも同じ手順で回せる
• Opus 5.5の破壊的変更は4つ。thinking: / tool_choice / モデル切り替え箇所 / computer_20251124 を検索すれば、該当の有無を事前に判定できる
• エラーにならない変更（effort既定値 high→medium）が実害としては大きい。 切り替え後に品質と請求額を再計測する
• 会話履歴を追記専用に保つ設計は、400エラー回避とプロンプトキャッシュのヒット率の両方に効く

Next.jsのバージョン追従と同じく、AIモデルの更新も「いつ来るか分からないが必ず来る」保守項目です。追従の体制をどう作るかという観点は、Next.jsのCVE対応は誰がやるのかやNext.js保守運用の費用と契約もあわせてご覧ください。

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

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