※この記事は AI（Microsoft Copilot）によって生成され、筆者が内容を確認・調整しています。
※この記事は前回の記事
https://qiita.com/genkyoryo110/items/3b66ed6f674c206115c3
の続編です。
この記事では、私が開発している 自律型マルチエージェント基盤「AIの町」 の
Version4 までの進化をまとめます。
Version4 は単なるアップデートではなく、
Version5（MCP 化）に向けた“基盤の再構築フェーズ” でした。
🎯 Version4 のゴール
Version4 の目的は明確です。
「作業AIの入出力を完全に統一し、MCP 化に耐えられるアーキテクチャへ進化させる」
そのために以下の 6 点を重点的に改善しました。
- 入出力仕様の完全統一（I/O Standardization）
- context_layer の正式導入
- manager-api の安定化（タスクID分離・順序保証）
- UI の責務分離（ChatPanel / WorkerResultPanel）
- Memory の整理（conversation_ai のみ stateful）
- Version5（MCP 化）に向けた準備完了
🧩 Version4 の全体像
Version4 のアーキテクチャは以下のように整理されました。
UI（ChatPanel / WorkerResultPanel）
↓
manager-api（LLM呼び出し／I/O統一）
↓
conversation_ai（LLM）
↓（LLMの返答を受け取るだけ）
manager-api（作業AIタスクを発行）
↓
WorkerLauncher（従来の start_worker）
↓
作業AI（I/O統一済み Worker）
Version4 のポイントは 「MCP 化はまだしない」 という点です。
ただし、MCP 化に必要な I/O の統一と責務分離はすべて完了しました。
🧱 1. 入出力仕様の完全統一（I/O Standardization）
Version4 最大の成果はこれです。
✔ 作業AIの出力形式を統一
{
"output": {
"result": "...", // 作業AIのメイン出力
"reply": "...", // conversation_ai 専用
},
"stdout": "...",
"stderr": "..."
}
✔ UI 側の受け取りも統一
- ChatPanel →
result.output.reply - WorkerResultPanel →
result.output.result
✔ replyHandled による二重表示防止
ChatPanel 側で：
- conversation_ai の返答は 1 回だけ表示
- 作業AIの返答は WorkerResultPanel へ分離
これにより UI の混乱が完全に解消されました。
🧱 2. context_layer の正式導入
Version4 の中核です。
context_layer = {
goal,
task_spec,
constraints,
world_model,
user_state,
conversation_summary,
available_workers,
ui_state,
memory_extract
}
✔ conversation_ai（stateful）
→ context_layer を使って会話の一貫性を維持
✔ 作業AI（stateless）
→ context_layer を使ってプロンプト生成を安定化
✔ manager-api が context_layer を一元生成
→ Worker 間の文脈ズレが消滅
🧱 3. manager-api の安定化
Version4 では manager-api を大幅に整理しました。
✔ 会話AIと作業AIのタスクIDを分離
{
"conversation_task_id": "...",
"worker_task_id": "...",
"worker_type": "code_ai"
}
✔ 会話AI → 作業AI の順序保証
非同期実行による逆転を防ぐため、
会話AI起動後に 0.4 秒の待機を追加。
✔ UI が正しくタスクを識別できるように
- ChatPanel → conversation_ai のみ
- WorkerResultPanel → 作業AIのみ
🧱 4. UI の責務分離（ChatPanel / WorkerResultPanel）
Version4 で UI は完全に整理されました。
✔ ChatPanel
- conversation_ai のみ扱う
- replyHandled で二重表示防止
- memory 更新もここで実行
✔ WorkerResultPanel
- 作業AIのみ扱う
- ResultCard で統一表示
- タスク完了をポーリングして自動表示
🧱 5. Memory の整理
Version4 では Memory の責務も明確化。
✔ conversation_ai のみ stateful
- USER.md
- MEMORY.md
- SKILL.md
- Hermes Memory（DB）
✔ 作業AIは stateless
→ MCP 化に最適な構造へ
🚀 Version5（MCP 化）への準備完了
Version4 の I/O 統一により、
Version5 の MCP 化に必要な前提条件がすべて揃いました。
Version5 で行うこと
- 作業AIを MCP ツール化
- WorkerLauncher を MCP サーバー化
- manager-api を MCP クライアント化
- mcp_tool.json（schema）を導入
- start_worker() を廃止し MCP 呼び出しへ移行
Version5 のアーキテクチャ（予定）
UI
↓
manager-api（MCPクライアント）
↓
WorkerLauncher（MCPサーバー）
↓
作業AI（MCPツール）
Version4 は この Version5 のための基盤整備フェーズでした。
📌 Version3 → Version4 の主な差分まとめ
| 項目 | Version3 | Version4 |
|---|---|---|
| I/O | Workerごとにバラバラ | 完全統一 |
| context_layer | なし | 正式導入 |
| manager-api | タスクID混在 | タスクID分離 |
| UI | 会話AIと作業AIが混在 | 責務分離 |
| Memory | Workerも参照 | conversation_ai のみ stateful |
| MCP 化準備 | 不十分 | 完全に整った |
📝 まとめ
Version4 は AIの町の内部構造を根本から整えるフェーズでした。
- I/O の統一
- context_layer の導入
- manager-api の安定化
- UI の責務分離
- Memory の整理
これらにより、
Version5（MCP 化）に向けた準備がすべて整いました。
次はいよいよ、
作業AIの MCP ツール化 → WorkerLauncher の MCP サーバー化
という大きな進化に入ります。