Claude Code v2.1.175 — 利用モデルの許可リストがDefaultにも効く管理設定を追加

Claude Code v2.1.175では、enforceAvailableModelsという管理設定が追加されました。これを有効にすると、利用できるモデルを絞る許可リストavailableModelsが、これまで対象外だったDefaultにも効くようになります。Defaultが許可されていないモデルへ解決される場合は、最初の許可モデル(許可リストの先頭と読めます)へ自動で切り替わります。さらに、ユーザー設定やプロジェクト設定の側から、管理者が定めたavailableModelsの許可リストを広げることもできなくなります。本稿では、この設定が誰の運用に効くのか、従来のモデル統制とどう違うのかを、設定の優先順位と利用形態別の早見表で見ていきます。

このリリースで何ができるようになるか

この版で加わるのは、組織がモデルの利用範囲を管理側で固定しきるための設定です。読者がまず把握したい変化は次の2つです。

1つ目は、許可リストがDefaultにも効くようになる点です。これまでavailableModelsは、/model・--model・ANTHROPIC_MODELで選べるモデルを絞る設定で、Defaultの選択肢には効きませんでした。enforceAvailableModelsを有効にすると、Defaultが許可されていないモデルへ解決される構成では、最初の許可モデルへ自動で切り替わります。許可リストに無いモデルが、Default経由で使われる余地がなくなります。

2つ目は、許可リストを下位の設定から広げられなくなる点です。availableModelsは複数の階層で設定でき、従来はユーザー設定とプロジェクト設定の値が結合・重複排除されてマージされていました。本設定の有効化後は、管理設定で定めた許可リストに対して、ユーザーやプロジェクトが項目を足して範囲を広げることはできなくなります。組織が決めた範囲が、下位の設定で緩められない形になります。

あなたの開発フローはどう変わるか

効き方は、availableModelsを管理設定で配っているかどうかで大きく分かれます。組織のセキュリティポリシーやコンプライアンス要件としてモデルを絞っているIT・DevOps部門には明確に効き、個人で使っている場合はそもそも管理設定が無いため、有効化する対象がありません。

管理設定でavailableModelsを配布している企業では、これまで残っていた「Default経由の抜け道」が塞がれます。許可リストを空にしてもDefaultではプランごとの既定モデルが使えてしまう挙動が従来はありましたが、enforceAvailableModelsを有効にすると、Defaultも許可リストの範囲内に収まります。許可リストの先頭に置いたモデルが、Defaultの実体として使われる形です。

バージョンを固定して運用しているチームにも関係します。従来は利用モデルを厳密に固定するために、availableModelsに加えてmodel、さらにANTHROPIC_DEFAULT_*の環境変数ブロックという3つの設定を組み合わせる必要がありました。環境変数ブロックを省くと、Defaultを選んだ利用者が最新のSonnetに解決され、バージョン固定をすり抜ける余地が残っていました。enforceAvailableModelsは、このDefault側の抜け道を許可リストだけで閉じる選択肢になります。

一方、個人の契約でローカルからClaude Codeを使っている場合は、管理設定そのものが存在しないため、この設定を有効にする前提が成立しません。/modelで選べるモデルを自分で絞っているだけのケースでは、体感の変化はほとんどありません。

主な変更点

この版の変更はenforceAvailableModels設定の追加の1点です。挙動を3つの側面に分けて説明します。

• 許可リストがDefaultにも効きます。有効化すると、Defaultが許可されていないモデルへ解決される構成では、最初の許可モデル(許可リストの先頭と読めます)へフォールバックします(モデルを管理側で絞る組織)。
• 下位の設定から許可リストを広げられなくなります。ユーザー設定やプロジェクト設定が、管理設定で定めたavailableModelsに項目を足して範囲を広げることができなくなります(管理設定で許可リストを配る組織)。
• 管理設定の階層で指定する設定です。Claude Codeの設定の優先順位は、管理設定が最も高く、コマンドライン引数・ローカル設定・プロジェクト設定・ユーザー設定の順に下がります。管理設定はほかのどの階層からも上書きできないため、組織全体のセキュリティポリシーやコンプライアンス要件を固定する用途に向きます。

availableModelsの周辺には、関連する設定がいくつかあります。v2.1.166で追加されたfallbackModelは、主モデルが過負荷や利用不可のときに最大3件のフォールバックモデルを順に試す設定で、availableModelsの許可リストの外にある要素は候補から落とされます。許可リストはこうした関連設定にも一貫して効くため、enforceAvailableModelsの有効化はモデルの選択経路をまとめて許可リストの範囲へ寄せる動きになります。

管理設定でavailableModelsとenforceAvailableModelsを配る場合の設定ファイルは、次のような形になります。

{
  "availableModels": [
    "claude-opus-4-8",
    "claude-sonnet-4-6"
  ],
  "enforceAvailableModels": true
}

利用者の側では、/modelで選べるモデルが許可リストの範囲に収まっているかを確認できます。

/model

更新後はバージョンを確認できます。

npm install -g @anthropic-ai/claude-code
claude --version

enforceAvailableModelsはモデル統制の「Default抜け穴」をどう塞ぐか

enforceAvailableModelsの有効化前後で変わるのは、Defaultの扱いと、下位設定による許可リストの拡張可否の2点です。従来の挙動では、availableModelsはDefaultの選択肢に効かず、許可リストを空にしてもプランごとの既定モデルがDefaultとして使えました。下位の設定もマージで結合されるため、ユーザーやプロジェクトの側で許可リストに項目を足すことができました。

Defaultの実体は、アカウントの種類で決まります。Max・Team Premium・従量課金のEnterprise・Anthropic APIではOpus 4.8、Pro・Team Standard・Enterpriseのサブスクリプション席ではSonnet 4.6、Bedrock・Vertex・FoundryではSonnet 4.5が、それぞれDefaultとして解決されます。enforceAvailableModelsが無効のままだと、許可リストでこれらのモデルを外していても、Default経由で使われる余地が残ります。有効にすると、Defaultもアカウントごとの実体ではなく、許可リストの先頭に置いたモデルへ寄ります。

この設定は、モデル統制まわりの修正・追加が続いた流れの先に位置づけられます。v2.1.166でfallbackModelが加わり、v2.1.172で許可リストの適用漏れがまとめて直り、v2.1.174で/modelピッカーがDefaultの実体を正しく表示するよう整えられてきました。表示と適用範囲を順に詰めてきた延長として、本版はDefault側の適用と下位設定の拡張可否に踏み込んだと読めます。fallbackModelの詳細はClaude Code v2.1.166の解説に、許可リストの適用漏れの修正はClaude Code v2.1.172の解説にまとめています。番号上の直前にあたる/modelピッカーの修正はClaude Code v2.1.174の解説で扱っています。本版v2.1.175の番号上の直前はv2.1.174で、同じ2026-06-12に公開された欠番のない並びです。

モデル統制まわりの追加・修正タイムライン

availableModelsとモデル統制まわりの変更が、4つの版でどう積み上がってきたかを時系列で並べます。

候補を増やすfallbackModelから、適用範囲を漏れなく効かせる修正、表示を実体に合わせる修正へと進み、本版で許可リストを下位設定からも崩せない形に固める、という順で読めます。1つの大きな機能というより、モデル統制の経路を版ごとに少しずつ閉じてきた流れと見ることもできます。

利用形態別の影響早見表

自分の使い方でどの程度効くかは、次の早見表で確認できます。全員が一律に急いで動くべき種類の変更ではなく、availableModelsを管理設定で配っているかどうかで濃淡が分かれます。

管理設定でavailableModelsを配っている組織にとっては、Default側の抜け道が塞がる点で「明確な恩恵あり」に寄ります。一方、個人の契約でユーザー設定だけを使っている場合は、有効化する前提となる管理設定そのものが無いため、影響はほとんど出ません。

有効化の前に確認したい点

enforceAvailableModelsを有効にする前に、許可リストの中身と並び順を見直しておくと、想定外のフォールバックを避けやすくなります。まず気をつけたいのは、availableModelsを空リストのままにしているケースです。従来は許可リストが空でもDefaultでプランの既定モデルが使えましたが、enforceAvailableModelsを有効にするとDefaultも許可リストの範囲に収まるため、空リストと有効化を組み合わせると「許可されたモデルが無い」状態になりうる点に注意が要ります。有効化と同時に、最低限使わせたいモデルを許可リストへ明示しておく確認が要りそうです。

許可リストの並び順も、見た目以上に効いてくる要素です。Defaultが許可されていないモデルへ解決される場合は「最初の許可モデル」へ切り替わるため、配列の並び順が実効的なDefaultを左右すると読めます。先頭にどのモデルを置くかで利用者が実際に使うモデルが変わりうるので、許可リストは「許す顔ぶれ」だけでなく「先頭に何を置くか」まで意識して並べておくと、運用後のズレが起きにくくなります。

フォールバック先との整合性も、併用する組織では見落としやすい点です。v2.1.166で加わったfallbackModelは最大3件のフォールバックモデルを順に試しますが、その連鎖の要素も許可リストの外にあれば候補から落ちます。enforceAvailableModelsとfallbackModelを一緒に使う場合は、フォールバック先のモデルも許可リストに含めておかないと、いざというときに切り替わる先が無くなりかねません。許可リストとフォールバック設定は、片方だけでなく両方をそろえて確認しておくと安全です。

アカウントの種類によってDefaultの実体が異なる点も、事前に突き合わせておきたいところです。Bedrock・Vertex・Foundryでは、ほかのアカウント種別とは別のモデルがDefaultとして解決されるため、エイリアスやバージョン固有のIDで許可リストを書いている場合は、その表記がDefaultの実体と噛み合うかが条件次第で変わります。許可リストの照合がアカウントの実体とずれていないかは、有効化の前に一度確認しておくと安心です。なおenforceAvailableModelsはchangelogで追加された設定で、挙動を試すときは小さな許可リストから動作を見ておくと把握しやすくなります。

まとめ

Claude Code v2.1.175は、enforceAvailableModelsという管理設定を追加した版です。有効にすると、availableModelsの許可リストがDefaultにも効き、Defaultが許可されていないモデルへ解決される場合は最初の許可モデルへ切り替わります。あわせて、ユーザー設定やプロジェクト設定の側から管理者の許可リストを広げることもできなくなります。

管理設定でモデルの利用範囲を配っているIT・DevOps部門や、バージョンを厳密に固定したい組織では、これまで残っていたDefault側の抜け道を許可リストだけで塞げるようになる点に更新の価値があります。個人の契約でユーザー設定だけを使っている場合は、有効化する前提が無いため体感差は小さく、手の空いたタイミングでの更新で問題ありません。Claude Code全体の使い方はClaude Code完全ガイドを参照してください。