Docker MCP Gatewayの使い方｜docker mcp gateway runの主要オプションと認証・インターセプター【2026年10月】

Docker MCP Gatewayは、MCP（Model Context Protocol）サーバーをDockerコンテナとして起動し、AIクライアントからの接続口を1つにまとめるDocker公式のオープンソースのプロキシです。中身は docker mcp CLIプラグインの docker mcp gateway run で、Docker DesktopのMCP Toolkitを有効にすると裏で自動的に動きます。2026年10月26日公開のv0.44.3ではサーバーの指定方法がプロファイル方式に切り替わっており、以前の解説にある docker mcp server enable の手順は通りません。この記事では、v0.44.3の公式イメージを手元で動かして確かめた挙動をもとに、起動方法、主要オプションの既定値、HTTP接続の認証、インターセプター、他社の「MCPゲートウェイ」との違いを順に説明します。

まとめ：Docker MCP Gatewayの要点（v0.44.3時点）

• 正体：GitHubの docker/mcp-gateway（MITライセンス）。2026年10月時点の最新は2026年10月26日公開のv0.44.3（GitHub上はPre-release表示）。Docker Desktopを使っている場合はMCP Toolkitが自動で起動するため、手で動かす必要はない。
• サーバーの指定：v0.44.3はプロファイル方式が常時有効。--profile を省くと default プロファイルを使い、--servers を付けるとカタログ直指定の従来方式になる。両方は同時に指定できない。
• HTTP接続：--transport=sse|streaming ではBearerトークンが必須（未設定なら起動ごとに50文字のトークンを自動生成）。--host を付けないと全インターフェースで待ち受けるので、手元だけで使うなら --host 127.0.0.1 を付ける。
• 安全の既定値：署名検証・シークレット遮断・呼び出しログは既定で有効。外向き通信は既定では遮断されないため、必要なら --block-network を付ける。
• 注意点：beforeインターセプターはstreaming/sse接続で失敗する既知の不具合（Issue #358・未解決）があり、v0.44.3でも再現した。IBM・Microsoft・Cloudflareの「MCPゲートウェイ」は別製品。

Docker MCP Gatewayとは：MCPサーバーをコンテナで束ねるプロキシ

Docker公式ドキュメントのMCP Gatewayのページは、Gatewayを「クライアントとサーバーの間に立つ集中型のプロキシで、設定・認証情報・アクセス制御を管理する」ものと説明しています。Gatewayが無い構成ではAIアプリごとに各MCPサーバーの接続を設定しますが、Gatewayを使うとアプリはGatewayだけに接続し、サーバーの起動・振り分け・認証はGatewayが受け持ちます。AIエージェント同士の通信を仲介するメッセージブローカーではありません。MCPの基本はMCP（Model Context Protocol）とは？仕組み・APIとの違い・MCPサーバーの作り方で解説しています。

ツール呼び出しが届くまでの流れ

AIアプリがツールを呼ぶと、Gatewayはそのツールを持つサーバーを特定し、まだ動いていなければDockerコンテナとして起動します。続いて必要な認証情報を注入し、制限をかけたうえで要求を転送し、結果をアプリへ返します。v0.44.3の公式イメージで duckduckgo サーバーを指定して起動したところ、ログには --security-opt no-new-privileges --cpus 1 --memory 2Gb --network bridge を付けたコンテナ起動が記録され、サーバーのイメージはタグではなくダイジェスト（mcp/duckduckgo@sha256:…）で固定されていました。2026年10月31日にColima上のDocker Engine 29.5.2（amd64）で各1回測定した初期化時間は、初回約18秒、2回目約5秒でした。署名検証とツール一覧取得を含む、この環境での観測値です。

MCP Toolkit・MCP Catalog・Gatewayの役割分担

DockerのMCP関連は3つの部品に分かれます。MCP Catalogは検証済みサーバーのイメージを集めたカタログで、公式の概要ページの表記は「300+ verified servers」です。MCP ToolkitはDocker Desktopの画面とCLIで、プロファイル作成やクライアント接続を扱います。MCP Gatewayはその裏でサーバーを実際に起動・集約・保護する実行部分です。Toolkitの有効化やプロファイル作成、Claude・Cursorへの接続手順はDocker MCP Toolkitの使い方｜プロファイル作成とClaude・Cursor接続、docker mcpコマンドにまとめ、この記事はGateway本体の起動方法と設定に絞ります。

なお、公式ドキュメントのMCP Gatewayのページ冒頭には「Docker AI Governanceの一部としてのMCP Gatewayは招待制の機能」という注記があります。これは組織向けのガバナンス製品の一機能を指すもので、GitHubで公開されているOSS版の docker mcp gateway run は誰でも使えます。

docker mcp gateway runの起動方法

起動経路はDocker Desktop経由、CLIプラグインの単体導入、公式イメージの3通りです。手元でAIアプリから試すだけならDocker Desktop、Linuxサーバーやほかのコンテナから使うなら公式イメージが手間がかかりません。

Docker DesktopとCLIプラグインの単体導入

Docker DesktopでMCP Toolkitを有効にしていれば、docker mcp プラグインは同梱済みで、Gatewayは自動で起動します。Docker Engineだけの環境では、GitHubのリリースページからOSに合うバイナリ（v0.44.3はLinux・macOS・Windowsのamd64/arm64の6種類）を取得します。Linux・macOSでは ~/.docker/cli-plugins/docker-mcp に置いて実行権限を付けます。Windowsでは %USERPROFILE%\.docker\cli-plugins に実行ファイルを配置します。ただし、Docker Desktopの動いていないmacOSでは docker mcp の各サブコマンドが「Docker Desktop is not running」で止まります（Docker MCP Toolkitの記事で実測）。Docker Desktopを入れていないMacでは、次の節の公式イメージを使ってください。以下のコマンド例はLinux amd64向けです。

tar -xzf docker-mcp-linux-amd64.tar.gz
mkdir -p ~/.docker/cli-plugins
mv docker-mcp ~/.docker/cli-plugins/docker-mcp
chmod +x ~/.docker/cli-plugins/docker-mcp
docker mcp version

公式イメージdocker/mcp-gatewayのCompose起動構成

公式イメージ docker/mcp-gateway は、エントリーポイントが /docker-mcp gateway run で、環境変数 DOCKER_MCP_IN_CONTAINER=1 を持っています。Dockerソケットを渡せばDocker Desktop無しで動き、ほかのコンテナのエージェントからHTTPで呼べます。次の構成は、v0.44.3でトークン無しの接続が401、トークン付きが200になることを確かめたものです。2026年10月31日に確認した時点で latest タグはv0.44.3ではなく2026年7月23日作成の古いビルドを指していたので、版を固定してください。

services:
  gateway:
    image: docker/mcp-gateway:v0.44.3
    command:
      - --servers=duckduckgo
      - --transport=streaming
      - --port=8811
    environment:
      - MCP_GATEWAY_AUTH_TOKEN=${MCP_GATEWAY_AUTH_TOKEN:?MCP_GATEWAY_AUTH_TOKENを設定してください}
    ports:
      - "127.0.0.1:8811:8811"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

Dockerソケットを渡すことは、Gatewayにホストの全コンテナを操作する権限を渡すことと同じです。共用サーバーで動かす場合は、このコンテナを動かせる人を絞ってください。

プロファイル方式と–servers指定の違い

v0.44.3のソースでは、プロファイル機能の判定関数（readProfilesFeature）が常に true を返します。そのため docker mcp server enable などは「Obsolete」の隠しコマンドに置き換わり、docker mcp profile server add を使うよう案内されます。旧版で使われていた docker mcp server enable brave duckduckgo の手順は、現行版では動きません。

docker mcp gateway run がどのサーバーを公開するかは、次の2つの方式で決まります。

2つの方式は排他です。--servers=duckduckgo --profile=x を同時に渡すと、v0.44.3は「cannot use –profile with –servers, –enable-all-servers, –catalog, …」で起動を止めました。また、--servers でサーバーを明示すると、エージェントが会話中にサーバーを探して追加する動的ツール（mcp-find・mcp-add など）が無効になります。ソースのコメントには「サーバーを明示するユーザーは手動の運用をしているため」とあります。動的ツールの使い方は、前述の「Docker MCP Toolkitの使い方」で解説しています。

# プロファイル方式（Docker Desktopで作ったプロファイルを使う）
docker mcp gateway run --profile dev-tools

# 従来方式（カタログのサーバー名を直接指定する）
docker mcp gateway run --servers=duckduckgo --tools=duckduckgo:search

docker mcp gateway runの主要オプションと既定値

オプションの一覧は公式CLIリファレンスにありますが、2026年10月31日時点の表にはv0.43.1（2026年6月25日）で入った --host と --allow-unauthenticated、v0.44.1で入った --preserve-tool-schema-dialect が載っていません。--verify-signatures の既定値も空欄ですが、v0.44.3のgateway.goのソースではホスト上・コンテナ内のどちらでも true です。次の表はソースを正として整理しました。

--port の8811はソースの既定値で、--transport をsseかstreamingにしてポートを省くと自動で使われます。stdioのまま --port=8811 を付けると「cannot use –port with –transport=stdio」で止まります。

–dry-runの検証範囲と終了動作

--dry-run は、イメージの取得・署名検証・ツール一覧の取得まで進めたうえで、待ち受けずに終了します。duckduckgo を指定した実測では「2 tools listed」「Initialized in 17.65s」のあと「Dry run mode enabled, not starting the server.」で終了コード0でした。シークレットの名前違いやイメージの取得失敗をCIで先に見つけたいときに使えます。

–toolsによる公開ツールの制限

--tools は「サーバー名:ツール名」の形で、server1:* とするとそのサーバーの全ツールを公開します（リポジトリのGateway解説の例）。ファイル削除やIssue作成など書き込み系のツールを持つサーバーは、読み取り系のツールだけを公開しておくと、AIアプリの誤操作が起きても被害を小さくできます。

HTTP接続（sse・streaming）の認証とバインド先

既定のstdioは起動したAIアプリとだけつながります。複数のアプリやほかのコンテナから使うにはsseかstreamingを選びます。streamingのURLは http://localhost:8811/mcp、sseは /sse です。MCPのトランスポートの違いはStreamable HTTPとは？MCPのトランスポートとSSEの違い、2026-07-28仕様の変更点で詳しく説明しています。

BearerトークンとMCP_GATEWAY_AUTH_TOKEN

リポジトリのセキュリティモデル文書によると、HTTP接続では既定でBearerトークンが必要です。環境変数 MCP_GATEWAY_AUTH_TOKEN があればその値を使い、無ければ起動のたびに英小文字と数字50文字のトークンを生成してログに出します。生成されたトークンは再起動で変わるため、AIアプリ側の設定を毎回書き換えることになります。常用するなら環境変数で固定してください。実測では、トークン無しの初期化要求は401、正しいトークン付きは200、/health はトークン無しでも200でした。/health はMCPの通信口ではないため、意図的に認証を外してあります。

export MCP_GATEWAY_AUTH_TOKEN="$(openssl rand -hex 24)"
docker mcp gateway run --transport=streaming --port=8811 --host=127.0.0.1

# 以下はGatewayを起動したまま、別ターミナルで実行する
# 起動元と同じトークンを設定する（新しい値を生成しない）
export MCP_GATEWAY_AUTH_TOKEN="Gatewayの起動に使ったトークン"
claude mcp add --transport http docker-gateway http://127.0.0.1:8811/mcp \
  --header "Authorization: Bearer ${MCP_GATEWAY_AUTH_TOKEN}"

–host未指定時の待受範囲とループバックへの制限

v0.44.3のソースでは --host の既定値は空文字で、その場合は全インターフェースで待ち受けます。トークンがあるのでそのまま他人に使われるわけではありませんが、社内LANやカフェのWi-Fiから接続を試みられる状態になります。手元のAIアプリだけで使うなら --host=127.0.0.1 を付けてください。公式イメージをコンテナで動かす場合はコンテナ内で全インターフェースに待ち受ける必要があるので、代わりに上のComposeの例のように公開ポートを 127.0.0.1:8811:8811 に絞ります。

--allow-unauthenticated を付けると認証が外れます。そのうえで外部から届くアドレスで待ち受けると、Gatewayは「Any client that can reach this listener can execute configured MCP tools」という警告をログに出します。ファイルやGitHubを操作するツールを無認証で外へ開くことになるので、ループバック以外では使わないでください。

Originヘッダーによるブラウザからの要求の拒否

Gatewayは、DNSリバインディング攻撃を防ぐため、Origin ヘッダーの付いた要求をlocalhost・127.0.0.1・::1以外から受け付けません。実測では、正しいトークンを付けても Origin: https://evil.example は403でした。注意したいのは、localhostでもポートが違う Origin: http://localhost:3000 も「Origin does not match Host」で403になった点です。この検証のようにOriginとHostのポートが異なるブラウザアプリから直接接続する構成は拒否されるため、サーバー側のプロセスを経由させてください。Origin を送らないCLIやSDKからの接続は影響を受けません。

セキュリティの既定値：署名検証・シークレット・ログ・分離

MCPサーバーはファイルや外部APIに触れるため、Gatewayを使う最大の利点はこの実行境界にあります。セキュリティモデル文書が定める既定の範囲を、実測結果と合わせて整理します。

• 署名検証：Docker Hubの mcp/ 名前空間のイメージに限り、取得前に署名を検証する。検証を有効にしている間はダイジェスト指定が必須。実測ログでも「Verifying images [mcp/duckduckgo]」「Images verified in 2.26s」が出た。名前空間外のサードパーティイメージは検証されない。
• シークレット：シークレットは宣言したサーバーにだけ渡り、ホストの環境変数はコンテナに引き継がれない。--block-secrets はツールの引数と応答を実行前後に走査する。
• 呼び出しログ：--log-calls が記録するのはツール名と引数の形だけで、値は残らない。実測でも「Calling tool search with arguments: object with 2 field(s)」と記録された。誰が何を検索したかまで監査したい場合は、後述のインターセプターで別途記録する必要がある。
• ネットワーク：外向き通信は既定では遮断されない（実測のコンテナも --network bridge）。--block-network か、サーバー定義の disableNetwork・allowHosts で絞る。
• ホストのディレクトリ：カタログやプロファイルからのバインドマウントは既定で読み取り専用。書き込みを許すには MCP_GATEWAY_DOCKER_BIND_ALLOW_WRITABLE_PATHS に完全一致のパスを登録する。

一方、ツールの説明文に仕込まれたプロンプトインジェクションや、許可した範囲内でサーバーが悪意ある内容を返すことは、文書上もGatewayの守備範囲外と明記されています。署名検証が守るのはイメージがDockerの公開した物かどうかだけです。サーバーの振る舞いが安全かどうかまでは保証しません。MCPサーバー経由のインジェクションの実例はPlaywright MCPのセキュリティ｜危険性とCVE-2025-9611対策を参照してください。

インターセプターによるツール呼び出しの検査・加工

インターセプターは、ツール呼び出しの前（before）か後（after）に任意の処理を挟む仕組みです。書式は --interceptor=タイミング:種類:引数 で、種類は次の3つです（リポジトリのインターセプター例）。

beforeは要求全体を受け取り、標準出力（httpなら空でない応答）にJSONを返すと、ツールを呼ばずにその内容を応答にできます。afterは応答を受け取って加工できます。標準エラー出力はGatewayのログに出るので、引数の監査ログを取る用途に向きます。

# 引数をGatewayのログへ出す（before）
docker mcp gateway run --servers=duckduckgo \
  --interceptor 'before:exec:echo Arguments=$(jq -c ".params.arguments") >&2'

# 応答テキストを先頭100文字に切り詰める（after）
docker mcp gateway run --servers=duckduckgo \
  --interceptor 'after:exec:jq -c ".content[].text |= (.[:100])"'

streaming・sseのbeforeインターセプター不具合（Issue #358）

v0.44.3でstreaming接続に before:exec と after:exec を付けて tools/call を送ったところ、ツールは実行されず「marshalling request: json: unsupported type: func(mcp.CloseSSEStreamArgs)」というエラーが返りました。同じ指定をstdio接続にすると、v0.44.3でもv0.43.3でもbefore・afterの両方が動き、検索結果も返りました。この現象はIssue #358として2026年1月23日に報告され、2026年10月31日時点でも未解決です。HTTP接続で監査や遮断をインターセプターに頼る設計は現時点では成り立たないので、stdioで使うか、Gatewayの手前に別のプロキシを置いてください。

他社の「MCPゲートウェイ」との違いと選び方

「mcp gateway」で検索すると、IBM・Microsoft・Cloudflareなどの同名の製品が並びます。名前は同じでも、どこで動きどこまで管理するかが違います。

IBMのContextForge（旧称MCP Context Forge・Apache-2.0）は、MCPに加えてA2AやREST・gRPCのAPIもまとめて登録し、ツールを束ねた仮想サーバーを作れるレジストリ兼プロキシです。Microsoftのmcp-gatewayはKubernetesでの運用を前提にしたリバースプロキシで、ローカルで試す手順でもKubernetesの有効化を求めます。agentgatewayは2025年にLinux Foundationへ寄贈されたプロジェクトで、LLM・MCP・エージェント間通信の経路制御を担います。CloudflareのMCP server portalsは2026年9月24日に一般提供が始まり、複数のリモートMCPサーバーを1つのHTTP窓口にまとめます。Cloudflare側の構築手順はCloudflare MCPとは？WorkersでリモートMCPサーバーを作る手順とMCPサーバーポータル、Envoy系の選択肢はAgent Routerとは｜Envoy AI Gateway改称後の構成とMCPゲートウェイの導入判断で扱っています。

Docker MCP Gatewayを選ばないほうがよい場面

Docker MCP Gatewayが強いのは、開発者の手元やCIで、MCPサーバーをコンテナに閉じ込めて動かす場面です。次の条件に当てはまる場合は、別の製品を選んでください。

• 数十人規模で同じMCPサーバー群を共有し、利用者ごとの権限を管理したい：Docker MCP Gatewayのトークンは1つで、利用者を区別しない。ContextForgeやagentgatewayのような集中管理型を選ぶ。
• HTTP接続でツール呼び出しの監査・遮断をインターセプターに任せたい：Issue #358が直るまでbeforeが動かない。
• サーバーを常時インターネットに公開したい：公開・冗長化を含めた基盤を別途設計する必要がある。CloudflareならWorkersでリモートMCPサーバー自体をホストでき、MCP server portalsで複数のサーバーを1つの窓口にまとめられる（ポータルは集約の窓口で、サーバーのホスティングはWorkers側が担う）。

社内向けのAIエージェントにMCPサーバーを組み込む構成から相談したい場合は、AIエージェント開発の支援でも対応しています。

よくある質問

Docker MCP GatewayはGitHubで公開されていますか？

はい。docker/mcp-gateway としてMITライセンスで公開されています。2026年10月時点の最新はv0.44.3（2026年10月26日）で、リリースはすべてPre-release表示です。Docker Desktopに同梱される docker mcp プラグインの実体もこのリポジトリです。

docker mcp server enableが使えないのはなぜですか？

v0.44.3ではプロファイル機能が常時有効になり、docker mcp server enable は廃止扱いになったためです。代わりに docker mcp profile server add でプロファイルにサーバーを追加するか、docker mcp gateway run --servers=サーバー名 で直接指定します。

Docker MCP Gatewayの既定のポート番号はいくつですか？

既定はstdio接続なのでポートは開きません。--transport=sse か --transport=streaming を指定してポートを省くと8811で待ち受けます。--host を付けないと全インターフェースで待ち受ける点に注意してください。

Docker Desktopが無くても使えますか？

使えます。Linuxなら docker-mcp バイナリをCLIプラグインとして置けば動きます。Docker Desktopの無いmacOSではプラグインが止まるため、公式イメージ docker/mcp-gateway:v0.44.3 にDockerソケットを渡してコンテナとして起動します。

DuckDuckGoなどカタログのサーバーはどう指定しますか？

従来方式なら --servers=duckduckgo のようにカタログのサーバー名を書きます。プロファイル方式なら docker mcp profile server add プロファイル名 --server catalog://mcp/docker-mcp-catalog/duckduckgo で追加し、--profile で起動します。DuckDuckGoサーバーはAPIキー不要で、search と fetch_content の2ツールを公開します。

関連記事

• Docker MCP Toolkitの使い方｜プロファイル作成とClaude・Cursor接続、docker mcpコマンド【2026年10月】
• Streamable HTTPとは？MCPのトランスポートとSSEの違い、2026-07-28仕様の変更点
• Agent Routerとは｜Envoy AI Gateway改称後の構成とMCPゲートウェイの導入判断
• Cloudflare MCPとは？WorkersでリモートMCPサーバーを作る手順とMCPサーバーポータル【2026年10月】
• MCP（Model Context Protocol）とは？仕組み・APIとの違い・MCPサーバーの作り方