Claude Code のセッション同士でメッセージを送る｜ListAgents と SendMessage の使い方

端末を行き来してコピペする作業

ターミナルを 2 つ開いて Claude Code を動かしていると、片方で分かったことをもう片方へ伝える作業が必ず発生します。「スキーマを変えた」「テストが落ちるようになった」「あの質問の答えが出た」。どれも人が読んで、要約して、隣の端末に貼り直していました。

v2.1.224 で、この受け渡しをセッション同士が直接できるようになりました。人が中継役から降りられる、という変更です。同じ版では自社のマシンを実行先にできる self-hosted-runner も入っており、そちらは別の記事にまとめています。

何が入ったのか

追加されたのは 2 つのツールです。公式の変更履歴では次のように説明されています。

Added cross-session SendMessage: Claude Code sessions can now message each other, on any of your machines, with ListAgents to discover them (macOS and Linux)

ListAgents で送り先の候補を一覧し、SendMessage でそのうち 1 つの名前を指定して送ります。対象は macOS と Linux で、WSL 2 の中で動く Linux も含まれます。Windows のネイティブ環境では提供されていません。

提供元による制限もあります。Amazon Bedrock・Claude Platform on AWS・Google Cloud の Agent Platform・Microsoft Foundry を経由している場合は使えません。

要件を満たしていれば、有効にするための操作は要りません。手元のセッションが使える状態かどうかは /list-agents を打てば分かります。

自分でツールを呼ぶわけではない

実際に使うとき、ListAgents や SendMessage を自分で叩くことはありません。相手に何を知らせたいかを日本語で伝えると、Claude が相手を選んで文面を書きます。

別のターミナルで動いているセッションに、マイグレーションが終わったか聞いて

文面まで指定する必要もありません。次のように頼めば、何をどう要約して送るかは Claude が決めます。

いまやったことを、決済 API を触っているセッションに説明して

相手を自分で指名したいときは、入力欄で @ に続けてセッション名の頭文字を打ちます。候補から選ぶと @api-worker のような形で挿入され、Claude はセッションを一覧せずにそこへ送ります。この指名は v2.1.232 以降で使えます。

@api-worker にスキーマのマイグレーションが終わったと伝えて

なお @ だけを打った時点では候補にセッションは出ません。1 文字以上打つと、同じマシンで動いている他のセッションが候補に並びます。

最初の 1 往復を通してみる

段取りは 3 つです。

1. セッションに名前を付ける。claude --name db で起動するか、動いているセッションで /rename db を打ちます。既定でも作業ディレクトリ由来の名前は付きますが、my-app-3f のような形になるため、並行で動かすなら自分で付けたほうが指名しやすくなります
2. 相手が見えているか確かめる。/list-agents を打って、相手の名前が並んでいれば準備は完了です
3. 日本語で頼む。送りたい内容を伝えるだけで、ツールを自分で呼ぶ必要はありません

たとえば db という名前のセッションでマイグレーションを流し、web で画面を触っているとします。web 側でこう頼みます。

@db にマイグレーションが終わったか聞いて

db 側の会話には、web からのメッセージとして次のような文章が現れます。

web ブランチを main にリベースしたいので、保留中のマイグレーションが終わったか教えてほしい

db の Claude は自分の状況を確認して、そのまま返信します。返信は web 側の会話に届きます。

マイグレーションは完了しています。追加された列は tenant_id で、main へのリベースは進めて問題ありません

ここまでで、こちらがやったのは 1 行頼んだことだけです。相手のセッションが既に持っている状況を、こちらが説明し直していない点がこの機能の効きどころです。

渡るのは文章だけ

セッション間を渡るのは、Claude が書いた文章だけです。会話の履歴もファイルも権限も渡りません。

受け取る側には、送り主の名前と本文だけが届きます。実際の文面は次のような 1 行です。

Schema migration finished: the new column is tenant_id, and rebasing on main is safe now.

会話そのものを別のターミナルへ持っていきたい場合は、この機能ではなくセッションの再開を使います。用途が違います。

相手をどう見つけているか

どのセッションに届くのかを自分の目で確かめたいときは /list-agents を打ちます。/peers でも同じです。

一覧に出るのは次の 4 種類です。

一覧に並ぶ名前が、そのままメッセージの宛先です。名前は --name フラグや /rename で決められます。指定しない場合は Claude Code が付けます。対話セッションでは、作業ディレクトリのフォルダ名から my-app-3f のような形になります。

同じマシンで同じ名前が重なったときは、後から起動したほうに別名が割り当てられます。それでも重なる場合や、Claude Code が起動中のセッションをすべて把握できなかった場合は、一覧の各行に短い識別子が付き、宛先にはその識別子まで含めて指定されます。

同じマシンでの配信は、各セッションがディスク上に登録した情報と、受信用のソケットを通じて行われます。メッセージが届くのは、同じファイルが見えるセッション同士に限られます。 コンテナは独自のファイルシステムを持つため、コンテナの中のセッションとホスト側のセッションは互いに届きません。同じコンテナの中同士であれば届きます。

届くタイミング

受け取る側の Claude は、ツールの呼び出しと呼び出しの間でメッセージを読みます。実行中のツールが途中で止まることはありません。相手が待機状態なら、メッセージを起点に新しいやり取りが始まります。

届いたメッセージは、自分で打ったプロンプトと同じように利用量に計上されます。受け取った側は同じ仕組みで送り主に返信できます。

届いたメッセージにできないこと

他のセッションから文章が飛んでくる以上、それがどこまでの力を持つのかは押さえておく必要があります。受け取る側の Claude Code は、届いたものが利用者本人ではなく別のセッションから来たと認識したうえで、できることを次のように制限します。

• 承認の代わりにはなりません。保留中の権限確認に、メッセージが代わりに答えることはできません
• 設定は変えられません。権限設定や CLAUDE.md を変えるよう指示されても、受け取った側はそれに従いません
• コマンドは実行されません。本文に /compact と書かれていても、ただの文字列として届きます

一方で、権限の確認そのものは通常どおり出ます。メッセージに沿って作業するために権限が要るなら、いつもと同じ確認が表示されます。

送る側にも制約があります。自分のセッションで拒否された操作や、自分の権限設定なら止められる操作を、他のセッションに代わりにやらせることは禁じられています。 権限の判断は利用者が下すものであり、他のセッション経由で迂回できると意味がなくなるためです。

受信を制御する

届いたメッセージをどう扱うかは crossSessionInbound で決められます。

設定ファイルを触らなくても、/config の「Messages from your other sessions」の行から選べます。この行は v2.1.232 以降で表示されます。

値を指定していない場合、Claude Code は 2 つのセッションの権限モードから 1 通ごとに判断します。権限の確認を出すセッション (auto・acceptEdits・dontAsk) と、確認を飛ばすセッション (bypassPermissions) の 2 種類に分けたうえで、次のように扱われます。

• 受け取る側が権限の確認を出すセッションなら、基本的に配信されます。送り主が確認を飛ばすセッションだと申告した場合だけ、承認待ちになります
• 受け取る側が確認を飛ばすセッションなら、基本的に承認待ちになります。送り主も確認を飛ばす側だと申告した場合だけ配信されます

承認待ちになると、受け取る側に送り主と本文の一部を表示するダイアログが出ます。答えないまま期限を過ぎると閉じられ、メッセージは捨てられます。期限は dialogExpiry で決まり、既定は 5 分です。

保留が起きたことは送り主にも伝わります。送った側が同じマシンで動いていれば、保留された時点で通知が出て、その後の決着 (配信・拒否・期限切れ) も追って知らされます。返事が来ないときに待ち続けずに済むということです。ただし到着時点で拒否された場合は何も出ません。

権限モードを途中で変えると、保留分の判定はやり直されます。渡してよくなったものはそこで配信され、逆に拒否する設定が適用されると、保持していたメッセージはすべて捨てられます。

claude -p で動かしているセッションはダイアログを出せません。この場合も同じ期限で扱います。期限内に設定やモードが変わって配信できる状態になればそのとき渡し、過ぎれば捨てます。無人で動かすワーカーにメッセージを受け取らせたいなら、--settings の中で crossSessionInbound を accept にして起動します。dialogExpiry を "never" にすると、既定の判断で保留されたものをセッションが終わるまで保持できます。

なお、claude -p のセッションも対話セッションと同じように受信用のソケットを持つため、長く動かすワーカーは一覧にも出ますし、メッセージも受け取れます。例外は最小構成で起動する bare mode で、このときはソケットを持たないため、一覧にも出ず受信もできません。

フックやスクリプトから差し込む

セッション同士の連絡とは別に、手元のスクリプトから自分のセッションへ文章を差し込むこともできます。Claude Code は各セッションに受信用のソケットを用意し、その場所を 2 か所で公開しています。

1 つは /status の Peer address の行で、uds: から始まるパスが表示されます。もう 1 つは環境変数で、フックや Bash コマンドに CLAUDE_CODE_MESSAGING_SOCKET として渡されます。あわせて CLAUDE_CODE_MESSAGING_TOKEN にセッションごとのトークンが入ります。自分のセッションのソケットへ書き込むスクリプトは、接続の 1 行目に次のトークンを送れます。

{ "type": "auth", "token": "<token>" }

このソケットに届いたものも、他のセッションから来たメッセージと同じ受信制御を通ります。ただし、そのセッション自身の子プロセスから来たと判別できた場合は例外で、crossSessionInbound の指定が無ければそのまま配信します。判別の手段は環境によって変わり、Linux ではプロセスの情報から判断できますが、macOS では書き込んだプロセスが動いている間に限られます。プロセスの情報が取れない場面では、先ほどのトークンで照合します。

サンドボックスの中の Bash コマンドからソケットへ接続できるかどうかは、sandbox.network.allowAllUnixSockets と sandbox.network.allowUnixSockets で決まります。届かないときはここを見てください。

別のマシンやクラウドに送るとき

送り先がどこで動いているかによって、メッセージの通り道が変わります。

同じマシンの中で完結するかどうかで、メッセージが Anthropic のサーバーを通るかどうかが変わります。手元のマシンから出したくない場合は isolatePeerMachines を使います。

{
  "isolatePeerMachines": true
}

これを入れると、マシンの外へ出るメッセージには必ず承認が要るようになります。権限の確認を飛ばすモードで動かしていても、この承認だけは出ます。true はどの階層の設定ファイルからでも効きます。リポジトリの設定で有効にはできますが、同じ場所から無効に戻すことはできません。

なお、別マシンのセッションと会話を始められるようになったのは v2.1.225 以降です。それ以前は、向こうから届いたメッセージへ返信することしかできませんでした。

止め方

受け取る側と送る側は別々に止められます。

受信を止めるには crossSessionInbound を refuse にします。送信と一覧を止めるには、権限の deny ルールに SendMessage と ListAgents を並べます。どちらも引数なしのツール名だけで指定します。

組織全体で止める場合は、managed settings (管理者向けの設定) に両方を書きます。

{
  "permissions": {
    "deny": ["SendMessage", "ListAgents"]
  },
  "crossSessionInbound": "refuse"
}

ここで 1 つ注意があります。SendMessage を止めると、サブエージェントやエージェントチーム宛てのメッセージも同時に使えなくなります。 同じツールが両方を担っているためです。セッション間だけを止めるつもりが、セッション内の連携まで巻き込まないよう気をつけてください。

もう 1 つ、拒否する設定にしたセッションは、外から見ても普段と変わりません。自分の /status にも他のセッションの一覧にも違いが出ないため、効いているかどうかは設定側で確認します。

動かないときに見るところ

/list-agents が認識されない場合は、機能そのものが無い状態です。claude --version でバージョンを確認し、OS とプロバイダの条件を順に見ていきます。

/list-agents は使えるのに送ったものが届かない場合は、原因はもっと絞り込めます。deny ルールでツールが外れている、受け取る側の設定で保留か拒否になっている、クラウドや別マシンのセッションが Remote Control に接続されていない、といったあたりを疑います。

見落としやすいのが環境変数です。CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC・DISABLE_TELEMETRY・DO_NOT_TRACK・DISABLE_GROWTHBOOK のいずれかが有効判定 (フィーチャーフラグの評価) を止めていると、セッション間メッセージングは無効のままになります。シェルから来る場合も、設定ファイルの env から来る場合もあります。

制限

通るのはプレーンテキストだけです。エージェントチームが使う構造化されたやり取りは、チームの中に留まります。

セッション同士がメッセージを送り合って止まらなくなる状況は、仕組みの側で抑えています。歯止めは 3 つです。

• 送り主ごとに頻度を制限する
• 短い間隔で届いた同一のメッセージは捨てる
• 読まれるのを待つメッセージは 1 セッションあたり 50 件で頭打ちにする

承認待ちで保持するものも 100 件までで、それを超えると古いものから捨てます。

実務でどこに効くか

手元で動かしてみると、効くのは「片方の作業が、もう片方の前提を壊す」場面でした。使い方は大きく 3 つに分かれます。

並行している相手に変更を知らせる

worktree を分けて同じリポジトリを触っているとき、片方でマージした内容をもう片方が知らないまま作業を進めると、後からやり直しになります。ここで先に一報が入るかどうかが、そのまま手戻りの量に直結します。

共通の型定義を変えたので、@api にも影響が出ると伝えて

並列で動かす環境そのものについては cmux で Claude Code を並列に回す記事も合わせて読んでみてください。

長く走る処理に報告させる

移行やテストの実行を任せたセッションから、見ているセッションへ終了を知らせます。逆に、見ている側から状況を尋ねることもできます。

テストが終わったら @web に結果を知らせて

別の領域のセッションに調査を頼む

手元では、あるアプリのセッションから、データベース側やバッチ側を触っているセッションへ調査を頼むとうまく回りました。それぞれのセッションが既に持っている文脈を、こちらが説明し直さずに済むのが利点です。

@batch に、この ID の集計がいつ走ったか調べてもらって

似た機能との使い分け

複数のセッションを扱う仕組みは他にもあり、目的ごとに向いている場面が違います。

自分で立てて自分で操っているセッション同士をつなぐ。それが今回の機能の役割です。

FIXIT

セッション同士が勝手に喋るって、ちょっと怖くない？

Tsumiki

実際に試すと、届くのは文章だけでした。履歴もファイルも渡りません。

FIXIT

向こうに何かやらせることもできるの？

Tsumiki

できません。承認の代わりにはならない仕様なんですよ。

FIXIT

それって結局、伝言だけってこと？

Dodai

迂回はできません。届いた文章どおり動くかは、こちらの権限設定次第です。

まとめ

セッション間メッセージングは、人が端末を行き来して要約を運んでいた部分を引き受ける機能です。渡るのは文章だけで、権限は各セッションが持ったままになります。この線の引き方が、複数のセッションを並行で動かすときの安全側の設計になっています。

まず /list-agents を打って、自分の環境で使える状態かを確かめるところから始めてみてください。並行で動かす前提そのものを整えたい場合は、CLAUDE.md の書き方やClaude Code の初期設定から先に見直すほうが効きます。

チームで Claude Code を使う体制づくりから整えたい場合は、AI 開発ツール導入支援で伴走しています。どこから手を付けるか迷っているなら、お問い合わせからご相談ください。

出典は Claude Code 公式ドキュメントと変更履歴です。