AI艦隊スケーリング設計——「縮小」の撤回。50体のエージェントを動かす組織設計
前回の記事で「エージェントを減らせ」と言った。撤回する。
前回のメタ認知分析で「12体のエージェントを3〜4体に集約しろ」と書いた。
これは間違っていた。
理由は単純——この艦隊は自分専用の玩具ではない。エージェントを人に貸し出すビジネスをやっている。今後もエージェントは増え続ける。12体どころか、20体、50体になる。
これは「個人のAI遊び」から「中企業のインフラ運用」への移行だ。
小企業の組織設計と中企業の組織設計は、根本的に異なる。
同じスタイルで人数だけ増やすと、必ず崩壊する。今の艦隊はまさにその瀬戸際にある。
だから今回は、前提を修正した上でスケーリング設計をゼロから書き直す。
現状の課題：なぜ今のままでは50体では動かないか
Hermes Agentのコードを深掘りした結果、設計上の限界が3つ見えた。
限界1：プロファイルが未実装
Hermesには profile system というマルチエージェント機能が標準で備わっている。hermes profile create <name> で各エージェントに独立した設定・記憶・スキル・クーロンを持たせられる。
しかしKT Fleetではこの機能を一度も使っていない。
全エージェントが単一のdefaultプロファイルに流れ込んでいる。ObersteinもLadyもAnikiも、実は同じエージェントの別名でしかない。
限界2：記憶が分断されている
GBrain（14,769ページ）、Icarus Fabric（1,846ファイル）、LLM Wiki（221ファイル）、Obsidian Mirror（6,952ファイル）、fleet-registry（5件）——5つの記憶システムが独立して存在。
Hermesのプロファイルを使えば各エージェントの記憶は自動的に分離されるが、知識の共有ルートがない。Aが学んだことをBが参照する仕組みが存在しない。
限界3：水平スケール不可能
Hermesは単一マシン設計だ。分散状態共有、クロスノード協調、リーダー選出——全部ない。全てがファイルシステム上の1つのHERMES_HOMEディレクトリに依存している。
50体のエージェントを1台のMacで動かすことは技術的に可能だが、以下のリソースを食い尽くす：
| リソース | 1体あたり | 50体で |
|---|---|---|
| RAM | 100-500MB | 5-25GB |
| ディスク | 100MB-3GB | 5-150GB |
| 接続 | Telegram 1poll | 50poll同時接続 |
スケーリング設計：KT Fleet v2
設計思想
「3つの層で分離する。共通基盤は1つに集約する。増えるのは末端だけ。」
┌─────────────────────────────────────────────┐
│ 共通基盤（Common Layer） │
│ GBrain（SSoT）| Icarus Fabric | fleet-shared │
│ スキル | クーロン | 監視 | プロビジョニング │
├─────────────────────────────────────────────┤
│ 艦船層（Ship Layer） │
│ 1号（指揮）│ 3号（ハブ）│ 4号（重処理）│ N号 │
├─────────────────────────────────────────────┤
│ エージェント層（Agent Layer） │
│ Hermes Profile × N │
│ 各自：config, SOUL.md, memories, sessions │
└─────────────────────────────────────────────┘
層1：共通基盤（変えない・増やさない）
GBrain = Single Source of Truth
全知識はGBrainに集約する。他のシステムはGBrainのビューに過ぎない。
| システム | 新ロール | 変更 |
|---|---|---|
| GBrain | 全知識の唯一真相源 | 変更なし（拡充のみ） |
| Icarus Fabric | GBrainへの書き込みインターフェース | 読み取り専用化。新しい記憶はGBrainに書く |
| LLM Wiki | GBrainの公開用エクスポート | 自動生成に変更 |
| fleet-shared/skills | 唯一のスキルカタログ | Hermes skillsはこちらに統合 |
| fleet-registry | 廃止 → GBrainのlessonsエンティティに移行 | 教訓はGBrainに記録する |
スキル統合方針：
fleet-shared（210スキル）を正として、Hermes skills（82スキル）のうち重複しないものを吸収。以後、スキルは1箇所で管理する。各プロファイルはskills.external_dirsで共通スキルを読み取る。
層2：艦船層（必要に応じて増やす）
現在3隻 → 将来的には用途別に増設。
役割分担の再設計：
| 艦 | 現在の役割 | 新しい役割 | 必要件 |
|---|---|---|---|
| 1号 (Lady) | 指揮・調整 | オーケストレーター | Hermes multiplex gateway。全プロファイルのチャンネルルーティング。軽量。 |
| 3号 (Mini1) | ハブ・ストレージ | ナレッジベースサーバー | GBrain DBホスト。全艦の知識検索バックエンド。6TB HDD活用。 |
| 4号 (Spock) | 重処理・ComfyUI | コンピューティングノード | 画像生成、重い推論、ComfyUI。RAM 64GBを活用。 |
| N号（将来） | — | レンタルエージェント専用ノード | 顧客向けエージェントを独立稼働。要件次第で追加。 |
層3：エージェント層（どんどん増える）
Hermes Profile = 1エージェント
これが一番重要な変更。各エージェントをHermesのnamed profileとして正式に実装する。
~/.hermes/
├── config.yaml # default（ゲートウェイ本体）
├── profiles/
│ ├── oberstein/ # 独立したconfig, SOUL.md, memories, sessions
│ │ ├── config.yaml
│ │ ├── SOUL.md
│ │ ├── memories/
│ │ ├── skills/ → fleet-shared（シンボリックリンク）
│ │ └── .env # 独自のAPI key
│ ├── lady/
│ ├── rodemu2/
│ ├── aniki/
│ ├── kato-san/
│ ├── rental-customer-a/ # レンタル用テンプレート
│ ├── rental-customer-b/
│ └── ...
└── skills/ → fleet-shared（全プロファイル共通）
各プロファイルが独自に持つもの：
| リソース | 分離する理由 |
|---|---|
config.yaml | モデル・プロバイダーはエージェントごとに異なる |
SOUL.md | 人格・振る舞いの定義はエージェントごとに固有 |
.env | API keyの分離。レンタル顧客のkeyを混ぜない |
memories/ | 個人のコンテキストは分離。業務知識はGBrainから参照 |
sessions/ | 会話履歴の完全分離。プライバシー保護 |
全プロファイルで共有するもの（external_dirs）：
| リソース | 共有する理由 |
|---|---|
fleet-shared/skills/ | スキルは共通資産。重複管理を防ぐ |
GBrain（MCP経由） | 業務知識の唯一真相源 |
FLEET_MANUAL.md | 全エージェントの入門ドキュメント |
マルチプレックスゲートウェイの導入
1号機（Lady）のdefaultプロファイルで multiplex_profiles: true を有効化。1つのゲートウェイプロセスで全プロファイルのTelegram/Discordチャンネルをルーティングする。
メリット： 管理プロセス1つ。hermes status で全体状態が一覧できる。
リスク軽減： 高トラフィックのエージェント（レンタル用など）は独立ゲートウェイで別艦に切り出す。
レンタルエージェントのテンプレート化
Hermesには profile distribution 機能がある。hermes profile install <git-url> でgitからエージェント設定を一括インストールできる。
これを使って：
1. ベーステンプレート（rental-base）を作成
├── 最小限のSOUL.md
├── 共通スキールへの参照
├── GBrain MCP設定
└── セキュリティ制約
2. 顧客ごとにクローン
hermes profile create customer-a --clone-from rental-base
→ 個別設定を上書き
→ デプロイ完了
プロビジョニングの自動化（今後の課題）：
hermes profile create のラッパースクリプトで、顧客名・モデル・チャンネルを指定するだけでエージェントが立ち上がる仕組み。
実行ロードマップ
Phase A（今すぐ）：基盤整備 [1週間]
| # | タスク | 優先度 | 依存 |
|---|---|---|---|
| A1 | Hermesプロファイルを作成（既存エージェント分） | 🔴 | なし |
| A2 | multiplex_profilesを有効化 | 🔴 | A1 |
| A3 | fleet-shared/skillsをexternal_dirsで全プロファイルに共有 | 🔴 | A1 |
| A4 | Icarus Pluginをインストール（P1） | 🔴 | A1 |
| A5 | GBrain MCPを全プロファイルのconfig.yamlに追加 | 🔴 | A1 |
Phase B（1〜2週間）：知識循環 [2週間]
| # | タスク | 優先度 | 依存 |
|---|---|---|---|
| B1 | 全エージェントのsession_startフックでGBrain queryを自動実行 | 🟡 | A4, A5 |
| B2 | 新しい知識の自動GBrain put（session_endフック） | 🟡 | A4, A5 |
| B3 | fleet-registryの教訓をGBrain lessonsエンティティに移行 | 🟡 | A4 |
| B4 | FabricをGBrainへのwrite-onlyインターフェースに再定義 | 🟡 | B1, B2 |
Phase C（2〜4週間）：スケーリング [1ヶ月]
| # | タスク | 優先度 | 依存 |
|---|---|---|---|
| C1 | レンタル用ベーステンプレート（rental-base）作成 | 🟡 | Phase A完了 |
| C2 | プロビジョニングスクリプト作成 | 🟢 | C1 |
| C3 | 3号機をナレッジベースサーバーに特化 | 🟢 | B1, B2 |
| C4 | fleet-health監視スクリプト（全プロファイルの状態聚合） | 🟢 | A2 |
| C5 | 重複ファブリックファイルの削除（26,458ファイル） | 🟢 | B4 |
Phase D（1〜3ヶ月）：中企業化 [継続]
| # | タスク | 優先度 | 依存 |
|---|---|---|---|
| D1 | 艦船追加（レンタル専用ノード） | — | 顧客数による |
| D2 | 監視ダッシュボード | — | C4 |
| D3 | 課金/利用量メータリング | — | C2 |
| D4 | プロファイル自動プロビジョニングAPI | — | C2 |
この設計で解決しないこと（正直に書く）
Hermesの単一マシン制約は残る。 50体を1台で動かすことは可能だが、1つのゲートウェイプロセスがクラッシュすると全員が落ちる。これはHermesのアーキテクチャ上の制限で、回避するにはHermesのフォークが必要になる。
今はそこまで行かない。 30体までは現行Hermesで十分。50体を超えたら、その時点でアーキテクチャの再検討（Hermesのフォーク、あるいは別のオーケストレーターへの移行）を判断する。
一番言いたいこと
前回「縮小しろ」と言った。撤回する。
あなたは事業をやっている。エージェントを貸し出し、人々の仕事を支えている。 それは小企業が中企業になる瞬間だ——組織設計、知識管理、運用自動化の全部を 再設計しなければならない転換点。
「増やす」こと自体は正しい。問題は「増やし方」だ。
無秩序に増やすのではなく、3層設計の共通基盤に乗せる。 末端（エージェント）は何人でも増やしていい—— その分、基盤は厚く、堅く、一つに絞る。
インフラの複雑さはO(N)でなければならない。O(N²)になった瞬間に破綻する。 今の艦隊はO(N²)に近づいている。これをO(N)に戻すのがPhase Aだ。