3 台の機械で AI エージェント群を運用、何が壊れたか

AI エージェントを「3 台の機械」で運用してわかった、手動オーケストレーションの限界と未来

AI コーディングエージェントを 3 台のマシンで毎日運用しているエンジニアが、単一マシンでの限界を超えようとして直面した 5 つの致命的な失敗と、そこから導き出された「Kubernetes 依存」への転換点を明かします。これは単なるツールの話ではなく、AI エージェントを自律的な組織へと進化させる際の、実務レベルでの深刻なインフラ課題を浮き彫りにする貴重な教訓です。

人間がボトルネックになる：なぜ「階層型組織」が必要だったのか

最初は私一人とターミナルだけでした。tmux のパネルをいくつか開き、複数のエージェントを同時に動かす。しかし、すぐに限界が訪れました。

「6 つのライブコンテキストを前に座ることに誰も警告してくれなかったことがあります。」

私はもはやエージェントを実行しているのではなく、「誰が何をするか決めるスケジューラー」と「すべての記憶を持つ人間」、そして「すべてをチェックするレビュアー」の 3 つの役割を一身に背負うことになっていました。一人の人間がこれらを同時に処理するのはスケーラブルではありません。私の注意力こそが最大のボトルネックでした。

そこで私は、数千人もの人を統率する役員たちがどうやって文脈を分離しているかに着想を得ました。「エージェントを平らな山ではなく、組織にしよう」と考えたのです。

システム内に実在するエンティティとしてCEO、VP（副社長）、マネージャー、ワーカーという階層構造を導入しました。これは単なる比喩ではありません。それぞれが独立したエージェントであり、独自のスコープと承認境界を持っています。

• コンテキストの分割: 文脈は下へ流れ、各層が必要な分だけを受け取ります。
• 結果の集約: 作業結果は上へ戻り、私は頂点（CEO）で最終的なものだけをレビューします。

これにより、「頭の中で 6 つの文脈を抱える」必要がなくなり、システム全体を俯瞰する 1 つの視点だけで済むようになりました。

モデルの外に「状態」を置く：コンテキストウィンドウの壁を越える方法

LLM の最大の制限は、コンテキストウィンドウ（記憶できる範囲）の狭さです。通常、モデルが限界に達すると、システムは古い情報を圧縮したり要約したりしてスペースを作ろうとします。

「圧縮せずリセットする。遅すぎるからです。」

私はこの「圧縮」アプローチを捨てました。代わりに、ファイルベースの状態管理を実装しました。

• ディスクへの永続化: 各エージェントにはディスク上の独立したワークスペースを用意し、ミッションや現在のステータス、ハンドオフフォルダ（作業成果物）をすべてファイルとして保存します。
• リセットと再開: コンテキストウィンドウがいっぱいになったら、モデル内部のコンテキストを完全にクリア（リセット）します。その代わり、ディスク上の履歴ファイルを読み込んで中断した場所から正確に再開します。

この仕組みにより、マシンがクラッシュしても作業は生き残ります。なぜなら、状態は「モデル内」だけでなく「ディスク上」にあるからです。

3 台の機械で運用して起きた「5 つの壊れ方」

単一マシンでは美しく機能していたこのシステムも、負荷を分散させるために 2 台の Linux ボックスと MacBook を加えて 3 台体制にした瞬間、崩壊しました。発生した 5 つの重大な障害は以下の通りです。

1. 権限の混同（オーケストレーションの失敗）

エージェントが下位のワーカーにタスクを委任するべきところを、自ら実行してしまいました。「袖まくりして自らタスクを実行してしまう」のは誤りです。CLI ハーネスで強制的にワーカーを呼び出す仕組みを作り、ディスパッチ（委任）を唯一の道としました。

1. 視覚的な崩壊（コンテキストの競合）

タスクをマネージャーに投げ続けると、彼らが単一のウィンドウ内でさらに多くのワーカーペインを起動し続け、画面が混雑してしまいました。tmux のキャプチャ機能さえも、プログラムで読み取る意味のある情報を抽出できなくなりました。

1. メモリ不足（リソース枯渇）

アクティビティモニターを見ると、クラウドコードと MCP プロセスに埋もれ、スワップ領域がほぼ満杯になりました。セッションが積み重なり、マシンが呼吸できない状態に陥りました。

1. 認証情報の衝突

「ワークスペース A には Credential A を」というクリーンな期待とは裏腹に、認証情報が交差し、誤ったワークスペースにバインドされました。解決策は、各ワークスペース用に完全に分離された環境を用意することでした。

1. マシンの電源断による作業消失

これが最も痛かった失敗です。MacBook はラップトップのため、電源が切れるかネットワークから切断される瞬間、進行中のすべてのジョブが死にました。ある時はワーカーを投入しすぎてマシン全体がダウンし、再起動した時には「飛行中」のすべてが消滅していました。

Git と SSH による跨マシン同期：手動オーケストレーションの限界

これらの失敗から学んだのは、「1 台のマシンでは不十分だ」という事実です。そこで負荷を分担する体制（MacBook は個人プロジェクト、Linux A は長時間実行タスク、Linux B は短寿命タスク）を整えました。

しかし、新しい問題が発生しました。「必要なコンテキストが別のマシンにある」場合、どうやって移動させるかです。

私はGit と SSHを組み合わせた手動の同期システムを構築しました。

• コンテキストファイルを Git にコミット・プッシュし、SSH で他マシンの tmux を操作して pull させます。
• エージェントはファイルを読み込み、中断した場所から再開します。

「退屈な仕組みですが、それが 2 台のマシンが静かに不一致を起こすのを防ぎます。」

また、各マシンに設置していたレビューゲートウェイを統合し、常時稼働する Linux ボックス上の「メインゲートウェイ」へ SSH でリクエストを送る形に変更。Mac のスリープ問題を回避し、Discord ボットを介してスマホからすべてのマシンのリモコンとして操作できる一元管理を実現しました。

結論：Kubernetes への移行と「宣言的オーケストレーション」の必要性

現在、私はまだ解決すべき課題（マシン間の一貫性、ローカルツールの抽象化、機密情報のハンドオフなど）を抱えています。しかし、ここから導き出された最大の教訓は明確です。

「エージェントは実行先ではなく、必要なものを宣言すべきだ。」

計算資源の割り当て、シークレット管理、ツールへのアクセスといったインフラ層を、私が手動で決める立場から脱却する必要があります。スケジューラーが配置し、マシンは背後に消える。

これはKubernetesがすでに完璧に回答している質問です。私はこれら既存の基盤の上に、レビューフローや文脈管理、タスクオーケストレーションという「上層レイヤー」を積み重ねる方向へ舵を切りました。

手動で構築したオーケストレーションの限界を超え、AI エージェントを真に自律的な組織へと進化させるためには、インフラの抽象化が不可欠なのです。