著者 Claude Codeでセッション間にメッセージを送る方法
Claude Code v2.1.224以降で使えるcross-session messagingを解説します。ListAgentsとSendMessageの役割、2つ目のセッションが有効な場面、メッセージが保留される理由を確認できます。
Claude Code セッション同士のメッセージ送信の仕組み
2 つの Claude Code セッションは、同じマシン上で同じオペレーティングシステムユーザーとして実行されている場合、相互にメッセージを送信できます。メッセージは、一方の Claude がもう一方に送るプレーンテキスト 1 件です。会話履歴やファイルは含まれません。Claude は ListAgents ツールで相手のセッションを見つけ、SendMessage でテキストを送信するため、ユーザーがどちらのツールを手動で呼び出す必要もありません。相手のセッションに伝える必要がある内容を指示すると、Claude がメッセージ自体を作成します。
この機能は cross-session messaging と呼ばれます。2026 年 8 月時点では Claude Code v2.1.224 以降が必要で、macOS と Linux で動作します。Linux は WSL 2 内の環境も含みます。ネイティブの 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つの作業が互いを待たずに同時進行し、その途中で一方が、もう一方に必要な情報を得ます。
- 一方のセッションが破壊的変更を見つけ、もう一方がその変更で壊れたコードを基に作業している場合です。Claude は変更内容を要約して送信するため、別の端末で再入力する必要がありません。
- 2つのセッションが、別々の git worktree で同じリポジトリを操作し、一方が取り込まれた変更を把握する必要がある場合です。
- 長時間の移行やテストの実行結果を、監視しているセッションへ返す場合です。
- builder セッションと reviewer セッションを使う場合です。reviewer は builder が生成した内容を読み取り、確認結果を返します。
作業が順番に進む場合や、両方のセッションで同じファイルを編集する場合は、1つのセッションを使用します。Claude が1つのタスク内で起動し、監督する連携グループを使いたい場合は、agent teams です。これは別の機能で、現在も実験的な段階です。別の端末で同じ会話を続けたいだけの場合は、セッションを resume します。セッション間メッセージングは、自分で開始し、指示する独立したセッション向けの機能です。
機能を前提にする前に、利用可能か確認する
まずバージョンを確認します。
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 マップや管理対象設定から指定される場合もあります。まずシェルの環境を確認してください。
env | grep -E 'DO_NOT_TRACK|DISABLE_TELEMETRY|DISABLE_GROWTHBOOK|NONESSENTIAL'値が表示された変数の設定を解除します。DISABLE_TELEMETRY と CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC では、空でない値を指定すると動作が有効になります。0 という文字列も同様です。そのため、DISABLE_TELEMETRY=0 は見た目どおりの動作になりません。無効にするには、変数の設定を解除するか、空文字列を設定します。
セッションに名前を付けないと、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 になるため、コミットせずに読み取りを行うセッションに適しています。
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 agentsCtrl+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 ターンでレビューを完了しやすくなるためです。この習慣を徹底するために 怠け者のシニア開発者スキル が存在します。
同じ VPS 上で、誰が誰を認識できるか
同じマシン内の配信が Anthropic のサーバーを経由することはありません。各セッションは登録ファイルをディスクに書き込み、自身の inbox ソケットをバインドします。Claude Code はそれらのファイルを読み取り、他のセッションを探します。サーバー上では、次の2点に注意が必要です。
ソケットへのアクセスは、オペレーティングシステムのユーザーに制限されます。root として開始したセッションと、deploy として開始したセッションは、同じ tmux サーバー内で隣り合っていても互いを認識できません。一方のユーザーのセッションから、もう一方のユーザーのソケットにアクセスできないためです。両方のセッションを同じユーザーとして実行してください。
コンテナには独自のファイルシステムがあります。Docker 内のセッションとホスト上のセッションは、同じ登録ファイルを読み取らないため、互いに接続できません。同じコンテナ内の2つのセッションは、通常どおりメッセージを交換できます。使い捨て VM でコーディングエージェントを実行する場合のように、分離のためにエージェントをコンテナ内で実行するなら、メッセージ交換はコンテナ内では機能しますが、コンテナ境界を越えては機能しないと考えてください。
他のマシン上のセッションや Web 上のセッションは、Remote Control の接続中だけ一覧に表示され、そのようにラベル付けされます。ここにいる Claude は、そのいずれかから届いたメッセージにのみ返信できます。この側から通信を開始することはできません。
メッセージが届かなかった理由
通常の原因はネットワークとは関係ありません。受信側のセッションがメッセージの処理方法を決定し、配信しないという判断をしたためです。到着したメッセージの結果は、配信、保留（承認するまで配信せずに取っておく）、拒否（配信せずに破棄）の3つのいずれかになります。
crossSessionInbound の値が適用されない場合、Claude Code は2つのセッションの権限モードを比較して、メッセージごとに処理を決定します。権限プロンプトをバイパスするセッションを1つのクラスにまとめ、それ以外のセッションをもう1つのクラスにまとめます。auto、acceptEdits、dontAsk はプロンプトを表示するモードとして扱われます。Plan mode は、バイパス権限を利用できるセッションでは、バイパスとして扱われます。ルールは次のように対称です。
- 権限プロンプトを表示する受信側セッションでは、各メッセージが配信されます。ただし、送信側セッションがプロンプトをバイパスすると示した場合だけ、メッセージを保留します。
- プロンプトをバイパスする受信側セッションでは、すべてのメッセージが承認待ちになります。ただし、送信側もバイパスする場合だけ、メッセージを配信します。
そのため、多くの人が最初に構築するワークフローは、まさに機能しない構成です。無人で実行したいため --permission-mode bypassPermissions で builder を起動し、reviewer はデフォルトのままにすると、builder が送信したすべてのメッセージが、誰も確認していない承認ダイアログで待機します。そのダイアログは dialogExpiry の期限が経過すると閉じます。デフォルト値は 5m です。期限が切れると、メッセージは破棄されます。同じマシン上では、送信側セッションにメッセージが保留された時点で通知が表示され、受信側が後から配信、拒否、または期限切れにした時点で追加の通知が表示されます。そのため、ソケットを疑う前に送信側の画面を確認してください。
セッションでメッセージを無人で受信するには、crossSessionInbound を accept に設定します。どこで設定するかによって、適用範囲が決まります。Claude Code はまず managed settings を読み取り、次に --settings フラグ、最後に user settings を読み取ります。そして、最初に見つかった値を適用します。project settings または 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 は送信元ごとに繰り返しメッセージをレート制限し、短い時間内に届いた同一メッセージを破棄します。また、セッションごとに読み取り待ちとして受け付けるメッセージを 50 件までに制限するため、2 つのセッションが無限に ping-pong を続けることはありません。保留中のメッセージは 100 件までで、それを超えると古いものから破棄されます。
実際に起きる障害は、より静かで、ループではなく引き継ぎに関するものです。セッション A が、処理を続ける前に回答が必要な質問をセッション B に送り、その後アイドル状態になります。B がメッセージを保留したままにする場合もあれば、時間のかかる処理の途中である場合もあります。また、B が A の意図とは異なる質問に回答する場合もあります。A は待機します。1 時間後に戻ると、2 つのセッションがアイドル状態のままで、作業がまったく進んでいないことがあります。
返信を必要としない引き継ぎメッセージを書いてください。良いメッセージは、事実または決定を伝えます。つまり、何が変わり、結果がどうなったかを示します。悪いメッセージは、相手の許可や、送信元が処理を進めるために必要な回答を求めます。Claude には、別のセッションに対して、自身の権限設定で許可されない操作を依頼しないよう、すでに指示されています。その場合は、代わりにあなたへ作業を戻します。このルールを自分の運用にも適用してください。回答がなければセッションが進められない場合は、あなたが回答するべきです。ここではコンテキストの管理も役立ちます。コンテキストの流れを失ったセッションは、曖昧なメッセージを書きやすくなります。この点については、Claude Code でコンテキストを管理するで説明しています。
受信メッセージは信頼できない入力として扱う
Claude Code は、受信側の Claude に対して、そのメッセージがあなたではなく別のセッションから送られたことを伝えます。また、そのメッセージで実行できる操作も制限します。別のセッションからの同意はあなたの同意ではないため、メッセージによって保留中の権限確認プロンプトに代わりに回答することはできません。別のセッションから要求されたという理由だけで、権限設定、CLAUDE.md、その他の設定を変更することもできません。/compact のようなスラッシュコマンドが本文に含まれていても、プレーンテキストとして届くだけで、実行されることはありません。メッセージへの対応に受信側セッションが持っていない権限が必要な場合は、他の作業と同じ確認プロンプトが表示されます。自動モードでは、配信前に分類器も各メッセージを確認します。分類器がブロックしたメッセージは受信側に届きません。これらの制限は許可範囲の広いモードでも維持されます。そのため、バイパスを行うセッションは、受信メッセージを信頼せず、デフォルトで保留します。
これは権限についての説明です。内容については別に考える必要があります。送信側セッションが、プルリクエストの説明、Web ページ、依存関係の README、または第三者が書いた issue コメントを読んでいる可能性があります。そして、読んだ内容が、別のセッションへ送るテキストに影響する可能性があります。そのメッセージはデータです。外部からセッションに入った他のテキストと同じように、疑って扱う必要があります。これは AI エージェントから秘密情報を遠ざける で説明している原則です。信頼境界を越えたものはすべて誤っている可能性があると考え、それ自体に権限を与えないでください。
このようなメッセージを減らすには、2 つの制御方法があります。crossSessionInbound を refuse に設定すると、受信側のピアメッセージを配信せずに破棄します。プロジェクト設定またはローカル設定でこの値を指定すると、他のすべての設定元より優先されます。設定の優先順位で最も厳しい値だからです。このセッションからの送信または一覧表示を停止するには、SendMessage と ListAgents を指定する権限拒否ルールを追加します。どちらも指定子を付けず、ツール名だけで記述します。isolatePeerMachines を true に設定すると、このマシンの外にあるセッションへメッセージを配信する前に、明示的な承認が必要になります。この承認は bypassPermissions モードでも必要です。
{
"crossSessionInbound": "refuse",
"isolatePeerMachines": true
}SendMessage を拒否すると、同じツールがサブエージェントにも使用されるため、サブエージェントへのメッセージ送信も無効になります。拒否したセッションの /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 が動作する場合、メッセージング自体は有効であり、より限定的な原因によってそのメッセージが停止しています。よくある原因は権限モードです。権限プロンプトをバイパスするセッションは、送信側もバイパスしていない限り、受信したすべてのメッセージを承認待ちにします。その承認ダイアログは dialogExpiry の期限後に破棄されます。デフォルトは 5 分です。送信側のセッションに保留通知が表示されていないか確認してください。修正するには、~/.claude/settings.json で crossSessionInbound を accept に設定するか、--settings で指定してください。プロジェクトまたはローカル設定にある accept は、より緩い値として無視されます。
Docker 内の Claude Code セッションからホスト上のセッションにメッセージを送信できますか？
いいえ。セッションはディスク上の登録ファイルと、セッションごとの inbox socket を介して互いを検出します。コンテナには独自のファイルシステムがあるため、両者は同じファイルを参照できません。同じコンテナ内にある 2 つのセッション同士なら、通常どおりメッセージを送信できます。同じ規則により、root として実行されるセッションと、通常のユーザーとして実行されるセッションも互いに到達できません。socket は、それを所有するオペレーティングシステムユーザーに制限されるためです。
別の Claude Code セッションからのメッセージを安全なものとして扱えますか？
テキストは信頼できない入力として扱ってください。送信側のセッションが、他者の Web ページ、README、Issue コメントを読み取っている可能性があるためです。Claude Code は、メッセージが単独で操作を実行することをすでに防いでいます。保留中の権限プロンプトを承認することはできません。要求に応じて権限設定や CLAUDE.md を変更することもできません。テキスト内のスラッシュコマンドはプレーンテキストとして届き、実行されません。これらの保護は権限を対象とするものであり、判断そのものを対象とするものではありません。そのため、受信セッションに操作を指示する前に、届いた内容を確認してください。
セッション間メッセージングでコードが Anthropic に送信されますか？
同じマシン上にある 2 つのセッション間では、送信されません。メッセージはそのマシン上のセッションごとの socket を経由し、Anthropic のサーバーを通りません。送信されるのは Claude が記述したテキストだけであり、会話履歴やファイルは送信されません。別のマシン上のセッション、または Web 上のセッションに送るメッセージは、Remote Control 接続を介して Anthropic のサーバーを通ります。この方向では、Claude は届いたメッセージに返信することだけができ、自分からメッセージを開始することはできません。マシン外への送信前に承認を必須にするには、isolatePeerMachines を true に設定してください。