Claude Fable 5.1のファイル書き直しを1文の指示で止める方法
Claude Fable 5.1は小さな修正でもテキストファイル全体を書き直しがちです。公式が示す1文の指示の置き場所、効く範囲、出力トークンで効果を測る手順を示します。
誤字1つ直すだけなのにファイル全体が出力される
設定ファイルの1行を直してほしいと頼んだのに、返ってきたのはファイル全文だった。Claude Fable 5.1を使っていて、こう感じる場面があります。
Fable 5.1のプロンプトガイドは、これを既知の挙動として挙げています。Fable 5.1はFable 5より、テキストファイルを部分的に直さず丸ごと書き直しやすい、という内容です。仕上がりのファイルは通常同じになります。違うのはコストで、書き直しは出力トークンと時間を余分に使います。
対処は1文の指示を足すことです。短いファイルや大半が変わる修正でなければ、書き直しを避けて部分編集に寄せられます。
Fable 5.1の価格(USD)
入力
$10 / MTok
基本価格
出力
$50 / MTok
書き直しで増えるのはこちら
出力単価は入力の5倍です。たとえば1万トークンのファイルを毎回書き直させると、それだけで出力料金が0.5ドル(10,000 × $50 ÷ 1,000,000)かかります。修正が数十回続く作業では、無視できない差になります。
足す指示の中身
足す指示は次の2文です。system promptか、最初のユーザーメッセージの末尾に追加します。
The number of tokens used to edit files is best minimized, all else being equal. Therefore, when it will not affect the end result, try to surgically edit a file rather than rewrite the entire thing.日本語に直すと「ファイルの編集に使うトークンは、他が同じなら少ないほうがよい。結果に影響しないなら、ファイル全体を書き直さず外科的に編集すること」という内容です。
効き方には条件があります。この指示を足すと、小さな変更から中程度の変更ではFable 5.1がFable 5と同じ水準に戻ります。つまり狙いは、Fable 5.1で増えた書き直しをFable 5並みに戻すことです。書き直しをゼロにする指示ではありません。
英語のまま入れてよいか
英語の原文をそのまま使えば、プロンプトガイドに載っている表現を流用できます。日本語に直して使うなら、「結果に影響しないなら」という条件と「他が同じなら」という前提を落とさないことが要点です。条件を落とすと、書き直したほうがよい場面でも無理に部分編集へ寄せる指示になります。
どこに置くか
置き場所は2つあります。system promptの末尾か、最初のユーザーメッセージです。Messages APIなら、次のようにsystemへ足せます。
import anthropic
client = anthropic.Anthropic()
EDIT_RULE = (
"The number of tokens used to edit files is best minimized, "
"all else being equal. Therefore, when it will not affect the end "
"result, try to surgically edit a file rather than rewrite the "
"entire thing."
)
response = client.messages.create(
model="claude-fable-5-1",
max_tokens=4096,
system="あなたは設定ファイルの保守担当です。\n\n" + EDIT_RULE,
messages=[{"role": "user", "content": "timeout を 30 から 60 に変えて"}],
)
print(response.usage.output_tokens)モデルIDはclaude-fable-5-1です。ここで押さえたいのは、指示を会話の途中ではなく先頭側に固定する点です。履歴の途中を書き換えるとプロンプトキャッシュが先頭から作り直しになるので、毎ターン変えない文面にするのが向いています。
Claude Codeで使う場合は、system promptへ文を足す--append-system-promptが使えます。違いはappend-system-promptとsystem-promptの違いで整理しています。Claude Codeのファイル編集の仕組みが部分置換を前提にしているかどうかは、プロンプトガイドに記載がありません。書き直しが観測されたときだけ足す、という順序が堅実です。
会話の途中で足したくなったとき
すでに動いている会話で書き直しに気づき、そこから指示を足したいことがあります。このときsystemを書き換えるのは避けます。履歴を後から編集する操作は、キャッシュを作り直すだけでなく、Fable 5.1では別の問題も起こします。
プロンプトガイドによると、2026年8月31日以降に作成されたアカウントでは、thinkingブロックは、それを生成した会話の中でだけ有効です。system prompt、ツール一覧、過去のメッセージのどれかが変わったあとにthinkingブロックを再送すると、400エラーになります。キャッシュを切る編集と、このチェックに引っかかる編集は同じ種類です。ベータ機能のthinking.block_binding.prefix_mismatch_behaviorにdrop_blockを指定すれば、エラーにせず該当ブロックだけが捨てられます。ただし、そもそも履歴を編集しない構成にしておくほうが確実です。
代わりに、mid-conversation system messageで指示を足します。systemやtoolsを書き換えず、履歴の末尾に指示を追加する方式です。既存の履歴はバイト単位で変わらないので、キャッシュもthinkingブロックも保たれます。ターンごとに入れては消すリマインダーは、turn-scoped system messageとして送る形が示されています。
キャッシュを保つ意味は価格にも出ます。Fable 5.1のキャッシュ読み取りは$0.25 / MTokで、基本入力価格($10 / MTok)の0.025倍です。Fable 5の4分の1にあたります。長い会話で同じ先頭部分を何度も読み直すほど、先頭を変えない設計が効きます。一方、キャッシュの書き込み価格(5分は$12.50 / MTok、1時間は$20 / MTok)は変わりません。途中でsystemを書き換えると、この書き込みを先頭からやり直すことになります。
履歴を短くしたいときも、手元で古いターンを要約に置き換えるより、サーバー側のコンパクションやコンテキスト編集に任せるほうが安全です。自分のハーネスがどんな編集をしているか分からないときは、通常のターンを数回分記録し、連続するリクエストが追加したターンの手前までバイト単位で一致しているかを見ます。
運用中の会話に後から足す場合も、指示の文面は上の2文のままで構いません。変わるのは置く場所だけです。
効果は出力トークンで測る
指示を入れたら、効いたかどうかを数字で見ます。見るのは応答のusage.output_tokensです。
効果を測る手順
- 1
同じ修正依頼を固定する
誤字の修正や1行の値の変更など、小さな修正を3〜5件用意します。
- 2
指示なしで実行する
出力トークン数を記録します。全文が返ってくる場合、ファイルの長さに近い値になります。
- 3
指示ありで実行する
同じ依頼を同じ条件で流し、出力トークン数を比べます。
- 4
結果のファイルを確認する
部分編集に寄せた結果、直すべき箇所が漏れていないかをdiffで見ます。
書き直しても最終結果は通常同じです。だから手順4は念のための確認です。トークンが減っても修正が漏れていては意味がないので、差分は必ず見ます。
効かない・避けたほうがよい場面
指示の文面そのものが、適用範囲を限定しています。
- ファイルが短いとき: 書き直しても出力は少なく、部分編集に寄せる利点が小さい
- 大半が変わるとき: 実質的に書き直しなので、部分編集の指示は意味を持たない
- 結果に影響するとき: 指示文の条件にあるとおり、書き直しのほうが仕上がりが良いなら書き直してよい
ファイル全体の構造を組み替える依頼では、この指示を外すか、依頼の側で「全体を書き直して」と明示します。指示がsystem promptに固定されていても、ユーザー側の明示的な依頼のほうが具体的です。
隣の指示と混同しない
Fable 5.1のプロンプトガイドには、似た名前の指示がほかにもあります。
似て見える2つの指示
部分編集を促す指示
ファイルの直し方を扱う。書き直しを避け、出力トークンを減らす。
変更範囲を絞る指示
依頼されていない修正や拡張、余計なテストの追加を避ける。直す量でなく、直す対象の話。
前者は「依頼された箇所を、どれだけ小さな出力で直すか」、後者は「依頼されていない箇所に手を出さないか」です。目的が違うので、両方を入れても矛盾しません。ただし、何が効いたのか分からなくならないよう、1つずつ入れて出力を比べると切り分けられます。
長い成果物をxhighやmaxで作らせたときの下書き問題は別の挙動です。思考の中で書いた内容を出力で再度書く、という二重化が原因で、Fable 5.1のxhigh/maxでmax_tokensに達し出力が切れる問題と対処で扱っています。全般の仕様と価格の変更点はClaude Fable 5.1とはにまとまっています。
まとめ
Fable 5.1は小さな修正でもファイルを丸ごと書き直しやすく、仕上がりは同じでも出力トークンと待ち時間が増えます。この2文をsystem promptの末尾か最初のユーザーメッセージに足すと、小さな変更から中程度の変更でFable 5並みに戻ります。
導入前に、書き直しが実際に起きているかをoutput_tokensで確かめてください。起きていないなら足す必要はありません。起きているなら、指示の有無で同じ修正依頼を比べ、減った分とdiffの漏れの有無をセットで見るのが判断の材料になります。low effortで検索が減る挙動のように、Fable 5.1には別の癖もあります。その対処はFable 5.1のlow effortで検索が減るときの直し方にあります。