Claude Code does not support this modelで400になる原因と更新手順

次のエラーは、Claude Codeのバージョンが古いために、APIがリクエストを拒否したことを示します。

API Error: 400 Claude Code 2.1.219 does not support this model; version 2.1.255 or newer is required. Run 'claude update', or update the Claude desktop app, then try again.

直す対象は、モデル名でもログインでもありません。リクエストを出したClaude Codeのバイナリです。更新して新しいセッションを始めれば解消します。

「does not support this model」は何を拒否されたのか

このエラーはHTTP 400で、エラーコードはclaude_code_version_too_oldです。Claude Codeの公式エラー一覧では、Claude Codeのバージョンが必要な最低ラインを下回ったときの拒否と説明されています。最低ラインの出どころは2つあります。

組織ポリシー側の文面は、たとえば次のとおりです。

API Error: 400 Claude Code 2.1.240 is older than the minimum version required by your organization's policy. Run 'claude update', or update the Claude desktop app, to continue.

どちらの文面でも、メッセージの中に適用された最低バージョンが書かれています。まずその数字を控えます。

APIが照合するのは「リクエストを出したClaude Codeバイナリが名乗るバージョン」です。ターミナルでclaude --versionが新しくても、実際に動いていたのが別の場所のバイナリなら、このエラーは出ます。この点は後の切り分けで効きます。

モデルごとの最低バージョン

モデル側の経路で下限になるバージョンは、モデルによって違います。公式のモデル設定ページに載っているものを表にします。

エラーメッセージの数字は、この表と食い違って見えることがあります。公式のエラー一覧が載せている例は「2.1.255」ですが、これはメッセージの一例です。実際に出る数字は、サーバーが選んだモデルに対して判定した値なので、エラー文に出た数字を正とします。

エイリアスの注意点もあります。sonnetやopusのようなエイリアスは、古いバージョンでは古いモデルに解決されます。新しいモデルをフルネームで指定するか、新しいバージョンのエイリアスに任せるかで、起きる失敗が変わります。エイリアスが認識されない側の失敗は「is not a recognized model id」の意味と対処で扱っています。

どのバイナリを更新するか

「何を更新するか」は、リクエストを出したバイナリの出どころで決まります。公式は4通りを挙げています。

手元でインストールした場合の確認と更新は、次の3行です。

claude --version
claude update
claude --version

更新後は新しいセッションを始めます。すでに開いていたセッションに、新しいバージョンが反映されるわけではありません。

Desktopアプリが起動したセッションで出たなら、ターミナルのclaude updateでは直りません。アプリ側のバイナリが動いているからです。VS Code拡張も同じで、拡張に同梱されたバイナリが使われます。エラー文の末尾が「Run 'claude update', or update the Claude desktop app」と二択で案内するのは、このためです。

Pythonのclaude-agent-sdkのように、パッケージの中にCLIを抱えているケースでは、claude updateを実行しても同梱バイナリは変わりません。実例はClaude Agent SDKでOpus 5.5がAPI Error 400になる原因と対処法にあります。

複数のバイナリが入っている端末での確認

同じ端末に複数のClaude Codeが入っていると、claude --versionの結果と、エラーを出したバイナリが別物になることがあります。まずPATH上の候補を並べます。

which -a claude
claude --version

エラーが出た経路が「ターミナルのCLI」なのか「Desktopアプリ」なのか「IDE拡張」なのかを先に確定させ、その経路のバイナリを更新します。ターミナルで直したのにDesktopでは再発する、という場合は、経路が別だったと考えられます。

更新しても直らないとき

更新してもエラーが続くときは、次の3点を順に見ます。

1. stableチャンネルが下限に届いていない。claude updateをstableチャンネルで実行しても、最新のstableより先には進みません。既定のlatestに対し、stableはおおむね1週間前のバージョンを配信するため、新しく公開されたモデルの下限に届かないことがあります。そのときはlatestチャンネルへ切り替えてから、もう一度更新します
2. チャンネルやバージョンが管理設定で固定されている。組織が管理設定でチャンネルやバージョンを固定している場合は、自分では動かせません。管理者に変更を依頼します
3. セルフホスト環境。自前の環境にデプロイしている場合は、公式のセルフホスト環境の手順に「バージョンを固定する」節があり、ここで固定したバージョンが下限を下回っていないかを確かめます

チャンネルは/configのAuto-update channel、またはsettings.jsonのautoUpdatesChannelで選べます。

{
  "autoUpdatesChannel": "latest"
}

チャンネルの違いと切り替えの影響はClaude CodeのautoUpdatesChannelでstableとlatestを選ぶにまとめています。更新全般の制御はClaude Codeアップデートの方法が詳しく扱っています。

HomebrewやLinuxのパッケージマネージャーで入れた場合、チャンネルはautoUpdatesChannelではなく、導入時の選択で決まります。

stableのcaskであるclaude-codeを入れていて下限に届かないときは、claude-code@latestのcaskに切り替えます。更新コマンドもcaskごとに別で、入れた側に合わせて実行します。

brew upgrade claude-code          # stable cask を入れている場合
brew upgrade claude-code@latest   # latest cask を入れている場合

apt、dnf、apkでlatestに寄せたいときは、リポジトリの設定をlatest側に切り替えます。手順は公式のLinuxパッケージマネージャーの節にあります。Homebrew、WinGet、apt、dnf、apkは既定では自動更新されないので、手動で更新するまでバージョンは上がりません。HomebrewとWinGetは、環境変数CLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATEを1にすると、新しいバージョンが出たときにClaude Codeが更新コマンドをバックグラウンドで実行します。apt、dnf、apkは管理者権限が要るため、この対象外で手動更新のままです。また、パッケージマネージャー側にはまだ新バージョンが届いていない場合があり、更新が失敗したら時間をおいて再試行します。

minimumVersionで下限を固定している場合

settings.jsonのminimumVersionは、自動更新とclaude updateが入れてよいバージョンの下限を決める設定です。この値より低いバージョンには更新されません。この設定は更新を制限するだけで、モデル側の400の下限を満たすかどうかとは別の話です。

{
  "autoUpdatesChannel": "stable",
  "minimumVersion": "2.1.100"
}

/configでlatestからstableに切り替えると、現在のバージョンのまま残るか、ダウングレードを許すかを尋ねられます。残る方を選ぶと、現在のバージョンがminimumVersionに入ります。latestに戻すと値は消えます。stableに切り替えたのにバージョンが下がらないのは、この仕組みによるものです。

管理設定にminimumVersionを置くと、組織全体の下限になり、ユーザー設定やプロジェクト設定では上書きできません。一方、管理設定のrequiredMinimumVersionは更新を制限するのではなく、範囲外のバージョンの起動そのものを拒否します。更新の下限か、起動の下限かが両者の違いです。

更新できないあいだの回避策

更新がすぐにはできないとき、モデル側の経路なら、別のモデルに切り替えて作業を続けられます。方法は面ごとに違います。

組織ポリシー側の文面で出た場合は、モデルを替えても通りません。下限が組織全体にかかっているので、更新してから続ける以外の手はありません。

CIでclaude -pを回しているなら、バージョンが足りないまま走らせないよう、実行前に最低バージョンを検査する手もあります。次のスクリプトは、sort -Vで比較する一例です。

required="2.1.280"   # 使うモデルの最低バージョンに合わせる
current="$(claude --version | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -1)"
if [ "$(printf '%s\n%s\n' "$required" "$current" | sort -V | head -1)" != "$required" ]; then
  echo "Claude Code $current は $required 未満です。claude update を実行してください" >&2
  exit 1
fi

claude --versionの出力形式は、実行環境のバージョンで確かめてから使います。

似たエラーとの見分け方

「モデルが使えない」系のエラーは多く、文面が近いものがあります。原因が違えば直し方も違うため、冒頭の文言で振り分けます。

Opus 5.5をプランの問題と取り違える例には注意が要ります。v2.1.280より前のClaude CodeでOpus 5.5を要求して失敗する場合、正体は本記事の400です。プランの変更ではなく更新で直ります。

組織側で下限を強制する設定キーとして、管理設定のrequiredMinimumVersionがあります。起動時に古いバイナリを止める仕組みで、Claude CodeのrequiredMinimumVersionで古いバージョンの起動を止めるに詳細があります。ただし、このキーと、APIが返す組織ポリシー側の400が同じ設定に由来するかどうかは、公式のエラー一覧に説明がありません。メッセージに出た数字を、管理者の設定と突き合わせて確認する形になります。

まとめ

400のclaude_code_version_too_oldは、モデルを替えたりログインし直したりしても根本的には解決しません。要点は3つです。

• メッセージに出た「X or newer」が下限。モデル側か組織ポリシー側かは文面で分かる
• 更新対象は、リクエストを出したバイナリ。CLI、Desktop、VS Code拡張、Agent SDKで更新方法が違う
• 更新しても直らなければ、stableチャンネルか、管理設定による固定を疑う

最後に、更新後は新しいセッションから試します。