Claude Fable 5.1のプロンプトの書き方 — 公式ガイド「Prompting Claude Fable 5.1」の16項目を、CLAUDE.md向けとAPI開発者向けに分けて解説

結論 — 書き直さず、症状から1項目ずつ引く。16項目の全体地図

公式ガイドの前提は明快で、Fable 5向けの既存プロンプトは変更なしでFable 5.1でも十分に機能するとされています。そのうえで「知っておく価値のある挙動の違いがいくつかある」として、観察される症状ごとに対処を並べたのがこのガイドです。

つまり読み方は「全部読んで全部入れる」ではなく、自分の環境で起きている症状の行だけを引くが正解です。16項目を、症状・公式ガイドの項目・誰に関係するかの3列で一覧にしました。

「全員」は、Claude Code・claude.ai・Claude Agent SDKなどAnthropicのハーネスの上で使う人を含みます。置き場所はCLAUDE.md、組織の指示、--append-system-prompt などです。「API」は、自社でメッセージ配列を組み立てるハーネス開発者だけに関係します。

前提 — effortが最初の調整つまみ。highから始めて全レベルを測り直す

ガイドが最初に置いているのがeffort（エフォート）です。Fable 5.1では知性・速度・コストのトレードオフを決める主要な制御がeffortであり、思考のオンオフではありません。公式の手順は「既定の high から始め、low・medium・xhigh・max を自分の評価セットで試す」です。

注意点は、Fable 5で測ったeffortの結果をそのまま持ち込まないこと。effortの名前が同じでも、モデルが違えば思考量は同じではないと公式が明記しています。Fable 5で「mediumで十分」と決めていても、5.1では測り直しが前提です。

Claude Codeでは /effort か起動時の --effort で切り替えます。low〜xhighを対話セッションで選ぶとモデルごとに保存されて次回以降も適用され、max はそのセッション限りです。effortの目盛りはモデルごとに較正されているため、同じ名前でも中身は同じではないとClaude Codeのドキュメントにも明記されています。

# セッション中に切り替える（low / medium / high / xhigh / max）
/effort medium

# 起動時に指定する（このセッションだけ。保存されない）
claude --model fable --effort high

effortに依存する癖が2つあり、ガイドは別項目として扱っています。low では検索・取得ツールを呼ぶ頻度が下がること、xhigh と max では長い成果物を書く前に長く考えることです。どちらもパートAのA-8で扱います。

パートA 利用者向け — CLAUDE.md・組織の指示に足す指示

ここからは、Claude CodeのCLAUDE.md、claude.aiの組織の指示、--append-system-prompt-file などに数行足すだけで効く項目です。公式の指示文は英語で、本記事はその要旨を日本語にしています。英語のまま貼りたい場合は、上の情報源から原文をコピーしてください。

A-1 進捗報告を求める — 長いツール実行で無言に見える

Fable 5.1の既定は、長いツール呼び出しの最中にユーザー向けの文章を書く回数がFable 5より少ないことです。effortが高いほど、ツールの連鎖が長いほど顕著で、数分間黙って見えたり、最終報告が最後の一歩分しか書かれなかったりします。

ガイドの手順は順番が大事です。まず、旧モデル向けに入れた抑制指示を消すこと。以前のモデルは作業中に報告しすぎたため「発見は最終回答までためておく」のような行を入れている場合があり、これが5.1では逆効果です。追記より先に削除します。

それでも足りなければ、いつユーザー向けの文章が欲しいか・各報告に何を含めるかを1行で指示します。ペアプログラミングや、人が途中で見る作業に向く追記です。

着手前に、これから何をするかを1行で伝える。作業中は短い経過報告を挟む。最後に「何を見つけた／何をした／次に何をするか」の要約で締め、最後のメッセージだけ読んだ人にも全体が分かるようにする。

APIで自前の画面を作っている場合は、その前に進捗報告がクライアントに届いているかを確認します。ツール呼び出し間の短いメモは進捗更新用の思考ブロックとして返り、既定の表示設定（omitted）では中身が空です。ベータの表示設定 display を updates か summarized にしないと、そもそもユーザーに届いていない可能性があります。

画面がツール出力を折りたたんで見せない製品なら、そのこともモデルに伝えます。伝えないと、モデルはユーザーに「見せる」ためにコマンドを実行し、実際には誰も見ていない出力を出し続けることがあります。

A-2 文章の密度 — 文が長く、段落が減る

公式は、Fable 5.1の文章は決まり文句や説明のない専門用語が減り、全体として一段良くなったとしています。一方で、場面によってはFable 5より密度が上がり、文が長く、段落の切れ目が減ります。

対処は「気取った文体（mannered prose）」という反パターンを定義して渡すことです。比喩や飾りで直接的な表現を置き換え、書き手を目立たせるための言い回しを指します。ガイドはこの説明文をシステムプロンプトよりユーザーメッセージに入れることを推奨しています。

気取った文体を避けること。気取った文体とは、直接的な言い方の代わりに比喩や飾りを使う文体を指す。「検討に値するパラメータ」と書けばよいところを「回す価値のあるダイヤル」と書くような言い回しは、考えを伝えるためではなく書き手を見せるためにあり、読者はそれを見抜く。比喩は書き手が選んでいない含みを持ち込み、正確さも落とす。言いたいことをそのまま言い、文字どおりの表現が使えるときはそれを使う。

A-3 チャットの書式 — 太字・見出し・箇条書きが減る

以前のモデルはチャットで箇条書きと太字を使いすぎ、それを抑える「箇条書き禁止」「太字を使うな」といった行が多くのプロンプトに残っています。Fable 5.1は逆に太字が減り、見出し・リスト・引用符にも手を伸ばしにくいため、抑制の行が残っていると必要な構造まで削られます。

対処は、抑制の行を消すか、いつ書式を使ってよいかを述べるルールに置き換えることです。

求められたとき、または内容が多面的で箇条書きの方が明快になるときは、リストや箇条書きを使う。相手が最小限の書式を明示的に求めたら、箇条書き・見出し・リスト・太字を使わずに書く。会話的・個人的・感情的なやり取りでは平文にとどめる。

A-4 引用の明示 — 要約が原文をそのまま再現する

文書を要約するとき、Fable 5.1は原文の一節を引用と示さずに再現する傾向がFable 5より強いとされています。外部資料の要約を社内外に配る業務では、出典と引用の表記が抜ける形で表れます。

対処は、正しい応答の完全な実例を1つシステムプロンプトに入れることです。実例は「ユーザーの依頼」「応答」「なぜ正しいかの一文」の3点で構成し、応答の中で検索ツールを呼ぶ行は自社のツール名に置き換えます。

<example>
<user>A新聞とB新聞がそれぞれ港湾橋の閉鎖をどう報じたか調べて、報道を比較して</user>
<response>
[web_search: 港湾橋 閉鎖 A新聞]
[web_search: 港湾橋 閉鎖 B新聞]
両紙は基本的な事実で一致している。3月3日に溶接部の亀裂が見つかって閉鎖され、州は修理に約8か月を見込む。違いは力点で、A新聞は地域経済の話として扱い、B新聞は予算の失敗として枠づけ、社説は閉鎖を「十分に予見できた」と評している。両方を読むと、A新聞は今誰が影響を受けているかを、B新聞はなぜこうなったかを説明しており、片方だけでは全体像は得られない。
</response>
<rationale>正しい。両紙の一致点と相違点を軸に構成され、どちらかの記事をなぞっていない。各紙の報道は1〜2文の間接話法で伝え、原文をそのまま使ったのは引用符つきの短い一句だけで、他はすべて言い換えている。それでいて具体的で完全である。</rationale>
</example>

A-5 最後までやり切らせる — 「次は…します」で止まる、依頼済みの作業の許可を求める

Fable 5.1は目標が明確なら方法論の指示がなくても非常に長い作業を実行できますが、非同期の複雑な作業では仕事が終わる前にターンを終えることがあると公式は述べています。「次に…を行います」と述べて止まる、依頼に含まれていた手順の許可を「適用しますか？」と求める、という形です。

利用者が「続けて」と返す往復はペアプログラミングには向きますが、長時間の自律作業の能力を使い切れません。対処はシステムプロンプトへの2つの追記で、両方入れるのが公式の推奨です。長さを抑えたければ1つ目だけでも効果の大半が残ります。

あなたは自律的に動作している。ユーザーはリアルタイムで見ておらず、作業の途中で質問に答えられないので、「…しましょうか？」と尋ねると作業が止まる。元の依頼から導かれる可逆な操作は、確認せずに進める。止まるのは、破壊的な操作と、ユーザーが決めるべき本当の範囲変更のときだけ。作業後に次の提案を添えるのはよいが、作業前に許可を求めるのはよくない。

例外: ユーザーが変更を依頼しているのではなく、問題を説明している・質問している・考えを口にしているときは、成果物はあなたの評価である。所見を報告して止まり、頼まれるまで修正を適用しない。

ターンを終える前に、最後の段落を確認する。それが計画・分析・質問・次の手順の一覧・まだやっていない作業の約束（「…します」「…したら教えてください」）なら、今ツールを使ってその作業を行う。エラー後の再試行や、足りない情報を自分で集めることも含む。コンテキストやセッションが長いという理由で止まらない。ターンを終えるのは、作業が完了したか、ユーザーにしか出せない入力で行き詰まったときだけ。

システムの状態を変えるコマンド（再起動・削除・設定変更など）を実行する前に、その操作を裏づける証拠が本当にあるかを確かめる。既知の障害に似た兆候でも、原因は別のことがある。

公式は、冒頭の一文（ユーザーは見ていない）が効果の多くを担うので、書かれたとおりに保つよう述べています。製品として特定の確認で止めたい場合は、その直後に止める操作を列挙した一文を足します。副作用として曖昧な依頼でも質問しにくくなるため、自分のタスクでその損得を確認してください。

# 成果物の届け方
ユーザーの依頼（または承認した計画）が範囲を決め、その範囲がそのまま成果物である。黙って狭めたり、広げたり、すり替えたりしない。曖昧さは注意深い同僚のように読み、日常的な判断は自分で下し、読み方によって成果物が大きく変わるときだけ確認する。指定されたタスクに本当の問題があれば一言二言で伝え、前提を明示して作り続ける。懸念を聞いたうえでユーザーが再確認したら、それはユーザーの決定なので依頼どおり全部を届ける。

途中で疑問が出たら、まず答えに依存しないことをすべて済ませる。そのうえで置いた前提を述べるか、誤った推測で進むのが危険・無意味になる場合は、その進捗を届けるターンの最後に質問を置く。一部が行き詰まったら、他の部分はすべて完成させ、何を省いたか・なぜかを明示する。全体が成果物であり、縮小するかはユーザーが決める。決めた手順は実行するものであって告知するものではない。次の手順を説明してターンを終えると、ユーザーが返事をするまで未着手のままになる。

変更は依頼に必要な範囲にとどめる。タスクが求めていない整理やドキュメント、必要のないファイルへの変更は、最後に提案するものであって行うものではない。依頼の含意を明らかに超える操作や、危険・破壊的な操作は、引き続きユーザーの了承が要る。

Claude Codeでは、削除や外部送信などの許可プロンプトは権限システムが別に管理しているので、この追記で許可の仕組みが外れることはありません。この追記が変えるのは「聞かなくてよいことを聞いて止まる」回数です。

A-6 変更とテストを依頼範囲に留める — 頼んでいない修正・テストが増える

範囲の広い機能を実装させると、Fable 5.1は依頼されたものに加えて周辺のコードを直したり、言及のない挙動を拡張したり、変更に見合わない数のテストファイルをコミットしたりすることがあります。公式は「何を省くか」を明示した指示によく応じると述べています。

次の指示を入れると、頼んでいない追加とコミットされるテストコードが大幅に減り、タスクの成功率には測定できる変化がなかったというのが公式の説明です。

作業中やテスト中に、既存のバグ・性能上の懸念・タスクが触れていない挙動を見つけても、依頼された挙動がそれなしでは動かない場合を除き、この変更の中で修正・最適化・拡張をしない。要約の中でフォローアップとして報告する。タスクが曖昧なら、文言と周囲のコードが最も直接に支持する読み方で実装し、その前提を要約に書き、他の読み方の分まで作らない。検証の方法は自由で、使い捨てのスクリプトや簡易チェックは残さなくてよい。テストをコミットするのは、タスクが求めている場合か、このリポジトリがこの種の変更にテストを持っている場合だけとし、隣接するテストファイルと同程度の規模（明示された挙動1つにつき焦点を絞ったテスト1つが目安）にする。簡易チェックを恒久的なテストファイルにしない。これは「余分」に関するルールであり、タスクが求める挙動はすべて完全に実装する。

A-7 部分編集を優先する — 小さな変更でファイル全体を書き換える

Fable 5.1は対象を絞った編集ではなくテキストファイル全体を書き直す傾向がFable 5より強いとされています。結果のファイルはたいてい同じですが、ファイルが短いか大半が変わる場合を除き、出力トークンと時間が余計にかかり、差分のレビューもしにくくなります。

次の2文をシステムプロンプトか最初のユーザーメッセージに足すと、小〜中規模の変更でFable 5と同じ振る舞いに戻ると公式は説明しています。

他の条件が同じなら、ファイル編集に使うトークンは少ないほどよい。したがって、最終結果に影響しない限り、ファイル全体を書き直すのではなく対象箇所だけを外科的に編集する。

A-8 effortの上下で出る2つの癖 — lowで検索しない、xhigh・maxで長く考えすぎる

low effortでは、Fable 5より検索・取得ツールを呼びにくく、記憶から答えやすくなります。最も簡単な対処は、会話全体ではなく該当するターンだけeffortを上げること。Claude Codeなら /effort で一時的に上げ、APIならベータのメッセージ単位のeffort変更が使えます。

プロンプトで直すなら、「名前を知っていることと、その現状を知っていることは別だ」と伝え、そうした名前はユーザーが書いたとおりの表記で検索させます。

自信を持って認識できない名前、あるいはAIモデルや開発者ツールのように数か月で状況が変わる分野の名前が問い合わせの中心にあるときは、その名前こそ検証すべき対象である。答える前に検索し、言い換えた検索語に加えて、ユーザーが書いたとおりの名前を少なくとも1つの検索に含める。ある程度の背景知識があっても同じで、部分的な知識こそ古い答えをもっともらしく見せる。知っているつもりであることは検索を省く理由にならない。

反対にxhigh と max では、長い成果物を書き始める前に長く考えることがあります。長い文書の全面書き換えを1回の依頼で求めると、思考の中で成果物の大半を下書きし、それを返答としてもう一度書き出すため、待ち時間と出力トークンが増えます。

公式の第一選択は、こうした依頼を推奨の開始点である high で回すことです。品質向上を測定できた場合だけ xhigh や max に上げ、その際はAPI側で max_tokens に思考と返答の両方の余白を取り、ユーザーメッセージの末尾に次の注記を足します。

1回の返答で生み出すものは、返答の前に行う推論や下書きも含めて、合計およそ[max_tokens]トークンという1つの上限に数えられる。返答が終わる前に上限に達すると、相手は途中で切れた応答を受け取り、やり直しになる。成果物全体を推論として書き、さらに返答としてもう一度書くとターンの長さが倍になるだけで結果は良くならないので、そうしない。

代わりに、複数節の文書・大きな表やデータ・完全なコードファイルのような長い成果物を求められたときは、依頼の理解、答えが依存する入力の確認、構成やその他の難しい判断に力を使い、推論の領域は推論に、出力の領域は出力に使う。通常、出力を何度も下書きする必要はない。

A-9 セーフガードの誤検知を減らす言い回し

Fable 5.1の安全性分類器はFable 5の公開時より誤検知が減り、ソースコードの脆弱性を見つける作業は許可されています。それでも起きうる誤検知として、ガイドは3つの状況を挙げています。

• コンパイル確認の聞き方 — 「このプログラムはエラーなくコンパイルできるか」ではなく「このプログラムにバグはあるか」と聞く
• あまり知られていないプログラミング言語 — その言語が何で、どう動くかの文脈を渡す。言語のドキュメントへのアクセスを与えるのが一例
• ツール出力のBase64 — Base64エンコードされたデータをモデルのコンテキストに返すツールは誤検知を誘発するため、取り除くのが推奨

拒否されたときにClaude Codeが別モデルへ自動で切り替える仕組みと、その設定はTeamプランの注意点の記事で解説しています。

パートAのまとめ — CLAUDE.mdに足すときの型

利用者向けの項目を1つの追記にまとめると次のようになります。すべてを入れる必要はなく、症状が出ている項目だけを残して使ってください。Teamプランの注意点の記事の6行版は、この完全版の短縮です。

## Fable 5.1 向けの補正（症状が出た項目だけ残す）

### 進捗報告
着手前に何をするかを1行で伝え、作業中は短い経過報告を挟み、最後に「何を見つけた／何をした／次に何をするか」で締める。

### 自律実行
あなたは自律的に動作している。ユーザーはリアルタイムで見ていないので、可逆な操作は確認せずに進め、破壊的な操作と本当の範囲変更のときだけ止まる。ターンを終える前に最後の段落を確認し、未着手の作業の約束になっていれば今それを行う。

### 範囲
作業中に見つけた既存のバグや改善点は、この変更では直さず要約で報告する。テストは依頼された範囲か、このリポジトリの慣習の範囲だけ。

### 編集
最終結果に影響しない限り、ファイル全体の書き直しではなく対象箇所だけを編集する。

### 文章
気取った文体（比喩や飾りで直接的な表現を置き換える言い回し）を使わない。箇条書き・見出し・太字は、内容が多面的で明快になるときに使う。

### 引用
外部資料を要約するときは、原文をそのまま使う箇所は引用符で示し、それ以外は自分の言葉で書く。

置き場所は3つです。Claude Codeなら各リポジトリの CLAUDE.md、スクリプトから起動する非対話実行なら --append-system-prompt-file、claude.aiなら全メンバーに常時適用される組織の指示です。モデル固有の補正は独立した見出しにしておくと、次の更新で外しやすくなります。

CLAUDE.mdの書き方はCLAUDE.mdの書き方、組織の指示はTeamプランの「組織の指示」に何を書くかを参照してください。

パートB API開発者向け — 自前のハーネスを作る人だけに関係する5項目

ここからは、自社でメッセージ配列を組み立ててAPIを呼ぶハーネス開発者向けです。Claude Code・claude.ai・Managed Agents・Claude Agent SDKを使う限り、会話履歴の条件はAnthropic側が満たしていると新機能ページに明記されています。

B-1 独立したツール呼び出しをまとめる — エージェントループで1ターン1回になる

Fable 5.1は、依頼で複数の取得対象が名指しされていれば通常どおり並列にツールを呼びます。例外は次の呼び出しが依頼から暗黙に導かれるコーディングやコンピュータ操作のループで、そこでは1ターンに1つずつ呼ぶことがあります。回答の品質は変わりませんが、ターンごとにトークン・往復・時間が余計にかかります。

対処は、現在の依頼の末尾に1文の促しを足すことです。

まず次に必要なものを非公開で列挙し、そのうえで、他の結果に依存しない項目をこの1回の応答ですべて要求する。

ツール結果を返すたびに、そのユーザーメッセージの後ろへターン限定のシステムメッセージとして追記します。role が system で clear_at が next_user_message のエントリで、ベータヘッダー mid-conversation-system-clear-at-2026-08-21 が必要です。

ベータを使わない場合は、同じユーザーメッセージ内の tool_result ブロックの後ろにテキストブロックとして置きます。

重要なのは、毎ターン新しいコピーを足し、以前のコピーはバイト単位でそのまま残すことです。後続のユーザーメッセージが現れると以前のコピーはAPI側で消され、モデルには見えず入力トークンも消費しません。逆に削除や書き換えは過去ターンの編集にあたり、キャッシュがそこから再構築され、後続の思考ブロックも無効になります。

while True:
    response = client.beta.messages.create(
        model="claude-fable-5-1",
        max_tokens=16000,
        betas=["mid-conversation-system-clear-at-2026-08-21"],
        tools=tools,
        messages=messages,
    )
    # 返ってきたassistantターンは思考ブロックごとそのまま追記する
    messages.append({"role": "assistant", "content": response.content})
    if response.stop_reason != "tool_use":
        break
    tool_results = run_tools(response.content)  # tool_result ブロックの配列を作る
    messages.append({"role": "user", "content": tool_results})
    # 促しはターン限定のsystemとして毎回追記する。以前のコピーは消さない
    messages.append({
        "role": "system",
        "content": BATCH_NUDGE,
        "clear_at": "next_user_message",
    })

B-2 会話履歴を追記専用に保つ — bound to a different conversation のエラー

各assistantターンはAPIが返したとおり、思考ブロックを含めてそのまま履歴に追記し、リクエストの間に以前のターンを編集しないでください。2026年8月31日以降に作成された新規アカウントでは、Fable 5.1の思考ブロックはそれを生成した会話の中でだけ有効です。

接頭辞（システムプロンプト・ツール一覧・以前のメッセージ）が変わった後で思考ブロックを再送すると400エラーになります。ベータの thinking.block_binding.prefix_mismatch_behavior を drop_block にすると、該当ブロックを落として続行できます（ヘッダー thinking-binding-controls-2026-08-01）。

それ以前のアカウントでは、APIは不一致を記録するだけで、この設定を指定したときだけ動作します。ただし将来のモデルは全アカウントで強制する見込みなので、今のうちに追記専用に直しておくのが公式の勧めです。

このチェックに引っかかる編集は、プロンプトキャッシュを再構築させる編集と同じです。ターンごとの注意書きの挿入と削除、古いターンのその場での要約、セッション途中でのシステムプロンプト変更が典型で、置き換え先はそれぞれ決まっています。

• ターンごとの注意書き → ターン限定のシステムメッセージ（B-1の形）で送る
• 指示やツールの変更 → system や tools を書き換えず、会話途中のシステムメッセージで行う
• コンテキストの削減 → サーバー側のコンパクションかコンテキスト編集に任せる
• クライアント側で要約する場合 → 履歴全体を「要約1件＋新しいユーザーターン」に置き換え、他は何も再送しない。思考ブロックが持ち越されないので失敗せず、モデルは要約された会話を新たに考える

キャッシュ読み取りが安くなったため（100万トークンあたり0.25ドル）、コスト節約のために早めに圧縮する判断はFable 5.1では割に合わない可能性があります。公式は圧縮のタイミングを後ろにずらして試すよう勧めています。

自分のハーネスがすでに履歴を編集していないかを調べるには、drop_block を指定したセッションを走らせて input_transformations を記録するか、通常の数ターン分のリクエストをそのまま捕捉し、追記されたターンを除いて連続するリクエストがバイト単位で一致するかを確認します。

B-3 コンパクション要約に何を残すかを指示する

Fable 5.1は、長い会話を圧縮するときに要約が保持すべきものを明示されると良く応じるモデルです。サーバー側のコンパクションはすでにこれを行っているので、対象はクライアント側で要約を作っている場合だけです。公式の要約指示は、次の6点を「長くなっても完全に」残すよう求めます。

1. 1発生した困難や問題と、それがどう扱われ解決されたか
2. 2提起・試行・却下された可能性・選択肢・アプローチと、その理由
3. 3求められた・決定された・合意された・除外された・好み／制約／境界として確立されたことを、言われたとおりの表現で
4. 4今どこまで進んでいるか。何が扱われ、確定し、完了したか
5. 5未解決・約束済み・次に起きる予定のこと
6. 6再構築しにくい具体的な詳細（名前・数値・日付・正確な文言・リンクや参照）を正確に

さらに、ユーザーの発言は本人の言葉に近い形で慎重に残し、モデル自身の説明や推論は結論と成果物まで大きく圧縮してよいという重みづけがあります。要約は summary タグで囲んで出力させる指定です。

B-4 サブエージェントの実行中もリードを止めない

コーディングエージェントがFable 5.1にサブエージェントへの委譲を許す場合、リードエージェントを各サブエージェントの完了まで強制的に待たせない方が、同程度の品質・トークン・コストで平均完了時間が短くなります。設計は3点です。

• サブエージェントを起動するツールは即座に返す
• 各サブエージェントの結果は、準備ができ次第後続のユーザーメッセージでリードに渡す
• リードが結果を待ちたいときに呼べる別の待機ツールを用意する

モデルはそれでも待つことを選びがちで、時間短縮は他の作業を続けた実行から生まれます。Claude Codeのサブエージェントは既定でバックグラウンド実行され、結果は後続ターンの完了通知として届くので、利用者側の設定は不要です。

B-5 ビジョン作業にクロップとズームのツールを与える

Fable 5.1は初期状態でビジョンが向上しており、密度の高いグラフのような複雑な視覚入力では、繰り返し分析し、切り出し、目で確かめられるときに最良の結果を出します。公式が勧めるのは、生の画像や動画を置いたコンテナと、PILやOpenCVのような基本的な画像処理ライブラリを持つエージェントとして動かすことです。

コンテナが重ければ、画像の指定領域を切り出して拡大して返すツール1つで向上分の大半が得られます。モデルが細部を深く調べられるようになり、画像トークンに応じてテスト時の計算量が伸びます。公式クックブックにクロップツールのレシピがあります。

運用の型 — 消す・測る・1項目ずつ足す・分けて置く

1. 1旧モデル向けの抑制指示を先に消す — 「発見は最後にまとめて」「箇条書き禁止」「太字を使うな」の類は、5.1では必要な報告や構造まで削る。追記の前に棚卸しする
2. 2effortを測り直す — high から始めて、自社の評価タスクで low〜max を試す。Fable 5の測定結果は持ち越さない
3. 3症状が出た項目だけ足す — 16項目を一度に入れない。追記が増えるほど、互いの効果が測れなくなる
4. 4足したら測る — 公式は「変更とテストの範囲」の指示について、追加が大幅に減りタスク成功率は変わらなかったと説明している。自社でも成功率と所要時間の両方を見る
5. 5「Fable 5.1補正」の節として分けて置く — 次のモデル更新で外しやすいよう、CLAUDE.mdの中で独立した見出しにする。モデル固有の補正が本文の規約に溶けると、次の更新で何を消してよいか分からなくなる

モデル更新のたびに「数行の補正」で追随できる体制を作ります

Fable 5.1のガイドから読み取れるのは、モデルの更新ごとに必要なのは「プロンプトの書き直し」ではなく「症状に応じた数行の補正」だという運用の型です。補正を誰がどこに置き、どう測って、次の更新でどう外すかが決まっていないと、CLAUDE.mdと組織の指示には世代ごとに古い指示が積もっていきます。

AI OrchestraのClaude Code研修・導入支援では、CLAUDE.md・組織の指示の設計と棚卸し、effortとモデルの使い分けルール、自社ハーネスの追記専用化まで、モデル更新に追随する仕組みとして伴走しています。「うちのCLAUDE.mdのどの行を消して何を足すか」という具体的な相談からお受けしています。