Claude Code のセッション間メッセージング

v2.1.224 以降、Mac や Linux 上で対話的に起動した Claude Code のセッションは、起動と同時に Unix ソケットをバインドします（筆者の環境では /tmp/cc-socks/38590.sock に、所有者だけがアクセスできる権限で作られていました）。ほかのセッションからは、そこへテキストメッセージを投げ込めます。¹ 機能を支えるのは2つのツールです。ListAgents が到達可能な自分のセッションを探し、SendMessage が名前を指定して届けます。² 有効化も設定も不要です。同じマシン上で双方が v2.1.224 以降であれば、すでに会話できる状態になっています。

要点

Claude Code のセッション同士が連絡を取れるようになりました。同一マシン上では Anthropic のサーバーを一切経由しないローカルソケットで、マシンをまたぐ場合は Remote Control 経由で届きます。後者は当初は返信専用でしたが、v2.1.225 で名前を指定して会話を始められるようになりました。¹⁵ 送れるのはプレーンテキストだけで、会話履歴もファイルも権限も渡りません。受け取った側はそれを入力として受け止めるだけで、権限として扱うことはありません。つまり、許可プロンプトへの承認も、設定の変更も、コマンドの実行もできないのです。¹ この機能は、ばらばらに動く端末の群れをチームに近いものへ変えます。真価を発揮するのは、これまで人が手で運んでいた連絡事項です。「マイグレーションが終わった」「あのカラム名を変えた」「main は今なら rebase して大丈夫」といったたぐいのものですね。最大の落とし穴は、何も言わずに消えることです。プライバシー関連の環境変数4つが、それぞれ単独でこの機能を黙って無効にします。³

リリース内容

v2.1.224 では、macOS と Linux 向けにセッション間 SendMessage と ListAgents による探索が追加されました。続く v2.1.225 では、これまで返信しかできなかった別マシンの Remote Control セッションに対して、こちらから会話を始められるようになっています。⁴⁵

裏側の仕組みは、3つの窓から確認できます。

• /list-agents（別名 /peers）は、Claude が到達できるセッションをすべて一覧します。現在のセッション内のサブエージェント、バックグラウンドを含む自分のほかのローカルセッション、そして Remote Control 接続中であれば別マシンのセッションと Web 版 Claude Code のセッションまで含まれます。¹
• /status には Peer address の行が現れ、そのセッション自身の受信ソケットが uds: 付きで表示されます。¹
• CLAUDE_CODE_MESSAGING_SOCKET は、すべてのフックと Bash コマンドに渡される環境変数で、そのセッション自身のソケットのパスを保持します。⁶ これが効いてくる理由は後述します。

手元での確認結果です。v2.1.226 で動いているセッションからは、ピアとなる2つのセッションが状態（「busy」）と経過時間つきで一覧されました。ソケットファイルの権限は srw-------、つまり読み書きできるのは自分のユーザーだけです。共用マシンではこの権限が境界線になります。¹

セッションは名前で呼びます。/rename か --name フラグで付けられますし、指定しなければ Claude Code が作業ディレクトリから myapp-3f のような名前を導き出します。¹ 名前が衝突した場合は、作業ディレクトリと短い識別子で区別して表示されます。¹

面白いのは信頼モデルのほう

多くのマルチエージェント設計が答えを外している問いに、Anthropic の設計は正面から答えています。ほかのエージェントからのメッセージには、いったいどれだけの重みがあるのか。答えは明快です。メッセージは情報であって、権限ではありません。¹

セッション A がセッション B に送るとき、届く内容には4つの制約がかかります。¹

1. 何も承認できません。 B に許可プロンプトが出ていても、A の言うことは一切無視されます。プロンプトに答えるのは人間だけです。
2. 設定を変更できません。 受信側の Claude には、ほかのセッションに言われたからといって権限設定や CLAUDE.md、その他の設定を書き換えてはならない、と指示されています。
3. コマンドはテキストとして届きます。 本文中の /compact は実行されるコマンドではなく、ただの4文字の文章です。
4. 許可プロンプトは通常どおり出ます。 メッセージに沿って動くのに B が持たない権限が要るなら、ほかの作業と同じようにプロンプトが表示されます。

受信側にも独自の関門があります。届いたメッセージは必ず、配信・保留（あなたの承認待ち）・拒否のいずれかに落ち着き、これを決めるのが crossSessionInbound 設定（accept、hold、refuse）です。¹ 何も設定しない場合、Claude Code は2つのセッションの権限モードを見てメッセージごとに判断します。この既定のロジックが巧みです。許可プロンプトを迂回するセッションを一方の区分、それ以外をもう一方の区分と見なすのです。プロンプトを出すセッションはメッセージを自由に受け取りますが、迂回モードのセッションから来たものは保留します。迂回モードのセッションは、同じく迂回モードの相手からのもの以外はすべて保留します。¹ この非対称は意図的なものです。メッセージが緩い権限に便乗してはならない——v2.1.224 はこの原則を受信側に当てはめました。送信側には v2.1.222 が先に適用しており、auto モードでは送信前に権限分類器が1件ずつ検査します。⁷

保留されたメッセージは承認ダイアログを開き、送信元とプレビューを表示します。答えないまま5分が過ぎると（dialogExpiry で調整可能）ダイアログは期限切れとなり、メッセージは破棄されます。¹ 同時に保留できるのは最大100件です。¹ さらに絞り込む制御が2つあります。isolatePeerMachines: true を立てると、bypassPermissions モードであってもマシン外へ出るメッセージには明示的な承認が必要になります。しかもどの設定スコープであれ true が優先されるため、リポジトリに入っているプロジェクト設定ファイルは制限を強めることはできても緩めることはできません。¹ 組織として完全に封じたい場合は、SendMessage と ListAgents への拒否ルールに加えて、管理設定で crossSessionInbound: "refuse" を指定します。¹

メッセージが通る経路

相手のセッションがどこで動いているかによって、経路も送れる内容も変わります。¹

ドキュメント間の食い違いを1点だけ挙げておきます。本稿執筆時点で、Anthropic のセッション間メッセージングのページはマシンをまたぐ通信をすべて返信専用と説明していますが、v2.1.225 のリリースノートには SendMessage が「別マシンの Remote Control セッションに対して、名前を指定して会話を始められるようになった」と書かれています。新しいのはリリースノートのほうで、ドキュメントページが追いついていません。¹⁵

「同一マシン」の判定基準は、ファイルシステムが見えているかどうかです。各セッションはディスク上のファイルに自分を登録するため、同じファイルが見える者同士でなければ届きません。コンテナの中のセッションとホスト側のセッションは会話できませんが、同じコンテナ内のセッション同士なら可能です。¹

配信は受信側のリズムを尊重します。ターン実行中であればツール呼び出しの合間に読まれ、実行中のツールを中断することはありません。アイドル状態なら新しいターンが始まります。¹ 配信されたメッセージは、自分で打ったプロンプトと同じように使用量に計上されます。¹

作り込む価値のある5つのパターン

1. worktree の連携。 真っ先に思いつく用途であり、公式ドキュメントが自らの例文で示している場面でもあります。同じリポジトリを別々の worktree で扱うセッション同士が、何が入ったかを伝え合うのです。¹「スキーマのマイグレーションが完了。新しいカラムは tenant_id で、main への rebase はもう安全です」——これはドキュメントに載っている例文そのもので、放っておけば人間が気づいて端末を切り替え、打ち直す羽目になる類の更新です。worktree ではなく1つのチェックアウトを複数セッションで共有しているなら、この連絡の価値はさらに上がります。「これから content/guides/ をコミットするので、そちらではステージしないでください」の一言が、あるセッションが別のセッションの書きかけをコミットしてしまう、共有ツリーの古典的な事故を防ぎます。

2. 見張り役と作業役。 デプロイやテストスイート、ログを監視する専用のセッションを走らせ、異変を検知した瞬間に修正担当のセッションへ連絡させます。受け取った側にとって、それは命令ではなく判断材料です。自分の権限の範囲で、どうするかは自分で決めます。バックグラウンドセッションと通知フックを組み合わせれば、本当に必要なときにだけ人間まで上がってくるエスカレーションの連鎖ができあがります。

3. 長時間処理からの報告。 マイグレーションや長いテスト実行を1つのセッションで走らせ、あなたが実際に見ているセッションへ結果を報告させます。¹ 進捗が、存在を忘れた端末の中に埋もれることはなくなります。逆向きも同様に機能します。見ている側から「別の端末のセッションに、マイグレーションが終わったか聞いてみて」と頼めばよいのです。探索も宛先の指定も文面も、Claude が自分で処理します。¹

4. 無人の作業役の群れ。 ヘッドレスの claude -p セッションも受信ソケットをバインドするので、長時間動く -p の作業役がメッセージを受け取れますし、一覧にも現れます。⁸ ただし注意点があります。-p のセッションは承認ダイアログを出せないため、保留されたメッセージは保留のまま、設定かモードを変えない限り配信される道がありません（v2.1.225 では、そうしたメッセージが通知も期限切れもないまま滞留する不具合も修正されました）。無人でメッセージを受ける作業役を立てるなら、その --settings の中で crossSessionInbound: "accept" を指定して起動してください。ユーザー設定に accept を書くと起動するすべてのセッションに効いてしまいますが、この方法なら作業役ごとの許可で済みます。⁸ なお、bare モードのセッションはソケット自体を作らないため、到達できません。⁸

5. スクリプトからの投函。 目立たないながら最も強力なのがこれです。CLAUDE_CODE_MESSAGING_SOCKET がフックと Bash コマンドに渡されているので、スクリプトからセッション自身の受信箱へ投函できます。⁶ Claude Code は自分の子プロセスからのメッセージを検証しており、明示的な crossSessionInbound 設定がなければ、フックやコマンドが自セッションへ投げたものは手続きなしで配信されます。¹ 夜間ジョブ、git フック、CI のラッパー——Unix ソケットに書き込めるものなら何でも、自分を起こしたセッションへ文脈を1行差し込めるようになったわけです。Linux では投函したプロセスが終了したあとでも検証は成立しますが、macOS では動作中に限られます。Claude Code が PID 1 になっているコンテナ内では検証に失敗し、通常の受信ルールにフォールバックします。¹ サンドボックス下のコマンドから使う場合は、sandbox.network.allowUnixSockets でソケットを許可する必要があります。¹

この機能があえて引き受けないこと

これらの限界は設計上の判断です。素直に受け入れておけば、見当違いのものを作らずに済みます。

承認の経路ではありません。 信頼モデルのすべては、あるセッションが別のセッションの行動を認可してしまう事態を防ぐためにあります。「セッション A が承認し、セッション B が実行する」という形の流れは、明確に排除されています。権限は常に人間を通してください。¹

文脈の受け渡しでもありません。 メッセージは、ある Claude が別の Claude に書くテキストであって、会話履歴でもファイルでもありません。Anthropic のドキュメントも端的に書いています。会話そのものを移したいなら、そのセッションを再開しなさい、と。¹ 要約して渡すこと。丸ごと流し込まないことです。

エージェントチームでもありません。 独立したセッション同士のやりとりは、あくまでピアツーピアの用途です。Claude が自ら起こして監督する統率されたチーム——構造化されたプロトコルメッセージ、名簿、共有されたタスク状態——はエージェントチーム（agent teams）機能の領分であり、構造化されたチームメッセージは意図的にチームの外へ出ません。¹ セッション間のテキストの上に独自のメッセージプロトコルを設計し始めていると気づいたら、あなたが求めているのはエージェントチームです。

チャットの往復でもありません。 Claude Code は送信元ごとに繰り返しメッセージへレート制限をかけ、短時間に届いた同一内容は破棄し、未読の受理済みメッセージを1セッションあたり50件で打ち切ります。2つのセッションの間でメッセージの往復が始まっても、設計上そこで先細りするわけです。¹ 作るべきは要求と応答のやりとりであって、おしゃべりではありません。

落とし穴

プライバシー関連の変数が黙って無効化します。 セッション間メッセージングは機能フラグの評価に依存しており、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC、DISABLE_TELEMETRY、DO_NOT_TRACK、DISABLE_GROWTHBOOK のいずれかがその評価を止めてしまうと、道連れでメッセージングも落ちます。しかも何の通知もありません。³ 切り分けには /list-agents を使いましょう。コマンド自体が認識されないなら、そのセッションには機能そのものがありません。動くのに送ったメッセージが届かないなら、もっと狭い原因——拒否ルール、受信側の受信制御、あるいは返信しか受け付けない相手先——を疑うことになります。¹

プラットフォームとプロバイダーの穴。 Windows ネイティブは非対応です（WSL 2 内の Linux なら動作します）。Amazon Bedrock、AWS 上の Claude Platform、Google Cloud の Agent Platform、Microsoft Foundry でも利用できません。¹

返信が一方通行になる際どい場面。 別マシンのセッションへの返信は、返信元が Remote Control に接続していない状態で送っても相手には届きます。ただし返信先の住所が付かないため、受け取った側は答えられません。Claude は送信時にその旨を知らされますし、v2.1.225 の修正で宛先解決が厳密になり、確定した別マシンの宛先が同名のローカルセッションに黙って置き換わることはなくなりました。⁵

ヘッドレスでの滞留。 -p の作業役が理由もなくメッセージを無視しているように見えるとき、ほぼ確実に保留の問題です。ダイアログが出ないので、配信もされません。受け取らせたい作業役には crossSessionInbound: "accept" を設定してください。⁸

まとめ

Claude Code を日常的に使う人へ: - まず一度 /list-agents を実行して、自分のセッションがどこまで届くのかを見てください。重要なセッションには /rename で名前を付けておくと、宛先の指定がすっきりします。 - 依頼は普通の言葉で構いません（「決済まわりを見ているセッションに、変更点を伝えて」）。文面は Claude が自分で書きます。¹

自動化を組む人へ: - CLAUDE_CODE_MESSAGING_SOCKET を使って、フックやスクリプトからセッションへ投函しましょう。自分の子プロセスからのメッセージは、Linux なら承認の手間なしで届きます。¹⁶ - 無人の -p 作業役には、グローバル設定ではなくその作業役自身の --settings で crossSessionInbound: "accept" を与えてください。⁸

チームとセキュリティ担当者へ: - 既定値は妥当な線に置かれています。メッセージは権限を運ばず、迂回モードのセッションは既定で隔離され、isolatePeerMachines と管理設定の拒否ルールによってマシン単位と組織全体の停止スイッチが手に入ります。¹ - メッセージングが壊れたと結論づける前に、例のプライバシー環境変数4つを確認してください。そして、拒否設定のセッションは相手側から見て何ら違いが見えないことも覚えておきましょう。¹

参考文献