Claude Media
Fable 5がsetup-token利用時に使用量クレジットを要求される原因と対処法
Claude CodeClaudeTips

Fable 5がsetup-token利用時に使用量クレジットを要求される原因と対処法

Claude Codeのclaude setup-token認証でFable 5選択時に出る使用量クレジット要求ダイアログの原因と、Maxプランのまま回避する設定方法をまとめます。

読了目安 約9分

claude setup-tokenで発行した長期OAuthトークンをCLAUDE_CODE_OAUTH_TOKENとして使うと、Maxプランのアカウントでも/modelでFable 5を選んだ瞬間に「使用量クレジットで続行しますか」という同意ダイアログが出ることがあります。実際に課金される設定ではなく、setup-tokenのスコープ制限でクライアント側がプランの権限を確認できないことが原因です。セッションを再起動しても、トークンを発行し直しても直りません。

setup-token認証だけこの表示が出る理由

原因はGitHub Issue #79360の調査で特定されています。claude setup-tokenが発行するトークンはuser:inferenceスコープしか持たず、プランの権限を読むエンドポイントが軒並み403を返すため、クライアントは「このアカウントはFable 5を含むプランか」を確認できません。確認できないときのフォールバックとして、使用量クレジットでの続行を求めるダイアログが出る設計です。

エンドポイントレスポンス
GET /api/oauth/usageレスポンス403「user:profileスコープを満たさない」
GET /api/oauth/claude_cli/rolesレスポンス403「user:profileスコープを満たさない」
GET /api/oauth/profileレスポンス403「user:profileまたはuser:officeスコープを満たさない」

一方でサーバー側の権限判定自体は正しく機能しています。Issue報告者が同じトークンでPOST /v1/messagesにmodel: claude-fable-5を直接指定したところ、通常どおり成功しました。つまりアカウントはFable 5を利用できる権限を持っており、ゲートはクライアント側だけで起きている問題です。

Fable 5が使用量クレジット対象になった経緯

この問題が表面化した背景には、2026年7月20日のFable 5権限変更があります。Issue報告者によれば、この変更でFable 5はMaxプランの週次利用枠の50%を上限として初めてプランに組み込まれました。プランに含まれる枠か、含まれず使用量クレジットが必要かをクライアント側が都度判定する必要が生じたのはこの変更以降で、setup-tokenのスコープ不足が実害として表面化したタイミングとも重なります。Issue自体も同日以降に報告が集中しており、権限変更前は同じ判定が発生していなかった、または別の扱いだった可能性があります。

関連するIssueとの関係

同種の症状を報告しているIssueは#79360だけではありません。#76237は「Fable 5がMaxプランで一覧に出ない」、#74051は「Fable 5がプランの利用枠を無視して使用量クレジットを求める」、#22450は「setup-tokenが/usageに必要なuser:profileスコープを持たない」という報告で、いずれもsetup-tokenの認証スコープとプラン判定ロジックの間にあるギャップに起因しています。個別の一過性のバグというより、setup-token認証の設計そのものに起因する構造的な症状群として見たほうが実情に近いといえます。

回避策が確立するまでの流れ

Issueのコメント欄では、根本原因の特定より先に回避策が先行して共有されています。報告翌日の7月21日には、別のAIツールを使ってパッチを見つけたという最初の回避策がWindows向けに共有され、同日中にLinux向けの派生版も投稿されました。7月22日にはOpus 4.8を使ってv2.1.217でも同じ回避策が機能したという報告が続きます。転機になったのは7月27日の投稿で、ダイアログの判定ロジックがsubscriptionTypeを環境変数から読む実装になっている点を突き止め、CLAUDE_CODE_SUBSCRIPTION_TYPEを使う現在主流の回避策が共有されました。この方式は初期の手作業パッチと違い、トークンの再発行や/loginへの切り替えを必要としません。8月17日にAnthropicのエンジニアが根本原因の分析が正しいと確認し、翌日には環境変数方式がv2.1.222からv2.1.235まで継続して有効だったという追加の実地報告が寄せられています。

認証方法によって挙動が変わる

同じ「使用量クレジットを求められる」現象でも、認証方法によって再現性と回復方法が異なります。

認証方法ダイアログの発生再起動での回復
対話ログイン(/login)ダイアログの発生出ることがある再起動での回復回復する
claude setup-token(CLAUDE_CODE_OAUTH_TOKEN)ダイアログの発生出る再起動での回復回復しない。トークンの再発行も無効
ANTHROPIC_API_KEYダイアログの発生対象外再起動での回復従量課金のためこのダイアログ自体が出ない

対話ログインのセッションで再起動が効くのは、/loginのたびにプランの権限情報を取り直せるためです。setup-tokenのセッションは権限情報を取得する手段自体を持たないため、再起動しても同じ結果になります。

なお、この同意ダイアログが出るのは対話セッションに限られます。ドキュメントによると、-pフラグを使った非対話実行やAgent SDK経由のセッションでは、この確認プロンプト自体が表示されず、使用量クレジットへの課金が必要な場合は確認なしにそのまま課金される仕様です。CIでsetup-tokenを-p実行にだけ使っている場合、対話セッションで報告されているこのダイアログ自体には遭遇しない可能性がありますが、その場合の課金判定がサーバー側の正しい権限情報に基づくのか、対話セッションと同じクライアント側の制限を引き継ぐのかは説明がありません。

Anthropicが確認している範囲

Anthropicのエンジニアは2026年8月17日、Claude Code 2.1.233での検証を踏まえてこのIssueにコメントし、報告されている根本原因の分析が正しいことを確認しました。バグとして分類したうえで、直前のリリースで修正された「ログインが期限切れのセッションでサブスクリプション階層を無視して機能フラグを評価してしまう」問題(この修正は2.1.227で入っています)は、setup-tokenのケースを救わないとも説明しています。setup-tokenのトークンは構造上プラン階層の情報を一切持たないため、期限切れログインの修正とは別の対応が要る、という位置付けです。

検討中の方向性は2つ提示されています。ひとつはsetup-tokenのスコープを広げてプラン情報を読めるようにする案、もうひとつはクライアント側でのゲートをやめてサーバー側の判断に委ねる案です。コメント時点での暫定的な回避策は対話ログイン(/login)の利用でした。取得できたchangelog(v2.1.278まで)を確認した範囲では、setup-token特有のスコープ問題を名指しした修正エントリはまだ見当たりません。

似た見た目のエラーとして、エラーリファレンスはOAuth token does not meet scope requirement: user:profileというメッセージを「保存済みのトークンが新しい権限スコープより古いケース」として扱っており、対処は/loginでトークンを取り直すことだと案内しています。ただしこれはトークンが発行された後にスコープ要件が追加された場合の話で、setup-tokenのように最初からuser:inferenceのみを要求する認証方式とは性質が異なります。setup-tokenでは/loginをやり直しても、次の新規セッションでCLAUDE_CODE_OAUTH_TOKENが再び読み込まれるため、恒久的な解決にはなりません。

setup-tokenを維持したまま回避する設定

Issueのコメント欄で確認された回避策は、プランの種別をクライアント側の環境変数で直接宣言する方法です。ダイアログの判定ロジックが、トークン使用時はsubscriptionTypeを環境変数から読む実装になっているため、正しい値を渡せば権限チェック自体をスキップできます。

export CLAUDE_CODE_OAUTH_TOKEN=your-token
export CLAUDE_CODE_SUBSCRIPTION_TYPE=max
export CLAUDE_CODE_RATE_LIMIT_TIER=default_claude_max_20x

CLAUDE_CODE_RATE_LIMIT_TIERは自分の契約に合わせてdefault_claude_max_20xかdefault_claude_max_5xを指定します。この値自体は/upgradeの案内文にだけ影響し、ダイアログの回避に効くのはCLAUDE_CODE_SUBSCRIPTION_TYPE=maxの指定です。シェルでのexportの代わりに、設定ファイルのenvブロックに置くこともできます。

{
  "env": {
    "CLAUDE_CODE_SUBSCRIPTION_TYPE": "max",
    "CLAUDE_CODE_RATE_LIMIT_TIER": "default_claude_max_20x"
  }
}

コメント欄では、この2つの環境変数だけでv2.1.222からv2.1.235まで複数バージョンにわたってFableが選択可能な状態を維持できたとされています。ただし一部の2.1.224以降のビルドでは、環境変数を設定した結果ダイアログの代わりに/modelからFableの行そのものが消えるケースも報告されています。その場合は、ドキュメントに記載のあるANTHROPIC_CUSTOM_MODEL_OPTIONとその関連変数(_NAME・_DESCRIPTION)でカスタムモデルの行として追加し直すと、ピッカーに戻せます。

よくあるつまずき

  • 再起動しても直らない: setup-tokenのトークンはuser:inferenceスコープしか持たないため、何度再起動してもプラン階層の情報を取得できません。対話ログインの再起動とは仕組みが違います
  • 新しいトークンを発行しても同じ: claude setup-tokenを再実行して新しいトークンを作っても、発行されるスコープ自体は変わらないため、同じ制限を引き継ぎます
  • /usageのプラン枠バーが表示されない: これも同じuser:profileの403が原因です。setup-tokenのセッションでは限界に対応するゲージ自体が描画できないため、claude.aiのSettings > Usageで確認する必要があります。ただしこの方法は、契約しているメールアドレスに日常的にアクセスできない委任利用のケースでは使えません。setup-tokenが選ばれる場面はまさにそうした委任利用が多く、Issueのコメント欄でも同じ事情を挙げる報告が複数あります
  • /usageに表示される金額を請求だと誤解する: 表示される金額は従量課金なら発生していたはずの参考値で、サブスクリプションでまかなわれている限り実際の請求は発生しません。この点はClaude Codeのドキュメントも「見積もりであり実際の請求と異なることがある」と明記しています

まとめ

claude setup-tokenでCIやスクリプトを組んでいるMaxプランの利用者が主な対象です。現状ではsetup-token側の構造的な制限が原因のため、待っていて直る性質の不具合ではありません。今すぐ回避したい場合はCLAUDE_CODE_SUBSCRIPTION_TYPEとCLAUDE_CODE_RATE_LIMIT_TIERを契約プランに合わせて設定し、恒久的な修正を待つ場合はIssue #79360をウォッチしておくと、対応バージョンがわかります。使用量クレジット自体の仕組みはClaude利用クレジットの購入・管理方法、似た「権限チェックで止まる」パターンはUsage credits required for 1M contextの意味と対処で扱っており、あわせて見ておくと切り分けが早くなります。Fable 5がMaxプランの中でどう位置付けられているかはClaude Opus 5の登場、他のCLAUDE_CODE_*環境変数でコストを制御する方法はClaude Codeの--max-budget-usdでAPI課金額に上限を設けるに整理があります。

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

関連する記事

Claude Code をもっと見る →