ai-docs

Prompting Claude Fable 5

Properties1
tagsprompting, agents, subagents, memory, effort, claude-fable-5

17 min read

一行要約

Fable 5 向けの prompting は「指示を列挙する」から「短い指示1つで steer する」へ移る。最大の実務的インパクトは1リクエストが数分〜数時間走ることで、クライアントのタイムアウトと harness の構造を先に直す必要がある。

要点

The teams seeing the best outcomes apply Claude Fable 5 to their hardest unsolved problems; testing it only on simpler workloads tends to undersell its capability range. 最も良い成果を得ているチームは、Claude Fable 5 を自分たちの最も難しい未解決の問題に当てている。単純なワークロードでしか試さないと、その能力の幅を過小評価しがちである。

安全分類器（移行前に知るべき）

Fable 5 は攻撃的サイバーセキュリティ技術（exploit、malware、攻撃ツール）、生物学・生命科学（実験手法、分子機構）、モデルの要約された thinking の抽出を対象とする安全分類器を走らせる。善意のセキュリティ研究や有益な生命科学タスクもこれに触れうる。 拒否されたリクエストを自動で回すには Opus 4.8 へのフォールバックを設定する。

能力の改善（プロンプトに影響するもの）

  • long-horizon autonomy — 数日にわたる目標指向の実行を完遂し、長く複雑なタスクで指示を保持する
  • 複雑でよく仕様化された問題での first-shot 正答率 — 早期テスターが「以前は数日の反復を要したシステムの単発実装」を報告
  • vision — 密な技術図、web アプリ、詳細なスクリーンショットをより少ない出力トークンで高精度に解釈。bash と crop ツールで反転・ぼけ・ノイズのある画像を扱うよう訓練されている
  • 委譲と協調 — 並列 subagent の dispatch と維持が格段に信頼できる

最大の変化 — ターンが長い

Individual requests on hard tasks can run for many minutes at higher effort settings, and autonomous runs can extend for hours. This is one of the largest shifts teams encounter. 難しいタスクでは、高い effort 設定で個々のリクエストが何分も走ることがあり、自律的な実行は数時間に及ぶこともある。これはチームが直面する最も大きな変化のひとつである。

移行前に、クライアントのタイムアウト・ストリーミング・進捗表示を調整する。 さらに harness をブロッキングではなく非同期でチェックする形に再構成することを検討する。

effort

high（既定）を大半のタスクに。 最も能力を要するものに xhigh、日常業務に medium / low。

Lower effort settings on Claude Fable 5 still perform well and often exceed xhigh performance on prior models. Claude Fable 5 は低い effort 設定でも十分に高い性能を示し、以前のモデルの xhigh を上回ることも多い。

高い effort での注意: 日常業務ではタスクが必要とする以上に文脈を集めて熟考しうる。一方で検証の振る舞い・洗練された推論・最も厳密な出力が得られる。

指示追従が強いので、短く書けばよい

Instruction-following is improved enough that you can steer most behaviors with a brief instruction rather than enumerating each behavior by name. 指示への追従が改善されたため、振る舞いをひとつずつ名指しで列挙するのではなく、短い指示で大半を誘導できる。

短い簡潔さの指示は、パターンを1つずつ列挙するのと同じ効果がある。

長時間実行での進捗の接地（実測で効いた）

In Anthropic’s testing, this nearly eliminated fabricated status reports even on tasks designed to elicit them. Anthropic のテストでは、これによって捏造された進捗報告がほぼなくなった。そうした報告を誘発するよう設計されたタスクにおいてさえである。

ツール結果に照らして各主張を監査させるのが要点。

境界を明示する

頼まれていない行動（頼まれていないメールの下書き、防御的な git ブランチのバックアップ）を稀に取る。

並列 subagent

Use subagents frequently, provide explicit guidance about when delegation is appropriate, and prefer asynchronous communication over blocking until each subagent returns. Long-lived subagents that keep their context across subtasks save time and cost through cache reads and avoid bottlenecking on the slowest subagent. subagent を頻繁に使い、どういうときに委譲が適切かを明示的に伝え、各 subagent の完了を待ってブロックするのではなく、非同期の通信を選べ。サブタスクをまたいで context を保つ長命の subagent は、キャッシュ読み出しによって時間とコストを節約し、最も遅い subagent がボトルネックになることを避けられる。

memory システムを作る

Claude Fable 5 performs particularly well when it can record lessons from previous runs and reference them. Provide a place to write notes, as simple as a Markdown file. Claude Fable 5 は、過去の実行から得た教訓を書き留め、それを参照できるとき特に良い性能を発揮する。メモを書く場所を用意せよ。Markdown ファイル1枚で十分である。

既存の履歴からブートストラップできる — 過去のセッションを振り返らせてテーマと教訓を抽出させる。

稀な早期停止

深いセッションで、対応するツール呼び出しなしに「これから X します」というテキストだけでターンを終える、または既に進められるのに許可を求めて止まることがある。「continue」で足りる。自律パイプラインには system reminder を足す。

稀な context 予算の懸念

非常に長いセッションで、新セッションを提案したり、要約と引き継ぎを申し出たり、自分の作業を切り詰めたりすることがある。

This is most often triggered when the harness shows a remaining-token countdown to the model. Avoid surfacing explicit context-budget counts where possible. これは、harness がモデルに残りトークンのカウントダウンを見せているときに最も多く起きる。context の残量を明示的に見せることは、可能な限り避けよ。

理由を与える

Claude Fable 5 tends to perform better when it understands the intent behind a request: context lets it connect the task to relevant information rather than inferring intent on its own. Claude Fable 5 は、依頼の背後にある意図を理解できるときに良い性能を示す傾向がある。context があれば、意図を自力で推測するのではなく、タスクを関連する情報に結びつけられる。

ユーザーとの対話の読みやすさ

長い agentic 会話では、矢印チェーンの略記・深い実装詳細・ユーザーが見ていない thinking への言及・過度に技術的な言い回しが出うる。

推奨される scaffolding の変更

  • 難易度の上端から始める — 従来モデルに割り当てるより難しいタスクを選び、スコープを切らせ、明確化の質問をさせ、実行させる

  • 長時間実行のプロンプトで自己検証を明示する

    Separate, fresh-context verifier subagents tend to outperform self-critique. 切り離された、まっさらな context を持つ検証用 subagent は、自己批判より良い結果を出す傾向がある。

  • 既存のプロンプトと skill を作り直す

    Skills developed for prior models are often too prescriptive for Claude Fable 5 and can degrade output quality. 以前のモデル向けに作った skill は、Claude Fable 5 には指示が細かすぎることが多く、出力品質を下げうる。

  • 推論を応答内に再現させる指示を書かない — echo / transcribe / explain internal reasoning を求める指示は reasoning_extraction の拒否カテゴリを発火させ、Opus 4.8 へのフォールバックを増やす。移行時に既存の skill と system prompt から「思考を見せろ」系の指示を監査して外す

  • send-to-user ツールを作る（下記）

そのまま使える具体例

過剰な計画を抑える:

When you have enough information to act, act. Do not re-derive facts already established in the conversation, re-litigate a decision the user has already made, or narrate options you will not pursue in user-facing messages. If you are weighing a choice, give a recommendation, not an exhaustive survey. This does not apply to thinking blocks.

高 effort での不要な整理・リファクタを止める:

Don't add features, refactor, or introduce abstractions beyond what the task requires. A bug fix doesn't need surrounding cleanup and a one-shot operation usually doesn't need a helper. Don't design for hypothetical future requirements: do the simplest thing that works well. Avoid premature abstraction and half-finished implementations. Don't add error handling, fallbacks, or validation for scenarios that cannot happen. Trust internal code and framework guarantees. Only validate at system boundaries (user input, external APIs). Don't use feature flags or backwards-compatibility shims when you can just change the code.

簡潔さ（短い指示1つで足りる例）:

Lead with the outcome. Your first sentence after finishing should answer "what happened" or "what did you find": the thing the user would ask for if they said "just give me the TLDR." Supporting detail and reasoning come after. Being readable and being concise are different things, and readability matters more.
 
The way to keep output short is to be selective about what you include (drop details that don't change what the reader would do next), not to compress the writing into fragments, abbreviations, arrow chains like A → B → fails, or jargon.

チェックポイントの挙動:

Pause for the user only when the work genuinely requires them: a destructive or irreversible action, a real scope change, or input that only they can provide. If you hit one of these, ask and end the turn, rather than ending on a promise.

進捗の接地（捏造された status を「ほぼ消した」指示）:

Before reporting progress, audit each claim against a tool result from this session. Only report work you can point to evidence for; if something is not yet verified, say so explicitly. Report outcomes faithfully: if tests fail, say so with the output; if a step was skipped, say that; when something is done and verified, state it plainly without hedging.

境界の明示:

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 running a command that changes system state (restarts, deletes, 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.

並列 subagent:

Delegate independent subtasks to subagents and keep working while they run. Intervene if a subagent goes off track or is missing relevant context.

memory システムの規約:

Store one lesson per file with a one-line summary at the top. Record corrections and confirmed approaches alike, including why they mattered. Don't save what the repo or chat history already records; update an existing note rather than creating a duplicate; delete notes that turn out to be wrong.

既存履歴から memory をブートストラップする:

Reflect on the previous sessions we've had together. Use subagents to identify core themes and lessons, and store them in [X]. Make sure you know to reference [X] for future use.

自律パイプライン用の system reminder（早期停止を防ぐ）:

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. Offering follow-ups after the task is done is fine; asking permission after already discussing with the user before doing the work is not. 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. End your turn only when the task is complete or you are blocked on input only the user can provide.

context 予算の懸念への安心:

You have ample context remaining. Do not stop, summarize, or suggest a new session on account of context limits. Continue the work.

理由を与えるテンプレート:

I'm working on [the larger task] for [who it's for]. They need [what the output enables]. With that in mind: [request].

最終要約の読みやすさ:

Terse shorthand is fine between tool calls (that's you thinking out loud, and brevity there is good). Your final summary is different: it's for a reader who didn't see any of that.
 
If you've been working for a while without the user watching (overnight, across many tool calls, since they last spoke), your final message is their first look at any of it. Write it as a re-grounding, not a continuation of your working thread: the outcome first, then the one or two things you need from them, each explained as if new. The vocabulary you built up while working is yours, not theirs; leave it behind unless you re-introduce it.
 
When you write the summary at the end, drop the working shorthand. Write complete sentences. Spell out terms. Don't use arrow chains, hyphen-stacked compounds, or labels you made up earlier. When you mention files, commits, flags, or other identifiers, give each one its own plain-language clause. Open with the outcome: one sentence on what happened or what you found. Then the supporting detail. If you have to choose between short and clear, choose clear.

send-to-user ツール（ツール入力は決して要約されないので、内容がそのまま届く）:

{
  "name": "send_to_user",
  "description": "Display a message directly to the user. Use this for progress updates, partial results, or content the user must see exactly as written before the task finishes.",
  "input_schema": {
    "type": "object",
    "properties": {
      "message": {
        "type": "string",
        "description": "The content to display to the user."
      }
    },
    "required": ["message"]
  }
}

定義だけでは呼ばれない。 system prompt に誘発する文言をセットで置く:

Between tool calls, when you have content the user must read verbatim (a partial deliverable, a direct answer to their question), call the send_to_user tool with that content. Use send_to_user only for user-facing content, not for narration or reasoning.

長時間タスクでの自己検証:

Establish a method for checking your own work at an interval of [X] as you build. Run this every [X interval], verifying your work with subagents against the specification.

原典で言及されている関連文書

未取得の派生リンク

グラフビュー

バックリンク