クロスセッションメッセージングとは何か
ターミナルの窓を二つ以上開いて Claude Code を使っていると、必ずこの瞬間が来る。左の窓でデータベースのスキーマを一つ変えたのに、右の窓はそれを知らないまま古い構造でコードを書き続けている。そこで左の結論を選択して右に貼り付けることになる。人が二つのセッションのあいだの配達人になるわけだ。
クロスセッションメッセージングは、その配達をセッション同士にやらせる機能である。一方のセッションの Claude が、もう一方のセッションの Claude に文章を一塊送る。公式文書の表現どおり、メッセージとは一つの Claude がもう一つの Claude に書くテキストであって、会話履歴やファイルではない。
使いどころは大きく三つ。一つ目は、片方で破壊的な変更や決定が出たときに、それを影響を受けるセッションへ渡す場合。二つ目は、同じリポジトリを複数のワークツリーで分担しているときに、何が入ったかを互いに知らせる場合。三つ目は、マイグレーションやテストのような長い作業の状況を、こちらが見ているセッションへ報告させる場合である。
要件はバージョンと OS だけだ。インストール作業も、設定ファイルで入れるスイッチもない。要件を満たすセッションならすでに有効になっている。
| 環境 | 必要なバージョン | 備考 |
|---|---|---|
| macOS · Linux | 2.1.224 以上 | WSL 2 内の Linux を含む |
| ネイティブ Windows | 2.1.234 以上 | ソケットではなく名前付きパイプを使う |
| 別のマシンにある自分のセッション | 2.1.225 以上 | 双方が Remote Control に接続している必要がある |
| アイドル通知（notify_when_idle） | 2.1.236 以上 | 両方のセッションがこのバージョン以上であること |
claude --version
# 2.1.224 未満なら更新する
claude updateセッション名がそのままアドレス — /peers
まず探したくなるのが「相手のアドレスはどう書くのか」である。答えは、書くアドレスなど無い、だ。セッション名がそのままアドレスであり、IP もポートもトークンも手で扱うことはない。
確かめるにはプロンプトで /peers と打つ。/list-agents でも同じだ。一行目に出るのがこのセッション自身の名前、つまり他のセッションがこちらを呼ぶときに使う名前である。その下に届く相手が並ぶ。このセッションの中で動いているサブエージェント、このセッションのチームメイト、同じマシンにある自分の別の Claude Code セッション、そして Remote Control に接続していればクラウドのセッションや別マシンのセッションまで。
同一マシンのセッションは名前の横に作業フォルダも表示される。似たような名前が並んだときは、このフォルダでどれがどのプロジェクトかを見分ける。
名前を自分で決めるには二通りある。起動時に claude -n 調査 のように付けるか、開いている対話の中で /rename 調査 と打つ。付けなければ Claude Code が作業フォルダをもとに自動で用意する。同じ名前のセッションがすでに動いていれば、後から来たほうに変化させた名前が付き、そのことを知らせてくれる。
一点だけ注意。一覧にこのセッション自身は行として現れない。Claude が誤って自分の名前宛てに送ると、宛先は現在のセッションだと言われて拒否される。
# 起動時に
claude -n 調査
# 開いている対話の中で
/rename 調査
# 届く相手を確認する（=/list-agents）
/peers送り方 — ツールを呼ばずに言葉で頼む
送るためのツールが SendMessage、相手を探すツールが ListAgents である。ただしこの名前を覚える必要はない。人がそのツールを直接呼ぶことはないからだ。何を伝えたいかを言えば、Claude が相手を見つけて文章を書いて送る。
文面まで自分で決める必要もない。「いまやったことを決済 API を触っているセッションに説明して」だけでよく、Claude が要約を自分で書く。だから同じ指示を二度しても、出ていく文章は毎回少しずつ違う。
相手を名指ししたいときはプロンプトで @ を打ち、名前の頭の数文字を入れる。動いているセッションが入力補完で現れ、選ぶと @api-worker のようなメンションが挿入される。こうすると Claude は一覧を引かずに直接そのセッションへ送る。この補完は 2.1.232 以降である。
Claude が自分で判断して送ることもある。頼まなくても、いましたばかりの変更が別のセッションの作業を壊すと見れば、先にそちらへ知らせる。
別のターミナルで動いているセッションに、マイグレーションが終わったか聞いて
いまやったことを決済 API を触っているセッションに説明して
@api-worker にスキーマのマイグレーションが終わったと伝えて受け取る側で起きること、そしてアイドル通知
受け取るセッションが作業の最中だったらどうなるか。実行中のツールは中断されない。受け取る側の Claude はツール呼び出しの合間にメッセージを読む。そのセッションが待機中であれば、Claude Code がそのメッセージで新しいターンを始める。どちらの場合も、送り主のセッション名とともに会話にそのまま残る。
実際に一番よく使うことになるのは、メッセージそのものよりアイドル通知のほうだ。「マイグレーションのセッションが終わったら教えて」と言えば、Claude が SendMessage の notify_when_idle で購読を掛ける。そのセッションが次に待機状態になるか終了したときに、通知がちょうど一度だけ届く。ここでの待機とは、キューに何もない状態でターンを終えたという意味である。
購読の利点は安いことだ。メッセージを付けずに購読だけ掛けると、見られている側のセッションではターンも始まらず、トークンも消費されない。すでに待機中なら通知はすぐ届く。互いに相手を繰り返し突つかない点が重要で、ポーリングを置き換えるために作られた機能である。
制約が三つある。一度きりであること。同じマシンのセッションにしか掛けられないこと。そしてメインの対話の Claude だけが購読でき、サブエージェントやチームメイトが試みると購読していないと知らされること。12時間のあいだ何の合図もなければ購読は失効し、そのことが Claude に伝えられる。
何が渡り、何が渡らないか
安全に使うには、境界を一度きちんと見ておくほうがよい。渡るのはプレーンテキストだけだ。ファイルも、積み上がった会話履歴も、権限も付いていかない。受け取るセッションは、送った側が何を読み何を実行したかを知らないまま、その文章だけを受け取る。
だから文脈を丸ごと移したい場合はこの機能ではない。それはセッションの再開（claude --resume）の仕事である。メッセージは「いまこの事実を向こうが知っている必要がある」ときに使う。
権限もセッションごとに独立している。自分のセッションで拒否された作業を隣のセッションにやらせて迂回することは規則で禁じられており、実際の強制は受け取る側に掛かっている。他のセッションから来たメッセージが利用者の承認の代わりになることはなく、受け取る側の Claude は相手に頼まれたからといって CLAUDE.md や権限設定を変えないよう指示されている。本文に /compact のようなスラッシュコマンドを書いて送っても、ただの文字として届くだけで実行されない。メッセージが求める作業に権限が要るなら、普段と同じ確認が出る。
経路も宛先によって分かれる。同じマシンの中なら、セッションごとに一つずつ結ばれる Unix ドメインソケット（ネイティブ Windows では名前付きパイプ）で直接届き、サーバーを経由しない。別のマシンやウェブのセッションへ送る場合は Anthropic のサーバーを通る。マシンの外へ出ること自体を止めたければ isolatePeerMachines を有効にして、毎回承認を求めるようにできる。
| 項目 | 渡るか | 説明 |
|---|---|---|
| メッセージ本文 | 渡る | プレーンテキストのみ。構造化されたチームのプロトコルはチーム内に留まる |
| ファイル・添付 | 渡らない | 受け取る側は自分の権限で読み直す必要がある |
| 会話履歴 | 渡らない | 丸ごと移すなら claude --resume |
| 権限・承認 | 渡らない | メッセージは承認にもならず設定も変えられない |
| スラッシュコマンド | 実行されない | 本文の /compact などは文字として届く |
既定は「承認待ち」ではない — そして届かないときの確認
「他のセッションが自分のセッションに話しかけられる」と聞いて不安が先に立つなら、実際の規則を見れば整理がつく。crossSessionInbound の設定で、受け取る側の動きを三つから選ぶ。accept はそのまま配信、hold は通知だけ出して配信しない、refuse は黙って捨てる。設定ファイルの代わりに /config の「他のセッションからのメッセージ」の行で選んでもよい。
誤解が生まれやすいのは、何も設定していないときだ。この場合の既定は「必ず承認待ち」ではない。二つのセッションの権限モードを比べて一件ごとに判断する。受け取るセッションが普段どおり権限を尋ねるモードならメッセージはそのまま配信され、送る側が権限の確認を飛ばすモードだと名乗ったときにだけ承認待ちになる。逆に受け取るセッション自体が権限の確認を飛ばすモードなら既定は保留で、送る側も同じモードのときにだけ配信される。
承認のダイアログが出たまま答えずにいると、dialogExpiry の期限を過ぎたところで閉じられ、メッセージは捨てられる。この期限の既定値が五分である。never にすればセッションが終わるまで待つ。なお、明示的に hold を設定して保留されたメッセージは失効せず、後から accept が適用されたときに配信される。
最後に、届かないときの確認の順番。/peers 自体が認識されなければその機能が無いということなので、まず claude --version を見る。/peers は使えるのに送ったものが届かないなら、もっと狭い理由だ。SendMessage・ListAgents に拒否ルールが掛かっているか、受け取る側の設定が保留か拒否になっているか、相手がコンテナの中のように別のファイルシステムにいるかである。コンテナ内のセッションとホストのセッションは互いに見えない。WSL 2 内のセッションと同じ計算機上のネイティブ Windows セッションも同様である。
| crossSessionInbound | 受け取る側の動き |
|---|---|
| accept | 届いたメッセージをそのまま Claude に配信する |
| hold | 通知だけ出して配信しない。後から accept が適用されると解放される |
| refuse | 配信せずに捨てる |
| （未設定） | 二つのセッションの権限モードを比べて一件ごとに判断する |
# 1) その機能があるか
claude --version # macOS/Linux 2.1.224+ / Windows 2.1.234+
/peers # 認識されなければ機能なし
# 2) 受信アドレスが結ばれているか
/status # Peer address の行を見る
# 3) 受け取る側が塞いでいないか（~/.claude/settings.json）
{ "crossSessionInbound": "accept" }