AI側のガードレール（ハーネス）や、Proxmox側の権限設定・接続元の制御などをすることを推奨します。
記事執筆時点（PVE9.2）の内容です。
昨今はCodexやClaude Codeなどを使って、Proxmox4兄弟やPVE上のゲストOSに対するオペレーションをする人たちも多いかと思います。
最近、私もそれで構築・運用してます。
だって評価用の4兄弟＋複数PVEクラスタ＋連携するZabbixやAnsibleのメンテナンス大変なんだもん
いろいろなやり方があると思いますので、一旦整理してみます＆所感をメモしておきます。
ホスト管理者目線でのコメントになります。
ちなみに詳細な手順とかは書きません。
AIに調べてもらった方が確実だと思いますし、何より私もAIにぶん投げているのでよく分かって（コマンドレベルで把握して）いません。
接続方法の一覧
以下あたりを検討しました。
| 方法 | AIに渡すもの | 届く範囲 | メリット | デメリット | 所感 |
|---|---|---|---|---|---|
| SSH（ID・パスワード） | rootのパスワード | ホスト全体（同じパスワードでGUI・APIにも入れる） | 準備が要らない | パスワードがコマンドラインや会話の履歴に残る | 論外 |
| SSH（秘密鍵） | 秘密鍵 | ホスト全体（root） | ホスト管理に必要な操作が全部できる。鍵ごとに取り消せる | rootなので何でもできてしまう。クラスタでは全ノードで有効になる | 事実上の選択肢 |
| SSH（物理キー） | 鍵ファイル（物理キーがないと使えない） | ホスト全体（root） | 認証のたびに物理キーへのタッチが要る | リモートの端末経由だと使いにくい。物理キーの管理とコストがかかる | よりセキュアだが試せていない |
| API（ID・パスワード） | パスワード | ユーザーの権限の範囲 | 準備が要らない | パスワードを渡すことになる。2要素認証を有効にしているとAIだけでは使えない | SSHのパスワードと同じ問題がある |
| API（APIトークン） | トークン | ユーザーとトークンの権限が重なる範囲 | 権限・期限を絞れる。ユーザーを止めずに失効できる | コンソールやroot限定の設定は使えない | VMの管理者・利用者向け |
| API（MCP経由） | トークン（MCPサーバーの設定に書く） | トークンの権限＋MCPサーバーのコードが動く範囲 | ツールとして呼べる | 第三者のコードにトークンを預けることになる | おすすめしない |
| Ansible | SSH鍵・APIトークン | playbookに書いた範囲 | 冪等で、レビュー・再現ができる | playbookを書く手間がかかる。check modeに対応していないモジュールがある | 複数のホスト・VM・ゲストOS・アプリの構築に便利 |
| ブラウザ拡張 | なし（ログイン済みのセッションを使う） | ログインしたユーザーがGUIでできること全部（rootならShellも） | GUIを操作でき、スクリーンショットも撮れる。TOTPなどの2要素認証を設定したままでも使える。直接SSHやAPIを叩けない環境でも使える | 画面の文字を指示として読んでしまうリスクがある。タブを開いている間は操作し続けられる | GUIの操作・撮影に便利 |
SSH
ホスト管理をするなら、実質SSH前提だと思います。
GUIやAPIからできないことがいろいろあるためです。
またrootに接続しないでsudoersを使った制御などもあると思います。
ID・パスワードで入る
AIにID・パスワードを渡すため、セキュリティ的に論外だと思います。
秘密鍵で入る
端末に保存した秘密鍵を使って接続します。
端末自体にセキュリティインシデントがない限りは、基本的には大丈夫だと認識しています。
YubiKeyなどの物理キーを使う
よりセキュアな方法としては、YubiKeyなどの物理キーを使う作戦もあると思います。
検討しましたが、リモート端末経由で管理しているクラスタがあった場合には使うのが難しいのと、何よりも物理キーの管理ができる自信がなかったので、試せてはいません。
あとコスト的にもきついです。
ただ、個人的にはProxmoxに限らず、もうちょっと大切なアカウントの保護（例えばGoogleアカウントとか）に使おうか未だ悩んでます。
API
前述の通りAPIだとできない操作もあるのでホスト管理者向けというよりは、VMの管理者や利用者向けの制御・操作方法だと思います。
ユーザーのID・パスワードで直接叩く
AIにパスワードを渡すことになるので、SSHのID・パスワードと同じ問題があります。
APIであれば、APIトークンを使った方がセキュリティ面や運用面でメリットが大きいので、あえてこれを選ぶ必要はないと思います。
APIトークンを発行して叩く
ガードレールの観点では、以下ができるのが大きいです。
- 権限の分離（
Privilege Separation）: 新しく作るトークンのデフォルト。トークンの権限は、ユーザーの権限とトークンの権限が重なる部分だけ - 期限（
Expire）: 期限を過ぎると使えなくなる - 失効: トークンが漏れても、ユーザーを止めずにトークンだけ消せる
- シークレットの作り直し: PVE9.2から、トークンのシークレットを作り直せる（
--regenerate）
MCPを経由して叩く
MCPについては、GitHubでProxmox向けのMCPサーバーがいくつか公開されています。
例えば以下です。
個人のプロジェクトを使うのが抵抗がある（セキュリティとか、リセラーとしてユーザーに提案できるかとか）ので、MCPが必要になったらClaude CodeやCodexを使って自分で作る気がします。
そもそも、MCPを経由してAPIを叩く必要がある場面はホスト管理の観点では思いつきませんでした。
PVEの権限がいけてないのでMCPサーバ側で実装するとか、環境制約がある場合などでしょうか？
と言っていたらコメントもらえました。ありがとうございます！
その他
Ansibleなどの構成管理ツールを使う
Ansibleは、ホスト単体というよりは、複数のホスト・VM・その上のゲストOS・アプリケーションを構築する上で便利だと思います。
再現性や冪等性の観点もそうですし、AIのトークン消費（利用料）というコストの観点でも、Ansibleのような構成管理ツールのほうが有利だと思います。
ただし、私も実際にそこを「Ansible vs AI」みたいな形で評価したわけではないのは補足しておきます。
もしかしたら、ちゃんとAI側にスキルやハーネスを渡しておけば、Ansibleと同等以上のことができるかもしれません。
また、AnsibleのplaybookなどをAIに書かせるというのも、合わせ技として有効だと思います。
ブラウザ拡張を使ってGUIを操作する
それ以外の操作方法として、ClaudeやCodexのブラウザ拡張を使って、ブラウザ経由で使うというのもあります。
この方式のメリットは以下だと思います：
- 人がGUIにログインしたセッションを使うので、TOTPなどの2要素認証を設定したままでも使える
- GUI操作ができるので、スクリーンショットを撮ったりすることができる
- 環境の都合でその他の認証があったり、直接SSHやAPIを叩けない場合に使える
ただし、GUIでもrootでログインしていれば、シェルを操作できますので注意してください。
採用した方法
もともと今回使っている環境がクローズドな環境なので、rootに対してSSH接続をしています。
もちろん秘密鍵を使っての接続になります。
また、接続元IPは念のため絞っています。
AIのハーネスとしては、まず一番初めに許可した操作以外を行わないようにハーネスをかけました。
実際に運用していく中で、常に許可する操作と都度承認を求める操作を指定して、それ以外は行わないように指定しています。
ゲストOS上に色々作りたかったので、Ansibleでできることは全部Ansibleでやること、VMテンプレートを使ってクローンしたり、バックアップ・スナップショットを使って特定断面に戻せるような指示もしたりもしてます。
PVE以外の4兄弟もスケジューリングして自動アップデート&自動テストとかはやってます。
終わりに
技術の発展により、感謝の正拳突き Proxmox のメンテナンス時間が大幅に減りました。おかげで祈る時間別の評価をする時間が増えて嬉しいです。
Zabbix 8 RC1 + PVE の OpenTelemetry の評価もしたので、次回書こうと思います。