Claude Code settings は「見せない」ではなく「読ませない」で秘密を守る
このノートは原文の代替ではありません。読むべきポイントと実装上の意味を整理し、原典への入口を示します。
要点まとめ
- この docs の本当の論点は、秘密ファイルを『見つけにくくする』ことと『実際に読めなくする』ことは別だと切り分けた点にある。
- AI coding agent では、検索結果から隠しても別経路で読めるなら保護にならない。だから非表示より強い『読み取り拒否』が必要になる。
- Claude Code は旧 `ignorePatterns` から `permissions.deny` へ重心を移し、`Read(./.env)` のような読み取り自体を拒否する設計を前面に出した。
- つまり settings の紹介というより、ローカル秘密をどの層で機械的に読ませないかという情報境界の文書として読むべきだ。
読み終えたら次へ
この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。
何が変わったのか
原典が示している変化は、秘密ファイル保護の中心が旧 `ignorePatterns` から `permissions.deny` へ移ったことです。前者は見つけにくくする寄りの旧設定、後者は『この読み取り操作は拒否する』と決める設定です。docs は deny に一致したファイルについて、検索や一覧に出にくくなるだけでなく、read operation、つまりファイル内容を読む処理自体も拒否されると説明しています。秘密保護を UI 上の非表示ではなく、読む操作そのものの拒否として扱う点が本質です。
なぜ重要か
日本の導入現場では、AI agent の危険が外部送信に偏って語られ、ローカルで読まれる時点の漏えいが軽く見られがちです。しかし `.env`、認証情報 JSON、社内設定、生成物に埋め込まれた秘密は、読まれた時点で次の推論や外部送信の材料になります。だから『最初に読めない』境界が重要です。さらに managed、user、project、local という設定スコープを責任分界として使えるので、個人の convenience と組織統制を分けて設計する入口にもなります。
技術的ポイント
- `permissions.deny` は拒否ルールであり、`Read(./.env)` や `Read(./secrets/**)` のように特定の読み取り操作を止める設定として使う。
- 旧 `ignorePatterns` との違いは、防ぐ対象が discoverability だけで終わらないことだ。deny に一致したファイルは search results から外れるだけでなく、read operation も拒否される。
- managed、user、project、local の scope は、どこで決めたルールかを表す。permission rules は後ろの設定で単純に消えるのではなく重ねて効く。
- managed settings は IT や DevOps が配る中央ポリシーであり、秘密ファイル保護を個人の善意任せにしない設計へ寄せられる。
英日キーワード
| 英語 | 日本語 | 補足 |
|---|---|---|
| permissions.deny | 拒否ルール | Claude Code に特定操作を実行させない設定。秘密保護では『見つけにくさ』ではなく『読めなさ』を作る。 |
| ignorePatterns | 旧除外パターン | Claude Code の旧方式設定。検索や一覧から見えにくくする寄りで、現行の秘密保護の中心ではない。 |
| read operation | 読み取り操作 | agent がファイル内容を開いて読む処理。ここを拒否できるかが秘密保護の本体になる。 |
| sensitive files | 秘密ファイル | `.env`、鍵ファイル、認証情報 JSON など、agent に読ませたくない対象。 |
| configuration scope | 設定スコープ | managed、user、project、local のような設定の適用範囲。どこで決めたルールかを表す。 |
| managed settings | 管理設定 | 組織側が中央配布する設定。個人の convenience より強い統制を置きたい時に使う。 |
試すなら
- repo 直下と周辺にある `.env`、`secrets`、認証情報 JSON、生成成果物を棚卸しし、『検索に出したくない』対象と『読ませたくない』対象を分ける。
- `.claude/settings.json` か managed settings に `permissions.deny` を追加し、少なくとも `Read(./.env)`、`Read(./.env.*)`、`Read(./secrets/**)` 相当の拒否を先に置く。
- agent に依頼する前に、秘密ファイルを読もうとした時に本当に deny されるかを小さく検証し、search 非表示だけで満足しない。
注意点
- deny rule を置いても、別の場所へ複製された秘密や build 出力に埋め込まれた秘密までは自動では守れない。保護対象の棚卸しが先である。
- project scope の設定だけでは個人が別環境で外す余地がある。組織統制が必要なら managed scope まで上げる検討が要る。
この記事は役に立ちましたか
公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。