※この記事は 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 の町」が本格的に拡張していく段階に入ります。