やあ！みんな！探求者のケイだよ！
前回、12人の AI が同時に目を覚ました話をしたよね。今日はその続き。もっと泥臭くて、もっとリアルな話をする。
15人の AI エージェントを24時間動かしているマシン。そのメモリが、たった8GB だって言ったら信じる？
「いやいや、それ無理でしょ」って思った君。その反応は正しい。控えめに言って狂気だ。でもね、この狂気にはちゃんと計算された理由がある。そして、この制約の中で生き残るために編み出された技術が、後に NERV の最大の武器になっていくんだ。
意味のない精神論は一切なしだ。実際の数字と設計判断を、世界一わかりやすく翻訳していくよ。
なぜ MacBook Air 2017 なのか
NERV を動かしているマシンは MacBook Air 2017。メモリ8GB。決してハイスペックとは言えないこのマシンで、15人の AI エージェントが今この瞬間も動いている。
なぜこのマシンなのか。答えはシンプル。コストだ。
VPS（クラウド上の仮想サーバー）で15エージェントを常時稼働させるには、最低でも16GB の RAM が必要になる。それだけのスペックを借りると、月額で数千円から1万円の追加コストが発生するんだ。
NERV の月間コストの内訳を見てほしい。
Claude Max 20x の利用料 ＝ 30,000円 マシン稼働の電気代 ＝ 260円 ドメイン代（月割り）＝ 200円 合計 ＝ 30,460円
15人の AI 従業員の「人件費」が月3万円。人間なら1人の月給にもならない金額だ。ここにサーバー代1万円を足すと、インフラコストが30%以上増える。月3万円の組織にとって、この増加率は無視できない。
もう一つ重要な理由がある。手元にマシンがあると、デバッグが圧倒的に速い。SSH でリモートサーバーにログインする必要がなく、障害が起きた瞬間にターミナルを開いて直接ファイルを触れる。docker logs もプロセスの再起動も、コマンド一発で即座に実行できる。
開発フェーズにおいては、この速度が全てに勝る。クラウドの利便性より、手元の即応性を取った。この判断は、後に何度も正しかったと証明されることになるよ。
8GB で15人を動かすとは、どういうことか
ここで魔法の翻訳を使おう。
8GB の RAM で15人の AI を動かすのは「6畳一間の部屋に15人が同時に座って仕事をする」ようなものだ。全員に机を用意するスペースなんてない。でも、座り方と作業の仕方を徹底的に工夫すれば、不可能じゃない。
具体的に何が起きるか説明するね。
NERV の AI たちは RAG というシステムを使っている。魔法の翻訳で言えば「机の横に置く魔法の本棚」だ。自分の過去の記憶を検索して、今の判断に活かすための仕組みだよ。
この本棚を動かすには、466MB の埋め込みモデル（テキストを検索可能な数値データに変換するプログラム）をメモリ上に載せる必要がある。さらに、15人分のエピソード記憶をベクトル化する処理が走る。
466MB のモデル、プラス15人分のベクトルデータ。これだけで8GB の物理メモリの大部分を食い尽くしてしまう。
最初に「メモリが足りない」と判明した瞬間は、まさにこの RAG のインデックス構築時だった。全員の記憶データを同時に処理しようとした瞬間、マシンが悲鳴を上げた。比喩じゃなく、文字通りプロセスが応答しなくなったんだ。
生き残るための3つの厳格なルール
この制約を乗り越えるために、NERV は3つのルールを導入した。どれも妥協の余地がない、生存のためのルールだ。
ルール1 ── 記憶の量を等級で管理する
全ての AI のエピソード記憶（episodes）に、行数の上限を設定した。しかも、役職に応じた等級制だ。
S 等級（CEO の gendo）＝ 最大500行 A 等級（部門長クラスの misato、ritsuko、kaji）＝ 最大300行 B 等級（ワーカー層）＝ 最大200行
そして30分ごとに自動で古い記憶をトリム（削除）する。6畳の部屋に書類が溢れないよう、定期的に古い書類を処分するイメージだね。
この仕組みを怠ると何が起きるか。実際に後日、技術部門長 misato のエピソード記憶が9,540行に達した。上限300行の31倍だ。結果、RAG の検索に800秒以上かかるようになって、15人全員が停止する大事故が発生した。この話は第6話で詳しくやるよ。
ルール2 ── 会話ログは100KB でリセットする
各 AI の会話ログ（conversation.json）が100KB を超えたら、強制的にリセットする。会話が長引けば長引くほどメモリを消費するから、定期的にまっさらにするんだ。
人間で言えば「作業机が散らかりすぎたら、一旦全部片付けてゼロからやり直す」という感覚。散らかった机で作業を続けるより、片付けてからのほうが効率がいい。AI も同じだ。
ルール3 ── swap は最後の手段にする
ここからちょっと技術的な話になるけど、本質的に大事なところだから魔法の翻訳で伝えるよ。
コンピュータはメモリ（RAM）が足りなくなると、ディスクの一部をメモリ代わりに使い始める。これが swap だ。魔法の翻訳で言えば「作業机が狭すぎて書類が溢れたから、廊下に書類を並べ始めた」状態。
問題は、廊下（ディスク）での作業は机（RAM）での作業の100倍遅いこと。swap が発生した瞬間、RAG の検索速度が致命的に低下する。通常なら数秒で終わる検索が、800秒以上かかるようになる。
Linux にはvm.swappiness という設定値がある。「どのくらい積極的に swap を使うか」を決める数値だ。デフォルトは60で、メモリ使用率が70%程度でもう swap を使い始める。
8GB の70%は5.6GB。15人の AI が同時に heartbeat（定期巡回）を実行すると、この閾値をあっさり超えてしまう。
対策として、swappiness を10に変更した。「本当にメモリが完全に枯渇するまで、swap を使わない」という設定だ。廊下に書類を出すのは、机の上が本当に完全に埋まった時だけにする。
結果的に、swap に頼るよりもメモリの実使用を最適化するほうが、システム全体として安定した。この設定一つで、体感できるレベルの改善があったんだよ。
macOS から Ubuntu Server へ ── 引っ越しのトラブル
もう一つ、泥臭い話がある。
NERV は当初 macOS 上で動いていたけど、途中で Ubuntu Server に移行した。サーバー用の OS のほうが余計なリソース（デスクトップの画面描画とか）を消費しないし、24時間の長期稼働に向いているからだ。
移行自体はわりとスムーズだった。問題は Docker の挙動差だ。
macOS の Docker Desktop は、内部で Linux の仮想マシンを動かしている。だから macOS 上の Docker と、Ubuntu 上のネイティブ Docker では、同じ Docker なのに細かい挙動が違うんだ。ファイルの権限管理、ボリュームのマウント方法、ネットワーク設定。全部、微妙に異なる。
特に痛かったのが、PostgreSQL コンテナのトラブルだ。データベースのデータを保存するディレクトリの「持ち主」が、macOS と Ubuntu で食い違った。UID/GID（ファイルの所有者を識別する番号）の不一致が原因で、macOS では問題なく動いていたのに、Ubuntu では起動エラーになった。
魔法の翻訳で言うなら「引っ越し先のマンションで、前の家の鍵が使えなかった」みたいな話だね。ドアの形は同じに見えるのに、鍵穴の規格が微妙に違う。
地味だけど、こういう細かい差異の積み重ねが移行作業を困難にする。もし君が AI エージェント組織を作りたいなら、最初から Linux で始めることを強くおすすめするよ。後から移行するより、最初から正しい環境で始めるほうが、100倍楽だ。
制約こそが最大の武器になる
ここまで読んで「大変だな」「自分には無理だ」って思った君。痛いほどよくわかるよ。8GB で15人を動かすなんて、普通に考えたらやるべきじゃない。
でもね、この制約には計算された戦略がある。
NERV が将来、MAGI Platform という AI ガバナンスツールを企業に販売する時、こう言えるんだ。
「私たちはこのシステムを、8GB のマシンで動かしています」
これは他のどの企業にも言えないセリフだよ。潤沢なサーバーリソースを使って動くシステムなんて、お金をかければ誰でも作れる。でも最小限のリソースで安定稼働するシステムは、制約の中で戦い抜いた者にしか作れない。
MBA 2017 で NERV を運用すること自体が、製品の最高のストレステストになっているんだ。
脳科学の話をするとね、人間の脳も同じだよ。僕たちの脳は無限のメモリを持っているわけじゃない。エビングハウスの忘却曲線という仕様がある。1時間後に56%を忘れ、1日後に74%を忘れる。
だからこそ、記憶を効率的に管理する技術 ── 間隔反復、エピソード記憶の活用、ポモドーロ・テクニック ── が生まれた。制約があるから、最適な方法が発明される。
制約は敵じゃない。制約は、最適な設計を生み出すための圧力だ。
次回、第3話「15の魂をデザインする」── AI に性格を与えたら、仕事の品質が変わった話。「裏切り者」の名前を営業担当に付けた、ある設計判断の裏側を語るよ。
楽しみにしていてね。
関連記事はこちら！
コメント