※この記事は 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 サーバー化
という大きな進化に入ります。