SendMessage/ListAgentsの中身──Claude Codeのセッション同士は何をどこまで送り合えるか
Claude Code公式ドキュメントを確認すると、セッション間メッセージはListAgentsで相手を見つけSendMessageで届ける2つのツールで動いており、同一マシン内はAnthropicサーバーを経由しない。承認の代行はできない、内容はプレーンテキストのみ、同一マシン宛は約100万文字が上限など、具体的な制約が明記されている。
目次
Claude Codeのautoモードがデフォルト化した8月のアップデートと同時に登場した「セッション間メッセージング」は、名前だけ知られていても、実際に何が送れて何が送れないのかはあまり整理されていない。公式ドキュメントを確認すると、ListAgentsとSendMessageという2つのツールで動く仕組みで、承認の代行はできない・内容はテキストのみ・宛先ごとに上限があるといった具体的な制約が明記されている。この記事はその原文だけを根拠に、実際の挙動を整理する。
- セッション間メッセージングは
ListAgents(相手探し)とSendMessage(送信)の2ツールで動く。同一マシン内はAnthropicサーバーを経由せず、Unixドメインソケットまたは名前付きパイプで直接届く- 受け取ったメッセージは「指示」としては扱われない。承認の代行・設定変更・コマンド実行のいずれもできない、プレーンテキストの通知にとどまる
- 受信設定
crossSessionInboundは「managed settings→--settingsフラグ→ユーザー設定」の順で読まれ、refuse＞hold＞acceptの順でより厳しい設定が優先される。認識できない値を設定した場合、managed settings内ならrefuse扱い、それ以外ならhold扱いになる
2つのツールと「メッセージ」の定義
Claude Codeはこの機能を2つのツールで実装している。ListAgentsで届く相手を探し、SendMessageで名前を指定して届ける。どちらもClaudeが自動で呼び出すツールで、人間が直接叩くものではない。
公式ドキュメントは「メッセージ」を明確に定義している。メッセージとは、片方のClaudeがもう片方のClaudeに向けて書く一片のテキストであり、会話履歴やファイルそのものではない。 会話全体やコンテキストごと引き継ぎたい場合は、メッセージングではなくresume（セッションの再開）を使う必要がある。
宛先の種類は5つ
/list-agents（別名/peers）を実行すると、Claudeが届けられる相手の一覧が出る。公式ドキュメントによれば、行に現れる相手は次の5種類に分類される。
- サブエージェント：現在のセッション内で動く作業者
- チームメイト：自分自身のagent teamの仲間
- 同一マシン上の他セッション：バックグラウンドセッションを含む
- クラウドセッション：Remote Control接続中に見える、Claude Code on the webのセッション
- 他マシンのRemote Controlセッション：Remote Control接続中に見える。接続が切れていると
offlineと表示される
どこを経由するかはメッセージの宛先で変わる
これは見落としやすいポイントだが、宛先によってメッセージの経路が変わる。
| 宛先 | 経路 |
|---|---|
| 同一マシン上の他セッション | macOS/LinuxはUnixドメインソケット、ネイティブWindowsは名前付きパイプ。Anthropicサーバーは経由しない |
| 別マシンの自分のセッション | Anthropicサーバー経由、相手のRemote Control接続に届く |
| Claude Code on the web（クラウドセッション） | Anthropicサーバー経由、クラウドセッションに直接届く |
同一マシン内で完結する場合はローカル通信のみで、外部サーバーを通らない。別マシン・クラウド宛だけがAnthropicのサーバーを経由する。
受け取った側にできないこと
公式ドキュメントは、メッセージを受け取ったセッション側の制約を明確に書いている。他セッションからのメッセージは「あなたからの指示」としては扱われない。
- 承認の代行は不可：他セッションからのメッセージは、保留中の権限確認への「あなたの承認」としてはカウントされない
- 設定変更の指示に従わない：権限設定・CLAUDE.md・その他の設定を、他セッションに言われたからといって変更しないよう指示されている
- コマンドは実行されない：メッセージ本文に
/compactのようなコマンド文字列が含まれていても、プレーンテキストとして届くだけで実行はされない - 権限確認は通常どおり発火する：メッセージの内容を実行するために権限が必要なら、いつもと同じ確認プロンプトが出る
受信側の設定で挙動が変わる
crossSessionInboundという設定値で、届いたメッセージの扱いを制御できる。
| 値 | 挙動 |
|---|---|
accept |
すべて配信 |
hold |
通知だけ出し配信しない（acceptが後から適用されれば解放） |
refuse |
配信せず破棄 |
設定していない場合、Claude Codeは送受信セッションそれぞれの権限モードから自動判定する。権限確認をスキップするbypassPermissionsモードのセッションと、それ以外のモード（auto・acceptEdits・dontAskを含む、プロンプトを出すモード扱い）の2クラスに分け、次のルールを適用する。
- 受信側が権限確認を出すモード：基本は配信。送信側が「権限確認をスキップする」と自己申告している場合だけ承認待ちにする
- 受信側が権限確認をスキップするモード：基本は承認待ち。送信側も同様にスキップ側だと自己申告している場合だけ配信
保留（hold）されたメッセージは承認ダイアログで表示され、既定5分（dialogExpiry設定で変更可）で自動的に破棄される。保留は最大100件までで、それを超えると古いものから捨てられる。
サイズと連投の上限
公式ドキュメントが明記する制約は以下の通り。
- 同一マシン宛のサイズ上限：シリアライズ後で約100万文字。超えると送信元で拒否され、相手には何も届かない
- 連投の抑制：短時間の連投が相手の受信枠の上限に達すると、送信側で以降の送信が拒否される
- ループ抑制：受信側で送信者ごとにレート制限をかけ、短い時間内の同一メッセージの繰り返しを破棄し、Claudeが読める未処理キューは最大50件まで
crossSessionInboundの優先順位と、認識できない値の扱い
公式ドキュメント「Settings reference」でcrossSessionInboundの項目を確認すると、本文で触れたaccept/hold/refuseの3値に加えて、優先順位の仕組みが細かく説明されている。Claude Codeはmanaged settings→--settingsフラグ→ユーザー設定の順で値を探し、最初に見つかった値を使う。その際、refuseはholdより厳しく、holdはacceptより厳しいという序列があり、信頼できるソース（上記3つ）のいずれにも値がなくても、プロジェクトやローカルの設定にholdまたはrefuseがあれば、それが既定の自動判定より優先して適用される。
認識できない値を設定してしまった場合の挙動も明記されている。ユーザー・プロジェクト・ローカル・--settingsのいずれかに認識できない値がある間は、それより優先度の高いソースがacceptを指定していても、Claude Codeは受信メッセージを保留(hold)し続ける。一方、managed settingsに認識できない値が入っている場合は、管理者が修正するまでrefuseとして扱われる(v2.1.248より前のバージョンでは、この警告なしのフォールバックが実装されていなかった)。
機能を無効化する環境変数の、見落としやすい仕様
記事末尾でも触れるCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICについて、公式ドキュメント「Environment variables」を確認すると、他の多くの真偽値系変数とは挙動が違う点が明記されている。この変数は「設定されているかどうかだけ」を見る特殊な変数の1つで、0やfalseを設定しても無効化されない——空にするか、変数自体をunsetしない限り、機能はオフのままになる。同じ挙動をする変数としてDISABLE_TELEMETRY・DISABLE_ERROR_REPORTINGなども挙げられている。「CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=0と書いたのに機能が復活しない」というのは、この仕様を知らないとハマりやすい落とし穴だ。
使える条件
利用にはClaude Code v2.1.224以降（macOS・Linux・WSL2）またはv2.1.234以降（ネイティブWindows）が必要。
提供条件は「同じマシンの中か、マシンをまたぐか」で分かれる。公式ドキュメントのAvailability節にはこうある。
Sessions on this machine: available on every provider, including Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, and Microsoft Foundry, and in sessions that run with feature-flag fetching off. On those providers, and with flag fetching off, same-machine messaging requires Claude Code v2.1.248 or later.
（このマシン上のセッション同士：Amazon Bedrock・Claude Platform on AWS・Google CloudのAgent Platform・Microsoft Foundryを含むすべてのプロバイダで利用でき、フィーチャーフラグの取得を切っているセッションでも使える。それらのプロバイダとフラグ取得オフの場合、同一マシン内のメッセージングにはClaude Code v2.1.248以降が必要）
一方、マシンをまたぐ側（他のマシンのセッション・Web版のセッション）はRemote Controlに接続している必要があり、こちらはAPIキー利用時と上記4プロバイダでは見つけられないと明記されている。CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC 等でフィーチャーフラグ評価を切った場合に使えなくなるのも、マシンをまたぐ側だけだ（2026年9月4日に公式ドキュメントを取得して確認）。
配信レイテンシの数値は公式ドキュメントに記載がない
限界を先に書く。
実際の配信レイテンシ。 ローカル通信・Anthropicサーバー経由それぞれでどの程度の遅延が発生するかは、公式ドキュメントに数値の記載がなく確認していない。
組織向け管理設定の全体像。 管理者がorganization全体でSendMessage・ListAgentsを拒否ルールで無効化する設定例は載っているが、それ以外の管理者向けオプションを網羅的には確認していない。
コンテナ・サンドボックス環境での挙動。 コンテナ内のセッションとホスト側セッションは互いに到達できないと書かれているが、具体的な回避策や設計判断の背景までは確認していない。
関連記事
出典・参照資料
AIニュースの解説を動画でも
YouTubeでは注目ニュースの背景を解説し、Xでは新着記事をお知らせしています。
コメント
まだコメントはありません。最初のコメントを書いてみませんか？
AIについて聞きたいことはありますか？
質問箱で無料で受け付けています。回答は公開され、他の方の参考にもなります。
質問箱を見る →新しい記事をメールで受け取る
AIの新しい発表を、出典付きで整理して届けます。
関連記事
Dynamic Workflowsとは──JavaScriptスクリプトで数百のsubagentをオーケストレーションする仕組み
AI-Native SDLCとは──Anthropicが「コードの80%をClaudeが書く」現場から逆算した開発フロー
Claude Codeのエージェントチームとは──複数セッションが直接会話する実験的機能
Agent View入門──複数のClaude Codeセッションを一画面で束ねる
Claude Codeの定期実行──/loopのEscは「直接頼んだリマインダー」を止めない
Claude Code Remote Controlの切断──要件・プロセス・ネットワーク・認証の4系統で切り分ける
MCPサーバーを追加したのに認識されない──設定ファイル・スコープ・コマンド単体実行で切り分ける
