Claude Fable 5.1公式プロンプトガイド全17項目を読む──effortは5段階で既定はhigh、「箇条書きを使うな」「見つけたことは最後まで取っておけ」の旧指示が今は逆効果、公式が配る貼るだけの文面11本

Claude Fable 5.1に関する当サイトの記事の入口はまとめページに。

2026年9月17日時点の情報です。Anthropicの開発者向けドキュメントに「Prompting Claude Fable 5.1」というページがある。Claude Fable 5.1（と Mythos 5.1）がFable 5からどう振る舞いを変えたかを、症状別に17項目に分け、それぞれに貼るだけの文面を添えたガイドだ。冒頭の一文は「既存のFable 5のプロンプトは変更なしで5.1でもよく動くはずだが、いくつかの挙動の違いは知っておく価値がある」。当サイトはこのページの.md版を取得し、この記事の記述をすべて原文と照合した。文面は逐語で載せる（読者がそのまま貼る種類の情報なので、要約しない）。

動画版も公開しています： https://youtu.be/DIPuKCkXa4I

3行まとめ

1. effortはlow・medium・high・xhigh・maxの5段階で、既定はhigh。 公式は「Fable 5で測っていても測り直せ（effortの名前はモデルをまたぐと同じ思考量に対応しない）」「mediumでFable 5とほぼ同じ結果がより安く」「lowでもOpus・Sonnetとコストで競合しつつスコアは上」と書いている。
2. Fable 5時代の指示が逆効果になる。 5.1は太字・見出し・リストを使わない方向に振れているので「書式を抑える」文言は消す。作業中の報告も減るので「見つけたことは最後まで取っておけ」の類は消す。何かを足す前に、まず消すのが公式の順番。
3. 途中で止まる・許可を求める癖には「ユーザーはリアルタイムで見ていない」で始まる文面（冒頭の1文が効果の大半、そのまま使え）。余計な修正・テストには範囲を絞る文面（「未依頼の追加とテストが大幅に減り、成功率に測れる変化なし」）。xhigh・maxで長い成果物を頼むときは、思考で下書きしてから書き直す分をmax_tokensに見込む。

17項目の索引──ガイド冒頭は「症状から引く」作り

ガイドは「観察した症状に合う節から始めよ」と書き、冒頭に症状→節の対応を並べている。この記事の見出しも同じ順に並べた。

1. effort──まずhigh、そこから上下に測る

原文の要点はこうだ。

Start at the default effort level, high, then test the other levels (low, medium, xhigh, and max) against your own evals. Effort is the primary control for trading off intelligence, latency, and cost on Claude Fable 5.1. Re-run the sweep even if you already ran one on Claude Fable 5: effort level names don't correspond to the same amount of thinking across models.

（既定のeffortであるhighから始め、他の段階を自分の評価で試せ。effortは5.1で知能・遅延・コストを取引する主な操作である。Fable 5で測っていても測り直せ。effortの名前はモデルをまたぐと同じ思考量に対応しない）

さらに「5.1の伸びは全段階で出るが高い段階で最大」「mediumではFable 5とほぼ同じ結果がより安く出るので、評価で品質が保てるならmediumかlowに下げよ」「lowでは、5.1はOpus・Sonnetとタスクあたりコストで競合しつつスコアは上のことが多いので、小さいモデルを高いeffortで回している場面では比較に入れよ」と続く。effort固有の挙動が2つあり、lowでは検索ツールを呼ぶ回数が減り、xhigh・maxでは長い成果物を書く前に長く考える（それぞれ後述）。

筆者の所感（動画で述べた・公式の記述ではない）：xhighがFable 5のmaxに相当する感覚で、普段はオーバースペック。lowでも十分に働き、コストの面でも納得できる。maxを1時間触ったが、必要になる場面が分からなかった。性能は高いが燃費が悪く、扱いに困る。公式はmaxの推奨用途を書いていない。なお筆者の手元のClaude Code（バージョン2.1.273）の/effortの選択肢には、maxの右に「ultracode」があり、説明は「xhigh effort + dynamic workflows for maximum thoroughness」。APIのeffortにはultraは存在しない（Effortのドキュメントを検索しても0件）。

2. 進捗報告──まず「届いていない」を疑い、次に「抑える指示」を消す

5.1は長いツール呼び出しの間、ユーザー向けの文章をFable 5より書かない。effortが高いほど、ツールの連鎖が長いほど顕著だ。公式の手順は3段階。

1. クライアントが進捗を受け取っているか確認する。 ツール呼び出しの合間の短いメモは進捗更新のthinkingブロックとして返るが、既定のthinking.displayが"omitted"だと中身が空。display: "updates"（ベータ・thinking-display-updates-2026-08-18ヘッダ）にして、空でないthinkingブロックをステータス行として描画する。「要求していなければ、モデルの更新は単にユーザーに届いていないだけかもしれない」
2. 報告を抑える指示を点検する。 「以前のモデルは作業中の報告に熱心だったので『見つけたことは最終回答まで取っておけ』のような行が入っている。何かを足す前に、そういう行を消せ」
3. それでも欲しければ、次の一文をシステムプロンプトに足す。

Before you start, say in a line what you're about to do; brief updates while you work help the user follow along. Close with a short recap that stands on its own — what you found, what you did, and what's next — so a reader who only sees the last message has the full picture.

製品がツール出力を畳んで隠す場合は、そのことをモデルに伝える（伝えないと、UIに表示されない出力を「見せる」ためのコマンドを走らせることがある）。ターン限定のシステムメッセージ（clear_at: "next_user_message"・ベータ）で渡す。

Only you see that command's output — the user's terminal shows at most a few lines of it. If the user needs to read any of it, put it in your reply.

3. 並列呼び出し──暗黙に決まるループでは1ターン1つになる

依頼に「これとこれを取ってこい」と書いてあれば5.1は並列で呼ぶ。例外は、次に呼ぶべきものが依頼から暗黙に決まるコーディングやコンピュータ操作のループ（自作のコーディングエージェント、bashとエディタのハーネスなど）で、そこでは1ターンに1つになることがある。「答えの質は落ちないが、余分なターンごとにトークン・往復・時間がかかる」。今の依頼の末尾に一文足す。

First privately list what you need next; then request every item that doesn't depend on another's result in this one response.

ツール結果を返すたびに、ターン限定のシステムメッセージ（messages内のrole: "system"・clear_at: "next_user_message"・ベータヘッダmid-conversation-system-clear-at-2026-08-21）として毎回新しく追加する。古いコピーは消さずそのまま残す（消したり書き換えたりすると過去のターンの編集になり、プロンプトキャッシュが途切れ、思考ブロックが無効になる）。ベータを使わない場合は、同じユーザーメッセージ内のtool_resultブロックの後ろにテキストブロックとして置く。

4. 履歴は追記のみ──8月31日以降の新規アカウントは400が返る

各アシスタントターンをAPIが返したまま（思考ブロック込みで）履歴に追記し、過去のターンを編集しない。2026年8月31日以降に作られた新規アカウントでは、5.1の思考ブロックはそれを生んだ会話の中でのみ有効で、前置き（システムプロンプト・ツール一覧・それ以前のメッセージ）が変わった後に思考ブロックを再送すると400が返る（thinking.block_binding.prefix_mismatch_behavior: "drop_block"を設定すれば該当ブロックを落として続行・ベータ）。「将来のモデルは全アカウントでこの検査を強制する見込みなので、今は強制されていなくても今のうちにこの形にせよ」。

引っかかる編集は、プロンプトキャッシュを途切れさせるものと同じ3種類。ターンごとのリマインダーの挿入と削除、古いターンのその場での要約、セッション途中のシステムプロンプト変更。それぞれ、ターン限定のシステムメッセージ、会話途中のシステムメッセージ、サーバー側の圧縮かコンテキスト編集に置き換える。クライアント側で圧縮するなら「履歴全体を要約メッセージ1つ＋新しいユーザーターンに置き換え、他は何も再送しない」が最も単純。そして**「キャッシュ読み込みが安くなったので、コスト節約のための早期圧縮は5.1ではもう最適な取引ではないかもしれない。圧縮の時点を遅らせて試せ」**。

5. 文章の密度──「気取った文」を定義して禁じる

5.1の文章は「以前のClaudeより一段良く、決まり文句と説明のない専門用語が減った」が、場合によってはFable 5より密で、文が長く段落の切れ目が少ない。対処は、アンチパターンを定義した指示をユーザーメッセージ（推奨）かシステムプロンプトに足すこと。

Mannered prose substitutes metaphor and flourish for direct statement. Instead of "a parameter worth varying," the mannered writer produces "a dial worth turning." Instead of "this point still matters," they write "this point earns its keep." The phrases exist to display the writer, not to convey the idea, and readers can tell. That is why mannered prose irritates: it makes the reader work harder so the writer can perform. It is also imprecise. Metaphors drag in connotations the writer did not choose and cannot control. The fix is to say what you mean. When a literal phrase is available, use it.

短い版でもだいたい通る。

Please remove all mannered prose.

6. チャットの書式──「書式を抑える」文言は消す

以前のモデルはチャットで箇条書きと太字を使いすぎ、それを抑えるための「書式禁止」の行が多くのプロンプトに残っている。5.1は逆に、太字を使わず、見出し・リスト・引用符にも手を伸ばしにくい。書式を抑える文言があるなら消すか、「どの書式がいつ適切か」を言う規則に置き換える。

Use lists and bullet points when asked to, or when the content is multifaceted enough that they help with clarity. If the person explicitly requests minimal formatting, always format your responses without bullet points, headers, lists, or bold emphasis, as requested. In conversational, personal, or emotional exchanges, keep to plain prose.

7. 出典の引用──正解例を1つ、理由の1文つきで

文書を要約するとき、5.1はFable 5より「出典の文をそのまま使うが引用と示さない」ことが多い。対処は、正しい応答の完全な例を1つ（ユーザーの依頼・応答・それが正しい理由の1文）システムプロンプトに足すこと。公式の例は架空の2紙による橋の閉鎖報道の比較で、<example><user>…</user><response>…</response><rationale>CORRECT: …</rationale></example>の形。例の中の[web_search: ...]の2行は自分のツール名に置き換える（テンプレ化したツール出力として読ませるため）。

8. 最後までやる──「ユーザーは見ていない」の1文が効果の大半

5.1は目標が明確なら長いタスクを方法論の指示なしで実行できるが、複雑な非同期の作業では、ターンを終える前に仕事を終えるよう促す必要がある。促さないと「次はこれをやります（Next, I'll …）」と書いて実行しなかったり、依頼済みの手順について「適用しますか？（Shall I apply this?）」と許可を求めたりする。対処はシステムプロンプトへの追加2つで、両方入れる。長さを削るなら1つ目だけで効果の大半は保てる。

1つ目（依頼済みの作業について聞かず、宣言した次の手順を実行させる）：

You are operating autonomously. The user is not watching in real time and cannot answer questions mid-task, so asking 'Want me to…?' or 'Shall I…?' will block the work. For reversible actions that follow from the original request, proceed without asking. Stop only for destructive actions or genuine scope changes the user must decide. Offering follow-ups after the task is done is fine; asking permission before doing the work is not.

Exception: when the user is describing a problem, asking a question, or thinking out loud rather than requesting a change, the deliverable is your assessment. Report your findings and stop. Don't apply a fix until they ask for one.

Before ending your turn, check your last paragraph. If it is a plan, an analysis, a question, a list of next steps, or a promise about work you have not done ('I'll…', 'let me know when…'), do that work now with tool calls. That includes retrying after errors and gathering missing information yourself. Do not stop because the context or session is long. End your turn only when the task is complete or you are blocked on input only the user can provide.

Before running a command that changes system state (such as restarts, deletes, or config edits), check that the evidence actually supports that specific action. A signal that pattern-matches to a known failure may have a different cause.

The opening sentence, which tells the model the user isn't watching, carries much of the effect. Keep it as written.

（冒頭の1文──ユーザーは見ていないと伝える文──が効果の大半を担う。そのまま使え）

止まってほしい確認事項があるなら、その後ろに列挙する。トレードオフとして「曖昧な依頼についても聞き返しにくくなる」ので、自分のタスクで確かめる。

2つ目（ユーザーの依頼を成果物の範囲と定義する）：

# Delivering work
The user's request — or the plan they approved — sets the scope, and the scope is the deliverable: don't quietly narrow, widen, or swap it. Read ambiguity the way a careful colleague would: make routine judgment calls yourself, and check in only when different readings would lead to materially different work. If you see a real problem with the task as specified, say so in a sentence or two and keep building under stated assumptions; if the user hears the concern and reaffirms, that is their decision, so deliver the full request.

If a question comes up partway, first do everything that doesn't depend on the answer; then state the assumption you made, or — when going ahead on a wrong guess would be unsafe or would make the work useless — put the question at the end of a turn that also delivers that progress. If one part turns out to be blocked, complete every other part in full and say exactly what you left out and why — the whole task is the deliverable, and scaling it down is the user's call, not yours. A step you have decided on is something to run, not to announce: describing the next step and ending the turn leaves it undone until the user replies.

Keep changes to what the request needs. Something else you notice worth doing — cleanup or documentation the task didn't call for, a change to a file the task didn't require — is a suggestion to make at the end, not a change to make; actions clearly beyond what the ask implies, and risky or destructive ones, still need the user's go-ahead.

9. 圧縮要約──残すものを6つ指定する

5.1は「要約に何を残すか」を明示されるとよく応える。サーバー側の圧縮はすでにそうしている。クライアント側で圧縮するなら次の指示を使う（要約を<summary></summary>で囲み、①起きた問題と解決、②挙がった選択肢と採否の理由、③依頼・決定・合意・除外・制約を原文どおり、④現在地、⑤未解決と次に起きること、⑥再構成しにくい具体（名前・数字・日付・原文・リンク）を正確に、の6点を長さを犠牲にしても残す。ユーザーの発言は本人の言葉に近く残し、モデル自身の説明は結論まで圧縮してよい）。原文は公式ページの「Tell the model what to preserve in compaction summaries」にある。

10. 範囲を絞る──「未依頼の追加とテストが大幅に減り、成功率は変わらない」

自由度の高い機能実装を頼むと、5.1は頼まれた以上をやることがある。近くのコードを直す、頼まれていない挙動を拡張する、変更に見合わない数のテストファイルをコミットする。何を省くかを明示すると応える。公式は「次の指示で、未依頼の追加とコミットされたテストコードが大幅に減り、タスクの成功率に測れる変化は無い」と書いている（減り幅の数値は公開されていない）。

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.

11. 検索の発火──lowでは記憶から答えがち

lowでは5.1はFable 5より検索・取得ツールを呼ばず、記憶から答えやすい。最も簡単な対処は「会話全体ではなく該当ターンだけeffortを上げる」。プロンプトで促すなら、システムプロンプトで「名前を知っていることと現状を知っていることは別で、そうした名前はユーザーが書いたとおりに検索せよ」と言う。

When a query centers on a name you do not confidently recognize, or recognize from a fast-moving area like AI models and developer tools where the landscape shifts within months, the name itself is the thing to verify: search before answering, and include the name as the user wrote it in at least one query alongside any reformulations. This holds even when you have some background on it — partial background is exactly what makes an out-of-date answer sound authoritative, so familiarity is not a reason to skip the search.

12. 誤検知──「コンパイルできるか」ではなく「バグはあるか」

5.1の安全分類器は、Fable 5の公開当初より誤検知が少なく、ソースコードの脆弱性発見は許可されている。それでも起きるときはstop_reason: "refusal"が返る。起きやすい状況は3つ。

• コンパイル確認の言い方：「エラーなくコンパイルできるか」ではなく「このプログラムにバグはあるか」と聞く
• マイナーな言語：その言語が何でどう動くかの文脈（ドキュメントへのアクセスなど）を渡す
• ツール出力のBase64：Base64を含むデータをモデルの文脈に返すツールは誤検知の引き金になるので、取り除くのが推奨

13. 部分編集──ファイル丸ごと書き換える癖を戻す1文

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.

14. 長い出力──xhigh・maxは「思考で下書きしてから書き直す」

xhigh、とくにmaxでは、5.1は返答を書き始める前に長く考える。長い文書の全面書き換えのような成果物を1回で頼むと、成果物の大半を思考の中で下書きし、それをもう一度返答として書き出すことがある（待ち時間と出力トークンが増える）。最も簡単な答えは推奨の出発点であるhighで回し、品質の向上を測れた場合だけxhigh・maxに上げること。それでもxhigh・maxで回すなら、①max_tokensは思考と返答の両方に余地を持たせる、②次の注記をユーザーメッセージの末尾に足す（[max_tokens]は実際の値、例えば64,000に置き換える）。

Everything produced in one reply, including any reasoning or drafting done before the reply, counts toward a single limit of about [max_tokens] tokens. If that limit is reached before the reply is finished, the person receives a cut-off response and has to start over. Composing an entire output or deliverable in full as reasoning and then again as a reply would double the length of the turn without improving the result, so don't do that.

Instead, when the person has asked for a long or effort-intensive deliverable such as a multi-section document, a large table or dataset, or a complete code file, spend extra effort on understanding the request, checking the inputs the answer depends on, settling the structure and other difficult decisions, and otherwise using the reasoning space to reason and the output space to write an output. Usually it is not needed to draft an output multiple times.

15. リードを待たせない──「それでもモデルは待つことを選ぶ場合が多い」

コーディングエージェントで5.1がサブエージェントに委任できる場合、リードを各サブエージェントの完了まで止めない。コーディングタスクでは、リードを続行させると「同程度の品質・トークン使用量・コストで、平均完了時間が下がる」。設定は、①サブエージェント起動ツールを即時返却にする、②結果は後のuserメッセージでリードに渡す、③待ちたいときに呼べる別のツールをリードに与える。公式は「それでもモデルは待つことを選ぶ場合が多い。時間の節約は、他の作業を続けた実行から来る」と書いている。

16. 切り抜きと拡大──クロップツール1つで効果の大半

5.1は最初から視覚能力が上がっており、密なグラフのような複雑な入力では「反復して分析し、切り抜き、視覚的に確認できる」ときに本領を発揮する。生の画像や動画を置いたコンテナと基本的な画像処理ライブラリ（PIL・OpenCV）をエージェントに与えるのが本筋だが、コンテナが重ければ画像の切り抜きツール1つで効果の大半が得られる（選んだ領域を切り抜いて拡大して返すツール）。公式クックブックにクロップツールの定義がある。

17. 何から手をつけるか──「まずeffort、次に消す、最後に足す」

ここは筆者の順番で、公式が明示している順序ではない。①effortをhighから測り直す（既定を疑わない）。②Fable 5時代に足した「書式を抑える」「報告を抑える」行を消す。③それでも症状が残る項目だけ、公式の文面を足す。公式自身が「何かを足す前にその行を消せ」と2度書いていることが、この順番の根拠だ。

この記事で確かめていないこと

• 公式が「大幅に減る」「平均完了時間が下がる」「効果の大半」と書いている箇所の数値。いずれも公開されていない
• 各文面の効果を当サイトが自分の評価で測ったわけではない。筆者の所感として書いたのは、effortの体感（xhigh≒Fable 5のmax、lowで十分、maxの使いどころが分からない）だけ
• ツール呼び出しバッチ化のPython・TypeScriptのコード例、prefix_mismatch_behavior: "drop_block"によるデバッグ手順、クロップツールのレシピの中身は、この記事では扱っていない（公式ページにある）

出典と時点

• 一次資料：Anthropic「Prompting Claude Fable 5.1」（platform.claude.com・.md版を2026年9月17日に取得し、引用文と文面を原文と照合）、同「Effort」、同「What's new in Claude Fable 5.1」
• 筆者環境の観測：Claude Code 2.1.273の/effortの選択肢（ultracode＝xhigh + dynamic workflows）
• 引用の訳は筆者による。コードブロック内の文面は原文のまま