スイッチメディアで CTO をしている高橋です。社内で AI を使った開発をいろいろ試している中で、最近やってみてよかった工夫があるので共有します。

AI に任せて開発を進める日々をすごしていると、「AI の思考をなるべく遮らずに、まとまった時間ひとりで作業してもらう」というのがけっこう効くなと感じています。とはいえ、これがなかなか難しいです。

Claude Code は、セキュリティ上の理由で頻繁に止まって人間に確認を求めてきます。必要なのは間違いないのですが、AI の作業も止まるし、見守る人間も地味にストレスが溜まります。設定を手探りで調整するだけではなかなか解消できず、困っていました。

そこで、Claude Code 用に Dev Container 環境を作って、bypass permissions モード（Claude Code が人間への確認を最小にするモード）で動かしてみました。かなり快適に使えるようになるので、この記事でやったことを紹介します。すでに Claude Code を使っていて、もう少し自律的に動かしたいなと思っている方の参考になれば嬉しいです。

Claude Code を全力で動かせない悩み

Claude Code を使いはじめて少し経ち、任せる範囲が広がってきた頃のことです。

20分はかかりそうな作業を Claude Code に依頼し、別の仕事にとりかかりました。確認しに戻ると、Claude Code はタスクを始めた直後に止まっています。「`cd ./api-repo/ && git status` を実行していいですか？」と尋ねたまま待っているのです。

╭───────────────────────────────────────────────────────────────────╮
│ Bash command                                                      │
│                                                                   │
│   cd ./api-repo/ && git status                                    │
│   Check git status in the api-repo directory                      │
│                                                                   │
│ Do you want to proceed?                                           │
│ ❯ 1. Yes                                                          │
│   2. Yes, and don't ask again for cd commands in /current/dir     │
│   3. No, and tell Claude what to do differently (esc)             │
│                                                                   │
╰───────────────────────────────────────────────────────────────────╯

たいしたコマンドでもないのに、と思いながら承認します。少しするとまた止まります。今度は `find . -name '*Test.kt' -print0 | xargs -0 -I{} cat {}` です。

Claude Code で作業していれば誰しも心当たりがあると思います。AIが意図しない動作をしないよう、外部環境とのやりとりは人間が確認しなければいけないようになっています。

最初は「まあそういうものか」と受け入れていたんですが、しばらく使っていると、これが地味に AI 活用のボトルネックになっているなあと感じてきて、もう少し何とかしたいと思いました。

permission 設定の限界

Claude Code からの許可確認を減らしたいときの第一選択肢として、すでに permission 設定という機能があります。

わたしたちも、最初は settings.json の permission 設定で何とかしようと頑張ってみました。が、これがけっこう上手くいかなくて。allow で事前許可を入れていっても、複合コマンドのような場面ではやっぱり確認を求められたりします。そのたびに調べて新しいパターンを足していくのですが、これがいつまで経っても終わらなくて、だんだん泥沼っぽくなってきます。

# いくら足してもきりがなく、バリエーションは書き切れない。
{
  "permissions": {
    "allow": [
      "Bash(git log *)",
      "Bash(git diff)",
      "Bash(git diff *)",
      "Bash(git show)",
      "Bash(git show *)",
      "Bash(git pull)",
      "Bash(git pull *)",
      ......# いくら足してもきりがなく、バリエーションは書き切れない。
{
  "permissions": {
    "allow": [
      "Bash(git log *)",
      "Bash(git diff)",
      "Bash(git diff *)",
      "Bash(git show)",
      "Bash(git show *)",
      "Bash(git pull)",
      "Bash(git pull *)",
      ......

deny の設定はもっと難しいです。Claude Code は、ある手段が塞がれていると平然と別の手段を試してきたりします。

● Read/Write ツールでは .env が permission ブロックされるので、 git apply で差分を適用します。

最近あった Claude Code の説明

禁止を確実に効かせるには経路をひとつ残らず塞ぐ必要があるはずですが、自信をもって設定し切れたという確信を持つのは無理だなと自分は感じました。

# がんばって並べていくものの、きりがない。 xargs との組み合わせなど書き切れない。
# バリエーションを考えるとコマンドごと禁止するしかなくなり、そうすると作業効率が下がる。
{
  "permissions": {
    "deny": [
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(ssh *)",
      "Bash(nc *)",
      "Bash(rm -rf /*)",
      "Read(//mnt/**)",
      "Write(//mnt/**)",
      "Glob(//mnt/**)",
      ......

補助的な位置づけと考えても、困る面があります。仕様として deny が allow に優先するので、permission 設定は「大きく allow しつつ、小さく deny する」書き方しかできません……。本当にやりたいのは「大きく deny して、個別に allow する」書き方で、たとえば「curl は基本禁止するけど、公式サイト・自社サイトはOK」と書きたいところですが、こうは書けません。ここで方向がだいぶズレてしまっているなあ、というのが正直なところです。

また、最近はある程度 "よしなに" 動く auto モードも出てきました。タスクによってはあまり止まらないようですが、いまのところ体感としては「それなりに止まる」感じで、わたしの作業ではもう一歩という印象です。（止まるポイントに納得感はあるのですが、自分の場合は止まらないでほしいな、という感じ。）

そして、数分おきに承認を求められるような状態だと、結局エージェントから目を離せません。AI も効率が落ちるし、人間の集中も切れる。任せる意味がだんだん薄れていきます。

しかも、頻繁に許可を求められていると人は自然と慣れてしまうもので、20 回目にはほとんど見ずに Yes を押しています。セキュリティのための仕組みのはずなのに、これだとむしろ危ういなあ、と感じてしまいました。

sandbox 機能の有効性

permission 以外の仕組みに、sandbox という機能もあります。
sandbox は仮想化技術で Claude Code からのアクセスを制御してくれるもので、「ファイル」「Web ドメイン」のように対象ごとに許可を書けて、確実性は permission より高そうです。

やりたいことに近そうだなと思って試してみたものの、最終的にはちょっと見送りました。理由はざっくり 2 つで、

• sandbox 機能を信用してよいのか
• パフォーマンスが落ちてしまった

ひとつめですが、たとえばプロンプトインジェクションなどで Claude Code 自体の挙動が怪しくなっているとしたら、Claude Code が自分で提供している防御機能を信用するのは少し怖いなあ、と。（多層防御として「より安全」になっているのは間違いないとは思いつつ。）

実際、勝手に sandbox が無効化されるケースは過去にあったようです。

エージェントの判断で、勝手にSandboxを無効化されるケースが発生します。

https://zenn.dev/mimimi193/articles/claude-code-guardrails-best-practices-20260301

Claude Codeが独自のサンドボックスをオフにすることがあるという声が多かったからです。

https://www.reddit.com/r/ClaudeCode/comments/1re4rce/how_to_really_sandbox_claude_code/?tl=ja

この「勝手に無効化する挙動」をさらに禁止する設定もあるみたいなのですが、結局 allow/deny の話と同じで、どこまで設定すれば本当に大丈夫なのかが分からず、それを維持しつづけるのも地味に大変そうだなと感じました。

そんなわけで、sandbox は便利だけど、セキュリティのロジックとして自分は寄りかかりきれないかな、というのが今のところの感想です。

また、sandbox を有効化すると、一部環境ではパフォーマンスが低下するという問題も発生し、常用は難しい状態でした。

DevContainer による隔離

これまで書いたことを経て、Claude Code を外側から閉じ込めてしまうほうが手っ取り早いかも、と思いはじめました。道具としては Dev Container がちょうどよさそう、ということで試してみることにしました。

中で何が起きても外には届かない作りにできれば、中では何をしてもいい。煩わしい許可も要らなくなります。

管理面でも、細かいルールを管理するより、大きな壁をひとつ立てるほうが強く、分かりやすいです。

参考実装

ここまで書いておいてなんですが、これは別に目新しいアイデアではなくて、Anthropic 社がすでに DevContainer で Claude Code を動かすためのリファレンス実装を公開してくれています。

anthropics/claude-code の .devcontainer/ を見ると、Node ベースに Claude Code を入れて iptables で必要なドメインだけ通す設定が公開されています。

今回実現したいこと

わたしたちのプロダクトでは、Anthropic 実装を参考にしつつ、自社プロダクト開発向けにチューニングしました。具体的には次の通りです。

• 言語ランタイムの両立: Kotlin/JVM と Node.js, Python をサポート
• ホスト側サービスへの接続: Docker ホスト側で動く PostgreSQL や LocalStack に繋ぎたい（ユニットテストで使用）
• 認証情報の永続化: コンテナ再起動しても Claude と GitHub の認証を維持したい

プロダクトに合わせた環境構築

ここからは、作成したものを説明していきます。

ベースイメージとツール一式

スタートラインとして下記のような Dockerfile を作りました。

• ベースイメージ gradle:jdk21
• 追加インストール
• • Claude Code CLI (claude)
  • GitHub CLI (gh)
  • Node.js v22 + nvm + yarn
  • Python
• ファイアウォール (iptables) の設定

ファイアウォールによる通信管理

まず、インターネットとの通信についてなるべく厳しくした環境を作ることからはじめました。要点は次の５つです。

• 許可するプロトコルは HTTPS だけ
• IPv6 は全 DROP
• GitHub はIPリストを取得して許可する
• Cloudflare もIPリストを取得して許可する
• Claude Code に必要なホストは許可する

プロトコルは DNS と HTTPS だけに絞りました。SSH など、不要なポートはすべて禁止です。HTTP (80番) も閉じました。

IPv6 もすべて DROP にしました。管理できない・認知できないと抜け道になってしまうので、まずは不要なものをとにかく消すことにしました。

GitHub のホストは起動時に api.github.com/meta から取得して許可するようにしました。SSH は禁止しているので、GitHub からの clone は HTTPS で行います。

追い込みきれなかった点として、Cloudflare の許可が入っています。npm リポジトリが Cloudflare で提供されているようで、セキュリティ面からするとリスクではあるものの、Cloudflare 全体を許可せざるを得ませんでした。
とはいえ、Docker イメージのビルド時だけでよさそうという感覚もあり、このあたりは今後詰めていきたいと考えています。

禁止ルールを詰めた後で、必要な通信のみ許可しました。

• Claude Code 自体のための通信: api.anthropic.com
• ユニットテストに必要な通信: Docker ホスト側にある PostgreSQL, Redis, Localstack との通信

実行環境のセキュリティ確保

通信を設定した後は、実行環境を整備しました。Docker コンテナ内で Claude Code が変な動作をしても、ユーザ権限で動作している限りは影響範囲が限定できます。そこで、一般的なセキュリティ対策として次の設定をしました。

• コンテナの実行ユーザ: 通常ユーザ権限で動かす
• 特権動作の禁止: sudo 権限を削除
• Claude Code 設定ファイル: readonly でマウントして読み書き禁止

Dockerfile では実行ユーザを通常ユーザにした上で、さらに sudo 権限を剥奪しました。特権ユーザとしての操作が一切できないようにしています。

また、念のためですが、Claude Code の設定ファイルを書き換えられる可能性を考慮して、ホスト側の settings.json などは読み込み専用でコンテナ内に取り込んでいます。

認証情報の永続化

最小限の環境を構築したら、実用に足るように便利にしていきます。
まずは、開発必須サービスについて認証が維持されるようにしました。

• Claude Code のログイン状態: ホスト側に永続化して許容
• GitHub の資格情報: 最小権限のトークンを渡す形で許容

Claude Code のログイン状態は、なにもしないとコンテナ作り直しのたびにリセットされてしまい、毎回 claude login を行うことになります。これでは毎回手間が掛かるので、ホスト側に永続化ディレクトリを作成して維持するようにしました。
次の2ファイルを永続化すれば認証を維持できるようになります。

• ~/.claude/.credentials.json
• ~/.claude.json

次に GitHub の資格情報です。こちらは、Fine-grained Personal Access Token を最小権限で発行してコンテナに渡す形に落ち着きました。
ローテーションのないトークンを使っている点はやや気になりますが、本番デプロイのような特権操作をできないようにするなど、GitHub 側の権限設定でリスク管理しています。

作業環境の仕上げ

最後に、Claude Code の作業対象となるディレクトリのマウントです。

• 作業ディレクトリのマウント: 読み書き可能で許容

このディレクトリにはソースコードがありますが、機密情報は含まれていません。なので、万にひとつ、最悪のケースとしてコードが漏れたとしても、本番システムが乗っ取られたり破壊されたりすることはありません。

おわりに

いま、実際に bypass permissions モードで作業をしていますが、本当に快適です。bypass permissions が有効だとこうなります。

────────────────────────────────────────────────────
❯ 
────────────────────────────────────────────────────
  ⏵⏵ bypass permissions on (shift+tab to cycle)

Claude Code が対話を求めてくる場面は、本当に作業に詰まっていたり、方針の意思決定が必要なときにかぎられるようになりました。

念のためですが、AI エージェントの効率を優先するというのは「セキュリティを軽視する」という判断ではありません。むしろ、つい形骸化しがちな「人間が毎回確認する」運用よりも、結果的に安全な環境に寄せられたと感じています。

AI をパートナーにして新しい開発を試していきたい方、お待ちしています。