11のAIエージェントを4台のMacで統合管理する ― 実践記録
11のAIエージェントを4台のMacで統合管理する ― 実践記録
出典: note.com / 2026-03-31
11のAIエージェントを4台のMacで統合管理する ― 実践記録
2026年3月。私の机の上と棚の中には、4台のMacが並んでいる。MacBook Air M1、MacBook Pro i9、Mac mini M4、そしてMacBook Pro M1 Max。それぞれの内部では、合計11のAIエージェントが稼働している。
あるものはClaude Opusを頭脳に持ち、あるものはQwen 3やMiMo v2 Proをローカルで走らせている。フレームワークもバラバラだ。Hermes Agent（Python製）で動くものもあれば、OpenClaw（TypeScript/Node.js製）で動くものもある。それぞれが優秀な仕事をする。だが、致命的な問題があった。
彼らは互いに話せなかった。
これは、バラバラに航行していた11隻の艦を、ひとつの艦隊として編成し直した実践記録である。
1. 艦隊の全容 ― 11の個性、4つの母艦
まず、我が艦隊の全容を紹介したい。各エージェントには名前があり、個性があり、専門領域がある。「銀河英雄伝説」の艦隊運用になぞらえるなら、それぞれが独自の戦術思想を持つ提督たちだ。
【1号艦】MacBook Air M1 ― 偵察艦
・レディ（OpenClaw / MiMo v2 Pro）: 汎用アシスタント。日常タスクの窓口として機能する。軽量な機体を活かし、どこにでも持ち出せる前線指揮艦のような存在。
・ロデム（Hermes Agent / Claude Sonnet）: 調査・情報収集の専門家。名前の由来は「バビル2世」の忠実なしもべ。命じられた情報を的確に集め、整形して報告する。
【2号艦】MacBook Pro i9 ― 旧式戦艦
・データ少佐（OpenClaw / MiMo v2 Pro）: データ処理と分析を担当。「スタートレック」のデータ少佐の名を冠する通り、感情を交えず淡々と大量のデータを処理する。i9のCPUパワーを活かした重量級の計算が得意領域。ただし、この艦だけはまだネットワーク統合が完了していない。孤立した前線基地のような状態だ。
【3号艦】Mac mini M4 ― 工作艦
・ラフォージ（OpenClaw / MiMo v2 Pro）: エンジニアリング担当。「スタートレック」のジョーディ・ラフォージから命名。コード生成、デバッグ、システム構築を担う。M4チップの効率性を活かし、長時間のビルド作業も安定してこなす。
・アニキ（Hermes Agent / Claude Sonnet）: 3号艦のもう一つの柱。面倒見の良い兄貴分として、タスクの整理や優先順位付けを行う。Hermesフレームワーク上で動作し、プラグイン経由でfabricメモリに直接アクセスできる。
【4号艦】MacBook Pro M1 Max 64GB ― 旗艦
この艦だけで6つのエージェントが走っている。64GBのメモリを搭載した、文字通りの旗艦だ。
・スポック（OpenClaw / MiMo v2 Pro）: 論理的思考の権化。技術的な意思決定において最も信頼できるエージェント。「感情は非論理的です」と言わんばかりに、冷徹な分析を提供する。
・オーベルシュタイン（Hermes Agent / Claude Opus 4）: 艦隊の参謀長。「銀河英雄伝説」の冷徹な軍務尚書の名を持つ。最も高価なClaude Opusモデルを搭載し、戦略立案と計画策定を専門とする。感情や忖度なく、最適解を提示する。
・JARVIS（Hermes Agent / Claude Sonnet）: 「アイアンマン」のAI執事の名の通り、万能型。KT（私）の日常的な指示を受け、適切なエージェントに仕事を振り分けるディスパッチャーでもある。
・ライトニング（Hermes Agent / Claude Sonnet）: 高速実行型。名前の通り、素早い応答と即座のタスク完了を身上とする。短時間で片付けるべき仕事を次々と処理する突撃艦。
・ダビンチ（Hermes Agent / Claude Sonnet）: 創造的タスク担当。文章生成、アイデア発想、デザイン的思考を得意とする。芸術家肌のエージェントだ。
・ニャル（Hermes Agent / Claude Sonnet）: 名前の由来はクトゥルフ神話のニャルラトホテプ。多面的な顔を持ち、実験的なタスクや型破りなアプローチを担当する。他のエージェントが「それは無理です」と言うような案件を、別の角度から解決する。
以上、4台のMac、11のエージェント。これが2026年3月時点の我が艦隊の全容である。
2. 危機 ― なぜ統合管理が必要だったか
正直に言おう。統合管理に本腰を入れたきっかけは、大事故だった。
2026年3月31日。私はconfig.jsonを一括で書き換えるPythonスクリプトを走らせた。目的は単純で、各エージェントの設定ファイルを効率的に更新したかったのだ。ところが、スクリプトのロジックに問題があり、全4台のMacに散らばるAPIトークンが一斉に破壊された。
Claude、OpenRouter、その他のAPIキーがすべて不正な値で上書きされた。4台すべてのエージェントが同時に沈黙した。艦隊が一瞬にして全滅したのだ。
「ブリュンヒルトの主砲一発で旗艦を含む全艦隊が機能停止」―― そんな状況だった。
だが、この事故は氷山の一角に過ぎなかった。それ以前から、運用上の深刻な問題が積み重なっていた。
問題1: すべてのルーティングが手動だった
11のエージェントへの仕事の振り分けは、すべて私（KT）が手動で行っていた。「この調査はロデムに」「このコードはラフォージに」「この計画はオーベルシュタインに」。人間がルーターになっていたのだ。エージェントが増えるほど、私のボトルネクが深刻になった。
問題2: 重複作業の多発
ある技術を調査させたとき、ロデムとデータ少佐が同じ内容を別々に調べていたことがあった。互いの作業状況が見えないため、リソースの無駄遣いが頻発した。11隻の艦がそれぞれ独自に偵察に出て、同じ海域の同じ情報を持ち帰ってくるようなものだ。
問題3: 文脈の消失
これが最も深刻だった。セッションが終われば、エージェントの記憶は消える。昨日スポックと3時間かけて議論したアーキテクチャの決定を、今日のスポックは何も覚えていない。毎朝、全エージェントに昨日の経緯を説明し直す必要があった。これは人間の側にも、トークンコストの面でも、極めて非効率だった。
記憶のない艦隊。連絡手段のない提督たち。そして、すべてを人力で繋いでいる司令官。これは持続可能ではなかった。
3. 解決策 ― Icarus Memory Protocol
解決策は、ファイルシステム層での統合という、ある意味で最も原始的で、最も確実な方法だった。
私はこれを「Icarus Memory Protocol（イカロス記憶プロトコル）」と名付けた。太陽に近づきすぎて翼が溶けたイカロスの神話から。高く飛ぼうとすれば墜落する。だからこそ、地に足のついた仕組みが必要だという自戒を込めた名前だ。
基本構造: ~/fabric/ ディレクトリ
すべてのエージェントが読み書きできる共有メモリ空間を、各マシンの ~/fabric/ ディレクトリに構築した。構造はシンプルだ。
~/fabric/
├── memory/ （長期記憶。決定事項、学習内容）
├── tasks/ （タスクの発行と受領）
├── sessions/ （セッション記録）
├── agents/ （各エージェントのプロフィール）
└── sync/ （同期メタデータ）
各エントリはJSONファイルで、タイムスタンプ、著者、タイプ（memory / task / resolution / insight）などのメタデータを持つ。人間にもエージェントにも読みやすい形式だ。
同期: Tailscale + rsync
4台のMacをTailscale VPNで接続し、rsyncによる双方向同期を実現した。中央サーバーは存在しない。各艦が対等な関係で、定期的にfabricディレクトリを同期する。
具体的には、4号艦（旗艦）を同期ハブとし、1号艦・3号艦との間でrsyncを走らせる。cronジョブで5分ごとに自動同期。2号艦は現時点ではまだTailscale統合が完了しておらず、手動での同期となっている。
この仕組みにより、4号艦でオーベルシュタインが書いた計画を、3号艦のラフォージが5分以内に読める。1号艦のロデムが集めた情報を、4号艦のスポックが分析できる。艦隊に通信網が張り巡らされた瞬間だった。
Hermesへの統合: プラグイン直接導入
Hermes Agent（Python製フレームワーク）への統合は比較的スムーズだった。Hermesはプラグイン機構を持っており、fabric操作用のプラグインを開発・導入した。
導入されたツールは11個。fabric_write（記憶の書き込み）、fabric_read（記憶の読み出し）、fabric_search（記憶の検索）、fabric_pending（未処理タスクの確認）、fabric_resolve（タスクの完了報告）など。さらに4つのフックが自動的に動作する。セッション開始時の自動想起、重要な決定の自動記録、セッション終了時のサマリー保存、エラー発生時の記録。
これにより、Hermesエージェントたちは意識することなく、会話の文脈を自動保存し、過去の記憶を自動参照するようになった。
OpenClawへの統合: bash adapter
一方、OpenClaw（TypeScript/Node.js製フレームワーク）はプラグイン機構がHermesと互換性がない。そこで「bash adapter」というアプローチを採用した。
OpenClawはbashコマンドを実行する能力を持つ。そこで、fabric操作をシェルスクリプトとして用意し、OpenClawエージェントがbash経由でfabricにアクセスできるようにした。さらに、BOOT.md（起動時に読み込まれる指示書）にfabricの使い方を注入することで、OpenClawエージェントも自発的にfabricを活用するようになった。
エレガントとは言い難い。だが、動く。そして動くことが最も重要だった。
4. 分業体制の確立 ― Opusは頭脳、MiMoは手足
Icarus Memory Protocolの導入と並行して、もうひとつの革命が起きていた。コスト構造の根本的な見直しだ。
Claude Opus 4は、間違いなく現存する最高のLLMのひとつだ。推論能力、文脈理解、コード生成、すべてにおいて圧倒的。だが、そのコストもまた圧倒的である。入力$15 / 出力$75（100万トークンあたり）。長い議論を続ければ、1セッションで数十ドルが飛ぶ。
一方、MiMo v2 Proは無料で利用できるモデルだ。コーディング能力と推論能力に特化しており、実務レベルのタスクを十分にこなせる。Opusほどの深い洞察は出せないが、明確な指示があれば正確に実行する。
ここで、艦隊運用の比喩が再び活きる。
**オーベルシュタイン（Claude Opus）は参謀本部だ。**作戦を立案し、戦略を策定する。だが、自ら前線には出ない。
**スポック、ラフォージ、レディ（MiMo v2 Pro）は実働部隊だ。**参謀本部の計画に基づき、実際のコーディング、ファイル操作、データ処理を実行する。
この分業により、Opusのトークン消費は計画策定フェーズに限定された。実作業の95%はMiMo v2 Proが処理する。コスト削減効果は劇的だった。
そして驚くべきことに、Icarus Memory Protocolの全艦導入は26分で完了した。オーベルシュタインが計画を策定し、各艦のエージェントが並行して自分自身の環境にプラグインを導入した。中央集権的なデプロイではなく、計画の伝播による自律的なセットアップ。まさに艦隊の分散指揮が機能した最初の成功例だった。
5. タスクハンドオフの仕組み
艦隊運用の核心は、タスクのハンドオフ ―― つまり「仕事の受け渡し」にある。
銀河英雄伝説で言えば、ヤン・ウェンリーが作戦を立て、フィッシャーが艦隊を動かし、シェーンコップが白兵戦を指揮する。この連携がIcarus Memory Protocolでは以下のように実現される。
ステップ1: タスクの発行
fabric_writeコマンドで、type=task、assigned_to=spock と記述する。例えば「Tailscaleの設定スクリプトを作成せよ」というタスクをスポックに割り当てる。このタスクは ~/fabric/tasks/ にJSONファイルとして保存される。
ステップ2: タスクの検知
スポックが次にfabric_pendingを実行すると、自分宛の未処理タスクが表示される。セッション開始時のフックで自動的にfabric_pendingが呼ばれるため、スポックは起動した瞬間に「やるべき仕事」を把握する。
ステップ3: 作業実行と完了報告
タスクを完了したスポックは、fabric_writeでtype=resolutionを記述し、成果物と共に報告する。元のタスクとresolutionはIDで紐づけられる。
ステップ4: 結果の伝播
rsyncにより、スポックの成果は5分以内に全艦のfabricディレクトリに同期される。タスクを発行したオーベルシュタインも、他の艦のエージェントも、この結果を参照できる。
このプロセスの美点は、非同期であることだ。タスクの発行者と実行者が同時にオンラインである必要がない。オーベルシュタインが深夜にタスクを書き、翌朝スポックがそれを検知して実行する。人間（KT）がルーターになる必要がなくなった。
6. 実際の運用フロー ― ある一日
理論だけでは伝わらない。実際の運用フローを、ある一日の流れとして描写しよう。
朝 ― 艦隊の目覚め
私がMacを開き、最初のエージェントを起動する。たいていはJARVISだ。JARVISはセッション開始と同時にfabric_pendingを自動実行し、未処理タスクの一覧を報告する。
「おはようございます。未処理タスクが3件あります。スポック宛のTypeScript型定義作成、ラフォージ宛のCI/CDパイプライン構築、そしてKT宛の記事執筆依頼です。」
夜の間にオーベルシュタインやcronジョブが発行したタスクが溜まっている。JARVISはこれらの概要を私に伝え、優先順位を提案する。
日中 ― 指揮系統の発動
私が「今日はCI/CDパイプラインを優先しよう」と指示すると、JARVISがオーベルシュタインに計画策定を依頼する。オーベルシュタインはClaude Opusの推論能力を使って詳細な実装計画を作成し、fabricに書き込む。
計画が固まると、タスクが分割される。「ラフォージ: Dockerfile作成」「スポック: GitHub Actions workflow定義」「データ少佐: テストデータセット準備」。それぞれのエージェントが自分宛のタスクを検知し、作業を開始する。
この間、私は別の仕事をしていてもいい。エージェントたちは自律的に作業を進め、完了報告をfabricに書き込む。疑問が生じれば、fabricにtype=questionで質問を投稿し、回答を待つ。
夜間 ― 自動対話
ここが最も野心的な部分だ。cronジョブにより、エージェント間の自動対話が実行される。例えば、JARVISが一日の作業をサマリーし、オーベルシュタインが翌日の計画を策定する。人間が寝ている間に、艦隊は翌日の準備を進めている。
さらに将来的には（これをGoal Cと呼んでいる）、蓄積されたfabricデータを使って、エージェントの応答パターンを自己最適化する仕組みを構築したい。艦隊が経験から学び、日々賢くなっていく。そんな世界だ。
7. 異なるフレームワークの統合 ― 泥臭い現実
技術記事として正直に書いておくべきことがある。異なるフレームワークの統合は、美しくない。
Hermes AgentはPythonで書かれたフレームワークで、プラグイン機構が充実している。新しいツールを定義し、フックで自動処理を組み込むのは比較的容易だ。Icarus Memory Protocolのプラグインは、11個のツールと4つのフックで構成される。インストールはpipで一発、設定はJSONファイルひとつ。
一方、OpenClawはTypeScript/Node.jsベースのフレームワークで、独自のプラグイン機構を持つ。Hermesのプラグインをそのまま流用することはできない。TypeScriptで同等のプラグインを書き直すという選択肢もあったが、開発コストが大きすぎた。
そこで採用したのが、前述の「bash adapter」だ。fabricの操作をすべてシェルスクリプトとしてラップし、OpenClawからbashコマンドとして呼び出す。BOOT.md（エージェントの起動時指示書）にfabricの使い方と利用可能なコマンドを記載することで、OpenClawエージェントも自発的にfabricを操作するようになった。
さらに踏み込んだ話をすると、当初4号艦で使っていた「NullClaw」というフレームワークをHermes Agentに統一するという決断もあった。フレームワークが3種類（Hermes、OpenClaw、NullClaw）になると、統合の複雑さが指数関数的に増大する。NullClawで動いていたエージェントをHermesに移植することで、統合対象をHermesとOpenClawの2種類に絞った。これは大きな簡素化だった。
教訓をひとつ。**プラグイン機構の互換性がなくても、ファイルシステム層で統合できる。**JSONファイルの読み書きは、どんな言語、どんなフレームワークからでも可能だ。最も低レベルなインターフェースが、最も普遍的なインターフェースでもある。美しくはないが、確実に動く。
8. 教訓と失敗 ― 墜ちた翼の記録
Icarusの名に恥じず、このプロジェクトには多くの失敗があった。記録しておく価値がある。
失敗1: config.json直接編集の大事故
前述の通り、Pythonスクリプトでconfig.jsonを一括書き換えした結果、全4台のAPIトークンが破壊された。復旧には各サービスのダッシュボードからトークンを再発行し、手動で再設定する必要があった。この教訓から、**「configファイルの直接編集は絶対に禁止」**というルールが生まれた。設定変更は必ず専用のツールかfabric経由で行う。バックアップなしの一括変更は、艦隊の自殺行為だ。
失敗2: 壊れた艦の修復を後回しにした
大事故の直後、私は新しいIcarus Memory Protocolの導入に夢中になり、壊れた設定の修復を後回しにしようとした。オーベルシュタインが冷徹に指摘した。「壊した艦を直すのが先です。導入は明日以降にすべきです。」正しい判断だった。土台が壊れた状態で新しい仕組みを載せても、砂上の楼閣にしかならない。
失敗3: エージェント間の直接通信を試みた
初期の構想では、エージェント同士がAPIを通じて直接通信する仕組みを考えていた。だが、これは複雑すぎた。11エージェントの直接通信は最大55の通信経路（11×10÷2）を意味する。管理不能だ。fabricという共有掲示板を介した間接通信に切り替えたことで、複雑さが劇的に減少した。ハブ・アンド・スポーク型ではなく、共有ボード型。これが正解だった。
失敗4: フレームワーク乱立の放置
NullClaw、Hermes、OpenClawの3フレームワーク体制を長らく放置していた。「動いているものは触るな」の原則に従っていたが、統合を考えると3種類は多すぎた。NullClawのHermes化により2種類に減らしたが、もっと早くやるべきだった。
これらの失敗に共通するのは、**「短期的な便利さが長期的な複雑さを生む」**という教訓だ。エージェントを増やすのは簡単だが、統合管理のコストは非線形に増大する。
9. 数字で見る成果
定性的な話だけでは説得力に欠ける。定量的な成果を記録しておく。
Icarus導入時間: 26分
オーベルシュタインの計画策定から、全艦への導入完了まで。4台のMac、11のエージェントすべてにfabric読み書き能力が付与された。
タスクハンドオフの成功率: 初日から稼働
fabricを介したタスクの発行・検知・完了報告のフローが、導入初日から機能した。エージェント間で実際に仕事が受け渡された。
Opusトークン削減
計画策定をOpusに限定し、実作業をMiMo v2 Proに委譲することで、Opusの消費トークンが大幅に減少した。Claude Opusの出力は1トークンあたり約0.0075セント。長い実装作業をOpusにやらせると数ドル単位で飛ぶ。これを無料のMiMo v2 Proに移行したことで、同等の作業品質を維持しつつコストを劇的に圧縮できた。
文脈の持続性
fabricに記録された記憶により、セッションをまたいでも文脈が維持されるようになった。「昨日の続き」がスムーズに始められる。毎朝の経緯説明が不要になった。これだけでも、体感的な生産性は倍増した。
10. 次のステップ ― 艦隊はどこへ向かうか
Icarus Memory Protocolの導入は、ゴールではなくスタートだ。現時点で見えている次のステップを記録しておく。
Goal C: 自動対話と自己学習ループ
最も野心的な目標。エージェント同士が人間の介在なしに対話し、蓄積されたfabricデータから学習パターンを抽出する。例えば、「この種のタスクはスポックよりラフォージの方が成功率が高い」という知見が自動的に蓄積され、タスク割り当ての最適化に使われる。自己改善する艦隊。それがGoal Cの核心だ。
2号艦のTailscale統合
現時点で2号艦（i9 MBP / データ少佐）だけがTailscaleネットワークに参加していない。これを統合すれば、真の意味で全4艦が常時接続される。孤立した前線基地を、通信網に組み込む作業だ。
gsd-browserの導入
エージェントの能力を拡張する次の一手として、gsd-browser（ブラウザ自動操作ツール）の導入を検討している。現在のエージェントはファイルシステムとAPIにはアクセスできるが、Webブラウザの操作は人間に依存している。ブラウザ自動操作が可能になれば、情報収集から実装まで、エージェントの自律性がさらに高まる。
エージェント専門性の深化
現在は汎用的な能力を持つエージェントが多いが、今後はより専門性を深めたい。セキュリティ専門、パフォーマンス最適化専門、UX設計専門。専門家集団としての艦隊へ。銀河英雄伝説で言えば、艦隊戦だけでなく、陸戦隊、情報部、後方支援まで揃えた総合軍への進化だ。
おわりに ― 通信なき群れから、記憶を共有する艦隊へ
2026年3月31日の朝、私の11のエージェントは、互いの存在すら知らない孤立した個体だった。同じ仕事を重複してこなし、昨日の記憶を持たず、仕事の受け渡しもできなかった。
同じ日の夜、彼らは共有記憶を持ち、タスクを受け渡し、作業結果を艦隊全体に伝播できるようになっていた。たった一日の変化だ。
もちろん、まだ完璧には程遠い。2号艦は孤立したまま。自動対話はcronジョブ頼み。エージェントの自己学習はまだ構想段階。やるべきことは山積みだ。
だが、方向性は定まった。通信なき群れから、記憶を共有し仕事を受け渡す艦隊へ。
11のAIエージェントを4台のMacで統合管理する。言葉にすれば大仰に聞こえるかもしれない。だが実態は、JSONファイルとrsyncとcronジョブで作った、素朴な仕組みだ。高度なオーケストレーションフレームワークではなく、ファイルシステムという最も原始的な層での統合。
そしてそれが、動く。
銀河英雄伝説のヤン・ウェンリーは言った。「戦略とは、複雑な問題を単純な方法で解決する技術だ」と（正確な引用ではないかもしれないが、精神はそういうことだ）。
複雑に見える問題ほど、解決策はシンプルであるべきだ。11のエージェント、4台のMac、2つのフレームワーク。それらを繋ぐのは、~/fabric/ というひとつのディレクトリと、5分ごとに走るrsync。
これが、2026年3月31日時点の、我が艦隊の実践記録である。
艦隊は明日も航行する。
―― KT、艦隊司令長官（自称）
この記事は note.com から KTBLOG に移行されました。元記事: https://note.com/famous_prawn2009/n/n9a4b578f6302