Claude Code managed settingsの適用結果を診断する

結論：設定ファイルの存在ではなく解決結果を見る

設定は存在していても、優先順位、managed policy、sandbox、network allowlistの別レイヤーで効かないことがあります。Settings公式資料でmanaged、command line、project local、shared project、userの優先順位を確認し、Security公式資料で信頼境界とsandboxの前提を確認します。既存のmanaged settingsのOTel監査は観測設計が主題で、本稿は「意図した制限が実際に効いているか」の診断に限定します。

warningが示す三つの問題

兆候	意味	読者が判断すること
外部linkのmanaged file	managed settings folder外を参照	配布元と更新責任を固定する
allowReadが無視される	managed policyがuserのsandbox pathを受けない	読めない範囲と代替経路を決める
allowed domainsが無視される	managed policyがuserのdomain指定を受けない	外部取得の停止・申請フローを決める

warningは「セキュリティが破られた」という断定ではなく、設定の意図と解決結果が一致しない可能性を知らせる材料です。一方で、業務が止まるからとuser設定で例外を足し続けると、組織の制限が見えなくなります。まず適用された値、次に業務影響、最後に期限付き例外を確認します。

8手順でscopeと実操作を診断する

1. 対象端末、Claude Codeのversion、managed settingsの配布元を記録します。
2. managed settings folder、link先、所有者、更新時刻を確認します。
3. 設定をmanaged、command line、project local、shared project、userへ分類します。
4. /statusとdoctorでwarning、policy、sandbox、domainの解決結果を保存します。
5. allowReadの対象pathを、許可されるpath、拒否されるpath、symlinkへ分けて試します。
6. allowed domainsを、許可domain、未登録domain、redirect先へ分けて試します。
7. 同じ設定で対話型sessionとCIを実行し、実行主体と適用scopeの差を記録します。
8. 意図と違う結果なら例外を追加せず、managed policyの所有者、影響、停止条件、再検証日を起票します。

診断では実データを読ませず、ダミーpathと管理下のtest domainを使います。linkを解決した結果が同じでも、更新権限や監査責任が外部へ移るなら運用上の問題です。逆に、読めないことが意図した機密境界なら、利用者へ「なぜ読めないか」と代替申請を伝えます。

設定scopeを比較する

scope	向く管理	診断の注意
managed	全利用者の制限、許可、監査	user設定で上書きできる前提にしない
project	repository固有の開発設定	共有ファイルの変更レビューが必要
local	個人端末の一時的な調整	CIや他端末へ伝播しない
command line	単一sessionの確認	恒久的な統制と混同しない

既存のHTTP hook許可先、WebFetch制御、symlink境界も関連します。とはいえ、domainが許可されていることと、hookやWebFetchがそのdomainを実際に使えることは別です。設定の読み込み、解決、実操作、ログを四つの証跡に分けると、過剰な許可を避けられます。

warningを運用チケットへ変換する

warningを見つけたら、設定担当者だけで閉じず、利用者が困る操作と管理者が守りたい境界を同じチケットへ書きます。たとえばallowReadが効かない場合、読めないpath、業務上必要な最小path、代替の受け渡し方法、承認期限を分けます。allowed domainsなら、domainの所有者、redirect先、データ送信の有無、停止時の代替資料を確認します。

linkのmanaged fileは、内容が正しくても配布経路が説明できないことがあります。誰がlinkを作り、どのrevisionを承認し、更新時に誰が差分を見るかを固定します。端末ごとの解決結果を同じformatで集め、warningが消えたかだけでなく、意図しない許可が増えていないかを比較します。policy変更後は小さな利用者群で再検証し、CIへ広げる順番を決めます。

診断の結果は、設定名だけでなく、端末、利用者、repository、session、実操作、期待値、実測値を結び付けて残します。管理者がpolicyを更新した後に同じテストを行えば、warningの解消と引き換えに許可範囲が広がっていないかを比較できます。期限付き例外は自動で延長せず、業務責任者が再承認する日を先に設定します。

公開前チェックリスト

• managed fileのlink、所有者、更新責任を記録した
• scopeの優先順位を端末ごとに確認した
• statusとdoctorのwarningを保全した
• allowReadを許可・拒否・symlinkで試した
• allowed domainsをredirect先まで試した
• 対話型とCIの解決結果を比較した
• 例外の期限、承認者、再検証日がある

企業運用で重要なのは、利用者が「設定を書いたのに効かない」と感じた時、local設定を増やす前に管理側へ戻せることです。managed policyの目的、制限対象、業務影響、申請窓口、解除条件を一枚にまとめます。warningを消すことを成功条件にせず、意図した境界が再現できることを合格条件にします。

FAQ

managed settingsのwarningを無視してよいですか？

無視せず、どのmanaged keyがuserやprojectの設定を上書きしたか、意図した制限か、業務停止を生むかを確認します。

allowReadを追加すれば読めますか？

managed settingsが許可pathを無視する設定なら、localへ追加しても有効とは限りません。statusとdoctorで解決結果を確認します。

Claude Codeの設定診断を相談できますか？

できます。scope、対象path、domain、権限、例外、監査を無料診断（60秒）で整理します。