Claude Codeでセッション間通信を使う方法

Claude Code のセッション間でメッセージを送受信する仕組み

同じマシン上で同じオペレーティングシステムユーザーとして実行されている 2 つの Claude Code セッションは、互いにメッセージを送受信できます。メッセージは、一方の Claude が他方の Claude に送るプレーンテキスト 1 件です。会話履歴やファイルは含まれません。Claude は ListAgents ツールで相手のセッションを見つけ、SendMessage でテキストを送信するため、これらのツールを手動で呼び出す必要はありません。相手のセッションに知らせる内容を指定すると、Claude がメッセージ自体を作成します。

この機能は cross-session messaging と呼ばれます。2026 年 8 月時点では Claude Code v2.1.224 以降が必要です。macOS と Linux で動作し、WSL 2 内の Linux も含まれます。ネイティブの Windows サポートはありません。また、Amazon Bedrock、Claude Platform on AWS、Google Cloud's Agent Platform、Microsoft Foundry では利用できません。セッションが要件を満たしていれば、メッセージ機能はすでに有効になっており、設定は不要です。以下で説明する動作は、cross-session messaging に関する Anthropic のドキュメントに基づいています。

この機能が重要になるのは VPS です。VPS では、セッションを引き続き利用する価値があるほど長時間実行できるためです。ノートパソコンでは、蓋を閉じればセッションも終了します。一方、tmux 上のサーバーでは、月曜日に開始したセッションが木曜日になっても実行され続け、1 つのリポジトリのコンテキストを保持しています。そのようなセッションが 2 つあると、セッション間の通信方法は理論上の話ではなくなります。まだ設定していない場合は、VPS 上の tmux で Claude Code を実行する方法から始めてください。このガイドが前提とするセッションの設定を説明しています。

2 つ目のセッションにトークンを使う価値がある場合

まずコストを考えます。各セッションは、それぞれ独自のコンテキストウィンドウを持つ別個の Claude インスタンスです。そのため、同じ期間では 2 つのセッションにかかるコストは、1 つの場合のおよそ 2 倍になります。送信されたメッセージは、自分で入力したプロンプトと同じように使用量へ加算されます。調整にもコストがかかります。実際には 1 つの手順として進める作業をセッション間に分けると、処理は遅くなり、費用も増えます。

2 つ目のセッションを使う価値があるケースには、共通する形があります。2 つの作業が互いを待たずに同時実行され、一方が作業の途中で、もう一方が必要とする情報を得る場合です。

• 一方のセッションが breaking change を見つけ、もう一方がその変更で壊れたコードを基に作業している場合。Claude は変更内容を要約して送信できるため、別の端末で自分が入力し直す必要がありません。
• 2 つのセッションが、別々の git worktree で同じリポジトリを操作し、一方がどの変更を取り込んだかを知る必要がある場合。
• 長時間の migration やテスト実行が、結果を監視中のセッションへ返す場合。
• builder セッションと reviewer セッションを使う場合。reviewer は builder が生成した内容を読み、確認結果を返します。

作業が順番に進む場合や、両方のセッションが同じファイルを編集する場合は、1 つのセッションを使います。Claude が単一のタスク内で起動して監督する、連携したグループが必要な場合は agent teams を使います。これは別の、まだ experimental な機能です。同じ会話を別の端末で続けたいだけなら、セッションを resume します。Cross-session messaging は、自分で開始して指示する独立したセッション間で使用します。

計画に組み込む前に機能の有無を確認する

まずバージョンを確認します。

claude --version

値を 2.1.224 と比較します。次に、セッション内で /list-agents と入力します。このコマンドは /peers としても実行できます。このセッションから到達できるすべてのエージェントを、それぞれが応答する名前とともに表示します。コマンド自体が認識されない場合、このセッションにはセッション間メッセージング機能がなく、設定ファイルを変更しても有効にはなりません。/status と入力し、Peer address の行を探します。この行には、このセッション自身の受信トレイアドレスが記録されています。アドレスの先頭には uds: が付きます。

VPS ユーザーには特有の注意点があります。セッション間メッセージングは機能フラグの評価に依存します。複数のプライバシー関連変数がこの評価を無効にするため、機能はデフォルトの無効状態のままになります。DO_NOT_TRACK、DISABLE_TELEMETRY、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC、DISABLE_GROWTHBOOK はすべてこの動作をします。新しいサーバーを強化するため、これらを ~/.bashrc に貼り付けると、/list-agents が存在しない理由が分からなくなることがあります。同じ値は設定ファイルの env マップや managed settings から渡される場合もあるため、まず shell の環境を確認します。

env | grep -E 'DO_NOT_TRACK|DISABLE_TELEMETRY|DISABLE_GROWTHBOOK|NONESSENTIAL'

値が表示された変数を unset します。DISABLE_TELEMETRY と CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC では、空でない値なら動作が有効になります。0 という文字列も含まれます。そのため、DISABLE_TELEMETRY=0 は見た目どおりの動作をしません。無効にするには、変数を unset するか、空文字列に設定します。

セッションに名前を付ける。そうしないと Claude はセッションを指定できない

Claude は名前でセッションを指定してメッセージを送信します。セッションの開始時に名前を設定します。

claude --name builder-api

実行中のセッション内で /rename を使って設定することもできます。名前を設定しない場合、Claude Code は作業ディレクトリのフォルダー名から名前を生成します。たとえば myapp-3f のようになります。1 つのセッションなら問題ありませんが、4 つあると区別しにくく、2 つのセッションが同じ名前になることもあります。/list-agents の出力には、各ローカルセッションの作業ディレクトリが表示されます。これにより、同じ名前のセッションを区別できます。また、名前が重複すると、Claude 独自の一覧には指定時に短い識別子が追加されます。自分で名前を付けるほうが、識別子を確認するより手間がかかりません。

再現可能な2セッション tmux レイアウト

これは、1つのリポジトリで builder セッションと reviewer セッションを動かす構成です。reviewer は別の git worktree で作業するため、2つのセッションが同じファイルを書き換えることはありません。git worktree add と HEAD を組み合わせると detached checkout になります。コミットせずに読み取りだけを行うセッションには、この構成が適しています。2つのセッションは役割が異なるため、reviewer には専用の 出力スタイルを設定する価値があります。これにより、そのセッションの system prompt が変更されます。1回だけ入力した指示のように効力が薄れることなく、すべてのターンに適用されます。

cd ~/src/api
git worktree add ../api-review HEAD
tmux new-session -d -s agents -n builder -c ~/src/api
tmux new-window -t agents -n reviewer -c ~/src/api-review
tmux send-keys -t agents:builder 'claude --name builder-api' C-m
tmux send-keys -t agents:reviewer 'claude --name reviewer-api' C-m
tmux attach -t agents

Ctrl+b に続けて w を実行すると、ウィンドウが名前付きで一覧表示されます。builder ウィンドウで /list-agents を実行します。作業ディレクトリが ~/src/api-review の reviewer-api が表示されます。表示されない場合は、reviewer セッションの起動が完了していないか、次のセクションで説明する2つの問題のいずれかに該当します。次に、内容を自然言語で引き継ぎます。

Tell reviewer-api which files I changed for the rate limiter and what to look at first.

Claude が要約を作成して送信します。メッセージ本文を入力する必要はありません。また、Claude が送信する内容は状況によって異なります。reviewer ウィンドウでは、送信者名付きでメッセージが会話に表示されます。そのセッションがアイドル状態なら、Claude は直ちに新しいターンを開始します。ターンの途中であれば、メッセージはツール呼び出しの間まで保留されるため、実行中のコマンドが中断されることはありません。Claude がメッセージを読み取ると、メッセージは1行の Message from 行に折りたたまれ、Ctrl+O で展開できます。builder が変更を小さく保つと、2つのセッションはより効率的に連携できます。差分が小さければ引き継ぎが短くなり、reviewer 側が1ターンでレビューを完了しやすくなるためです。これは、lazy senior dev skill が徹底させる習慣です。

同じ VPS 上で誰が誰を確認できるか

同一マシン内の配信が Anthropic のサーバーを経由することはありません。各セッションは登録ファイルをディスクに書き込み、自身の受信ソケットをバインドします。Claude Code はこれらのファイルを読み取り、他のセッションを検出します。サーバー上では、次の 2 つの点に注意が必要です。

ソケットへのアクセスは、オペレーティングシステムのユーザー単位で制限されます。root として起動したセッションと deploy として起動したセッションは、同じ tmux サーバー上で隣り合わせに実行していても、互いを確認できません。一方のユーザーのセッションから、もう一方のユーザーのソケットにアクセスできないためです。両方のセッションを同じユーザーとして実行してください。

コンテナには独自のファイルシステムがあります。Docker 内のセッションとホスト上のセッションは、同じ登録ファイルを読み取らないため、互いに接続できません。同じコンテナ内の 2 つのセッションは、通常どおりメッセージを送受信できます。使い捨て VM でコーディングエージェントを実行する場合のように、分離のためにエージェントをコンテナ内で運用する場合は、コンテナ内ではメッセージングが機能し、コンテナ境界を越えると機能しないことを想定してください。

他のマシン上のセッションや Web 上のセッションは、Remote Control が接続されている間だけ一覧に表示され、その旨がラベル付けされます。ここにいる Claude は、そのいずれかから届いたメッセージにのみ返信できます。Claude からそのやり取りを開始することはできません。

メッセージが届かなかった理由

通常、原因はネットワークとは無関係です。受信セッションがメッセージの処理方法を決定し、配信しないという判断をしたためです。到着したメッセージの結果は、配信、保留（承認するまで未配信のまま保持）、拒否（配信せず破棄）の3つです。

crossSessionInbound の値が適用されない場合、Claude Code は2つのセッションの権限モードを比較して、メッセージごとに処理を決定します。権限確認プロンプトを回避するセッションを1つのクラスにまとめ、それ以外のセッションをもう一方のクラスにまとめます。auto、acceptEdits、dontAsk はプロンプトを表示するモードとして扱われます。Plan mode は、バイパス権限を利用できるセッションでは、回避するモードとして扱われます。セッションがどちらのクラスに属するか不明な場合は、各権限モードの実際の動作を先に確認してください。現在、多くのセッションは auto で開始され、これはこの分類ではプロンプトを表示する側に該当するためです。ルールは次のように対称です。

• 権限確認プロンプトを表示する受信セッションには、すべてのメッセージが配信されます。ただし、送信セッションがプロンプトを回避していると申告した場合だけ、メッセージを保留します。
• プロンプトを回避する受信セッションは、すべてのメッセージを承認待ちにします。送信側も回避している場合だけ、メッセージを配信します。

そのため、多くの人が最初に構築するワークフローは、まさに動作しない構成です。無人で実行したいので --permission-mode bypassPermissions を指定して builder を起動し、reviewer はデフォルトのままにすると、builder が送信するすべてのメッセージが、誰も確認していない承認ダイアログで待機します。そのダイアログは dialogExpiry の期限が経過すると閉じます。デフォルト値は 5m です。その時点でメッセージは破棄されます。同じマシン上では、送信セッションにメッセージが保留された時点で通知が表示され、受信側が後で配信、拒否、期限切れにした時点でも追加の通知が表示されます。そのため、ソケットを疑う前に送信側の画面を確認してください。

セッションでメッセージを無人で受信するには、crossSessionInbound を accept に設定します。設定場所によって適用範囲が決まります。Claude Code は、まず managed settings、次に --settings flag、最後に user settings を読み込み、最初に見つかった値を適用します。project または local settings の値は、accept < hold < refuse の優先度で、より厳しい値の場合にだけ適用されます。.claude/settings.json にある accept は、どの値よりも緩いため、信頼されたソースで値が設定されている場合は無視されます。~/.claude/settings.json に設定するか、1回のセッションに限って指定します。

claude --name runner --settings '{"crossSessionInbound":"accept"}'

headless claude -p worker は interactive session と同じように inbox socket をバインドし、一覧にも表示されます。ただし、承認ダイアログを表示できません。ここで保留されたメッセージは、後でモードまたは設定が変更されて受信可能になるまで保留されたままです。上記の --settings 行は、このような worker にメッセージを受信させるための設定です。bare mode で起動したセッションはソケットをまったくバインドしないため、メッセージを受信できず、一覧にも表示されません。

引き継ぎが行き詰まる場合

メッセージのループは自動的に処理されます。Claude Code は送信元ごとに繰り返しメッセージをレート制限し、短時間内に届いた同一メッセージの重複を破棄します。また、1 セッションで読み取り待ちとして受け付けるメッセージを 50 件までに制限するため、2 つのセッションが無限に ping-pong することはありません。保留中のメッセージは 100 件までで、それを超えると古いものから破棄されます。

実際に起きる障害は、より気付きにくい引き継ぎです。ループではありません。セッション A が、続行する前に回答を必要とする質問をセッション B に送り、その後アイドル状態になります。B がメッセージを保留している場合もあれば、時間のかかる処理の途中である場合もあります。あるいは、A が実際には尋ねていない質問に B が回答することもあります。A は待ち続けます。1 時間後に戻ると、2 つのセッションがアイドル状態のままで、作業は進んでいません。

返信を必要としない引き継ぎを書いてください。良いメッセージには、事実または決定事項が含まれます。何が変わり、結果がどうなったかを伝えます。悪いメッセージは、別のセッションに許可や、送信元が回答を得るまで先に進めない質問への回答を求めます。Claude には、別のセッションの権限設定で拒否される操作をそのセッションに依頼せず、その作業をあなたに戻すよう、すでに指示されています。このルールを自分の運用にも適用してください。回答がなければセッションが進められない場合は、あなたが回答する担当者です。ここでもコンテキストの管理が役立ちます。作業の流れを見失ったセッションは、曖昧なメッセージを書きやすくなります。その点については、Claude Code でコンテキストを管理するで説明しています。

受信メッセージは信頼できない入力として扱う

Claude Code は、受信側の Claude に対して、そのメッセージがあなたではなく別のセッションから送られたことを伝えます。また、そのメッセージで実行できる操作を制限します。この制御は、モデルが従う意思ではなく、モデルを包むプログラム側で行われます。これが、エージェントハーネスが実際に果たす役割です。別のセッションからの同意はあなたの同意ではないため、メッセージで保留中の権限プロンプトに代わって回答することはできません。別のセッションから要求されたという理由だけで、権限設定、CLAUDE.md、その他の設定を変更することもできません。/compactのようなスラッシュコマンドが本文に含まれていても、プレーンテキストとして届くだけで、実行されることはありません。メッセージへの対応に、受信側セッションが持っていない権限が必要な場合は、他の作業と同じプロンプトが表示されます。auto モードでは、配信前に各メッセージを classifier も確認します。classifier がブロックしたメッセージは受信側に届きません。これらの制限は、許可範囲の広いモードでも維持されます。そのため、bypass 中のセッションは受信メッセージをデフォルトで保留し、信頼することはありません。

これは権限についての説明です。内容については別の注意が必要です。送信側セッションが、Pull Request の説明、Web ページ、依存関係の README、または第三者が書いた issue コメントを読んでいる可能性があります。そこで読んだ内容が、別のセッションに送るテキストへ影響することがあります。メッセージはデータです。セッションの外部から入ってきた他のテキストと同じように、疑って扱う必要があります。これはAI エージェントから Secret を排除する際の原則です。信頼境界を越えたものは誤っている可能性があると考え、自身に権限を与えさせないでください。

この動作を減らすための制御が2つあります。crossSessionInboundをrefuseに設定すると、受信側の peer メッセージを配信せずに破棄します。project または local の設定では、この値が他のすべての設定元より優先されます。設定階層の中で最も厳しい値だからです。このセッションからの送信または一覧表示を停止するには、SendMessageとListAgentsを指定する permission deny ルールを追加します。どちらも specifier を付けず、ツール名だけを記述します。isolatePeerMachinesをtrueに設定すると、このマシンの外部にあるセッションへメッセージを配信する前に、明示的な承認が必要になります。この承認はbypassPermissionsモードでも必要です。

{
  "crossSessionInbound": "refuse",
  "isolatePeerMachines": true
}

SendMessageを拒否すると、同じツールが使用されるため、subagent へのメッセージ送信も無効になります。拒否したセッションの/statusや、他のセッションの一覧表示には、目に見える変化がありません。そのため、画面ではなくセッションの設定から値を確認してください。

ブリッジと共有メモリ MCP サーバー

同じ時期に、関連する別の形態を持つサードパーティープロジェクトもいくつか登場しました。実行中のエージェント間でテキストを中継するローカルのエージェント間ブリッジや、複数のエージェントが読み書きできる共有ストアを提供する MCP（model context protocol）サーバーです。これらは競合製品ではなく、異なる構成として評価してください。実行前に、インストールコマンドがプロジェクト独自の README に記載された内容と一致することを確認してください。メッセージングは push です。送信側が受信側のターンにテキストを書き込むためです。共有ストアは pull です。どのセッションも中断されず、次に確認した時点でノートを読み取るためです。変化が遅い状態の共有には pull のほうが適しており、セッションが実際に確認した場合にだけ機能します。

この方式を選ぶ場合、確認すべき点は機能一覧ではなくプロセスです。サーバーはどのユーザーとして実行され、サーバー上のどのデータを読み取れるのでしょうか。VPS 上で MCP サーバーを実行する では、その構成を説明しています。リポジトリ間でエージェントのスキルを共有する では、セッション間で共有したいものがライブ状態ではなく手順である、より単純なケースを説明しています。この方法を使うと、通常なら送信する多くのメッセージを減らせます。全体像を確認するには、VPS 上でコーディングエージェントを実行する から始めてください。

FAQ

/list-agents がセッションで認識されないのはなぜですか？

セッション間メッセージングが有効になっていません。まず claude --version が 2.1.224 以降か確認してください。この機能にはそのバージョン以降が必要です。次にプラットフォームを確認してください。この機能は macOS と Linux で動作しますが、ネイティブの Windows では動作しません。また、Amazon Bedrock、AWS の Claude Platform、Google Cloud の Agent Platform、Microsoft Foundry では利用できません。どちらにも問題がなければ、シェルに DO_NOT_TRACK、DISABLE_TELEMETRY、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC、または DISABLE_GROWTHBOOK がないか確認してください。これらはいずれも、この機能が依存する機能フラグの評価をブロックし、機能を無効のままにします。

他のセッションに送ったメッセージが届かなかったのはなぜですか？

/list-agents が動作するなら、メッセージングは有効で、別の原因によってそのメッセージだけが止まっています。よくある原因は権限モードです。権限プロンプトをバイパスするセッションは、送信側もバイパスしていない限り、受信したすべてのメッセージを承認待ちにします。この承認ダイアログは、デフォルトで 5 分間の dialogExpiry を過ぎると破棄されます。送信側のセッションで保留通知を確認してください。修正するには、~/.claude/settings.json で crossSessionInbound を accept に設定するか、--settings で渡してください。プロジェクト設定またはローカル設定にある accept は、より緩い値として無視されるためです。

Docker 内の Claude Code セッションからホスト上のセッションにメッセージを送信できますか？

いいえ。セッションはディスク上の登録ファイルとセッションごとの inbox socket を使って相互に検出します。コンテナは独自のファイルシステムを持つため、両者は同じファイルを参照できません。同じコンテナ内の 2 つのセッションなら、通常どおり相互にメッセージを送信できます。同じ規則により、root として実行されているセッションと、通常のユーザーとして実行されているセッションも相互に接続できません。socket へのアクセスは、それを所有するオペレーティングシステムのユーザーに制限されているためです。

別の Claude Code セッションからのメッセージは安全に実行できますか？

そのテキストは信頼できない入力として扱ってください。送信側のセッションが、他者の Web ページ、README、issue コメントを読み取っている可能性があるためです。Claude Code は、メッセージが単独で操作を実行することをすでに防止しています。保留中の権限プロンプトを承認することはできません。要求に応じて権限設定や CLAUDE.md を変更することもできません。テキスト内の slash command はプレーンテキストとして届き、実行されません。これらの保護は権限を対象とするもので、判断そのものを対象とするものではありません。受信セッションに操作を指示する前に、届いた内容を確認してください。

セッション間メッセージングでコードが Anthropic に送信されますか？

同じマシン上の 2 つのセッション間では、送信されません。メッセージはそのマシン上のセッションごとの socket を通過し、Anthropic のサーバーを経由しません。送信されるのは Claude が書いたテキストだけで、会話履歴やファイルは送信されません。別のマシン上のセッション、または Web 上のセッションに送るメッセージは、Remote Control 接続を介して Anthropic のサーバーを経由します。その方向では、Claude は届いたメッセージに返信することしかできず、自分からメッセージを開始することはできません。マシン外へ送信する前に承認を求めるには、isolatePeerMachines を true に設定してください。