Advisor unavailableエラー — Fableをadvisorにすると出る条件と対処法

Advisorがunavailableになる条件

Claude CodeのAdvisorツールは、advisorModel をFableにした会話で Advisor unavailable (unavailable) を返すことがあります。条件はトランスクリプトの長さではなく、Read・Bashなどの tool_use/tool_result ブロックが会話に1つでも生成されているかどうかです。

Advisorとは、Claude Codeが実行中の会話の要所で、メインモデルとは別のモデルに意見を求めるサーバー側の機能です。GitHub issue #67609として報告されたこの不具合は、当初「トランスクリプトが約10万トークンを超えると失敗する」という説で立てられました。20件のコメントを経た調査の結果、実際の条件は別にあることが分かっています。

最初は「トランスクリプト100Kトークン」説だった

issueの本文を書いた報告者は、claude-fable-5 をリクエストモデル、fable をadvisorに設定したセッションをヘッドレスで二分探索しました。コンテキストが約4万〜7.5万トークンでは成功し、約12.2万トークン以上で失敗する境界を確認しています。メインモデルをOpus 4.8からFable 5へ切り替えた直後から失敗が始まった一方、Opus 4.8をリクエストモデルにしていた間は29.6万トークンでも成功していた、という記録も添えられていました。

報告者vishnutskumarは同一セッション内で条件を1つだけ変える比較を行っています。メインモデルをOpus 4.8に固定し、大きなシステムプロンプトとMCPツールカタログを含む同じトランスクリプトに対して /advisor opus を実行すると成功し、/advisor fable に切り替えると即座に失敗しました。処理に時間がかかるopus側と、処理を試みずに即座に拒否するfable側という応答速度の違いも記録されており、リクエストモデルではなくadvisorモデル側の制限であることを裏付けています。

後続のコメントも同じ傾向を裏付けています。

失敗したAdvisor呼び出しは一度でもエラーになると、以降の呼び出しもエラーを返し続けます。文言は The advisor tool is unavailable. Do not try to use it again. で固定され、複数の報告者がこのラッチ挙動を確認しています(別issue #67411として切り出し済み)。/compact でトランスクリプトを縮めても、このラッチは解除されませんでした。

実際の引き金はtool_useブロックの有無

issueが進むにつれて、トークン数説と矛盾する再現例が出てきます。報告者AliAltivateは、メインモデル・advisorモデル・事前のツール呼び出しの有無・コンテキストサイズを組み合わせたA/Bテストで、次の結果を得ました。

トークン数だけを増やした2行目は成功しています。一方、ツール呼び出しを1回加えただけの3〜5行目は、小さいコンテキストでも失敗しました。advisorがFable以外(sonnet・opus)であれば、同じツール呼び出しがあっても成功する点も一致しています。長いセッションには必ずツール呼び出しが含まれるため、「約10万トークンを超えると失敗する」という最初の見立ては、tool_useブロックが増える傾向と単に相関していただけだった、というのがこの検証の結論です。

Claude CodeのAdvisor公式ドキュメントは、Advisorが「会話全体(すべてのツール呼び出しと結果を含む)を受け取る」と説明しています。tool_useブロックはAdvisorへ渡るペイロードの一部そのものです。Fableをadvisorにした場合だけこのブロックの有無で失敗するのは、サーバー側でのFable advisor固有の処理に起因すると考えられます。ただし、この因果関係そのものをAnthropicが認めた記述は、今回確認できた一次ソースの中にはありませんでした。

公式の対応 — v2.1.210からv2.1.232

公式changelogでは、この不具合に対応する2つの記述が見つかります。

まずv2.1.210で「Fableをadvisorピッカーから一時的に選べなくする」という応急処置が入りました。

Fable temporarily shows as unavailable in the advisor picker while a server-side issue causing Fable advisor failures is fixed

その後のv2.1.232で、Fableアクセス権を持つ組織向けにAdvisorの選択肢としてFableが復帰したことが記録されています。

Fable 5 is offered as an advisor in /advisor again for organizations with Fable access, with usage-credits consent set up through /model fable

公式の週次更新まとめによると、v2.1.202〜206は7月6日〜10日の週にリリースされています。同じく別の週次まとめでは、v2.1.234〜239が8月17日〜21日の週にリリースされたと分かります。v2.1.210とv2.1.232はこの間のリリースにあたるため、応急処置から選択肢の復帰までは、おおむね1か月程度の期間が空いたことになります。

v2.1.232でFableが選択肢へ戻ったことは、サーバー側の問題への対応が進んだことを示す記録です。ただし、issue #67609自体はクローズされておらず、tool_useブロックを引き金とする挙動がこの時点で解消されたと明言するコメントも見つかりませんでした。現在のAdvisor公式ドキュメントの「Requirements」節を見ても、条件はAnthropic APIであること・対応するメインモデルであること・feature flag取得が有効であることの3つだけです。トランスクリプト長やtool_useブロックに由来する制限は明記されていません。

同じ公式ドキュメントの「Common model pairings」節では、Fable main + Fable advisorの組み合わせを「Fableが使える環境での最高性能の組み合わせ」と位置づけています。この不具合はまさにその組み合わせを実運用で使い物にならなくしていた形になります。ドキュメント上の推奨と、issueで報告された実際の挙動が食い違っていた期間があった、と読めます。

今すぐ使える回避策

issueのコメントで確認できた回避策は次の2つです。いずれもissue内の報告者による検証で、Anthropicが公式に案内したものではありません。

export CLAUDE_CODE_DISABLE_ADVISOR_TOOL=1

advisorModelの切り替えは /advisor コマンドから行うのが安全です。settings.jsonを手書きすると、綴りやペアリングの検証が保存時には効きません。結果として、意図しない設定のまま気づかない状態になりやすいためです。

Fableをメインモデルとして使っている場合、advisorをopusやsonnetに変えても「メインより弱いモデルを助言役にする」形になります。advisorの狙いだった「メインより強いモデルの意見を仰ぐ」効果は得られません。この場合の実質的な回避策は、Advisorそのものを諦めるか、Fableを使う場面自体を絞り込むことになります。Fable 5.1のxhigh/maxでmax_tokensに達する既知の制約と合わせて、Fable運用全体の癖として把握しておくと切り分けが早くなります。

関連して報告されている問題

issue #67609のスレッド内では、隣接する問題として2件のissue番号が挙げられています。

• #67411: 一度 unavailable になったセッションで、以降のAdvisor呼び出しがすべて拒否され続けるラッチ挙動を追跡するissue
• #73923: ToolSearch で遅延ロード型のツール定義を1つ読み込んだだけで、小さいコンテキストでもAdvisor呼び出しが即座に失敗する別パターンを報告するissue

どちらも本issueの報告者が「同じサーバー側の拒否クラスに属する可能性がある」と位置づけているものです。tool_use起因の失敗と根が同じかどうかは、本issue単体からは確認できていません。セッションのトランスクリプト長そのものを確認したい場合は、Ctrl+Oトランスクリプトビューアーで現在の会話量を見た上で、Advisorの設定を見直す判断材料にできます。

まとめ

AdvisorがunavailableになるのはFableをadvisorに設定した会話にtool_use/tool_resultブロックが含まれる場合です。トランスクリプトの長さは直接の原因ではありません。公式changelogはv2.1.210で一時的にFableを選択肢から外し、v2.1.232で復帰させています。ただしissue自体はopenのままで、根本原因が解消されたとする明確な記述は見つかっていません。Fableをadvisorとして安定して使いたい場合、現状ではadvisorModelを一時的にopusやsonnetへ切り替えるか、Advisor自体をオフにするかの二択になります。