結論：前回承認との差分をsecurity boundary別に審査する
Claude Codeのmanaged settingsは、設定全文を漫然と承認せず、前回承認から変わったkey、配布主体、適用scope、security boundaryへの影響、rollbackを一件ずつ確認します。2.1.251では承認dialogが変更された設定だけを列挙し、sandbox TLS終端、独自proxy、credential注入、sandbox isolationを弱めるserver-managed settingsは適用前承認の対象になりました。
困りごとは、再loginや管理者更新のたびに長い設定一覧が出て、何が変わったのか分からないまま利用者が承認してしまうことです。読了後には、即時承認、管理者へ照会、利用停止の三つを設定riskで判断できます。次の行動は、managed settingsのowner、配布経路、前回承認revision、緊急連絡先を一枚の台帳へ固定することです。
公式changelogは、同じClaude apps gatewayへ再loginし設定が不変なのに承認promptが再表示される問題の修正も案内しています。promptが出ないことを「設定検証不要」と解釈せず、管理側のrevisionとclient状態を定期的に照合します。server-managed settingsは組織が配布する統制面ですが、配布主体の誤設定や侵害まで自動的に防ぐものではありません。
変更を4分類して判断する
- 情報表示：UIや説明の変更でsecurity boundaryを変えないものは、ownerと影響範囲を確認します。
- routing：proxy、base URL、tenant headerは通信先とdata経路を変更するため、証明書と契約を確認します。
- credential：credential注入や認証headerはsecretの入手元、scope、rotation、log非表示を確認します。
- isolation：sandbox TLS終端、network経路、sandbox弱化は最もriskが高く、security ownerの承認へ回します。
ANTHROPIC_CUSTOM_HEADERSがAuthorization、Host、org/tenant、API behaviorへ影響するheaderを設定する場合も、2.1.251では承認が必要になる変更が案内されています。header名だけで判断せず、値の供給元、送信先、mask、rotationを確認します。project settingsから詳細beta tracingやraw API body loggingを有効にできた経路も修正対象に含まれるため、log destinationと収集項目を再点検します。
承認者は「会社から来た設定だから安全」と一括判断しません。managed policyの署名・配布経路、管理consoleのactor、change ticket、適用対象groupを照合します。緊急変更でも、有効期限と自動rollbackを付けます。設定がsession途中で到着する場合、既存sessionへどう反映されるかも確認し、必要なら安全な停止点で再起動します。
料金はmanaged settings承認に固定課金されるというより、Claude契約、gateway、model利用、networkやlog基盤に依存します。proxyやgateway変更で請求主体、rate limit、data residencyが変わる可能性があるため、pricingと契約条件を公式情報および管理者に確認します。
承認前の9手順
- Claude Code versionと公式changelogを確認します。
- promptに表示された変更keyとold/new valueを記録します。
- 管理台帳のrevision、change ticket、配布actorを照合します。
- 適用scopeがuser、project、organizationのどれか確認します。
- routing、credential、isolation、loggingへの影響を分類します。
- 送信先domain、certificate、proxy owner、data regionを確認します。
- secretのscope、rotation、mask、監査logを確認します。
- test groupで通信、permission、sandbox、rollbackを検証します。
- 承認者、時刻、revision、検証結果、次回review日を記録します。
変更diffに値がmaskされている場合も、完全なsecretを利用者へ表示する必要はありません。代わりにsecret ID、issuer、scope、更新時刻、送信先を確認できる管理情報を用意します。raw API body loggingやtracingは、障害調査に便利でもprompt、tool input、personal dataを外部collectorへ送る可能性があるため、保存期間と閲覧権限を確認します。
rollbackは「元に戻す」だけでなく、clientが古いsettingsをcacheしていないか、既存sessionが新旧どちらを使うか、gateway credentialをrotationしたかまで確認します。適用後は/statusや組織が指定する診断面で取得状態を確認し、代表taskをread-onlyで実行します。本番writeを最初の検証に使いません。
チェックリストとHOLD条件
- versionを確認した
- 変更keyだけを抽出した
- old/newを比較した
- 配布actorを確認した
- change ticketがある
- scopeを確認した
- 通信先を確認した
- credentialをmaskする
- data regionを確認した
- test groupで検証した
- rollbackがある
- 承認記録を残した
- 再login時の状態を確認した
HOLD条件は、変更理由がない、配布actorが不明、未知のproxyやHostへrouting、credentialが平文表示、sandbox isolation弱化のowner未承認、raw body logの保存先不明、rollback不能な場合です。業務を急ぐことを理由に利用者へ一括承認させず、必要ならClaude Codeの利用を一時停止します。
よくある質問と次の行動
差分表示なら必ず安全ですか？
差分は確認範囲を狭めますが、配布主体や値の妥当性は別途検証します。
promptが再表示されない場合は承認済みですか？
同一gatewayで設定不変なら再表示問題が修正されていますが、管理revisionとの定期照合は必要です。
誰を承認者にしますか？
routingはnetwork owner、credentialはidentity owner、isolation弱化はsecurity ownerを含めます。
一次情報はClaude Platform公式release notesとClaude Agent SDK permissions公式文書です。関連するworkspace trust、sandboxのread deny、release channelの選び方も確認してください。Miraigentの無料診断では、managed settingsの承認境界を60秒で整理します。