Claude Media
Claude Codeのfast modeがゲートウェイ経由で使えない原因と回避策

Claude Codeのfast modeがゲートウェイ経由で使えない原因と回避策

LLMゲートウェイやプロキシ越しで/fastが使えないとき、可用性チェックの宛先とメッセージから原因を切り分け、2つの環境変数でどちらを使うか判断します。

LLMゲートウェイ越しでClaude Codeを使っていて、推論は動くのに/fastだけが「Fast mode unavailable due to network connectivity issues」と返す。組織でfast modeを有効にしていても、リクエストは標準速度のままです。原因は、fast modeの可用性チェックがゲートウェイを通らないことにあります。

回避に使う変数は2つあります。CLAUDE_CODE_SKIP_FAST_MODE_NETWORK_ERRORSとCLAUDE_CODE_SKIP_FAST_MODE_ORG_CHECKです。どちらを入れるかは、/fastが返すメッセージと、チェックがどこで失敗しているかで決まります。

fast modeの可用性チェックはどこへ向かうのか

Claude Codeは、fast modeを提示する前に、組織のfast mode可用性をapi.anthropic.comへ直接問い合わせます。この問い合わせはANTHROPIC_BASE_URLに従いません。

そのため、Claudeの通信をLLMゲートウェイに集約し、api.anthropic.comへの直接の外向き通信を塞いでいるネットワークでは、推論が通ってもチェックだけが失敗します。

一方、チェックは設定済みのHTTPプロキシには従います。失敗するのは、プロキシ経由でもapi.anthropic.comに届かない場合だけです。過去に成功したチェックはキャッシュされて有効なままなので、影響が目立つのは新規インストールです。

ゲートウェイ全体の設計はClaude Code LLM gatewayとは、接続手順はLLMゲートウェイへの接続方法にあります。ここではfast modeのチェックだけを扱います。

表示されるメッセージから原因を切り分ける

/fastの表示は、原因によって2種類に分かれます。同じ接続不良メッセージでも、ネットワークが塞がれているとは限りません。

/fastの表示原因効く対処
Fast mode unavailable due to network connectivity issues原因api.anthropic.comへの直接通信が拒否される効く対処許可リストに追加、またはSKIP_FAST_MODE_NETWORK_ERRORS=1
同上(開放ネットワーク)原因ゲートウェイ発行の鍵をチェックに添えて送り、Anthropicが拒否した効く対処SKIP_FAST_MODE_NETWORK_ERRORS=1のみ
Fast mode has been disabled by your organization原因ANTHROPIC_AUTH_TOKENだけで認証しており、チェック自体が送られない効く対処SKIP_FAST_MODE_ORG_CHECK=1
同上原因TLS検査プロキシがブロックページ(HTTP 200)を返し、無効の応答と読まれる効く対処SKIP_FAST_MODE_ORG_CHECK=1
Fast mode is currently unavailable原因CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICがチェックを止めており、成功したキャッシュもない効く対処どちらのskip変数でも復旧

2行目の落とし穴は、鍵の出どころです。ANTHROPIC_API_KEYやapiKeyHelperが返すのがゲートウェイ発行の鍵だと、チェックはその鍵でapi.anthropic.comに届きます。Anthropicは知らない鍵を拒否し、その拒否が接続不良として表示されます。何も塞がれていないので、許可リストを足しても直りません。

3行目も同じくらい紛らわしい点です。ANTHROPIC_AUTH_TOKENだけで動かしていると、claude.aiのログインもAnthropicのAPIキーもありません。この状態でキャッシュもなければ、Claude Codeはリクエストを送らずに「組織が無効にしている」と扱います。

2つの変数の使い分け

NETWORK_ERRORSは「失敗したチェックを通す」

CLAUDE_CODE_SKIP_FAST_MODE_NETWORK_ERRORS=1は、失敗したチェックを「利用可能」として扱います。ただし「組織が無効にしている」という応答が返ったときは、その応答に従って無効のままにします。

使いどころは、ネットワークが接続を拒否する場合と、Anthropicがゲートウェイ発行の鍵を拒否する場合です。

ORG_CHECKは「チェックそのものを飛ばす」

CLAUDE_CODE_SKIP_FAST_MODE_ORG_CHECK=1は、チェックを丸ごと省きます。ネットワークが接続を拒否するのではなく、リクエストを横取りして別の応答を返すときに使います。

横取りされた応答を無効の返事と読んでしまうため、NETWORK_ERRORSでは効きません。この変数は「失敗したチェック」だけを通すもので、無効という応答は失敗ではないからです。ANTHROPIC_AUTH_TOKEN単独の構成も同じ理由で、ORG_CHECKが必要です。

迷ったときの目安は次のとおりです。

  • 接続不良のメッセージが出る: まずNETWORK_ERRORS
  • 「disabled by your organization」が出るのに組織では有効: ORG_CHECK
  • 両方を同時に入れた場合の挙動は、公式に記載がありません。片方ずつ試すと原因を確定できます

設定例

環境変数として渡すなら、シェルで次のようにします。

export CLAUDE_CODE_SKIP_FAST_MODE_NETWORK_ERRORS=1
claude

チーム全体に配るなら、~/.claude/settings.jsonやmanaged settingsのenvブロックに書く形が使えます。ゲートウェイの認証情報を配る場所と同じ階層に置けます。

{
  "env": {
    "CLAUDE_CODE_SKIP_FAST_MODE_ORG_CHECK": "1"
  }
}

一般的なゲートウェイの配布手順と、この2変数が環境変数の一覧でどう位置づけられるかは、Claude CodeのLLMゲートウェイをロールアウトする手順が扱っています。プロキシ側の許可ドメインはClaude Codeプロキシ設定にあります。

変数を入れても直らないケース

skip変数が消すのはクライアント側のチェックだけです。組織でfast modeが無効なら、APIがfast modeのリクエストを拒否します。変数を設定していても、この拒否は覆りません。

拒否されると、Claude Codeはそのリクエストを標準速度で再送し、fast modeをオフにします。/fastは組織が無効にしていると報告します。

次の状態は、そもそもこの2変数の守備範囲外です。

  • 組織でfast modeが有効化されていない(Team・Enterpriseは既定で無効。Ownerが有効化する)
  • managed settingsでfastMode: falseが設定されている
  • fastModePerSessionOptIn: trueが設定され、対話的な端末セッション以外で/fast onを実行している
  • availableModelsの許可リストが、fast mode対応のOpusモデルを除外している
  • Amazon Bedrock・Google Cloud・Microsoft Foundry・Claude Platform on AWS経由の利用(fast modeは非対応)
  • Consoleの組織で、fast modeのアクセスが未プロビジョニング(APIが各リクエストを429で拒否し、Claude Codeはレート制限として扱う)

最後の項目は、クールダウンで解ける通常のレート制限と違い、アクセスが付与されるまで拒否が続く点が特徴です。制限の仕組みはfast modeのレート制限で解説しています。

切り分けの手順

  1. /fastのメッセージを確認する。接続不良か、組織による無効か
  2. 認証方式を確認する。ANTHROPIC_AUTH_TOKEN単独なら、送られないチェックが原因
  3. 鍵の出どころを確認する。ANTHROPIC_API_KEYやapiKeyHelperがゲートウェイ発行の鍵なら、許可リストでは直らない
  4. 直接通信が塞がれているだけなら、プロキシでapi.anthropic.comを許可する。塞ぎたいなら変数で回避する
  5. 変数を入れて再起動し、/fastを再実行する
  6. それでも無効と返るなら、組織の設定とmanaged settings、プランの条件を確認する

NONESSENTIAL_TRAFFICを入れた環境で止まるもの

ゲートウェイ運用では、外部への余計な通信を減らす目的でCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICを入れる組織があります。この変数は自動更新、テレメトリ、エラー報告、/feedback、リリースノート、PRステータスバッジの確認に加えて、fast modeの可用性チェックも止めます。成功したチェックのキャッシュがなければ、/fastは「Fast mode is currently unavailable」と返します。どちらのskip変数でも復旧できます。

同じ変数の副作用は、fast mode以外にも及びます。

  • 自動更新が止まるので、パッケージマネージャーや配布基盤など別の更新経路が要る
  • フィーチャーフラグの取得も止まり、Remote Controlなど取得に依存する機能が使えなくなる
  • ゲートウェイのモデル探索は影響を受けない(問い合わせ先がゲートウェイだけのため)
  • WebFetchのドメイン安全チェックは止まらず、api.anthropic.comを呼び続ける。ネットワークで塞いでいるなら、settingsでskipWebFetchPreflight: trueを別に設定する

なお、この変数に0やfalseを入れても通信は止まったままです。多くのオン・オフ変数と違い、値が空でなければ有効になります。戻すときは変数そのものを外します。

ゲートウェイと無関係な「使えない」メッセージ

/fastが返す別のメッセージは、ゲートウェイではなくプランや課金の条件が原因です。ここで2変数を試しても状況は変わりません。

/fastの表示原因対処
Fast mode requires usage credits原因Pro・Max・Team・Enterpriseで使用クレジットがオフ対処Pro・Maxは設定のUsage画面、TeamとEnterpriseは課金権限のあるメンバーが管理画面でオンにする(/usage-creditsで該当ページへ進める)
Fast mode unavailable during evaluation. Please purchase credits.原因Consoleの無料Evaluationプラン対処Consoleの課金設定でクレジットを購入
is not in your organization's allowed models原因availableModelsがfast mode対応のOpusを除外している対処許可リストに対象モデルを加える

料金の出どころも異なります。サブスクリプションのプランでは、fast modeの利用は残りの含有分があっても使用クレジットから引かれます。Consoleの組織は、他のAPI利用と同じくトークン単位で支払います。

Bedrock、Google Cloud、Microsoft Foundry、Claude Platform on AWSの経由では、モデル通信と認証が各プロバイダーに向かいます。fast modeの対象外でもあるため、この2変数の出番はありません。

非対話モードとVS Codeで「組織が無効」と出るとき

「Fast mode has been disabled by your organization」は、ゲートウェイの外でも出ます。managed settingsでfastModePerSessionOptIn: trueを配っている組織では、/fast onが動くのは対話的な端末セッションだけです。非対話モード、VS Code拡張、クラウドセッションでは、同じ「無効」のメッセージで拒否されます。

この設定は、複数セッションを並行して回す組織でコストを抑える目的で使われます。各セッションはfast modeオフで始まり、ユーザーが/fastで明示的にオンにします。本人のfast modeの好みは保存されたままなので、設定を外せば通常の持続的な挙動に戻ります。ゲートウェイの環境でCIやスクリプトから/fast onを呼んで拒否された場合は、skip変数ではなくこの設定を先に疑う場面です。

fast mode自体の料金や速度はfast modeの概要にまとまっています。

環境別のまとめ

環境チェックの結果必要な変数
外向き通信を許可済みチェックの結果成功必要な変数不要
外向き通信を遮断(接続拒否)チェックの結果接続不良必要な変数NETWORK_ERRORSまたは許可リスト
ゲートウェイ発行の鍵をAPIキーとして使用チェックの結果接続不良(拒否)必要な変数NETWORK_ERRORS
ANTHROPIC_AUTH_TOKEN単独チェックの結果組織が無効と誤判定必要な変数ORG_CHECK
TLS検査プロキシがブロックページを返すチェックの結果組織が無効と誤判定必要な変数ORG_CHECK

同じ「使えない」でも、対処する変数は反対側になります。メッセージの文言を読まずに片方だけ入れると、直らないまま原因を見誤ります。

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