Claude Fable 5.1の余計な修正とテスト追加を抑える指示文

Fable 5.1が頼んでいない修正とテストを足す場面

機能追加を頼んだのに、差分に近くの関数の整理や、頼んでいない挙動の拡張が混ざっている。テストも1本で足りるところに、確認用のファイルが何本も残っている。Claude Fable 5.1でこの手の差分が出るときは、公式のガイドが対処を用意しています。

Prompting Claude Fable 5.1の該当節は、Fable 5.1が「頼まれたことは届けるが、ときにそれ以上をやる」と説明しています。具体的には、近くのコードを直す、タスクが触れていない挙動を広げる、変更に見合う数を超えてテストファイルをコミットする、の3つです。

同じ節は、明示的に「やらないこと」を書くと反応がよいとも書いています。その指示文は、次の節で文ごとに読めます。

公式が示す抑制指示文を文ごとに読む

ガイドが示す指示文は、システムプロンプトに足す英語の一段落です。この指示で、頼まれていない追加とコミットされるテストコードが大きく減り、タスクの成功率には測定できる差が出なかったと書かれています。全文は次のとおりです。

If, while working or testing, you find a pre-existing bug, a performance concern, or behavior the task doesn't mention, don't fix, optimize or extend it in this change unless the requested behavior cannot work without it; report it as a follow-up in your summary. Where the task is ambiguous, implement the reading its wording and the surrounding code most directly support, state that assumption in your summary, and don't build for the other readings as well. Verify your work however you like; scratch scripts and quick checks need not be kept. Commit tests only where the task asks for them or this repository already keeps tests for this kind of change, sized like the neighboring test files — roughly one focused test per stated behavior — and don't turn scratch checks into additional permanent test files. This is about extras only: implement every behavior the task asks for, completely.

一文ずつ役割が違います。

1文目には例外があります。要求された挙動がそのバグを直さないと動かないなら、直してかまいません。例外の条件を自分で書き換えるときは「動かないなら」という必要性の基準を残すのが要点です。「関連するなら」と緩めると、周辺修正を許す穴になります。

既存バグは直させず、follow-upとして報告させる

実装中に既存のバグを見つけたとき、直すか黙るかの二択だと、差分が膨らむか、発見が失われるかのどちらかになります。1文目はもう1つの出口を作っています。要約にfollow-upとして書かせる、という扱いです。

読む側の手間も変わります。レビュアーは「頼んだ変更」だけを差分で読み、別件は別のチケットや別のコミットで判断できます。見つかったバグ自体は報告に残るので、頼んでいない修正を避けても情報は落ちません。

要約の形をそろえたいなら、報告の欄を指示で固定する方法があります。例えば次のような形にします。これは公式の指示文に足した例示で、公式が示す文面ではありません。

作業の要約には次の見出しを必ず付けてください。
- 実施した変更: 依頼された挙動の実装内容
- 採用した解釈: 仕様が曖昧だった点と、選んだ読み
- follow-up: 作業中に見つけた既存バグ・性能の懸念・仕様に無い挙動(修正はしていない)

follow-upの欄が空なら「何も見つからなかった」という報告になるので、空欄そのものが情報になります。

曖昧な仕様は、選んだ読みを書かせて1つだけ実装させる

2文目は、曖昧なタスクで複数の読みに備えて両方を作ってしまう挙動を止めます。「文面と周辺コードが最も直接支える読みを実装し、その前提を要約に書く。ほかの読みのためには作らない」という指示です。

たとえば「エラー時はリトライするようにして」という依頼で、回数も間隔も書かれていないとします。両対応を避けるなら、リポジトリに既にあるリトライ処理の流儀に合わせた1通りだけを実装し、「回数は3回、間隔は既存の fetchWithRetry に合わせた」と要約に書かせます。違っていたら、読み直しの依頼は前提の1行を直すだけで済みます。

質問で止めるか、仮定を置いて進めるかも、ここで決まります。公式のガイドは別の節で、routineな判断は自分で下し、実質的に違う仕事になる読みが複数あるときだけ確認するよう、モデルに求める指示文も示しています。その節の指示文は、確認の頻度を下げる方向に効く点に注意が必要です。曖昧な依頼に質問を返してほしい運用では、そちらを入れる前に自分のタスクで挙動を確かめてください。

テストは頼まれたときと、リポジトリに慣行があるときだけ

3〜4文目は、検証とコミットするテストを分けています。検証の方法は自由で、確認用のスクリプトも走らせてよいが、それを残さない。恒久的なテストを足すのは、次のどちらかのときに限ります。

• タスクがテストを求めている
• そのリポジトリが、この種の変更にテストを付ける慣行を既に持っている

足すときの量も指定されています。隣のテストファイルと同じ大きさで、書かれた挙動1つにつき焦点の絞られたテストを大まかに1本です。テストを書かせる手順そのものはClaude Codeで単体テストを書かせる手順にまとめてあります。そちらで「どう書かせるか」を決めたうえで、この指示で「どこまで残すか」に枠をはめる組み合わせになります。

Claude Codeで使うならCLAUDE.mdに写す

公式の指示文はAPI利用者向けにシステムプロンプトへ足す形で書かれています。Claude Codeでは、プロジェクトの規約として CLAUDE.md に置く運用が自然です。次のように、公式の趣旨を日本語の規約にします。この日本語は公式の逐語訳ではなく、趣旨に沿った書き換えの例です。

## 変更の範囲
 
- 依頼された挙動だけを実装する。作業中に見つけた既存バグ・性能の懸念・依頼に無い挙動は、
  依頼の挙動が動くために必須でない限り直さず、要約の「follow-up」に書く
- 仕様が曖昧なときは、文面と周辺コードが最も直接支える読みを1つ実装し、
  採用した解釈を要約に書く。他の読みのための実装は足さない
- 確認用のスクリプトは残さない。テストは依頼されたとき、または
  このリポジトリが同種の変更にテストを付けているときだけ、隣のテストと同じ規模で足す
- 上は余計な追加の話であり、依頼された挙動は省略せず最後まで実装する

規約を書いたら、効いているかを差分で確かめます。作業後に次のコマンドで、触れたファイルの一覧と、新規ファイルの有無を見ます。

git status --short
git diff --stat

依頼と無関係なファイルが git diff --stat に出ていれば、指示が効いていないか、1文目の例外に当たる事情があったかのどちらかです。要約のfollow-up欄に理由が書かれているかを見ます。git status --short で ?? が付いた新規ファイルは、確認用スクリプトが残っていないかの目安になります。

小さな修正でファイル全体を書き直すときは、別の1文を足す

「余計な修正」には、修正する中身ではなく書き方が過剰な型もあります。数行の変更のために、テキストファイルをまるごと書き直す動きです。Fable 5.1のガイドは、Fable 5よりこの書き直しを選びやすいと説明しています。できあがるファイルは多くの場合同じですが、ファイルが短い場合や大半が変わる場合を除き、書き直しは出力トークンと時間を余計に使います。

対処は、システムプロンプトか最初のユーザーメッセージの末尾に、次の英語1文を足すことです。小さな変更と中くらいの変更については、Fable 5と同じ挙動に戻ると書かれています。

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の新機能をまとめたページにも、この書き直しは移行時に気づきやすい挙動の1つとして載っています。Fable 5から切り替えて、出力トークンや所要時間が増えたと感じたときの確認先になります。

「結果に影響しないとき」という条件が付いているので、大半を書き換える変更までピンポイント編集に縛る指示ではありません。ここまでの抑制指示文とは縛る対象が違います。

書き直しでも結果のファイルがほぼ同じなら、git diff --stat には現れにくい点に注意が必要です。コストを見るなら、同じ修正を指示ありとなしで走らせて、出力トークン数と所要時間を比べます。Claude Codeで使うなら、CLAUDE.md の「変更の範囲」の箇条書きに、この趣旨を1行足す形が収まりやすいはずです。

高effortで増える整理や抽象化には、別の指示がある

Fable 5.1の前世代にあたるFable 5のガイドにも、似た悩みへの指示文があります。高いeffortで日常的な作業を頼むと、必要以上に文脈を集めたり、頼まれていない整理やリファクタリングをしたりする、というものです。そちらの指示文は、機能追加・リファクタリング・抽象化を依頼の範囲に限り、起こりえない場面のエラー処理や検証を足さず、feature flagや後方互換のための仕掛けも不要なら入れない、という内容です。

使い分けは次のとおりです。

Fable 5.1のガイドは、Fable 5のプロンプトはそのままでも動くと述べています。Fable 5向けの指示文を既に入れているなら、足りないのは「既存バグの扱い」「曖昧さの扱い」「テストの扱い」の3点で、それを足す形で試すのが現実的です。

効果は自分のタスクで測る

数字の読み方にも注意が必要です。ガイドが言う「頼まれていない追加とコミットされるテストコードが大きく減り、成功率は変わらない」は、公式の評価での結果で、手元のタスクで同じになる保証はありません。測り方は単純で、同じタスクを指示ありとなしで数回ずつ走らせ、差分のファイル数とテストファイル数を比べます。

見る点は3つです。

1. 依頼の挙動が欠けていないか。最後の文が効いていれば、省略は増えません
2. follow-upの欄に、実際の既存バグが書かれているか
3. 採用した解釈が、レビューで直せる粒度で書かれているか

もう1つ、low のeffortで検索が減る問題など、effortに絡む別の挙動もあります。範囲を絞る指示とは独立した話なので、切り分けて見てください。その直し方はClaude Fable 5.1のlow effortで検索が減るときの直し方にあります。モデル自体の仕様や単価はClaude Fable 5.1とはでまとめています。

まとめ

頼まれていない修正とテストを抑える鍵は、禁止だけでなく出口を用意することです。既存バグは要約のfollow-upへ、曖昧さは採用した解釈の1行へ、検証用のスクリプトは残さず捨てる。そのうえで、頼まれた挙動は完全に実装させます。この4点が公式の指示文の骨格で、CLAUDE.mdに写すときもこの構造を崩さなければ、レビューの差分は依頼したものだけになります。