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

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

長時間の自律セッションの終盤で、Claude Fable 5がツール呼び出しをせずに「これからXを実行します」という文章だけを残してターンを終えることがあります。すでに実行してよい判断材料が揃っているのに、許可を求めて止まるケースも同じ症状です。公式ドキュメントはまれに起きるケースと位置づけていますが、数時間から数日かけて回す自律パイプラインでは、この一度の停止が丸ごとタイムアウトや無駄な待機に直結します。

対処自体はシンプルです。会話が生きているなら「continue」や「go ahead and do it end to end」と一言返せば再開します。問題は、人が張り付いていない自律パイプラインではその一言を誰も打てないことです。

なぜ長時間実行ほど早期停止が起きやすいか

Claude Fable 5は、複雑で長時間・曖昧なタスクをこなす前提で設計されたモデルです。高いeffort設定でのハードなタスクは数分単位で走り、自律実行では数時間に及ぶこともあります。セッションが長く深くなるほど、モデルが「ここで一度確認を取ったほうが安全ではないか」と判断する場面が増えます。これ自体は無茶な暴走を防ぐ健全な挙動ですが、監視役が不在の自律パイプラインでは、確認待ちのまま止まった状態が「失敗」として観測されます。

見分け方は明確です。最後の段落が計画・分析・質問・次のステップの列挙・または「〜します」「〜したらお知らせします」のような未実行の宣言で終わっているなら、それは早期停止です。ツール呼び出しの結果で終わっていれば正常に完了しています。

ハーネス側から見ると、この2つは同じ「テキストでターンが終わった」というイベントとして観測されるため、ログだけでは区別しづらいことがあります。区別を自動化したい場合は、ターン最後のブロックがテキストのみで、かつ本文に「します」「実行します」「確認します」のような未来形の述語が含まれるかを簡易チェックし、該当すれば早期停止候補としてアラートを出す運用が現実的です。

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

公式ドキュメントが提示する回避策は、システムプロンプトに「ターンを終える前に最後の段落を自分で点検させる」指示を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. 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つ目は、ターンを終える直前に自分の最後の段落を読み返させ、それが計画・分析・質問・未実行の約束のいずれかに該当するなら、その場でツール呼び出しに落とし込ませることです。これによって「言うだけで実行しない」状態のままターンが閉じることを防ぎます。

誤爆を防ぐ境界の指示も併用する

早期停止を防ぐ指示だけを入れると、今度は逆に「本当に確認が必要な場面」まで押し切ってしまう懸念が出ます。公式ドキュメントは、いつ止まってよいかを別立てで明示することを勧めています。

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つではありません。症状を切り分けてから対応するプロンプトを選ぶと、無駄な指示の重ね掛けを避けられます。

進捗報告の裏取りとセットで運用する

早期停止の対策だけを入れると、今度は「止まらずに進むが、報告内容が怪しい」という別の問題が表面化することがあります。長時間の自律実行では、ツール呼び出しの結果を確認せずに「完了しました」と報告してしまう挙動が稀に起きるためです。公式ドキュメントは、この2つを必ずセットで運用するよう推奨しています。

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.

「止まらず進める」ための指示と「進んだ結果を正直に報告させる」ための指示は別物です。片方だけを入れると、早期停止は解消したのに進捗報告の信頼性が下がる、という別の穴が開きます。

効き目を弱めがちな実装ミス

早期停止の対策プロンプトを入れても効果が薄いと感じる場合、次の3点を確認します。

1. 指示をシステムプロンプトの奥深くに埋めている: 長い指示リストの末尾に追加すると、他の指示に埋もれて優先度が下がります。自律実行を前提とするタスクでは、冒頭近くの独立した段落として配置します。
2. 「止まってよい3条件」を省いている: 早期停止の抑制だけを入れると、破壊的操作の直前まで確認なしで進めてしまう副作用が出ることがあります。3条件は必ず対で運用します。
3. effort設定を確認していない: 高いeffort設定ほど自律実行の判断が複雑になり、確認を挟みたくなる場面も増えます。ルーチン作業まで高いeffortで回している場合は、タスクの難度に応じてeffortを下げることも早期停止の抑制に寄与します。

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

早期停止と隣接する挙動として、非常に長いセッションで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.

チェックポイント設計と合わせて使う

早期停止の抑制は、Claude Fable 5の指示追従性の高さとセットで理解すると設計しやすくなります。Claude Fable 5は簡潔な指示でも意図を汲み取る精度が上がっているため、想定される挙動を1つずつ列挙するより、原則を1〜2文で渡すほうが効きます。ターン終了前の自己点検プロンプトも、境界の指示も、この「原則を渡す」設計思想の延長線上にあります。

自律パイプラインを組む際は、この早期停止対策をチェックポイント設計・進捗報告の裏取り(ツール結果に基づかない進捗報告をさせない指示)・send-to-userツールの3点セットで導入すると、Claude Fable 5の長時間自律実行が持つ本来の強みを取りこぼしません。send-to-userツールは、途中経過や部分成果物をユーザーに逐語で見せたいときにターンを終えずに呼び出せるツールで、モデル自身の要約に頼らず内容をそのまま届けられます。ただしツールを定義するだけでは呼び出されにくく、システムプロンプト側に「ユーザーが確認すべき内容があるときはこのツールを呼ぶ」という指示を添えて初めて機能します。

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

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

ここで紹介した指示は、人が張り付いていない自律パイプライン向けです。ユーザーがリアルタイムで会話に参加している対話型セッションでは、Claude Fable 5が確認を挟むこと自体は正しい挙動である場面が多く、「操作している人間が不在である」という前提を明示する必要がありません。むしろ対話型セッションにこの指示をそのまま入れると、本来確認すべき場面まで押し切ってしまう副作用が出ます。自律パイプラインと対話型セッションでシステムプロンプトを分けるか、実行モードに応じて該当の一文を出し分ける設計にします。

よくある質問

早期停止はClaude Opus 4.8でも起きるか

公式ドキュメントが早期停止のパターンとして明記しているのはClaude Fable 5です。Claude Opus 4.8は長時間の自律実行を前提とした設計ではないため、同じ症状は出にくいとされています。Opus系からFable 5へ移行する際は、この挙動差分を踏まえてシステムプロンプトを見直す必要があります。

「continue」と一言返す運用ではだめか

会話が生きているセッションなら「continue」の一言で再開でき、応急処置としては機能します。ただし自律パイプラインでは人がその一言を打つタイミングが無いため、根本対策にはなりません。恒久対応はシステムプロンプト側にターン終了前の自己点検を仕込むことです。

まとめ

Claude Fable 5の早期停止は、長時間の自律セッション終盤で「実行を宣言するだけで止まる」「許可を求めて止まる」という2パターンで現れます。対処は、自律実行であることを明示したうえで、ターンを終える前に最後の段落が計画や未実行の約束になっていないかを自分で点検させる一文をシステムプロンプトに加えることです。合わせて「止まってよい3条件」を明示しておけば、誤って確認を省略する副作用も抑えられます。