結論：Preで判断し、Postで記録する

企業利用では、PreModelSwitchを許可・確認・拒否の判断点、PostModelSwitchを実際に切り替わった結果の記録点として分けます。最新のClaude Code公式releaseでは両hook eventが追加され、モデル切替をblock、confirm、annotateできると説明されています。全切替を止めるのではなく、契約外モデル、承認されていないprovider、機密区分に合わないmodelだけをpolicyで止めるのが実務的です。

読者の具体的な困りごとは、利用者が作業途中で高額または未承認のモデルへ切り替えても、管理者が理由と結果を追えないことです。読了後には、切替を自動許可する条件、人へ確認する条件、拒否する条件を決められます。次の行動は、代表3業務で切替eventを観測し、拒否を有効化する前に誤検知を洗い出すことです。

モデル選択は品質だけでなく、料金、context、provider、data handling、利用枠へ影響します。ただしhookは契約条件そのものを変更せず、利用可能なmodelや料金を保証しません。公開直前にClaude Code changelog、Hooks reference、利用中planの料金表を照合し、model aliasではなく実際のmodel識別子を証跡へ残します。

公式仕様と適用範囲を確認する

公式releaseが示す新機能は、切替前後に処理を差し込めることです。Pre側では切替をblockする、利用者へconfirmを求める、判断材料をannotationとして加える設計ができます。Post側では切替完了後の情報を監査先へ送り、session中のmodel変遷を再構成します。hook commandが失敗した場合に許可するか拒否するかは業務riskで決め、障害時の既定動作を曖昧にしません。

Hooks公式文書に従い、event名、matcher、入力JSON、終了結果、設定scopeを対応versionで確認します。user設定だけに置くと本人が変更できるため、企業policyはmanaged settingsなど管理可能なscopeを優先します。project設定はrepository単位の運用には便利ですが、forkや古いbranchへ残る可能性を考慮します。CLI、IDE、Remote Controlなど利用経路別に同じeventが届くかtestし、未確認経路を「保護済み」と扱いません。

切替前の入力には、現在model、候補model、session情報など判断に必要な値が含まれるかを実データで確かめます。文書にないfieldへ依存せず、欠損時は安全側の確認へ回します。annotationへ機密promptや認証情報を入れず、利用者へは拒否理由と申請先だけを短く返します。hookの標準出力やerrorがsession transcriptへ残る可能性も含めてdata分類します。

許可・確認・拒否を6軸で比較する

  1. 契約：契約と管理者設定で利用可能なmodelだけを許可候補にします。
  2. 費用：単価だけでなくcontext量、再試行、cache、月額上限を含めます。
  3. 機密区分：入力dataの区分とprovider、region、retention条件を対応させます。
  4. 品質：承認済み評価setで合格した用途だけ自動許可します。
  5. 変更理由：障害回避、長文処理、品質改善など選択式で記録します。
  6. 例外期限：一時承認はownerと失効時刻を必須にします。

低riskな公開文書の要約で、同一provider内の承認済みmodelへ移る場合は自動許可が候補です。顧客情報を扱うsessionや料金が大きく変わる切替はconfirmへ回します。契約外model、評価前model、禁止provider、識別子不明のaliasは拒否します。切替回数が多いsessionは設定不良や品質問題の兆候としてalertを上げます。

確認dialogへ長い規程を表示しても読まれません。「何が変わるか」「費用またはdata条件」「承認の有効範囲」を一画面で示します。承認はsession単位を基本とし、永久許可にしません。管理者の例外承認も同じaudit logへ入れ、口頭承認だけで通さない設計にします。

段階導入する7手順

  1. Claude Code対応versionと利用経路を棚卸しします。
  2. 承認済みmodel識別子、provider、用途、料金確認日を台帳化します。
  3. PreModelSwitchを観測modeで設定し、切替候補と理由を一週間収集します。
  4. PostModelSwitchで実際の切替結果をsession IDへ結びます。
  5. 公開情報、社内情報、機密情報の代表sessionでevent内容をtestします。
  6. 契約外と識別子不明だけを拒否し、次に費用・機密条件を追加します。
  7. 誤拒否率、確認率、例外数、切替後の品質を月次reviewします。

testでは、許可、確認後許可、利用者cancel、policy拒否、hook timeout、監査先停止の6ケースを実行します。Preで許可されてもPostが届かない場合は切替結果を確定できないため、session終了時の状態と突合します。hook更新は設定revisionと適用時刻を記録し、旧policyとの混在を検知します。

企業運用チェックリストとHOLD条件

  • 対応versionを固定した
  • 正式なmodel識別子を使う
  • 利用可能planを確認した
  • 料金確認日がある
  • PreとPostの役割を分けた
  • CLIとIDEをtestした
  • Remote経路をtestした
  • managed scopeを優先した
  • 失敗時の既定動作がある
  • 拒否理由が利用者に分かる
  • 例外にownerと期限がある
  • 秘密情報をlogへ出さない
  • session終了時に突合する
  • rollback手順がある

HOLD条件は、eventが利用経路で発火するか未確認、model aliasの解決先が不明、契約・料金を再確認していない、監査先へ機密promptを送る、hook障害時の動作が未定の場合です。新hookだけで完全な費用統制やdata境界が成立すると説明してはいけません。gatewayのspend limit、権限、入力禁止情報、定期監査を併用します。

よくある質問と次の行動

Postだけで禁止モデルを止められますか？

事後eventなので、切替前の拒否にはPreを使います。Postは結果記録とalertに使います。

全切替で管理者承認が必要ですか？

承認済み範囲は自動許可し、高risk条件だけ確認へ回す方が運用負担を抑えられます。

費用上限もhookで保証できますか？

hookは判断点です。実際の上限は契約、gateway、usage設定と合わせて管理します。

一次情報はClaude Code公式release、Hooks公式文書、提供条件はAnthropic公式pricingです。関連するHooksの基本、更新channelの選び方、コスト管理も確認してください。Miraigentの無料診断では、承認境界と例外手順を60秒で整理します。