モデル世代をまたぐ移行 — 結局どうすればいいか
12本を統合する。移行の失敗は「足りない」ではなく「余計なものが残っている」で起きる、というのが横断して見えた最大の発見。
1. 基本方針: 足すより剥がす
4つのモデル別ガイドが独立に同じことを言っている。
最新モデルでは「足す prompting」より 旧世代向けに書いた過剰な指示を剥がす prompting のほうが重要 —
claude-prompting-best-practices
If your prompt contains explicit verification instructions, remove them: instructions like these cause over-verification on Claude Opus 5, and removing them reduces wasted tokens with no loss in quality. —
prompting-claude-opus-5プロンプトに明示的な検証指示が含まれているなら、それを削れ。この種の指示は Claude Opus 5 で過剰な検証を引き起こし、削除すると品質を落とさずに無駄なトークンを減らせる。
Skills developed for prior models are often too prescriptive for Claude Fable 5 and can degrade output quality. —
prompting-claude-fable-5以前のモデル向けに作った skill は、Claude Fable 5 には指示が細かすぎることが多く、出力品質を下げうる。
If you’ve added scaffolding to force interim status messages, try removing it. —
prompting-claude-sonnet-5途中経過のメッセージを強制するために scaffolding を足しているなら、外してみよ。
共通する構造: 旧モデルの限界を回避するために書いた補助輪が、新モデルではそのままコストと害になる。
2. 剥がすべきものの一覧
| 旧世代で書いていたもの | 最新モデルでの害 | 出所 |
|---|---|---|
CRITICAL: You MUST use this tool when... | 過剰発火。Use this tool when... に戻す | claude-prompting-best-practices |
If in doubt, use [tool] | 過剰発火 | 同上 |
Default to using [tool] | 包括的すぎる。「理解が深まるときに使え」に絞る | 同上 |
| 「最後に検証ステップを入れよ」 | Opus 5 は指示なしで自己検証する。書き換えではなく削除 | prompting-claude-opus-5 |
| 「ダブルチェックせよ」「返答前に再検証せよ」 | 同上。コストだけ増えて結果は良くならない | 同上 |
| 「3ツール呼び出しごとに進捗を要約せよ」 | 自分で質の高い更新を出すので不要 | prompting-claude-sonnet-5 / -opus-4-8 |
| 「もっと徹底的に」（anti-laziness） | 過剰発火 | claude-prompting-best-practices |
| 「思考を見せろ」「推論を説明しろ」 | Fable 5 で reasoning_extraction 拒否を誘発し、フォールバックが増える | prompting-claude-fable-5 |
| 「重大な問題だけ報告せよ」（コードレビュー） | 忠実に守るので recall が落ちて見える | -sonnet-5 / -opus-4-8 |
| 単一ファイルのリファクタに限定するルール | 限界が消えたので不要 | large-codebases |
3. 向きが反転するもの（最も危険）
同じ指示が逆効果になる。 これは1つの文書を読んでいては絶対に見えない。
| subagent の傾向 | 必要な prompt | |
|---|---|---|
| Opus 4.8 | 少なく起こす（推論をツール呼び出しより好む） | 「こういう場面では委譲せよ」と促す |
| Opus 5 / Fable 5 | 多く起こす | 「小さい仕事は自分でやれ」と抑える |
Opus 4.8 で必要だったプロンプト:
Do not spawn a subagent for work you can complete directly in a single response.
Spawn multiple subagents in the same turn when fanning out across items or reading multiple files.Opus 5 で必要なプロンプト（逆向き）:
Delegate to a subagent only for large tasks that are genuinely independent and parallelizable.
Do not delegate work you can finish yourself in a handful of tool calls, and do not use subagents
to verify or double-check your own work. If one subagent can complete the task, use one rather
than several, and keep spawn counts low.→ 移行時に prompt の向きを反転させる必要がある。そのまま持ち越すと悪化する。
4. API パラメータの破壊的変更
プロンプトより先に、これで落ちる。
| 世代 | 変更 |
|---|---|
| Claude 4.6 以降 | prefill が 400 エラー（最後の assistant ターンへの prefill） |
| Claude 4.7 以降 | budget_tokens が 400 エラー |
| Sonnet 5 | adaptive thinking が既定オン / temperature top_p top_k が 400 / manual extended thinking 削除 / 新トークナイザ |
| Opus 5 | thinking 既定オン。xhigh / max では thinking を切れない（400） |
| Fable 5 / Mythos 5 | thinking 常時オン。要約のみ。refusal stop reason |
prefill の移行先
| 旧用途 | 移行先 |
|---|---|
| 出力形式の強制（JSON/YAML、分類） | Structured Outputs、または enum を持つ tool |
| 前置きの除去 | system prompt で直接指示。漏れたら後処理 |
| 不当な拒否の回避 | 不要。user メッセージ内の明確な prompting で足りる |
| 継続 | user メッセージに移し、中断した末尾テキストを含める |
| context の再注入 | user ターンに入れる、または tool / compaction 時に |
トークナイザの変更（見落とされやすい）
Because Claude Sonnet 5 uses a new tokenizer that produces approximately 30% more tokens for the same text,
max_tokenslimits tuned for Claude Sonnet 4.6 may truncate equivalent output. Claude Sonnet 5 は同じテキストに対しておよそ30%多いトークンを生成する新しい tokenizer を使うため、Claude Sonnet 4.6 向けに調整したmax_tokensでは同等の出力が途中で切られる可能性がある。
→ Sonnet 4.6 から移行するなら max_tokens を見直す。
5. effort と thinking の整理
混同が最も多い2つ。別の軸である。
| 何を制御するか | |
|---|---|
thinking | thinking ブロックで考えるかどうか |
effort | 応答全体（テキスト + ツール呼び出し + thinking）にどれだけ労力を割くか |
adaptive を effort の値として渡してはいけない（thinking のモードであって effort のレベルではない）。
費用を縛るもの
You don’t set a thinking token budget. Two controls bound cost: **thinking のトークン予算を自分で設定するのではない。**コストを縛るのは次の2つの制御である。
| 制御 | 性質 |
|---|---|
max_tokens | 厳密な上限。thinking + 応答テキストの合計。Claude はこれを超えない |
effort | ソフトな指針。トークン数を保証しない |
stop_reason: "max_tokens" が出たときの分岐:
その推論が必要だった → max_tokens を上げる
考えすぎだった → effort を下げるeffort レベルの意味
| effort | thinking の振る舞い |
|---|---|
max | 常に思考。深さに制約なし |
xhigh | 常に深く思考、探索を拡張 |
high（既定） | ほぼ常に思考 |
medium | 適度。単純なクエリでは飛ばすことがある |
low | 最小化。速度が最重要な単純タスクでは飛ばす |
モデル別の出発点
| モデル | 出発点 |
|---|---|
| Opus 5 | high（既定）から。 要求の厳しいコーディング / agentic で xhigh。品質が保てるなら low / medium を積極的に |
| Opus 4.8 / 4.7 | xhigh から（コーディング / agentic）。他は high を最低線に |
| Sonnet 5 | high（既定）。最難のタスクで xhigh |
| Sonnet 4.6 | medium を推奨既定に。 既定は high なので明示的に設定する（予期しないレイテンシを避ける） |
| Fable 5 | high（既定）。低い設定でも旧モデルの xhigh を上回ることが多い |
移行時の対応関係（Sonnet の例）:
Sonnet 5 の medium ≒ Sonnet 4.6 の high
Sonnet 5 の high ≒ Sonnet 4.6 の maxWhen benchmarking, match by observed thinking length rather than effort name. ベンチマークを取るときは、effort の名前ではなく、実測した thinking の長さで揃えよ。
そして最も重要な指示:
If you carried effort settings over from an earlier model, run a fresh effort sweep on your evals rather than reusing them. 以前のモデルから effort 設定を引き継いだ場合は、そのまま使い回さず、自分の eval で effort を振り直して測れ。
effort を厳密に守るようになった
Opus 4.7 以降の性質。
Claude Opus 4.7 also respects effort levels more strictly than Claude Opus 4.6. At lower effort levels, the model scopes its work to what was asked rather than doing more than requested. Claude Opus 4.7 は Claude Opus 4.6 より effort レベルを厳密に尊重する。低い effort では、モデルは求められた以上のことをせず、依頼された範囲に作業を限定する。
If you observe shallow reasoning on complex problems, raise effort rather than prompting around it. 複雑な問題で推論が浅いと感じたら、プロンプトで回避しようとせず、effort を上げよ。
プロンプトで回避しない。 どうしても低く保つなら:
This task involves multistep reasoning. Think carefully before responding.キャッシュとの相互作用
effort と thinking の設定はプロンプトにレンダリングされる。
Changing any of them starts a new cache prefix. いずれかを変更すると、新しい cache prefix が始まる（＝それ以降のキャッシュが効かなくなる）。
運用ルール:
- 会話ごとに
thinking設定とeffortを固定する - ターン単位の調整は per-message prompting で（最新の user メッセージへの追記は前方の breakpoint を壊さない）
- 既定値を明示的に設定するのは省略と等価（キャッシュを壊さない）
6. 世代共通で残る調整点
モデルが変わっても、次の3つは毎回チューニングが要る。
① 応答の長さ
タスクの複雑さに応じて長さを較正するようになったので、固定の冗長さを期待していた製品はずれる。
Opus 5 は特殊:
The effort parameter controls how much the model thinks rather than how much it says: lowering effort can reduce thinking volume without reliably shortening the visible response. effort パラメータが制御するのは、モデルがどれだけ話すかではなくどれだけ考えるかである。effort を下げれば thinking の量は減りうるが、目に見える応答が確実に短くなるわけではない。
→ 応答長は prompt で明示的に指定するしかない。
効く書き方:
Positive examples showing how Claude can communicate with the appropriate level of concision tend to be more effective than negative examples. 適切な簡潔さで伝える方法を示す肯定的な例のほうが、否定的な例より効果的な傾向がある。
② より字義通りの指示追従
It does not silently generalize an instruction from one item to another, and it does not infer requests you didn’t make. モデルはある項目への指示を、黙って別の項目へ一般化することはないし、していない依頼を推測することもない。
利点は精度（構造化抽出、予測可能なパイプライン）。対処は「スコープを明示する」:
Apply this formatting to every section, not just the first one.この性質が生む最大の落とし穴がコードレビュー harness:
When a review prompt says “only report high-severity issues,” “be conservative,” or “don’t nitpick,” the model may follow that instruction more faithfully than earlier models did: it may investigate the code just as thoroughly, identify the bugs, and then not report findings it judges to be below your stated bar. レビュー用のプロンプトに「重大な問題だけ報告せよ」「保守的に」「細かい指摘はするな」と書くと、モデルは以前のモデルより忠実にその指示に従う可能性がある。コードは同じだけ丹念に調べ、バグも特定したうえで、指定した基準に達しないと判断した指摘を報告しないことがある。
→ precision は上がるが recall が落ちて見える。能力の後退ではない。
直し方は「発見段階の目的はカバレッジ」と明示し、フィルタを別段階に移す:
Report every issue you find, including ones you are uncertain about or consider low-severity.
Do not filter for importance or confidence at this stage - a separate verification step will do that.
Your goal here is coverage. For each finding, include your confidence level and an estimated severity.③ デザインの既定
開放的なブリーフで一貫した既定スタイルに落ち着く。 Opus 4.8 は具体的に記述されている（クリーム色の背景 ~#F4F1EA、セリフ体、テラコッタのアクセント）。
Generic instructions (“don’t use cream,” “make it clean and minimal”) tend to shift the model to a different fixed palette rather than producing variety. 漠然とした指示（「クリーム色は使うな」「清潔でミニマルに」）は、多様性を生むのではなく、モデルを別の固定パレットへ移すだけになりがちである。
効くのは2つだけ:
- 具体的な代替を指定する（色コード、書体、角丸の px まで）
- 作る前に選択肢を提案させる —
temperatureが使えない Sonnet 5 ではこれが推奨手段
Before building, propose 4 distinct visual directions tailored to this brief
(each as: bg hex / accent hex / typeface, plus a one-line rationale).
Ask the user to pick one, then implement only that direction.7. Fable 5 世代で新しく必要になったこと
「1リクエストが数分〜数時間走る」が最大の実務的インパクト。
Adjust client timeouts, streaming, and user-facing progress indicators before migrating, and consider restructuring harnesses to check on runs asynchronously rather than blocking. 移行の前に、クライアントのタイムアウト・ストリーミング・ユーザー向けの進捗表示を調整せよ。さらに、ブロッキングせずに非同期で実行状況を確認するよう harness を組み替えることも検討せよ。
プロンプト側で新しく要るもの:
| 課題 | 対処 |
|---|---|
| 進捗の捏造 | ツール結果に照らして各主張を監査させる。「テストが落ちたならその出力とともにそう言え」（実測でほぼ消えた） |
| 稀な早期停止 | 自律パイプラインには system reminder。「最後の段落が計画・質問・約束なら、その作業を今やれ」 |
| context 予算の懸念 | harness が残トークンのカウントダウンを見せると誘発される。見せないのが最善 |
| verbatim で届けたい内容 | send_to_user ツールを作る。ツール入力は要約されないので内容がそのまま届く |
そして scaffolding 側:
Start at the top of your difficulty range. Pick a task harder than what you’d assign to prior models. **自分が扱う難易度の上限から始めよ。**以前のモデルに割り当てていたものより難しいタスクを選ぶ。
Separate, fresh-context verifier subagents tend to outperform self-critique. まっさらな context を持つ検証用 subagent は、自己批判より良い結果を出す傾向がある。
8. 移行の手順
1. API パラメータの互換性を確認する（プロンプトより先に落ちる）
□ prefill を使っていないか（4.6+ で 400）
□ budget_tokens を使っていないか（4.7+ で 400）
□ temperature / top_p / top_k を送っていないか（Sonnet 5 で 400）
□ トークナイザ変更で max_tokens が足りるか（Sonnet 5 で約30%増）
□ thinking の既定が変わっていないか
2. 剥がす（§2 の一覧を上から確認）
□ 検証指示、再確認指示
□ 進捗要約の scaffolding
□ 過剰な発火促進（CRITICAL / MUST / If in doubt）
□ 「思考を見せろ」系（Fable 5 で拒否を誘発）
□ コードレビューの「重大なものだけ」
3. 向きが反転しているものを直す
□ subagent の promptを、抑制 ⇄ 促進 のどちらが要るか確認
4. effort を測り直す
□ 旧モデルの設定を流用しない。eval で sweep をやり直す
□ 会話内では固定する（キャッシュのため）
□ xhigh / max なら max_tokens を 64k から
5. 世代共通の3点を再調整する
□ 応答の長さ（Opus 5 は effort では変わらない）
□ スコープの明示（字義通りに読むので）
□ デザインの既定（具体指定 or 選択肢提案）
6. eval で確認する
□ recall が落ちて見えるのは harness 効果かもしれない
□ 「観測される thinking の長さ」で揃えて比較する9. この文書自体の鮮度
§2〜§7 は陳腐化が最も速い部分。 モデルがもう1世代進んだら真っ先に見直す。
鮮度の起点: whats-new のモデルの既定の推移。
W16 Opus 4.7 → W22 Opus 4.8 → W27 Sonnet 5 → W30 Opus 5約2ヶ月に1度、既定モデルが変わっている。 つまりこの文書は2ヶ月ごとに点検する必要がある。
2026-08-12 に該当ページを再取得済み。 ただし digest が言う「Opus 5 が Claude Code の既定 Opus に」は choosing-a-model に書かれていなかった。原典が述べているのはeffort の既定が high（Claude Code と Messages API の両方で）であり、既定モデルの話ではない（DECISIONS.md #3）。