公開日:
X（旧Twitter）で.envファイルの話が盛り上がっていたので、自分の考えを書き留めておきます。
.envに絞って考えると、シンプルにまとめられます。
これでClaude Codeが読み込むことは100%ない。これはbefore LLMの時代からそうなっていることが多いですが、改めて徹底する価値があります。インフラのapplyやdeployはCIに委ねて、本番クレデンシャルはCIのシークレット管理にのみ存在させる。
ローカルには開発環境用のAPI Keyを置くことは現実的な妥協です。漏洩しても顧客の個人情報が流出することはまずない。あるとしたら不正利用されてコストが異常にかかる懸念があります。以下の対策でカバーします。
--dangerously-skip-permissionsを使っていたり、Claude Codeの許可確認を真面目に見ずにYesを押している人は、コンテナを起動してその中でClaude Codeを起動するのが良いでしょう。
なぜかというと、--dangerously-skip-permissionsで動かすとClaude CodeがAWS CLIなどのコマンドを実行することがあります。もしSSOでログインしている状態だと、開発者と同じ権限で本番環境を普通に操作できてしまいます。本番の.envを隔離していても、例えばAWS Secret Managerのコマンドを打たれると困ったことになります。
SSOのクレデンシャルをコンテナにマウントしなければ、この問題は防げます。
ホスト（開発者）
├── 本番クレデンシャル → CIのみ
├── フル権限のクラウド認証情報 → ホストのみ、コンテナに渡さない
└── Claude Code環境（Docker等）
└── 開発用クレデンシャルのみ
あとは隔離しておくことでClaudeCodeを実行するコンテナのアウトバウンドトラフィックを厳格にcontrolすることも可能です。
Claude Codeにはネイティブのサンドボックス機能があります。macOSはSeatbelt、LinuxはbubblewrapというOSレベルのプリミティブでファイルシステムとネットワークを分離できます。一見すると有効な対策に見えます。
しかし構造的な問題があります。
Claude Codeのプロセス（サンドボックスの外）
└── サンドボックス（コマンドの実行環境）サンドボックスはClaude Codeが実行するコマンドを隔離するものであって、Claude Code自身のプロセスはホストに存在しています。タスクを完了するために、実行されたら困るコマンドが打たれる可能性はゼロではありません。
「How Claude Code escapes its own denylist and sandbox」という記事が詳しいですが、実際にエージェントがサンドボックス自体を無効化してコマンドを実行した事例があります。ジェイルブレイクも特別なプロンプトも不要で、ただタスクを完了させようとしただけで起きたことです。
自分を縛っているロープを自分で切れる構造になっている以上、根本的な限界があります。
Dockerコンテナはこの問題を外側から解決します。制約はClaude Codeの外側から与えられているので、Claude Code自身がその制約を外すことはできません。
最終的にはClaude Codeのガードレールをどこまで信用するか、という話になってきます。
Anthropicとしては、AGI実現のためにClaudeが倫理観に基づいて物事を判断できる姿を目指しています。将来的には2つのシナリオが考えられます。
Anthropicが「このモデルはこういう行動をしない」という保証が法的・社会的に意味を持つようになったとき、LLMにより多くの権限が委譲されていくでしょう。人間のエンジニアが本番のクレデンシャルにアクセスできるのも、雇用契約・法的責任・社会的評判という信頼のインフラがあるから。LLMにも同様のインフラが整備される未来です。
社会的な保証なしで、長時間のタスクを自律的に解けるようになるため「便利 > セキュリティ」の構図になり大きな権限をなし崩し的に与える。
これは結構ありそうで、この時どういった環境でClaudeCodeを実行するかが重要なポイントになりそうです。
どちらのシナリオに転んでも、今のうちにDockerで隔離する習慣をつけておくのは良い筋だと思っています。現時点では--dangerously-skip-permissionsを使うなら隔離された環境で実行するのが安全です。