※この記事は AI（Microsoft Copilot）によって生成され、筆者が内容を確認・調整しています。
※この記事は前回の記事
https://qiita.com/genkyoryo110/items/66ace09c0828ed3c90b6
の続編です。

AI の町プロジェクトは、複数の AI エージェントが協調してタスクを遂行する「自律型マルチエージェント基盤」です。
Version 5 では、アーキテクチャ全体を抜本的に再設計し、MCP（Model Context Protocol）化、Validation Layer Version3、短期改善ループなど、AI エージェントの品質保証と自律性を大幅に強化しました。

この記事では、Version 5 の全体像と技術的ポイントをまとめます。

🎯 Version 5 のゴール

Version 5 の目的は以下の 3 点でした。

Worker を MCP ツールとして正式に標準化する（MCP化）
Validation Layer Version3 を完成させ、Worker 出力の品質を保証する
Critic による短期改善ループを実装し、AI が自律的に改善する仕組みを作る

これらはすべて達成され、Version 5 は「AI の町の基盤が完成したバージョン」と言える状態になりました。

🚀 Version 5 の主な変更点

1. MCP（Model Context Protocol）化の完了

Version 5 最大の変更点は、Worker を MCP ツールとして再構成したことです。

WorkerLauncher → MCPサーバー
manager-api → MCPクライアント
Worker → MCPツール（JSON Schema で定義）

これにより、Worker の追加・差し替え・拡張が極めて容易になりました。

MCP リクエスト例

POST /manager_mcp
{
  "tool": "code_ai.run",
  "args": {
    "description": "Write a fibonacci function",
    "language": "python",
    "context_layer": {
      "goal": "高速化",
      "task_type": "code_generation",
      "improvement": "前回の改善案：メモ化を追加"
    }
  }
}

2. Validation Layer Version3 の完成

Version 5 では、Worker 出力の品質を保証するために 4段階の検証レイヤを実装しました。

🔍 4つの検証

検証	内容
Semantic Similarity	bge-m3 による意味類似度判定
Structure Validation	Worker タイプ別の構造検証
Anomaly Detection	IsolationForest による異常検知
Critic	LLM による改善案生成

フロー

Semantic → Structure → Anomaly → Critic

Critic が改善案を返した場合のみ、短期改善ループに進みます。

3. 短期改善ループの実装（最大3回）

Validation NG の場合、Critic が改善案を返すと、
context_layer.improvement に改善案を注入して自動再実行します。

改善ループのコード（抜粋）

for attempt in range(1, MAX_RETRY + 1):
    result = call_mcp(...)
    validation = pipeline.run(...)

    if validation["ok"]:
        return result

    critic_improve = validation["details"]["critic"]["improvement"]
    if critic_improve:
        req.args["context_layer"]["improvement"] = critic_improve
        continue

    raise HTTPException(400, validation)

ポイント

改善案が ない場合は retry しない（無限ループ防止）
改善案がある場合のみ再実行
novel_ai / code_ai が改善案をプロンプトに反映

4. Worker の安定化

novel_ai

scenario_text fallback
outline / metadata / scenario_text の抽出強化
改善案のプロンプト反映

code_ai

改善案のプロンプト反映
失敗ログ（failures/）
改善ログ（improvements/）
Obsidian の style.md / preferences.md を参照

5. UI の責務分離

Version 5 では UI も大きく改善。

ChatPanel → conversation_ai 専用
WorkerResultPanel → 作業AI専用
ResultCard → 統一フォーマットで結果表示

これにより、会話と作業結果が混ざらない構造になりました。

🏗️ Version 5 のアーキテクチャ

UI（Next.js）
   ↓
manager-api（MCPクライアント）
   ↓ Validation Layer（Version3）
   ↓ 短期改善ループ
WorkerLauncher（MCPサーバー）
   ↓
Worker（code_ai / novel_ai / conversation_ai ...）
   ↓
llm-executor（Ollama / GPU）

特徴

Worker はすべて MCP ツールとして統一
manager-api が Validation と改善ループを担当
llm-executor が LLM 呼び出しを一元管理

📁 ディレクトリ構成（抜粋）

ai-town/
├── manager-api/
│   ├── validation/        ← Validation Layer Version3
│   ├── context_layer/
│   └── routers/
├── launcher/
│   ├── workers/           ← MCPツール化された Worker
│   ├── services/
│   └── validation/
├── llm-executor/
└── next-ui/

🧠 Obsidian 統合記憶システム

各 Worker は以下の Markdown を参照します。

preferences.md
style.md
failures/
improvements/

これにより、Worker が「ユーザーの好み」や「過去の失敗」から学習できます。

🔮 Version 6 に向けて

Version 5 で基盤が完成したため、Version 6 は Worker 増産フェーズに入ります。

予定されている Worker：

image_ai（画像生成）
data_ai（データ分析）
browser_ai（ブラウザ操作）
blender_ai（3D）
voice_ai（音声生成）

また、payload / context_layer の標準化も進める予定です。

📝 まとめ

Version 5 は AI の町にとって 基盤完成のバージョンでした。

MCP化で Worker が標準化
Validation Layer Version3 で品質保証
短期改善ループで自律改善
Worker の安定化
UI の責務分離
Version 6 の準備完了

次のフェーズでは、より多くの Worker を追加し、
「AI の町」が本格的に拡張していく段階に入ります。