1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Proxmox×AIでホームラボを育てた話 (2) 手作業で「その場対応」に育てた最初の環境

1
Last updated at Posted at 2026-10-12

前回(1)「事の始まり」では、余っていたPCのスペックを見て「これは1用途はもったいない」と思い、Proxmox VEを導入することにした経緯を書きました。今回は、実際にサービスを立ち上げていった最初期の話です。結論から言うと、最初から設計図があったわけではなく、その場その場で「必要になったから作る」を繰り返していました。

まずは本命のImmichを手作業で構築

最初にやったのは、当初の目的だった写真管理サービス Immich 用のVMを作ることでした。Proxmox上に1台VMを立てて、その中にDockerでImmichのスタックを構築する、というオーソドックスな流れです。

この時期はまだ、構築作業を助けてくれる相棒はサーバーの外にいました。手元の別PCでClaude Desktopを開き、そこに相談しながら、Proxmoxの管理画面(UI)や物理コンソール、SSHでの手作業を進めていくスタイルです。「次は何をすればいいか」をClaude Desktopに聞いては、その手順をサーバー側で実行する、という往復作業でした。使い分けとしては、VM作成やコンソール経由での初期設定はUI、ネットワーク変更などUI/SSHが使えなくなるリスクがある操作は物理コンソール、それ以外の普段の作業はSSH、という感じです。

なお、Claude DesktopはあくまでPC上の会話アプリで、こちらが聞いたことに答えてはくれますが、ファイルを直接編集したりコマンドを実行したりはできません。一方この後出てくるClaude Codeは、許可した範囲でファイル操作やシェルコマンドの実行まで自分でこなせるツールです。この能力差が、後述する「サーバーの中に置いてしまう」という発想につながっていきます。

サーバーと手元PCの往復が、地味に面倒だった

この進め方は最初のうちはうまくいっていたのですが、作業が長引くにつれてある種のストレスが溜まっていきました。

この往復を、構築作業のたびにひたすら繰り返すことになります。1回1回は大した手間ではないのですが、積み重なると地味に煩わしく、「これ、いちいちコピペして往復する必要ある?」という疑問が徐々に大きくなっていきました。

発想の転換: サーバーの中に相談相手を置いてしまう

ここで出てきたのが、「サーバーの外から相談する」のではなく「サーバーの中に相談相手を置いて、直接操作してもらう」という発想です。手元PCとサーバーを往復するのではなく、Claude Codeをサーバー自身の中で動かし、そのVM自身の中でファイル操作やコマンド実行を任せてしまえばいいのでは、という考えに至りました。

これが、後にAIエージェント専用となるVM(VMID 200)が生まれたきっかけです。ただし、この時点で持たせた権限はあくまで「そのVM自身の中で作業する」範囲にとどまり、他のゲストやProxmox自体をAPI経由で操作する権限はまだありません(そのあたりは後の回で紹介するAnsible導入やCodex連携以降の話です)。当時は「AIに運用まで任せる」という壮大な狙いがあったわけではなく、単に「往復が面倒だから、サーバーの中に置いてしまおう」という実利的な動機でしたが、振り返るとこの一台がシリーズ後半(7回目)につながる最初の分岐点になっています。

監視用の環境やGiteaも、同じノリで追加

Immich用VMとClaude Code用VMを手作業で作った後も、しばらくは似たような調子が続きました。「メトリクスを見たくなったから監視用の環境を作る」「コードやMarkdownをちゃんとバージョン管理したくなったからGitサーバーを立てる」といった具合に、必要になったタイミングでそのつどLXCを手作業で追加していきました。

サービス 形態 追加のきっかけ
Prometheus + Grafana LXC メトリクスを見たくなった
Gitea LXC コード/Markdownを管理したくなった

このあたりから結果的に、Dockerでスタックをまるごと動かすような重めのサービスはVM、単一の役割で軽く済むサービスはLXC、という使い分けになっていきました。最初から基準を決めていたわけではなく、後から振り返るとそうなっていた、というのが実態です。

設計より「動くもの優先」だった時期

今振り返ると、この時期は明確な設計方針があったわけではなく、「とにかく動くものを作る」ことを優先していました。「このVMをもう一度同じ手順で作れと言われたら困るな」という再現性への不安を抱えながらの運用で、この「行き当たりばったりのしんどさ」が、後々Git管理やAnsibleによる自動化に向かっていく動機の一つになっていきます。

次回予告

次回は、この行き当たりばったりな構築をどう管理下に置いていったか、Git化とTailscale導入について書きます。
Git化とTailscale導入

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?