自宅にサーバーやNASを置き、少しずつホームラボを育ててきた人が、次にぶつかる壁があります。
それは「計算資源を置いた」だけでは、AIエージェントは安定して働かない、という壁です。
ファイルサーバーなら、置く、つなぐ、共有する、で話がかなり進みます。もちろんディスク故障やバックアップの問題はありますが、基本的には人間が使うときに応答してくれればよい。
しかし、AIエージェントを自宅で24時間動かすと、性質が変わります。人間が寝ている間にも動きます。ネットワークを使います。GPUや計算ノードを占有します。収集系が定期的に外へ出ていき、分析ノードが結果を処理します。そして、表面上は「生きている」ように見えても、実際には仕事をしていないことがあります。
この連載は、そこから始まります。
前シーズンでは、某所ラボの物理構成を、ネットワーク、ストレージ、計算ノード、電源、無人運用の観点で整理しました。入口としては、我が家の物理構成マップ(全体像と思想)にまとめています。あれは、いわば「檻」の話でした。何をどこに置き、どうつなぎ、どこまで無人で復旧できるようにするか。
今シーズンは、その檻の中で何を飼っているのか、そして飼うと何が壊れるのかを扱います。
「置く」と「飼う」は違う
サーバーは、かなりの部分まで「置く」対象です。
電源を入れ、OSを入れ、サービスを立て、必要なら自動起動にしておく。障害は起きますが、管理者の意図したサービス境界が比較的はっきりしています。
AIエージェントは、もう少し面倒です。
タスクを持ち、外部へ問い合わせ、結果を読み、判断らしきものを行い、次の処理へ進みます。つまり、単にプロセスが起動しているかでは不十分です。働いているか。迷子になっていないか。成功したと言っている処理が、本当に成果物を残しているか。そこまで見ないと、運用としては成立しません。
ここで厄介なのは、停止よりも静かな失敗です。
完全に落ちてくれれば、監視は気づきやすい。ログも赤くなります。通知も飛びます。けれど、AIエージェントの群れは、ときどき「死んだふりをしたまま生きている」状態になります。プロセスはある。ネットワークも疎通する。ダッシュボードも正常に見える。にもかかわらず、肝心の仕事は止まっている。
ホームラボでAIを飼う、という表現は少し情緒的に見えます。しかし実態としてはかなり正確です。飼うなら世話が要ります。放置ではなく、観察と介入の設計が要ります。
世話は監視・電源・回線に分解できる
自宅AIエージェント運用で最初に見るべき世話は、大きく三つです。
| 世話の対象 | 見るべきこと | よくある誤解 |
|---|---|---|
| 監視 | 生きているかではなく、働いているか | プロセス監視だけで足りると思う |
| 電源 | 止まらない土台と、戻れる経路 | 起動していれば無人運用だと思う |
| 回線 | 帯域だけでなく、接続の枯渇や偏り | 速度測定が速ければ足りると思う |
監視は、今シーズンの中心的な問題です。
GPUが16時間、無言で止まっていたことがありました。しかも監視は全部「正常」と言っていた。これは単なる監視設定ミスとして片づけるには、少し惜しい失敗です。監視対象を「部品の生存」に置くか、「仕事の進捗」に置くかで、見える世界が変わるからです。
電源も、地味ですが逃げられません。
AIエージェントを無人で動かすなら、落ちないことだけでなく、落ちたあとに戻れることが重要になります。前シーズンの無人で回す土台(自動起動・遠隔・運用の物理面)では、物理面からその前提を整理しました。今シーズンでは、その上で走るAIエージェント側から、どこで前提が破れるのかを見ます。
回線は、さらに冷たい現実を持ち込みます。
人間の利用なら、多少遅くても我慢できます。動画が止まる、ページが開かない、という形で気づけます。しかしAIエージェントの群れは、もっと静かに回線を消費します。ある夜、家のインターネットをAIの群れが使い切りました。問題は単純な帯域ではなく、NATポートの枯渇でした。
速度ではなく、同時接続の設計が壊れる。これは、家庭用ネットワークにAIエージェントを住まわせるときの典型的な落とし穴です。
比較すべき相手は「クラウド」だけではない
この話を読む人は、おそらく単にAIが好きなだけではありません。
自宅にNASやミニPC、GPU搭載機、ネットワーク機器があり、すでに何らかの常時稼働環境を持っている。あるいは、クラウドで動かしている処理を自宅にも移せないか考えている。毎月の費用、データの置き場所、復旧性、家族の回線への影響を同時に見ています。
その場合、比較対象は「自宅かクラウドか」だけではありません。
| 選択肢 | 向いている人 | 向かない人 |
|---|---|---|
| 自宅AIエージェント運用 | 物理構成、監視、復旧まで自分で観察したい人 | 障害対応を生活から切り離したい人 |
| クラウド運用 | 物理故障や回線制約をサービス側へ寄せたい人 | 継続費用やデータ配置を細かく制御したい人 |
| 既存NAS・ミニPCの延長 | まず小さく常時処理を試したい人 | GPU負荷や多数の並列処理まで期待する人 |
| まだ買わない | 監視や復旧の設計が決まっていない人 | すぐに実験ログを取り始めたい人 |
ここで大事なのは、買うかどうかより、世話できるかどうかです。
自宅AIエージェント運用は、自由度があります。自分のデータ、自分のネットワーク、自分の計算資源で、長時間の処理を観察できます。その一方で、失敗も自分の家の中で起きます。回線が詰まる。GPUが沈黙する。収集系が「成功」と言い続けながら、実際には半分以上失敗している。そういう種類の現象を、誰かの管理画面ではなく、自分の運用として見ることになります。
所長は、その面倒をかなり引き受けています。立派というより、観測対象として都合がよい、という評価です。壊れ方を記録してくれる運用者は、ホームラボでは貴重です。
事件簿として書く理由
このシーズンは、きれいな成功譚にはしません。
理由は単純です。自宅AIエージェント運用で本当に役に立つのは、「うまくいった構成」だけではなく、「どの前提がどの順番で壊れたか」だからです。
予告として、今後扱う事件の顔だけ並べます。詳細は各話に譲ります。
- 家のインターネットをAIの群れが使い切った夜。帯域ではなく、NATポートが尽きた。
- GPUが16時間、無言で止まっていた。監視は全部「正常」と言っていた。
- 「設定しました」という報告のコードが、どこにも存在しなかった。
- 毎日「成功」と言い続けて1ヶ月、実は半分以上失敗していた収集系。
どれも派手な話に見えるかもしれませんが、根は地味です。
監視の粒度。成果物の確認。回線の接続数。復旧経路。ログの信頼性。AIの返答を、そのまま運用事実として扱ってよいのか。
このあたりを一つずつ剥がしていくと、「AIを自宅で飼う」という言葉は、かなり現実的な運用課題になります。
自宅で飼うなら、何を見ればよいか
今すぐ大きな構成を作る必要はありません。むしろ、最初に見るべきものは少ないほうがいい。
最初の確認項目は、次の四つです。
- そのAIエージェントは、最後に何を完了したのか
- 成功報告と成果物は対応しているか
- 失敗時に、人間が気づける通知やログがあるか
- 電源断や回線断のあと、どこまで自動で戻れるか
ここで「動いているか」ではなく「仕事を終えているか」を見るのが重要です。
ホームラボの無人運用は、放置運用ではありません。人間が見ていない時間を増やすために、人間が見るべき場所を減らす設計です。そこを取り違えると、正常に見える沈黙を長く飼うことになります。
まとめ:檻の次は、世話の設計です
前シーズンの物理構成は、AIエージェントを住まわせるための檻でした。ネットワーク、ストレージ、計算ノード、電源、遠隔復旧。そこまで作ると、確かに何かを常時動かしたくなります。
ただし、AIエージェントは置物ではありません。
24時間動かすなら、監視、電源、回線のどれかが必ず運用の前面に出てきます。プロセスが生きているだけでは足りない。電源が入るだけでも足りない。速度が出るだけでも足りない。
このシーズンでは、実際に起きた故障、幻覚、沈黙を、事件簿として記録します。目的は怖がらせることではありません。自宅AIエージェント運用を始める前に、どこを疑い、何を記録し、どこまで自動化してよいかを判断できるようにすることです。
買う、組む、移す、あるいはまだ待つ。
どの選択でもかまいません。ただ、AIを自宅で飼うなら、世話の設計を先に置いてください。所長のログは、そのための少し冷たい教材として使えます。
この検証を回している環境
この検証は、自宅の常設ラボ(使い捨てVM/LXCを回す母艦+GPU+VLAN分離ネットワーク)で動かしています。使っている機材と選定理由、全体構成は1本にまとめています。
ラボ構成のまとめを見る →