Anthropicは、Claude Codeの独立したセッション同士がテキストを送り合う「cross-session messaging」を追加した。2026年8月7日に公開されたv2.1.224以降、複数のターミナルやworktreeで別々に動くClaudeが相手を見つけ、作業中に得た知見や判断を直接渡せる。これまで利用者が担っていた端末間の転記を、Claude自身が引き受ける仕組みだ。ただし、共有されるのはテキストであり、会話履歴やファイル、操作権限までは相手へ移らない。
v2.1.224で独立セッションが互いを見つける
新機能を支えるのは、到達可能な相手を探すListAgentsと、名前を指定してテキストを送るSendMessageである。利用者がこの2つのツールを直接操作する必要はない。「フロントエンド側のセッションにAPI変更を伝えて」と頼めば、Claudeが宛先を特定し、必要な内容を文章にして送る。別セッションの作業に影響する変更を見つけた場合には、Claudeが自ら連絡することもある。
想定されているのは、同じリポジトリを複数のworktreeに分けた並列開発だ。あるセッションがAPIの破壊的変更を見つけたとき、依存する実装を進める別セッションへ先回りして知らせられる。時間のかかる移行処理やテストを走らせたセッションから、監視中のセッションへ進捗を返す用途にも向く。判断待ちで止まった作業へ、答えを得た側から連絡することも可能だ。
受信側が処理中なら、メッセージはツール呼び出しの切れ目で読まれる。実行中のコマンドを割り込ませる仕組みではない。受信側がアイドル状態なら、そのメッセージを起点に新しいターンが始まる。並列作業を続けたまま連絡できる一方で、いつ届いても処理を中断する割り込みにはならない設計である。
共有するのは履歴ではなく、テキスト
同じマシン上の通信は、セッションごとに作られる受信用ソケットを通る。Claude Codeはセッションの登録情報をディスクへ置き、受信用ソケットをOSユーザーに制限する。ローカルのメッセージはAnthropicのサーバーを経由しない。2つのセッションが同じ登録ファイルを参照できることが前提なので、ホスト側と別コンテナ内のセッションは互いを発見できない。同じコンテナ内で動く2セッションなら通信できる。
通信経路と送れる内容は、相手がどこにいるかで変わる。
| 相手の場所 | 通信経路 | ローカル側からできること |
|---|---|---|
| 同じマシン | セッションごとのソケット | 新規メッセージと返信 |
| 別の自分のマシン | Remote Control経由でAnthropicのサーバーを通過 | 相手から届いたメッセージへの返信 |
| Claude Code on the web | Anthropicのサーバーを通過 | Web側から届いたメッセージへの返信 |
遠隔通信はローカル通信の完全な延長ではない。別マシンやWeb上のセッションに対し、ローカル側から新しい会話を始めることはできず、相手から届いたメッセージへ返答する片方向の起点に限られる。Remote Controlに接続していない状態でも返信は送れるが、その場合は返信先情報が付かず、受信側からさらに返事を戻せない。
メッセージに含まれるのは、送信側のClaudeが書いたテキストだけだ。送信元の会話履歴や作業ファイルは渡らない。同じ会話を別ターミナルで続けたい場合はセッションのresume、ファイルを共有したい場合は双方が参照できるリポジトリやworktreeを使う必要がある。また、届いたメッセージは利用者が入力したプロンプトと同様に利用量へ算入される。連絡回数が増えれば、その分だけコンテキストとトークンを消費する。
サブエージェント、Agent Teamsとの境界
Claude Codeには、すでに複数の処理主体を使う手段がある。cross-session messagingが加わっても、それぞれの使い分けは異なる。
| 機能 | 誰が作業単位を始めるか | 文脈と調整方法 | 向いている場面 |
|---|---|---|---|
| resume | 利用者 | 既存の会話を再開 | 同じ仕事を別の端末で継続する |
| サブエージェント | 親セッション | 独立した文脈で作業し、結果を親へ返す | 調査や検証を委譲して親の文脈を節約する |
| Agent Teams | リード役のClaude | 各teammateが独立文脈を持ち、共有タスクリストで連携 | Claudeに複数担当の生成と監督を任せる |
| cross-session messaging | 利用者が別々に起動・操作 | 必要なテキストをセッション間で送る | 人が監督する並列作業を途中から結び付ける |
cross-session messagingの持ち味は、中央のリードや共有タスクリストを作らず、独立性を保ったセッションを緩くつなぐ点にある。利用者は各セッションの目的や権限を別々に決めたまま、依存関係が生じた時点で知見を渡せる。一方、作業の割り振りや完了管理までClaudeへ任せたいならAgent Teamsが適する。Agent Teamsは実験機能であり、各teammateに別のコンテキストウィンドウを持たせるため、稼働数に応じてトークン使用量も増える。
サブエージェントは親セッションから切り出した作業を終え、要点を親へ戻すための仕組みである。独立して人が操作する複数セッションの調整役ではない。新機能が埋めるのは、利用者がすでに並行運用しているセッションの間に、必要な連絡路がなかった部分だ。
導入前にどの条件を確認するか
セッションから届くメッセージは、利用者本人の指示や承認として扱われない。受信側のClaudeは、別セッションから来た文面だと知らされたうえで処理する。送信側は権限要求を承認できず、受信側の設定やCLAUDE.mdを変更するよう命じることもできない。/compactのようなコマンドを書いても平文として届き、実行はされない。メッセージを受けてファイル編集や外部接続が必要になれば、受信側の権限規則が改めて適用される。
受信設定のcrossSessionInboundにはaccept、hold、refuseの3値がある。明示設定がない場合も、送受信側の権限モードに応じて即時配信か保留かが決まる。保留されたメッセージは最大100件で、承認ダイアログの既定期限は5分だ。マシン外への送信を必ず確認したい組織はisolatePeerMachinesを有効にできる。受信を止めるならrefuse、送信と相手一覧の取得を止めるならSendMessageとListAgentsのdeny規則を使う。
利用環境にも条件がある。対応するのはv2.1.224以降のmacOSとLinuxで、WSL 2内のLinuxを含む。ネイティブWindowsでは利用できない。Amazon Bedrock、Claude Platform on AWS、Google Cloud Agent Platform、Microsoft Foundryも対象外だ。非必須通信やテレメトリーを止める一部の環境変数によって、依存するfeature flagの評価が無効になっている場合にも機能しない。
長時間動かすclaude -pセッションも通常は受信用ソケットを持つが、bare modeでは登録されない。非対話セッションは保留メッセージの承認画面を出せないため、無人で受信させる運用ではcrossSessionInbound=acceptを明示する必要がある。この設定では受信メッセージが即時に処理され、自動処理の新しい入力経路になる。導入時には、同じファイルシステムを見ているか、どの権限モードで受け取るか、メッセージを受けた後に許す操作は何かを、セッションごとに決めるべきである。
