【中級者向け】settings.jsonの編集経験がある人向け。JSON設定の書き方自体は説明しますが、Claude Codeの基本操作（起動・権限プロンプトの意味）は既知として進めます。
無人サーバーでClaude Codeにcronジョブを任せたい。でも「AWS_SECRET_ACCESS_KEY」や「GITHUB_TOKEN」を環境変数に置いたまま自動実行させて、万一おかしなコマンドを実行されたら、その値がそのままログや外部に漏れるのではないか——そう考えて二の足を踏んだことはありませんか。
Claude Codeのサンドボックス機能には、認証情報そのものをコマンドに見せずにツールだけ正常に動かす「mask」という仕組みがあります。さらに2026年9月には、ネットワークアクセスをコマンド単位で制御する「per-command allowed domains」がauto modeに追加されました。この記事では、denyとmaskの使い分け、AWSキーやGitHubトークンを安全に扱う具体的なsettings.json、そして無人実行環境で踏みやすい落とし穴を、公式ドキュメントの記載に沿って整理します。TL;DR
この記事でできること
- Claude Codeサンドボックスの「認証情報を守る」機能（deny/mask）を理解し、自分の環境に適用できる
- AWSキー・GitHubトークン・npmトークンなど、実際によく使う認証情報ごとの設定例を持ち帰れる
- 2026年9月に追加された、auto modeでのper-command allowed domainsの仕組みを理解できる
- サンドボックス導入時によくあるエラーと対処法が分かる
対象読者
- cron・CI/CDでClaude Codeを無人実行している、またはこれから始める人
- Claude CodeにAWS/GitHub/npm等のCLIツールを触らせたいが、認証情報の扱いが不安な人
- 「--dangerously-skip-permissions」のような強い権限モードを避けつつ自動化したい人
情報源・確認日
- 情報源: Claude Code公式ドキュメント（code.claude.com/docs/en/sandboxing）、公式Changelog（2026年9月分）
- 確認日: 2026-09-23
- 対象バージョン: 記事中に明記（機能ごとに要求バージョンが異なるため）
サンドボックスとは何か、なぜ必要なのか
Claude Codeの「サンドボックス」は、BashやPowerShell、Monitorツール（とその子プロセス）が触れるファイルとネットワーク接続先を、OSの機能で強制的に制限する仕組みです。macOSでは標準搭載のSeatbeltを、Linux/WSL2ではbubblewrap（隔離）とsocat（ネットワークプロキシの中継）を使います。
普通、Claude Codeはコマンドを実行する前に「このコマンドを実行していいですか？」と確認を求めます。無人実行（「claude -p」）ではこの確認に誰も答えられないため、多くの現場は「--dangerously-skip-permissions」のような「全部許可」モードに頼りがちです。
しかしこれは、Claudeが誤って「rm -rf」のような破壊的なコマンドを実行したり、環境変数に置いた秘密情報をそのまま外部へ送信するコマンドを実行したりするリスクをそのまま受け入れることになります。
サンドボックスはこの問題への別解です。「何でも許可する」のではなく、「許可された範囲の外には、たとえClaudeが実行しようとしても物理的に届かない」状態を作ります。ファイルは決められたディレクトリだけ、ネットワークは決められたドメインだけ。この境界はOSレベルで強制されるので、Claudeがどう判断したかに関わらず有効です。
無人サーバーでcronにClaude Codeを任せてるんですが、AWS_SECRET_ACCESS_KEYを環境変数に置きっぱなしなのがずっと気になってます。もし変なコマンドを実行されたら、そのままキーが漏れますよね……
そうですね。サンドボックスのcredentials設定を使うと、その心配にちゃんと対処できます。実は『完全にブロックする』か『動かしつつ隠す』かの2択があって、用途によって使い分けるのがポイントです
何が便利なのか
サンドボックスなしとありで、無人実行時にできること・守られるものがどう変わるかを整理します。
| 項目 | サンドボックスなし | サンドボックスあり（deny/mask併用） |
| ファイルアクセス | 作業ディレクトリ外も含め、権限確認をすり抜ければ広く読み書き可能 | 作業ディレクトリと明示的に許可したパスのみ書き込み可能 |
| ネットワーク接続 | 許可した範囲内で任意のホストへ到達可能 | 事前許可ドメイン＋（auto modeなら）コマンドごとの申告ドメインのみ |
| 環境変数の認証情報 | コマンドがそのまま値を読み書き・出力できる | denyなら消去、maskならコマンドにはダミー値しか見えない |
| ログへの秘密情報混入 | コマンドの標準出力やエラーメッセージにそのまま出うる | maskならログ・出力に本物の値が一切現れない |
| 「--dangerously-skip-permissions」との関係 | 併用すると全許可 | サンドボックス境界はOSが強制するため、このフラグと組み合わせても境界自体は残る（後述の限界は別途あり） |
必要なもの
- Claude Code（バージョンは機能ごとに異なる。本文中の表を参照）
- macOS、Linux、またはWSL2（ネイティブWindowsは非対応）
- Linux/WSL2の場合は「bubblewrap」と「socat」（「apt-get install bubblewrap socat」等）
- 保護したい認証情報（AWSキー、GitHubトークン等）の環境変数名・ファイルパスの棚卸し
全体像
サンドボックスの設定は、大きく3つの層に分かれます。
- モードの選択：コマンドをサンドボックス化した上で自動実行する「auto-allowモード」か、サンドボックス化されていても毎回確認を求める「regular permissionsモード」か
- ネットワーク分離：どのドメインに接続してよいかを、セッション単位（「allowedDomains」）またはauto modeならコマンド単位（per-command allowed domains）で制御
- 認証情報の保護：ファイル・環境変数それぞれについて、「deny」（消す）か「mask」（隠しつつ動かす）かを選ぶ
この3層は独立して設定でき、組み合わせて使います。以下の図は、Claudeが実行しようとしたコマンドが、この3層をどう通過していくかを示しています。
有料パートでは、この3層のうち最も実務で効く「認証情報の保護（deny/mask）」と、2026年9月に追加された「per-command allowed domains」を、実際に使えるsettings.jsonの形で見ていきます。
AWSキーの自動再署名、GitHubトークンのマスキング、per-command allowed domainsが実際にどう動くか、そして無人実行環境で踏みやすいエラーとその対処まで、コピペで使える設定を含めて解説します。
この記事のライター
