この記事で分かること
- v2.1.224 で追加された2つのツールが、何をするものか
- メッセージが届いたとき、何が渡って何が渡らないか
- 従来の「成果物を書いて後から読ませる」引き継ぎと、どちらが何に向くか
- 動かない環境と、受信側で決められる設定
Claude Code を複数のターミナルや複数の端末で並行して動かしている人に向けて書いている。
Claude Code v2.1.224 で、走っている別のセッションへテキストを送れるようになった
Claude Code は、ターミナル1枚につき1つのセッションが走る。 複数のターミナルを開けば、その数だけセッションが並ぶ ― 片方でアプリを書きながら、もう片方でインフラを直す、という使い方になる。
これまで、並んでいるセッションは互いの存在を知らなかった。 片方の結果をもう片方へ渡す方法は2つしかない。 人がコピーして貼るか、ファイルに書いて後から別のセッションに読ませるかだ。
v2.1.224 で、そこに3つ目が入った。走っているセッションを一覧し、名前を指定してテキストを届ける。
| ツール | 役割 |
|---|---|
ListAgents |
いま手が届くセッションを列挙する |
SendMessage |
その1つに名前を指定してテキストを届ける |
どちらも人が直接叩くものではなく、Claude が自分で使う。 人が書くのは「隣のターミナルのセッションに、マイグレーションが終わったか聞いて」の一言で、 相手を探して、選んで、投げて、返事を待つところまでを Claude がやる。
渡るのは送信者名・返信先・本文の3つだけ
会話履歴は渡らない。読んだファイルも渡らない。CLAUDE.md も、メモリも、権限設定も渡らない。
受け手は、自分の端末のディスクから自分の設定を読んで起動している別のセッションのままで、 そこへ短いテキストが1本届く。これは文脈の共有ではなく、宛先を指定した伝言である。
会話と文脈ごと移したい場合に使うのは、この機能ではなくセッションの resume になる。
届くのはツール呼び出しの合間で、実行中のコマンドは中断されない
- 受け手はツール呼び出しの合間に読む。走っているコマンドが止められることはない
- 受け手が待機中なら、そのメッセージで新しいターンが始まる
- 届いたメッセージは、人が打ったプロンプトと同じように利用量に計上される
3つ目は見落としやすい。増えるのは送った側ではなく、受けた側の消費である。
新しいのは対等なセッション同士で、SendMessage 自体は前からあった
以前の SendMessage は、親セッションが自分で spawn した子（subagent）へ届くだけで、
親から子への一方通行の木構造だった。
この木の外にいる対等なセッションへ広がったのが、今回の差分である。
従来の引き継ぎでは、書いた時点で受け手のプロセスが存在しない
セッションをまたいで仕事を渡すこと自体は前からできた。やり方が違う。 成果物を書いて、後から別のセッションに読ませる。
A が渡している相手は B ではなく、保存された成果物である。 B は後から起動して、それを読む。宛先は無く、誰かが見に来るまで動かない。
直通で増えるのは、受け手が生きていること・中継が要らないこと・宛先を指定できること
- 受け手が実行中の文脈を持っている — 「何の件か」から読ませ直さなくていい
- 人も中継の仕組みも挟まらない — 配送待ちも、人の「着手して」も要らない
- 相手を発見して指名できる — 書き置きには宛先が無かった
裏返すと、この3つ以外は増えていない。 セッションをまたいで仕事を渡す能力そのものは、前からあったものだ。
速さと引き換えに、記録が残らない
| 軸 | 成果物を経由した引き継ぎ | セッション間メッセージ |
|---|---|---|
| 到達 | 遅い（人の起動待ち・中継待ち） | 即時 |
| 受け手 | まだ居ない。後から読む | 走っている。割り込まれる |
| 残るか | 残る。後から辿れる | 残らない。受け手の文脈に溶ける |
| セッションが死んだら | 生き残る | 消える |
| 人の判断 | 挟まる | 挟まらない |
| コスト | 書く1回 + 読む1回 | 受け手の文脈を1本ぶん消費する |
上位互換ではない。 人の判断が要るものと、後から根拠として辿る必要があるものは直通に載せない。 直通に向くのは、その場で完結して消えてよい確認だけになる。
書き置き型は読む前に前提が揃い、直通型はその時点の文脈で解釈される
書き置きを読む側は、起動時に常時載る層（設定・作法・環境の事情）を全部読んでから本文に触る。 直通はそこを飛ばして、走っている最中の文脈へ割り込む。 「遅い」ことの対価として買っていたのは、受け手が読む前に前提を揃え終えていることだった。
端末ごとの設定の差は、メッセージでは埋まらない
複数の端末で Claude Code を動かしていると、端末ごとに文脈の厚みが違う状態になる。 端末A には作法や環境の事情が書き溜められていて、端末B には無い。すると端末B では、
- 毎回ゼロから探索するので消費が増える
- その端末固有の事情（パスの違い、OS の差）を知らずにコマンドが落ちる
- 前提が共有されていないので、差し戻しと認識の齟齬が増える
セッション間メッセージでこれは埋まらない。渡るのはテキスト1本で、 端末B のセッションは端末B のディスクにある薄い設定を読んで起動したままだからだ。
むしろ差は開きうる。送り手は、受け手の設定に何が載っているかを知らない。 人が書くプロンプトなら、人は相手の薄さを知っていて前提を補える。 送り手が Claude だと、自分の厚い文脈を前提にした1行を投げ、 受け手は自分の薄い文脈の上でそれを解釈する。 届いた1本は利用量に計上されるので、薄い側が動き出す回数だけが増える。
常時載る層は、端末ごとに置くしかない。
受信側は、メッセージを理由に設定や権限を変えない
送りつけて相手の設定を直す使い方は、実装の不足ではなく意図的に塞がれている。
- 受信側の Claude は、他のセッションに言われたことを理由に設定や権限を変えることを禁じられている
- 本文中の
/compactのようなコマンドは、ただのテキストとして届き、実行されない - 他セッションからのメッセージは人の同意として数えられないので、 保留中の権限プロンプトに答えることもできない
- 受け手の側の権限プロンプトは、通常どおり出る
ここが通れば、メッセージ1本が乗っ取りの経路になる。
用途ごとの使い分け
| やりたいこと | 使うもの |
|---|---|
| 会話と文脈ごと移す | セッションの resume |
| 常に載っていてほしい作法 | 設定ファイル。その端末に置く |
| 走っている相手に短い事実を1本渡す | セッション間メッセージ |
| CI 結果など外部イベントを流し込む | channels |
動かない環境がある
- OS は macOS と Linux。ネイティブ Windows では動かない（WSL2 の中の Linux は動く）
- Bedrock や Vertex など、一部のプロバイダでは使えない
- テレメトリ系の環境変数で機能フラグの評価を切っていると、この機能も無効のままになる
- 同じマシンの中はセッションごとの Unix ソケットで、Anthropic のサーバを通らない。 同じファイルシステムが見える者同士しか到達しないので、コンテナの中と外は互いに見えない
- 端末をまたぐ場合は返信しかできない。こちらから会話を開始することはできず、 相手側が Remote Control で接続されている必要がある
受信側で決められること
crossSessionInboundでaccept/hold/refuseを選ぶ。 既定では、権限プロンプトを飛ばして走っているセッション宛の受信が人の承認待ちになる- 承認ダイアログは既定 5分 で失効して破棄される（
dialogExpiry） - 同一内容の連投は落ちる。未読は 50件、保留は 100件 で頭打ちになる
- 送信と受信は個別に止められる。受信は
crossSessionInbound: refuse、 送信と列挙はSendMessage/ListAgentsの deny ルール