Claude Code の複数セッションを見失わずに管理する方法

Claude Code の作業時間の大半は、こちらが見ていなくても進みます。となると自然な次の一歩は、 2 つ、3 つ、5 つとセッションを並列で走らせることです。難しいのは起動そのものではなく、 互いの作業を踏み荒らさないよう分離することと、「今どれが自分の入力待ちか」を 即座に把握すること。このガイドはその両方を扱います。

そもそもなぜ並列で動かすのか

機能実装・テストスイートの実行・複数ファイルにまたがるリファクタリングなど、 それなりのタスクなら Claude Code の 1 ターンは数分かかります。それをじっと眺めているなら、 遊んでいるのは人間の側です。よくある並列パターン:

• 同一リポジトリ内の独立タスク — バグ修正を 1 セッション、ドキュメント更新をもう 1 セッション。
• 別リポジトリ — API サーバーとフロントエンドをそれぞれのセッションで。
• 調査と実装の分離 — 設計の検討を 1 つが進め、承認済みプランの実装を別の 1 つが実行。

Step 1: 作業を分離する — git worktree

2 つのセッションが同じチェックアウトを編集するのは典型的な事故パターンです。片方の git status がもう片方の書きかけの編集で埋まり、ビルドは混ざった状態を拾います。 解決策は git worktree。 1 つのクローンから複数の作業ディレクトリを作り、それぞれに別ブランチを割り当てます。

# メインのチェックアウトから
git worktree add ../myapp-fix-auth  -b fix-auth
git worktree add ../myapp-new-onboarding -b new-onboarding

# worktree ごとに 1 セッション
cd ../myapp-fix-auth        && claude   # ターミナルタブ 1
cd ../myapp-new-onboarding  && claude   # ターミナルタブ 2

これで各セッションはクリーンなツリー・専用ブランチ・独立したビルド成果物を持ちます。 ブランチをマージしたら git worktree remove ../myapp-fix-auth で片付け。 worktree はオブジェクトストアを共有するため、クローンを増やすよりディスク消費は はるかに小さく済みます。

Step 2: セッションの居場所を決める — ターミナルレイアウト

マルチプレクサでもタブ対応ターミナルでも構いません。重要なのは、各セッションに 「いつも同じ、すぐ見つかる場所」があることです。

tmux

# セッションごとに名前付きウィンドウ
tmux new-window -n fix-auth
tmux new-window -n onboarding

# あるいは 1 ウィンドウをペイン分割
tmux split-window -h

ステータスバーのウィンドウ名は簡易的なセッション一覧を兼ねます。tmux は SSH 切断にも 耐えるので、リモートマシンでは事実上の第一候補です。

iTerm2 / Terminal.app / IDE

タブや分割ペインでも同じことができます。1 ペイン 1 セッション、名前はタスク名に。 VS Code や Cursor なら、エディタウィンドウごとに統合ターミナルで 1 セッションを動かす 構成が定番で、コードとセッションが常に並びます。

どのレイアウトでも効く習慣が 2 つあります。タブ名をタスク名に変えること（tmux なら tmux rename-window fix-auth）、そして各セッションに ステータスラインを 付けること。/statusline コマンドでプロンプト下にカスタム行（モデル・git ブランチ・ コンテキスト使用量）を設定でき、どのセッションに飛び込んでも自己紹介してくれます。

Step 3: 本当の問題 — 「誰が自分を待っているか」

分離とレイアウトは解決済みの問題です。実際に時間を奪うのは注意のルーティングのほう。 Claude Code のセッションは、次のような見逃しやすい瞬間にブロックします:

• ツールの実行許可を求めている — ファイル編集、シェルコマンド、ネットワークアクセス。
• プランの承認待ち — コードに触る前にプランを提示して止まっている。
• 選択肢つきの確認の質問を投げている。
• 単に応答が完了し、次のプロンプトを待っている。

1 セッションなら気づけます。4 セッションあると、どれか 1 つは他の出力の陰で静かに 止まっています。Yes/No のダイアログが見えないまま置かれて、実時間で 5 分が消える—— Cmd+Tab でタブを巡回して確認するのは、コードでは絶対に書かない ポーリングループそのものです。

ターミナル標準の仕組みでできること

tmux の monitor-activity は新しい出力があったウィンドウに印を付けます （ただしあらゆる出力で発火するのでノイズが多い）。iTerm2 もアクティビティやベルで タブにバッジを出せます。これらが教えてくれるのは「何かが起きた」であって 「Claude があなたを待ってブロックしている」ではありません。結局は見に行くことになります。

hooks でできること

Claude Code の hooks は、 ライフサイクルイベントでシェルコマンドを実行します。Notification（入力が必要）と Stop（応答完了）を macOS 通知につなげば、プッシュ型の通知が手に入ります。 コピペで使える設定はmacOS 通知ガイドにまとめました。 残る課題は、通知が教えてくれるのはイベントであって状態ではないこと。 「今この瞬間、5 セッションのうちどれがブロック中か？」に答えるには、 集約する何かが必要です。

Step 4: 全セッションのステータスボード

その「集約する何か」を、私たちはアプリとして作りました。 AgentManager は、マシン上のすべての Claude Code セッションを 常時最前面の小さなフローティングウィンドウに一覧表示する macOS メニューバーアプリです:

• 各セッションが 1 行で、状態ランプ付き — 確認待ち、 処理中、 完了、 待機。
• 確認待ちの行には返答の形が表示される — Yes/No の許可、プランのレビュー、選択式の質問 — 切り替える前に優先順位を判断できます。
• どれかが確認待ちになるとウィンドウが自動で前面に出て、すべて解消すると引っ込みます。
• 行をクリックすると、そのセッションが動いているターミナルペインへ直接ジャンプ — iTerm2、Terminal.app、Ghostty、VS Code 系エディタに対応（tmux のセッションも状態表示は対応しますが、tmux ペインへのジャンプは現状非対応）。

仕組みは上で説明したのと同じ公開 hooks API です（セットアップはワンクリック、hooks は きれいに解除可能）。自作の hook スクリプトとも共存できます。セッションが worktree・タブ・ tmux のどこで動いていても、同じボードに載ります。

並列セッションを破綻させないための実践 Tips

• 名前を付ける。セッション一覧（AgentManager の行も）には作業ディレクトリ名が出ます。myapp-fix-auth は myapp (2) より一目で分かります。
• リポジトリごとに CLAUDE.md を置く。ビルドコマンド・テストコマンド・コーディング規約を毎セッション説明し直さずに済みます。
• セッション数はレビュー帯域に合わせる。並列セッションはそれぞれ読むべき diff を生みます。多くの人は 2〜4 が適正で、それを超えると生成ではなくレビューがボトルネックになります。
• 大きめのタスクはプランモードで。30 秒のプランレビューは、方向を間違えた 40 ファイルの diff レビューに勝ります。
• 終わったセッションは閉じる。タブを放置せずセッションを終了すれば、目にする一覧がすべて正確に保たれます。