Claude 4.6でprefillが廃止された理由と5つの移行先
Claude 4.6以降とClaude Mythos Previewは最後のassistantターンへのprefillを400エラーで拒否する。5つの用途別に公式が示す移行先を整理する。
Claude 4.6以降でprefillが使えなくなるとはどういうことか
prefill(アシスタント事前入力)とは、最後のassistantターンに部分的な応答をあらかじめ渡し、Claudeにその続きを書かせる手法です。Claude 4.6系のモデルとClaude Mythos Previewでは、この使い方が丸ごと拒否されるようになりました。
最後のassistantターンにprefillを含むリクエストを送ると、400エラーが返ります。エラーになるのは「会話の最後のassistantターンにprefillを置く」パターンだけです。会話の途中にassistant発言を挿入する使い方(few-shot例の構築など)には影響しません。旧世代モデル(Claude 4.5以前)は引き続きprefillを受け付けます。
Anthropicの説明は明快です。モデルの指示追従力が上がり、prefillで無理やり型にはめる必要がなくなったというものです。実際、公式ドキュメントはprefillの主な使いみちを5つに分類し、それぞれに代替手段を用意しています。
なぜAnthropicはprefillを切り捨てたのか
prefillは元々、Claudeの出力を強制的に狙った形へ寄せるための力技でした。JSON形式で答えさせたい、前置きの雑談を省かせたい、といった要求に対して「途中まで自分で書いてしまい、続きをClaudeに書かせる」という運用でこれを実現していたわけです。
Claude 4.6以降は、モデル単体の指示追従力が上がった前提に立っています。「JSONで答えて」と頼めば素直にJSONで返す。前置きを禁止すれば前置きを書かない。この前提が成立するなら、prefillという迂回策を残す理由は薄くなります。むしろprefillはアシスタント側の発話を事後から書き換える構造上、ツール呼び出しやthinkingブロックとの相性が悪く、エージェント的なワークフローが複雑化するほど扱いにくくなっていました。
thinkingを使う会話では、直前のassistantターンに含まれるthinkingブロックを受け取った通りに送り返す必要があります。ここへ手作業のprefillを差し込むと、APIが検証する「最新のassistantメッセージは改変されていない」という前提を壊しかねません。prefillという仕組み自体が、thinking対応モデルの会話フローと構造的に噛み合いにくくなっていた面があります。
5つの移行パターンをどう置き換えるか
公式ドキュメントは、prefillの典型的な用途を5つに分けて移行先を示しています。
パターン1: JSON/YAML形式を強制していた場合
出力フォーマットをprefillで固定していたケースは、Structured Outputsへの置き換えが第一候補です。JSON Schemaを渡してClaudeの応答をそのスキーマに拘束する機能で、prefillより堅牢に構造を強制できます。分類タスクであれば、enumフィールドを持つツール定義かstructured outputsのどちらかを使うのが公式の推奨です。スキーマが複雑になりがちな場合は、SDKがJSON Schemaをどう自動変換するかも合わせて確認すると制限を避けやすくなります。
まずは素直に「このスキーマに従って」と指示するだけで足りるケースが増えています。新しいモデルはリトライを組み合わせれば複雑なスキーマにも安定して従うため、prefillに頼らず指示ベースで試す価値があります。
これまでのprefillでは、リクエストの最後に{"role": "assistant", "content": "{"のような部分JSONを積んで応答を強制していました。Structured Outputsではこの行を削り、代わりにリクエストへoutput_config.format(JSON Schema)を渡す形に変えます。
curl https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "claude-sonnet-5",
"max_tokens": 1024,
"messages": [
{"role": "user", "content": "この製品レビューを分類してください"}
],
"output_config": {
"format": {
"type": "json_schema",
"schema": {"type": "object", "properties": {"label": {"type": "string"}}}
}
}
}'messages配列の末尾がassistantロールで終わっていない点が、prefill運用との構造上の違いです。
パターン2: 前置き(preamble)を排除したかった場合
「Here is the requested summary:」のような前置きをスキップさせるためのprefillは、system prompt側の明示指示に移行します。「前置きなしで直接答えてください。『こちらが〜』『〜に基づいて』のようなフレーズで始めないでください」と明記する方法です。
XMLタグの中に出力させる、structured outputsを使う、ツール呼び出しの形で結果を受け取る、といった代替も有効です。まれに前置きが残る場合は、後処理で取り除く運用でカバーできます。
system prompt側の指示は次のような形になります。
curl https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "claude-sonnet-5",
"max_tokens": 1024,
"system": "前置きなしで直接答えてください。「こちらが〜」「〜に基づいて」のようなフレーズで始めないでください。",
"messages": [
{"role": "user", "content": "この記事を要約してください"}
]
}'assistantロールのメッセージを一切含まない点が、prefillベースの実装との最大の違いです。既存コードでprefillを外すだけでは前置きが復活するため、system側への指示追加は省略できません。
パターン3: 不要な拒否(refusal)を回避したかった場合
意図しない拒否を避けるためのprefillは、公式が最も明確に「不要になった」と述べているパターンです。Claudeの拒否判断そのものが以前より適切になったため、userメッセージ側の指示を明確にするだけでprefillなしでも十分だとしています。
パターン4: 中断した応答の続き(continuation)を書かせていた場合
途中で切れた生成の続きをprefillで再開させていた運用は、続きの依頼をuserメッセージに移す形へ変更します。「直前の応答は[前回の応答]で中断されました。続きを書いてください」という形で、中断箇所のテキストをuserメッセージに含めて渡す方法です。
エラーハンドリングの一環で、UX上のペナルティが無いのであれば、prefillで繋ぐより素直にリクエストをリトライする方が簡潔になるケースもあります。
パターン5: 文脈を定期的に再注入(context hydration)していた場合
長い会話でコンテキストが薄れないよう、定期的にprefillで文脈を再注入していた運用は、その内容をuserターンに移します。より複雑なエージェント的システムの一部であれば、ツール経由で文脈を補給する(ターン数などのヒューリスティックに応じてツールの利用を促す)方法や、context compactionのタイミングで文脈を再構成する方法が代替になります。ツール経由で構造化データを渡す実装は、Agent SDKの構造化出力入門が参考になります。
5パターンをどう選び分けるか
| 元のprefill用途 | 移行先 | 効くケース |
|---|---|---|
| JSON/YAML強制・分類 | 移行先Structured Outputs / enumツール | 効くケース出力形式が固定のAPI連携 |
| preamble排除 | 移行先system promptの明示指示 | 効くケースチャットUIの応答冒頭を制御したい場合 |
| refusal回避 | 移行先userメッセージの明確化 | 効くケース境界線上のリクエストを扱う場合 |
| continuation | 移行先userメッセージでの再依頼 | 効くケースストリーミング中断からの復帰 |
| context hydration | 移行先ツール経由の文脈補給 / compaction | 効くケース長時間稼働するエージェント |
いずれのパターンにも共通するのは、Claudeの発話そのものを書き換えるのではなく、userターン側の指示を厚くするという方向性です。prefillが担っていた「型にはめる」役割を、モデルの指示追従力とstructured outputsに委ねる設計へ移すことになります。
Claude 4.5以前を使い続ける場合はどうなるか
Claude 4.5以前のモデルは今回の変更の対象外で、これまで通りprefillを送信できます。ただし複数モデルを併用するシステムでは、モデルによってprefillの可否が分かれる状態になるため、モデルIDで分岐する実装が必要になります。将来的にモデルを4.6系以降へ切り替える計画があるなら、この記事の5パターンに沿ってprefillに依存しない実装へ先に寄せておくと、移行時の手戻りを減らせます。
まとめ
Claude 4.6以降とClaude Mythos Previewは、最後のassistantターンへのprefillを400エラーで拒否します。会話途中へのassistant発言挿入は引き続き有効で、影響を受けるのは「続きを書かせる」用途だけです。移行先はStructured Outputs・system prompt指示・userメッセージへの依頼変更の3系統に集約されます。Claude 4.6系以降への移行を予定している開発者は、まず自分のprefill利用がどのパターンに当てはまるかを棚卸しし、該当する移行先へ順に置き換えるのが最短ルートです。
よくある質問
prefillを使っていないコードでも影響はあるか
会話履歴の途中にassistantメッセージを挿入するfew-shotプロンプティングは対象外です。影響が出るのは、リクエストの最後がassistantロールで終わる場合に限られます。
エラーは400以外で返ることもあるか
公式ドキュメントに記載されているのは400エラーのみです。ステータスコードで判定できるため、複数モデルを扱う実装ではモデルIDでの事前分岐に加えて、400エラーのハンドリングも保険として用意しておくと安全です。
JSON/YAML以外の構造化(自由記述の要約など)にもStructured Outputsは使えるか
使えます。スキーマは配列やネストしたオブジェクトも定義できるため、単純な分類・抽出に限らず、レポート生成のような自由度の高い出力にもフィールド単位で型を固定できます。ただし出力全体を1つの自然文にしたい場合は、prefillの代わりにsystem prompt側の指示だけで足りることが多く、無理にStructured Outputsへ寄せる必要はありません。