結論：開始モデルは統一し、例外は記録する
Claude Code 2.1.236以降では、ANTHROPIC_DEFAULT_MODELで新規セッションの開始モデルを指定できます。利用者が/modelで別モデルを選ぶと、その選択が優先され、再起動後も保持されます。全員の初期値をそろえつつ、難しい作業だけ上位モデルへ切り替える運用に向きます。モデル変更を禁止する設定ではないため、強制統制が必要ならgatewayやmanaged settingsも併用します。
読者の具体的な困りごとは、担当者や端末ごとに開始モデルが違い、同じ手順でも品質、速度、利用量が揺れることです。この記事を読むと、標準モデル、例外モデル、切替記録を分けて設定し、既存セッションを壊さず展開できます。
次の行動：代表的な三つの業務を選び、現在の開始モデル、必要品質、許容費用を一枚の表へ記録してください。
公式仕様と提供条件を確認する
公式Claude Code changelogの2.1.236は、ANTHROPIC_DEFAULT_MODELを追加し、新規セッションが開始するモデルを設定できると説明しています。同じ項目には、/modelで選んだモデルが環境変数を上書きし、再起動後も保持されること、従来のANTHROPIC_MODELとは挙動が異なることも明記されています。したがって、この変数は「毎回必ず同じモデルへ固定する命令」ではなく、「選択がない時の安全な初期値」です。
公式settings文書では、Claude Codeの設定範囲をManaged、User、Project、Localに分け、Managedが最も高い優先順位を持つと説明しています。環境変数をshell profileだけへ置くと個人端末に限定され、CI、Desktop、remote sessionでは継承経路が異なる場合があります。企業では、どの実行入口へ配布するか、誰が変更できるか、値をどこで監査するかを先に決めます。
公式model configuration文書では、利用可能モデルやalias、provider別の指定方法が更新されます。名称を推測して設定せず、契約で利用できる正式なmodel identifierを公開直前に確認します。プラン、組織policy、Bedrock・Vertex AI・Foundry等のproviderによって利用可能性が異なるため、設定値が通ることと契約上使ってよいことを分けて検証します。
三つの設定方法を比較する
- ANTHROPIC_DEFAULT_MODEL：新規sessionの初期値をそろえ、利用者の
/model選択を残したい時に使います。段階導入と例外運用に向きます。 - ANTHROPIC_MODEL：既存systemとの互換性を含め、より直接的なmodel指定が必要な経路で使います。新変数との優先関係を検証せず併記しません。
- /model：一つのsessionで作業難度に合わせて切り替える時に使います。個人の選択が保持されるため、標準から外れた理由を記録します。
比較軸は適用範囲、上書き可否、持続性、配布方法、監査性の五つです。個人の試用はUser環境で十分ですが、team標準は設定配布の正本を一つにします。projectごとに違うモデルが必要なら、repositoryの目的とdata分類を基準にし、単に「高性能そうだから」という理由で上位modelへ固定しません。
費用を抑える業務では、分類、定型変換、短い修正を標準modelへ置き、複雑なarchitecture判断や長いreviewだけ明示的に切り替えます。品質を優先する業務でも、すべてを最上位へ固定すると利用上限や待ち時間が増えます。taskごとの合格基準をtest、review件数、再作業率で測り、model名だけで品質を判断しないことが重要です。
安全に導入する7手順
- Claude Codeを2.1.236以降へ更新し、
claude --versionで対象versionを記録します。 - 公式model設定文書で、契約とproviderに対応する正式なmodel identifierを確認します。
- 新規sessionの標準業務、例外業務、禁止業務を一文ずつ定義します。
- 一人のtest環境へ
ANTHROPIC_DEFAULT_MODELを設定し、新規sessionの開始modelを確認します。 /modelで一度切り替え、session再起動後に選択が保持されることをreadbackします。- shell、Desktop、IDE、remote、CIの各入口で値の継承を個別に確認します。
- 一週間の利用量、品質、例外切替、失敗をreviewし、全社配布かHOLDかを決めます。
検証では既存sessionと新規sessionを混同しません。新しい変数は新規sessionが開始するmodelを決めるため、設定前から開いているsessionだけを見て「反映されない」と判断しないようにします。また、/modelの選択が保持されている端末では標準値が見えない場合があります。test用の新しいprofileか、選択状態を記録したうえで確認します。
配布時は秘密情報を値へ含めず、設定管理systemには変数名、値、owner、適用日、rollback方法を残します。provider移行やmodel廃止が起きた時に、どの端末へ古い値が残るか追える状態が必要です。突然の一括変更より、開発team、review team、非開発teamの順にpilotを分けると影響を限定できます。
企業運用チェックリストとHOLD条件
- 対象versionを確認した
- 正式なmodel identifierを確認した
- 契約上利用可能である
- 標準業務を定義した
- 例外切替の条件がある
- 設定ownerが明確
- 配布経路を一つにした
- 新規sessionでtestした
- /model上書きをtestした
- 再起動後の保持を確認した
- IDEとterminalを分けて確認した
- 利用量を測定できる
- rollback手順がある
- 変更履歴を残せる
HOLD条件は、model名称が公式文書で確認できない、契約上の提供条件が不明、provider別identifierを混同している、設定がどこから配布されるか追えない、例外切替を監査できない場合です。設定に成功しても、品質と費用の評価がないまま全社展開しません。
特に複数providerを使う企業では、同じ通称でもidentifierや提供時期が違うことがあります。fallback modelがある構成では、開始modelだけでなくfallback chainも記録します。障害時に別modelへ切り替わった結果を標準modelの評価へ混ぜないよう、sessionの実modelとproviderを監査logへ残してください。
よくある質問と次の行動
設定したのに別モデルで始まるのはなぜですか？
以前の/model選択が保持されている、別の入口が環境変数を継承していない、provider側のaliasが異なる可能性があります。新規profileと新規sessionで切り分けます。
最安モデルを全員の既定にすべきですか？
費用だけで決めず、taskの合格率、修正時間、review負荷まで比較します。安価でも再作業が増えれば総費用は上がります。
モデル変更を完全に禁止できますか？
この環境変数単体は初期値です。許可modelの制限、managed policy、gateway、監査を組み合わせてください。
提供内容は公式Claude Code changelog、設定範囲は公式settings、model指定は公式model configurationで公開直前に確認してください。
利用量の可視化はstatus lineガイド、企業の費用上限はspend limitガイド、更新方法はrelease channelガイドへつなげます。Miraigentの無料診断では、標準model、例外条件、設定配布、費用監視を整理します。