Claude Fable 5の早期停止をプロンプトで防ぐ方法

Claude Fable 5の早期停止で何が起きるか

長時間の自律セッションの深い段階で、Claude Fable 5がツール呼び出しをせずに「これからXを実行します」という文章だけを残してターンを終えることがあります。実行してよい材料が揃っているのに、許可を求めて止まるケースも同じ症状です。Anthropicのプロンプトガイドは、これを「まれなケース(rare cases)」に分類しています。

とはいえ、数時間かけて回す自律パイプラインでは、この一度の停止が丸ごとタイムアウトや無駄な待機になります。会話が生きているなら「continue」や「go ahead and do it end to end」と一言返せば再開します。人が張り付いていないパイプラインでは、その一言を誰も打てません。止まらずに進んだ作業の報告が正しいかは、進捗報告をツール結果に照合させる指示で別に守ります。

見分け方と、起きる場面

早期停止かどうかは、ターンの最後が何で終わっているかで決まります。

ガイドは、長いセッションの深い段階で起こりうるとしています。Claude Fable 5は、難しいタスクでは1回のリクエストが高いeffort設定で数分かかり、自律実行は数時間に及びます。移行時に最も大きく変わる点の1つとされ、クライアントのタイムアウトやストリーミング、進捗表示は移行前に見直します。スケジュールジョブなどで非同期に様子を見る設計も検討対象です。

ログからの機械的な検出

ハーネス側から見ると、早期停止も正常な完了も「テキストでターンが終わった」という同じイベントです。Messages APIの応答なら、候補は絞れます。条件は3つで、stop_reasonがend_turnであること、contentにtool_useブロックが無いこと、最後の段落が宣言か質問に見えることです。次のスクリプトは、4つの応答例を下の出力のように判定します。なお、モデルが拒否した場合のstop_reason: "refusal"はend_turnではないので、この条件には入りません。Messages APIはこれをエラーではなく、HTTP 200の成功応答として返します。

import re
 
INTENT = re.compile(r"(I'll|I will|Let me|Shall I|Want me to|let me know)|(します|しましょうか|よろしいですか|お知らせします)")
 
def looks_stopped_early(message: dict) -> bool:
    if message.get("stop_reason") != "end_turn":
        return False
    blocks = message.get("content", [])
    if any(b.get("type") == "tool_use" for b in blocks):
        return False
    texts = [b["text"] for b in blocks if b.get("type") == "text"]
    if not texts:
        return False
    last_paragraph = texts[-1].strip().split("\n\n")[-1]
    return bool(INTENT.search(last_paragraph))

宣言だけで終了: True
許可待ちで終了: True
ツール呼び出しで終了: False
完了報告で終了: False

「宣言だけで終了」は最後の段落が「これからデプロイを実行します。」、「許可待ちで終了」は「Shall I run the migration?」で終わる例です。3つ目はstop_reasonがtool_useで、宣言のあとに実際の呼び出しが付いています。

この判定は正規表現による当たりをつける程度のものです。「完了しました。次回は〜します」のような正常な報告も拾うので、アラートの手前に置いて、検出したら再開用のメッセージを自動で送る入口に使います。再開の文面は、人間が打つ場合と同じ「go ahead and do it end to end」で足ります。

ターン終了前の自己点検プロンプト

プロンプトガイドが自律パイプライン向けに示す回避策は、システムプロンプトに「ターンを終える前に最後の段落を自分で点検させる」指示を加えることです。

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.

要点は2つです。1つ目は「ユーザーは見ていない、答えられない」という前提の明示で、可逆な操作なら確認を挟まず進めてよいという線引きも同時に与えます。2つ目は、ターンを閉じる直前に最後の段落を読み返させ、計画・分析・質問・未実行の約束のどれかに当たるなら、その場でツール呼び出しに落とし込ませることです。

Claude Codeで使うなら、Claude Code v2.1.287のclaude --helpに--append-system-prompt <prompt>が載っています。既定のシステムプロンプトに文を足すフラグなので、既定の挙動を残したままこの指示を加えられます。

止まってよい条件を別立てで渡す

ガイドの早期停止の節は、自己点検を、止まってよい場面を定める「チェックポイントの指示」と組み合わせるよう書いています。

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.

止まってよい条件は3つです。破壊的または不可逆な操作、実質的なスコープの変更、本人にしか出せない入力。この3つに当たらない限り、自己点検の側で進めさせます。場面を1つずつ列挙しなくても短い指示で足りるのは、Claude Fable 5の指示追従性が高いためだと説明されています。

症状別に使い分ける早見表

自律実行が止まる原因は1つではありません。症状から、効くプロンプトを選びます。

進捗報告の裏取り

止まらずに進めるようにすると、次に気になるのは報告の中身です。長い自律実行では、進捗の主張をこのセッションのツール結果と突き合わせさせる指示が勧められています。Anthropicのテストでは、これで状況報告の捏造が、捏造を誘うよう設計したタスクでもほぼ消えたとのことです。

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.

自己点検は「動かすこと」、裏取りは「正直に報告すること」を担うので、役割が別です。検証は自己批評に任せるより、新しいコンテキストの検証用サブエージェントに仕様と照合させるほうがうまくいく傾向がある、とも書かれています。

検証の間隔を指定したい長時間タスクには、ガイドに専用の文面もあります。[X]の部分に、作業量や時間の区切りを入れて使います。

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.

導入の順序

指示を一度に足すと、どれが効いたか分かりません。次の順に入れると、症状と対策が1対1で確かめられます。

効き目が薄いときの見直し点

対策を入れても止まるときは、次の点を見直します。

1. 再開の入力: 宣言止まりが出たときは、「continue」や「go ahead and do it end to end」のような短い入力で足りるとガイドにあります。再開用の入力を、自動再投入に組み込めます。
2. 停止条件の抜け: 自己点検だけで確認の質問が減らないなら、止まってよい3条件が入っているかを見ます。入っていなければ、先の節の指示を足します。
3. effortの強さ: タスクは終わるのに必要以上に時間がかかるなら、effortを下げる選択肢があります。routine作業までhigh以上で回しているなら、mediumやlowが選択肢に入ります。
4. 過去のプロンプトの持ち越し: 以前のモデル向けに作ったスキルは、Claude Fable 5には指示が細かすぎて出力を落とすことがあります。古い指示は、既定の挙動のほうが良いなら外します。

自己点検に「推論を書かせる」文を混ぜない

自己点検の指示を足すとき、「判断の理由を回答に書き出して」のような文を混ぜないでください。モデルの内部推論を回答テキストとして再現させる指示は、Claude Fable 5でreasoning_extractionという拒否カテゴリを招きうるとされています。fallbacks: "default"のサーバー側フォールバックはこの拒否を再試行せず、呼び出し側に返します。推論の可視化が必要なら、構造化されたthinkingブロックを読むか、途中経過をsend-to-userツールで出す設計が案内されています。

コンテキスト残量を理由にした停止

早期停止と隣り合う挙動として、非常に長いセッションで、新しいセッションの提案や要約しての引き継ぎの申し出、自分の作業の切り詰めが出ることがあります。ガイドはこれも「まれなケース」としたうえで、ハーネスが残りトークン数のカウントダウンをモデルに見せていることが最も多い引き金だと書いています。具体的な残量表示は見せないのが第一の対策で、見せざるを得ないなら次の一文を添えます。原因の切り分けはClaude Fable 5が新しいセッションを勧めてくる原因と対処にあります。

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

途中経過はsend-to-userツールで見せる

ターンを終えずにユーザーへ内容を届けたいときは、send-to-userツールが勧められています。クライアント側のツールで、メッセージを要約せず逐語で届けます。ただしツールを定義するだけではClaude Fable 5はほとんど呼びません。「ユーザーが逐語で読むべき内容(部分的な成果物、質問への直接の答え)があるときは、ツールを呼ぶ」という指示をシステムプロンプトに添えて初めて動きます。ナレーションや内部の推論までこのツールに流すと、目的が崩れます。定型の進捗を語るだけのエージェントなら、モデル自身の要約で足りるとされています。

モデルの挙動差や料金はClaude Fable 5.1とは、Opus 5との使い分けはFable 5とOpus 5の違いで扱っています。

最終報告は「初めて読む人」向けに書かせる

人が見ていない間に長く作業したあとは、最後のメッセージが、ユーザーにとって作業内容を初めて目にする場になります。長いエージェント会話では、矢印でつないだ省略表記や、ユーザーが見ていない推論への言及が混ざり、読みにくい文章になることがあります。ガイドには、途中のツール呼び出しの間は省略表記でよいが、最終まとめは経緯を見ていない読者向けに書く、という追記が載っています。

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.

ガイドの追記が求める順序は、結果を先に言い切り、本人に判断してほしい点が残れば1〜2点だけを初めて聞く人向けに説明する、というものです。止まらずに完走させる設計では、この最終報告がレビューの唯一の入口になります。進捗の裏取りと合わせて入れておくと、結果から読み始められます。

計画だけを述べ続ける場合は別の指示で抑える

宣言で止まるのとは別に、曖昧なタスクで選択肢の説明や再検討ばかりが続く症状もあります。同じガイドの「ターンが長くなる」節は、この過剰な計画に対して、動ける情報が揃ったら動くことを求める短い指示を示しています。

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.

末尾の一文のとおり、対象はユーザー向けのメッセージで、thinkingブロックの中の検討は制限されません。

長時間エージェントには依頼の目的も添える

ガイドは、Claude Fable 5が依頼の意図を理解しているほど性能が上がる傾向にあると述べ、特に複数の作業の流れをまたぐ長時間エージェントでは、なぜ頼むのかを書くよう勧めています。示されているひな形は次の1行です。

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

自律パイプラインでは、依頼文の冒頭にこの目的を置き、そのあとに自己点検と停止条件の指示を続ける構成にできます。

対話型セッションでは同じ指示は不要

ここまでの指示は、人が張り付いていない自律パイプライン向けです。自己点検のプロンプトは冒頭で「ユーザーは見ていない」と宣言する作りなので、リアルタイムで会話している場に入れると前提が食い違います。自律パイプラインと対話型でシステムプロンプトを分けるか、実行モードに応じてこの一文を出し分けます。

まとめ

自律パイプラインでは、自己点検の一文と止まってよい3条件をセットで入れ、止まり方をログで数えて効果を見ます。対話型セッションに同じ指示を持ち込む必要はありません。