ホームラボのVM作成を、シェルスクリプトではなく自然言語で済ませる構成が、実運用レポートとして注目を集めています。
テクノロジー系ライターのJoe Rice-Jones氏は、Claude DesktopにProxmox向けMCPサーバーを2本接続し、英語の一文からVMを立ち上げ、稼働中のVMからTerraform設定を逆生成するワークフローを公開しました（参考）。
この記事では、同氏の構成を軸に、MCP（Model Context Protocol）で仮想化基盤をAIに触らせるときの設計判断と、実際の運用で効くポイントを整理します。
この記事でわかること
- Proxmox向けMCPサーバーを2本に分ける理由
- 会話からVMを作成する手順とルーティングの仕組み
- 稼働中インフラからTerraformを逆生成する流れ
- APIキー権限と人間の確認を残す安全設計
課題は「手作業VM」と「ドキュメント不在のIaC化」
ProxmoxのWeb UIはVM作成自体は速いです。一方で、試験用VMを何度も立てるたびにスクリプトを書くか迷う場面は珍しくありません。Rice-Jones氏も、プロビジョニング速度より「次もスクリプト化するかどうかの判断コスト」が下がったと述べています。
もう一つの課題は、数か月かけて手で増やしたVMの行方です。設定の記録が残らないままインフラが膨らむと、後からTerraformなどのIaC（Infrastructure as Code）に載せ替える作業が重くなります。新規構築用のTerraformは手順が確立されていますが、既存環境の「逆輸入」は手作業が多くなりがちです。
解決策はMCPサーバー2本と権限の切り分け
MCPは、AIアプリケーションと外部システムをつなぐオープン標準です。Claude DesktopなどのMCPクライアントは、接続したMCPサーバーが公開するツールを通じてAPI操作を実行します（参考）。
Rice-Jones氏の構成の核心は、1本の万能接続ではなく役割分担です。
| 役割 | ツール数の目安 | 主な用途 |
|---|---|---|
| 作成・操作系 | 約250ツール | VM作成、クラスタ操作などProxmox APIの大半をカバー |
| 読み取り・エクスポート系 | 35ツール（実使用は2つ） | 稼働VMのTerraform設定生成 |
作成系には、PyPIのproxmox-mcp-server（GitHub: GethosTheWalrus/proxmox-mcp）のような大規模サーバーが該当します。環境変数TOOL_ROUTING=trueにすると、公開ツールはroute_tools、call_routed_tool、proxmox_api_rawの3つだけに絞られます。Claudeはまず「VMを作るツールはどれか」とルーティング層に問い合わせ、返ってきた短い候補からcreate_vmなどを選びます。1回の依頼が2段階になる分だけ応答は遅くなりますが、コンテキストウィンドウを本題に使える利点があります（参考）。
エクスポート系には、GitHubのmjrestivo16/mcp-proxmoxが代表例です。35ツールのうちTerraform連携は2つで、pve_generate_terraformが個別VMのHCLを、pve_generate_terraform_providerがクラスタ向けプロバイダーブロックを出力します（参考）。
重要な設計は、作成系サーバーはTerraformを知らず、エクスポート系は新規VMを作れない点です。重複はありますが、会話での試行錯誤とIaC化を意図的に分離しています。
会話からVMを作る流れ
https://github.com/GethosTheWalrus/proxmox-mcp
Claude Desktopのclaude_desktop_config.jsonにMCPサーバーを登録し、Proxmox VEのAPIトークンを環境変数で渡します。Proxmox側では、Datacenter > Permissions > API Tokensからトークンを発行し、必要最小限の権限に絞るのが推奨です。
実際の依頼例は次のとおりです。
create a small Ubuntu VM on the pve node with 2 cores and 4GB of RAM, ID 999
Claudeはルーティング経由でcreate_vmを呼び出し、指定ノードに2コア・4GB RAMのUbuntu VM（ID 999）を作成します。Rice-Jones氏は数分以内にこの操作が可能になったと報告しています。
ただし、これは無人自動化ではありません。依頼内容の確認から実行結果の検証まで、人間が介在する「支援型インフラ管理」として運用しています。AnsibleやTerraformによる本番自動化は、設計が固まったあとに別途使う位置づけです。
稼働VMからTerraformを逆生成する
https://github.com/mjrestivo16/mcp-proxmox
2本目のMCPサーバーは、グリーンフィールド構築ではなく、すでに動いているVMの設定をコードに戻す用途です。手順は会話ベースで次のように進みます。
- Claudeにクラスタ内のVM一覧を取得させる
- IaC化したいVMを人間が選ぶ
- 選んだVMごとにTerraform設定を生成させる
- 生成物を手で修正し、
terraform planとimportブロックで既存リソースへ取り込む
生成されるHCLはあくまで足場です。stateファイル、ドリフト検知、モジュール分割、環境分離といったIaCの基本要素は人間側の知識が前提になります。Terraform本体がimportを実行し、Claudeは指示書づくりを手伝う役割にとどまります。
MCPは置き換えではなく上乗せのCLI
Rice-Jones氏は、MCPがTerraformやAnsibleの代替にはならないと明言しています。マイグレーションが止まったときの確認、過去1週間のCPUグラフ閲覧、視覚的フィードバックが要る作業は、これまでどおりProxmox UIを使います。ZFSプールの操作はClaudeに任せない、とも述べています。
MCPはコマンド構文を覚えなくてよいCLIに近い存在です。NASやDNSサーバーも別MCPで接続し、全体構成の推測精度を上げていますが、VLAN割り当てやストレージ階層、命名規則は学習が必要な領域として残ります。
安全面で忘れてはいけないこと
MCPはProxmox APIの危険性を下げません。権限の広いAPIキーを渡せば、会話1つでVM削除まで届きます。スコープを絞ったAPIトークンの利用は必須です。MCPは安全柵を増やすのではなく、到達可能な操作の幅を広げるだけ、という認識が記事の結論に近い部分です。
コミュニティ製MCPサーバーは複数あり、@samik081/mcp-pveのようにアクセス階層（read-only / read-execute / full）で絞れるものや、読み取り専用の@itunified.io/mcp-proxmoxのように監視特化のものも存在します。自環境のリスク許容度に合わせて選び、作成系とエクスポート系の分離は応用できます。
ホームラボ運用者が持ち帰れること
Rice-Jones氏の事例は、新製品発表ではなく既存ツールの組み合わせ術です。ClaudeとProxmoxをMCPでつなぐことで、VM試行のハードルが下がり、散らばったVMをあとからTerraformへ逆輸入する道筋ができます。成功の条件は、ツール接続そのものより、API権限の設計と人間による確認フローを残すことにあります。会話でインフラを触る未来は、自動化の代替ではなく、設計と記録の補助として現実的に使えます。