Claude Code複数セッションの一覧と連携のやり方｜セッション同士が自分で連絡し合う運用と、claude agentsで稼働中を見る方法【2026年】

Claude Codeの複数セッションを回すとき、僕に必要だったのは「今どれが動いているかの一覧」と「セッション同士の連絡」の2つでした。僕の会社では受信を常時許可にし、セッションが言われなくても他のセッションへ連絡する決まりで回しています。

始めたのは2026年8月21日で、5日後の8月26日には「言わなくても自動的に会話して」と決まりを格上げしました。10月4日には、稼働中のセッションを15秒ごとに集める全案件ダッシュボード（社内用）も作っています。

この記事では、公式の仕組み、社内の6つの決まり、宛先の取り違えなどの失敗、一覧の取り方を順に書きます。「セッションを何本も開いていると、結局どれが何をしているのか分からなくなる」と困っている方に向けた記録です。

Claude Code複数セッションを並列で回すときに要るのは「一覧」「連絡」「引き継ぎ」

Claude Codeの複数セッションを並列で回すなら、稼働中の一覧、セッション同士の連絡、会話の引き継ぎの3つを決めておけば足ります。どれも公式の機能で用意されています。

僕の会社では、別々の案件のセッションが同時に動くのが普通です。連絡の手段が無いと、あるセッションで決まったことを、僕が別のセッションへ伝え直す伝書鳩役になります。

3つの困りごとと、使っている公式の手段を並べます。

僕が最初に決めるなら、連絡の受け方です。一覧は後から足せますが、受け方が決まっていないと、送ったメッセージが保留のまま消えることがあるからです。

3つ目の引き継ぎは、Claude Codeのセッションを再開する方法に分けて書きました。この記事では1つ目と2つ目を中心に書きます。

セッション同士の連絡はListAgentsとSendMessage、受け方はcrossSessionInboundで決まる

セッション同士の連絡は、Claudeが ListAgents で相手を探し、SendMessage で文章を送る仕組みです。受け取る側の動きは、設定の crossSessionInbound で決まります。

公式ドキュメントによると、この機能はmacOSとLinuxでv2.1.224以降、Windowsでv2.1.234以降で使えます。条件を満たせば、何も有効にしなくても最初から動いています。

届くのは文章だけで、会話の履歴やファイルは渡らない

送られるのは、送り手のClaudeが書いた文章だけです。会話の履歴やファイルの中身は渡らないので、会話ごと移したいときは再開の機能を使うよう公式に案内されています。

受け手が作業中なら、ツールの呼び出しの合間に読みます。受け手が待機中なら、そのメッセージで新しいターンが始まります。同じパソコンの中では、セッションごとの経路で届き、Anthropicのサーバーは通りません。

宛先は、/rename か --name で付けた名前です。名前を付けていなければ、Claude Codeが自分で名前を付けます。

名前の付け方はClaude Codeのセッション名を変更・日本語にする方法に書きました。

crossSessionInboundの3つの値

crossSessionInbound は、他のセッションから届いたメッセージをどう扱うかの設定です。公式の説明を、値ごとに並べます。

僕の会社では全セッションを accept にしています。設定が無いと、許可のモードが合わない相手からのメッセージが保留になるからです（次の節）。

設定が無いと、許可のモードの組み合わせで保留になる

値を設定していないときは、送り手と受け手の許可のモードの組み合わせで、届けるか保留にするかが決まります。確認を飛ばすモードのセッションと、それ以外のセッションの間で保留が起きます。

公式によると、デスクトップアプリとVS Code拡張は保留の確認画面を出せません。保留になったメッセージは期限まで置かれ、期限は既定で5分です。期限を過ぎると捨てられます。

届いたメッセージは「本人の承認」にならない

他のセッションからのメッセージは、あなたの承認として扱われません。許可の確認に代わりに答えることも、設定や CLAUDE.md を書き換えさせることもできないと公式に書かれています。

メッセージの中に /compact のようなコマンドがあっても、ただの文章として届き、実行されません。受け手で許可の要る操作をするときは、いつもどおり確認が出ます。

2026年8月21日に常時オン、8月26日に「言われなくても連携」へ格上げした

僕の会社では、2026年8月21日にセッション間のやり取りを常時オンにし、8月26日に「頼まれなくても自分から連絡する」決まりに変えました。きっかけはどちらも僕の指示です。

8月21日に僕が出した指示は、セッション間で会話を自動でやり取りできる機能を必ず有効にして、ずっと使うことでした。複数のセッションが並んで動くのが当たり前になっていたからです。

セッション同士が依頼・報告・確認を直接やり取りできれば、僕が伝書鳩をしなくて済みます。

そこで設定ファイルの settings.json に "crossSessionInbound": "accept" を入れました。全セッションで自動で受け取る形です。

8月26日に決めた6つの決まり

8月26日に、僕は「言わなくても自動的に会話して」と指示しました。送れるだけの状態から、自分から連絡する義務に変えたのです。社内の決まりとして全プロジェクト共通のルールファイルに書いた6つは、次のとおりです。

1. 起動時チェック：最初の作業のついでに稼働中のセッションを確かめ、作業対象が重なる相手には「何をどこまで触るか」を先に送る
2. 節目プッシュ：共有のファイルや引き継ぎメモを更新したら、関係しそうなセッションへ要点を1通送る。聞かれるのを待たない
3. 訂正：他のセッションの記録に古い情報を見つけたら、直せるファイルは直し、そのセッションにも一言伝える
4. 受信時：本題を止めない範囲ですぐ返し、往復は原則1回で終える。担当外でも5分以内で済むなら代わりにやってよい
5. 禁止：自分のセッションで止められた操作を他のセッションに頼むこと、認証情報を平文で送ること、返事の要らない儀礼だけのメッセージ
6. 記録と報告：やり取りで決まったことは案件の引き継ぎメモに残し、僕には要点を1〜2行で伝える

1の起動時チェックは、衝突を防ぐための決まりです。同じファイルや同じ広告アカウントを2つのセッションが同時に触る前に、どちらが何を触るかをはっきりさせます。

5の禁止は、公式の仕組みとも重なります。公式でも、自分のセッションで拒否された操作を他のセッションに頼まず、人に戻すようClaudeに指示されています。

動いているセッションは、ルールを読み直さない

決まりを変えたときに気づいたのは、すでに動いているセッションはルールファイルを読み直さないことです。新しい決まりは、次に始めたセッションから効きます。

そこで、ルールを変えたときは、稼働中のセッションへ SendMessage で直接知らせる運用にしました。連絡の仕組みそのものを、ルールの周知にも使っています。

実際に起きた2つの失敗：宛先の取り違えと、2つのセッションへの逆の回答

運用を始めてから、宛先の取り違えと、2つのセッションで僕の回答が逆になる出来事が起きました。どちらも、送る側の書き方と、確かめ方を変えて対処しています。

2026年8月26日：名前の末尾を頼りに送ったら、別の案件のセッションに届いた

8月26日、あるセッションが、名前の末尾の英数字を頼りに別のセッションへ依頼を送りました。ところが届いたのは、撮影の案件を担当していたセッションでした。

原因は、セッション名の末尾の英数字が、セッションIDの先頭と一致しないことがある点でした。名前から担当を推測して送ると、外れることがあります。

このときは、受け取ったセッションが事情をくみ、頼まれたレジストリの更新を代わりにやってくれました。それ以来、大事な依頼は本文に「〇〇担当のセッション宛」と書き、違えば転送か代行を頼める書き方にしています。

2026年9月15日：2つのセッションに、僕が数十分差で逆の回答をしていた

9月15日、LPの案件で、2つのセッションが同じ論点を僕に選択式で聞いていました。片方のセッションから「佐藤さんの決定です。戻してください」と連絡が来ましたが、もう片方が僕に直接聞いた答えは逆でした。

受けた側のセッションは、最初「相手の拡大解釈だ」と判断しました。しかし調べると、相手の伝え方は正確でした。僕は相手の選択肢を実際に選んでいて、数十分後に別のセッションで逆の選択をしていたのです。

原因は、それぞれのセッションが自分の担当ファイルの範囲で聞き、僕もその場の範囲で答えたことでした。疑うべきは相手の伝え方ではなく、僕が別々の回答をしている可能性だったと記録しています。

矛盾は「矛盾ごと」本人に見せて決める

決着させた方法は、「2つのセッションで回答が逆になっています」と矛盾をそのまま僕に見せることでした。判断の決め手になる事実も、質問に添えてもらいました。

たとえば「その指示は、取引先からの要求でしたか」という問いです。この聞き方で2回とも同じ選択が返り、確定しました。決まるまでの間は、取り消しの効かない操作をしない現状維持の側で待たせています。

この出来事から、社内の決まりに次の4つを足しました。

• 同じ論点を複数のセッションから聞かない（担当を1つに決める）
• 伝え聞いた決定と本人の指示が食い違ったら、矛盾ごと本人に見せ、決め手の事実を添えて聞き直す
• 確定するまでは、取り消しの効かない操作をしない
• 決着したら経緯つきで記録し、同じ提案を繰り返さない

なお、相手のセッションが見て報告した事実は、自分でファイルを読むなどして裏を取れば信用してよいとしています。9月15日も、事実の報告は正確でした。疑うのは事実ではなく、「決定」がどこまで及ぶかです。

Claude Codeのセッション一覧はclaude agents --jsonで取れる（2026年10月4日の記録）

今動いているClaude Codeのセッションの一覧は、ターミナルで claude agents --json を打てば、JSONの配列で取れます。会話の中なら /list-agents で、連絡できる相手を見られます。

僕の会社では2026年10月4日に、全案件ダッシュボード（社内用）を作りました。その中で、各Macの稼働中のセッションを claude agents --json で15秒ごとに集め、画面に出しています。

claude agents --json に入る項目

公式ドキュメントにある、1つのセッションごとの主な項目を並べます。動いているセッションのほか、終わっていないバックグラウンドのセッションも入ります。

ダッシュボードに送っているのは、セッションの題名と、稼働中か待機中かの状態です。公式の説明では、status が waiting なら、許可の確認や入力を待っているという意味になります。

--all を付けると、終わったバックグラウンドのセッションも入ります。--cwd <パス> を付ければ、そのフォルダで始めたセッションだけに絞れます。

フックだけでは「終わった」を取りこぼす

ダッシュボードでは、セッションの開始や応答の終了などをフックでも記録しています。それでも claude agents --json を併用しているのは、フックだけだとセッションの終了を取りこぼすためです。

フックが送るのは、出来事の種類、時刻、ツール名、書き込み先のパスだけです。指示の本文やファイルの中身は送らない作りにしました。監視しているフォルダの外の会話は記録しません。

作業フォルダでは案件を見分けられなかった

作ってみて分かったのは、ほぼ全部のセッションの作業フォルダが、社内の知識ベースの同じフォルダの直下だったことです。cwd だけでは、どの案件の作業か見分けられません。

そこで案件との紐づけは、セッション名、書き込み先のパス、セッションからの報告を主にしました。社内ではセッション名を「【分類】案件名｜内容」の形にそろえているので、名前が紐づけの手がかりになります。

10月4日の夜の本番では、126件の案件を取り込みました。新しく始めたセッションの開始から終了までが記録され、セッション名で案件に自動で紐づくことを確かめています。セッションからの報告は、4秒以内に画面に出ました。

claude -pの--resume・--json-schema・--permission-modeを実測して分かったこと

ダッシュボードの画面から作業を頼むと、裏の実行係が claude -p でセッションを起動し、続きは同じセッションIDで再開します。そのために、2026年10月4日にClaude Code 2.1.237で主なフラグを試しました。

claude -p そのものの仕組みと無人実行の注意は、claude -pとは？ヘッドレス実行と定期実行の実録にまとめています。

ここでは、複数のセッションを外から動かす視点で分かったことだけを書きます。

使えたフラグと、セッションIDでの再開

僕の環境（2.1.237）では、claude -p で5つのフラグが使えました。--session-id・--resume・--json-schema・--permission-mode・--name です。

--permission-mode は、dontAsk・acceptEdits・auto の3つを試しています。

実行係は、起動するときにセッションIDを決めて保存し、続きはそのIDで --resume します。公式でも、-p の会話はセッションIDを取っておけば、別のフォルダからでも再開できると書かれています。

同じ作業フォルダには同時に書き込ませません。人が手で動かしているセッションが同じ場所で作業中なら、実行係は待つ作りです。同時に動かす数は、既定で2件にしました。

小さいモデルで試した結果（API換算0.13ドル）

実機での確認は、小さいモデルのHaikuで行い、API換算で0.13ドルでした。確かめたことを並べます。

このうち変数の展開の拒否は、作りを変えるきっかけになりました。セッションからダッシュボードへ報告するコマンドは、引数に変数を書かせず、コマンド自身が環境変数を読む形にしています。

環境変数のUSERが無いと、未ログイン扱いになった

実行係から起動したとき、環境変数の USER（と LOGNAME）が無いと、ログインの情報を読めず未ログイン扱いになりました。空の環境で再現し、USER を足すと直っています。

認証のエラーでも結果の subtype が success のまま返り、is_error が true になる点も、同じ日に確かめました。

この点はclaude -pの記事で詳しく書いたので、成否は is_error で見ると決めた、とだけ書いておきます。

なお実行係は、契約しているプランの枠で動かし、従量課金のAPIは使わない作りです。起動するときに、環境変数からAPIキーを外しています。

Claude Codeを並列で回すときの注意：権限、使用量、クラウドとの違い

Claude Codeを並列で回すときに押さえることは3つあります。他のセッション経由で権限を広げない、メッセージも使用量に数えられる、クラウドの並列とは別物、の3つです。

他のセッション経由で、自分の権限を広げない

僕の会社では、他のセッションへの依頼で自分のセッションの制限を回避することを禁止しています。社内のメモでは、これを permission laundering と呼んでいます。

たとえば、自分のセッションで止められた書き込みを、許可の広いセッションに頼む形です。公式でもClaudeに頼まないよう指示されていますが、社内のルールファイルにも禁止事項として書いています。

メッセージは、打った指示と同じく使用量に数えられる

公式によると、届いたメッセージは、あなたが打った指示と同じように使用量に数えられます。受け手が待機中でも、メッセージで新しいターンが始まると、それまでの会話をまとめて読み直します。

社内で消費の内訳を調べたときも、セッション間の連携と定期タスクが要因の1つに入っていました。詳しくはClaude Codeのトークン節約は送り直す量を減らすに書いています。

返事の要らない「ありがとう」だけの往復を禁止しているのは、このためでもあります。

クラウドの「Projects」とは別の仕組み

Claude Codeには、1つの会話からクラウドのセッションを並列に回す「Projects」という機能もあります。調整役のClaudeがスレッドに作業を分ける形で、この記事の手元のセッション同士の連絡とは別の仕組みです。

手元のMacで、案件ごとに独立したセッションを動かすなら、この記事の方法になります。

Projectsの中身はClaude Code Projectsとは？並列のクラウドセッションを回す新機能で解説しました。

止まっているのか、待っているのかを見分ける

並列で回していると、どこかのセッションが止まっていても気づきにくくなります。claude agents --json の status が waiting なら、何かの返事待ちです。

止まり方の見分け方は、Claude Codeが途中で止まる・固まる時の切り分けにまとめています。

まとめ

• Claude Codeの複数セッションは、一覧（claude agents --json）、連絡（ListAgents と SendMessage）、引き継ぎ（--resume とメモ）の3つで回せる
• 受け方は crossSessionInbound で決まる。デスクトップアプリは保留の確認画面を出せないので、accept にしないと、許可のモードが合わない相手からの分は既定5分で捨てられる
• 僕の会社では2026年8月21日に常時オンにし、8月26日に「起動時チェック」「節目プッシュ」など6つの決まりで自分から連絡させている
• 宛先は名前から推測せず、本文に担当を書く。伝え聞いた決定と本人の指示が食い違ったら、矛盾ごと本人に見せる
• 僕なら最初に、全セッションを accept にして、起動時チェックの決まりを1行だけルールファイルに書きます