Claude Code のモデルを組織で固定する — availableModels / enforceAvailableModels と /config 新構文(v2.1.175〜183)

Claude Code をチームや組織で配るとき、地味だが効いてくるのが 「誰がどのモデルを使えるか」を固定できるかです。v2.1.175(2026-06-12)で enforceAvailableModels 管理設定が入り、availableModels 許可リストが Default モデルを縛り、ユーザー設定・プロジェクト設定からの上書き拡張を防げるようになりました。続く v2.1.176 では alias 経由のすり抜けも塞がれ、v2.1.181 では /config key=value 構文と /config --help、v2.1.183 では 非推奨モデル使用時の警告が追加されています。本記事では、この一連の「モデルガバナンス」周りと、設定を素早く扱う /config 新構文を実装目線で整理します。

到達点

availableModels と enforceAvailableModels の役割の違いを理解する
管理設定(managed settings)が user / project 設定に勝つ優先順位を押さえる
v2.1.176 の alias リダイレクト封じが何を防いでいるか
/config key=value と /config --help で設定を素早く確認・変更する
非推奨モデル警告(v2.1.183)を移行管理にどう使うか

なぜ「モデルの固定」が要るのか

個人利用なら好きなモデルを選べばよいのですが、チーム配布になると事情が変わります。

コスト管理:上位モデルを無制限に使われるとトークン課金が読めない
一貫性:レビューや CI で人によってモデルが違うと挙動が揃わない
コンプライアンス:データ取り扱いや承認済みモデルの制約がある組織では、使ってよいモデルを限定したい

これらは「お願いベース」では守られません。設定として強制できる必要があります。そこを担うのが availableModels と enforceAvailableModels です。

`availableModels` と `enforceAvailableModels`

両者はセットで効きますが、役割が違います。

設定	役割
`availableModels`	使用を許可するモデルの許可リスト(どのモデルを選べるか)
`enforceAvailableModels`	有効化すると、`availableModels` が Default モデルを制約し、user / project 設定が許可リストを広げるのを防ぐ

ポイントは、availableModels を置くだけでは**「広げる」上書きを完全には防げないこと。enforceAvailableModels を有効にして初めて、「許可リストの外には出られない」ハードな制約**になります。

// 管理設定(組織が配布する側)で固定する例
{
  "availableModels": ["claude-opus-4-8", "claude-sonnet-4-6"],
  "enforceAvailableModels": true
}

この状態だと、ユーザーが自分の settings.json で別モデルを足そうとしても、許可リストを広げる方向の上書きは効きません。Default モデルも許可リストの範囲に制約されます。

効く順番:管理設定 > project > user

この仕組みが意味を持つのは、Claude Code の設定が階層で合成され、管理設定が最優先されるからです。

層	誰が置くか	強さ
管理設定(managed)	組織の管理者が配布	最優先(下位が広げられない)
project 設定	リポジトリの `.claude/`	中間
user 設定	各自のホーム	下位

通常の設定は「より近い層が勝つ」ことも多いのですが、enforceAvailableModels の眼目は 「管理設定が引いた許可リストの線を、下位の層が外側に広げられない」 点にあります。つまり強制力の方向が一方向(縛る側だけが勝つ)になっている。これが「ガバナンス設定」たるゆえんです。

v2.1.176:alias リダイレクト封じ

許可リストには抜け道がありえます。モデルには claude-opus-latest のような alias(別名) があり、これがブロック対象の実体に解決されると、許可リストを実質すり抜けられてしまう。

v2.1.176 では、availableModels の強制が alias リダイレクト経由のブロック対象モデルへの解決を防ぐようになりました。つまり「別名で迂回して禁止モデルに当てる」ルートが塞がれた、ということです。

ガバナンス設定は**「正面の入口」だけ塞いでも意味がない**。alias という裏口も同時に塞いで初めて、許可リストが約束どおりに機能します。組織で固定するなら v2.1.176 以降を前提にするのが安全です。

あわせて v2.1.176 では、/model ピッカーの表示も整理され(Max / Team Premium / Enterprise プランでは Opus が独立した行で出る)、どのモデルが選べるかの見え方も分かりやすくなっています。

v2.1.181:`/config key=value` と `/config --help`

ガバナンスを設計・確認するうえで地味に効くのが、設定そのものを素早く扱う構文です。v2.1.181 で /config が強化されました。

/config key=value:任意の設定をプロンプトから直接セットできる(例:/config thinking=false)。interactive / -p(print)/ Remote Control のいずれでも動く
/config --help:/config key=value で使えるショートハンドキーの一覧を表示
トグル挙動の変更:/config 画面で Enter と Space の両方が設定を切り替え、Esc で保存して閉じる

# 設定をその場で確認・変更
/config --help              # 使えるキーの一覧
/config thinking=false      # 拡張思考をオフに

これが効くのは、-p(非対話)モードでも /config key=value が通る点です。スクリプトや CI から設定を当てて挙動を確認する、といった設定の検証ループが回しやすくなります。ガバナンス設定を組んだあと、「本当に縛れているか」を素早く確かめる手段として有用です。

v2.1.183:非推奨モデル警告

モデルガバナンスは「固定して終わり」ではなく、モデルの世代交代に追従する必要があります。v2.1.183 では、要求したモデルが非推奨、または新しいモデルへ自動更新された場合に警告が出るようになりました。

これは移行管理に直接効きます。availableModels にピン留めした特定バージョンがいつの間にか非推奨になっていた、というのは組織配布でありがちな事故です。警告が出れば、許可リストの更新タイミングを逃さない。

実際、Claude Sonnet 4 / Opus 4 の旧モデルは 2026-06-15 に API 側で完全リタイア(リクエストがエラー化)しています。ピン留めしたモデルがリタイアするとそのまま壊れるので、非推奨警告を「許可リスト棚卸しのトリガー」として運用に組み込むのが安全です。

組織配布での組み立て(最小レシピ)

許可リストを決める:availableModels に承認済みモデルだけを列挙する。コストと用途で 2〜3 個に絞るのが現実的。
強制を有効にする:enforceAvailableModels: true を管理設定側に置く。user / project からの拡張を不可にする。
alias 封じの版を前提にする:v2.1.176 以降を配布バージョンの下限にして、別名すり抜けを防ぐ。
検証する:/config --help と /config key=value(必要なら -p モード)で、縛りが実際に効いているかを確認する。
非推奨警告で棚卸しする:警告が出たら許可リストを更新。モデルのリタイアで配布が壊れる前に追従する。

注意点

availableModels 単体では不十分:enforceAvailableModels を有効にしないと、広げる上書きを完全には防げません。ガバナンス目的なら両方セットで。
管理設定として配る必要がある:user 設定に書いても本人が外せます。強制力が要るなら管理(managed)層に置くこと。
alias は v2.1.176 以降:それより前の版では別名すり抜けの余地が残ります。配布バージョンの下限に注意。
ピン留めはリタイアで壊れる:特定バージョンに固定したモデルは、リタイア時にエラー化します。非推奨警告を見逃さない運用とセットで。

まとめ

v2.1.175〜183 の一連の変更で、Claude Code は 「組織で使ってよいモデルを固定する」道具が一通り揃いました。availableModels で許可リストを引き、enforceAvailableModels で下位設定が広げられないハードな制約にし、v2.1.176 の alias 封じで裏口も塞ぐ。/config key=value / /config --help で縛りの確認を素早く回し、v2.1.183 の非推奨警告で世代交代に追従する。

勘所はシンプルです — 許可リストは管理設定に置いて両輪(availableModels + enforce)で縛る、alias 封じの版を下限にする、非推奨警告を棚卸しのトリガーにする。個人利用では出番が少ない機能ですが、Claude Code をチームに配る段になったら、最初に押さえておくべき設定群です。

到達点