結論：Claude Codeを業務導入するなら、作業ディレクトリ外の読み取りは「初回確認を出す設定」「Read deny」「サンドボックスのdenyRead」の3層で設計します。v2.1.257で追加されたpermissions.blockReadsOutsideWorkingDirectoriesだけを有効にして終わり、ではありません。
- 新しい境界：v2.1.257では、auto modeが作業ディレクトリ外のファイルを初めて読む前に一度確認し、以後の外部読み取りをブロックする選択肢が追加されました。
- 役割の違い：Read denyはClaude Codeのファイル系ツールを制御し、sandboxの
denyReadは有効化されたサンドボックス内のBashと子プロセスをOSレベルで制約します。 - 導入手順：対象パスの棚卸し、管理設定、機密パスのdeny、サンドボックス、回帰試験の5段階で進めます。
対象読者：Claude Codeをチームへ導入するエンジニア、DevSecOps、プラットフォーム担当、情報システム部門
最初の一手：検証用リポジトリでclaude --versionを記録し、作業ディレクトリ外のダミーファイルを読む試験を1回実施してください。
「リポジトリの外は書けない設定だから、ホームディレクトリの認証ファイルも読まれないはず」。この理解は、Claude Codeの権限設計では危険です。書き込み境界、ファイルツールの読み取り境界、Bashプロセスの読み取り境界は同じではないからです。
Anthropicの公式セキュリティ文書によると、Manual modeではRead・Grep・Globが作業ディレクトリ外を読む前に確認を求めます。一方、auto modeは従来、作業ディレクトリ外を確認なしで読める扱いでした。公式changelogのv2.1.257には、この差を意識した初回確認とpermissions.blockReadsOutsideWorkingDirectoriesが追加されたと記載されています。
この記事は特定企業の成果紹介ではなく、記事区分：実装パターン解説です。2026年9月3日に再取得したAnthropic公式文書を基に、再現可能な設定例と試験項目を組み立てます。機密情報をClaude Codeへ渡してよいという意味ではありません。所属組織のセキュリティ規程とデータ取り扱い基準を優先してください。
外部読み取り制御を1枚で理解する
最初に、混同しやすい3つの仕組みを分けます。ここが曖昧なままJSONを足すと、「Readでは拒否されたのにBashのcatでは読めた」「サンドボックスを切ったらdenyReadが効かなかった」という状態になります。
| 制御 | 主な対象 | 目的 | 重要な注意 |
|---|---|---|---|
permissions.blockReadsOutsideWorkingDirectories |
auto modeの外部ファイル読み取り | 作業範囲の外へ広がる読み取りを止める | v2.1.257で追加。全ツールを一律にOS隔離する機能とは説明されていない |
permissions.denyのRead(...) |
Read、Grep、Glob、@fileなどのファイル系操作 | 機密ファイルや機密ディレクトリを明示的に拒否する | 公式文書は一部をbest-effortと説明。Bash隔離とは別 |
sandbox.filesystem.denyRead |
サンドボックス内のBashと子プロセス | OSレベルで読み取り可能範囲を狭める | サンドボックス有効時だけ適用。より具体的なallowReadで再許可可能 |
Manual modeとauto modeでは出発点が違う
Manual modeは、作業ディレクトリ外をRead・Grep・Globで読む前に確認します。auto modeはツール呼び出しを背景の安全チェックで自動承認するモードです。v2.1.257の新機能は、auto modeでも外部読み取りの最初に境界を認識させるものです。
ただし、「確認が出る」と「OSがアクセスを拒否する」は別です。人が承認すれば進める確認フローと、プロセス自体にアクセスを許さないサンドボックスは、脅威モデルが違います。業務導入では片方に寄せず、機密度に応じて重ねます。
additionalDirectoriesは例外ではなく作業範囲の拡張
--add-dir、/add-dir、permissions.additionalDirectoriesは、Claude Codeが読み書きできる作業ディレクトリを増やします。共有ライブラリや別ワークツリーを扱うには便利ですが、外部読み取りを閉じたい設計とは逆方向の設定です。
公式Permissions文書は、設定ファイルのadditionalDirectoriesがファイルアクセスだけを与え、追加先を完全な設定ルートにはしないと説明しています。つまり、別ディレクトリを足したからといって、その配下のすべての.claude/設定が自動的に同じ意味で読み込まれるわけではありません。権限範囲と設定探索範囲を分けてレビューしてください。
チーム向けの既存設計も見直すなら、Claude Code権限設計ガイドを先に読み、allow・ask・denyの優先関係を揃えておくと進めやすいです。
v2.1.257で何が変わったのか
初回の外部読み取りに確認が入る
Anthropic公式changelogのv2.1.257には、auto modeで作業ディレクトリ外のファイルを初めて読む前に一度プロンプトを表示し、その読み取りをブロックする選択肢としてpermissions.blockReadsOutsideWorkingDirectoriesを追加した、とあります。
この変更の実務上の価値は、auto modeを「完全に無人でどこでも読むモード」として扱わず、セッション開始後の最初の境界越えを見える化できる点です。モノレポの親ディレクトリ、ホーム配下の設定、隣接リポジトリ、ビルドキャッシュなど、開発者の端末には意図せず参照できる場所が多くあります。
なお、2026年9月3日時点で公式changelogの先頭はv2.1.258です。v2.1.258はmacOS 12の起動回帰とRemote・scheduled sessionの不具合修正が中心で、外部読み取り設定の追加自体はv2.1.257欄にあります。導入検証では「最新版か」だけでなく、どの版で権限挙動が変わったかを記録してください。
新設定は機密パス一覧の代わりではない
作業ディレクトリ外を一括して意識させる設定は便利ですが、リポジトリ内にも秘密は置かれます。たとえば.env、クラウド資格情報の一時ファイル、テスト用の顧客データ、診断ログです。これらは「外にあるから危険」なのではなく、「内容が機密だから拒否すべき」対象です。
そのため、境界全体をブロックする新設定に加えて、permissions.denyへ具体的なReadルールを置きます。公式文書は、Read denyが同じパスのEdit・Writeにも影響すると説明しています。ただしNotebookEditまで同じ仕組みで完全に覆うわけではないため、変更禁止を厳密にする場合はEditルールも別途設計します。
5手順で設定する
手順1：作業範囲と機密範囲を分けて棚卸しする
最初にJSONを書かず、読み取りが必要な場所と拒否する場所を表にします。最低でも次の4分類が必要です。
- 作業ルート：現在のGitリポジトリ
- 許可する追加ルート：共有ライブラリ、生成物置き場、別ワークツリー
- 常時拒否：資格情報、秘密鍵、環境変数ファイル、個人データ
- 確認付き：隣接リポジトリ、ホーム配下の一般設定、過去ログ
「ホーム全体を許可して、秘密ファイルだけdenyする」より、「必要なディレクトリだけ追加して、機密パスをさらにdenyする」方がレビューしやすくなります。広いallowと狭いdenyが重なるときは、公式設定文書の優先規則を確認してください。
# 検証用。値そのものは表示せず、候補パスだけ棚卸しする
pwd
find .. -maxdepth 2 -type d -name .git -print
printf '%s\n' "$HOME/.ssh" "$HOME/.aws" "$HOME/.config" "./.env"
手順2：外部読み取りブロックを設定する
v2.1.257以降を前提に、設定ファイルのpermissionsへ次を置きます。まず検証用端末でUserまたはManaged設定として配り、挙動を確認してから対象を広げてください。
{
"permissions": {
"blockReadsOutsideWorkingDirectories": true
}
}
組織でauto mode自体を許可しない場合は、同じ公式Permissions文書にあるpermissions.disableAutoModeも選択肢です。どちらを採るかは、「auto modeを使いながら読み取り境界を狭める」のか、「そもそもauto modeを禁止する」のかで決めます。
Managed settingsは設定優先順位の最上位です。公式Settings文書によれば、コマンドライン引数やプロジェクト設定から同じキーを上書きできません。組織の必須統制はManaged、プロジェクト固有の制限追加はProjectという分担にすると、責任範囲が明確です。
手順3：Read denyで機密パスを明示する
次に、リポジトリの内外を問わず読ませないパスをpermissions.denyへ追加します。以下は形を示す例です。実在の秘密値は記事にも設定レビューにも貼らないでください。
{
"permissions": {
"blockReadsOutsideWorkingDirectories": true,
"deny": [
"Read(./.env)",
"Read(./secrets/**)",
"Read(~/.ssh/**)",
"Read(~/.aws/**)"
]
}
}
公式Permissions文書は、Readルールのパス構文とsandboxのパス構文が異なる点も説明しています。見た目が似ていても、そのまま相互コピーしないでください。さらに、denyはどの設定スコープにあってもallowより先に評価されるため、プロジェクトのallowでユーザー側denyを打ち消す、といった設計はできません。
手順4：Bashを使うならsandbox denyReadを重ねる
Claude CodeのReadツールだけを止めても、Bashからcat、python、tar、子プロセスなどを実行できれば、別の読み取り経路が残ります。そこでサンドボックスを有効にし、sandbox.filesystem.denyReadを組み合わせます。
{
"permissions": {
"blockReadsOutsideWorkingDirectories": true,
"deny": [
"Read(./.env)",
"Read(./secrets/**)",
"Read(~/.ssh/**)",
"Read(~/.aws/**)"
]
},
"sandbox": {
"enabled": true,
"filesystem": {
"denyRead": [
"~/.ssh",
"~/.aws",
"~/.config/cloud"
]
}
}
}
公式Sandboxing文書によれば、filesystem isolationはBashとその子プロセスへOSレベルで適用されます。重なるルールでは、より具体的なパスが優先されます。たとえばホーム全体をdenyし、プロジェクトだけをallowReadで再許可する構成も可能です。ただし、設定ファイルの置き場所によって相対パスの基準が変わります。Project設定の.はプロジェクトルートですが、User設定では~/.claudeを基準に解決されるため、同じJSONを無条件に移動しないでください。
サンドボックス全体の設計はClaude Code v2.1.251の安全確認7項目も参照してください。シンボリックリンクやプラグイン経路を含む回帰試験まで広げられます。
手順5：許可・拒否・確認の3結果を回帰試験する
設定後は「秘密ファイルが読めなかった」だけで合格にしません。通常のリポジトリファイルは読める、追加許可した共有ディレクトリは読める、拒否対象はReadでもBashでも読めない、という3結果を確認します。
# 検証用のダミー構成を作る。実際の資格情報は使わない
mkdir -p /tmp/cc-boundary-demo/project /tmp/cc-boundary-demo/outside
printf 'public fixture\n' > /tmp/cc-boundary-demo/project/fixture.txt
printf 'dummy secret for boundary test\n' > /tmp/cc-boundary-demo/outside/blocked.txt
cd /tmp/cc-boundary-demo/project
claude
対話内では、fixture.txtの読み取り、外部blocked.txtのRead、Bash経由の読み取りを別々に依頼します。テスト後はダミーファイルを削除します。期待結果と実結果を変更チケットへ残し、Claude Codeのバージョン、OS、permission mode、設定ソースを添えてください。
設定スコープをどう分担するか
Managedは最低線、Projectは追加制限に使う
チーム導入で最も避けたいのは、各開発者が同じルールを手作業で再現することです。Managed settingsには、組織全体で外せない最低線を置きます。たとえばauto modeの可否、外部読み取りブロック、資格情報ディレクトリのdenyです。
Project設定には、そのリポジトリ固有の機密パスやビルド用ディレクトリを置きます。ローカル設定は、個人端末だけの追加制限や一時的な検証に使います。Projectのallow系ルールやadditionalDirectoriesはワークスペースの信頼後に適用される一方、denyとaskは制限を強めるため先に効く、という公式仕様もレビュー項目です。
設定変更後はdoctorと実動作の両方を見る
JSONとして正しくても、想定した設定ソースから読まれていない可能性があります。claude doctorで無効な設定や破損した設定を確認し、/statusで読み込まれた範囲を確認します。そのうえで前節の実動作試験を行います。
claude --version
claude doctor
# 対話開始後
/status
設定ファイルの内容を共有するときは、環境変数の値、トークン、パスワード、内部ホスト名を除去してください。設定のスクリーンショットにも秘密値が映ることがあります。レビュー対象はルールであり、秘密そのものではありません。
Claude Codeへ渡すレビュー指示5つ
Claude Code自身に設定レビューを支援させる場合も、秘密値を読ませない前提を明記します。以下は出力をそのまま採用するためではなく、人間のレビュー観点を揃えるための指示です。
指示1：権限境界の棚卸し
このリポジトリで必要な読み取り範囲を、作業ルート、追加許可候補、常時拒否候補、確認付き候補の4分類で整理してください。ファイル内容は読まず、パス名と設定ファイルの宣言だけを確認してください。資格情報の値は出力しないでください。不足している情報があれば、最初に質問してから作業を開始してください。指示2：設定スコープのレビュー
Claude CodeのManaged、User、Project、Project localの設定候補を比較し、各ルールをどのスコープに置くべきか提案してください。denyを弱める提案は禁止です。仮定した点は必ず「仮定」と明記し、公式ドキュメントの該当URLを添えてください。指示3：Read denyの静的点検
permissions.deny内のReadルールだけを静的レビューしてください。機密ファイルの抜け、広すぎる拒否、パス構文の誤りを分類し、修正案をdiff形式で示してください。実ファイルの内容は読み取らないでください。不足している情報があれば、最初に質問してください。指示4：sandbox設定の試験計画
sandbox.filesystem.denyReadとallowReadの境界試験を設計してください。許可1件、拒否1件、より具体的な再許可1件、子プロセス経由1件を含め、実在の資格情報を使わないダミーデータだけで実行できる手順にしてください。期待結果とロールバック手順も書いてください。指示5：リリース更新時の回帰確認
現在のClaude Codeバージョンと公式changelogを基に、外部読み取り、Read deny、sandbox denyReadに関係する変更だけを抽出してください。変更が確認できない項目は「確認できず」と書き、推測で補完しないでください。数字と固有名詞には出典URLを添えてください。これらの指示でも、最終判断は人間が行います。特に「安全」「準拠」「漏えいしない」といった断定をAIに作らせないでください。設定はリスクを下げる手段であり、情報セキュリティ認証や法令適合を自動的に保証するものではありません。
【要注意】よくある失敗パターンと回避策
失敗1：外部ブロックだけで.envも守れると思う
❌ blockReadsOutsideWorkingDirectoriesを有効にしたので、プロジェクト内の.envも保護されたと判断する。
⭕ 外部境界と機密パスは別に扱い、Read(./.env)やRead(./secrets/**)をdenyへ明示する。
理由：作業ディレクトリ内外という位置の分類と、情報の機密性は一致しないからです。
失敗2：Read denyをBashのOS隔離だと思う
❌ Readツールが拒否されたので、すべてのシェルコマンドと子プロセスも同じ強度で拒否されると考える。
⭕ ファイルツールのルールとサンドボックスのfilesystemルールを分け、Bash経路を別に試験する。
理由：公式文書はRead denyとsandbox denyReadを別の仕組みとして説明しています。前者の一部適用はbest-effort、後者は有効なサンドボックス内でOSレベルに適用されます。
失敗3：additionalDirectoriesへホーム全体を入れる
❌ 参照エラーを減らすために~/を追加し、すべての隣接リポジトリと設定を作業範囲へ入れる。
⭕ ビルドや参照に本当に必要なディレクトリだけを追加し、追加理由と所有者を記録する。
理由：確認回数は減っても、読み取り可能面が広がります。利便性の改善と境界の縮小を同時に達成したことにはなりません。
失敗4：最新版へ上げただけで検証を終える
❌ v2.1.258へ更新できたため、既存設定も意図どおり動くと判断する。
⭕ 更新前後で許可・拒否・確認のテストケースを実行し、設定ソースとpermission modeを含む証跡を残す。
理由：バージョン更新は機能を届けますが、組織固有の設定内容や相対パスの解決まで保証しません。既存のauto mode標準化の移行7手順と組み合わせ、カナリア端末から広げてください。
導入前QAチェックリスト
- Claude Codeのバージョンを記録した
- 公式changelogで対象設定の追加版を確認した
- Manualとautoのどちらを許可するか決めた
- 作業ルートとadditionalDirectoriesを一覧化した
- プロジェクト内の機密パスをRead denyへ入れた
- Bashを許可する場合のsandbox denyReadを設計した
- Managed、User、Project、Localの責任分担を決めた
- 実在の秘密値を使わないダミー試験を作った
- ReadとBashを別々に試験した
- 失敗時に戻す設定ファイルのバックアップを確保した
サンドボックスをCIや自己ホスト環境へ広げる場合は、Claude Codeセルフホスト実行ガイドも確認してください。ローカル端末とランナーでは、ホーム、資格情報、テンポラリ領域の構成が異なります。
FAQ
Q1. blockReadsOutsideWorkingDirectoriesはどのバージョンで追加されましたか？
Anthropic公式changelogではClaude Code v2.1.257の項目として記載されています。導入時はclaude --versionで実機を確認し、最新版の公式changelogも再確認してください。
Q2. この設定だけで秘密鍵の読み取りを防げますか？
この設定だけであらゆる読み取り経路を完全に遮断できる、とは公式文書から断定できません。機密パスにはRead denyを明示し、Bashを使う場合はサンドボックスのdenyReadも検討してください。実在の秘密値ではなくダミーファイルで回帰試験します。
Q3. Manual modeでも設定する意味はありますか？
公式セキュリティ文書では、Manual modeは作業ディレクトリ外をRead・Grep・Globで読む前に確認します。新設定はchangelog上、auto modeの初回外部読み取りに関する追加です。Manualを採る場合でも、機密パスのdenyとBash経路の検証は別途必要です。
Q4. additionalDirectoriesを設定すると、その中の設定も全部読み込まれますか？
いいえ。公式Permissions文書は、設定ファイル内のpermissions.additionalDirectoriesはファイルアクセスを付与するもので、追加先を完全な設定ルートにはしないと説明しています。--add-dirや/add-dirには一部の設定要素を読む例外があるため、使った方法まで記録してください。
Q5. Read denyとsandbox denyReadはどちらを優先すべきですか？
代替関係ではありません。Read denyはClaude Codeのファイル系ツール、sandbox denyReadはサンドボックス内のBashと子プロセスという異なる面を守ります。Bashを使わない運用でもRead denyは有効です。Bashを使う運用では両方を試験してください。
Q6. 設定したら情報漏えい対策は完了ですか？
完了とは言えません。権限設定、サンドボックス、秘密管理、端末管理、ログ管理、利用者教育を組み合わせます。Claude Codeは補助ツールであり、組織のセキュリティ責任者や法務判断を代替しません。所属組織の規程と最新の公式文書に従ってください。
参考・一次情報
- Claude Code changelog — Anthropic公式。v2.1.257の外部読み取り確認とv2.1.258の修正内容（参照日：2026-09-03）
- Claude Code Permissions — Anthropic公式。permission mode、Readルール、additionalDirectories、設定優先順位（参照日：2026-09-03）
- Claude Code Security — Anthropic公式。Manualとautoの作業ディレクトリ境界（参照日：2026-09-03）
- Claude Code Sandboxing — Anthropic公式。filesystem denyRead、allowRead、OSレベルの隔離（参照日：2026-09-03）
- Claude Code Settings — Anthropic公式。ManagedからProjectまでの設定スコープと優先順位（参照日：2026-09-03）
結論と次の一歩
Claude Codeの外部読み取り制御は、単一のスイッチではなく、境界・機密パス・実行プロセスを分けて設計するのが要点です。v2.1.257でauto modeの初回外部読み取りを扱う設定が加わりましたが、Read denyとsandbox denyReadの役割は残ります。
- 今日：作業ルート、追加許可、常時拒否、確認付きの4分類を作る
- 今週：検証端末へ3層の設定を入れ、ReadとBashのダミー試験を実行する
- 展開前：Managed設定とProject設定の責任分担、ロールバック、更新時の回帰試験を文書化する
Claude Codeを「個人で動く設定」から「チームで説明できる設定」へ進めたい方へ。
Uravationでは、既存リポジトリと組織ポリシーを前提に、権限境界、サンドボックス、段階導入、評価手順の設計を支援しています。まずは機密値を含まない設定一覧と、現在困っている確認ダイアログのパターンを整理すると、相談が具体的になります。
