Claude Codeのdevcontainerは、Claude Codeを開発コンテナの中で動かす構成です。公式資料では「development container」「dev container」と書かれ、Claude Codeが実行するコマンドは手元のパソコンではなくコンテナの中で動きます。チーム全員が同じ環境を使えることと、手元のパソコンに直接触らせる範囲を減らせることが主な利点です。

先に答えをまとめると、設定の中心は.devcontainer/devcontainer.jsonへ公式のFeatureを1行足し、コンテナを作り直してサインインすることです。ただし、作り直すと認証が消える点と、作業フォルダーの変更は手元のリポジトリにそのまま反映される点は、最初に押さえておきます。この記事では、コンテナの定義、依存関係、マウントの範囲、作り直した後の確認までを説明します。

この記事は、2026年10月31日に確認したAnthropicの公式資料と公式リポジトリをもとに、編集部が設定の順序と確認項目をまとめたものです。設定例は公式資料に沿った説明用で、編集部が実際にコンテナを作成して確かめた実測結果ではありません。Featureの内容や項目名は今後変わる可能性があります。

Claude Code devcontainerとは：コマンドの実行先をコンテナに移す

公式資料（英語）によると、dev containerはDockerコンテナとして動き、VS Code、GitHub Codespaces、JetBrains IDE、CursorなどDev Containersの仕様に対応したエディターがそこへ接続します。ファイルの閲覧や編集はいつもどおりエディターで行いますが、統合ターミナル、言語サーバー、ビルドツールはコンテナの中で動きます。VS Codeでは拡張機能のパネルでも統合ターミナルのclaudeでも、同じコンテナの中で動いて同じ~/.claudeを使います。

ここで混同しやすいのが、Claude Codeのsandbox機能です。隔離方法の比較（公式資料・英語）をもとに整理すると、隔離する範囲と準備の手間が次のように違います。

方法隔離される範囲準備向いている目的
sandbox（Bashツール）Bashなどのコマンドとその子プロセス。組み込みのファイル操作、MCPサーバー、hooksは対象外Docker不要手元の普段の作業で確認の回数を減らす
sandbox runtimeClaude Codeのプロセス全体Docker不要DockerなしでMCPやhooksも隔離する
devcontainer開発環境全体Docker必要チームで同じ環境をそろえる
仮想マシンOS全体Docker不要信頼できないリポジトリを扱う
クラウドセッションAnthropicが用意するOS全体Docker不要手元に何も用意せず任せる

devcontainerは、環境をそろえて再現する手段であり、どんなコードでも安全に動かせる箱ではありません。公式資料も、信頼できるリポジトリで使い、Claudeの動きを見守るよう注意しています。信頼できないリポジトリには、仮想マシンかクラウドセッションが案内されています。

devcontainerで分かれる3つの場所です。手元のパソコンにはエディターの画面とリポジトリの実体があり、コンテナの中でClaude Code、ターミナル、ビルドが動き、名前付きボリュームに認証と設定を残します。作業フォルダーの編集は手元にも反映されるので、隔離は万能ではありません。
図：devcontainerで分かれる3つの場所です。手元のパソコンにはエディターの画面とリポジトリの実体があり、コンテナの中でClaude Code、ターミナル、ビルドが動き、名前付きボリュームに認証と設定を残します。作業フォルダーの編集は手元にも反映されるので、隔離は万能ではありません。編集部の説明図です。製品の実画面ではありません。画像を開くと拡大できます。

devcontainerを使う前に決めておくこと

設定を書く前に、次の3つを決めておくと手順に迷いません（編集部の整理です）。

  • エディター：Dev Containersの仕様に対応したものを選びます。Vim単体のように対応していないエディターは、この使い方の対象外です。
  • コンテナを動かす場所：手元のDockerか、GitHub Codespacesのようなクラウドです。VS Codeで手元のDockerを使うなら、DockerとDev Containers拡張機能を先に入れます。
  • 認証の方法：Claudeのアカウント、Anthropic Consoleのアカウント、またはAmazon Bedrockなどのクラウドプロバイダーです。プロバイダーの認証情報は、手元のファイルをマウントせず環境変数などで渡します。

devcontainer.jsonにClaude Codeを追加する手順

Claude Codeは公式のDev Container Featureで入れます。VS Codeを例に、手順は3段階です。

1. devcontainer.jsonを作る

リポジトリに.devcontainer/devcontainer.jsonを保存します。すでにファイルがあればfeaturesのブロックだけを足します。

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  }
}

imageの行は、プロジェクトのベースイメージに置き換えます。Dockerfileを使っている場合はこの行を消します。末尾の:1.0が固定するのはFeatureのインストール手順で、Claude Code本体のバージョンではありません。Featureは最新のClaude Codeを入れ、コンテナの中でも既定で自動更新されます。

2. コンテナを作り直す

VS Codeのコマンドパレット（MacはCmd+Shift+P、WindowsとLinuxはCtrl+Shift+P）でDev Containers: Rebuild Containerを実行します。まだコンテナで開いていないリポジトリなら、表示される「Reopen in Container」か、同じパレットのDev Containers: Reopen in Containerで開きます。Node.jsがないベースイメージではFeatureがNode.jsも入れようとします（FeatureのREADMEによると、自動で入るのはNode.js 18系で、Node.jsのFeatureを併記する構成が推奨されています）。Failed to install Node.js and npmで止まった場合は、Claude CodeのFeatureより上に"ghcr.io/devcontainers/features/node:1": {}を足して作り直します。

3. サインインする

作り直したコンテナのターミナルでclaudeを実行し、案内に沿ってサインインします。ブラウザが開かない、またはlocalhostの接続エラーになる時は、貼り付け欄の上に表示されるログインURLをブラウザで開き、表示されたコードをその欄に貼ります。VS CodeやCodespacesで開いた場合は、FeatureがClaude Codeの拡張機能も追加します。

devcontainerの依存関係とマウント範囲を決める

コンテナの中のClaudeに何が見えるかは、作業フォルダーのマウントと追加のマウントで決まります。依存関係は、どこで入れるかによって作り直した後に残るかどうかが変わります。

依存関係を入れる場所

VS Codeの公式資料によると、作り直すと手で入れたものは入れ直しになります。ターミナルで一時的に入れたものや、Claudeがコンテナの中で追加したものも、定義に書いていなければ同じ扱いと考えます。残したいものは次のどこかに書きます。

入れるもの置く場所理由
言語やビルドツールベースイメージ、Feature、Dockerfile全員が同じものを使える。Dockerfileはビルドのキャッシュが効くが、作業フォルダーのファイルは読めない
npm installなど作業フォルダーの内容に依存するものpostCreateCommandコンテナを作った後に作業フォルダーの中で実行できる
MCPサーバーリポジトリ直下の.mcp.jsonをコミットし、必要な実行ファイルはDockerfileで入れるコンテナの定義と一緒に共有できる
認証と設定名前付きボリューム（次の節）既定ではホームディレクトリは作り直すと消える

マウントの範囲を決めるキー

何も書かなければ、エディターが開いたリポジトリが作業フォルダーとしてバインドマウントされます。編集がそのまま手元のリポジトリに現れ、Claudeがファイルを消せば手元からも消えます。範囲を変える時は、devcontainer.jsonの仕様にある次のキーを使います。

キー決めること
workspaceMountどのフォルダーを作業フォルダーとしてマウントするか。workspaceFolderと一緒に指定する
workspaceFolderエディターがコンテナの中で開くパス
mounts追加でマウントするもの。認証を残すボリュームもここに書く

公式の参考構成では、作業フォルダーを/workspaceに置いています。

"workspaceMount": "source=${localWorkspaceFolder},target=/workspace,type=bind,consistency=delegated",
"workspaceFolder": "/workspace"

たとえばsourceをリポジトリの中の一部のフォルダーにすると、Claudeに見せる範囲を狭められます。mountsに手元のフォルダーを足すほど見える範囲が広がるので、足す前に本当に必要かを確かめます。

手元の秘密情報はマウントしない

公式資料は、~/.sshやクラウドの認証情報ファイルをコンテナへマウントしないよう勧めています。代わりに、リポジトリ単位のトークンや有効期限の短いトークンを使います。理由は単純で、コンテナの中にあるものは、Claudeやそこで動くコードから読める可能性があるからです。公式資料は、確認なしの実行では悪意のあるプロジェクトが~/.claudeの認証情報も含めてコンテナ内のものを外へ持ち出すのを防げないと警告しています。

devcontainerを作り直しても認証と設定を残す

既定では、作り直すたびにコンテナのホームディレクトリが捨てられ、サインインをやり直すことになります。認証トークン、ユーザー設定、会話の履歴は~/.claudeに、アカウント情報やプロジェクトごとの信頼の情報は別の~/.claude.jsonに保存されます。両方を残すには、ボリュームをマウントしてCLAUDE_CONFIG_DIRを同じ場所に向けます。

"mounts": [
  "source=claude-code-config-${devcontainerId},target=/home/node/.claude,type=volume"
],
"containerEnv": {
  "CLAUDE_CONFIG_DIR": "/home/node/.claude"
}

/home/nodeはremoteUserがnodeの場合の例です。最初の例のbase:ubuntuにはvscodeというユーザーが用意されているなど、イメージによって違うので、コンテナのターミナルでecho $HOMEを実行して置き換えます。${devcontainerId}を名前に含めると、リポジトリごとに状態が分かれます（公式の参考構成も同じ書き方です）。外すと一つのボリュームを全リポジトリで共有します。

ボリュームを付けたのに初回設定が毎回出る場合は、containerEnvのCLAUDE_CONFIG_DIRを確かめます。これがないと~/.claude.jsonがホームディレクトリに残り、作り直しで消えてしまいます。すでにcontainerEnvがある時は、2つ目を作らず同じオブジェクトに足します。

GitHub Codespacesでは、停止と再開では~/.claudeが残りますが、コンテナの作り直しでは消えます。複数のcodespaceで認証を使い回すなら、ANTHROPIC_API_KEYかclaude setup-tokenで作ったCLAUDE_CODE_OAUTH_TOKENをCodespacesのシークレットに保存します。

作り直した後にdevcontainerで確かめること

「起動した」だけでは、狙いどおりに隔離できたかは分かりません。設定を変えたら、コンテナのターミナルで次の順に確かめます（編集部が整理した確認項目です）。

  1. 実行場所：which claudeとwhoamiで、コンテナ内のClaude Codeを、rootではないユーザーで動かしているかを見ます。
  2. 認証：claudeを起動し、/statusで想定したアカウントになっているかを見ます。
  3. 依存関係：プロジェクトのビルドとテストのコマンドを1回実行します。手元のパソコンにだけ入っているツールに頼っていないかが分かります。
  4. マウント：ls -la ~/.sshなどで、持ち込まないと決めた認証情報が見えないことを確かめます。鍵ファイルが見えなくても、エディターの機能でGitの認証が共有されている場合があるので、リモートへ書き込めるかはgit push --dry-runで別に確かめます（成功すれば書き込める状態です）。あわせて、一時ファイルを作業フォルダーに作り、手元のリポジトリにも現れることを見て、消します。
  5. 残るもの：もう一度作り直し、サインインをやり直さずに済むかと、コンテナの中で始めた会話をclaude --resumeで選べるかを見ます。
  6. 通信：通信を絞った場合は、許可していないドメインへの接続がcurl --connect-timeout 5 https://example.comなどで失敗し、サインインを含むClaude Codeの通信は通ることを確かめます。参考のスクリプトを使う時も、許可先をネットワーク設定の資料の一覧と照らします。

devcontainerでチームのルールをそろえる

同じイメージと設定が全員の環境で動くので、組織のルールを配る場所にもなります。Linuxでは、Claude Codeは/etc/claude-code/managed-settings.jsonを最も高い優先順位で読みます。Dockerfileで配置できます。

RUN mkdir -p /etc/claude-code
COPY managed-settings.json /etc/claude-code/managed-settings.json

ただし、Dockerfileはリポジトリの中にあるので、書き込み権限のある人なら変更や削除ができます。回避されては困るルールは、サーバー管理の設定かMDMで配ります。また、devcontainerをコミットするだけでは「全員が必ず使う」状態にはなりません。Claude Code自体はコンテナなしでも動くので、強制が必要ならデバイス管理などを併用します。

環境変数はcontainerEnvに書きます。Claude Codeのバージョンを固定したい場合は、Featureを使わずDockerfileでnpm install -g @anthropic-ai/claude-code@バージョン番号として入れ、DISABLE_AUTOUPDATERを1にします。CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICを1にすると、テレメトリやエラー報告を止められますが、Remote Controlなど機能フラグの取得が必要な機能も使えなくなります。

devcontainerの外向き通信を絞る

コンテナの中のコマンドでも、通信を絞らなければ外部へ接続できます。Claude Codeが必要とするドメインは、ネットワーク設定の公式資料に一覧があります。

公式の参考コンテナには、外向きの通信を許可した宛先だけに制限するinit-firewall.shが入っています。コンテナの中でファイアウォールを動かすには追加の権限が必要で、参考構成はrunArgsでNET_ADMINとNET_RAWを付けています。これらはClaude Code自体には必須ではなく、社内のネットワーク制御に任せて省くこともできます。

参考コンテナは、3つのファイルでできています。保守されるベースイメージではなく動作例という位置づけなので、構成の参考にして、自分のプロジェクトに合わせて調整します。

ファイル役割
devcontainer.jsonボリューム、runArgsの権限、VS Codeの拡張機能、containerEnv
Dockerfileベースイメージ、開発ツール、Claude Codeの導入
init-firewall.sh外向きの通信を許可した宛先に制限

試すだけなら、Claude Codeのリポジトリを複製してVS Codeで開き、「Reopen in Container」を押します。自分のプロジェクトで使う時は、.devcontainer/をコピーしてDockerfileを調整するか、前の手順のFeatureだけを足します。

devcontainerで確認なしに動かす時の注意

コンテナはrootではないユーザーで動かし、コマンドの実行先もコンテナに閉じているので、無人で動かすために--dangerously-skip-permissionsを使う選択肢があります。root権限で起動するとこのオプションは拒否されるため、remoteUserがrootでないことを確かめます。

ただし、このオプションを付けると、実行前に確かめる機会がなくなります。Claudeはバインドマウントされた作業フォルダーのファイルを変更でき、その結果は手元に直接現れます。コンテナのネットワーク設定が許す範囲にも接続できます。そのため、公式資料は前の節の通信の制限と組み合わせるよう勧めています。始める前に変更をコミットしておくと、差分で確かめて戻せます。

確認を減らしたいだけなら、分類器が操作を確かめるautoモードも候補です。組織としてこのオプションを禁止するには、管理設定でpermissions.disableBypassPermissionsModeを"disable"にします。

devcontainerで止まった時の確認項目

  • ビルドがFailed to install Node.js and npmで止まる：Node.jsのFeatureをClaude CodeのFeatureより上に足します。
  • 作り直すたびに初回設定が出る：ボリュームのマウント先とCLAUDE_CONFIG_DIRが同じか、ホームディレクトリのパスがremoteUserと合っているかを確かめます。
  • ボリュームに書き込めないという権限エラーが出る：ボリュームの所有者とコンテナのユーザーが合っているかを確かめます（公式資料にはなく、編集部の補足です）。
  • サインインでブラウザが開かない、localhostのエラーになる：ターミナルに表示されるログインURLを手元のブラウザで開き、コードを貼り付けます。貼り付けても反応しない時は、インストールのトラブル対処のコンテナの項を確かめます。
  • --dangerously-skip-permissionsが拒否される：rootで起動していないか、remoteUserを確かめます。
  • Remote Controlが使えない：CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICを設定していないかを確かめます。
  • MCPサーバーが動かない：実行ファイルをDockerfileで入れているか、接続先のドメインを許可リストに足しているかを確かめます。

まとめ：devcontainerで環境をそろえ、隔離の範囲は自分で確かめる

Claude Codeのdevcontainerは、Featureを足して作り直すだけで始められます。大事なのはその後で、認証を残すボリューム、持ち込まない認証情報、外向きの通信の範囲を決め、作り直した後に実際に確かめることです。最初は通信を絞らない最小の構成で動かし、チームで使う段階で通信の制限と管理設定を足していくと、どこで問題が起きたかを切り分けやすくなります。手元への導入はインストールの記事に、許可の考え方は権限設定の記事にまとめています。

社内で使う場合は、どのリポジトリをコンテナで動かすか、Claudeに渡すトークンの範囲、無人で動かしてよい作業を先に決めておくと、開発者ごとの差が出にくくなります。業務に合わせた構成や運用ルールづくりは、PLaiのAI社員導入支援でも相談できます。