Claude Codeを並列で回すようになるまでの話

この記事は Claude on SonicGarden の記事です。ソニックガーデンのプログラマが、Claude Codeの活用について書いています。#claude_on_sonicgarden

はじめに

ソニックガーデンでClaude Codeが全社導入されてから、自分の開発スタイルは大きく変わった。最初は1つのセッションで十分だったのが、気づけば複数セッションを並列で回すのが日常になっていた。

この記事では、そこに至るまでの経緯と、個人的な並列運用の話を書く。

ソニックガーデンでの開発スタイル

ソニックガーデンは「納品のない受託開発」をやっている会社だ。日々の開発は複数の案件をまたいで進むことが多い。

僕は主にRailsアプリが多く、業務時間の隙間や業務外の時間で個人OSSの開発もやっている。各案件ごとに週1の定例ミーティング、設計、開発、不具合修正、コードレビュー、デプロイ、障害対応、お問い合わせ対応など、開発だけでなく実に様々なことをやっている。

開発環境やOSなど特に縛りがなく自由なので、僕の場合はOSはManjaro Linux, 主にtmux + NeoVimで、tmuxのウィンドウ/ペインを活用して多くの画面を切り替えながら開発している。この環境は長年かけて手に馴染んだもので、変更するに値する合理的な理由が無い限り、あまり変えたくはないなと思っている。IDEが嫌いなわけではないけど、いつものキー操作でなるべくマウス触らずに過ごしたいと思っている。ソニックガーデンの中では割と少数派なんじゃないかな。

1セッション時代

Claude Codeを本格的に使い始めた当初は、1つのセッションで満足していた。

案件Aの機能を実装する。Claude Codeに方針を伝え、コードを書かせ、レビューする。終わったら次のタスクに移る。元々開発スピードには自信があったし、凄く早くなったということもなく、そこまでClaude Codeに依存することもないなと思った。ワークフロー自体は直列だし、1人のちょっと抜けたところもあるような優秀な若手と組んでペアプロしている感覚に近いなぁと思った。用途としても設計と開発ぐらいだったかなと思う。

並列に移行しはじめたきっかけ

Claude Code開発者のBoris Chernyを始めとして、色んな人が並列で複数セッション使っているのを見聞きするようになって自分でもやってみようと思ったのがきっかけだったと思う。実際普段利用していても、プロンプトを投げるたび、何かと待ち時間が多いなとは思ってたし。将来このへんの待ち時間が限りなくゼロに近づくならば、一周回って直列が大正義になりそうな気もするけども、今はそうでないので、並列化に取り組むことにした。なお、待ち時間で休憩したり、お茶を飲んだり、体を動かしたりするのも体験として悪くないし、今でも疲れてるときはあえて1セッションだけにするときもあるし、並列にすべきと言いたいわけではないよ。人間は本質的にシングルタスクだし、コンテキストスイッチのコストも無視出来ないし。

並列のパターン

一口に並列と言っても色々なパターンがあるかなと思う。例えば3つだけ例を出してみると

• (1) 異なるリポジトリでの並列作業
  • 後述するgit worktree使うとか考えなくていいしこれが始めやすいと思う。
• (2) 同一リポジトリでの並列作業
  • これは少し注意が必要。作業ディレクトリを分ける必要があるので、git worktreeを使ったほうがいい。個人的には git-wt を使ってる。理由は省略するけどClaude Code本体の -wオプションは合わなかった。
• (3) 開発とそれ以外の作業
  • レビュー、お問い合わせ対応などしつつ、開発みたいな。これもgit worktreeで作業ディレクトリ分けたほうがいいケースが多いので、最近は何も考えずに分けるようにしてるかな。Claude Codeでお問い合わせ調査してたら、他セッションのためブランチ切り替えちゃって事故る、みたいなことがあったので。

ようするにClaude Codeというのは基本ディレクトリ単位で動かすので、各セッションで独立したディレクトリのほうが都合がいいってことだね。同一ディレクトリで複数セッション起動して開発しつつ、お問い合わせ調査とかやってもいいけど、Claude Codeの履歴が混ざっちゃう影響で後からセッションを/resume したいときなんかもどれだっけ...ってなりがちだし。

参考までに僕のRailsアプリでのgit-wtの設定を掲載しておく。プロジェクトの.git/configに以下を書いてgit wt ブランチ名をしてる。人によってcopyしたいもの、hook実行したいものは違うとおもうので適宜読み替えて欲しい。

[wt]
	copy = config/database.yml
	copy = config/credentials/development.key
	copy = config/credentials/development.yml.enc
	copy = config/credentials/test.key
	copy = Procfile.dev
	hook = bundle install
	hook = pnpm install

Procfile.devは例えばこんな感じ

web: bin/rails server -p 3001
js: pnpm build --watch
sass: pnpm build:sass --watch
tailwind: pnpm build:tailwind --watch
job: bundle exec good_job start

で、動作確認したいときは別ターミナルでgit wt ブランチ名してからovermindで、overmind start -f Procfile.devする。E2EテストまではClaude Codeでいいんだけど、実ブラウザでの最終確認はやっぱり最終的には人間がやる必要がまだあるかなっておもう。

並列運用の課題

ただ、セッションが増えると問題も出てくる。

どのセッションが何をしてるかわからなくなる

3つ、4つ...と増えると、どのセッションがどこまで進んでいるか把握しきれなくなりがち。tmuxのペインを切り替えて確認するのが煩雑になる。「あのセッション、もう終わってたっけ？」と思って切り替えたら、まだ途中だった。逆に、とっくに終わっていたのに気づかず放置していた、ということもあった。勿論Claude Code本体のHooksを使ってデスクトップ通知するなどの工夫はしたけど無理だった。

承認待ちの割り込み

Claude Codeはファイルの書き込みやコマンド実行のたびに承認を求めてくる。1セッションなら問題ないが、複数セッションが同時に承認を求めると割り込みの嵐になる。

設計を考えている最中に「案件Bが承認待ちです」と気づく。切り替えて承認する。戻って設計の続き...と思ったら「案件Cも承認待ち」。思考が細切れになって辛い。

コンテキストスイッチのコスト

案件Aのレビュー中に案件Bの承認要求が来る。案件Bのコードを見て判断し、戻ってきたときに案件Aの文脈を思い出す必要がある。セッション数が増えるほど、このスイッチングコストが大きくなる。

最初はclaudeyeを作った

この問題を解決するために、当初はclaudeyeというツールを作った。tmux前提だけど稼働中の全Claude Codeセッションを収集してデスクトップの最前面に状況をリアルタイム表示するウィジェット。最終的に後述するcrmuxとも連動出来るようにして、今でも便利に使ってる。これ単体で使うことも勿論出来る。

次にcrmuxを作った

当時、cmuxが話題になり始めてて、使ってみようとしたらMac専用で絶望した。しかし自分にはClaude Codeがあるし、claudeye も作ったんだから自作してみるかーとすぐ切り替えて作ったのが、crmux。cmuxを始めとして似たようなツールは複数あるけど、tmuxのこれまでの開発フローを変えたくはなかったし、結果的にすごく手に馴染むものが出来て満足してる。Vimmer的な発想のキーバインドでマウス操作も出来ないのでとてもマニアックなツールだと思うけど、一部の人にはぶっ刺さったようで嬉しい反応もあった。

tmuxのペインとして動く管理画面で、すべてのClaude Codeセッションの状態を一覧できる。どのセッションが実行中で、どれが承認待ちで、どれが完了しているか。ペインを切り替えなくても全体が見えるし、プロンプト入力もcrmux上から出来るけど、実体はあくまでもClaude Codeが起動しているtmuxペインである、というのがポイントで、何も変えずに導入出来るしいつでも捨てれるものとして設計している。

詳しい機能や使い方は別の記事に書いているので、ここでは省略する。tmuxユーザはもしよかったら使ってみて欲しい。社内のMacユーザの一部は使ってくれてるのかも。

crmuxを作ったことで、並列運用の課題はかなり解消された。全体の状態が常に見えているから、承認待ちにもすぐ気づける。コンテキストスイッチも、一覧画面でプレビューを見てから切り替えるので、復帰コストが下がった。

おわりに

Claude Codeの並列運用は、とても疲れるので万人にはおすすめできない。でもチャレンジはしてみる価値があるんじゃないかと思う。僕は随分慣れてきて、これまでとは時間の使い方が変わってきた。Claude Codeに任せることが出来る範囲が広がることで、自分の時間を何に注ぐべきなのか、これまで以上にちゃんと考える必要があると感じている。時間的な余裕は確実に以前より生まれるようにはなってきている。一方で並列運用による頻繁なコンテキストスイッチや、ペアプロ的な頭の使い方により脳が短時間で酷使されているのか疲れやすくなったようにも感じるが、それはそれで集中力が高くエネルギーにあふれている午前中の時間で頭の使う仕事中心に進めて、午後は軽めの仕事中心にするなどメリハリがつくようになったとも思う。今のところはうまくいっているとおもうので、当面はこのまま続けてみるつもり。

そしてこれは余談だけど、以前は課題を思いついても自作ツールをすぐに作ろう、とまでは中々ならなかった。でもClaude Codeのおかげで、思いついてから形にするまでの距離が短くなったから、「じゃあ作るか」のハードルも下がったのはとてもいい体験になっている。探すより作るほうが早いかもということが増えた。それに自分で作るほうが自分の手に馴染む。本業のシステム開発のようにセキュリティ、決済、24時間365日止めてはいけない、など厳しい制約のない開発はこんなに楽しかったんだって、若いときの気持ちを思い出しながらGWもあれこれ作って遊ぼうと思う。