「コンテナのログを見て」「n8nを立ち上げて」と話しかけるだけで、自宅サーバーのDocker環境が動く——そんな構成が、ローカルLLMとMCPサーバーの組み合わせで実現できます。

この記事では、XDA DevelopersのAyush Pande氏が実際に構築した「ローカルLLM × Docker MCPサーバー」の仕組みと、再現に必要なセットアップ手順、安全に使うための制限設定までを整理します。

この記事でわかること

  • MCPサーバーがDocker操作に使える理由
  • mcp-server-dockerの導入手順とローカルLLMとの接続方法
  • コンテナ作成・障害修復まで自然言語で任せた具体例
  • 誤操作を防ぐためのツール制限設定

MCPとは何か

MCP（Model Context Protocol）は、LLMと外部サービスをつなぐためのプロトコルです。LLMが出した指示を、DockerやHome Assistantなど各アプリが理解できるツール呼び出しに変換します。LLM単体ではコンテナの起動やログ取得はできませんが、MCPサーバーが間に入ることで、会話ベースのインフラ操作が可能になります。

Pande氏はHome AssistantやNextcloudにもMCPを接続しており、今回はDocker管理に焦点を当てています。Docker Desktopには公式のMCP Gatewayが組み込まれていますが、ホスト上のDocker環境を直接触るには追加の工夫が必要です。そこで、開発者ckreiling氏が公開した非公式パッケージ「mcp-server-docker」を採用しました。

mcp-server-dockerの概要

https://github.com/ckreiling/mcp-server-docker

mcp-server-dockerは、自然言語でDockerを操作するためのMCPサーバーです。コンテナの一覧・作成・起動・停止・ログ取得、イメージのpullやbuild、ボリュームやネットワークの管理まで、Docker SDK経由でホストのDockerデーモンに直接アクセスします。SSH経由でリモートのDockerデーモンに接続する設定（DOCKER_HOST=ssh://ユーザー@ホスト）にも対応しています。

READMEでは、LLMが作成するコンテナは必ず人間が確認すべきだと明記されています。Dockerは安全なサンドボックスではなく、--privilegedなどの危険なオプションは意図的にサポート外とされています。

セットアップ手順

1. MCPサーバーの設定ファイルを用意する

config.jsonを作成し、以下を記述します。

{
  "mcpServers": {
    "mcp-server-docker": {
      "command": "uvx",
      "args": [
        "mcp-server-docker"
      ]
    }
  }
}

uvxはPythonパッケージ実行ツール「uv」に付属するコマンドで、PyPIからmcp-server-dockerをそのまま起動できます。

2. mcp-proxyでサーバーを起動する

ターミナルで次を実行します。

uvx mcp-proxy --named-server-config config.json --allow-origin "*" --port 8001 --stateless --host 0.0.0.0

これでポート8001にMCPサーバーが立ち上がり、ローカルLLMから接続できるURLが生成されます。

3. ローカルLLMと接続する

Pande氏の環境では、RTX 3080 Ti上でQwen3.6-35B-A3Bを動かしています。MoEオフロードにより秒間24トークン、コンテキストウィンドウは10万トークンです。llama-serverのWeb UIはMCPサーバーに対応しており、起動時に--webui-mcp-serverフラグを付け、mcp-proxyが出力したURLを登録して接続します。

クラウドAPIを使わず、推論からDocker操作まですべてローカルで完結する構成です。Pande氏によると、Raspberry Pi上の低パラメータモデルでは誤ったツール呼び出しが頻発し、環境が混乱したため、35BクラスのMoEモデルが実用ラインだと判断しています。

自然言語でできる操作の具体例

既存コンテナの管理

コンテナのヘルスチェック、ログ閲覧、ボリューム一覧、ネットワーク設定の変更など、日常の運用タスクを会話で実行できます。Pande氏は「孤立しているボリュームを洗い出して」と指示し、Qwen3.6-35B-A3Bが複数回のツール呼び出しに分解して対応したと報告しています。

新規コンテナのデプロイ

具体的なパラメータを指定するケースから、曖昧な指示に任せるケースまで試しています。

  • n8n: /home/node/.n8n用のローカルディレクトリとポート5678を指定してデプロイに成功
  • BentoPDF: ポートマッピング3000:8080だけを伝え、残りの設定はLLMに任せて起動
  • Joplin: 新規フォルダをボリューム先に指定。初回はコンテナが壊れたが、原因はLLMの設定ミスではなくサーバーの時刻同期問題だった。LLMがログを読み取り、runコマンドの修正で自動修復した

複数コンテナが必要なFOSSツールにも対応でき、指示を段階的に曖昧にしても動作する点が特徴です。

安全設定で誤操作を防ぐ

LLMの推論が外れると、ボリュームやネットワークの削除で稼働中のサービスが壊れる恐れがあります。Pande氏は次の制限を設けています。

ツール 設定 理由
remove_volume deny（拒否） マウント済みボリュームの削除でコンテナが破損する
remove_network deny（拒否） ネットワーク削除で接続が切れる
remove_container 削除前に確認を要求 トラブルシュート時の再作成には必要なため

mcp-server-dockerのREADMEでも、APIキーやDBパスワードなど機密データをコンテナ設定に含めないよう警告されています。LLMとやり取りした情報は、ローカル推論であっても漏洩リスクがあると考えるべきです。

Docker公式MCP Gatewayとの違い

Docker DesktopにはMCP Gatewayが標準搭載されており、Desktopアプリからすぐ使えます。一方、mcp-server-dockerはホストのDockerソケットに直接接続する非公式ツールです。Desktopを介さず自宅サーバーやリモートノードのDockerを操作したい場合に向いています。Pande氏は今後、リモートノードをこの構成に追加する予定だと述べています。

運用を始める際のポイント

ローカルLLMとmcp-server-dockerを組み合わせれば、セルフホスティング環境のコンテナ管理を会話ベースに切り替えられます。35BクラスのMoEモデルとツール権限の制限が、実用と安全の両立に欠かせません。まずはremove_volumeとremove_networkをdenyにし、コンテナ削除だけ確認付きにする——この3点セットから試すのが現実的です。