3/19

2026

将軍マルチエージェントをやめた — Claude Code単体運用への移行と、そこで得たもの

#Claude Code#マルチエージェント#AI#Notion#移行#ECC

将軍マルチエージェントをやめた — Claude Code単体運用への移行と、そこで得たもの

前回の記事で「将軍・家老・足軽」の階層型マルチエージェントシステムを紹介した。Notionからスマホで指示するだけでアプリ開発が回る仕組みに感動した、という話。

あれから数週間。将軍システムをやめて、Claude Code単体運用に移行した。

やめた理由、移行でやったこと、移行後の比較を書く。

なぜやめたのか

将軍システムは楽しかった。でも運用していくうちに「これ、本当に必要か？」と思う場面が増えた。

1. コンテキスト管理が重い

将軍システムは4層のコンテキスト管理（CLAUDE.md / instructions/ / context/ / Memory MCP + YAML Queue）を持っていた。/clear のたびに「自分のIDを確認 → 指示書を読む → メモリ復元 → YAML状態復元 → 作業開始」というSession Start手順を踏む。

これが意外と脆い。復元に失敗して文脈が飛ぶこともあるし、YAML Queueのパースエラーでタスクが消えることもあった。仕組みの維持自体にコストがかかっていた。

2. 足軽の手が空く

前回の記事でも書いたが、足軽は2人で十分だった。タスクの依存関係やレビュー待ちがあるので、並列で走らせても手が空いてしまう。将軍→家老→足軽と伝言ゲームをするより、1つのClaude Codeに直接頼んだほうが速いケースが大半だった。

3. Claude Codeの進化

Claude Code自体がかなり進化した。特に大きいのは:

Agent tool（サブエージェント）: Claude Code内部で並列にエージェントを起動できるようになった。足軽をtmuxで分けていた必要性が薄くなった
ECC（Everything Claude Code）プラグイン: 18のエージェント、90以上のスキルが使える。planner、code-reviewer、tdd-guideなど、家老や足軽がやっていたことを1セッション内でこなせる
hooks: SessionStartフックで自動処理を走らせられる。将軍のSession Start手順をシェルスクリプトに置き換えられた

つまりClaude Code単体で「将軍+家老+足軽」の役割を1セッションでまかなえるようになった。

4. コスト

将軍・家老・足軽が常にコンテキストを消費する。ポーリングのたびに「新しいタスクある？」とLLMが考える。やっていることの大半はオーバーヘッドだった。

⚡ 将軍システムの問題は「マルチエージェントが不要だった」ではなく「Claude Code単体がマルチエージェントに追いついた」ということ。半月前には必要だった仕組みが、ツールの進化で不要になった。

移行後のアーキテクチャ

Before: 将軍システム

Notion DB
  ↓ 30秒ポーリング（LLMコスト発生）
将軍（Claude Code #1）
  ↓ cmd YAML
家老（Claude Code #2）
  ↓ subtask YAML
足軽1（Claude Code #3） + 足軽2（Claude Code #4）
  ↓ inbox/outbox YAML
レポート → Notion返信

4プロセス常駐（1プロジェクトあたり）
YAML Queue（cmd / subtask / report）でタスク管理
Memory MCPで記憶永続化
将軍専用のinstructions/で行動制御

After: Claude Code単体 + 軽量ポーリング

Notion DB
  ↓ 30秒ポーリング（bashスクリプト、LLMコスト0）
notion_poller.sh
  ↓ Projectラベルでルーティング
  ├── "PlayTime"  → claude-playtime (tmux session)
  ├── "miyashiapp" → claude-miyashiapp (tmux session)
  ├── "support"   → claude-support (tmux session)
  └── !コマンド   → poller直接実行（LLMコスト0）

1プロセス（プロジェクトあたり）+ 軽量bashポーリング
Agent toolで必要に応じてサブエージェントを内部起動
ECCプラグインのスキルで専門タスクを処理
~/.claude/commands/と~/.claude/rules/で知識共有

移行でやったこと

移行作業自体もClaude Codeにやってもらった。以下が主な作業。

1. 用語の汎用化

将軍システムの用語（殿・将軍・家老・足軽）がdocsやskillsに散らばっていた。これを汎用的なAI用語に置き換えた。

旧用語	新用語
殿（Tono）	オーナー / ユーザー
将軍（Shogun）	オーケストレーター
家老（Karo）	マネージャー
足軽（Ashigaru）	ワーカー

23ファイル、66箇所を一括置換。ただしゲーム内コンテンツ（「神殿」など）やファイルパス（DerivedData-ashigaru1）は除外した。

2. Notionポーリングの軽量化

将軍システムのポーリングは将軍プロセス（Claude Code）自身がやっていたのでLLMコストが発生していた。新システムではbashスクリプト（notion_poller.sh）がポーリングし、メッセージ検出時のみtmux経由でClaude Codeに送信する。ポーリング自体のLLMコストはゼロになった。

さらに ! プレフィックスのスーパーバイザーコマンドを追加した。!restart claude-playtime のようなシステム管理コマンドはポーリングスクリプトが直接実行するので、Claude Codeがスタックしていてもリモートから介入できる。

3. claude-configリポの作成

将軍システムでは知識が各プロジェクトのinstructions/やCLAUDE.mdに分散していた。移行を機にclaude-configリポを作り、プロジェクト横断の知識を一元管理するようにした。

claude-config/
├── scripts/         ← notion_poller.sh等
├── commands/        ← /keychain-unlock等のスラッシュコマンド
├── skills/          ← ECCスキル定義
├── rules/common/    ← 全プロジェクト共通ルール
└── docs/            ← TestFlight配信手順等

~/.claude/rules/common/ に置いたルールは全プロジェクトで自動的に読み込まれる。ブランチ戦略やコーディングスタイルを一箇所で管理できるようになった。

4. commands/の移植

意外と見落としがちだったのが .claude/commands/。将軍プロジェクトにはkeychain-unlock、incident-review、sns-loginなど便利なスラッシュコマンドがあったが、プロジェクトローカルのcommandsだったので他プロジェクトからは見えなかった。

これを ~/.claude/commands/（ユーザーレベル）に移植して全プロジェクトで使えるようにした。移植時にハードコードされていたシークレットを発見して、macOS Keychainに移動させた。

⚠️ 移植作業ではシークレットのスキャンが必須。将軍システムのコマンドファイルにfastlane matchのパスワードがハードコードされていた。git管理リポにそのままコピーしたら事故になるところだった。

5. シークレット管理の統一

将軍システムではシークレットがコマンドファイルにハードコードされていたり、.notion_envに入っていたり、バラバラだった。

移行を機にmacOS Keychainに統一した。.zshrcでシェル起動時にKeychainから環境変数に設定する。

# ~/.zshrc
export MATCH_PASSWORD=$(security find-generic-password -a match -s MATCH_PASSWORD -w 2>/dev/null)
export NETLIFY_PERSONAL_ACCESS_TOKEN=$(security find-generic-password -a netlify -s NETLIFY_PERSONAL_ACCESS_TOKEN -w 2>/dev/null)

CIではGitHub Secretsから同じ環境変数が設定される。ローカルとCIで同じインターフェースになった。

メリット・デメリット比較

メリット

観点	詳細
コスト削減	ポーリングのLLMコスト0。常駐プロセス数が4→1に。$200プランでも余裕が出た
シンプルさ	YAML Queue、inbox/outbox、Memory MCPが不要に。bashスクリプト+tmuxだけ
安定性	伝言ゲームのパースエラー、復元失敗がなくなった。プロセスが1つなのでスタックしにくい
保守コスト	将軍固有の仕組み（instructions、Session Start手順）の維持が不要に
知識の一元管理	claude-configリポで全プロジェクト共通の知識を管理。rules/common/は自動読み込み
リモート介入	!コマンドでLLMコスト0の直接介入。スタック時もNotionから復旧可能

デメリット

観点	詳細
真の並列性の低下	将軍システムでは足軽2人が物理的に別プロセスで同時実行できた。Agent toolのサブエージェントは便利だが、同一コンテキスト内での並列なのでtmux並列ほどの独立性はない
ロール分離の喪失	「将軍は戦略、家老は管理、足軽は実装」という明確な責務分離がなくなった。1セッションが全部やるので、たまに「レビューする側とされる側が同じ」になる
スケーラビリティ	4プロジェクト同時運用は将軍システムのほうが得意だった。現システムはプロジェクトごとにtmuxセッションを立てるので、管理は手動寄り
楽しさ	将軍・家老・足軽が連携して動く様子は見ていて楽しかった。1セッションで淡々とこなすのは効率的だが、ロマンは薄れた

📝 「真の並列性」が必要な場面（大規模リファクタリング、複数機能の同時開発）は実際にはそこまで多くない。大半のタスクはAgent toolの内部並列で事足りる。

残したもの、捨てたもの

残したもの

Notion連携: 30秒ポーリング+プロジェクト別ディスパッチの仕組みはそのまま。bashスクリプトに置き換えただけ
supportプロセス: claude-supportとして常駐。リモートからのシステム管理を担当
worktree運用: 並列作業時のgit worktreeはそのまま使用
ブランチ戦略: matome → develop → master のフローは変更なし
docs/による知識永続化: 各プロジェクトのdocs/はそのまま活用

捨てたもの

YAML Queue: cmd / subtask / reportのYAMLファイル管理。Agent toolとECCスキルで代替
inbox/outbox通信: ファイルベースのエージェント間通信。1セッション内で完結するので不要
Memory MCP: Claude Codeのメモリシステム（memory/ディレクトリ）で代替
instructions/: ロール別の指示書。~/.claude/rules/common/とCLAUDE.mdに統合
将軍用語: 殿・将軍・家老・足軽 → 汎用的なAI用語に置換

移行して思ったこと

将軍システムを作ったのは3週間前。たった3週間でツールが進化して「あの仕組み要らなかったな」と思えるのがAI開発の面白いところであり怖いところでもある。

ただ、将軍システムを作った経験は無駄ではなかった。エージェント間通信、コンテキスト永続化、リモート介入、シークレット管理 — これらの設計課題に向き合ったからこそ、Claude Code単体で「何が必要で何が不要か」を判断できた。

将軍システムの教訓を一言でまとめるなら:

💡 マルチエージェントは組織設計。 ツールが進化したら組織も変わる。固執せずに、その時点で最もシンプルな構成を選ぶ。

現時点ではClaude Code単体+軽量ポーリングが最適解。でも来月にはまた別の最適解があるかもしれない。そのときはまた移行すればいい。

仕組みを作るのが好きな人間にとって、この速度感は最高に楽しい。