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

こんにちは。宿題を最終週にまとめて片づけるように、溜めていた作業を AI にまとめて任せたくなる時期ですね。ところが、その任せた作業が途中で止まる。今回はその話です。

8月7日の再調整で、Fable 5 の生物分野でのフォールバック（安全のための判定に引っかかり、別のモデルに回されたり断られたりすること）は約85%減りました。ただ、Claude Code で起きている拒否全体が直ったわけではありません。公式発表が示す Claude Code での削減率は17%にとどまり、cyber や reasoning_extraction、frontier_llm については触れられていません。私の判断は、Claude Code で止めたくない作業はまず Opus 5 を選ぶ、です。Fable 5 は、短い探索的な相談や、結果を人間がすぐ確かめられる用途で開けた問いを投げるなら向いています。逆に、コード修正、CI デバッグ（自動テストの失敗の調査）、リリース自動化、長時間の自律実行のように、途中で止まるコストが大きい作業には過剰になりやすい。使う場合も、主モデルや advisor に固定するのではなく、短いセッションで降格・拒否・バージョンを記録しながら試すのがよいと考えています。

前回の記事では、ユーザーが仕込んだ UserPromptSubmit フック（入力を送るたびに自動で文言を差し込む仕掛け）の注入文言が拒否を招く真因だと、実機の二分探索で特定しました。今回はその続報です。前回は自分の手元に犯人がいたから直せましたが、8月の一部の拒否は Claude Code 自身が注入する文言と結びついています。前回の記事：Claude Fable 5 が弾かれた本当の理由、MCPでもスキルでもなくフックと、料金と賢さの差を測った Claude Fable 5 vs Sonnet 5：料金5倍・知能+7点の実測使い分けガイド もあわせて読むと、今回の論点とのつながりが見えやすくなります。

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

この改修で、生物分野のフォールバックは全体で約85%減りました。ところが面別に見ると、claude.ai は約67%、Cowork は55%、Claude Code は17%、Claude Platform は7%です。開発者が主に使う Claude Code は、4つの面の中で Claude Platform（7%）に次いで削減率が小さい。「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 バイナリ（Linux の実行ファイル）を既定の 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 が止まる引き金まで消えたわけではありません。

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