Claude Codeを使用するとコマンド実行の承認が多数発生していると思います。よく使用する安全なコマンドであれば settings.json で allow に設定すれば解決しますが、複数のコマンドを組み合わせた場合やshellやpythonなどのスクリプト実行は承認を求められてしまいます。しかもこれらのスクリプトは長いので読むのも時間がかかりますし、なにより面倒です。段々とちゃんと読まずに承認するようになってしまっている人も多いのではないでしょうか。
私はちゃんと読まずに承認するようになってしまっていました。そんなときにAuto Modeというモードが実装され、Sonnetベースのclassifierが危険か安全かを判断して自動的に実行してくれると知り、これをメインに使用することができないか考え始めました。
さすがにclassifierに任せっきりにするのは怖く、Anthropicの公式ブログでもClaude Codeがユーザーの意図を超えて危険な操作を行った事例が紹介されています。そこで安全にAuto Modeを使用するために行った工夫を共有したいと思います。
Auto Modeがどのような挙動をするか等の解説がAnthropicの公式ブログで公開されているので合わせて参照してください。
サンドボックスの有効化
まずはClaude Codeを安全な設定に変更していきます。
最初にサンドボックスを有効化させます。これを有効化するだけで安全性が大きく向上するのでClaude Code全体に設定しましょう。~/.claude/settings.json で以下のように設定するだけです。
{
"sandbox": {
"enabled": true,
"failIfUnavailable": true,
"allowUnsandboxedCommands": false
}
}
サンドボックスを有効化するだけで以下のメリットを受けられます。
- Bashコマンドやその子プロセスによる作業ディレクトリ外への書き込みを制限できる
"deny": ["Read(**/.env*)"]とした設定のcat .env等による迂回ができなくなる
サンドボックスは強力ですがClaude Codeの設定が緩いと意味がなくなってしまいます。秘匿情報を中心に読み込み不可にし、危険なコマンドの実行を拒否するようにします。PCに保存されている秘匿情報の詳細については最近流行っているインフォスティーラーの解説記事を参考にするのがおすすめです。平文で保存されている秘匿情報のパスが多数記載されています。
具体的な設定については以下のドキュメントがよくまとまっているので参考にしてください。
上記ドキュメントに記載されていない部分について補足すると、外部ライブラリのインストールを ask に設定しています。Claude Codeはbashとpythonをよく使用するので brew をaskにし、pip はインフォスティーラーが怖いので denyにし exclude-newer で公開直後のパッケージを避ける設定をした uv をaskにし、pip ではなく uv を使用するように ~/.claude/CLAUDE.md に記述しています。
Auto Modeは deny の設定も重要ですが ask の設定がより重要になります。事故のリスクとスピードを比較し適宜 ask を設定することをおすすめします。
1Passwordの導入
ここからはClaude Code外の設定になります。
サンドボックスを適切に設定すれば秘匿情報へのアクセスは防げるはずですが、万が一を考慮し秘匿情報はすべて1Passwordに保存しています。1PasswordにはCLIの op コマンドがあり、それを使用することで保存された秘匿情報を別のコマンドに渡すことができます。通常はつなぎこむ処理を自分で書かなければいけませんが著名なSaaSには公式のPluginが用意されているためそれを追加するだけで使用できます。
Pluginが用意されていなかったり開発で使用している独自ツールとかの場合は以下のようなコマンドで実行できます。以下はE2EテストでSaaSにアクセスキーを使用してアクセスする例です。
$ cat .env SAAS_SECRET = op://vault/saas/secret $ op run --env-file="./.env" -- bash ./e2e.sh
これでアクセスキーは e2e.sh のみに渡されClaude Code等からは見えません。
また、開発用のPCからアクセスキーや秘密鍵をすべて1Passwordに保存させるとセキュアになるだけでなくPCを新しく買ったときの移行作業がとても楽になるというメリットもあります。
Read Onlyなコマンドの作成
Auto Modeで一番やっかいなのはSaaSのCLIコマンドの扱いです。GET系のコマンドは承認なしに実行してほしいですが、事故につながるPOST系のコマンドを自動で実行させるのは怖いです。そこでRead Onlyのラッパーコマンドを作成しました。ラッパーコマンドを自動で実行できるようにした上でオリジナルのコマンドを ask に設定します。
設定例
私たちの環境では gh コマンドと gcloud コマンドをよく使用するのでこの2つを紹介します。
ghroコマンド
まずはGitHubでFine-grained personal access tokenをRead Onlyの権限で作成します。その後以下のコマンドでログインします。
GH_CONFIG_DIR=~/.config/ghro gh auth login --with-token <<< "token"
以下を ~/.zshrc 等に設定します。
ghro() {
GH_CONFIG_DIR="$HOME/.config/ghro" gh "$@"
}
あとは ~/.claude/CLAUDE.md にGET系の操作のときは ghro を使用するように記述して ~/.claude/settings.json に "ask": ["Bash(gh:*)"] を設定したら完成です。
gcloudroコマンド
基本的な流れは ghro と同じですがRead Onlyにする仕組みが異なります。
GCPの機能であるサービスアカウントの権限借用（Impersonation）を使用します。 Read権限だけを設定したサービスアカウントを作成してそれをImpersonationするラッパーコマンドを定義するだけです。
大抵のコマンドには環境変数等で既存の認証情報を上書きする方法が存在するので同じようなアプローチでRead Onlyなラッパーコマンドが作成できると思います。ここで先ほど触れた1Passwordの op コマンドを組み合わせるとセキュアにアクセスキー等を設定できるはずです。
監査ログの取得
最後に、万が一事故が起きたときに影響範囲を調査するためにClaude Codeの監査ログを保存するようにします。Hooks を利用することで実現できます。Claude Codeに実装を依頼するとサクッと作成してくれます。最低限、実行したコマンドだけでも残しておくことをおすすめします。
終わりに
ここまでの対応でかなり安全にAuto Modeを実行できるようになったと思います。サンドボックスは有名なので多くの人が使用していると思いますが、それ以外だとRead Onlyのラッパーコマンドの作成が大きな効果がありました。
これを導入する前は gh コマンドでちょっとした事故（関係ないPRのタイトルを変更するなど）が発生していましたが、ReadをAllow、WriteをAskにすることで防げるようになりました。
Writeでは承認を求められてしまいますが、Writeが必要になるのは開発の最終段階なのでほとんど気になりません。開発の前半に行われる調査や設計を安全に承認なしで実行できるのはとても快適です。
ホワイトプラスでは、ビジョンやバリューに共感していただけるエンジニアを募集しています！
ネットクリーニングの「リネット」など、「生活領域×テクノロジー」で事業を展開しています。
弊社に興味がある方は、オウンドメディア「ホワプラSTYLE」をご覧ください。オンラインでのカジュアル面談も可能ですので、ぜひお気軽にお問い合わせください。
