multi-agent-shogun徹底解説｜将軍・家老・足軽で10AIを並列統制するOSS

AIコーディングツールが乱立する2026年、Claude Code・OpenAI Codex・GitHub Copilot・Kimi Codeを同時に動かしたいと思ったことはないだろうか。multi-agent-shogunは、最大10のAIエージェントをtmux上で並列実行し、日本の封建制度にインスパイアされた階層構造で統制するオープンソースフレームワークだ。GitHubスター数は1,200超、MITライセンスで公開されている。

作者のyohey-w氏はREADMEで「上様（The Lord）はShogunに命令するだけでよい」と述べており、そのシンプルさが本ツールの核心だ。公式ドキュメントをベースに、アーキテクチャ・セットアップ・YAML通信プロトコル・Bloom’s Taxonomyルーティング・スキル自動発見までを体系的に解説する。

このフレームワークが画期的なのは、エージェント間の調整に一切のAPI呼び出しを使わない点だ。すべての通信がファイルシステムとtmuxペインで完結する。つまり調整レイヤのトークン消費がゼロになる。1時間あたり100ドル以上かかるAPI課金型と比べ、月200ドル程度のCLIサブスクリプション定額で8エージェントが並列稼働する経済性がある。

AIエージェントフレームワークの主要選択肢を検討中の開発者にとって、multi-agent-shogunは「CLIを束ねる」という独自ポジションを取る有力候補だ。本記事では16分相当の動画解説レベルの情報量で、封建的アーキテクチャの中身を日本語で展開する。

この記事ではAIエージェントに特化して解説します。AIエージェント全般は AIエージェントフレームワーク比較2026年版 をご覧ください。

「封建階層はフォルダとペイン」——構造を理解する

multi-agent-shogunの本質は驚くほどシンプルだ。tmuxセッション1本の中に4種類のペイン（Shogun・Karo・Ashigaru×7・Gunshi）が並び、queue/フォルダ配下のYAMLファイルで情報をやり取りする。それだけだ。

multi-agent-shogun/
├── shutsujin_departure.sh   ← 全エージェント起動スクリプト
├── first_setup.sh           ← 初回セットアップ
├── config/
│   └── settings.yaml        ← モデル・Bloom tier設定
├── queue/
│   ├── shogun_to_karo.yaml  ← 上様→Shogunの命令
│   ├── karo_to_ashigaru/    ← Karoから各足軽への指示
│   ├── tasks/               ← サブタスク定義
│   └── inbox/               ← 各エージェントの受信箱
├── dashboard.md             ← リアルタイム進捗（Karo管理）
└── skills/                  ← ボトムアップで育つスキル集

階層構造にするメリットは「命令の即時委任」にある。ユーザーがShogunに命令を出した瞬間、Shogunはqueue/shogun_to_karo.yamlにタスクを書き込みKaroに渡し、制御をユーザーに返す。ユーザーは次の命令をすぐに積める。逐次実行が前提の多くのエージェントフレームワークとはUX思想が根本的に異なる。

既存のマルチエージェントフレームワークとの根本的な違い

多くのユーザーがまず疑問に思うのが「LangGraphやCrewAIでいいのでは？」という点だ。

大量のエージェント間メッセージをAPIで送受信すると、毎回プロンプトキャッシュ外のトークンを消費する。multi-agent-shogunはファイルシステムを共有メモリとして使うため、調整コストを物理的に削減する設計だ。

役割と設定：YAML frontmatterフィールド完全解説

multi-agent-shogunの各エージェントはconfig/settings.yamlで定義される。役割・モデル・Bloom上限・echo_messageなどを構造化YAMLで記述する。

# config/settings.yaml — エージェント定義の抜粋
agents:
  shogun:
    role: "supreme_commander"
    model: claude-opus-4-6
    extended_thinking: true
    description: "Receives the Lord's orders and delegates immediately"
  karo:
    role: "manager"
    model: claude-sonnet-4-6
    description: "Task decomposition, quality check, dashboard management"
  ashigaru:
    count: 7
    model: claude-sonnet-4-6
    description: "Parallel implementation, research, file operations"
  gunshi:
    role: "strategist"
    model: claude-opus-4-6
    description: "Analysis, evaluation, design review"

エージェント役割の全フィールド

最重要フィールドは role と max_bloom だ。Karoはタスクの認知的複雑度（Bloom’s Taxonomy）を評価し、そのレベルに対応できるエージェントにルーティングする。設定ミスがあると「L6の設計タスクを足軽に割り振る」ような事故が起きる。

タスクYAMLで使える変数

# Shogunペインでの命令例
"Research top 5 JS frameworks and build a comparison table"

# queue/tasks/subtask_010b.yaml 内での変数参照
${task_id}          → "subtask_010b"
${blocked_by}       → 先行タスクID配列
${ashigaru_id}      → 担当足軽番号（1〜7）
${SHOGUN_SESSION}   → 現在のtmuxセッションID
${SKILL_DIR}        → ボトムアップで生成されたスキル集のパス

動的通信：inotifywatch駆動のイベント配信

YAMLファイルの更新検知にはinotifywaitが使われ、ポーリングではなくカーネルイベントとして即時に伝播する。CPUアイドル時の消費はゼロだ。

# inbox_watcher.sh — 各エージェントが起動時にバックグラウンドで実行
inotifywait -m -e modify,create \
  "$QUEUE_DIR/inbox/${AGENT_NAME}.yaml" | \
while read -r directory events filename; do
  flock -x "$LOCK_FILE" \
    cat "$QUEUE_DIR/inbox/${AGENT_NAME}.yaml" | \
    process_message
done

これによりファイル書き込みからエージェント反応までのレイテンシは10ms未満に収まる。APIベースのメッセージバスでは避けられないネットワーク往復が存在しないため、体感上は「同時実行」そのものだ。

4つの役割スコープ：誰に何を任せるか

multi-agent-shogunには4種類のエージェントスコープがある。どのタスクをどの役割に委譲するかで処理効率とコストが大きく変わる。

# スコープ別の責務

# 1. Shogun（将軍・1名）
上様の命令を受け取り、即時にKaroへ委任。自身は実装しない

# 2. Karo（家老・1名）
タスク分割・Bloom評価・足軽への配分・品質チェック・ダッシュボード管理

# 3. Ashigaru（足軽・7名）
実装担当。コード生成・ファイル編集・リサーチを並列実行

# 4. Gunshi（軍師・1名）
分析・評価・設計レビュー。L4〜L6の高度タスクを処理

Shogun > Karo > Ashigaru という階層で、上位が下位に命令する一方向の流れが保証される。これにより指示系統の循環参照が発生せず、デッドロックや競合が起きにくい構造になっている。

Gunshiはやや特殊で、Karoから相談を受けて戦略レベルの判断を返すアドバイザー的役割だ。新アーキテクチャの採用可否や、複雑なトレードオフのある設計判断に使われる。OpenHandsのように単一エージェントが自律的に動くツールと比べ、multi-agent-shogunは「戦略担当」を分離することで意思決定の質を上げる設計思想を取っている。

エージェントの呼び出し：3パターンを使い分ける

タスクの割り振りパターンには3つの方式がある。自動ルーティング・手動指名・スキルベース実行の3つだ。

呼び出しパターンの制御

# パターン1：自動ルーティング（デフォルト）
task:
  task_id: research_js_frameworks
  description: "Survey top 5 JS frameworks"
  # Karoが自動でBloom L2（Understand）と判定 → 足軽に配分

# パターン2：手動指名（特定足軽に直接委譲）
task:
  task_id: migrate_prisma
  assigned_to: ashigaru_3   # 明示的に3号を指定
  description: "Migrate Prisma schema"

# パターン3：スキル呼び出し（ボトムアップで生成された手順）
task:
  task_id: api_scaffold
  skill: "api-endpoint-scaffold"   # skills/配下の手順を呼び出す
  arguments: ["/api/users", "GET,POST"]

本番デプロイなど副作用のある操作は、必ずassigned_toを明示して手動指名すべきだ。自動ルーティングでは意図しない足軽に重大タスクが割り当てられる可能性がある。

タスクのライフサイクル

書き込まれたタスクYAMLはqueue/tasks/に保存され、完了までファイルとして存在し続ける。途中でクラッシュが発生しても、再起動後に未完了タスクを自動再開できる。完了後はqueue/archive/YYYY-MM/に移動され、dashboard.mdからリンクが張られる。

# queue/archive/2026-03/subtask_010a.yaml 完了タスクの例
task:
  task_id: subtask_010a
  status: completed
  started_at: "2026-03-24T18:02:11+0900"
  completed_at: "2026-03-24T18:04:33+0900"
  assigned_to: ashigaru_1
  output_files:
    - "src/api/client.ts"
    - "src/api/types.ts"
  echo_message: "🔥 足軽1号、一番槍を取ったり！"

実践活用パターン：封建階層で「複雑タスクを分解」する

作者yohey-w氏がREADMEで強調するキーメッセージは「並列度を上げるだけでは不十分で、指揮系統を設計することが重要」だ。具体的な活用パターンを3つ紹介する。

パターン1：大規模リサーチの並列実行

# 上様の命令
"Survey the top 10 JavaScript frameworks for server-side rendering"

# Karoが自動分解した結果（queue/karo_to_ashigaru/配下）
- ashigaru_1.yaml: "Next.js 公式ドキュメント調査"
- ashigaru_2.yaml: "Remix 公式ドキュメント調査"
- ashigaru_3.yaml: "SvelteKit 公式ドキュメント調査"
- ashigaru_4.yaml: "Nuxt 公式ドキュメント調査"
- ashigaru_5.yaml: "Astro 公式ドキュメント調査"
- ashigaru_6.yaml: "SolidStart・Qwik・Hydrogen調査"
- ashigaru_7.yaml: "比較表の整形・dashboard.md更新"
- gunshi.yaml:   "全調査結果の評価・推薦ランキング作成"

パターン2：フルスタックアプリのスキャフォールディング

# 上様の命令
"Create a todo app with Next.js + Prisma + Postgres + Vitest"

# Karoが自動分解（依存関係を含む）
tasks:
  - task_id: scaffold_repo
    assigned_to: ashigaru_1
    description: "Next.js初期化・TypeScript設定"

  - task_id: prisma_schema
    assigned_to: ashigaru_2
    blocked_by: [scaffold_repo]
    description: "Prismaスキーマ定義・マイグレーション"

  - task_id: api_routes
    assigned_to: ashigaru_3
    blocked_by: [prisma_schema]
    description: "/api/todos CRUD実装"

  - task_id: frontend
    assigned_to: [ashigaru_4, ashigaru_5]
    blocked_by: [api_routes]
    description: "UI実装を2名で分担"

  - task_id: tests
    assigned_to: ashigaru_6
    blocked_by: [frontend]
    description: "Vitestでユニット・統合テスト"

パターン3：音声経由のタスク投入とntfyプッシュ通知

# SayTask連携例（config/saytask.yaml）
saytask:
  voice_input: enabled
  ntfy_topic: "multi-agent-shogun-alerts"
  morning_digest: "08:00"

# 音声入力「明日歯医者」→ 自動分類
auto_categorize:
  - pattern: "歯医者|病院|予約"
    category: "personal_schedule"
  - pattern: "deploy|リリース"
    category: "production_operation"
    require_shogun_approval: true

封建階層の最大の価値は「タスクの同時並列化による時間短縮」だ。単一エージェントで逐次実行すると30分かかるタスクが、8エージェント並列では実質5〜10分に短縮される。CLIサブスクは月額固定なので、並列化してもコストは増えない。

ForgeCodeのような単一エージェントAIコーディングツールが「深く集中する」方向なのに対し、multi-agent-shogunは「広く並列化する」方向性を取っている。

ボトムアップのスキル発見：5週間で200スキルが自動生成

multi-agent-shogunには、他のフレームワークにない独自機能がある。足軽が作業中に発見した再利用可能パターンを自動的にスキル候補として提案する機能だ。

# 足軽が作業中に検出したパターンをYAMLで報告
skill_candidate:
  found: true
  name: "api-endpoint-scaffold"
  reason: "Same REST scaffold pattern detected in 3 recent tasks"
  template_files:
    - "src/api/{resource}/route.ts"
    - "src/api/{resource}/schema.ts"
  approval_required: true

3種類のスキル生成経路

動画でyohey氏が紹介したスキルカテゴリは3つに分類される。

• 頻度トリガー: 同じパターンが3回以上検出されると自動提案
• 軍師推奨: Gunshiが設計パターンとして発見・推奨
• 上様承認型: ユーザー（上様）が「これをスキル化しろ」と明示的に指示

特に興味深いのは、AIコーディング以外の領域でもスキル発見が起きている点だ。音声入力の自動分類パターン・ntfy通知のフォーマット・ダッシュボード更新ルールなど、フレームワーク自身の運用ノウハウがスキル化されていく。

MCPとShogunスキルの関係

動画では、MCPとShogunスキルの関係も明確に整理されている。

MCPは「外部世界への接続」、Shogunスキルは「内部知識の蓄積」——この2つは競合ではなく補完関係だ。MCP経由でGitHub・Notion・Slackなど外部サービスに接続し、その使い方をShogunスキルとして蓄積する構造になっている。

リリース5週間で、公式リポジトリには約200個のコミュニティスキルが登録された。api-endpoint-scaffold・prisma-migration・next-auth-setupなど実用的なものが並ぶ。Browser Useとの組み合わせでUI自動化スキルも続々と公開されている。

multi-agent-shogunあり vs なし：何が変わるのか

封建階層アーキテクチャを導入する前後で何が変わるか、具体的な対比で整理する。

指揮系統・MCP・スキル・フックの使い分け

multi-agent-shogun関連プリミティブの4階層：

┌─────────────────┬──────────────┬───────────────────────────┐
│ 機能            │ 動作タイミング │ 主な用途                   │
├─────────────────┼──────────────┼───────────────────────────┤
│ 指揮系統         │ 常時          │ 役割分担・Bloom評価        │
│ Shogunスキル     │ パターン検出時 │ 再利用可能な手順書         │
│ MCPサーバー      │ 外部接続時     │ GitHub/Slack/Notion連携    │
│ フック(hooks/)   │ タスク前後    │ lint・test・通知の自動実行 │
└─────────────────┴──────────────┴───────────────────────────┘

まとめ：「将軍はただのtmuxペイン」の意味

yohey-w氏がmulti-agent-shogunで伝えたかったことはシンプルだ。

tmuxセッション1つ作り、YAMLで命令を書く。それだけでAIの軍勢が動き出す。

README のクロージングでは、コンピューティングの歴史になぞらえた鮮やかなアナロジーが示されている。

CLIサブスク = 将兵の俸給（固定費で人数に依存しない）
tmux + YAML = 陣形・伝令（API呼び出しゼロの指揮系統）
封建階層   = 意思決定ピラミッド（責任の明確な分離）

将軍一人では戦に勝てない。
家老の分割統治と足軽の機動力、軍師の戦略眼がそろって初めて勝てる。
multi-agent-shogunはこの戦国の知恵を、AIエージェントの世界に持ち込んだ。

「上様は号令を出すだけでよい。現場の泥仕事は我々に任せよ」——README冒頭の家老のセリフ

そしてもう1つ、READMEで語られた大きなビジョンがある——継続学習だ。

multi-agent-shogunを1日目から使い続けると、30日目の陣営は1日目より格段に優秀になる。足軽が発見したパターンがスキルとして蓄積し、Karoのタスク分解精度が上がり、Gunshiの戦略判断に過去事例が反映される。現在すでに「skill-creator skill」（Shogunがスキルを自分で作るスキル）が公開されており、この方向をさらに推し進める予定だという。

multi-agent-shogunのポイントを再整理すると：

1. 構造: multi-agent-shogun/配下にtmuxセッション＋YAML通信キュー
2. エージェント: Shogun（1）・Karo（1）・Ashigaru（7）・Gunshi（1）の計10名
3. 役割分担: Bloom’s Taxonomy L1〜L6でタスク複雑度を評価しルーティング
4. 通信: YAMLファイル書き込み＋inotifywaitでAPI呼び出しゼロ
5. コスト: CLIサブスクで月200ドル、API課金型なら時給100ドル超の差
6. 拡張: ボトムアップのスキル自動発見で、使うほど賢くなる

# 今すぐ試す最短手順
git clone https://github.com/yohey-w/multi-agent-shogun
cd multi-agent-shogun
bash first_setup.sh && bash shutsujin_departure.sh
tmux attach-session -t shogun
# Shogunペインに自然言語で命令を入力

「エージェントを一人ずつ動かすのをやめて、軍勢として動かそう」——yohey-w氏のメッセージだ。今日からtmuxセッションを1本立ててみてほしい。

参照ソース

• yohey-w/multi-agent-shogun - GitHub
• multi-agent-shogun README（公式ドキュメント）
• ntfy - Open Source Push Notifications
• Bloom’s Taxonomy公式解説（Vanderbilt大学）
• tmux公式ドキュメント