結論：availableModelsMatchで許可範囲を決め、deniedModelsで例外を止める
Claude Code 2.1.283でモデルの自動採用を防ぎたい場合は、managed settingsのavailableModelsMatchを確認し、厳密な許可が必要なscopeではexactを使います。特定のmodel versionだけを追加で止めたい時はdeniedModelsを組み合わせます。ただし、これは料金や品質を保証する設定ではありません。model ID、provider、契約、context、利用目的を別に承認してください。
2.1.283の公式changelogでは、exactの場合、availableModelsに記載したmodel versionだけを許可し、新しいリリースは一覧へ追加するまでブロックすると説明されています。またdeniedModelsは、availableModelsが許可する候補から特定モデルを拒否するための設定です。更新を止めること自体が目的ではなく、追加検証のないモデルを本番へ流さないための変更管理です。
一次情報はClaude Code公式changelogとsettings公式文書です。設定の適用順序、managed scope、project scopeを混同しないでください。既存の既定モデルを統一するガイドが開始モデルの選択を扱うのに対し、この記事は組織が利用可能な候補を閉じる境界に絞ります。
allowlistとdenylistの違いを比較する
| 設定 | 役割 | 更新時の判断 |
|---|---|---|
availableModels | 利用候補を列挙する | ID、日付、評価票、対象groupを確認して追加 |
availableModelsMatch: exact | 列挙したversionだけを許可 | 新versionは自動採用せず、明示的な更新を行う |
deniedModels | 候補から特定versionを除外 | 事故、契約、評価未完了などの理由と解除条件を記録 |
重要なのは、設定名だけを見て「安全なモデル」が決まると考えないことです。availableModelsの記述が広すぎれば候補は増え、deniedModelsの理由が期限なしなら一時対応が恒久化します。反対にexactを全組織へ適用すると、必要な新機能が追加審査待ちになり、利用者が別の非公式経路を探す可能性があります。利用者group、開発・検証・本番の環境、緊急時の例外を先に表へします。
また、同じmodel名でもproviderのmodel ID、日付suffix、契約プラン、APIとClaude Codeでの提供条件が異なる場合があります。表示名だけで承認せず、/statusやmodel pickerで実際に解決されたIDを確認します。料金はClaudeの料金ガイドと公式pricingを突き合わせ、設定変更だけで費用が下がるとは書かないようにします。
導入・更新の8手順
- 対象を定義する。誰がどの環境で何のmodelを使うか、対象外の業務とともに一文で書きます。
- versionを固定する。
claude --versionと2.1.283以降の対応状況を記録し、古いclientがmanaged keyを理解できるか確認します。 - 候補の正本を作る。表示名でなくmodel ID、provider、日付、利用目的、評価担当を
availableModelsの変更票へ紐づけます。 - match方式を選ぶ。新versionを自動採用しない本番は
exact、検証環境では更新の検知を目的に別scopeを検討します。 - 拒否理由を登録する。
deniedModelsへ入れる場合は、理由、登録者、期限、再評価条件、利用者への告知を書きます。 - 設定scopeを確認する。managed settingsがprojectやuser設定より優先される公式ルールを確認し、同じkeyを下位scopeで上書きできる前提にしません。
- 安全なfixtureで実機検証する。許可model、拒否model、新しい未登録modelを順に選び、表示、エラー、ログ、監査イベントを保存します。
- 解除とロールバックを試す。一つのgroupで戻せること、設定配布遅延、既存sessionへの影響、緊急連絡先を確認してから全社へ広げます。
モデル管理チェックリスト
- model IDと表示名を分けて記録した。
exactを適用する環境と、更新を試す環境を分けた。deniedModelsの理由・期限・解除担当がある。- managed、command line、project、userの優先順位を検証した。
- 許可・拒否・未登録の3ケースを実機で確認した。
- 料金、性能、context、データ保持を利用可否設定と別に評価した。
- 利用者が拒否理由と問い合わせ先を確認できる。
更新の承認では「新しいmodelだから試す」だけでなく、変更される利用者体験を記録します。選択肢が減るのか、既存sessionが継続するのか、未登録versionを選んだ時にどの表示が出るのかを確認し、ヘルプデスク向けの回答を用意します。managed settingsの変更が配布されるまでの時間も環境ごとに異なるため、設定を書き換えた時刻と、利用者側で確認した時刻をログへ残します。
緊急時にdenyを追加する場合も、理由だけでなく解除条件を同時に決めます。例えば障害調査中、契約確認待ち、評価データ不足のどれなのかで、再開に必要な証拠が変わります。denyの解除を口頭だけで行わず、変更票、実機readback、責任者の承認を一組にすることで、モデルの選択結果を後から説明できます。
特に複数providerを使う組織では、同じ表示名を同じ挙動だと扱わないようにします。API側のID、Claude Code側の解決結果、Gatewayのrouting、利用者が見たpickerを一つの検証記録に並べます。どれか一つでも不一致なら本番の許可を保留し、問い合わせ先へ返すエラー文も確認します。
更新日は台帳に残し、定期再評価へつなげます。
よくある質問と次の行動
exactを使うと新モデルの検知もできませんか？
検知と採用を分けます。changelogを定期確認し、検証groupへ一時的に追加して評価し、承認後に本番のavailableModelsへ追加する運用が安全です。
deniedModelsだけで運用できますか？
候補全体が広い場合は除外漏れが起きます。利用範囲を先にallowlistで決め、明確な例外だけdeniedModelsへ置きます。
導入判断が社内で止まります。
設定の作業だけでなく、model選定、権限、評価、停止条件を一枚の変更票にまとめると承認者が判断しやすくなります。必要なら無料診断で業務別に整理できます。
利用者の開始modelは既定モデルの環境変数ガイド、組織設定の監査はmanaged settingsのOTel監査ガイド、MCPや外部toolの許可はmanaged MCPの運用ガイドも参照してください。Miraigentの無料診断では、モデルの許可・拒否と業務の停止条件を一緒に棚卸しします。