直ったのは生物分野だけ――Claude Code で Fable 5 の拒否が続く理由

Verdict

• Fable 5が向く人：短い探索的な相談や、結果を人間が確認できる用途で、開けた問いを投げたい人。
• Fable 5が過剰になりやすい人：コード修正、CIデバッグ、リリース自動化、長時間の自律実行など、途中で止まるコストが大きい人。
• 現時点の実務判断：Claude Codeで止めたくない作業は、まずOpus 5を選ぶ。Fable 5を使う場合は、主モデルやadvisorへの固定ではなく、短いセッションで降格・拒否・バージョンを記録しながら試す。

関連記事としては BlogClaude Fable 5 vs Sonnet 5：料金5倍・知能+7点の実測使い分けガイドFable 5とSonnet 5をArtificial Analysisの知能指数・タスク単価・出力量で比較。料金5倍の差を実務の判断材料に落とし込みます。→ もあわせて読むと、今回の論点とのつながりを把握しやすくなります。

8月7日の再調整で、Fable 5の生物分野におけるフォールバックは約85%減りました。ただし、Claude Codeで起きている拒否全体が直ったわけではありません。公式発表が示すClaude Codeの削減率は17%にとどまり、cyberやreasoning_extraction、frontier_llmについては触れられていません。

前回の記事では、ユーザーが仕込んだUserPromptSubmitフックの注入文言が拒否を招く真因だと、実機の二分探索で特定しました。今回はその続報です。前回は自分の手元に犯人がいたから直せましたが、8月の一部の拒否はClaude Code自身が注入する文言と結びついています。

BlogFable 5 が弾かれた本当の理由、MCPでもスキルでもなくフックClaude Code で Fable 5 が毎ターン Opus 4.8 へフォールバックする現象を実機で二分探索。犯人は CLAUDE.md でも MCP でもなく、UserPromptSubmit フックの強制命令調の注入文言でした。→

Anthropicの2026年8月7日の発表では、生物分野の分類器について、判定規則の集合であるconstitutionを書き直し、良性用途を細かく切り出したと説明されています。専門家の意見を取り入れ、更新したデータで再学習し、有害な用途やデュアルユース研究では従来どおり発火することも検証した、という内容です。

この改修によって、生物分野のフォールバックは全体で約85%減りました。しかし面別に見ると、claude.aiは約67%、Coworkは55%、Claude Codeは17%、Claude Platformは7%です。開発者が主に使うClaude Codeは、4つの面の中で削減率が最も小さい。つまり、「Fable 5の拒否問題が85%改善した」という数字を、そのままClaude Codeの体感に置き換えることはできません。

Claude Codeでの削減率は17%にとどまった、というのが読者が持ち帰るべき数字です。

公式発表が対象としているのは生物分野です。virology、toxicology、molecular designでは引き続きフォールバックすると明記されています。一方で、cyber、reasoning_extraction、frontier_llmへの言及はありません。8月にコード作業で再び止まった人が、発表を読んで「自分の設定がまだ悪いのか」と迷うのは、この対象範囲が見えにくかったからだと思います。

なお、6月時点の記事ではフォールバック先がOpus 4.8でしたが、8月7日の公式発表ではClaude Opus 5と記載されています。現在の情報を確認するときは、この二つを混ぜないでください。

2026年8月18日に起票されたissue #87640では、Claude Code 2.1.234で、入力がHiだけでも[reasoning_extraction]の拒否が発火したと報告されています。報告者は、拒否を招いているのは打ち込んだ文言ではなく、読み込まれた文脈だと観察しています。同じセッションの文脈がOpus 5では通り、再試行でも間欠的ではなく再現した、という内容です。2026年8月27日時点でも状態はOPENでした。

ただし、この報告をそのまま「Anthropicの分類器がまだ壊れている証拠」と扱うのは正確ではありません。グローバルとプロジェクトのCLAUDE.md、memory、スキル、MCPなどが同時に読み込まれた環境で、--safe-modeによる切り分けや二分探索までは行われていないためです。これは前回の記事で特定した第1層、つまりユーザー側の注入が残っている可能性を先に疑うべき事例です。

より重要なのが、2026年8月20日に起票されたissue #88364です。この報告では、reasoning_extractionの拒否増加が、Claude Code 2.1.236で入ったクライアント側のbatching reminderと連動することを、版の二分探索と同日の別版との対照で調べています。2026年8月27日時点でも状態はOPENでした。

Claude Codeは、最後のツール結果の直後に、Fable 5向けのメタメッセージを差し込みます。報告で確認された文言は次の形です。

First privately list what you need next; then request every item that doesn't depend on another's result …

「次に必要なものを、まず内側で列挙する」という指示です。Anthropic自身のFable 5向け案内は、内部の推論過程を応答テキストとして説明・転記させる指示がreasoning_extractionを誘発しうるとして、スキルやシステムプロンプトの監査を求めています。その案内に照らすと、今回の文言は分類器が警戒しうる形に近いと言えます。

ここで原因の所在が変わります。前回は、自分のcourt-guard.shが毎ターン注入していた文言を消せばよかった。今回はClaude Codeのクライアントが注入しているため、ユーザーがフックやプロンプトを整理しても、その文言自体は消せません。送信された本文もディスクには残らず、batching_reminder_sentという印だけが残るため、通常のセッションログからは再構成できません。

版の差は明確です。報告者が出荷バイナリ内の文字列を数えた結果、batching_reminderは2.1.235で0件、2.1.236で17件、2.1.237で17件でした。拒否数も、2026年8月20日は1,000応答あたり7.07件で、直前18日間の平常値0.55件から増えています。注入を伴う要求は拒否19・成功43で拒否率30.6%、伴わない要求は拒否0・約2,627成功で0.00%でした。

ただし、報告者自身が「この注入だけで全部は説明できない」と但し書きを付けています。#87273と#87640は2.1.236より前に起票されており、注入が存在する前からreasoning_extractionの過剰発火はありました。また、注入を伴う要求でも拒否は約30%で、注入は実際上必要な条件に見えるものの、十分条件ではありません。この限定は外せません。

今回の確認を踏まえ、私は次の構成を常用から外しました。

• Fable 5をClaude Codeの主モデルに固定する
• Fable 5をadvisorに固定し、長時間の自律実行を任せる
• reasoning_extractionを含む会話を同じセッションで長く継続する
• 拒否が出ても、モデルや注入文言を記録せず再試行だけを繰り返す

これはFable 5の能力を否定する判断ではありません。拒否が明示的なエラーと黙った降格の二つの形で現れ、reasoning_extractionではフォールバック経路まで欠けているためです。失敗したターンを人間がすぐ確認できない作業では、モデルの能力より復旧経路の有無を優先します。

⚠️ 戻し方：まずフック、CLAUDE.md、スキル、MCPを最小構成に戻し、主モデルをOpus 5へ切り替えます。Fable 5を再投入する場合は、長い既存セッションをそのまま再利用せず、文脈を短くした新しいセッションで試します。

拒否の原因は三層に分けると診断しやすくなります。第1層は、フック、CLAUDE.md、スキル、プラグインなど、ユーザー自身がリクエストへ入れている文言です。ここは消せます。前回の記事が特定したのもこの層でした。

第2層は、今回のbatching reminderのようにClaude Code自身が追加する文言です。設定を最小化してもクライアントの版に残っていれば、ユーザーには消せません。第3層はAnthropic側の分類器で、今回の8月7日の改修は生物分野に限られます。ここまで来ると、できるのは状況を記録して修正を待つことです。

自分で確認する順序は、次の三つに絞れます。

1. 通常の対話セッションで、グローバル設定・プロジェクト設定・フック・スキル・MCPを最小構成にする。
2. --safe-modeで同じ入力を試し、結果が変わるかを見る。変わるなら第1層を二分探索する。
3. 変わらない場合はClaude Codeの版を確認し、batching_reminderの有無と拒否発生時刻を記録する。

⚠️ --safe-modeの注意点：通常セッションと読み込まれる設定やワークスペース文脈が異なる場合があるため、通過しただけで「本番構成も安全」とは判断できません。戻すときは、設定を一度に全て戻さず、フック、CLAUDE.md、スキル、MCPの順に一つずつ有効化します。

-pの非対話ワンショットは、前回11回中11回通ったため、今回も診断用のハーネスにはできません。対話モードで、同じワークスペース文脈を持たせた比較が必要です。

私の環境でも2026年8月26日に、手元の出荷バイナリを確認しました。最初にgrep -rで数えたところ、どの版も0件に見えました。しかしELFバイナリを既定のgrepがテキストとして読んでいなかっただけでした。advisorModelやswitchModelsOnFlagを陽性対照として確認したうえで、grep -aを使うと次の結果になりました。

grep -ao "batching_reminder" ~/.local/share/claude/versions/2.1.246 | wc -l

報告から6日後の2.1.246にも文言は残っていました。2.1.246でも文字列を12件確認した、というのがこの実測の結論です。

⚠️ grep -aの限界：-aはバイナリをテキストとして扱うだけで、圧縮・暗号化・難読化された文字列や、別のELF形式、ラッパーから呼ばれる実体までは確認できません。版のパスを取り違えると誤判定にもなります。0件だった場合は「注入がない」と決めつけず、既知の文字列を陽性対照にしてから、実行中の版とファイルの版を照合してください。

この確認はバイナリを書き換える手順ではありません。⚠️ 戻し方：調査後に元の版へ戻す必要がある場合は、出荷バイナリを編集せず、Claude Codeを対象バージョンへ切り替えます。文字列の削除やバイナリの差し替えは、署名・更新・再現性を壊すため行わないでください。

主モデルでFable 5を使う場合、既定のswitchModelsOnFlag: trueでは、拒否の代わりに黙ってOpus 5へ切り替わり、末尾に一文だけ添えられる挙動があります。falseにすると応答が返らず、エラーで止まります。つまり、利用者が見ているのが「断られた」という明示的なエラーではなく、回答品質や口調の変化だけという場合もあります。

⚠️ switchModelsOnFlagの注意点：trueでは処理が続く一方、どのモデルが答えたかを確認しないと品質差を見落とします。falseでは原因の見え方は明確になりますが、拒否時に処理が止まります。調査時は一時的にfalseで明示的なエラーを記録し、通常運用へ戻すときはtrueに戻したうえで、降格をログや末尾表示で確認できるようにします。

reasoning_extractionはさらに扱いが悪い分類です。クライアントのフォールバック経路表はbioとcyberしか覆っておらず、カテゴリ語彙には存在するreasoning_extractionが経路表にありません。そのため既定オフのcatch-allへ落ち、model_refusal_no_fallbackになります。フォールバック先が用意されないため、catch-all用の環境変数を設定しても救えません。

結果として、そのターンは消費され、再試行されず、人手の介入が必要になります。長時間の自律実行では、数時間分の作業を進めたあとに一つの拒否で流れが切れる可能性があります。Fableをadvisorにした場合は主モデル側の降格がadvisorへ伝播しないため、主モデルがOpusへ切り替わってもadvisorが復旧するとは限りません。

第三者のA/B比較では、空のスクラッチプロジェクトではadvisorが成功し、防御セキュリティのリポジトリでは最初のadvisor呼び出しで失敗しました。差はワークスペース文脈でした。なお、issue #67306は2026年8月25日にクローズされていますが、github-actions botによる放置クローズであり、修正済みという意味ではありません。

一方で、拒否された18ターンのうち15ターンが、49秒から21分後に「resume」程度の些細な新しいターンを送ると、同じclaude-fable-5のまま成功しています。これは分類器の判断が安定していないことを示す材料ですが、1回通ったから次も安全という意味ではありません。

今回の不満は、単純に拒否の回数が多いことだけではありません。

• 何が送信されたかを通常ログから復元できない
• 拒否がエラーではなくOpus 5への降格として現れる
• reasoning_extractionではフォールバック経路がない
• 失敗したターンが再試行されず、人手の介入が必要になる
• 版を戻しても、既存セッションの文脈や設定を引き継ぐと比較条件が揃わない

このため、設定を変えて一度通っただけでは改善を確認できません。少なくとも、Claude Codeの版、主モデルとadvisor、ワークスペース、注入の有無、拒否カテゴリ、発生時刻、降格の有無を同じ記録に残す必要があります。

私の環境では、Claude Code 2.1.246、主モデルOpus 5、advisorをFable 5にした状態で、分類器やcyber、reasoning_extraction、拒否について長く議論した会話を1回実行しました。発火せず、advisorも通常どおり応答しました。

しかしこれはn=1の観察です。#88364では、平常時の拒否が1,000応答あたり0.55件、不調日の拒否が7.07件でした。間欠的な現象では、緑の結果が一つ出ても、設定の問題や分類器の問題を否定できません。自分の環境で再現しなかったことは、「その条件では、その回は通った」と記録するにとどめるべきです。

⚠️ 再現テストの戻し方：検証用に設定を最小化した場合は、本番のフックやMCPを一度に戻さず、構成要素ごとに復元します。セッションを使い回すと過去の文脈が混ざるため、比較ごとに新しい対話セッションを作るほうが判断しやすくなります。

Fable 5の価格は入力100万トークンあたり10ドル、出力50ドルです。Opus 5は入力5ドル、出力25ドルで、Fable 5の半額です。Fable 5は30日のデータ保持が必須で、ゼロデータ保持の組織では利用できません。Priority TierはFable 5にありますが、Opus 5にはありません。

Fable 5は思考の無効化ができず、無効化を指定すると400が返ります。Opus 5はeffortがhigh以下なら思考を無効化でき、Fast modeもあります。開けた問い、探索、創作をFable 5に任せる余地はありますが、コード修正や限定的なリファクタのように仕様があり、途中で止まるコストが大きい作業では、Opus 5のほうが運用上の説明をしやすい場面があります。

以前の「Claude Fable 5 vs Sonnet 5」の記事は、比較相手がSonnet 5です。Opus 5は2026年7月24日に公開された後発モデルなので、あの記事の差分をそのままOpus 5との比較に読み替えないでください。なお、この記事本文にはOpus 5の公開日を確認できる公式URLは掲載していないため、この日付自体を一次情報リンク付きの確認結果として扱うのではなく、記事内の比較前提として扱います。

Fable 5は探索用、Opus 5は止めたくない実務用

私なら、Claude CodeでFable 5を主モデルやadvisorに固定する運用は避けます。理由はモデルの能力差ではなく、拒否が明示的な失敗と黙った降格の二つの形で現れ、reasoning_extractionではフォールバック経路まで欠けているからです。

探索的な相談を短いセッションで行い、結果を人間が確認できるならFable 5を試す余地はあります。リリース自動化、CIデバッグ、長時間の自律実行のように一ターンの失敗が後工程へ波及する作業では、Opus 5を先に選ぶほうが妥当です。Fable 5を使う場合も、1回成功したことではなく、降格の有無、バージョン、拒否カテゴリ、注入の発生をログに残してください。

今回の実務的な結論は、Anthropicの改修を待つ前に、自分の注入を疑うことです。それで直らなければ、Claude Code 2.1.236以降のクライアント注入という第2層を疑います。そこから先は設定をいじり続けても消せない問題です。8月7日に直ったのは生物分野の一部であり、Claude CodeでFable 5が止まる引き金まで消えたわけではありません。

• BlogClaude Fable 5 vs Sonnet 5：料金5倍・知能+7点の実測使い分けガイドFable 5とSonnet 5をArtificial Analysisの知能指数・タスク単価・出力量で比較。料金5倍の差を実務の判断材料に落とし込みます。→
• BlogAnthropicリーク2連発：Claude MythosとClaude Code流出で見えたKAIROS、BUDDY、Undercover Modeの正体Anthropicの2週間で2回のリークを整理。Claude Mythosの位置づけ、Claude Code流出の中身、KAIROS/BUDDY/Undercover Modeの意味を分けて読む。→
• BlogClaude Code の新effortモード徹底解説｜max・ultracode・autoと『呪文ultrathink』の正体Claude Code の /effort に増えた max・ultracode・auto と、プロンプトに紛れ込ませる呪文 ultrathink を、公式が明言した『ultracode は API の effort レベルではない』を起点に解剖。overthinking・自律ワークフロー・永続性と優先順位の罠まで、誤解されやすい論点を一次情報で正します。→

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です！エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします！