この記事は 2/6 付でアップデートされた Agent Teams に乗っ取られました・・・
備忘として残していますが、現在の neko-pm は Agent Teams ベースの v3 に移行済みです。
AI記事は寝かせてはダメ。
はじめに
初めまして！株式会社Dirbatoの田中です！
普段はDatadogを用いたSREとして、日々運用設計やオブザーバビリティ基盤の構築をやっています！
そして普段からClaude CodeをAIエージェントとして業務に組み込んでおり、こんな感じで働いてもらっています。
- SRE: SLI/SLO設計、アラート設計
- Datadog: ダッシュボード作成、モニター設定
- 資料: 運用設計書、PowerPoint作成
つまり既にAIエージェント1体と一緒に仕事してる状態です。この記事では、そこからさらに踏み込んでマルチエージェントシステムを作って業務改善してみた話を共有します！
AIは初心者ですので生暖かく見守ってください🍺
本記事の構成発想は下記紹介の記事を参考にしていますが、コードや文書は引用の範囲内とし、新規で書き起こしをしております。
元記事に掲載されているコードは著作権者に帰属します。
引用元記事のエンジニアの皆様によってこの記事は成り立っております！
きっかけ
いつもの通り、Xを徘徊していると・・・
「すてきやん？！」
ただ、Claude Code超初心者としては最初から設計・実装を全部やるのは大変。
発想の転換
「Claude Codeに作ってもらえばいいのでは？」
考えてみれば
- Claude Codeはシェルスクリプトを書けます
- Markdownの指示書も書けます
- 自分自身の拡張ができます
つまり 「マルチエージェントシステム作って」で作れるはずです。
※なお、この発想に至るまで5秒
実際にやってみた
私の視点：PM/PL/メンバー構造 × 猫キャラ
元記事では「将軍・家老・足軽」という戦国メタファーでしたが、私はこう捉え直しました。
せっかくなら可愛いほうが
| 元記事 | 私の解釈 | neko-pm |
|---|---|---|
| 将軍 | PM（プロジェクトマネージャー） | ボスねこ 🐱 |
| 家老 | PL（プロジェクトリーダー） | 番猫 🐱 |
| 足軽 | メンバー | 子猫 🐱 |
普段の仕事で使い慣れた構造 + 猫キャラで、「誰が何を担当すべきか」がクリアになります。この構造を指示して、Claude Codeに作ってもらいます。
最初の指示
マルチエージェントPMシステムを作りたい。
参考: https://zenn.dev/shio_shoppaize/articles/5fee11d03a11a1
構成:
- PM役（全体統括）
- PL役（タスク管理）
- メンバー役（実行部隊）
tmuxで並列実行、YAMLで通信したい。
あと、猫キャラで語尾に「にゃ〜」をつけて。
Claude Codeの動き
元記事を読み込み、アーキテクチャを理解した上で、必要なファイルを次々と生成してくれました。
生成されたファイル構成
neko-pm/
├── shuugou.sh # 集合（起動）スクリプト
├── neru.sh # 寝る（終了）スクリプト
├── nawabari.md # 縄張り（状況板）
├── instructions/ # 役職別指示書
│ ├── boss-cat.md # ボスねこ（PM）
│ ├── guard-cat.md # 番猫（PL）
│ ├── kitten.md # 子猫（メンバー・汎用）
│ └── elder-cat.md # 長老猫（参謀・オンデマンド）
├── config/
│ └── settings.yaml # 設定ファイル
└── queue/ # 通信キュー
├── boss_to_guard.yaml
├── tasks/
└── reports/
動く・・・動くぞ・・・コイツ！
./neko-pm/shuugou.sh -w 3
tmuxで5つのペインが開き、それぞれにClaude Codeが起動。ボスねこがopus、番猫と子猫がsonnetで動作しています。
そんな装備で大丈夫か？ — 改善フェーズ
「大丈夫だ、問題ない」
...と思っていた時期が私にもありました。
ここまでは、ぶっちゃけ 「模倣」 に過ぎません。元記事の構成をClaude Codeに再現させただけです。動きましたが、これでは元記事の焼き直しでしかありません。
「一番いいのを頼む」 — カスタマイズします。
そうなんです。コピーしただけでは意味がありません。自分のニーズに合わせて改造してこそ価値があるのです。
デビルズアドボケイトで自己批判させる
基本形ができた後、こう依頼しました。
デビルズアドボケイト・テストして
これまでのやり方振り返ってみて
メリデメ分析ではありません。あえて批判的な視点で検証させるのです。
すると、Claude Codeが自分で作ったシステムを容赦なく批判し始めました。
Claude Codeの自己批判（容赦ない）
コスト効率への疑問
5つのClaude Codeインスタンスを同時起動。今回の「仕様書3つ作成」タスクに本当に必要だったか？
通信オーバーヘッド
YAML + send-keys + ポーリング。番猫が縄張り更新する度にトークン消費。
メタファーの限界
子猫は専門固定（SRE/Datadog/資料）→ 汎用タスクに対応しにくい
成果物の品質検証
「完了」判定が自己申告。誰がレビューした？
痛いところを突いてきます。お前が作ったんだろうが。
でも改善案も出してくれます。
評価フレームワーク：メリデメをやめる
ここで私がこだわったのは、メリデメ分析をやめることです。
メリデメって結局「メリットの裏返しがデメリット」になりがちで、判断基準がブレます。代わりにこういうフレームワークを使いました：
1. 論点に対する選択肢を出す
2. 論理構成を持つ評価項目を作る
3. 目指す方向性を基準に評価する
Claude Codeにもこれを伝えて、改善案を整理させました。
改善1: 長老猫の導入
課題: 番猫（sonnet）だけでは品質判断が不安
選択肢:
| 案 | 内容 |
|---|---|
| A | 番猫をopusに昇格 |
| B | 長老猫（opus）をオンデマンド召喚 |
| C | ハイブリッド（普段sonnet、迷ったらopus呼び出し） |
私: 「案C面白そうだなぁ」
コンテキスト圧縮が目的だったので、常駐opusより「必要な時だけ召喚」の方が理にかなっています。
結果: 長老猫システムが実装されました。普段はsonnetで軽量に動き、判断に迷った時だけopusの長老猫を召喚する仕組みです。
改善2: なんでも使えるエージェントシステムへ
最初のシステムでは、冒頭で紹介した普段の業務（SRE・Datadog・資料作成）をそのまま子猫の専門として固定していました。SRE猫、Datadog猫、資料猫、みたいな感じです。
課題: でも、子猫が専門固定だとそれ以外のタスクに対応できない
せっかくマルチエージェントシステムを作ったのに、普段の業務3つにしか使えないのでは意味がありません。どんなタスクでも投げられるシステムにしたい。
まず 目指す方向性の優先順位 を決めました。
柔軟性 > スケーラビリティ > コンテキスト効率 > 運用シンプル化
この基準で各論点を評価します。
| 論点 | 選択肢 | 判断 |
|---|---|---|
| 専門性 | 完全汎用 / 一部専門 / 専門固定 | 完全汎用（柔軟性重視） |
| スキルロード | 起動時固定 / タスク時指定 / 自己判断 | タスク時指定（柔軟+効率） |
| 子猫の数 | 固定3匹 / 可変 / 動的生成 | 可変（スケーラビリティ） |
私: 「ok」
それだけです。方向性さえ決めれば、Claude Codeが実装してくれます。
結果: 子猫は汎用化され、タスクに応じてスキルを動的にロードする仕組みになりました。必要な子猫の数も自由に変えられます。
# 子猫3匹で集合
./neko-pm/shuugou.sh -w 3
# 子猫5匹で集合
./neko-pm/shuugou.sh -w 5
SRE設計だろうがコードレビューだろうがスライド作成だろうが、同じシステムで何でも対応できるようになりました。
完成したアーキテクチャ
ご主人（私）
│ 指令
▼
ボスねこ（opus）──────┐
│ │ 相談
▼ ▼
番猫（sonnet）────→ 長老猫（opus・オンデマンド）
│
├── 子猫1（sonnet・汎用）
├── 子猫2（sonnet・汎用）
└── 子猫3（sonnet・汎用）
特徴
- ボスねこ（PM）: opus、全体方針決定
- 番猫（PL）: sonnet、タスク分解・進捗管理・レビュー
- 長老猫: opus、オンデマンド召喚（コンテキスト圧縮）
- 子猫: sonnet、汎用（スキルはタスク時に動的ロード）
見せてもらおうか、neko-pmの性能とやらを
せっかくなので、neko-pmの動作確認も兼ねて新しいツールを作ってみることにしました。
参考にしたのはこちら：
https://github.com/minorun365/marp-agent
※上記のハンズオン資料大変参考にしております。
こちらを参考に、PPTX形式で出力して後から編集したい ということを叶えるプランをコンサルスライドマンとして猫ちゃんたちに考えてもらいました！
# 集合にゃ〜
./neko-pm/shuugou.sh -w 3
# ボスねこセッションに接続
tmux attach -t boss
ボスねこに作戦を伝えると
- ボスねこがYAMLで作戦命令を作成
- 番猫に通知（send-keys 2回ルール厳守）
- 番猫がタスク分解して子猫に配分
- 子猫が並列で作業開始
- 完了報告が番猫に集まる
- 縄張り（nawabari.md）が更新される
私がやったこと: ボスねこに「これやってにゃ」と言っただけです。
※完全に理解した（してない）
学び
1. Claude Codeは自己拡張できる
「マルチエージェントシステム作って」で本当に作れました。なにそれこわい。
Claude Codeは自分自身の開発環境を拡張する能力があります。
2. 対話的に改善できる
作って → 批判して → 改善案出して → 選んで → 実装して
このサイクルを回すだけで、システムがどんどん良くなります。
3. 人間は判断するだけ
元記事では「AIが設計・実装を担い、人間は判断に集中する未来」が語られています。
方針を選ぶだけで、設計も実装もClaude Codeがやってくれます。
まとめ
- shio_shoppaizeさんの記事に感謝。あの記事がなければこのシステムは生まれませんでした
- 「難しそう」→「作ってもらえばいい」の発想。Claude Codeは自分の拡張を自分で作れます
- Claude Code × Claude Code = 可能性の獣。マルチエージェントで並列作業、さらにそのシステム自体もClaude Codeが改善していきます
- オリジナリティは猫が担当。コンセプトは参考にしつつ、命名・キャラ・実装は全てオリジナルにゃ〜 🐱
次回予告：猫だけじゃ足りなくなってきた
ここまでClaude Code同士で組ませてきましたが、世の中にはAIエージェントが他にもいます。
Gemini CLI（Google）、Codex CLI（OpenAI）— こいつらも猫の組織に引き入れたらどうなるか？
Claude Codeが指揮を執り、Geminiがリサーチし、Codexがレビューする。異なるAIベンダーのエージェントが1つのチームで協働する世界、現在絶賛模索中です。
猫の組織に、キツネとタヌキとフクロウが加わります。
次の記事でお届け予定なので、お楽しみに。
リポジトリ
参考
- Claude Codeで『AI部下10人』を作ったら... - 元ネタ、リスペクト
-
minorun365/marp-agent - スライド生成の参考（神）
参考にさせていただきましたminorun365/marp-agentより（PPTX出力対応等の）改変およびコードの新規書き起こしを行っています。こちらに関しては私のリポジトリにはコードとして存在いたしません。