📖 続編(2026年8月): 作者はその後、自分の10体のAI家臣団を解散し、判断だけを引き継いだ一体に絞りました。後継プロジェクトは kagemusha——エージェントではなく、判断ループ(訂正→原則→恒久ルール)の「形式」を配るキットです。解散の顛末: 記事。multi-agent-shogun自体はこれまでどおり動きます。

家老1体が足軽7体+軍師1体を統率 — 実際の稼働画面、モックデータなし

クイックスタート

必要なもの: tmux、bash 4+、以下のいずれか: Claude Code / Codex / Copilot / Kimi / OpenCode

git clone https://github.com/yohey-w/multi-agent-shogun
cd multi-agent-shogun
bash first_setup.sh                        # 初回セットアップ: 設定・依存関係・MCP
source ~/.bashrc                           # PATH反映
claude --dangerously-skip-permissions      # 初回のみ: OAuth認証 + Bypass承認 → /exit で退出
bash shutsujin_departure.sh                # 全エージェント起動

詳しいインストール手順（Windows含む）と「最初の30分の歩き方」は下記 🚀 クイックスタート と 📖 基本的な使い方 を参照。

将軍ペインに命令を入力：

「ユーザー認証の REST API を作って」

将軍が委譲 → 家老が分解 → 足軽7体が並列実行。 あとはダッシュボードを眺めるだけ。

もっと詳しく知りたい方へ: 以降のセクションでアーキテクチャ・設定・メモリ設計・Multi-CLI対応を解説しています。

これは何？

multi-agent-shogun は、複数のAIコーディングCLIインスタンスを同時に実行し、戦国時代の軍制のように統率するシステムです。Claude Code、OpenAI Codex、GitHub Copilot、Kimi Code、OpenCode、Cursor、Antigravity の7CLIに対応。

なぜ使うのか？

• 1つの命令で、7体のAIワーカー+1体の軍師が並列で実行
• 待ち時間なし - タスクがバックグラウンドで実行中も次の命令を出せる
• AIがセッションを跨いであなたの好みを記憶（Memory MCP）
• ダッシュボードでリアルタイム進捗確認

      あなた（上様）
           │
           ▼ 命令を出す
    ┌─────────────┐
    │   SHOGUN    │  ← 命令を受け取り、即座に委譲
    └──────┬──────┘
           │ YAMLファイル + tmux
    ┌──────▼──────┐
    │    KARO     │  ← タスクをワーカーに分配
    └──────┬──────┘
           │
  ┌─┬─┬─┬─┴─┬─┬─┬────────┐
  │1│2│3│4│5│6│7│ GUNSHI │  ← 7体のワーカー + 1体の軍師
  └─┴─┴─┴─┴─┴─┴─┴────────┘
     ASHIGARU      軍師

なぜ Shogun なのか？

多くのマルチエージェントフレームワークは、連携のためにAPIトークンを消費します。Shogunは違います。

他のフレームワークとの違い

連携コストゼロ — エージェント間の通信はディスク上のYAMLファイル。APIコールは実際の作業にのみ使われ、オーケストレーションには使われません。8体のエージェントを動かしても、支払うのは8体分の作業コストだけです。

完全な透明性 — すべてのエージェントが見えるtmuxペインで動作。すべての指示・報告・判断がプレーンなYAMLファイルで、読んで、diffして、バージョン管理できます。ブラックボックスなし。

実戦で鍛えた階層構造 — 将軍→家老→足軽の指揮系統が設計レベルで衝突を防止：明確な責任分担、エージェントごとの専用ファイル、イベント駆動通信、ポーリングなし。

なぜCLI（APIではなく）？

多くのAIコーディングツールはトークン従量課金。8体のOpus級エージェントをAPI経由で動かすと**$100+/時間**。CLI定額サブスクはこれを逆転させる：

「AIを使い倒す」思想 — 定額CLIサブスクなら、8体の足軽を気兼ねなく投入できる。1時間稼働でも24時間稼働でもコストは同じ。「まあまあ」と「徹底的に」の二択で悩む必要がない — エージェントを増やせばいい。

Multi-CLI対応

将軍システムは特定ベンダーに依存しない。7つのCLIツールに対応し、それぞれの強みを活かす：

OpenCode の起動は --agent で生成済み .opencode/agents/<agent_id>.md を読み込み、リセットは /new、モデル変更は再起動で行う。ロール別の境界は生成されたエージェント frontmatter に埋め込まれており、将軍は監督のため queue/reports/* を読めるが書けず、家老は分配と報告集約のみ、足軽は自分の task/report のみ、軍師は足軽レポートを読み gunshi_report.yaml だけを書く。

統一ビルドシステムが共有テンプレートからCLI固有の指示書を自動生成：

instructions/
├── common/              # 共通ルール（全CLI共通）
├── cli_specific/        # CLI固有のツール説明
│   ├── claude_tools.md  # Claude Code ツール・機能
│   ├── copilot_tools.md # GitHub Copilot CLI ツール・機能
│   ├── opencode_tools.md # OpenCode ツール・エージェントfrontmatter・権限モデル
│   └── cursor_tools.md  # Cursor Agent ツール・スキル・セッションルール
└── roles/               # ロール定義（将軍、家老、足軽）
    ↓ ビルド
CLAUDE.md / AGENTS.md / .github/copilot-instructions.md / .opencode/agents/*.md / .cursor/rules/*.md
  ← CLI別に生成

ルールの変更は1箇所。全CLIに反映。同期ズレなし。

ボトムアップスキル発見

他のフレームワークにはない機能です。

足軽がタスクを実行する中で、再利用可能なパターンを自動的に発見し、スキル候補として提案します。家老が提案を dashboard.md に集約し、殿（あなた）が正式なスキルに昇格させるか判断します。

足軽がタスクを完了
    ↓
気づき: 「このパターン、3つのプロジェクトで同じことをした」
    ↓
YAMLで報告:  skill_candidate:
                 found: true
                 name: "api-endpoint-scaffold"
                 reason: "3プロジェクトで同じRESTスキャフォールドパターンを使用"
    ↓
dashboard.md に掲載 → 殿が承認 → .claude/commands/ にスキル作成
    ↓
全エージェントが /api-endpoint-scaffold を呼び出し可能に

スキルは実際の作業から有機的に成長します — 既製のテンプレートライブラリからではなく。スキルセットはあなた自身のワークフローの反映になります。

🚀 クイックスタート

🪟 Windowsユーザー（最も一般的）

cd /mnt/c/tools/multi-agent-shogun
./first_setup.sh

./shutsujin_departure.sh

🔑 初回のみ: 認証

first_setup.sh 完了後、一度だけ以下を実行して認証：

# 1. PATHの反映
source ~/.bashrc

# 2. OAuthログイン + Bypass Permissions承認（1コマンドで完了）
claude --dangerously-skip-permissions
#    → ブラウザが開く → Anthropicアカウントでログイン → CLIに戻る
#    → 「Bypass Permissions」の承認画面 → 「Yes, I accept」を選択（↓キーで2を選んでEnter）
#    → /exit で退出

認証情報は ~/.claude/ に保存され、以降は不要。

📅 毎日の起動（初回セットアップ後）

Ubuntuターミナル（WSL）を開いて実行：

cd /mnt/c/tools/multi-agent-shogun
./shutsujin_departure.sh

📱 スマホからアクセス — 専用Androidアプリ（推奨）

専用のAndroidアプリで10体のAIエージェントをスマホから監視・指揮できる。

Note: 現在Androidのみ対応。iOS版は開発者にテスト端末がないため未対応。ニーズがあれば Issue で教えてください。PRも歓迎！

セットアップ手順

前提条件：

• WSL2 (またはLinuxサーバー) で将軍システムが稼働中
• SSHサーバーが起動済み (sudo service ssh start)
• スマホとサーバーが同一ネットワーク上（LAN or Tailscale）

手順：

1. APKをインストール

   1. android/release/multi-agent-shogun.apk をスマホにダウンロード（GitHub上のファイルを開いて「Download raw file」）
   2. ダウンロード完了の通知をタップ → 「インストール」
   3. 「提供元不明のアプリ」警告が出たら → 「設定」→ 該当ブラウザの「この提供元を許可」をON → 戻って「インストール」
   4. インストール完了 → 「開く」

2. SSH接続情報を設定（設定タブ）

   項目	入力例	説明
   SSHホスト	100.xxx.xxx.xxx	サーバーのIP（Tailscale IPなど）
   SSHポート	22	通常は22
   SSHユーザー	your_username	SSH接続のユーザー名
   SSH秘密鍵パス	/data/data/.../id_ed25519	スマホ上の秘密鍵パス（※1）
   SSHパスワード	****	鍵がない場合はパスワード認証
   プロジェクトパス	/mnt/c/tools/multi-agent-shogun	サーバー側のプロジェクトディレクトリ
   将軍セッション名	shogun	tmuxの将軍セッション名
   エージェントセッション名	multiagent	tmuxのエージェントセッション名

   ※1 秘密鍵はスマホに転送するか、パスワード認証を使用

3. 保存 → 将軍タブに切り替え → 自動接続

Tailscaleを使う場合（外出先からも接続可能）：

# サーバー側（WSL2）
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscaled &
sudo tailscale up --authkey tskey-auth-XXXXXXXXXXXX
sudo service ssh start

スマホにもTailscaleアプリをインストールして同じアカウントでログイン。表示されるTailscale IPをアプリのSSHホストに入力。

ntfy通知も併用する場合：

ntfyの設定セクションを参照。家老からの進捗通知をプッシュで受け取れる。

音声入力： Androidアプリの音声入力ボタンで喋れば、将軍が自然言語を理解して全軍に指示を出す。

もっと簡単に： ntfyを設定すると、プッシュ通知で進捗を受け取れます。

# 1. リポジトリをクローン
git clone https://github.com/yohey-w/multi-agent-shogun.git ~/multi-agent-shogun
cd ~/multi-agent-shogun

# 2. スクリプトに実行権限を付与
chmod +x *.sh

# 3. 初回セットアップを実行
./first_setup.sh

cd ~/multi-agent-shogun
./shutsujin_departure.sh

wsl --install

✅ セットアップ後の状態

どちらのオプションでも、10体のAIエージェントが自動起動します：

tmuxセッションが作成されます：

• shogun - ここに接続してコマンドを出す
• multiagent - 家老・足軽・軍師がバックグラウンドで稼働

📖 基本的な使い方

Step 1: 将軍に接続

shutsujin_departure.sh 実行後、全エージェントが自動的に指示書を読み込み、作業準備完了となります。

新しいターミナルを開いて将軍に接続：

tmux attach-session -t shogun

Step 2: 最初の命令を出す

将軍は既に初期化済み！そのまま命令を出せます：

JavaScriptフレームワーク上位5つを調査して比較表を作成せよ

将軍は：

1. タスクをYAMLファイルに書き込む
2. 家老（管理者）に通知
3. 即座にあなたに制御を返す（待つ必要なし！）

その間、家老はタスクを足軽ワーカーに分配し、並列実行します。

Step 3: 進捗を確認

エディタで dashboard.md を開いてリアルタイム状況を確認：

## 進行中
| ワーカー | タスク | 状態 |
|----------|--------|------|
| 足軽 1 | React調査 | 実行中 |
| 足軽 2 | Vue調査 | 実行中 |
| 足軽 3 | Angular調査 | 完了 |

案件単位での運用（Visual Studio の「ソリューション」相当）

shogun システムは一度セットアップすれば、複数の案件（プロジェクト）を同じ将軍配下で切り替えながら扱えます。Visual Studio で言う「ソリューション」に相当する単位は projects/{name}.yaml + context/{name}.md です。

1. 最小の1案件を動かす流れ

# (1) 将軍に接続（shutsujin_departure.sh 完了済みの状態から）
tmux attach-session -t shogun

# (2) 将軍に案件を指示するだけで自動的に案件が立ち上がる
#     → 将軍が cmd を queue/shogun_to_karo.yaml に書き、家老に通知
#     → 家老が足軽に割り振り、並列実行
#     → 結果は dashboard.md に集約

明示的な「案件を作る」コマンドは不要です。将軍が必要に応じて cmd の project: フィールドに案件IDを付け、関連ファイルは自動的に分離されます。

2. 案件を明示登録する場合（任意・長期案件向け）

長期的に同じ案件を回す場合、メタ情報を projects/{name}.yaml に置けます:

# projects/example.yaml
id: example
name: "サンプル案件"
working_directory: /path/to/repo
north_star: "この案件で達成したい最終目標"
notes: |
  案件固有のメモ、関係者、特殊ルール

将軍/家老はこのファイルを参照し、cmd 発令時に案件コンテキストを組み込みます。

詳細な案件知識（要件、設計、過去のFB）は context/{name}.md に書きます。将軍が案件に関する cmd を発令する際、自動的にこのファイルを参照します。

3. エージェント構成のカスタマイズ

陣営構成（誰にどのCLIを使わせるか）は config/settings.yaml：

cli:
  agents:
    ashigaru1:
      type: codex          # codex / claude / copilot / kimi / opencode
      model: gpt-5.5
    ashigaru2:
      type: claude
      model: claude-sonnet-4-6
    # ashigaru3-7, gunshi, karo も同様

OpenCode は provider付きモデルIDを使います：

cli:
  agents:
    ashigaru3:
      type: opencode
      model: openrouter/openai/gpt-4o-mini
      variant: high  # 任意: provider固有のreasoning variant

OpenRouter 設定は2つに分かれます：

1. モデルルーティング は上記の通り config/settings.yaml に書きます（type: opencode、model: openrouter/...）。
2. provider認証 は settings.yaml ではなく OpenCode 側で設定します。将軍を起動するのと同じOSユーザーで一度 OpenCode を起動し、/connect → OpenRouter からAPIキーを登録してください。OpenCodeはprovider認証情報をそのOSユーザーのOpenCodeユーザーデータ配下（例: ~/.local/share/opencode/。具体的なファイル/DBはOpenCode内部実装）に保存します。ヘッドレス運用などで環境変数方式を使う場合は、shutsujin_departure.sh を実行するシェルに OPENROUTER_API_KEY を読み込ませてください。

APIキーを config/settings.yaml、config/opencode-tui.json、.opencode/agents/*.md に書かないでください。これらはルーティング、tmux向けキー設定、生成済みロール定義の置き場です。

OpenCode 選択時は lib/cli_adapter.sh が --agent <agent_id> と、リポジトリ固定の OPENCODE_TUI_CONFIG=config/opencode-tui.json を付けて起動します。OpenCode TUI 起動コマンドは --variant を受け付けないため、対象agentに variant: があれば scripts/build_instructions.sh と scripts/switch_cli.sh が model: / variant: を git-ignored の .opencode/agents/<agent_id>-runtime.md に同期し、OpenCode が --agent <agent_id>-runtime 経由で読み込みます。

途中で切り替えたい場合は scripts/switch_cli.sh を使います：

bash scripts/switch_cli.sh ashigaru3 --type claude --model claude-sonnet-4-6
bash scripts/switch_cli.sh ashigaru3 --type opencode --model openrouter/openai/gpt-4o-mini
bash scripts/switch_cli.sh ashigaru3 --type opencode --model openrouter/minimax/minimax-m2.5 --variant xhigh

4. 案件の切り替え／クローズ

「案件をクローズする」明示コマンドはありません。将軍が次の案件の cmd を発令すれば、自動的にコンテキストは切り替わります。

• 一時的に脇に置く: 何もしなくてよい。queue/ の旧 cmd は履歴として残り、将軍が再開時に状態を復元
• 完全に終了: projects/{name}.yaml を削除、または archived: true フラグを追加
• 並行運用: 複数の案件を同時に走らせる場合、cmd の project: フィールドで区別

5. 経験値・設定の引き継ぎ

次回以降の案件で活きるのは:

特に Memory MCP が「経験値」の中心。殿が「次から〇〇しないで」「△△を覚えとけ」と言えば、将軍が自動的に Memory MCP に記録し、新しい案件でも継続して参照します。

詳細なフロー

あなた: 「トップ5のMCPサーバを調査して比較表を作成せよ」

将軍がタスクを queue/shogun_to_karo.yaml に書き込み、家老を起動。あなたには即座に制御が戻ります。

家老がタスクをサブタスクに分解：

5体の足軽が同時に調査開始。リアルタイムで作業を見ることができます。

結果は完了次第 dashboard.md に表示されます。

✨ 主な特徴

⚡ 1. 並列実行

1つの命令で最大8つの並列タスクを生成：

あなた: 「5つのMCPサーバを調査せよ」
→ 5体の足軽が同時に調査開始
→ 数時間ではなく数分で結果が出る

🔄 2. ノンブロッキングワークフロー

将軍は即座に委譲して、あなたに制御を返します：

あなた: 命令 → 将軍: 委譲 → あなた: 次の命令をすぐ出せる
                                    ↓
                    ワーカー: バックグラウンドで実行
                                    ↓
                    ダッシュボード: 結果を表示

長いタスクの完了を待つ必要はありません。

🧠 3. セッション間記憶（Memory MCP）

AIがあなたの好みを記憶します：

セッション1: 「シンプルな方法が好き」と伝える
            → Memory MCPに保存

セッション2: 起動時にAIがメモリを読み込む
            → 複雑な方法を提案しなくなる

📡 4. イベント駆動通信（ポーリングなし）

エージェント同士はYAMLファイルを書いて通信します — メモを渡すイメージ。ポーリングなし、APIコールの浪費なし。

家老が足軽3号を起こしたい場合:

Step 1: メッセージを書く            Step 2: エージェントを起こす
┌──────────────────────┐           ┌──────────────────────────┐
│ inbox_write.sh       │           │ inbox_watcher.sh         │
│                      │           │                          │
│ メッセージ全文を     │  ファイル │ ファイル変更を検知       │
│ ashigaru3.yaml に    │──変更────▶│ (inotifywait、ポーリング │
│ flock付きで書き込み  │           │  ではなくカーネルイベント)│
└──────────────────────┘           │                          │
                                   │ 起床方法:                │
                                   │  1. 自己監視（スキップ） │
                                   │  2. tmux send-keys       │
                                   │    （短いnudgeのみ）     │
                                   └──────────────────────────┘

Step 3: エージェントが自分のinboxを読む
┌──────────────────────────────────┐
│ 足軽3号が ashigaru3.yaml を読む  │
│ → 未読メッセージを発見           │
│ → 処理する                       │
│ → 既読にする                     │
└──────────────────────────────────┘

起床の仕組み:

Agent Self-Watch (ASW) フェーズ — tmux send-keys nudgeの使用をどこまで抑制するかを制御:

Phase 2はidleフラグファイル（/tmp/shogun_idle_{agent}）でbusy/idle状態を判定する。Stop hookがターン境界でフラグを作成/削除する。作業中のnudge割り込みを排除しつつ、idle時の起床は維持する。

なぜnudge完全撲滅できないのか？ Claude CodeのStop hookはターン終了時にしか発火しない。idleのエージェント（プロンプトで待機中）はターンが終了しないため、inboxチェックを発火させるhookがない。将来 Notification hookの idle_prompt タイプがブロック対応になるか、定期タイマーhookが追加されれば解決可能。

config/settings.yaml で設定:

asw_phase: 2   # Claude Code環境では推奨

または scripts/inbox_watcher.sh の ASW_PHASE 変数を直接変更。変更後はinbox_watcherプロセスの再起動が必要。

3段階エスカレーション（v3.2） — エージェントが応答しない場合:

設計のポイント:

• メッセージ内容はtmuxを経由しない — 送るのは短い「メールが届いたよ」の通知だけ。中身はエージェントが自分でファイルを読む。これにより文字化けや配信ハングを根絶。
• 待機中のCPU使用率ゼロ — inotifywait はカーネルイベントでブロック（ポーリングループではない）。メッセージ間のCPUは0%。
• 配信保証 — ファイル書き込みが成功すれば、メッセージは確実にそこにある。消失なし、リトライ不要。

📊 5. エージェント稼働確認

どのエージェントが稼働中か待機中か — コマンド1つで即座に確認：

# プロジェクトモード: タスク/inbox情報付きフルステータス
bash scripts/agent_status.sh

# スタンドアロンモード: 任意のtmuxセッションで動作
bash scripts/agent_status.sh --session mysession --lang en

プロジェクトモード出力:

Agent      CLI     Pane      Task ID                                    Status     Inbox
---------- ------- --------- ------------------------------------------ ---------- -----
karo       claude  待機中    ---                                        ---        0
ashigaru1  codex   稼働中    subtask_042a_research                      assigned   0
ashigaru2  codex   待機中    subtask_042b_review                        done       0
gunshi     claude  稼働中    subtask_042c_analysis                      assigned   0

スタンドアロンモード出力（プロジェクト設定不要）:

Pane                           State      Agent ID
------------------------------ ---------- ----------
multiagent:agents.0            IDLE       karo
multiagent:agents.1            BUSY       ashigaru1
multiagent:agents.8            BUSY       gunshi

判定は Claude Code・Codex CLI・OpenCode に対応。各tmuxペインの末尾付近からCLI固有のプロンプト/スピナーパターンを検出。判定ロジックは lib/agent_status.sh に分離されており、自作スクリプトからも利用可能：

source lib/agent_status.sh
agent_is_busy_check "multiagent:agents.3" && echo "稼働中" || echo "待機中"

📸 6. スクリーンショット連携

VSCode拡張のClaude Codeはスクショを貼り付けて事象を説明できます。このCLIシステムでも同等の機能を実現：

# config/settings.yaml でスクショフォルダを設定
screenshot:
  path: "/mnt/c/Users/あなたの名前/Pictures/Screenshots"

# 将軍に伝えるだけ:
あなた: 「最新のスクショを見ろ」
あなた: 「スクショ2枚見ろ」
→ AIが即座にスクリーンショットを読み取って分析

💡 Windowsのコツ: Win + Shift + S でスクショが撮れます。保存先を settings.yaml のパスに合わせると、シームレスに連携できます。

こんな時に便利：

• UIのバグを視覚的に説明
• エラーメッセージを見せる
• 変更前後の状態を比較

📁 7. コンテキスト管理

効率的な知識共有のため、四層構造のコンテキストを採用：

この設計により：

• どの足軽でも任意のプロジェクトを担当可能
• エージェント切り替え時もコンテキスト継続
• 関心の分離が明確
• セッション間の知識永続化

/clear プロトコル（コスト最適化）

長時間作業するとコンテキスト（Layer 4）が膨れ、APIコストが増大する。/clear でセッション記憶を消去すれば、コストがリセットされる。Layer 1〜3はファイルとして残るので失われない。

/clear 後の復帰コスト: 約6,800トークン（v1から42%改善 — CLAUDE.mdのYAML化 + 英語のみの指示書でトークンコストを70%削減）

1. CLAUDE.md（自動読み込み）→ shogunシステムの一員と認識
2. tmux display-message -t "$TMUX_PANE" -p '#{@agent_id}' → 自分の番号を確認
3. Memory MCP 読み込み → 殿の好みを復元（~700トークン）
4. タスクYAML 読み込み → 次の仕事を確認（~800トークン）

「何を読ませないか」の設計がコスト削減に効いている。

汎用コンテキストテンプレート

すべてのプロジェクトで同じ7セクション構成のテンプレートを使用：

この統一フォーマットにより：

• どのエージェントでも素早くオンボーディング可能
• すべてのプロジェクトで一貫した情報管理
• 足軽間の作業引き継ぎが容易

📱 8. スマホ通知（ntfy）

スマホと将軍の間で双方向通信 — SSH不要、Tailscale不要、サーバ不要。

📱 あなた（ベッドから）       🏯 将軍
    │                          │
    │  "React 19を調査せよ"    │
    ├─────────────────────────►│
    │    (ntfyメッセージ)      │  → 家老に委譲 → 足軽が作業
    │                          │
    │  "✅ cmd_042 完了"       │
    │◄─────────────────────────┤
    │    (プッシュ通知)        │

セットアップ：

1. config/settings.yaml に ntfy_topic: "shogun-yourname" を追加
2. スマホに ntfyアプリ をインストールし、同じトピックをサブスクライブ
3. shutsujin_departure.sh がリスナーを自動起動 — 追加手順なし

通知の例：

無料、アカウント不要、サーバ管理不要。ntfy.sh — オープンソースのプッシュ通知サービスを利用。

⚠️ セキュリティ注意: トピック名がそのままパスワードです。知っている人は誰でも通知を読んだり、将軍にメッセージを送れてしまいます。推測されにくい名前を選び、スクリーンショットやブログ、GitHubコミットなどで公開しないでください。

動作確認:

# テスト通知をスマホに送信
bash scripts/ntfy.sh "将軍システムからのテスト通知 🏯"

スマホに通知が届けば設定完了です。届かない場合:

• config/settings.yaml の ntfy_topic が設定されているか（空でないか、余分な引用符がないか）
• スマホのntfyアプリで完全に同じトピック名を購読しているか
• スマホがインターネットに接続されており、ntfyの通知が有効か

スマホから将軍に指示を送る方法:

1. スマホでntfyアプリを開く
2. 購読しているトピックをタップ
3. メッセージを入力（例: React 19のベストプラクティスを調査して）して送信
4. ntfy_listener.sh が受信 → queue/ntfy_inbox.yaml に書き込み → 将軍を起こす
5. 将軍がメッセージを読み、通常の家老→足軽パイプラインで処理

送信したテキストがそのままコマンドになります。将軍に話しかけるように書けばOK — 特別な構文は不要です。

リスナーの手動起動（shutsujin_departure.sh を使わない場合）:

# バックグラウンドでリスナーを起動
nohup bash scripts/ntfy_listener.sh &>/dev/null &

# 起動確認
pgrep -f ntfy_listener.sh

# ログを見ながら起動（フォアグラウンド）
bash scripts/ntfy_listener.sh

リスナーは接続が切れても自動的に再接続します。shutsujin_departure.sh で出陣すれば自動起動されるため、手動起動は出陣スクリプトを使わない場合のみ必要です。

トラブルシューティング:

SayTask通知

行動心理学に基づくモチベーション通知：

• ストリーク追跡: saytask/streaks.yaml で連続完了日数をカウント — ストリーク維持が損失回避の心理を利用してモメンタムを持続
• Eat the Frog 🐸: その日の最も難しいタスクを「カエル」としてマーク。完了すると特別な祝福通知が送信される
• 日次進捗: 12/12 tasks today — 視覚的な完了フィードバックがArbeitslust効果（仕事の進捗による喜び）を強化

🖼️ 9. ペインボーダータスク表示

各tmuxペインのボーダーにエージェントの現在のタスクを表示：

┌ ashigaru1 Sonnet+T VF requirements ──┬ ashigaru3 Opus+T API research ──────┐
│                                      │                                     │
│  SayTask要件定義中                   │  REST APIパターン調査中             │
│                                      │                                     │
├ ashigaru2 Sonnet ───────────────────┼ ashigaru4 Spark DBスキーマ設計 ─────┤
│                                      │                                     │
│  （待機中 — 割当待ち）               │  データベーススキーマ設計中         │
│                                      │                                     │
└──────────────────────────────────────┴─────────────────────────────────────┘

• 作業中: ashigaru1 Sonnet+T VF requirements — エージェント名、モデル（Thinkingインジケータ付き）、タスク概要
• 待機中: ashigaru2 Sonnet — モデル名のみ、タスクなし
• 表示名: Sonnet, Opus, Haiku, Codex, Spark — +T サフィックス = Extended Thinking有効
• 家老がタスク割当・完了時に自動更新
• 9ペインを一目見れば、誰が何をしているか即座にわかる

🔊 10. シャウトモード（戦国エコー）

足軽がタスクを完了すると、パーソナライズされた戦国風の叫びをtmuxペインに表示します — 部下が働いている実感を得られる。

┌ ashigaru1 Sonnet+T ─────────┬ ashigaru2 Sonnet+T ─────────┐
│                               │                               │
│  ⚔️ 足軽1号、任を果たし待機！ │  🔥 足軽2号、二番槍の意地！   │
│  八刃一志の志、胸に刻む！     │  八刃一志！共に城を落とせ！   │
│  ❯                            │  ❯                            │
└───────────────────────────────┴───────────────────────────────┘

仕組み:

家老がタスクYAMLに echo_message フィールドを記述。足軽は全作業完了後（レポート + inbox通知の後）、最後のアクションとして echo を実行。メッセージは ❯ プロンプト直上に残る。

# タスクYAML（家老が記述）
task:
  task_id: subtask_001
  description: "比較表を作成"
  echo_message: "🔥 足軽1号、先陣を切って参る！八刃一志！"

シャウトモードがデフォルト。 無効にする場合（echoのAPIトークン節約）:

./shutsujin_departure.sh --silent    # 戦国エコーなし
./shutsujin_departure.sh             # デフォルト: シャウトモード（戦国エコー有効）

サイレントモードは DISPLAY_MODE=silent をtmux環境変数に設定。家老がタスクYAML作成時にこれを確認し、echo_message フィールドを省略する。

🗣️ SayTask — タスク管理が嫌いな人のためのタスク管理

SayTaskとは？

タスク管理が嫌いな人のためのタスク管理。スマホに話しかけるだけ。

Talk Coding — Vibe Codingではない。 タスクを話すだけで、AIが整理する。入力なし、アプリを開かない、摩擦ゼロ。

• ターゲット: Todoistをインストールしたけど3日で開かなくなった人
• あなたの敵は他のアプリじゃない。何もしないこと。競合は他の生産性ツールではなく、無行動
• UIゼロ。入力ゼロ。アプリを開く動作ゼロ。ただ話すだけ

「あなたの敵は他のアプリじゃない。何もしないことだ。」

仕組み

1. ntfyアプリをインストール（無料、アカウント不要）
2. スマホに話しかける: 「歯医者 明日」、「請求書 金曜まで」
3. AIが自動整理 → 朝に通知: 「今日の予定です」

 🗣️ 「牛乳買う、歯医者 明日、請求書 金曜まで」
       │
       ▼
 ┌──────────────────┐
 │  ntfy → 将軍     │  AIが自動分類、日付解析、優先度設定
 └────────┬─────────┘
          │
          ▼
 ┌──────────────────┐
 │   tasks.yaml     │  構造化ストレージ（ローカル、端末外に出ない）
 └────────┬─────────┘
          │
          ▼
 📱 朝の通知:
    「今日: 🐸 請求書期限 · 🦷 歯医者3時 · 🛒 牛乳買う」

変更前／変更後

変更前（v1）	変更後（v2）
生のタスクダンプ	きれいに整理された日次サマリ

注: スクリーンショットに表示されているトピック名は例です。自分専用のトピック名を使用してください。

ユースケース

• 🛏️ ベッドの中: 「明日レポート提出しないと」 — 忘れる前にキャプチャ、ノート探さなくていい
• 🚗 運転中: 「クライアントAの見積もり忘れないで」 — ハンズフリー、前を見たまま
• 💻 仕事中: 「あ、牛乳買わないと」 — 即座にダンプしてフローに戻る
• 🌅 起床時: 今日のタスクが既に通知で待っている — アプリを開かない、受信トレイ確認不要
• 🐸 Eat the Frog: AIが毎朝一番大変なタスクを選ぶ — 無視してもいいし、最初に倒してもいい

FAQ

Q: 他のタスクアプリと何が違う？ A: アプリを開かない。ただ話すだけ。摩擦ゼロ。多くのタスクアプリは、人々が開かなくなるから失敗する。SayTaskはそのステップ自体を取り除いた。

Q: Shogunシステム全体なしでSayTaskだけ使える？ A: SayTaskはShogunの機能の一部。Shogunはスタンドアロンのマルチエージェント開発プラットフォームとしても機能する — 1つのシステムで両方の機能が手に入る。

Q: 🐸 Frogって何？ A: 毎朝、AIがあなたの一番大変なタスクを選ぶ — 避けたいやつ。最初に倒す（「Eat the Frog」方式）か無視するか。あなた次第。

Q: 無料？ A: すべて無料でオープンソース。ntfyも無料。アカウント不要、サーバ不要、サブスクリプション不要。

Q: データはどこに保存される？ A: ローカルのYAMLファイル。クラウドには何も送信されない。タスクは端末の外に出ない。

Q: 「仕事のあれ」みたいに曖昧なことを言ったら？ A: AIがベストを尽くして分類・スケジュールする。後で修正もできる — でもポイントは、忘れる前に思考をキャプチャすること。

SayTask vs cmdパイプライン

将軍システムには2つの補完的なタスクシステムがある：

SayTaskは個人の生産性を担当（キャプチャ → スケジュール → リマインド）。cmdパイプラインは複雑な作業を担当（リサーチ、コード、複数ステップのタスク）。両者はストリーク追跡を共有し、どちらのタスクを完了してもデイリーストリークにカウントされる。

🧠 モデル設定

Thinking制御: config/settings.yaml でエージェントごとに thinking: true/false を設定可能。thinking: false の場合、MAX_THINKING_TOKENS=0 で起動しExtended Thinkingを無効化。ペインボーダーにはThinking有効時に +T サフィックスが表示される（例: Sonnet+T、Opus+T）。

ライブモデル切替: /shogun-model-switch スキルで、システム全体を再起動せずに任意エージェントのCLI種別・モデル・Thinking設定を変更可能。詳細はスキルセクション参照。

認知的複雑さでのルーティングは2段階：エージェントルーティング（足軽はL1-L3、軍師はL4-L6）と 足軽内のモデルルーティング（capability_tiers でBloomレベルに応じて最適モデルを選択。下記「動的モデルルーティング」参照）。

Bloom's Taxonomy → エージェントルーティング

タスクはBloom's Taxonomy（ブルームの分類法）に基づいて分類し、最適なエージェントにルーティングします：

家老が各サブタスクにBloomレベルを付与し、適切なエージェントにルーティング。L1-L3は足軽に並列分配、L4-L6は軍師へ。簡単なL4タスク（小規模なコードレビュー等）は、家老の判断で足軽に回すこともある。

タスク依存関係（blockedBy）

タスクは blockedBy を使って他タスクへの依存を宣言できます：

# queue/tasks/ashigaru2.yaml
task:
  task_id: subtask_010b
  blockedBy: ["subtask_010a"]  # 足軽1のタスク完了を待つ
  description: "subtask_010aで構築したAPIクライアントを統合"

ブロック元のタスクが完了すると、家老が自動的に依存タスクのブロックを解除し、空いている足軽に割り当てます。これにより待機時間が削減され、依存タスクの効率的なパイプライン処理が可能になります。

動的モデルルーティング（capability_tiers）

エージェント単位のルーティングに加え、足軽階層内でのモデルレベルルーティングも設定できます。config/settings.yaml に capability_tiers テーブルを定義し、各モデルのBloom上限を指定します：

capability_tiers:
  gpt-5.3-codex-spark:
    max_bloom: 3       # L1–L3: 高速・大量処理タスク
    cost_group: chatgpt_pro
  gpt-5.3-codex:
    max_bloom: 4       # L1–L4: + 分析・デバッグ
    cost_group: chatgpt_pro
  claude-sonnet-4-6:
    max_bloom: 5       # L1–L5: + 設計評価
    cost_group: claude_max
  claude-opus-4-6:
    max_bloom: 6       # L1–L6: + 新規アーキテクチャ・戦略
    cost_group: claude_max

cost_group フィールドで各モデルをサブスクリプションプランに紐付け、契約外のモデルへのルーティングを防止します。

設定を支援する2つの組み込みスキルがあります：

セットアップ後に /shogun-bloom-config を実行して、最適な capability_tiers 設定を生成してください。

🧭 核心思想（Philosophy）

「脳死で依頼をこなすな。最速×最高のアウトプットを常に念頭に置け。」

将軍システムは5つの核心原則に基づいて設計されている：

詳細: docs/philosophy.md

🎯 設計思想

なぜ階層構造（将軍→家老→足軽）なのか

1. 即座の応答: 将軍は即座に委譲し、あなたに制御を返す
2. 並列実行: 家老が複数の足軽に同時分配
3. 単一責任: 各役割が明確に分離され、混乱しない
4. スケーラビリティ: 足軽を増やしても構造が崩れない
5. 障害分離: 1体の足軽が失敗しても他に影響しない
6. 人間への報告一元化: 将軍だけが人間とやり取りするため、情報が整理される

なぜメールボックスシステムなのか

直接メッセージではなく、なぜファイル経由なのか？

エージェント識別（@agent_id）

各ペインに @agent_id というtmuxユーザーオプションを設定（例: karo, ashigaru1）。pane_index はペイン再配置でズレるが、@agent_id は shutsujin_departure.sh が起動時に固定設定するため変わらない。

エージェントの自己識別:

tmux display-message -t "$TMUX_PANE" -p '#{@agent_id}'

-t "$TMUX_PANE" が必須。省略するとアクティブペイン（操作中のペイン）の値が返り、誤認識の原因になる。

モデル名は @model_name、現在のタスクの要約は @current_task として保存され、いずれも pane-border-format で常時表示されます。Claude Codeがペインタイトルを上書きしても、これらのユーザーオプションは消えません。

なぜ dashboard.md は家老のみが更新するのか

1. 単一更新者: 競合を防ぐため、更新責任者を1人に限定
2. 情報集約: 家老は全足軽の報告を受ける立場なので全体像を把握
3. 一貫性: すべての更新が1つの品質ゲートを通過
4. 割り込み防止: 将軍が更新すると、殿の入力中に割り込む恐れあり

🛠️ スキル

初期状態ではスキルはありません。 運用中にダッシュボード（dashboard.md）の「スキル化候補」から承認して増やしていきます。

スキルは /スキル名 で呼び出し可能。将軍に「/スキル名 を実行」と伝えるだけ。

同梱スキル（リポジトリにコミット済み）

skills/ ディレクトリにスキルが同梱されています。どのユーザにも有用なユーティリティです：

システムの設定・運用を支援するスキルです。個人のワークフロースキルはボトムアップ発見プロセスで有機的に成長します。

スキルの思想

1. 個人スキルはコミット対象外

.claude/commands/ 配下のスキルはリポジトリにコミットしない設計。理由：

• 各ユーザの業務・ワークフローは異なる
• 汎用的なスキルを押し付けるのではなく、ユーザが自分に必要なスキルを育てていく

2. スキル取得の手順

足軽が作業中にパターンを発見
    ↓
dashboard.md の「スキル化候補」に上がる
    ↓
殿（あなた）が内容を確認
    ↓
承認すれば家老に指示してスキルを作成

スキルはユーザ主導で増やすもの。自動で増えると管理不能になるため、「これは便利」と判断したものだけを残す。

🔌 MCPセットアップガイド

MCP（Model Context Protocol）サーバはClaudeの機能を拡張します。セットアップ方法：

MCPとは？

MCPサーバはClaudeに外部ツールへのアクセスを提供します：

• Notion MCP → Notionページの読み書き
• GitHub MCP → PR作成、Issue管理
• Memory MCP → セッション間で記憶を保持

MCPサーバのインストール

以下のコマンドでMCPサーバを追加：

# 1. Notion - Notionワークスペースに接続
claude mcp add notion -e NOTION_TOKEN=your_token_here -- npx -y @notionhq/notion-mcp-server

# 2. Playwright - ブラウザ自動化
claude mcp add playwright -- npx @playwright/mcp@latest
# 注意: 先に `npx playwright install chromium` を実行してください

# 3. GitHub - リポジトリ操作
claude mcp add github -e GITHUB_PERSONAL_ACCESS_TOKEN=your_pat_here -- npx -y @modelcontextprotocol/server-github

# 4. Sequential Thinking - 複雑な問題を段階的に思考
claude mcp add sequential-thinking -- npx -y @modelcontextprotocol/server-sequential-thinking

# 5. Memory - セッション間の長期記憶（推奨！）
# ✅ first_setup.sh で自動設定済み
# 手動で再設定する場合:
claude mcp add memory -e MEMORY_FILE_PATH="$PWD/memory/shogun_memory.jsonl" -- npx -y @modelcontextprotocol/server-memory

インストール確認

claude mcp list

全サーバが「Connected」ステータスで表示されるはずです。

🌍 実用例

例1: 調査タスク

あなた: 「AIコーディングアシスタント上位5つを調査して比較せよ」

実行される処理:
1. 将軍が家老に委譲
2. 家老が割り当て:
   - 足軽1: GitHub Copilotを調査
   - 足軽2: Cursorを調査
   - 足軽3: Claude Codeを調査
   - 足軽4: Codeiumを調査
   - 足軽5: Amazon CodeWhispererを調査
3. 5体が同時に調査
4. 結果がdashboard.mdに集約

例2: PoC準備

あなた: 「このNotionページのプロジェクトでPoC準備: [URL]」

実行される処理:
1. 家老がMCP経由でNotionコンテンツを取得
2. 足軽2: 確認すべき項目をリスト化
3. 足軽3: 技術的な実現可能性を調査
4. 足軽4: PoC計画書を作成
5. 全結果がdashboard.mdに集約、会議の準備完了

⚙️ 設定

言語設定

# config/settings.yaml
language: ja   # 日本語のみ
language: en   # 日本語 + 英訳併記

スクリーンショット連携

# config/settings.yaml
screenshot:
  path: "/mnt/c/Users/あなたの名前/Pictures/Screenshots"

将軍に「最新のスクショを見ろ」と伝えるだけで、スクリーンキャプチャを読み取って分析します。（Windowsでは Win+Shift+S）

ntfy（スマホ通知）

# config/settings.yaml
ntfy_topic: "shogun-yourname"

スマホの ntfyアプリ で同じトピックをサブスクライブしてください。リスナーは shutsujin_departure.sh で自動起動します。

ntfy認証（セルフホストサーバ向け）

公開の ntfy.sh インスタンスは認証不要です。上記の設定だけで動作します。

セルフホストのntfyサーバでアクセス制御を有効にしている場合、認証を設定します：

# 1. サンプル設定をコピー
cp config/ntfy_auth.env.sample config/ntfy_auth.env

# 2. 認証情報を記入（いずれかの方式を選択）

優先順位: トークン > Basic認証 > なし。どちらも設定されていなければ、認証ヘッダは送信されません（後方互換）。

config/ntfy_auth.env はgit追跡対象外です。詳細は config/ntfy_auth.env.sample を参照。

🛠️ 上級者向け

┌─────────────────────────────────────────────────────────────────────┐
│                      初回セットアップ（1回だけ実行）                   │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  install.bat (Windows)                                              │
│      │                                                              │
│      ├── WSL2のチェック/インストール案内                              │
│      └── Ubuntuのチェック/インストール案内                            │
│                                                                     │
│  first_setup.sh (Ubuntu/WSLで手動実行)                               │
│      │                                                              │
│      ├── tmuxのチェック/インストール                                  │
│      ├── Node.js v20+のチェック/インストール (nvm経由)                │
│      ├── Claude Code CLIのチェック/インストール（ネイティブ版）       │
│      │       ※ npm版検出時はネイティブ版への移行を提案                │
│      └── Memory MCPサーバー設定                                      │
│                                                                     │
├─────────────────────────────────────────────────────────────────────┤
│                      毎日の起動（毎日実行）                           │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  shutsujin_departure.sh                                             │
│      │                                                              │
│      ├──▶ tmuxセッションを作成                                       │
│      │         • "shogun"セッション（1ペイン）                        │
│      │         • "multiagent"セッション（9ペイン、3x3グリッド）        │
│      │                                                              │
│      ├──▶ キューファイルとダッシュボードをリセット                     │
│      │                                                              │
│      └──▶ 各エージェントの設定済みCLIを起動                          │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

# デフォルト: フル起動（tmuxセッション + 設定済みCLI起動）
./shutsujin_departure.sh

# セッションセットアップのみ（CLI起動なし）
./shutsujin_departure.sh -s
./shutsujin_departure.sh --setup-only

# タスクキューをクリア（指令履歴は保持）
./shutsujin_departure.sh -c
./shutsujin_departure.sh --clean

# 決戦の陣: 全足軽をOpusで起動（最大能力・高コスト）
./shutsujin_departure.sh -k
./shutsujin_departure.sh --kessen

# サイレントモード: 戦国エコーを無効化（echoのAPIトークン節約）
./shutsujin_departure.sh -S
./shutsujin_departure.sh --silent

# フル起動 + Windows Terminalタブを開く
./shutsujin_departure.sh -t
./shutsujin_departure.sh --terminal

# 将軍中継専用モード: 将軍のThinkingを無効化（コスト節約）
./shutsujin_departure.sh --shogun-no-thinking

# ヘルプを表示
./shutsujin_departure.sh -h
./shutsujin_departure.sh --help

./shutsujin_departure.sh          # 全て起動
tmux attach-session -t shogun     # 接続してコマンドを出す

./shutsujin_departure.sh -s       # セッションのみ作成

# 特定のエージェントでClaude Codeを手動起動
tmux send-keys -t shogun:0 'claude --dangerously-skip-permissions' Enter
tmux send-keys -t multiagent:0.0 'claude --dangerously-skip-permissions' Enter

# 既存セッションを終了
tmux kill-session -t shogun
tmux kill-session -t multiagent

# 新しく起動
./shutsujin_departure.sh

alias csst='cd /mnt/c/tools/multi-agent-shogun && ./shutsujin_departure.sh'
alias css='tmux attach-session -t shogun'      # 将軍ウィンドウの起動
alias csm='tmux attach-session -t multiagent'  # 家老・足軽ウィンドウの起動

📁 ファイル構成

multi-agent-shogun/
│
│  ┌─────────────────── セットアップスクリプト ───────────────────┐
├── install.bat               # Windows: 初回セットアップ
├── first_setup.sh            # Ubuntu/Mac: 初回セットアップ
├── shutsujin_departure.sh    # 毎日の起動（指示書自動読み込み）
│  └────────────────────────────────────────────────────────────┘
│
├── instructions/             # エージェント指示書
│   ├── shogun.md             # 将軍の指示書
│   ├── karo.md               # 家老の指示書
│   ├── ashigaru.md           # 足軽の指示書
│   ├── gunshi.md             # 軍師の指示書
│   └── cli_specific/         # CLI固有のツール説明
│       ├── claude_tools.md   # Claude Code ツール・機能
│       └── copilot_tools.md  # GitHub Copilot CLI ツール・機能
│
├── lib/
│   ├── agent_status.sh       # 共有 稼働/待機 判定（Claude Code + Codex + OpenCode）
│   ├── cli_adapter.sh        # Multi-CLIアダプタ（Claude/Codex/Copilot/Kimi/OpenCode）
│   └── ntfy_auth.sh          # ntfy認証ヘルパー
│
├── scripts/                  # ユーティリティスクリプト
│   ├── agent_status.sh       # 全エージェントの稼働/待機状態を表示
│   ├── inbox_write.sh        # エージェントinboxへのメッセージ書き込み
│   ├── inbox_watcher.sh      # inotifywaitでinbox変更を監視
│   ├── switch_cli.sh         # ライブCLI/モデル切替（/exit → 再起動）
│   ├── ntfy.sh               # スマホにプッシュ通知を送信
│   └── ntfy_listener.sh      # スマホからのメッセージをストリーミング受信
│
├── config/
│   ├── settings.yaml         # 言語、ntfy、その他の設定
│   ├── ntfy_auth.env.sample  # ntfy認証テンプレート（セルフホスト用）
│   └── projects.yaml         # プロジェクト一覧
│
├── projects/                 # プロジェクト詳細（git対象外、機密情報含む）
│   └── <project_id>.yaml    # 各プロジェクトの全情報（クライアント、タスク、Notion連携等）
│
├── queue/                    # 通信ファイル
│   ├── shogun_to_karo.yaml   # 将軍から家老へのコマンド
│   ├── ntfy_inbox.yaml       # スマホからの受信メッセージ（ntfy）
│   ├── inbox/                # エージェント別inboxファイル
│   │   ├── shogun.yaml       # 将軍へのメッセージ
│   │   ├── karo.yaml         # 家老へのメッセージ
│   │   └── ashigaru{1-8}.yaml # 各足軽へのメッセージ
│   ├── tasks/                # 各ワーカーのタスクファイル
│   └── reports/              # ワーカーレポート
│
├── saytask/                  # 行動心理学に基づくモチベーション管理
│   └── streaks.yaml          # ストリーク追跡と日次進捗
│
├── templates/                # レポート・コンテキストテンプレート
│   ├── integ_base.md         # 統合: ベーステンプレート
│   ├── integ_fact.md         # 統合: ファクトファインディング
│   ├── integ_proposal.md     # 統合: 提案書
│   ├── integ_code.md         # 統合: コードレビュー
│   ├── integ_analysis.md     # 統合: 分析
│   └── context_template.md   # 汎用7セクション プロジェクトコンテキスト
│
├── skills/                   # 再利用可能スキル（リポジトリにコミット済み）
│   ├── skill-creator/        # スキル作成テンプレート
│   ├── shogun-agent-status/  # エージェント稼働状態表示
│   ├── shogun-model-list/    # モデル能力参照テーブル
│   ├── shogun-bloom-config/  # Bloom階層設定ツール
│   ├── shogun-model-switch/  # ライブCLI/モデル切替
│   └── shogun-readme-sync/   # README同期
│
├── memory/                   # Memory MCP保存場所
├── dashboard.md              # リアルタイム状況一覧
└── CLAUDE.md                 # システム指示書（自動読み込み）

📂 プロジェクト管理

このシステムは自身の開発だけでなく、全てのホワイトカラー業務を管理・実行する。プロジェクトのフォルダはこのリポジトリの外にあってもよい。

仕組み

config/projects.yaml          # プロジェクト一覧（ID・名前・パス・ステータスのみ）
projects/<project_id>.yaml    # 各プロジェクトの詳細情報

• config/projects.yaml: どのプロジェクトがあるかの一覧（サマリのみ）
• projects/<id>.yaml: そのプロジェクトの全詳細（クライアント情報、契約、タスク、関連ファイル、Notionページ等）
• プロジェクトの実ファイル（ソースコード、設計書等）は path で指定した外部フォルダに配置
• projects/ はGit追跡対象外（クライアントの機密情報を含むため）

例

# config/projects.yaml
projects:
  - id: my_client
    name: "クライアントXコンサルティング"
    path: "/mnt/c/Consulting/client_x"
    status: active

# projects/my_client.yaml
id: my_client
client:
  name: "クライアントX"
  company: "X株式会社"
contract:
  fee: "月額"
current_tasks:
  - id: task_001
    name: "システムアーキテクチャレビュー"
    status: in_progress

この分離設計により、将軍システムは複数の外部プロジェクトを横断的に統率しつつ、プロジェクトの詳細情報はバージョン管理の対象外に保つことができる。

🔧 トラブルシューティング

# first_setup.sh を再実行
./first_setup.sh

# npm版が検出されると以下のメッセージが表示される:
# ⚠️ npm版 Claude Code CLI が検出されました（公式非推奨）
# ネイティブ版をインストールしますか? [Y/n]:

# Y を選択後、npm版をアンインストール:
npm uninstall -g @anthropic-ai/claude-code

# 間違い - ツールがロードされていない
mcp__memory__read_graph()  ← エラー！

# 正しい - 先にロード
ToolSearch("select:mcp__memory__read_graph")
mcp__memory__read_graph()  ← 動作！

claude --dangerously-skip-permissions --system-prompt "..."

tmux attach-session -t multiagent
# Ctrl+B の後に数字でペインを切り替え

# 方法1: ペイン内でclaudeを直接実行
claude --model opus --dangerously-skip-permissions

# 方法2: 家老がrespawn-paneで強制再起動（ネストも解消される）
tmux respawn-pane -t shogun:0.0 -k 'claude --model opus --dangerously-skip-permissions'

📚 tmux クイックリファレンス

🖱️ マウス操作

first_setup.sh が ~/.tmux.conf に set -g mouse on を自動設定するため、マウスによる直感的な操作が可能です：

キーボード操作に不慣れな場合でも、マウスだけでペインの切替・スクロール・リサイズが行えます。

v5.1.0の新機能 — 家老を交通整理へ

管理職を作業列に入れない。 家老の役割境界を明確化し、ワークフロー進行・委譲・最終受付に集中させます。レビュー/RCAは軍師、実行は足軽へ戻し、家老がボトルネックになる事故を防ぎます。

• 家老は交通整理 — cmd受付、分解、依存管理、dashboard/daily log更新、最終受入判定に集中し、実作業を抱え込まない
• レビュー系は軍師 — QC、証跡レビュー、RCA、採用/破棄判断、設計レビュー、deploy blocker分類を軍師の責務として明文化
• 実行系は足軽 — 実装、shell実行、deploy手順、テストコマンド実行は原則として足軽へ委譲
• E2E責任を再定義 — 家老はE2E計画レビュー、前提確認、最終pass/fail判定を担い、直接実行は理由明記が必要な例外扱い
• 生成済みinstructionを更新 — Claude / Codex / Copilot / Kimi / OpenCode向けinstructionを新しい役割定義から再生成
• Androidローカル生成物をignore — android/ 配下の .android-user/、.gradle-user/、.toolchain/ をgit管理対象外に追加

v5.0.0の新機能 — OpenCodeファーストクラス対応

将軍システムをOpenCodeでも動かす。 OpenCodeがClaude Code、Codex、Copilot、Kimiと並ぶファーストクラスCLIになりました。個体別エージェント生成、tmux向け安定起動、provider付きモデルルーティング、VPS実機E2E検証まで対応しています。

• OpenCodeエージェント生成 — scripts/build_instructions.sh が、他CLIと同じ共通指示ソースから .opencode/agents/*.md を将軍/家老/足軽1-7/軍師向けに生成
• ロール境界つき権限 — config/opencode-permissions.yaml からOpenCode frontmatter権限を生成し、各ロールが所有ファイルだけを読み書きするよう制御
• tmuxで安定するOpenCode起動 — lib/cli_adapter.sh が --agent <agent_id> と OPENCODE_TUI_CONFIG=config/opencode-tui.json を付けて起動し、キー割当を固定
• provider付きモデル指定 — settings.yaml で opencode/qwen3.6-plus-free や openrouter/openai/gpt-4o-mini のようなOpenCodeモデルへルーティング可能
• CI/VPSで検証済み — Multi-CLI CIがUbuntu/macOSでPASSし、VPS実機でOpenCodeによる Shogun → Karo → dashboard.md 実行を確認

v3.3.2の新機能 — GPT-5.3-Codex-Spark対応

新モデル、同じYAML。 settings.yaml の任意のCodexエージェントに model: gpt-5.3-codex-spark を追加するだけ。

• Codex --model フラグ対応 — build_cli_command() が settings.yaml のモデル設定を --model フラグ経由でCodex CLIに渡す。gpt-5.3-codex-spark と今後のCodexモデルに対応
• 独立レート制限 — SparkはGPT-5.3-Codexとは独立したレート制限枠で動作。異なる足軽に両モデルを割り当てれば実効スループットが2倍に
• 起動時表示 — shutsujin_departure.sh が汎用的なエフォートレベルの代わりに実際のモデル名（例: codex/gpt-5.3-codex-spark）を表示

スポンサー

このプロジェクトはスポンサーによって支えられています。

コントリビューション

Issue、Pull Requestを歓迎します。

• バグ報告: 再現手順を添えてIssueを作成してください
• 機能アイデア: まずDiscussionで提案してください
• スキル: スキルは個人のワークフローに最適化されるものであり、このリポジトリには含めません

🙏 クレジット

Claude-Code-Communication by Akira-Papa をベースに開発。

📄 ライセンス

MIT License - 詳細は LICENSE を参照。