Claude Fable 5.1へのプロンプト

モデルの機能、APIの変更、料金、提供状況については、Claude Fable 5.1の新機能を参照してください。Claudeモデル全般に適用できる手法については、プロンプトのベストプラクティスを参照してください。

既存のClaude Fable 5のプロンプトは、変更しなくてもClaude Fable 5.1で良好に機能するはずです。ただし、知っておくべき動作の違いがいくつかあります。観察された状況に合ったセクションから読み始めてください：

• どのエフォートレベルで実行すべきかわからない、またはレイテンシとコストがタスクに見合わないほど高い：すべてのエフォートレベルを検討する
• ツール呼び出しの間にテキストがほとんど、またはまったくない：ユーザー向けの進捗更新を求める
• エージェントループで1ターンにつき1つのツール呼び出ししか行われない：エージェントループで独立したツール呼び出しをバッチ処理する
• リクエストがbound to a different conversationで失敗する、またはハーネスがリクエスト間で以前のターンを編集している：会話履歴を追記専用に保つ
• 文章が長く、密度が高くなる：文章の密度
• チャットの返信の構造が、内容に必要な程度より少ない：チャットでのフォーマット
• 要約が、ソースの文言を引用として示さずにそのまま再現する：取得したソースの引用
• 作業が終わる前にターンが終了する、またはすでに依頼した作業についてモデルが許可を求める：タスク全体を完了させる
• クライアント側の「compaction」（コンパクション）の要約で、制約、決定事項、または正確な詳細が失われる：コンパクションの要約で保持すべき内容をモデルに伝える
• 依頼していない修正や拡張が行われる、またはタスクが必要とする以上のテストファイルがコミットされる：変更とテストをタスクが求める範囲に留める
• 低エフォートで、検索せずに記憶から回答する：低エフォートでの検索のトリガー
• 無害なコーディングリクエストがstop_reason: "refusal"を返す：セーフガードの誤検知を減らす
• 小さな変更のためにファイル全体が書き直される：ファイル全体の書き直しよりも的を絞った編集を優先する
• xhighまたはmaxエフォートでの長い成果物に時間がかかる、またはmax_tokensに達する：xhighおよびmaxエフォートで長い出力のための余裕を残す
• サブエージェントの実行中にリードエージェントが待機状態になる：サブエージェントの実行中もリードエージェントに作業を続けさせる
• グラフや情報量の多い画像に関する回答で詳細が見落とされる：ビジョン作業にクロップとズームのツールを与える

すべてのエフォートレベルを検討する

デフォルトのeffort（エフォート）レベルであるhighから始め、その後、他のレベル（low、medium、xhigh、max）を独自の評価でテストしてください。エフォートは、Claude Fable 5.1において知能、レイテンシ、コストのトレードオフを調整するための主要な制御手段です。Claude Fable 5ですでにスイープを実行済みであっても、再度実行してください。エフォートレベルの名前は、モデル間で同じ量の思考に対応しているわけではありません。

Claude Fable 5に対するClaude Fable 5.1の能力向上はすべてのエフォートレベルで見られ、高い設定ほど大きくなります。mediumでは、結果はおおむねClaude Fable 5と同等で、コストはより低くなります。そのため、評価で品質が維持されることが示される場合は、mediumまたはlowに下げてください。lowでは、Claude Fable 5.1はタスクあたりのコストでClaude OpusやClaude Sonnetモデルと競合できることが多く、しかもスコアはより高くなります。そのため、本来であればより小さなモデルをより高いエフォートレベルで実行するような場面では、比較対象に含めてください。

エフォート固有の2つの動作については、それぞれ専用のセクションがあります。lowでは、Claude Fable 5.1は検索ツールや取得ツールを呼び出す頻度が低くなります（低エフォートでの検索のトリガーを参照）。また、xhighとmaxでは、長い成果物を書く前により長く思考することがあります（xhighおよびmaxエフォートで長い出力のための余裕を残すを参照）。

ユーザー向けの進捗更新を求める

Claude Fable 5.1のデフォルトの動作では、長いツール呼び出しのターン中に書くユーザー向けの更新が、Claude Fable 5よりも少なくなります。この傾向は、エフォートが高いほど、またツールチェーンが長いほど顕著になります。ユーザーからは、エージェントが一度に数分間沈黙しているように見えたり、最終メッセージがタスク全体ではなく最後のステップだけを扱っているように見えたりします。

まず、クライアントがそもそも進捗更新を受け取っているかを確認してください。ツール呼び出しの間にモデルが書く短いメモ（直前に見つけたことと次に行うこと）は、進捗更新のthinkingブロックとして返されますが、これらのブロックはデフォルトのthinking.displayである"omitted"では空になります。display: "updates"（ベータ、thinking-display-updates-2026-08-18ヘッダー）を設定して空でない各thinkingブロックをステータス行として表示するか、"summarized"を設定して要約された推論とともに受け取ってください。これらをリクエストしていない場合、モデルの更新が単にユーザーに届いていないだけかもしれません。

次に、ナレーションを抑制する指示がないかプロンプトを確認してください。以前のモデルの中には作業中に積極的に更新を出すものがあり、その結果「すべての調査結果は最終応答まで保留すること」のようなシステムプロンプトの行が書かれるようになりました。何かを追加する前に、そのような行を削除してください。

それでも更新を増やしたい場合（たとえばペアプログラミングやその他のhuman-in-the-loopの作業など）は、モデルからのユーザー向けテキストをいつ求めるか、また各更新に何を含めるべきかを示す短い行をシステムプロンプトに追加してください：

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.

エージェントループで独立したツール呼び出しをバッチ処理する

Claude Fable 5.1は通常、期待どおりに並列ツール呼び出しを行います。リクエストで取得すべきものが複数指定されている場合、それらの呼び出しを並列に行います。例外は、次に行う独立した呼び出しが明示的に要求されるのではなくタスクから暗に示される、コーディングやコンピューター使用のループ（カスタムコーディングエージェント、bashとエディターのハーネス、コンピューター使用）です。このような場合、1ターンに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"を持つものです。後続のユーザーメッセージが存在すると、APIは以前のコピーをクリアするため、モデルは最新のものだけを読みます。ターンスコープのシステムメッセージはベータ版であり、ベータヘッダー mid-conversation-system-clear-at-2026-08-21が必要です。ベータを使用しない場合は、代わりに同じユーザーメッセージ内のtool_resultブロックの後にあるテキストブロックにこの文を配置してください。

毎ターン新しいコピーを追加し、以前のコピーはバイト単位でそのまま残してください。それらは配列内に残りますが、クリアされた後はモデルには見えず、入力トークンのコストもかかりません。それらを削除したり書き換えたりすることは、以前のターンの編集にあたります。その時点からプロンプトキャッシングのキャッシュがやり直しになり、その後に続く思考ブロックが無効になります（会話履歴を追記専用に保つを参照）。

次のループはこの配置を示しています。各アシスタントターンは返されたとおりにそのまま戻され、各ユーザーターンにはツール結果のみが含まれ、その後に促しの新しいターンスコープのコピーが続きます。

import anthropic
from anthropic.types.beta import (
    BetaMessageParam,
    BetaToolParam,
    BetaToolResultBlockParam,
)

client = anthropic.Anthropic()

BATCH_NUDGE = (
    "First privately list what you need next; then request every item "
    "that doesn't depend on another's result in this one response."
)
# サンプルがどこでも実行できるよう、インメモリファイルが作業ディレクトリの代わりを務めます。
FILES = {
    "pyproject.toml": """\
[project]
name = "demo"
version = "0.1.0"
description = "Demo project for the batching example"
""",
    "README.md": """\
# demo

A small demo project. Run `demo --help` for usage.
""",
}
tools: list[BetaToolParam] = [
    {
        "name": "read_file",
        "description": "Read a UTF-8 text file from the working directory.",
        "input_schema": {
            "type": "object",
            "properties": {"path": {"type": "string"}},
            "required": ["path"],
        },
    }
]
messages: list[BetaMessageParam] = [
    {"role": "user", "content": "Summarize pyproject.toml and README.md."}
]

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,
    )
    # 思考ブロックを含め、返されたアシスタントターンをそのまま追加します。
    messages.append({"role": "assistant", "content": response.content})
    if response.stop_reason != "tool_use":
        break
    tool_results: list[BetaToolResultBlockParam] = []
    for block in response.content:
        if block.type == "tool_use":
            raw_path = block.input.get("path")
            path = raw_path if isinstance(raw_path, str) else ""
            if path in FILES:
                tool_results.append(
                    {
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": FILES[path],
                    }
                )
            else:
                tool_results.append(
                    {
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": f"File not found: {path}",
                        "is_error": True,
                    }
                )
    # ツール結果をユーザーターンとして送信し、続いてナッジの新しいコピーを
    # ターンスコープのシステムメッセージとして送信します。以前のコピーはそのまま残します。APIがそれらをクリアするため、
    # モデルには最新のものだけが見えます。
    messages.append({"role": "user", "content": tool_results})
    messages.append(
        {"role": "system", "content": BATCH_NUDGE, "clear_at": "next_user_message"}
    )

print(next((block.text for block in response.content if block.type == "text"), ""))

会話履歴を追記専用に保つ

各アシスタントターンは、思考ブロックを含め、APIが返したとおりに正確に履歴へ追加し、リクエスト間で以前のターンを編集しないでください。2026年8月31日以降に作成された新しいアカウントでは、Claude Fable 5.1の思考ブロックはそれを生成した会話の中でのみ有効です。プレフィックス（システムプロンプト、ツールリスト、または以前の任意のメッセージ）が変更された後に思考ブロックを再送するリクエストは400を返します。thinking.block_binding.prefix_mismatch_behavior: "drop_block"（ベータ、thinking-binding-controls-2026-08-01ヘッダー）を設定している場合は、代わりに影響を受けるブロックが破棄されます。ご自身のアカウントでこのチェックが適用されていない場合でも、同じコードがすべてのアカウントで動作するように、このパターンを採用してください。

このチェックに引っかかる履歴の編集は、プロンプトキャッシングのキャッシュをやり直しにするものと同じです。具体的には、ターンごとのリマインダーの挿入と削除、古いターンのその場での要約、セッション途中でのシステムプロンプトの変更などです。ターンごとのリマインダーはターンスコープのシステムメッセージとして送信し、指示やツールを変更する場合はsystemやtoolsを書き換えるのではなく会話途中のシステムメッセージを使用し、トリミングはサーバー側のコンパクションまたはコンテキスト編集に任せてください。クライアント側でコンパクションを行う場合、最もシンプルな形は、履歴全体を1つの要約メッセージと新しいユーザーターンに置き換え、それ以外は何も再送しないことです。思考ブロックは引き継がれないため何も失敗せず、モデルはコンパクションされた会話について新たに思考します（クライアント側でのカスタムコンパクションを参照）。キャッシュ読み取りが安くなったため（料金を参照）、コスト削減のために早めにコンパクションを行うことは、Claude Fable 5.1ではもはや適切なコストと知能のトレードオフではない可能性があります。より遅いコンパクションのタイミングを試してみてください。

ハーネスがすでに行っている編集を見つけるには、統合が影響を受けるかどうかを確認する方法で説明されているように、prefix_mismatch_behavior: "drop_block"を指定してセッションを実行し、input_transformationsをログに記録してください。または、通常の数ターンの間にハーネスが送信する正確なリクエストをキャプチャし、連続するリクエストが追加されたターンの手前までバイト単位で同一であることを確認してください。

文章の密度

Claude Fable 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.

チャットでのフォーマット

以前のモデルはチャットで箇条書きや太字を多用しすぎる傾向があり、多くのプロンプトにはそれを抑えるために書かれたフォーマット抑制のルールが含まれています。Claude Fable 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.

取得したソースの引用

ドキュメントを要約する際、Claude Fable 5.1はClaude Fable 5よりも、ソーステキストの一節を引用として示さずに再現する可能性が高くなります。これに対処するには、正しい応答の完全な例を1つシステムプロンプトに追加してください。例には、ユーザーのリクエスト、応答、そしてその応答が正しい理由を説明する1文を含めます。

<example>
<user>look up how the Riverton Ledger and the Coast Dispatch each covered the Harbor Bridge closure and compare their reporting</user>
<response>
[web_search: Harbor Bridge closure Riverton Ledger]
[web_search: Harbor Bridge closure Coast Dispatch]
Both outlets agree on the basics: the bridge closed on March 3 after inspectors found cracked welds, and the state expects repairs to take about eight months. Where they differ is emphasis. The Ledger treats it as a local-economy story. The Dispatch frames it as a funding failure; its editorial calls the closure "entirely foreseeable." Read together, the Ledger explains who is affected now and the Dispatch explains how it came to this — neither account alone gives the whole picture.
</response>
<rationale>CORRECT: The response is organized around where the two outlets agree and differ, not as a walk through either article. Each outlet's reporting is conveyed in one or two sentences of the assistant's own indirect speech. One short marked phrase from one source; every other claim is reworded. The response is still specific and complete.</rationale>
</example>

2つの[web_search: ...]行を独自のツール名に置き換えてください。そうすることで、モデルはそれらを出力すべきリテラルテキストではなく、テンプレート化されたツール出力として読み取ります。

タスク全体を完了させる

Claude Fable 5.1は、特に目標が明確な場合、方法論に関する多くのガイダンスなしで非常に長いタスクを実行できます。ただし、複雑な非同期ワークロードでは、作業が完了する前にターンを終了しないよう促してください。この促しがないと、モデルは次に行うことを実行する代わりに説明したり（「次に、…します」）、元のリクエストですでにカバーされているステップについて許可を求めて停止したり（「これを適用しましょうか？」）することがあります。ユーザーは「続けて」や「進めて」と返信する必要があり、これはペアプログラミングやその他のhuman-in-the-loopの作業には適していますが、モデルの長期的なタスク遂行能力を最大限に活用できません。

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.

ユーザーが見ていないことをモデルに伝える冒頭の文が、効果の大部分を担っています。書かれたとおりに残してください。製品で特定の確認のためにモデルを停止させる必要がある場合は、その後にそれらを列挙する文を追加してください。このブロックにより、モデルが曖昧なリクエストについて質問する可能性も低くなることがあるため、そのトレードオフを独自のタスクで確認してください。

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.

コンパクションの要約で保持すべき内容をモデルに伝える

Claude Fable 5.1は、長い会話がコンパクションされる際に要約で何を保持しなければならないかを明示的に伝えられると、よく応答します。サーバー側のコンパクションはすでにこれを行っています。クライアント側でコンパクションを行う場合は、次の要約指示を使用してください：

Summarize the transcript inside <summary></summary> tags. Include relevant information in the summary such that this conversation will be continued by a new context window without needing to redo work or be reprovided with relevant constraints or context. Be sure to preserve: (1) any difficulties or problems that came up, and how they were handled or resolved; (2) any possibilities, options, or approaches that were raised, tried, or set aside, and why; (3) anything that was asked for, decided, agreed, ruled out, or established as a preference, constraint, or boundary — stated exactly; (4) exactly where things stand now — what has been covered, settled, or completed so far; (5) anything still open, unresolved, promised, or expected to happen next; (6) specific details that would be hard to reconstruct — names, numbers, dates, exact wording, links or references — kept exactly. Be complete on these even at the cost of length; keep everything else concise. Weight the two voices differently: keep what the user said, asked for, shared, or established carefully and close to their own words; your own explanations and reasoning can be condensed much further, to what they concluded or produced — as long as nothing in the six items above is dropped.

変更とテストをタスクが求める範囲に留める

オープンエンドな機能の実装を求められた場合、Claude Fable 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.

低エフォートでの検索のトリガー

lowエフォートでは、Claude Fable 5.1はClaude Fable 5よりも検索ツールや取得ツールを呼び出す可能性が低く、記憶から回答する可能性が高くなります。場合によっては、会話全体ではなく影響を受けるターンのエフォートを上げるのが最も簡単な解決策です。会話の途中でエフォートを変更するを参照してください。

それ以外の場合は、検証を促すプロンプトが役立ちます。システムプロンプトで、名前を認識していることはその現在の状態を知っていることと同じではなく、そのような名前はユーザーが書いたとおりに検索すべきであると伝えてください：

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.

セーフガードの誤検知を減らす

Claude Fable 5.1の安全性分類器が生成する「false positive」（誤検知）は、リリース時のClaude Fable 5よりも少なくなっており、ソースコード内の脆弱性を見つけることは許可されています。それでも誤検知は発生し、ブロックされたリクエストはstop_reason: "refusal"を返します（拒否、フォールバック、課金を参照）。次の3つの状況では誤検知が発生しやすくなります：

• コンパイルチェックの言い回し： 「このプログラムはエラーなしでコンパイルできますか？」ではなく、「このプログラムにバグはありますか？」と尋ねてください。
• あまり知られていないプログラミング言語： その言語が何であり、どのように動作するかについてのコンテキストをモデルに与えてください。たとえば、その言語のドキュメントへのアクセスを与えます。
• ツール出力内のBase64： base64エンコードされたデータをモデルのコンテキストに返すツールは誤検知を引き起こす可能性があるため、それらを削除することが推奨される対処法です。

ファイル全体の書き直しよりも的を絞った編集を優先する

Claude Fable 5.1が小さな変更のためにファイル全体を書き直す場合は、次の指示をシステムプロンプトまたは最初のユーザーメッセージに追加してください。Claude Fable 5.1はClaude Fable 5よりも、的を絞った編集を行う代わりにテキストファイル全体を書き直す可能性が高くなります。結果のファイルは通常同じですが、ファイルが短いか大部分が変更される場合を除き、書き直しには出力トークンと時間がより多くかかります。この指示により、小規模および中規模の変更について、Claude Fable 5.1の動作がClaude 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.

xhighおよびmaxエフォートで長い出力のための余裕を残す

xhigh、特にmaxエフォートでは、Claude Fable 5.1は返信を書き始める前により長く思考することがあります。1つのリクエストで長い文書の全面的な書き直しなどの長い成果物を求める場合、その成果物の大部分を思考の中で下書きし、それを返信として再度書き出すことがあり、その結果、待ち時間が長くなり出力トークンも増えます。最もシンプルな方法は、このようなリクエストを推奨される出発点であるhighで実行し、品質の向上を測定できた場合にのみxhighまたはmaxに移行することです（すべてのエフォートレベルを検討するを参照）。xhighまたはmaxで実行する場合は、次のようにしてください：

• max_tokensは、想定する返信の長さだけでなく、思考と返信の両方のための余裕を残すように設定してください。
• 次のメモをユーザーメッセージの末尾に追加してください。これにより、文章やコードのリクエストでの思考が大幅に短くなります。[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.

サブエージェントの実行中もリードエージェントに作業を続けさせる

コーディングエージェントでClaude Fable 5.1が「subagent」（サブエージェント）に作業を委任できる場合、リードエージェントに各サブエージェントを停止して待つことを強制しないでください。コーディングタスクでは、サブエージェントの実行中にリードが作業を続けられるようにすると、品質、トークン使用量、コストを同程度に保ちながら、完了までの平均時間が短縮されます。これを設定するには：

• サブエージェントを開始するツールがすぐに戻るようにします。
• 各サブエージェントの結果は、準備ができ次第、後続のuserメッセージでリードに渡します。
• 結果を待ちたいときに呼び出せる別のツールをリードに与えます。

モデルは依然として待つことを選択することがよくあります。時間の節約は、モデルが他の作業を続ける実行から生まれます。

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

Claude Fable 5.1は、追加の設定なしでもビジョン機能が向上しており、情報量の多いグラフなどの複雑な視覚入力では、見ているものを反復的に分析し、クロップし、視覚的に検証できるときに最高の成果を発揮します。その恩恵を最大限に受けるには、生の画像や動画を保持し、基本的な画像処理ライブラリ（PILやOpenCVなど）がプリインストールされたコンテナにアクセスできるエージェントとしてモデルを実行してください。コンテナの実行がオーバーヘッドとして大きすぎる場合は、画像クロップツールだけでも向上の大部分が得られます。画像の選択した領域をクロップして拡大して返すツールにより、モデルは特定の詳細をより深く調べることができ、画像トークンに応じてテスト時の計算量をスケールさせることができます。クロップツールのレシピに、動作する定義が掲載されています。