Claude Fable 5.2 とエージェントのメモリに残った古い注意書き：Anthropic が測定したこと

Anthropic は 11 月 9 日に Claude Fable 5.2 をプロンプトガイドとともにリリースしました。Fable 5.2 は Claude Code 2.1.321 でデフォルトの Fable モデルになりました。ガイドの大部分は effort レベルと読みやすいレポートについてです。ただ、ひとつのセクションは、長く動かしているエージェント環境なら必ずたまっていくものを扱っています。メモリファイル、メモ、指示ファイル、エージェント間のメッセージに残された注意書きです。

ガイドの主張は短いものです。Fable 5.2 はこうした指示を忠実に守るので、必要のない承認を求めたり、ルーチン作業を控えたりすることがあります。初期のテスターの一部がこれを確認しており、その多くは複数のエージェントが協調する環境で使っていました。以下の数字はすべて Anthropic が自社のテストで得たものです。私の読みでは、このテストはガイドの対処法が見落としている問題を示しています。ガイドは理由がもう成り立たない注意書きを削除するよう勧めていますが、ほとんどのメモは理由を書き残していません。

「never retry」を含む古いメモは Claude Fable 5.2 にどれだけ影響するか

Anthropic のシミュレーションタスクでは、以前のセッションから残った 12 件ほどのメモのうち 1 件が「リトライしないこと」と書いていただけで、ツールがビジーだったあとのリトライが、ほぼ毎回から 10 回中 4 回ほどに減りました。プロンプトにはリトライを許可する記述はありませんでした。ビジーなツールは、エージェントが出会う障害の中でもいちばんありふれたものです。そしてメモは、その「never」がこのツールについてなのか、調子の悪かった 1 週間についてなのか、すでに直ったバグについてなのかを書いていませんでした。モデルがそれを区別できる手がかりは、メモのどこにもありません。

なぜ「act more freely」では Claude Fable 5.2 のブレーキが外れないのか

Anthropic のテストでは、一般的な後押しでは何も変わらず、手順を名指ししたときにだけ結果が変わったからです。この設定は最初のものより制約が多く、「never」ルール、メモ、レビュアーの条件がすべてコンテキストにあり、リトライはほぼゼロでした。ルールの最後に、承認不要な手順のひとつとしてリトライを挙げる 1 行を加えると、リトライは約半分まで上がりました。

「もっと気軽に動いて」という広い指示は、すでにコンテキストにある具体的な文と競うことになり、このテストでは負けました。ガイドはこの対処を、繰り返しても安全な呼び出しに限っています。支払いやメッセージ送信のリトライはルーチンではありません。

レビュアーエージェントの停止条件は Claude Fable 5.2 自身の作業に漏れるか

約 3 回に 1 回は漏れます。ある設定では、プロンプトがすでにリトライを承認不要と定めており、レビュアーの「stop at the first error（最初のエラーで止まる）」がコンテキストにありました。Fable 5.2 は約 3 回に 1 回リトライを飛ばしました。Fable 5.1 と Opus 5.5 はリトライしました。

ガイドの助言は、レビュアーエージェントが付け加えるものを確認することです。私はもう一歩踏み込みます。レビュアーは自分のレビューのために条件を書きますが、それがワーカーのコンテキストに入った時点で、出どころを示すものは何も残りません。だから Fable 5.2 は 3 回に 1 回、その条件を自分の作業に当てはめました。これは、レビュアーのプロンプトを調整するだけでなく、レビュアーの出力とワーカーのあいだに何かを挟むべきだという論拠になります。フィルターを挟む形でも、条件ごとに適用範囲を明記する形でもかまいません。

Claude Fable 5.2 では承認の例外をどこに書くべきか

ルールの中です。Anthropic のテストでは、責任者がある手順を承認していました。「never」ルールのもとでは、モデルがその手順を実行したのは約 10 回に 1 回でした。承認済みの手順は実行してよいと書いた別の 1 行は、ほとんど効果がありませんでした。ルールそのものに「先に許可を得ること」と書くと、モデルは約 10 回中 9 回その手順を実行しました。

Separate line:  Never do X.  (...)  An approved step has its go-ahead.
In the rule:    Do X only after a go-ahead from the person in charge.

ガイドはこれらの設定を文章で説明しています。上の 2 行は私による要約で、ガイドの文言ではありません。例外を別の段落に書くと、モデルの前には食い違う 2 つの文が並びます。このテストでは「never」が 10 回中 9 回勝ちました。

Claude Fable 5.2 は承認リストをどこまで文字どおりに読むか

一語一語、書かれたとおりに読みます。承認する人が誰もいないシミュレーションタスクで、あるルールが承認の必要な手順として「sending messages to people outside this conversation（この会話の外の人へのメッセージ送信）」を挙げていました。モデルは同僚や他チームへのルーチンの依頼のおよそ半分を控えました。ガイドの対処法は、ルールが対象とする具体的な行動を名指しすることです。

テストの対象は人へのメッセージでした。私の読みでは、マルチエージェント環境では、別のエージェントへの引き継ぎやステータス通知も、ハーネスがメッセージとして届けるなら同じ表現に含まれてしまうことがあります。表現のどこにも、そうではないとは書かれていないからです。

Claude Fable 5.2 で Anthropic の対処法を使うと、トークンと副作用のコストはどれだけかかるか

対処法もまた指示であり、Fable 5.2 はそれも同じように忠実に守ります。オーナーシップの一文（"This codebase is yours: what it's for and how it's built are your call, and you'll keep building on it."）を入れると、小さなコーディングタスクでモデルが重複コードをまとめた割合は約半分でした。入れない場合は 1 割未満です。同時に出力トークンは約 1.5 倍になりました。モデルは誰も頼んでいないテストやドキュメントを追加し、バグ修正以外で既存機能の動作を変えた割合は 10 回に 1 回から 6 回に 1 回の間でした。ガイドの「タスクを最後までやり切る」テキストは、medium effort で実行可能な作業を残したまま終わったセッションを、記録したセッションの再生テストで半分に減らしましたが、出力トークンは約 30% 増えました。Anthropic がテストしたこのテキストは、リスクのある操作や破壊的な操作では確認を求めることを明示的に残しています。

オーナーシップの例は、注意書きとは逆向きに働きます。同じプロンプトの前のほうに "No drive-by refactors, renames or cleanups" があっても、モデルは約 3 回に 1 回重複コードをまとめました。明示的な禁止が、あとから来た許可に負けたわけです。禁止が勝つというパターンではありません。具体的な文が一般的な文に勝つ傾向があり、両方が具体的なときに何が決め手になるかは、ガイドの数字からはわかりません。

Claude Fable 5.2 の数字のうち検証できるのはどれか

直接検証できるものはありません。ガイドにはタスク数も、タスクの一覧も、ばらつきも載っていません。注意書きのケースで Fable 5.1 や Opus 5.5 と比べた結果も、ひとつの設定から得たものだけです。パーセンテージは、Anthropic のタスクにおける効果の傾向として受け取ってください。自分の環境では違う数字になり、どれだけ違うかを見積もる材料もガイドにはありません。ガイド自身もそう書いています。変更はひとつずつ適用し、その効果とトークンコストを自分の作業で測ること。

Claude Fable 5.2 のメモリにある注意書きが古いと誰が判断するのか

移行前にやることとしてガイドが挙げるのは、理由がもう成り立たない注意書きを削除し、絶対的なルールは適用範囲と理由を書くように書き直し、元のものはコピーを残しておくことです。注意書きの一部はモデル自身が書いたかもしれない、とも指摘しています。この指示は、理由を復元できることを前提にしています。理由が横に書かれていない注意書きでは、持ち主にもモデルにも復元できません。

セッション中のエージェントがリトライを試して、失敗するかどうかを見ることはできます。それでわかるのはツールが今日動くかどうかで、メモが何を防ごうとしていたかではありません。本当に何かを守っていたメモも、古くなったメモと同じ根拠で削除されてしまいます。

CLAUDE.md については、理由はファイルに、経緯は git に残すことが解決策だと書きました。そうすれば git blame で見つけられます。しかしメモリは git で管理されていないことが多く、ページが過去を残せるかどうかは、たまたまどこに置かれているかで決まります。だから理由、適用範囲、日付は、メモを書くときにメモそのものに入れる必要があります。そして書くのはたいていモデルです。エージェントに注意書きを保存させる指示こそ、この 3 つを必須にすべき場所です。

整理には Fable 5.2 ならではの落とし穴もあります。Messages API を直接使う自作コードでは、system、tools、または以前のメッセージが変わったあとに thinking を送り返すリクエストは、デフォルトで 400 を返します。コードが進行中の会話に注入するメモリファイルは、新しい会話でだけ変更するべきです。Claude Code や Agent SDK が組み立てるリクエストは影響を受けません。

メモリ付きのエージェントを動かしているなら、Fable 5.2 が目にするのと同じ形でメモを読んでみてください。どの行もコンテキストに入っていて、どの行にも日付がありません。何を防いでいるのか、誰が解除できるのかを書いた「never」なら外せます。それを書いていないものは、誰かが勘で消すまで残り続けます。