6月15日から、headless の claude -p・Agent SDK・GitHub Actions・サードパーティ製エージェントは、サブスクリプションの利用上限から外れて API レート準拠の月次クレジット（繰越なし）へ移行します。個人開発で4つの技術ブログ（Dolice Labs）を夜間バッチで自動更新しているので、この変更で最初に心配したのは「品質が落ちること」ではなく、意図しないモデルの格上げでクレジットが月半ばに尽きること でした。
具体的にはこういう経路です。親エージェントには Haiku を割り当てていても、サブエージェントの設定が model: opus のまま残っていたり、過負荷時の fallbackModel が上位モデルを指していたり、あるいは新モデルの導入期間中に「とりあえず一番賢いやつ」を手元で選んでしまったりする。1回あたりの差額は小さくても、毎晩走る自動実行では月末に効いてきます。
ここでは enforceAvailableModels という管理設定を軸に、セッションが選べるモデルそのものを管理側から固定し、クレジット消費を予測可能な範囲に収める 設計をまとめます。プロンプト側の工夫ではなく、設定レイヤーで「上限」を作るアプローチです。
なぜ課金変更後は「モデルの固定」が効くのか
繰越のある月や、サブスク上限内で動いていた頃は、たまたま上位モデルが走っても翌月に吸収できました。月次クレジットが繰越なしになると、この緩衝がなくなります。クレジットは「使い切ったら止まる」予算であり、月内の配分そのものが運用設計の対象になります。
ここで効くのが、消費を入口で 抑える発想です。プロンプトで「安いモデルを使ってください」と頼む方法は、サブエージェントの再帰や自動ワークフローの中では守られないことがあります。一方、選べるモデルの集合を管理設定で絞れば、どの経路から来ても許可外のモデルは起動できません。コスト管理を「お願い」から「制約」に変える、というのがこの記事の中心です。
私のパイプラインでの目安をひとつ挙げると、記事1本の生成（リサーチ＋下書き＋日英整合チェック）を Haiku 中心で回した場合と、同じ工程を取り違えて Opus で回した場合では、トークン単価の差がそのまま数倍の消費差になりました。1晩6本×4サイトの規模だと、この取り違えが一晩あるだけで日次予算を押し上げます。だからこそ、人間の注意ではなく設定で止めたいのです。
enforceAvailableModels が効くレイヤー
Claude Code の設定は複数のレイヤーが重なって最終値が決まります。優先度の高い順に並べると、おおむね次の通りです。
管理設定（managed settings） — 端末や組織の管理者が配置し、ユーザーが上書きできない
プロジェクト設定 — リポジトリの .claude/settings.json
ユーザー設定 — ~/.claude/settings.json
実行時のフラグやセッション内の選択
コスト上限を「絶対に破られない床」にしたいなら、上書き不可能な管理設定レイヤーに置くのが要点です。enforceAvailableModels は、このレイヤーで「このマシン（またはこの組織）のあらゆるセッションが使ってよいモデルの集合」を宣言する管理設定です。集合の外にあるモデルは、実行時フラグでもサブエージェント設定でも選べなくなります。
macOS の管理設定ファイルの場所は次の通りです（Linux は /etc/claude-code/managed-settings.json）。
# macOS の管理設定（root 権限で配置・ユーザーは上書き不可） /Library/Application Support/ClaudeCode/managed-settings.json 最小構成：許可するモデルを宣言する
まず、管理設定で許可モデルの集合を宣言します。ここでは「主力＝Sonnet、軽作業＝Haiku」の2枚だけを許可し、Opus 級と新ティアは入れない構成にします。
// /Library/Application Support/ClaudeCode/managed-settings.json { "enforceAvailableModels" : [ "claude-sonnet-4-6" , "claude-haiku-4-5-20251001" ], "model" : "claude-haiku-4-5-20251001" } enforceAvailableModels が許可集合、model がそのセッションの既定値です。既定を Haiku にしておくと、明示的に Sonnet を指定しない限り軽いモデルで走るので、消費が静かになります。
この状態でセッションが Opus を要求すると、起動時に拒否されます。サブエージェントの設定に model: claude-opus-4-8 が残っていても、その値は許可集合の外なので発火しません。「設定が古いまま放置されていた」事故をレイヤーで吸収できる のがこの構成の利点です。
Before / After：プロジェクト側に依存していた頃との違い
以前の私の構成は、コスト制御をプロジェクト設定に頼っていました。
// Before: .claude/settings.json（ユーザーが上書き可能・サブエージェントは独自に model を持てる） { "model" : "claude-haiku-4-5-20251001" } これだと、既定値は Haiku でも、サブエージェント定義や --model フラグで簡単に上書きできます。実際、デバッグ中に手元で --model opus を付けたまま、その設定をコミットしてしまい、夜間バッチが数日間 Opus で走っていたことがありました。
// After: managed-settings.json（上書き不可の床） { "enforceAvailableModels" : [ "claude-sonnet-4-6" , "claude-haiku-4-5-20251001" ], "model" : "claude-haiku-4-5-20251001" } After の構成では、--model opus を付けても起動時に弾かれます。床を管理レイヤーに移したことで、プロジェクト側の設定ミスがコストに直結しなくなりました。
fallbackModel を許可集合の内側だけで降格させる
過負荷（529 Overloaded）対策で fallbackModel を使っている方は多いと思います。落とし穴は、フォールバック先を「より賢いモデル」にしてしまうと、混雑時にこそ上位モデルへ跳ねてクレジットが膨らむことです。フォールバックは横ではなく下へ 、つまり許可集合の内側で軽い方へ降ろすのが、コスト観点では正解です。
// managed-settings.json — 過負荷時は Haiku へ「降格」する { "enforceAvailableModels" : [ "claude-sonnet-4-6" , "claude-haiku-4-5-20251001" ], "model" : "claude-sonnet-4-6" , "fallbackModel" : "claude-haiku-4-5-20251001" } こうすると、通常は Sonnet で走り、混雑時には Haiku に降りて処理を継続します。fallbackModel の値も enforceAvailableModels の集合に含まれている必要があります。集合外を指定すると、いざ過負荷になったときにフォールバック自体が無効化され、処理が止まってしまうので注意してください。三層にしたい場合は、主・副ともに集合内に置きます。
モデル切替コマンドを deny の glob で塞ぐ
セッション内からシェル経由でモデルを切り替えられると、せっかくの床に穴が空きます。permissions.deny の glob で、モデル指定フラグを含むコマンド実行を禁止しておきます。
// managed-settings.json — モデル上書きを試みるコマンドを拒否 { "enforceAvailableModels" : [ "claude-sonnet-4-6" , "claude-haiku-4-5-20251001" ], "model" : "claude-haiku-4-5-20251001" , "fallbackModel" : "claude-haiku-4-5-20251001" , "permissions" : { "deny" : [ "Bash(claude --model *)" , "Bash(claude -p --model *)" , "Bash(* ANTHROPIC_MODEL=*)" ] } } ANTHROPIC_MODEL 環境変数の差し込みまで塞いでおくと、サブプロセスから既定モデルを書き換える経路も止まります。glob は前方一致で素直に効くので、claude --model * のように「フラグの直後にワイルドカード」を置くのがコツです。スペースの有無で取りこぼさないよう、フラグの異形（-p 併用など）も列挙しておきます。
許可外モデルが本当に弾かれるかをCIで検証する
設定は「書いたつもり」で漏れるのが怖いところです。私は管理設定をデプロイしたあと、許可外モデルが確実に拒否されるかを小さなスクリプトで確認しています。CIに組み込めば、設定ファイルの改変をすり抜けて上位モデルが復活する事故を早期に捕まえられます。
#!/usr/bin/env bash # verify-model-guardrail.sh # 許可外モデルでの起動が「失敗する」ことを期待する逆説テスト set -uo pipefail
DENIED_MODEL = "claude-opus-4-8" PROMPT = "出力は OK の2文字だけにしてください。"
echo "▶ 許可外モデル ${ DENIED_MODEL } での起動を試行します（失敗を期待）" if claude -p " $PROMPT " --model " $DENIED_MODEL " > /tmp/out.txt 2> /tmp/err.txt ; then echo "❌ 失敗: 許可外モデルが起動してしまいました。床が効いていません。" cat /tmp/err.txt exit 1 else echo "✅ 期待どおり拒否されました（床が機能しています）" fi
echo "▶ 許可内モデルでの起動を確認します（成功を期待）" if claude -p " $PROMPT " --model "claude-haiku-4-5-20251001" > /dev/null 2>&1 ; then echo "✅ 許可内モデルは正常に起動しました" else echo "❌ 失敗: 許可内モデルまで弾かれています。集合の宣言を見直してください。" exit 1 fi ポイントは、「拒否されたら成功」という逆向きのアサーション にすることです。普通のテストは成功を期待しますが、ガードレールの検証は「禁止が効いていること」を確かめるので、終了コードの扱いが逆になります。許可内モデルの起動確認もセットにして、集合を絞りすぎて正規の処理まで止めていないかを同時に見ます。
複数リポジトリへ管理設定を配る
私のように複数のリポジトリを同じマシンの夜間バッチで回している場合、管理設定はマシンに1枚置けば全リポジトリへ一律に効きます。これがプロジェクト設定との大きな違いで、リポジトリごとに .claude/settings.json を直す必要がありません。
# 管理設定を配置して権限を固める（root で実行） SRC = "./managed-settings.json" DEST = "/Library/Application Support/ClaudeCode/managed-settings.json"
sudo install -d -m 755 "$( dirname " $DEST ")" sudo install -m 644 -o root " $SRC " " $DEST "
# 配置後の確認 echo "▶ enforceAvailableModels の宣言を確認します" python3 -c "import json,sys; d=json.load(open(' $DEST ')); print('allowed:', d.get('enforceAvailableModels'))" 所有者を root にし、書き込み権限を一般ユーザーから外しておくのが要点です。夜間バッチを動かすユーザー自身が設定を書き換えられてしまうと「床」の意味が薄れます。新しいモデルを正式採用したくなったら、この1ファイルの集合に追記して再配置するだけで、全リポジトリの許可が一斉に広がります。
クレジット消費の見通しを数字で持っておく
最後に、固定したモデル構成でひと月どれくらい消費するのか、ざっくりでも見積もっておくと安心です。私は次のような単純な式で「日次の許容トークン」を出し、それを超えそうな工程から軽いモデルへ寄せています。
月次クレジット（繰越なし）÷ 稼働日数 = 1日あたりの予算 1日あたりの予算 ÷ (主力モデルの平均単価) = 1日に回せるトークンの目安 たとえば月次クレジットが $100、稼働を 30 日とすると 1 日あたり約 $3.3 の予算です。私の環境では記事1本の生成が Haiku 中心で平均 4 万トークン前後に収まり、これを $3.3 の枠に当てはめると 1 日 6 本でも主力を Sonnet にしてよいかどうかが数字で見えてきます。推奨は、主力を 1 枚（Sonnet）に固定し、残りの枠を Haiku 降格でしのぐ二層構成から始めることです。実数を入れて計算しておくと、「Sonnet を主力に据えても予算内に収まるか」「混雑が続いて Haiku 降格が増えたらどう変わるか」といった問いに、感覚ではなく数字で答えられます。enforceAvailableModels で集合を絞っておけば、この試算に出てこない上位モデルが突然消費に混ざることがないので、見積もりと実績がずれにくくなります。予算管理の前提として、まず「使われ得るモデルの集合が確定していること」が効いてくるわけです。
繰越のない月次クレジットは、設計を少し変えるだけで驚くほど扱いやすくなります。まずやるべき一手は、お使いのマシンの管理設定に enforceAvailableModels を1行足し、許可するモデルを2〜3枚に絞ってから、上の逆説テストを一度走らせてみることです。床が効いていることを自分の目で確かめられれば、6月15日以降のバッチ運用はずいぶん見通しが良くなるはずです。