Docker MCP Gateway でAIエージェント用MCPサーバをコンテナ隔離する
AIコーディングエージェント(Claude Code、Cursor、各種IDEアシスタント)から外部ツールを呼び出す標準として MCP(Model Context Protocol) が定着してきた。一方で、MCPサーバは「npx で得体の知れないパッケージを実行する」「ホストのファイルや環境変数に無防備にアクセスする」「秘密情報を平文で設定に書く」といった運用上の危うさを抱えがちだ。
2026年に入り Docker が押し出しているのが Docker MCP Catalog / Toolkit と、その中核である MCP Gateway である。狙いはシンプルで、MCPサーバをコンテナの中で隔離して動かし、複数サーバを1つのゲートウェイの背後に束ね、秘密情報は Docker が管理する仕組みに寄せる、というものだ。エージェント側から見ると接続先は「ゲートウェイ1つ」だけになり、個々のサーバ実装やランタイム差異を意識せずに済む。
本記事では、この Gateway が解く問題を整理したうえで、ローカルで無料で完結する手順として CLI プラグインで MCP サーバをコンテナ起動し、ツール一覧の取得・呼び出しまでを実際に試す。
MCP Gateway が解く3つの課題
- 隔離: 各 MCP サーバを独立したコンテナで起動する。ホストの全ファイルではなく、明示的にマウントしたパスだけを露出できる。npx で任意コードをホスト直上で走らせるより攻撃面が小さい。
- 集約: 複数の MCP サーバ(GitHub、ファイルシステム、検索など)を1つの Gateway の背後に集約する。エージェント側の設定は Gateway 1エントリだけになる。
- 秘密情報の分離: API トークン等を設定ファイルへ直書きせず、Docker が管理するシークレット経由でコンテナへ注入できる。
アーキテクチャは「エージェント → MCP Gateway(stdio か streaming で待受) → 各 MCP サーバコンテナ」という素直な多段構成だ。
前提
- Docker Desktop
4.59以降(MCP Toolkit 機能を含む)。docker mcpCLI プラグインが同梱される。 - 動作確認は 2026年7月時点。カタログの中身は随時更新されるため、サーバ名やタグは
docker mcp catalog showで都度確認すること。 - ここで扱う操作はすべてローカル実行で課金は発生しない。外部SaaS(GitHub等)のMCPサーバに実際のトークンを渡す場合のみ、そのサービス側のレート制限や権限に注意する。
まずプラグインが入っているか確認する。
1 | |
サブコマンド(catalog / gateway / tools / secret / client など)の一覧が表示されれば準備完了だ。表示されない場合は Docker Desktop を最新へ更新し、Settings の Beta features で「Docker MCP Toolkit」を有効化する。
実際に試す
1. カタログを確認する
Docker が公開するキュレーション済みカタログには、コンテナ化された MCP サーバが並ぶ。まずローカルに取得済みのカタログを一覧する。
1 | |
期待される出力(例):
1 | |
カタログの中身(収録サーバ)を見るには次を実行する。
1 | |
サーバ名(fetch、filesystem、github など)とタグ、必要なシークレットや設定項目が確認できる。以降のサーバ名は環境の出力に合わせて読み替えること。
2. サーバを有効化する
利用したいサーバを有効化する。ここでは秘密情報も外部SaaSも不要な fetch(URLを取得してテキスト化する軽量サーバ)を例にする。
1 | |
server ls で有効なサーバ一覧が確認できる。これらは Gateway 起動時にコンテナとして立ち上がる。
3. Gateway をドライランで確認する
いきなり常駐させる前に、どのサーバ・ツールが構成されるかを確認する。--dry-run は実際にはサーバを起動せず、構成だけを検証する。
1 | |
構成に問題がなければ、次に実際に起動する。stdio(標準入出力)はエージェントが直接プロセスとして起動する接続方式、streaming は HTTP でポート待受する方式だ。ローカルで手早く試すなら stdio がデフォルトで扱いやすい。
1 | |
Gateway が起動すると、有効化した各 MCP サーバがコンテナとして立ち上がる。別ターミナルで確認できる。
1 | |
MCP サーバ由来のコンテナが docker mcp 系の名前で並んでいれば、隔離起動が効いている。
4. ツールを一覧・実行する(Gateway に触らず単体検証)
Gateway を常駐させなくても、CLI から集約されたツール群を直接叩いて動作確認できる。まずツール一覧を取得する。
1 | |
有効化したサーバが提供するツール(fetch なら URL 取得系のツール)が列挙される。JSON で機械可読に取りたい場合:
1 | |
個々のツールの引数スキーマを確認する。
1 | |
実際に呼び出してみる。ツール名と引数は inspect の出力に合わせること(下記の引数キーは環境により異なるため、必ず inspect を先に確認する)。
1 | |
取得したページのテキストが返れば、コンテナ隔離された MCP サーバ経由でツール実行が成立している。ここまでは外部トークン不要・完全ローカルで検証できる。
5. 秘密情報を安全に渡す(GitHub 等を使う場合)
GitHub などトークンが必要なサーバを使うときは、設定ファイルに直書きせず Docker のシークレットへ入れる。標準入力から渡せばシェル履歴にも残らない。
1 | |
その後、対象サーバを有効化して Gateway を起動すると、シークレットが該当コンテナへ環境変数として注入される。トークン文字列が設定JSONやコマンド履歴に露出しないのが利点だ。使い終わったら削除する。
1 | |
6. エージェントから接続する
エージェント側の MCP 設定には、個々のサーバではなく Gateway 1つだけを登録する。stdio 接続の場合、設定JSONは概ね次の形になる(クライアントごとにキー名は異なる)。
1 | |
この1エントリで、Gateway 背後の複数サーバのツールがまとめてエージェントに見える。サーバを増減しても、エージェント側の設定は変更不要だ。Docker Desktop を使う場合は GUI の Clients タブから各クライアントへワンクリックで接続を書き込むこともできる。
後片付け
検証用に有効化したサーバは無効化しておく。
1 | |
起動していた Gateway は Ctrl+C で停止できる。関連コンテナが残っていれば docker ps で確認して停止する。
まとめ
Docker MCP Gateway の要点は「MCP サーバをコンテナで隔離し、複数サーバを1つのゲートウェイに集約し、秘密情報を設定から追い出す」ことに尽きる。npx でホスト直上に任意コードを走らせる従来のMCP運用に比べ、攻撃面と設定の散らばりを確実に減らせる。しかも本記事の検証範囲(fetch サーバ + tools call)はトークン不要・ローカル完結・無料で試せるので、まず手元で1コマンド動かして接続方式の感触を掴むのがよい。
参考: Docker MCP Catalog and Toolkit(公式ドキュメント) / MCP Gateway(公式ドキュメント) / docker/mcp-gateway(GitHub)