CODE IN TOKYO

Claude Codeを5つ立ち上げたら、ローカルに小さな開発組織ができた

最近、Claude Codeでクロスセッションができるようになった。

要するに、複数のClaude Codeを同時に立ち上げ、それぞれ別の役割を持たせながら、必要に応じてセッション間でやり取りさせることができる。

以前からClaude Codeを複数起動すること自体はやっていた。ただ、基本的には人間である私がそれぞれに指示を出し、必要な情報を別セッションへ持っていく運用だった。

その前には、複数のAIをまとめて動かすオーケストレーションツールも試している。

発想としては単純で、司令塔となるAIに仕事を渡せば、そこから複数のAIへ作業を振り分け、AI同士で相談しながら勝手に開発を進めてくれる。うまくいけば、人間は最初に指示を出して最後に成果物を確認するだけで済む。

ところが実際に試してみると、あまり効率が良くなかった。

AIからAIへ指示が渡るたびに情報が少しずつ変わり、伝言ゲームのようになる。さらに同じ背景情報を複数のAIが何度も読み書きするため、トークン消費もかなり大きい。

そこで結局、

人間が直接それぞれのAIに指示する。AI同士の通信はプロンプトなどを使って人間が代行。

という、かなり現実的なところに落ち着いた。

ところが最近、Claude Codeでクロスセッションが使えるようになったことで、その構成も少しずつ変わってきた。

今、実際にやっているスタイルは、単にClaude Codeを複数立ち上げるのではなく、自分のPCの中に小さな開発組織を作ってしまう方法である。

少し紹介してみたい。

5つのClaude Codeを立ち上げる

ここからは説明しやすいように、架空の動画配信サービスを例にしてみる。もちろん、実際に私が担当している案件ではない。

この架空のシステムは、

の3つに分かれ、それぞれが別のGitリポジトリで管理されているとする。

私が担当するのは会員管理だが、当然ながら会員管理だけを見て開発できるわけではない。「このコンテンツは視聴可能なのか」「この会員の課金状態はどうなっているのか」といった具合に、他システムとの仕様確認が頻繁に発生する。

そこでローカルでClaude Codeを5つ立ち上げる。

会員管理
├─ 開発セッション
├─ タスク管理セッション
└─ レフェリーセッション

コンテンツ管理
└─ コンテンツ管理セッション

請求管理
└─ 請求管理セッション

全部Claude Codeだが、役割はまったく違う。

開発するAIと、仕事を整理するAIを分ける

まず中心になるのが「開発セッション」。

これは普通のClaude Codeで、実際にコードを書いたり、テストしたり、技術調査をしたりする。

その横に「タスク管理セッション」を置いている。こちらはコードを書くためではない。WBSを更新したり、作業状況を整理したり、外部やチームに提出する資料を作ったりする。

以前はこういう仕事も全部同じClaude Codeにやらせていた。

しかし長く使っていると、「この仕様について考えてくれ」「このコードを直してくれ」「ところでWBSを更新してくれ」「会議用の説明資料も作ってくれ」という情報が一つのコンテキストに全部入っていく。

人間で言えば、プログラマーにコードを書かせながら、横から進捗管理と議事録とPowerPointまで同時に頼んでいるようなものだ。

だったら最初から分ければいい。

開発者には開発だけをさせ、PMには管理だけをさせる。AIだから一人二役にする必要はない。

判断に困ったら「レフェリー」に丸投げする

もう一つ置いているのがレフェリーセッションだ。

ここには、その時使える中で最も賢いモデルを割り当てる。私の場合ならFableのような最上位モデルを使う。

普段はあまり仕事をさせない。

設計判断が割れた、開発セッションと相手側セッションの主張が食い違った、何かがおかしいが原因が分からない。そういう時だけ呼び出す。

そして、

「よく分からなくなったので、あとは調べて判断してくれ」

と丸投げする。

レフェリー自身が必要に応じて各セッションへ問い合わせ、双方の主張やコードを確認した上で判断する。

以前なら私自身が「会員管理はこう言っている」「でも請求管理はこう言っている」「この仕様書にはこう書いてある」と情報を集めて、一つのAIに説明し直していた。

ここだけはセッション間通信を積極的に使う。

私は最後にレフェリーの判断を確認すればいい。

面白いのは「相手方のAI」を自分のPCに置くこと

この構成で一番面白いと思っているのが、コンテンツ管理と請求管理のClaude Codeだ。

この2つは、自分が開発している会員管理とは完全に別のディレクトリで起動する。

ここはかなり重要だと思っている。

同じ環境でClaude Codeを動かしていると、こちら側のCLAUDE.mdや設計思想、過去のやり取り、ローカルルールなどを知ってしまう。

するとAIは賢いので、こちらの意図まで理解してしまう。

それが普段の開発では便利なのだが、相手システムの役をやらせる場合にはむしろ邪魔になる。

たとえば私が「このAPIなら当然この値を返すだろう」と思っている。その前提を相手側AIまで知っていたら、「まあ、そういう意図なんでしょう」とこちらに寄せた回答をする可能性がある。

それでは壁打ちにならない。

だから別フォルダでClaude Codeを起動し、コンテンツ管理ならコンテンツ管理のコードとルールだけを基本的な世界として持たせる。

こちら側の常識を知らないAIにするわけだ。

ただし、お互いのソースコードそのものはGit経由で読めるようにしておく。

つまり、

「こちらの事情には忖度しない。しかし必要ならこちらのコードを調査することはできる」

という状態を作る。

これが、かなり本物の別チームに近い。

鍵になるのは、実はADR

この構成を成立させる上で、かなり重要な前提がある。

プロジェクトの知識がGitの上に載っていることだ。

人間だけが知っている仕様が大量にあったり、重要な仕様書が別の場所に置かれていたりすると、この構成はうまく回らない。

このプロジェクトでは、設計上の判断や仕様の背景をできるだけ**ADR（Architecture Decision Record）**として残し、Gitで管理するようにしている。

ADRという名前だが、重要なのは形式ではない。「なぜこの設計になったのか」「どの選択肢を捨てたのか」「この値にはどういう意味があるのか」といった、ソースコードだけでは分からない知識をAIが読める場所に置いておくことだ。

これが十分に蓄積されていると、相手側の役割を与えたAIはかなり強い。

たとえば請求管理セッションなら、請求管理のソースコードだけでなく、過去のADRや仕様変更の経緯まで読める。

すると「なぜこのAPIはこうなっているのか」「このケースではどう処理すべきなのか」という質問に対して、本物の請求管理担当者にかなり近い挙動をするようになる。

逆に、知識ベースが別の場所にありAIから参照できない場合、手がかりはほぼソースコードだけになる。

実装から現在の動作を調べることはできる。しかし、「なぜそうしたのか」「例外条件は何か」「過去に何が決定されたのか」まではコードだけでは分からない。

当然、回答の正確さも落ちる。

クロスセッションを増やす前に、AIが読める場所に知識を残しておく。この土台がないと、何人AIを増やしても知らないものは知らない。

本物の相手に質問する前に、ローカルの相手に聞く

この仕組みは、実際の問い合わせでも使える。

たとえば会員管理を開発していて、コンテンツ管理チームに仕様を確認したくなったとする。

以前ならSlackで、

「このAPIなんですが、このケースではどうなりますか？」

と聞いていた。

今は、その前にローカルの「コンテンツ管理セッション」に同じ質問をする。

相手役のClaude CodeがコードやADRを調べて、「それは実装を読めば分かります」「ADRにすでに決定事項として残っています」と答えれば、本物のコンテンツ管理チームに質問する必要はない。

逆に、「コード上では判断できない」「仕様と実装が食い違っている」「このケースの定義が存在しない」となれば、そこで初めて外部へ問い合わせる。

つまり相手方AIが、質問の事前審査をしている。

開発現場では、調べれば分かることを他チームに聞いてしまうと、相手の時間を奪うし、「まずコードを読んでくれ」で終わる。

AIなら何回くだらない質問をしても怒らない。

だったら、怒らない相手に先に全部聞けばいい。

Slackは人間用、AIにはMarkdownを渡す

外部との通信経路も分けている。

人間 ⇔ 人間
    Slack

AI ⇔ AI
    Markdown + Git

人間同士のちょっとした確認までGitでやる必要はないので、そこは普通にSlackを使う。

一方、AI同士で正式に受け渡す情報はMarkdownにしてGitに置く。

たとえば、

docs/integration/content-api.md
docs/integration/billing-api.md
docs/questions/content/
docs/questions/billing/

のようにする。

そしてプロジェクト開始時に、**「どのリポジトリの、どのブランチの、どのMarkdownを読むのか」**まで決めておく。

こうしておけば履歴が残り、差分が取れ、レビューもできる。

チャットのどこかに重要な仕様が埋もれて、「確か先月誰かが言っていた」という状態にもならない。

相変わらず私がプロマネとして各セッションに仕事を渡し、必要な時だけ横につなぐ。この程度の連携のほうが、今のところ扱いやすい。

1人なのに、組織になってきた

PCの前にいる人間は一人なのに、開発担当、タスク管理、相手システム担当、レフェリーまで揃った。

だんだん組織っぽくなってきた。

足りない役割があれば、Claude Codeをもう一つ立ち上げればいい。

今回は開発セッションだけだが、テスト専門のセッションを追加してもいい。

人間の会社でこれをやるとテスターの採用だが、AIの会社ではターミナルを一枚増やすだけである。