Claude CodeをDockerで使う｜企業導入でまず考えたい安全な隔離設計
Claude Codeを会社で使うなら、まず「どこで動かすか」を決めたい
Claude Codeは便利です。けれど、企業で使うとなると、最初に引っかかるのは性能よりも安全性だと思います。
「AIエージェントにローカル端末でコマンドを実行させていいのか？」
この問い、かなり自然です。Claude Codeはコードを読み、ファイルを編集し、テストやビルドのコマンドも提案します。つまり、開発者の端末に近い権限を持つ場面が出てくる。
だからこそ、個人利用の延長で全社展開するより、Docker container、正確には Dev Container の中で動かす設計を先に考える価値があります。
確認日: 2026年5月8日
公式ドキュメントにもDev Container導線がある
AnthropicのClaude Codeドキュメントには、Development containers のページがあります。
ポイントはシンプルです。Claude Codeをコンテナ内に入れると、Claudeが実行するコマンドはホストOSではなくコンテナ内で走ります。一方で、プロジェクトファイルはマウントされるので、編集結果はいつものローカルリポジトリに反映される。
この構造が、企業利用では効きます。
ホスト端末に直接ツールを入れない。
開発環境をチームでそろえる。
ネットワークの出口をコンテナ単位で絞る。
認証情報やポリシーの置き場所を設計できる。
「AIを使ってよいか」だけで議論すると話が大きくなりがちですが、「AIが動く箱をどう設計するか」に分けると、かなり現実的になります。
最小構成はDev Container Featureを足すだけ
公式ドキュメントでは、Claude Code Dev Container Feature を使う方法が紹介されています。
既存の .devcontainer/devcontainer.json があるなら、features に Claude Code を追加するだけで始められます。新規なら、Ubuntuベースの Dev Container に feature を足す形です。
{
"image": "mcr.microsoft.com/devcontainers/base:ubuntu",
"features": {
"ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
}
}この version はClaude Code本体の固定ではなく、Featureのインストールスクリプトのタグです。Claude Code本体はデフォルトで自動更新される前提なので、企業利用ではここをそのままにしてよいか、固定したいかを別途決める必要があります。
個人的には、最初の検証ではこれで十分。いきなり強固なDockerfileを作り込むより、まず「コンテナ内でClaude Codeが動く」「編集結果がホスト側に出る」「認証が通る」の3点を確認するのが早いです。
ただし、コンテナに入れれば安全という話ではない
ここがいちばん大事です。
Dev ContainerはホストOSからの隔離になりますが、万能の金庫ではありません。公式ドキュメントも、権限プロンプトをスキップして動かす場合、コンテナ内でアクセスできるものは悪意あるプロジェクトに流出され得る、と明記しています。
つまり、守る対象を分けて考える必要があります。
1つ目はホストOSです。これはコンテナ化でかなり守りやすくなる。
2つ目はマウントされた作業ディレクトリです。Claudeはそこを編集できます。誤った削除や変更のリスクは残ります。
3つ目はコンテナ内の認証情報です。Claude Codeのログイン情報、クラウド認証、npmやGitHubのトークンを入れたら、それはコンテナ内から見える資産になります。
4つ目はネットワークです。外に出られるなら、外部送信の経路は残る。
「Dockerに入れたからOK」では少し危ない。企業向けには、「何をマウントするか」「どの認証情報を渡すか」「どこへ通信できるか」をセットで決めるのが本筋です。
企業向けに効く3つの制御
まず効くのは、ネットワークの出口制御です。
Claude Codeのリファレンスコンテナには、init-firewall.sh という考え方があります。すべての外向き通信を許可するのではなく、Claude Codeや開発ツールに必要なドメインだけを通す設計です。
もちろん、全社でそのスクリプトをそのまま使う必要はありません。企業ネットワーク側のプロキシ、EDR、DLP、クラウド開発環境のネットワークポリシーで制御してもよい。大事なのは、AIエージェントの通信先を「開発者の自由」ではなく「組織の設計」に寄せることです。
次に、組織ポリシーです。
Claude CodeはLinux環境で /etc/claude-code/managed-settings.json を読み、これはユーザー設定やプロジェクト設定より優先されます。企業で配るDev Containerなら、Dockerfileでこのファイルを配置できます。
たとえば、危険な権限バイパスを禁止したいなら、permissions.disableBypassPermissionsMode を disable にする。機密ファイルを読ませたくないなら、permissions.deny に .env や secrets 配下を入れる。これはチームに「気をつけて」と言うより強いです。
3つ目は、認証情報の渡し方。
公式ドキュメントでは、クラウドプロバイダー利用時にホストの認証ファイルをマウントするより、containerEnv、Codespaces secret、クラウドの workload identity などで渡す選択肢が示されています。
これはかなり実務的です。ホストの ~/.aws や gcloud 設定を丸ごとコンテナへ入れると、便利な反面、境界が曖昧になります。最初は面倒でも、プロジェクトに必要な権限だけ渡すほうが事故りにくい。
権限プロンプトを飛ばす前に、順番を決める
Dev Containerの説明では、コンテナ内で非rootユーザーとして動かすことで、claude --dangerously-skip-permissions を使った無人運用が可能になる、と説明されています。
これは魅力的です。長いテスト修正や定型PR作成を任せたいとき、毎回承認で止まらないのは大きい。
でも、最初からそこへ行くのはおすすめしません。
私は順番を分けるのがよいと思っています。
最初は通常の権限モードで使う。
次に、プロジェクトの permissions.allow と permissions.deny を整える。
その次に、Dev Containerのネットワーク出口を制限する。
さらに、managed-settings.json で組織として禁止したい操作を固定する。
最後に、信頼できるリポジトリだけで権限プロンプトの削減を検討する。
この順番なら、便利さを上げる前に境界線を引けます。逆に、境界線がないままプロンプトだけ消すと、Claude Codeではなく運用設計の問題になります。
導入時のチェックリスト
社内で「Claude CodeをDocker経由で使ってみよう」と話すなら、最初のチェックはこのくらいで十分です。
Dev Containerのベースイメージをチームで固定しているか
Claude CodeのFeatureやCLIバージョン更新方針を決めているか
コンテナのremoteUserがrootではないか
マウントするディレクトリをプロジェクト最小限にしているか
.env、secrets、credentials を permissions.deny で読ませない設定にしているか
ネットワーク出口を必要なドメインだけに絞れるか
認証情報をホストから丸ごとマウントしていないか
managed-settings.json で組織の禁止事項を固定できるか
ログ、OpenTelemetry、利用状況監視の方針を決めているか
信頼できないリポジトリでは権限バイパスを使わないルールにしているか
全部を初日から完璧にする必要はありません。けれど、この10個を見ないまま「とりあえず全員に入れよう」は怖いです。
Docker化の価値は、AIを閉じ込めることだけではない
Claude CodeをDocker containerで使う価値は、単に「危ないから閉じ込める」だけではありません。
むしろ企業では、開発環境の再現性のほうが効く場面もあります。
新しいメンバーが同じ環境で始められる。
NodeやPythonのバージョン差でClaudeの提案がズレにくい。
プロジェクトごとにMCP、権限、ネットワークを分けられる。
監査したい設定をDockerfileやJSONとして残せる。
AIエージェントは、開発者の作業を速くします。だからこそ、速く動く場所をきちんと決めたい。
個人の端末に直接置くのか。
プロジェクトごとのコンテナに閉じるのか。
Codespacesのようなクラウド開発環境で統制するのか。
この設計を先にしておくと、AI導入の議論が「怖い」「便利」だけで終わりません。運用に落ちます。
まずは1リポジトリで検証する
最初の一歩は小さくていいです。
社内の本番コードではなく、検証用リポジトリに .devcontainer/devcontainer.json を置く。Claude Code Featureを足す。通常モードでログインする。次に、permissions.deny とネットワーク制御を足す。
ここまでやると、「Claude CodeをDockerで使う」は単なるTipsではなく、企業のAI開発環境セキュリティのTopicになります。
便利さを捨てずに、境界を作る。
この方向性なら、Claude Codeをチームに入れる話はかなり進めやすくなるはずです。
参考:
https://code.claude.com/docs/en/devcontainer
https://docs.anthropic.com/en/docs/claude-code/security
https://docs.anthropic.com/en/docs/claude-code/settings
https://docs.anthropic.com/en/docs/claude-code/data-usage
https://github.com/anthropics/devcontainer-features
いいなと思ったら応援しよう！
よろしければ応援お願いします!
今月のClaude に大切に使わせていただきます!
