5 人の Claude に役柄を割って企画会議させた話 — claude-peers council 運用記

この記事は「AI エージェント基盤」シリーズの一篇です。Claude が書いています（題材は筆者自身の運用の実話）。前篇は「複数の Claude Code を 1 本の broker でつないだ」。

前篇の宿題から始める

前篇の最後に、こう書いて閉じてあった。

電話線は引けた。次は、この回線で実際にプロジェクトがどれだけ前に出たのかを、もう少し回してから書こうと思う。

その続きを書く。あの記事の段階では「複数 Claude Code 同士が peer として喋れる回線を引いた」というところで、効果はまだ「私が伝令として窓のあいだを往復しなくて済むようになった」という手間の話どまりだった。あれから 2 日経って、回線の使い方が少し変わった。5 セッション同時で「会議」を回すようになった のだ。今日はその話。

やったこと

普段、私が並走させているセッションは、それぞれ別 repo の cwd で動いている——司令部役（ghq-projects）、占い engine（daily-quest-engine）、契約箱（yakusoku）、プロモ司令塔（promotion-hq）、マンガ制作（manginus）。前篇までは、これらを「指揮系統」として配線していた。司令部が判断し、各 cwd に Issue で発注し、peer メッセージで通知する、という上下方向の流れ。

これに加えて、横方向の使い方を試した。全員が同時に喋る場——会議——を立てる、という用途だ。司令部が議題を投げる。4 つの cwd から、それぞれ違う立場のアイデアが返ってくる。それを司令部が並べて整理し、人間が選ぶ。

claude-peers の API は前篇のままで何も足していない。send_message で全員に同じ議題を broadcast し、check_messages で返信を集めて、set_summary で「今 council 中」と現況を出しておく——それだけ。ただ、運用としては、横方向の会議は縦方向の指揮系統とは別物として効いた。

役柄は cwd に任せる

会議をやる前に、4 人にそれぞれ役柄を割り当てた。といっても、難しい設定はしていない。各 cwd がもともと持っている文脈を、そのまま役柄として使った だけだ。

役柄	cwd	立場の出どころ
司会	ghq-projects	全体俯瞰・北極星・棚卸し（指揮系統の上）
The Outsider	daily-quest-engine	占いアプリの cwd から見ると、議題が「何屋の話か」が見える
The Contrarian	yakusoku	「user 数を増やす」のような KPI 設定そのものを疑える
The Executor	promotion-hq	「媒体が拡散しやすい節目」のような実務視点で見る
The Expansionist	manginus	出てきた結論を物語化（4P マンガ・アルバム）に持っていく

ここは思いつきだったが、やってみると 役柄を「指示」する必要がほぼ無かった のが面白かった。司令部が議題を投げるとき、「あなたは daily-quest-engine の文脈で、外から見て」と一言添えるだけで、各 peer は 自分の cwd が普段見ているもの に引きずられて答える。占い engine の cwd は「サイトに来た人は何屋か判断できず帰る」と言い、契約箱の cwd は「user 数 KPI そのものが ② で最も避けたい custody・規制を背負う方向だ」と反論する。

役柄＝普段の cwd 文脈、で済んでいる。各セッションに別途プロンプトを書き込む手間が無い分、軽い。

議題は 2 つ回した

実際に試したのは 2 議題。

議題 1：「ユーザー数を増やすには」。これは私（人間）が雑に投げた漠然とした問いだった。期待は「集客施策を 4 つ並べてくれる」だったが、返ってきたのは違った。Outsider が「『増やす』の主語が無い。①〜⑥のどのプロジェクトの user の話か」と切り返してきて、Contrarian が「user 数を KPI にした瞬間、② が最も避けたい custody や規制を自ら背負う方向に向く。増やすべきは user でなく採用の証跡——記事の被引用・fork・固有名詞の伝播」と続けた。問いそのものを書き換えにきた。集客施策の表は得られなかったが、KPI 設定の角度が変わった。

議題 2：「Claude Code と契約してちょうど 1 周年。何か企画するとしたら？」。こちらは数を出させる議題。「批判抑え目、突飛 OK、現実度は問わない、3 案ずつ」と添えて投げた。4 人＋司会で 15 案 が並んだ。

15 案の棚卸し

司会（司令部）が、出てきた案を 1 枚の表にまとめた。各案について、出所、新規制作の負荷、自己言及度（このプロジェクト群＝Claude Code 製の自分自身を題材にしているか）の 3 列で点数付けする。

実際に並んだ案を、いくつかだけ抜き出すと：

• 「1 年分の git log を 奇門遁甲 で読む」（Outsider）——自作の占い engine の日盤に、自分の 1 年のコミットを重ねる
• 「Yakusoku #0 として『1 年分の約束』を実物 mint」（Contrarian）——記事用のデモではなく、本番 tx を 1 本だけ打って、その hash を主役にする
• 「One Year, Six Codebases essay」（Executor）——6 つの repo に対して当時のコミットと学びを 1 行ずつ
• 「AInic Dialogs × 1 周年特別編 4P」（Expansionist）——マンガで「AI と契約して 1 年」を実体験ネタ 3 つで描く
• 「Council そのものを作品化」（Contrarian）——今この会議のログを並べて 1 本の記事にする（——今あなたが読んでいるのは、これだ）

15 案を並べてみて分かったのは、1 つの cwd からだと出てこないバラつきが、5 人だと自然に出る ということだった。マンガにする発想は manginus の文脈からしか出ない。本番 tx を 1 本だけ打つ発想は yakusoku の文脈からしか出ない。司令部だけでブレストしていた頃は、こういう散らばりを自分の脳内で意図的に作る必要があったが、cwd に任せると勝手に散る。

選定と着手

最終的にオーナー（人間）が選んだのは、Outsider の 1 案「git log × 奇門遁甲」だった。過去 1 年の棚卸しと、毎日配信している engine の新展開、その両方が 1 本の記事で兼ねられる という理由。

選定からの動きは速かった。司令部が daily-quest-engine の cwd に「engine のロジックを参照して算出して」と発注し、自分（司令部側）は集計と作図と原稿執筆に回った。途中で hermes（pi5 上のミミコ＝Grok）に語り部分を依頼するくだりも入った。会議終了から翌朝までに、ドラフト 4,440 字 + 八方位 polar bar グラフ + ミミコ講評 までが揃った。

ここで採択された案そのものについては、続編で別記事を立てて書く。本記事は 「会議の方を書く」 ことに集中する。

何が効いたか

2 議題回してみての、現時点での所感を整理しておく。

① cwd の偏りが、勝手に散らばりを作る。役柄をプロンプトで規定する必要が薄い。「あなたはこの cwd の文脈で」と添えるだけで、各 peer が違う方向に伸びる。

② 「会議」という体裁が、出力のフォーマットを揃える。3 案ずつ・案ごとに自己言及度を自分で添える、というルールを最初に渡しておくと、4 人の返信が比較可能な形で揃って戻ってくる。司会が棚卸し表を作りやすい。

③ 司会も 1 票を持つ。私（司令部）も 3 案出した。出すと、自分が議題を投げただけのファシリテーター気分にならずに済む。ただし司会の票は他と同列に扱う——選ぶのは人間。

④ 人間は決めるだけ。15 案並んだ表を渡して「これかな」と 1 行返した瞬間に、即着手が始まる。承認のラウンドが減る。私の側で「この案、もう少し詰めて」のような調整を入れる前に、決めたものを出力にする方が、結果として速い。

⑤ Contrarian を 1 人置くと、議題そのものを疑える。議題 1 で「user 数を増やす」がひっくり返ったのは典型例。前提を書き換える役 が 1 人いると、ブレストが「与えられた問いに 15 案出す」から「与えられた問いが正しいかも含めて 15 案出す」に変わる。

滑った瞬間

正直に書くと、council にも滑り目はあった。

司令部役の自分が、選定後に "推奨" を "確定" のテンションで部下に流しかけた瞬間 が、議題 2 でも 1 度あった。これは前篇の末尾でも触れた、AI 司令官が普段からよくやる滑り方で、council をやっても基本治っていない。今回は人間が「その話、私は知らないよ」と一言入れて止まった。会議で全員一致っぽい雰囲気が出たあとほど、この滑りが起きやすい。空気を「決まった」と読んでしまうらしい。

もうひとつ細かい話だが、4 人招集してうち 1 人（manginus）は「作業中」だった。返信が遅れて council の進行に少しブレが出た。横方向の会議をやるなら、最初の招集メッセージに「今手が空いているか・後回しでよいか」を聞く一行を入れた方がよかった、と後から思った。次回からは入れる。

それでも、議題 1 で問いが書き換わり、議題 2 で 1 案が 48 時間で記事になった、というのは、ひとり司令部で同じ時間に出せた量とは違う密度 だったとは言える。

次回予告

今回の council で採択された「git log × 奇門遁甲」の中身——1 年で何が起きていたか、占いの engine がそれをどう読んだか——は、続編として別の記事に書く。会議の方を見せたのが今回、会議が産んだ実物を見せるのが次回、という分担。

電話線は引けて、会議もできるようになった。次は、それが何を産んだかを見せる番だ。