amiiby
ぬにょす(挨拶)。
Claude Code を並列で動かす記事はたくさんありますが、多くは1つのリポジトリの中で worktree を切ったり、サブエージェントを走らせたりする話なんですよね。
私は個人開発のアプリをいくつか（以下、アプリ 1・アプリ 2…）と、その紹介サイトを作っていて、プロジェクトごとに Claude Code のセッションを立てっぱなしにしたまま、それらを同時並行的に相手にしています。
この記事では、そのやり方と、そのために作った道具を紹介します。
ちなみにメインのマシンは、M1・メモリ 8GB の Mac mini（2020）です。カツカツです(´･_･`)
作業環境
それぞれの画面に何が映っているかを、図にしてみました。
Mac mini（メインモニター）
27インチ・2560×1440。ターミナル（Alacritty）を全画面にして、Herdr でペインを6分割しています。
5つのペインでプロジェクトごとの Claude Code セッションを動かしていて、そのうち1つが、プロジェクトをまたぐ用事や雑用を引き受ける常駐セッション（秘書）です。残りの1つは自分の作業用で、主に Helix, Yazi, hunk を使っています。
Helix は、Vim 系のモーダルなエディタです。言語サーバーやシンタックスハイライトが、設定なしで効きます。
HelixA post-modern modal text editor.helix-editor.comYazi は、ターミナルで動くファイルマネージャです。Rust 製で、とにかく速いです。
YaziBlazing fast terminal file manager written in Rust, based on async I/O.yazi-rs.github.iohunk は、ターミナルで差分を読むビューアです。AI エージェントが書いた変更をレビューする用に作られています。
hunk — review-first terminal diff viewerHunk is a review-first terminal diff viewer for agent-authored changesets. Multi-file review stream, inline AI annotations, watch mode, TypeScript extensions, and Git/Jujutsu integration.hunk.dev
Mac mini（モバイルモニター）
15.6インチ・1920×1080。基本的にはブラウザが開いていて、Web アプリの表示確認だったり、外部サービスの設定だったり、各種の情報収集だったりに使っています。
Claude からの報告も、Artifact に出してもらってここで読みます。Artifact の方が Markdown より圧倒的に読みやすいです。
Windows のノート PC
13.3インチ・1920×1200。Windows でしか確かめられない作業だけを受け持ちます。
ここにも常駐セッションを置き、Windows での作業が要るアプリのセッションだけを立てています。
iPad
Claude アプリの Code タブを開きっぱなしにしています。
- 画面がオフになっていても、セッションとやり取りできる
- 自動テストで PC のマウスやキーボードがふさがっていても、セッションへの指示を続けられる
- ターミナルでは Claude が送ってくる画像が見えないけど、Claude アプリなら見れる
- 長文をタイプするのが面倒なときの、音声入力用
iPhone
モニターの横のスタンドに縦置きしています。Mac のスペックが最低ラインなもんで、メールや LINE のように Mac の外に出せるものは、iPhone と iPad に追い出しています。
なぜプロジェクトをまたぐ仕組みが要るのか
複数のプロジェクトを並行して作っていると、プロジェクトの間で揃えたいものや、知識・技術の輸出入がどうしても出てきます。後から作った側が改良して、元のプロジェクトへ持ち帰る「逆輸入」もよく起きます。
たとえば、アプリ 1 で「開発サーバーが本番用の DB を触る」不具合を直したときのことです。それを聞いたアプリ 2 のセッションが自分の側を確かめると、同じ不具合がありました。
しかもアプリ 2 の直し方のほうがよかったので、アプリ 1 はその日のうちにそちらに合わせました。
1つのリポジトリの中の並列では、こういう問題は起きません。プロジェクト単位で並べると、プロジェクトの間をつなぐ層が要る訳です。
なお、コードは共通にしていません。輸出入するのは、決まり・型・調べた結果です。その置き場として、プロジェクトをまたぐ共通の記憶のリポジトリを1つ置いています。
秘書: 常駐セッション
常駐セッションは、この共通の記憶のリポジトリで動くセッションが兼ねています。
ペインの分割には、tmux ではなく Herdr を使っています。決め手は、Claude がペインを操作するための skill があることです。セッションが別のペインの出力を読んだり、入力を送ったりできます。
Herdr: the runtime coding agents run onRun them anywhere. Leave them running. Herdr holds real terminals open so your agents keep working when you close the laptop, and gets you back in from any tty.herdr.dev
秘書（常駐セッション）の仕事は、たとえば次のようなことです。
- 全員への連絡: 複数のセッションに同じ指示を、セッション間メッセージで送ってもらう
- 共通の記憶の更新: ほかのセッションから頼まれて、共通の記憶を書き足す
- todo の作成: ほかのセッションが作業している間に、そのセッションの todo を作っておく
- 軽い用事: ちょっとした調べ物や、メールチェックなど
使うときの決まりは次のとおりです。
- 実作業は各プロジェクトのセッションに頼む: 常駐セッションは、ほかのプロジェクトのファイルを書き換えません。
- 結果を集めない: 依頼には「返信は不要。結果はそのペインで報告してください」と書きます。私は各ペインを直接見ているので、報告が秘書に集まると、秘書の文脈と私との会話が割り込みで埋まってしまうんですよね。状況が知りたいときは、秘書から取りに行きます。
- 依頼は命令ではない: 相手のセッションは聞き返したり、別の判断をしたりします。権限も各セッションで独立しています。私が常駐セッションに了解を出し、根拠を添えてブランチの削除を頼ませたときも、相手は自分で確かめ直し、私に確認してから消しました。えらい。
似た仕組みとの違い
最近、近い発想のものがいくつか出てきました。
- 公式のセッション間メッセージ。私の秘書も、これを使って頼んでいます。
- Claude Code Projects。常駐の会話が、複数のリポジトリのスレッドを指揮します。今はクラウドだけです。
- Chief of Staff パターン。調整役のセッションが1つ常駐し、実行役のセッションに任せます。
私の形との違いは、次の点です。
- 相手が、使い捨ての実行役ではなく、プロジェクトごとに文脈を持って常駐しているセッションであること
- 常駐セッションは指揮をせず、取り次ぎと記録と雑用を受け持つこと
- 結果を秘書に集めないこと
- 全部を手元で動かし、Mac と Windows をまたぐこと
まとめ
- プロジェクトごとに Claude Code のセッションを立てっぱなしにし、常駐セッションを秘書にする
- 秘書は取り次ぎと記録と雑用を受け持ち、結果は集めない。報告は各ペインで直接読む
当初は常駐セッションを「万事屋（よろずや）」と名付けて、Herdr の操作や、ほかの Claude Code セッションの再起動なんかを頼んでいました。
その後 Claude Code に mod の仕組みが入って、この形は大きく変わりました。その話は、またいずれ書こうと思います。
汎用的に使えそうな仕組みや skill は、yorozuya として公開しています。複数のプロジェクトを抱えている方の参考になれば幸いです。
GitHub - miyabi-satoh/yorozuya: 複数の Claude Code セッションを手元で運用するための skill 集複数の Claude Code セッションを手元で運用するための skill 集. Contribute to miyabi-satoh/yorozuya development by creating an account on GitHub.github.com
でわでわ。