Docker MCP ToolkitでClaude Codeからコンテナを操作する設定
Docker MCP ToolkitのプロファイルとゲートウェイをClaude Codeに接続し、コンテナ化されたMCPサーバーを呼び出す手順を扱います。
Docker MCP ToolkitでClaude Codeから何ができるようになるか
Docker MCP Toolkitは、Docker Desktopに統合されたMCPサーバーの管理機能です。MCPサーバーをコンテナとして分離実行し、プロファイル単位でまとめて管理できます。Claude Codeをクライアントとして接続すると、GitHubやPlaywrightのようなMCPサーバーをnpxやuvxで個別にインストールせず、Dockerコンテナ経由でClaude Codeのセッションから呼び出せるようになります。依存関係の管理やランタイムの用意が不要になる点が、素のstdioサーバーを個別追加する方式との最大の違いです。
前提はDocker Desktop 4.62以降(MCP Toolkitが現行UIで動くバージョン)とClaude Codeのインストール済み環境です。docker mcpコマンドはDocker Desktopに同梱されているため、追加インストールなしで使えます。
プロファイルとゲートウェイの役割(profile / gateway)
Docker MCP Toolkitは3つの要素で構成されます。カタログはDockerが提供するMCPサーバーの一覧、プロファイルは使用するサーバーとその設定をまとめた名前付きコレクション、ゲートウェイはクライアントとサーバーの間に立つプロキシです。クライアントを接続するとき、実際に指定するのはプロファイルで、ゲートウェイがそのプロファイル内のサーバーをコンテナとして起動・仲介します。
| 要素 | 役割 |
|---|---|
| カタログ | 役割利用可能なMCPサーバーの一覧(mcp/docker-mcp-catalogが既定) |
| プロファイル | 役割サーバーと設定をまとめた名前付きコレクション。プロジェクトや用途ごとに分けられる |
| ゲートウェイ | 役割クライアントとコンテナ化されたサーバーの間を仲介するプロキシ |
セキュリティ面では、ビルド時の対策(カタログ内のイメージはDockerが署名し、SBOMを添付)とランタイムの対策(サーバーごとにCPU1コア・メモリ2GBの制限、ファイルシステムへの既定アクセスなし、シークレットを含むリクエストの遮断)の両方が組み込まれています。個別にMCPサーバーをローカルへインストールするより、隔離の粒度が細かい構成です。
ステップ1: プロファイルを作りサーバーを追加する
まずプロファイルを作成し、使うMCPサーバーを追加します。
# プロファイルを作成
docker mcp profile create --name web-dev
# カタログのサーバー一覧を確認(サーバーIDを控える)
docker mcp catalog server ls mcp/docker-mcp-catalog
# プロファイルにサーバーを追加(複数指定可)
docker mcp profile server add web-dev \
--server catalog://mcp/docker-mcp-catalog/github-official \
--server catalog://mcp/docker-mcp-catalog/playwrightサーバーはURI形式で指定します。カタログ由来ならcatalog://<catalog-ref>/<server-id>、自前のDockerイメージならdocker://<image>:<tag>、MCPコミュニティレジストリならhttps://<url>/v0/servers/<uuid>、ローカルのYAML/JSON定義ならfile://<path>です。サーバーIDはDocker Desktopの「MCP Toolkit」→「Catalog」の該当サーバー詳細か、catalog server lsの出力名で確認できます。カタログにはGitHubやPlaywrightのような汎用ツールに加えて、Docker Hub自体をLLMから検索・操作できるMCPサーバーも含まれています。
ステップ2: Claude Codeをクライアントとして接続する
プロファイルができたら、Claude Codeをクライアントとして接続します。Docker公式のCLIプラグインリポジトリでは、次のコマンドが例として示されています。
docker mcp client connect claude-code --profile web-devこのコマンドが使えない、または挙動を手元で確認しながら進めたい場合は、Claude Code側のclaude mcp addでゲートウェイをstdioサーバーとして直接登録する方法もあります。こちらはClaude Code公式ドキュメントに記載された、他クライアント向けの手順をClaude Codeの構文に変換する標準パターンそのものです。
claude mcp add --transport stdio docker-toolkit \
-- docker mcp gateway run --profile web-dev--より前がClaude Code自身のオプション、より後がゲートウェイに渡すコマンドという区切りです。claude mcp add構文の詳細(スコープの使い分けや環境変数展開など)はClaude Code MCP設定ガイドにまとめています。Docker公式ドキュメントが示す手動接続例はClaude Desktopのclaude_desktop_config.json向けの形式が中心で、Claude Codeのclaude mcp add構文とは書き方が異なる点も押さえておくと変換しやすくなります。
OAuth認証が必要なサーバーを追加する
GitHubやNotionのように外部サービスと連携するMCPサーバーは、OAuth認証を求めることがあります。Docker MCP ToolkitはこのOAuthフローも管理下に置きます。Docker Desktopの「MCP Toolkit」→「Catalog」から該当サーバーを追加し、サーバーの「Configuration」タブでOAuth認証方式を選ぶと、ブラウザで認可ページが開きます。認可が終わったら「OAuth」タブで連携済みのサービス一覧を確認でき、不要になった連携は「Revoke」で個別に取り消せます。APIトークンを自分で発行してコピー&ペーストする作業が要らない分、トークンの取り扱いミスによる漏えいリスクを減らせます。Claude Code側から見れば、この認証はプロファイルに紐づいたサーバー単位で完結しており、Claude Code自身がOAuthのやり取りを仲介する必要はありません。
ステップ3: 接続を確認する
接続後はclaude mcp listまたはclaude mcp get docker-toolkitで状態を確認します。Claude Codeのセッション内では/mcpパネルからも同じ情報が見られます。✔ Connectedが表示されれば、プロファイル内のサーバーがコンテナ経由で呼び出せる状態です。ツールを実際に呼び出すと、ゲートウェイがそのサーバーのコンテナをまだ起動していなければこのタイミングで起動するため、初回だけ応答が遅くなることがあります。
「MCP Gateway」という名前が指す2つの機能を混同しない
Docker公式ドキュメントを読むときに紛らわしいのが、「MCP Gateway」という名前が2つの異なる機能を指すことです。ひとつは、ここまで扱ってきたdocker mcp gateway runコマンド(Docker MCP Toolkitを構成するオープンソースのCLI機能で、無料で誰でも使えます)。もうひとつは、Docker AI Governanceという別製品の一部として提供される「MCP Gateway」で、こちらは招待制の企業向け機能です。
どちらも同じ「ゲートウェイ」という語を使っているため、Docker AI Governanceの紹介記事を読んで「招待制でないと使えない」と誤解し、docker mcp gateway runまで避けてしまうケースがあります。本記事で扱ったコンテナ経由のMCPサーバー呼び出しは、Docker Desktopがあれば誰でも使えるオープンソース側の機能です。エンタープライズ向けのガバナンス機能(組織横断のポリシー適用や監査ログの集中管理など)が必要になったときだけ、別製品として検討すれば足ります。
見分け方はシンプルです。Docker Desktopを使っていれば、MCP Toolkitを有効にした時点でゲートウェイはバックグラウンドで自動的に動いており、手動での起動や設定は不要です。本記事のようにdocker mcp gateway runやclaude mcp addを自分で書くのは、Docker Desktop本体を使わずCLIプラグイン単体で動かす場合や、挙動を細かく制御したい場合に限られます。Docker Engineのみの環境(Docker Desktopなし)でCLIプラグインを使うときは、GitHubリリースページからバイナリを取得し、~/.docker/cli-plugins/docker-mcpに配置してからchmod +xで実行権限を与える手順になります。
よくあるつまずき
- 「Docker Desktop is not running」エラーが出る: Dockerデーモン自体は動いているのに出る場合、WSL2やDocker CEなどDocker Desktop本体を使わない環境が原因です。
DOCKER_MCP_IN_CONTAINER=1を環境変数に設定すると、Desktop本体の機能チェックを回避できます - プロファイル機能が動かない: Docker Desktop以外の環境(Docker CE・WSL2・コンテナ内)では、プロファイル機能が既定で無効です。
docker mcp feature enable profilesを先に実行します --profileを省略したらサーバーが1つも呼び出せない:docker mcp gateway runは--profileを省略するとdefaultプロファイルを使いますが、何も追加していなければ空です。空のプロファイルへ接続してもツールは1つも見えません- VS Codeでも同時に使いたい:
docker mcp client connect vscode --profile web-devで別クライアントとして同じプロファイルに接続できます。生成される.vscode/mcp.jsonはユーザー固有のファイルなので.gitignoreに追加します - Claude Code自体をDockerコンテナで動かしている: 本記事はClaude Codeから外部のDockerコンテナを操作する手順で、Claude Code自体をコンテナ内で実行する構成とは逆方向です。両方を同時に組む場合は、コンテナ内のClaude Codeからホスト側のDockerデーモンにアクセスできるかを別途確認してください
まとめ
Docker MCP Toolkitは、プロファイルにサーバーを登録し、ゲートウェイ経由でクライアントへ公開する構成です。Claude Codeへの接続はdocker mcp client connect claude-codeか、claude mcp add --transport stdioでゲートウェイを直接登録するかのどちらかで完結します。コンテナ隔離とビルド時の署名検証が既定で効くため、npxやuvxでMCPサーバーを個別インストールするより、依存関係の管理を減らしたい場面に向いています。
プロジェクトごとにプロファイルを分けておけば、案件を切り替えるたびに--profileの値を変えるだけで、Claude Codeから見えるツールの範囲も自動的に切り替わります。チームで同じプロファイルを共有したい場合は、docker mcp profile exportでファイルに書き出し、リポジトリ経由で配布する運用も選べます。