Claude Media
Claude Fable 5が新しいセッションを勧めてくる原因と対処

Claude Fable 5が新しいセッションを勧めてくる原因と対処

長いセッションでClaude Fable 5が新セッションや要約での引き継ぎを勧める原因は、ハーネスが見せる残りトークン数のカウントダウンです。表示を外す方法と、外せないときの一文を解説します。

新セッションの提案が出る原因は残量カウントダウン

Claude Fable 5は、非常に長いセッションの途中で「新しいセッションを始めませんか」と勧めたり、要約して引き継ぐと申し出たり、自分の作業を切り詰めたりすることがあります。Anthropicのプロンプトガイドはこれを「まれなケース(rare cases)」とし、最も多い引き金を、ハーネスがモデルに見せる残りトークン数のカウントダウンだと書いています。

対処は2つあります。

  • 残量の数字をモデルに見せない
  • 見せざるを得ないときは、文脈は十分残っていると一文で伝える

コンテキストが足りなくなっていない場合が多い点が肝です。数字を見たモデルが、余裕があるうちから店じまいの姿勢に入ることがあります。

数字はどこから来るのか

Fable 5自身は、残量を自動では知りません。コンテキストウィンドウのページによると、APIが残量タグ(token_budgetとsystem_warning)を差し込むのは、Claude Sonnet 5やSonnet 4.6など一部のモデルだけです。Claude Fable 5、Fable 5.1、Mythos 5、Opus 4.7以降のOpus、Sonnet 5.5、Haiku 5.5には、このタグは差し込まれません。

つまりFable 5で残量の数字がモデルに届いているなら、経路は自分たちの側にあります。確かめる場所を表にします。

経路数字が入る場所見分け方
自作ハーネスのプロンプト数字が入る場所システムプロンプトや各ターンの追記文見分け方「残り◯◯トークン」のような文字列がリクエストに入っている
ツール結果への付記数字が入る場所ツールの戻り値の末尾見分け方ツールが使用量を毎回返している
task budget(ベータ)数字が入る場所APIがサーバー側で差し込むカウントダウン見分け方output_configにtask_budgetを指定している
他モデル向けの流用数字が入る場所Sonnet 5向けに書いた残量の扱いを足した文見分け方プロンプトにtoken_budgetの扱いが残っている

task budgetについては、モデルが実行中のカウントダウンを見て優先順位をつけ、予算が減るにつれて切り上げると説明されています。ただしFable 5のガイドが名指しで挙げている引き金は「ハーネスが見せるカウントダウン」で、task budgetでこの提案が増えるかどうかは、どちらのページにも書かれていません。task budgetを使っているなら、それを外した比較で確かめます。

診断の順序

切り分け

新セッションの提案が出たときの切り分け

  1. Qリクエストの中に、残りトークン数の文字列が入っているか?
    答えが入っている

    システムプロンプトやツール結果から数字を除きます。外せないなら、次の節の一文を添えます。

    答えが入っていない
  2. Qtask_budgetを指定しているか?
    答えが指定している

    予算の大きさがタスクに対して小さすぎないかを見ます。小さすぎる予算は、早めに止まる原因になります。

    答えが指定していない

数字の経路が無い

提案が出た直前の会話を保存し、何が起きたかを読み直します。コンテキスト以外の要因を疑う段階です。

対処1残量の数字をモデルに見せない

ガイドの第一の指示は、明示的なコンテキスト予算の数字をなるべく見せないことです。ログや画面に残量を出す用途と、モデルに渡す用途は分けられます。

人間向けの表示とモデル向けの入力を同じ文字列にしていると、数字を外した途端に画面表示も消えます。表示は別経路にして、モデルへ送る文面からだけ除きます。

前と後

残量表示の置き場所

BEFORE

モデルにも数字を送る

各ターンの末尾に「Remaining: 120000 tokens」のような行を足してモデルへ送る。

AFTER

数字は画面とログだけに出す

使用量は自分のログと画面に出し、モデルに送る文面からは除く。

対処2見せるなら一文で抑える

予算を渡す必要があるハーネス(予算に応じて動作を変える設計など)では、ガイドが示す一文をシステムプロンプトに添えます。

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

この文は、文脈が十分あると伝える部分と、止まる・要約する・新セッションを勧める行動をとらないよう求める部分でできています。事実と異なる安心を与える文ではないので、本当に余裕があるときだけ使います。余裕が少ない場面では、後述の引き継ぎの設計と併せて考えます。

検出のしかた

ハーネスで提案を検知しておくと、増減が数えられます。ターン終了時の最後のテキストに、新セッションや引き継ぎを匂わせる語があるかを調べる素朴な判定です。

import re
 
PATTERN = re.compile(
    r"(new session|fresh session|start a new|hand ?off"
    r"|summariz\w+ (?:and|so)|running low on context)"
    r"|(新しいセッション|新規セッション|引き継ぎ"
    r"|要約して(?:から|引き継)|コンテキスト(?:が|の)(?:残り|不足))",
    re.IGNORECASE,
)
 
def suggests_wrapup(message: dict) -> bool:
    if message.get("stop_reason") != "end_turn":
        return False
    texts = [b["text"] for b in message.get("content", []) if b.get("type") == "text"]
    return bool(texts) and bool(PATTERN.search(texts[-1]))

3つの応答例にかけると、次のように判定されます。

新セッションを提案: True
英語で引き継ぎを提案: True
通常の完了報告: False

これは語の有無で当たりをつけるだけの判定です。ユーザーが「新しいセッションで試したい」と書いた文脈の引用などにも反応するので、アラートや自動介入の前段に置き、数を比べる用途に向きます。対処の前後で、同じ種類のタスクを同じ長さだけ回し、提案の回数を比べます。

実際に埋まるまでの距離

提案が出たとき、コンテキストは本当に埋まりかけているのでしょうか。Fable 5のコンテキストウィンドウは1Mトークンで、これが既定です。ベータヘッダーは要らず、1回のリクエストで生成できる出力は最大128kトークンです。

一方で、Fable 5は過去のターンのthinkingブロックをAPIが既定で保持し、これも他の入力と同じようにコンテキストに数えられます。数時間続く自律実行では、ツール結果と思考が積み重なっていきます。だから長いセッションで残量の表示が出ると、数字が小さく見えやすい場面が実際にあります。

ここで区別したいのは、数字が小さいことと、提案が妥当なことは別だという点です。残りが少なくなったら、モデルに止まらせるのでなく、compactionやメモで続けられる構成を用意します。モデルに伝える内容は、実態に合わせます。

本当に余裕が少ないときは

一文で抑えてよいのは、実際に余裕があるときです。コンテキストが埋まりかけているなら、引き継ぎの設計を先に作ります。

  • サーバー側のcompaction: 入力トークンが指定の閾値に達したとき、APIが古い部分を要約します。閾値の決め方はCompactionの発動しきい値の決め方で扱っています。
  • メモ書きの場所: 教訓や状況を1つのMarkdownファイルに残させます。ガイドも、前回の学びを記録して参照できる環境でFable 5がよく働くとしています。Claude Fable 5のメモリシステムに仕組みをまとめています。
  • 予算を渡す場合: task budgetが小さすぎると、課題に取りかからない、範囲を絞り込む、途中結果で止まる、といった振る舞いが出ることがあるとされています。最小値は20,000トークンで、それ未満は400エラーです。

なお、compactionを使う自作のハーネスでtask budgetも併用するなら、remainingの渡し方に注意が必要です。全履歴を毎回送り直す設計でremainingも自分で減らすと、モデルには実際より少ない残量が見え、カウントダウンが速く進んで早めの切り上げにつながると注意されています。仕組みはtask_budgetのremainingでcompaction後の予算を引き継ぐ方法にまとめています。

compactionがあるハーネスで伝えておくこと

ガイドの対処は、数字を隠すか、安心の一文を添えるかです。もう1つの考え方が、同じプロンプトガイドの別の節にあります。コンテキストを圧縮したり、外部ファイルに保存したりできるハーネスでは、そのことをプロンプトに書いておくと、モデルが上限に近づいて自然に仕事を畳みにいく挙動を減らせる、という趣旨の節です。

示されているサンプルは、コンテキストウィンドウが上限に近づくと自動で圧縮され、作業を続けられる、だから予算の心配で早めに止めない、という内容です。ただしこの節は、残量を追跡するモデル(Sonnet 5など)の説明として書かれています。Fable 5にそのまま当てはめた記述ではありません。

Fable 5で使うなら、実際にcompactionが動く構成のときだけ、同じ趣旨の1〜2文を足す形が自然です。言い回しは自分のハーネスの実態に合わせ、動かない仕組みを動くと書かないようにします。

早期停止との違い

同じガイドには「早期停止」の節もあり、ターンを「これからXを実行します」で閉じる、必要のない許可を求める、といった症状が別に書かれています。見分けは、提案の中身です。

症状提案の中身引き金として挙げられているもの効く指示
早期停止提案の中身未実行の宣言や許可の質問引き金として挙げられているもの長いセッションの深い段階効く指示ターン終了前の自己点検と止まってよい条件
残量起因の提案提案の中身新セッション、要約しての引き継ぎ、作業の切り詰め引き金として挙げられているものハーネスが見せる残りトークンのカウントダウン効く指示数字を見せない、または余裕があると伝える一文

両方が出るなら、指示も両方入れます。早期停止の指示の書き方はClaude Fable 5の早期停止をプロンプトで防ぐ方法にあります。

予算を渡す設計の落とし穴

task budgetはあくまで助言的な上限で、強制ではありません。実行を止める上限は引き続きmax_tokensです。この性質はtask_budgetは強制上限でなくadvisoryという性質で整理しています。予算を使うかどうかは、次の2点で決めます。

  • 費用や所要時間に上限を置きたいか(置きたいなら予算が役立つ)
  • 長い連続作業を途切れなく進めさせたいか(進めさせたいなら、数字を見せない構成が先)

後者の用途で予算を渡すと、今回の症状を自分で呼び込む形になる場合があります。どちらを優先するかは、運用ごとに決めます。

まとめ

新セッションの提案を減らす近道は、残量の数字をモデルへ送らないことです。送る必要があるなら、文脈は十分あると一文で添えます。Fable 5にはAPIが残量タグを差し込まないので、数字の経路は自分のハーネスかtask budgetにあります。そこを洗い出すのが最初の作業です。

この記事を共有:XはてブLinkedIn