Docker MCP と Kubernetes MCP｜クラスタ操作をAIに触らせていいかの判断フレーム（要調査）

コンテナオーケストレーションの運用現場において、LLM（大規模言語モデル）の推論能力をインフラ操作に直結させる「MCP（Model Context Protocol）」の活用が急速に注目されています。これまでエンジニアが手作業で kubectl get pods や docker logs を実行し、その結果をAIにコピペして解析させていたフローが、MCPの登場により「AIが直接クラスタの状態を把握し、必要なコマンドを実行する」形へと進化しました。

しかし、本番環境のクラスタ操作をAIに委任することには、当然ながら慎重な判断が求められます。本記事では、Docker MCPおよびKubernetes MCPの具体的な導入手順から、AIに操作権限を与える際の判断基準（フレームワーク）、そしてセキュリティ上のガードレール設計について、実務者の視点で詳しく解説します。

1. MCP（Model Context Protocol）が変えるコンテナ運用

MCPは、Anthropic社が提唱した、AIモデルと外部データソース・ツールを安全に接続するためのオープンスタンダードです。これをコンテナ環境に適用することで、Claude Desktopなどのクライアントを通じて、自然言語で次のような指示が可能になります。

• 「起動に失敗しているPodの原因をログから特定して修正案を出して」
• 「開発環境でメモリ使用量が多いコンテナを特定し、再起動して」
• 「現在のDeployment設定とベストプラクティスを比較して、改善点を指摘して」

これにより、エンジニアの「認知負荷」が大幅に軽減されます。一方で、AIが意図しないリソース削除を行わないよう、適切な権限管理と「どこまで触らせるか」の定義が不可欠です。インフラの負債化を防ぐための考え方は、SaaSコストとオンプレ負債を断つ。バックオフィス＆インフラの「標的」と現実的剥がし方でも触れている通り、ツールの導入そのものよりも「責務の分解」が重要となります。

2. Docker MCP の導入と実務活用

Docker MCPは、主にローカル開発環境におけるDocker DesktopやDocker Engine上のリソースをAIが操作するための仕組みです。開発者が「このコンテナがなぜ立ち上がらないのか」を調べる際、AIが直接 docker ps -a や docker inspect の結果を参照できるようになります。

Docker MCP Server のセットアップ手順

一般的に、Claude Desktopをクライアントとして使用する場合の手順は以下の通りです。

1. MCP設定ファイルの編集: ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) を開きます。
2. サーバー設定の追加: 以下の通り、Docker MCP Serverを登録します。

   {
   "mcpServers": {
   "docker": {
   "command": "npx",
   "args": ["-y", "@modelcontextprotocol/server-docker"]
   }
   }
   }
   

3. Claude Desktopの再起動: 設定を反映させると、右下にハンマーアイコン（ツールアイコン）が表示され、Docker操作ツールが認識されます。

ローカル環境でのユースケース

Docker MCPを利用することで、複雑な docker-compose 環境のトラブルシューティングが劇的に効率化されます。例えば、「DBコンテナとの接続エラーが出ている原因を調べて」と投げるだけで、AIがネットワーク設定とログを照合し、環境変数の不備を特定してくれます。

3. Kubernetes MCP の導入と実務活用

Kubernetes MCPは、kubectl が操作する対象（EKS, GKE, オンプレK8sなど）に対してAIがAPIを発行することを可能にします。Docker MCPよりも影響範囲が広いため、より厳格な設定が求められます。

Kubernetes MCP Server のセットアップと権限設定

Kubernetes MCPを使用する場合、AIが「どのコンテキスト（Context）」を「どの権限」で触るかを制御することが最優先事項です。

1. kubeconfigの確認: AIが使用するコンテキストを、あらかじめ kubectl config use-context で指定しておくか、MCPサーバーの引数で制限します。
2. 設定例:

   {
   "mcpServers": {
   "kubernetes": {
   "command": "npx",
   "args": ["-y", "@modelcontextprotocol/server-kubernetes"],
   "env": {
   "KUBECONFIG": "/path/to/restricted-kubeconfig"
   }
   }
   }
   }
   

注意点：RBAC（Role-Based Access Control）の適用

AIに渡す kubeconfig は、管理者権限（cluster-admin）であってはなりません。AIによる誤操作や、プロンプトインジェクションによる悪意あるリソース操作を防ぐため、「参照専用（ReadOnly）」のRoleを割り当てたServiceAccountのトークンを使用することを強く推奨します。

データ連携の全体像を設計する際の考え方は、SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』で解説している「各システムの責務と権限の分離」の原則と同じです。AIも一つの「外部システム」として捉え、最小権限の原則（Least Privilege）を適用してください。

4. 【比較】Docker MCP vs Kubernetes MCP

それぞれの特性を以下の表にまとめました。導入の際の参考にしてください。

5. AIにクラスタ操作を触らせていいかの判断フレームワーク

「AIにどこまで権限を渡すべきか」という問いに対し、以下の3つのステップで判断することをお勧めします。

ステップ1：環境（Environment）による判断

• ローカル開発環境: 「実行（Write）権限」を付与しても良い。 失敗しても個人の環境で完結するため、AIによる自動修復を試す価値が高い。
• 検証（Staging）環境: 「限定的な実行権限」に留める。 特定のNamespace内に限り、Podの再起動などを許可する。
• 本番（Production）環境: 「参照（Read）専用」を絶対原則とする。 AIには「現状の分析」と「改善案の提示」だけをさせ、実際の kubectl apply は人間が行う（Human-in-the-loop）。

ステップ2：業務の可逆性による判断

AIに行わせようとしている操作が「すぐに元に戻せるか」を考慮します。例えば、オートスケールの設定変更やPodのローリングアップデートなどは可逆性が高いですが、PV（Persistent Volume）の削除やDBコンテナの破棄は不可逆的なダメージを与えます。不可逆な操作を伴うツールは、MCPの定義から外すか、実行前に必ず人間の承認を挟む仕組みを構築すべきです。

ステップ3：監査（Audit）体制の有無

AIがどのようなプロンプトに対し、どのMCPツールを呼び出し、どのようなAPIレスポンスを得たかをログとして記録できているかを確認してください。Claude Desktop等のクライアント側のログだけでなく、Kubernetes側のAudit Logで「AI用のServiceAccount」の動きを追跡できる状態が理想です。こうしたガバナンスの考え方は、SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャにおけるアイデンティティ管理と同様に、現代のITインフラ運用では避けて通れない要素です。

6. 実務上のエラーと対処法

MCPを導入する際によく遭遇するトラブルとその解決策をまとめました。

• エラー: MCPサーバーが起動しない (Timeout)

  原因: npx の実行権限や、Node.jsのバージョン不整合。

  対処: node -v で推奨バージョン（18以上）を確認し、MCP設定ファイルでフルパス（例: /usr/local/bin/npx）を指定する。

• エラー: AIが「権限がありません」と回答する

  原因: kubeconfig で指定されたコンテキストの権限不足、またはNamespaceの指定漏れ。

  対処: AIへの指示に「Namespace: default を参照して」と含めるか、RBACで当該Namespaceへの list/get/watch 権限を明示的に付与する。

• エラー: Docker Desktopとの接続エラー

  原因: Docker Socket（/var/run/docker.sock）へのアクセス権限がない。

  対処: 実行ユーザーが docker グループに属しているか確認し、Docker Desktopの設定で「Allow the default Docker socket to be used」が有効になっているか確認する。

7. まとめ：コンテナ運用の自律化へ向けて

Docker MCPやKubernetes MCPは、インフラエンジニアを単純なログ確認作業から解放し、より高度なアーキテクチャ設計や最適化に集中させる強力なツールです。しかし、その強力さゆえに、AIを「万能な管理者」ではなく「指示に従うジュニアエンジニア」として扱い、適切な権限という名の「ガードレール」を敷くことが、プロフェッショナルとしての実務担当者の役割となります。

まずは開発環境でのDocker MCP活用から始め、徐々にKubernetesのReadOnly権限を用いた検証環境の診断へとステップアップしていくことをお勧めします。AIとの共生は、安全な権限管理の上にのみ成り立つものです。