クロスセッションメッセージングとは?
Claude Codeを日常的に使っていると、ターミナルを複数開いて並行作業する場面が出てきます。片方でAPIの実装、もう片方でフロントエンド、さらに別のタブでマイグレーション、といった具合です。
このとき困るのが、片方のセッションで起きたことをもう片方が知らないことです。スキーマを変更したのに、隣のセッションは古いカラム名のままコードを書き続ける。移行が終わったかどうかを確認するために、いちいちタブを切り替えて眺める。
結局、人間が連絡役になって各エージェントに事情を説明する必要があります。
クロスセッションメッセージングは、この橋渡しをClaude自身にやらせるものです。Claudeは2つのツールを使います。
ListAgents: 到達できるセッションを一覧する
SendMessage: 名前を指定してメッセージを届ける
重要なのは、送られるのはテキストだけという点です。会話履歴もファイルも渡りません。受信側が受け取るのは、送信者の名前と本文だけです。
使い方
ユーザー側でツールを呼ぶ必要はありません。宛先の特定も含めてClaudeが判断します。指示はこの程度で通ります。
もう一方のターミナルで動いているセッションに、マイグレーションが終わったか聞いて
いま実装した内容を、決済APIを触っているセッションに説明しておいて
送る文面はClaude自身が書くので、こちらが本文を用意する必要もありません。実際に届くメッセージは、たとえばこんな一文です。
スキーマ移行が完了しました。新しいカラムは tenant_id です。mainへのリベースは安全です。
受信側では、Claudeが処理の合間にこれを読みます。ツールの実行中に割り込むことはなく、アイドル状態なら新しいターンとして受け取ります。読み終わると1行に折りたたまれ、Ctrl+Oで展開できます。
どのセッションに届くのかを自分で確認したい場合は、/list-agents(別名 /peers)を実行します。
ここに出てくる名前が、そのままメッセージの宛先です。名前は /rename コマンドか起動時の --name フラグで設定でき、指定しなければ作業ディレクトリ名から myapp-3f のような名前が自動でつきます。
なお、Claudeは自分から必要だと判断して送ることもあります。ある変更が別のセッションの作業を壊すと気づいたときに、こちらが頼まなくても警告を飛ばす、という動き方です。
どういう場面で効くのか
公式ドキュメントが挙げているのは次のようなケースです。
- 発見の引き継ぎ: 破壊的変更や設計判断を、影響を受ける側のセッションに要約して伝える
- 並列worktreeの調整: 同じリポジトリを別々のworktreeで触っているセッション同士で、何がマージされたかを共有する
- 長時間タスクの進捗確認: マイグレーションやテスト実行の状況を、手元で見ているセッションに報告させる
- 別マシンからのメッセージへの返信
個人的にいちばん実用性を感じるのは1つ目です。並列でエージェントを走らせたときの失敗は、たいてい「片方の前提が古くなっていることに誰も気づかない」という形で起きます。人間が気づいた頃には、もう一方が数十分ぶん間違った方向に進んでいる。その検知を、いちばん早く気づける立場にいるClaude自身にやらせるという発想は理にかなっています。
仕組み: どこを通ってメッセージが届くのか
送信先がどこにいるかで、経路と可能なことが変わります。
| 相手のセッションの場所 |
経路 |
送れるもの |
| 同じマシン |
セッションごとのソケット。Anthropicのサーバーを経由しない |
新規メッセージと返信 |
| 自分の別のマシン |
Anthropicのサーバー経由でRemote Control接続へ |
返信のみ |
| Claude Code on the web |
Anthropicのサーバー経由でクラウドセッションへ |
返信のみ |
同一マシン内の通信はローカル完結です。各セッションは自分専用の受信ソケットをディスク上に作り、OSのユーザー単位でアクセスを制限します。共有マシンで他人のセッションに届くことはありません。ソケットのパスは /status の Peer address 行か、環境変数 CLAUDE_CODE_MESSAGING_SOCKET で確認できます。
この「ファイルを見に行く」実装のため、コンテナの内と外では相互に到達できません。同じファイルシステムを共有しているセッション同士だけが会話できる、と覚えておくと挙動を予測しやすいです。
マシンをまたぐ場合は返信しかできません。こちらから会話を始めることはできない、という非対称な設計になっています。地味な仕様に見えますが、これは安全側に倒した妥当な判断だと思います。同一マシン内はOSのユーザー権限という強い境界がありますが、ネットワーク越しは違います。始点を常に手元に置いておくことで、外から一方的に自分のセッションを叩き起こす経路を塞いでいるわけです。
受信側は、届いたメッセージをどう扱うか
ここがこの機能でいちばん考え抜かれている部分です。
Claude Codeは受信側のClaudeに対して「これはユーザーからの指示ではなく、別のセッションから届いたメッセージだ」と明示したうえで、できることを制限します。
- 承認の代わりにならない: 他セッションからのメッセージは、保留中の権限確認に対するあなたの同意としては扱われない
- 設定を変えられない: 権限設定や
CLAUDE.md などの構成を、他セッションに言われたからという理由で変更しない
- コマンドが実行されない: 本文に
/compact のような文字列が含まれていても、ただのテキストとして届く
- 権限確認は通常どおり発生する: メッセージに従って作業するのに権限が必要なら、いつもと同じ確認が出る
送信側にも制約があります。自分のセッションで拒否された操作や、自分の権限設定なら弾かれる操作を、他のセッションに代行させないよう指示されています。
この設計を見て、なるほどと思いました。セッション間通信を素朴に実装すると、権限の抜け道が生まれます。厳しい設定のセッションAが、緩い設定のセッションBに「代わりにこれを消しておいて」と頼めば、権限管理は事実上崩壊します。Claude Codeはその経路を、送信側と受信側の両方から塞いでいます。
さらに、Auto modeなどの権限モードとも連動します。設定で明示していない場合、Claude Codeは両セッションの権限モードから配送可否を自動判断します。判定は「権限確認をスキップするセッション(bypassPermissions)」と「それ以外」の2クラスに分けて行われます。
- 受信側が権限確認をするモード: 基本は配送する。送信側がbypassPermissionsを名乗っている場合だけ承認待ちにする
- 受信側がbypassPermissionsのモード: 基本は承認待ちにする。送信側も同じくbypassPermissionsの場合だけ配送する
つまり、危険な操作を無確認で実行できるセッションほど、外から入ってくる指示に慎重になる。プロンプトインジェクションの侵入口として最悪なのは「無確認モードのセッション」なので、そこを一番守るという優先順位づけです。
保留されたメッセージは受信側に承認ダイアログとして表示され、送信者と本文のプレビューが出ます。放置すると dialogExpiry(デフォルト5分)で自動的に破棄されます。保留の上限は100件です。
設定でコントロールする
受信の挙動は crossSessionInbound で指定します。
| 値 |
挙動 |
accept |
届いたメッセージをそのままClaudeに渡す |
hold |
通知だけ出して配送しない。後から条件が変われば解放される |
refuse |
配送せずに破棄する |
マシンをまたぐ送信すべてに承認を必須にしたい場合は、isolatePeerMachines を使います。
{
"isolatePeerMachines": true
}
これを設定すると、bypassPermissionsモードであっても、マシン外へメッセージが出る前に確認が入ります。どこかの設定スコープで true になっていれば有効になり、下位のスコープから無効化はできません。チェックインしたプロジェクト設定で制限をかけられる一方、それを個人設定で緩められない、という方向性です。
機能そのものを止めたい場合、受信と送信は別々に制御します。組織全体で無効化するなら、管理設定でこう書きます。
{
"permissions": {
"deny": ["SendMessage", "ListAgents"]
},
"crossSessionInbound": "refuse"
}
ここで一点、実務上の注意があります。SendMessage を拒否すると、サブエージェントやエージェントチームへのメッセージ送信も同時に使えなくなります。同じツールが両方の役割を担っているためです。並列エージェントを活用している組織が、セッション間通信だけを止めるつもりでこの設定を入れると、想定より広い範囲が止まります。
もうひとつ、無効化したセッションは見た目に変化がありません。自分の /status にも、他セッションの一覧にも、拒否している事実は出てきません。挙動がおかしいときは設定ファイルを直接確認する必要があります。
似た機能との使い分け
Claude Codeは並列実行まわりの機能が増えてきたので、混同しやすくなっています。ドキュメントも明確に「それぞれ専用の機能があるので、目的に合うものを使え」と書いています。
| やりたいこと |
使う機能 |
| 別のターミナルで同じ会話の続きをしたい |
セッションのresume |
| Claudeが自分でチームを組んで統括してほしい |
Agent Teams |
| 多数のセッションを一箇所から監視・操作したい |
Agent View(並列エージェント対応のデスクトップ版) |
| スマホなど別デバイスから自分で操作したい |
Remote Control |
| CIの結果など外部イベントをセッションに流し込みたい |
channels |
| 自分で立てた独立セッション同士で情報を渡したい |
クロスセッションメッセージング |
境界線はシンプルです。誰かがまとめて指揮を執る構造ならAgent Teams、コンテキストごと持っていきたいならresume、そして自分で始めて自分で操縦している対等なセッション同士の連絡だけがクロスセッションメッセージングです。
Agent Teamsを実際に9体構成で試したときの感触で言うと、あちらは「プロジェクトを立ち上げてチームで攻める」道具でした。今回の機能はそこまで大がかりではなく、すでに動いている作業の横に一本だけ連絡線を引くイメージです。GitHub Copilot CLIの /fleetやGemini CLIのサブエージェントのような並列実行の仕組みと比べても、「並列に動かす」ことより「並列に動いているものを噛み合わせる」ことに寄っています。
考察: 会話履歴を送らないという判断
この機能で私がいちばん面白いと思ったのは、送れるのがプレーンテキストだけという割り切りです。
技術的には、会話履歴やファイルの参照を渡す実装も当然できたはずです。そのほうが受信側は状況を正確に理解できます。それでもテキスト一本に絞ったのは、コンテキストウィンドウという有限資源を守るためだと思います。
他セッションの履歴を丸ごと受け取れる設計にすると、受信側のコンテキストは他人の作業ログで一気に埋まります。エージェントの精度はコンテキストの密度に強く依存するので、これは実質的に受信側を弱くする行為です。「一文に要約して渡す」という制約は、不便に見えて、送信側のClaudeに要約という仕事を強制する仕掛けにもなっています。コンテキストを丸投げできないから、何が本当に重要かを判断せざるを得ない。
同じ理由で、コンテキストごと移したい場合は resume を使え、と機能が明確に分離されています。1つのツールに何でも詰め込まず、目的別に分けたうえで境界を文書化する。この姿勢は仕様駆動開発的な発想とも通じるものがあります。
もうひとつ、地味ですが実運用で効くのがループ対策です。AIエージェント同士が自由に会話できる仕組みで最も怖いのは、2体が延々と返信し合ってトークンを燃やし続ける事故です。Claude Codeは送信者ごとのレート制限、短時間の同一内容の破棄、未読上限50件という3段構えでこれを止めます。仕様として最初からループを想定に入れているのは、実際に運用した知見が入っている証拠だと思います。
注意点
導入前に押さえておきたい制限をまとめます。
- 対応OSはmacOSとLinux(WSL 2内のLinuxを含む)。ネイティブWindowsでは使えない
- Amazon Bedrock、Claude Platform on AWS、Google CloudのAgent Platform、Microsoft Foundry経由では使えない
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC、DISABLE_TELEMETRY、DO_NOT_TRACK、DISABLE_GROWTHBOOK などで機能フラグの評価を止めていると、この機能もオフになる
- コンテナの内と外はファイルシステムが別なので相互に到達できない
- 配送されたメッセージは、自分で入力したプロンプトと同じように利用量にカウントされる
- 送れるのはプレーンテキストのみ
claude -p のヘッドレスセッションも受信できるが、承認ダイアログを表示できないため保留されたままになる。無人で受け取らせたい場合は --settings で crossSessionInbound を accept にしておく(bare modeではソケット自体が作られず、一覧にも出ない)
使えているかどうかの確認は /list-agents が手っ取り早いです。コマンドが認識されなければ機能自体が無い状態なので、まず claude --version でバージョンを確認します。コマンドは通るのにメッセージが届かない場合は、権限のdenyルール、受信側の crossSessionInbound、あるいはマシンをまたぐ返信専用の制約のいずれかを疑うことになります。
まとめ
最後にポイントを整理します。
- クロスセッションメッセージングは、独立して立ち上げたClaude Codeセッション同士が、人間のコピペを介さずにテキストを渡し合う機能。v2.1.224以降のmacOS・Linuxで、設定なしで有効
- 送れるのはテキストのみ。会話履歴やファイルは渡らない。コンテキストごと移したい場合はresumeを使う
- 受信メッセージは承認の代わりにならず、設定変更もコマンド実行もできない。権限モードに応じて配送・保留・拒否が自動で決まる
- 同一マシン内はローカルのソケット完結。マシンをまたぐ場合は返信のみ可能
- Agent Teams、Agent View、Remote Control、channelsとは役割が分かれている。自分で操縦している対等なセッション同士の連絡がこの機能の担当範囲
Claude Codeを1つのターミナルで使っているうちは出番のない機能ですが、並列で走らせ始めた途端に効いてきます。ルーティン機能で長時間のジョブを回している場合も、その進捗を手元のセッションに報告させる使い方ができそうです。すでに複数タブでClaude Codeを開いている方は、次にコピペしそうになった瞬間に「隣のセッションに伝えておいて」と言ってみると、便利さがすぐ分かると思います。