ジョブカン事業部のアドベントカレンダー11日目の記事です！

ジョブカン事業部で開発を担当している @osakanabokujo と申します。

この記事では、コンテナ内開発環境で Cursor を利用し、Docker Desktop MCP Toolkit と MCP Gateway を使ってローカルのMCPサーバー（Context7）にアクセスする方法を紹介します。

はじめに

どうも、Docker大好き芸人で～す。

Docker好きとしては、開発はコンテナ内（Dev Containers）で行いたいし、MCPサーバー自体もローカルのコンテナとして安全に起動・管理したいわけです。
（なぜMCPサーバーをコンテナで実行すると安全なのかは、以下が参考になります！）
https://github.com/docker/mcp-gateway/blob/main/docs/security.md

ところが、開発用のDockerコンテナ内からMCPサーバーをコンテナで起動しようとすると、うまくできません。
これはコンテナ内からDocker Desktopのホストにアクセスできないためです。

そこでMCP Toolkitを利用してMCPサーバーを起動し、MCP Gatewayを使用しHTTP経由でホスト側(WindowsやMac)とコンテナ内で通信できればよいのではと考えました。

Docker Desktop MCP Toolkitとは？

ｺﾚです

まだbetaなので、設定画面から設定を有効にしないと使えません。

MCP Toolkitは、MCPサーバをDockerコンテナで立ち上げるための管理ツールのようなもの。
これはCLIに直接インストールして使うこともできます。
https://docs.docker.com/ai/mcp-catalog-and-toolkit/toolkit/
今回の主題であるDocker Desktop MCP Toolkitは、MCP ToolkitをDocker Desktopから使うものです。

ちなみにこの機能だけであれば、Clientタブから直接Cursor等の開発ツールと接続することができます。

ただし、冒頭で述べたコンテナ内開発環境では、この接続方法（Clientタブからの直接接続）は使えません。これは、開発コンテナ内からDocker Desktop（ホストOS側）へのアクセスが必要となるためです。
さすがにネットワークのレイヤーが異なるため、そのままでは通信できませんね。

一応、コンテナ内からホストOSにssh接続してアクセスする方法も考えられますが、設定が煩雑になるため、チーム等での採用は難しいと感じました。

MCP Gatewayによる解決

そこで今回はMCP Gatewayを使用します。
https://github.com/docker/mcp-gateway
Docker Desktop環境であれば、デフォルトでインストールされています。

MCP Toolkitを使う場合は以下のような通信経路になります。

Cursor(コンテナ内)👉(streaming(HTTP))👉MCP Gateway(ホスト)👉(stdio)👉MCPサーバー(Dockerコンテナ)

（MCPサーバーはDocker DesktopのMCP Toolkitで管理・起動しています。）

図にまとめると以下のような感じです！! (本記事ではWindows+WSL環境を例としていますが、基本的な通信の考え方はMacなど他の環境でも同様です)

streaming(HTTP)を経由することで、コンテナ内からホストのMCP Toolkitへアクセスできるようになります！

やってみる

MCPサーバーの追加

まず、MCP ToolkitへCatalog(MCPサーバー)を追加します。
せっかくなので、推しMCPサーバーのContext7を追加してみたいと思います。

Context7は、最新かつ正確なライブラリやフレームワークのドキュメント情報をリアルタイムで提供するツールです。
このツールはAIへプロンプトを投げる際にContext7から取得した最新のドキュメントを添えることで、AI内の古い学習済みデータに基づいて誤ったコードを生成するハルシネーションを防ぐことができます。

自分の環境では上の方にありましたが、無かったら検索してください。
＋マークを押すことで追加できます。

追加されるとMy serversに追加されます。

追加できましたね！

MCP Gatewayの起動

ホスト側のShell（Windowsならコマンドプロンプト等）で以下のコマンドを実行します。
portは都合のいいものに書き換えてもらって問題ありません。

docker mcp gateway run --port 8008 --transport streaming

実行されると多量のログが流れますが、上の方にトークンが記載された行があるので拾っておきます。

Cursorの設定

Cursorの設定ファイル mcp.json に設定を追記します。
url のホストIPアドレスには、Docker Desktopが動作しているPC（ホスト）のローカルIPアドレスを入力してください。
トークンには先ほどログから取得した値を設定します。

mcp.json

{
  "mcpServers": {
    "MCP_DOCKER": {
      "type": "stream",
      "url": "http://{ホストipアドレス}:8008",
      "headers": {
          "Authorization": "Bearer {トークン}"
        }
    }
  }
}

これで設定完了です！

うまくいくとCursorのTools & MCPで以下のような表記になります。

うまくいかない時は、パネル⇒出力⇒MCP: user-MCP_DOCKERを開くとエラーがでています。
エラーを見て解消してみてみてください！

ちなみに、いつのまにかトークンが必須になっていました。
以前は無認証でも接続できましたが、現在はトークンが必須となっています。仕組み上、他のマシンからもアクセスできる可能性があるため、認証が必須となったのは妥当ですね。

これは任意ですが、Cursor側のルールにuse Context7を追加しておきます。
プロンプトを実行するときに、Context7を使って最新ドキュメントを取得してやりとりを行おうぜ、という命令ですね。

追加しない場合は、以降のステップでプロンプトにuse Context7を追加して入力してください。

プロンプトを投げてみる

ここからは普通のMCPツール紹介です（笑）

チャットでBuilderパターンについて教えてと聞いてみます。

詳しく調べてくれていますね！

Context7を実行した2個目のMCP実行を開いてみます。

context7のパラメータを見てみると、refactoring_guru-design-patternsとあるので以下のサイトから情報を取得しているようです！

うまく使えていますね！
(ちなみにこのサイト、詳しくデザインパターンが乗っていて勉強になります！)

感想

いつのまにかDocker Desktop MCP Toolkitなるものが公開されていたため、試してみました。

選定理由は、MCPサーバーの用意のためにコンテナ起動したいのだからDockerネイティブの機能の方が楽でしょ、という安直なものです😌
他にもMCPサーバーをまとめるツールはあるようなので、調べてみたいと思います！

利点

使ってみて+環境構築としてMCP Toolkit+MCP Gatewayを使用する利点を以下にまとめてみました。

Docker Desktopのネイティブ機能でサポートされているから誰でも使いやすい
コンテナ内開発における、ホスト上のMCPサーバーへのアクセス問題を解消できる
DockerでMCPサーバーを一元管理できる
複数の開発ツール（CursorやVS Codeなど）や複数のウィンドウからの同時利用が可能

操作が容易

1は結構大事だと思っていて、チーム開発などではGUIの使いやすいツールの方が浸透しやすく管理もしやすいためです。CLIツールも偉大なのですが、人によって得意不得意がでてしまうので、できれば自動化したいです。
といいつつ、CLIツールのMCP Gatewayを使用しているのでなんともですね。ぜひ、Docker DesktopのGUIから設定できるようになってほしいですね！

コンテナ内からコンテナMCPサーバーを取り扱える

これはMCP Gatewayの機能ではあるのですが、とても便利です。
開発環境がどんな構成であっても、HTTPさえ通信できればMCPサーバーにアクセスができるということです。
開発環境の構成を気にしなくてよくなります。

また、streamingで通信できる以上、理論上は別のマシンからアクセスできます。（現在はトークンで認証が必要なので容易ではありませんが…）
個人的に特に魅力的だと感じている点は、MCPサーバーにナレッジを集約しやすくなることです。

例えば、以下のような取り組みにつなげられるなと考えています！

サーバーを用意して常時MCP ToolkitとMCP Gatewayを起動する
チームメンバーはAIチャットの結果が自動でMCPサーバーに集約するように設定する
プロダクトの仕様等、コードを深堀りしないと分からないナレッジがMCPサーバーに集約される
AIが先にMCPサーバーからナレッジを取得してプロンプトに混ぜる
回答精度が向上する

あくまでこの取り組みの、インフラ的な運用が楽になるかも、という感じですね。
（やるとしたら、CLIでの運用になると思うのでDocker Desktopでの操作はできなくなりそうですが…）

MCPサーバーを一元管理できる

結構便利かなと思います。コンテナをDocker側がネイティブに管理してくれるため、docker psでも表示されません。
今後便利系MCPサーバーが増えていくことを考えると、管理が煩雑になっていくことが予想されるため、大事な要素です。

複数のCursorから開発できる

かなり大事なんじゃないかと思います。
今後、もっとAIの精度があがっていけば2画面を使って、AIが自動変更を行っている間に別画面のCursorにプロンプト指示を書く、ということは当たり前に起こりそうです。
今回、私がMCP Toolkitを使ってみようと思ったきっかけもこれでした。

こういうことをしたくて…

直にコンテナを起動してMCPサーバーを起動している場合、Cursorを開いた分だけコンテナ起動してしまいます。
まあ別にいいのですが、その分PCリソースが消費されるので微妙です。
その点MCPサーバーを一元管理することで、リソースを節約できるのはありがたいです。

また、CursorだけでなくVS CodeとCursorなど、複数の開発ツールを併用することで、定額サブスクのクレジットの消費を分散して管理できていいですね。

欠点

MCP Gatewayの使い勝手が悪い😡😡

少なくともDocker Desktopから起動するMCP Toolkitとは相性が悪いと思います。

CLIからしか実行できない
自動起動を設定しづらい(Docker Desktopから設定できない）

だれでも使いやすい、という点でDocker Desktop MCP Toolkitは優れているため、MCP GatewayがDocker Desktopから操作できないのは非常にマイナスポイントです。
裏を返せば、MCP GatewayがDocker Desktopから操作できるようになれば、欠点が解消されるということです。
期待ですね～

さいごに

株式会社DONUTSおよびジョブカン事業部では、新卒・中途を問わず一緒に働くメンバーを募集しています。
もし弊社に興味を持っていただけた方、あるいは「業務で堂々とMCPツールを試してみたい」という方は、ぜひ応募をご検討ください！！