追記（2026-08-11）: 公開後、公式の機能ページが更新され、v2.1.225 以降は別マシンの Remote Control セッションへ名前を指定して新規会話を開始できることが本文に明記されました（「Starting a conversation with a session on another of your machines requires Claude Code v2.1.225 or later」）。あわせて経路表から「送れるもの（返信のみ）」の列自体が削除されています。本文中の「機能ページは返信のみ」「公式情報同士の食い違い」に関する記述は、公開日 2026-08-09 時点の記録としてそのまま残します（当時の保存版）。なお Claude Code on the web への新規送信の可否は、現行ページでも明示されていません。

何が起きたのか

Anthropicの公式ドキュメント「Message your other Claude Code sessions」が、Claude Code のセッション同士がメッセージをやり取りする機能を記載しています。要件は Claude Code v2.1.224 以降、対応OSは macOS と Linux（WSL 2 内の Linux を含む）で、ネイティブ Windows では提供されないと明記されています。同ドキュメントには「When a session meets the requirements, messaging is on with nothing to enable」とあり、要件を満たしたセッションでは有効化操作なしで動きます。

Claude が使うツールは 2 つだけです。到達可能なエージェントを列挙する ListAgents と、名前を指定して届ける SendMessage。ユーザーがこれらを直接呼ぶことはありません。9to5Mac も 2026-08-07 付でこの機能を取り上げています（9to5Mac 2026-08-07）。

ひとつ先に断っておくと、この機能は登場翌日に一度仕様が動いています。npm レジストリ上の公開時刻で v2.1.224 が 2026-08-07 10:36 JST（2026-08-07T01:36Z）、v2.1.225 が 2026-08-08 08:08 JST（2026-08-07T23:08Z）。公式 CHANGELOG の v2.1.225 には、マシンをまたぐ送信と非対話セッションの保留に関する変更が 2 件入っています（Claude Code CHANGELOG v2.1.225）。機能ページ側は公開日時点ではこの差分を反映していなかったため（冒頭の追記参照）、以下では該当箇所で両方を並べて示します。

面白いのは機能そのものより、公式ドキュメントが割いている分量の配分です。「何ができるか」の説明より、「何が届かないか」「どこで止まるか」の記述のほうが明らかに長い。エージェント間通信に必要な最小限のガードレールとは何か、という問いに対する Anthropic の現時点の解答が、そのまま仕様として書かれています。

3つの経路と、その非対称性

メッセージの通り道は、相手セッションがどこで動いているかで 3 通りに分かれます。公開日時点の公式ドキュメントの表を整理すると次のとおりです（その後のページ更新は冒頭の追記参照）。

相手の実行場所経路送れるもの
同じマシン上セッションごとのソケット経由、Anthropic サーバを経由しない新規メッセージと返信
自分の別マシンAnthropic サーバ経由、相手マシンの Remote Control 接続へ機能ページ上は返信のみ。CHANGELOG v2.1.225 で名指しの新規会話が追加
Claude Code on the webAnthropic サーバ経由、クラウドセッションへ直接返信のみ

同一マシン間は「never through Anthropic servers」と明示されています。各セッションはディスク上のファイルに自分を登録し、そこに受信箱ソケットをバインドする。ローカルの相手を探すときは Claude Code がそのファイルを読むので、同じファイル群が見える者同士でしか到達できません。コンテナは自前のファイルシステムを持つため、コンテナ内のセッションとホスト側のセッションは互いに届かない。同一コンテナ内の 2 セッションなら届く。この「ファイルが見えるか」という素朴な基準が、そのまま到達範囲の定義になっています。

マシンをまたぐ側は、公開日時点の機能ページ上では「返信のみ」でした。ただしこの記述は v2.1.225 の変更をまだ反映していないもので、CHANGELOG の v2.1.225 には「SendMessage が他マシンの Remote Control セッションへ名前を指定して会話を開始できるようになった。相手から先にメッセージが来たときだけ返信する形ではなくなった」とあります（ListAgents はそれらを name [ref] の形で表示します）。公開日時点では機能ページがこの差分を反映しておらず、公式情報同士が食い違っている状態でした（2026-08-11 までにページが更新され解消。冒頭の追記参照）。実装の現行に合わせるなら、Remote Control で到達できる自分の別マシンには、返信だけでなく新規の会話も送れると読むべきです。Claude Code on the web 側は CHANGELOG の変更対象に入っておらず、公開日時点のページでは返信のみとされていました。現行ページではこの列自体が削除されており、Web セッションへの新規送信の可否は明示されていません。

したがって「外部から任意のセッションへ話しかける経路を塞ぐ」という非対称性は、初版の設計であって現行の性質ではありません。残っているのは経路の制約のほうで、マシンをまたぐ通信は Remote Control 接続を通り、返信には返信アドレスが要ります。返信する側が Remote Control に接続していない状態でマシン外へ返信すると、Anthropic サーバへの直接リクエストとして通りはするものの、返信アドレスを持たないまま届くため、受け取った側はそれ以上答えられません。ドキュメントには「Claude is told as much when it sends」とあり、送信する Claude 自身にその旨が伝えられます。

ソケットのパスは 2 か所で確認できます。/status の Peer address 行（uds: プレフィックス付き）と、環境変数 CLAUDE_CODE_MESSAGING_SOCKET。後者はフックや Bash コマンドへエクスポートされ、SessionStart を含むあらゆるフックの実行前にエクスポートされます。各セッションは自分自身のソケットをエクスポートし、親セッションから継承したものを渡すことはありません。到達可能なセッションの一覧は /list-agents、別名 /peers で見られます。

既定の配信ルールは『同じ権限クラス同士』

ここが今回いちばん設計として読み応えのある部分です。受信側は crossSessionInbound 設定で挙動を選べます。値は 3 つで、accept は Claude へ配信、hold は通知だけ出して配信しない、refuse は配信せず破棄。

問題は、どのスコープにも値が設定されていないときです。そのとき Claude Code は、送信側と受信側それぞれの権限モードから、メッセージ単位で判断します。公式ドキュメントは全セッションを 2 クラスに分けます。許可プロンプトをバイパスするクラス（bypassPermissions 系）と、それ以外の「プロンプトするクラス」。プランモードは、バイパス権限が利用可能なセッションではバイパス側に数えられ、auto / acceptEdits / dontAsk はプロンプト側に数えられる、と細かく指定されています。

そのうえで規定は次の 2 行です。

  • 受信側がプロンプトするクラス: 各メッセージを配信する。ただし送信側が「バイパスする」と自己申告した場合のみ保留して承認を求める
  • 受信側がバイパスするクラス: 各メッセージを保留して承認を求める。ただし送信側も「バイパスする」場合のみ配信する

この 2 行を 2×2 の表に展開すると、意外な形が現れます。送信側クラスを $s$、受信側クラスを $r$ とし、いずれも $\{B, P\}$（バイパス／プロンプト）の値をとるとすると、配信可否 $D$ は

$$ D(s, r) = \delta_{sr} = \begin{cases} \text{配信} & (s = r) \\ \text{保留} & (s \neq r) \end{cases} $$

つまり既定値は、クロネッカーのデルタそのものです。「信頼度の高い側から低い側へは通す」といった半順序ではなく、クラスが一致したときだけ素通りする。$B \to P$ も $P \to B$ も、方向にかかわらず保留されます。バイパスセッションからの発言を無防備なセッションに流し込まない、というのは直感的ですが、逆向き（慎重なセッションからバイパスセッションへ）まで止めるのは、非対称な信頼モデルを避けて「クラス境界そのものを承認ポイントにする」という判断に見えます。境界を越える通信は、向きを問わず人間が一度見る。

保留された場合、受信セッションに承認ダイアログが開きます。承認すればその 1 通だけが配信され、拒否またはダイアログを閉じれば破棄。無応答のまま dialogExpiry の期限を過ぎるとダイアログは閉じ、メッセージは破棄されます。この期限のデフォルトは「5m」で、"60s" / "5m" / "10m" / "never" が指定でき、never で無効化できます（Claude Code Settings）。なお dialogExpiry はユーザー・managed・--settings の 3 ソースからしか読まれませんが、実効値は環境変数 CLAUDE_CODE_USER_DIALOG_TIMEOUT_MS で上書きできると設定リファレンスに明記されています。

保留中に受信セッションの権限モードクラスが変われば、Claude Code は受信ルールを再適用し、通るようになったメッセージを配信して通知を出します。逆に、変更によって refuse が適用されるようになった場合は、保留中のメッセージをすべて破棄し、到達できる各送信者に拒否を報告します。

メッセージにできない4つのこと

セッション A が B にメッセージを送ると、Claude Code は B の Claude に対して「これはユーザーではなく別セッションから来た」と伝えたうえで、できることを制限します。公式ドキュメントが挙げるのは 4 点です。

  1. 承認の代わりにならない: 他セッションからのメッセージはユーザーの同意として数えられず、保留中の許可プロンプトに代理で答えることはできない
  2. 設定を変更できない: 別セッションに言われたからといって、権限設定・CLAUDE.md・その他の設定を変更しないよう受信側 Claude に指示される
  3. コマンドは実行されない: メッセージ本文中の /compact のようなコマンドは、ただのテキストとして届く。Claude Code がそれを実行することはない
  4. 許可プロンプトは通常どおり出る: メッセージに従って動くのに権限が足りなければ、他の作業と同じプロンプトが出る

送信側にも制約があります。ドキュメントには、自分のセッションで拒否またはブロックされたアクション、あるいは自分の権限設定がブロックするであろうアクションを、別セッションに依頼しないよう Claude が指示されており、その作業はユーザーへ差し戻す、と書かれています。「権限境界はセッションごとに保たれる（Permission boundaries stay per-session）」という一文が、この節の主張を要約しています。

送られる中身も限定されています。メッセージは一方の Claude がもう一方に書くテキストであり、会話履歴やファイルではない。会話全体やコンテキストを移したいならセッションの再開を使え、と誘導されます。受信側が受け取るのは、原則として送信者名と本文、そして返信アドレスだけです（前述の一方向のマシン外メッセージには返信アドレスが付きません）。

そして、配信されたメッセージは「ユーザーが打ったプロンプトと同様に利用量にカウントされる」とも明記されています。セッション間通信はタダではありません。

ループの暴走を抑える3つの機構

エージェント同士が自動でメッセージを送り合う仕組みで最初に心配になるのは、往復が止まらなくなることです。ドキュメントの「Limitations」節は、これに 3 つの機構で答えています。

  • 送信者ごとに繰り返しメッセージをレート制限する
  • 短い時間窓内に届いた同一メッセージは破棄する
  • Claude が読むのを待っている受理済みメッセージを、1 セッションあたり 50 件 で打ち切る

これに加えて、保留メッセージは配信キューとは別枠で最大 100 件、それを超えると古いものから捨てられます。結果として「メッセージのループは自然に止まる（A message loop between two sessions therefore stops on its own）」と書かれています。

ここで 50 件と 100 件が何を切っているかは、正確に読む必要があります。どちらも同時に滞留できる件数の上限であって、時間を通じた累積メッセージ数の上限ではありません。受信側が読み進めればキューは空くので、ゆっくり往復し続ける 2 セッションはこの数値だけでは止まらない。ループを収束させているのは送信者ごとのレート制限と短時間窓内の同一メッセージ破棄のほうが主で、キュー上限はそれを補って「読まれないまま溜まり続ける」状態を有限に抑える役割です。レート制限の時間窓もしきい値も公開されていません。したがって「自然に止まる」は公式の説明の紹介として正確でも、文面を変えながら低頻度で続く通信まで必ず終了するという保証までは、公開仕様からは確認できません。

それでも設計の考え方としては読み取れるものがあります。1 通が平均何通の返信を誘発するかという増幅率そのものを推定・制御しようとせず、レート・重複・滞留量という観測できる量にそれぞれ独立に上限を置き、組み合わせで頭打ちにする。エージェント間通信のガードレールを自前で書くときに真似できるのは、この分解のしかたでしょう。

設定の優先順位は『厳しい方へのラチェット』

crossSessionInbound の優先順位は、Claude Code の一般的な設定優先順位とは別ルールで動きます。公式の設定リファレンスによれば、Claude Code はまず managed 設定、次に --settings フラグ、次にユーザー設定を読み、最初に見つかった値を適用します。プロジェクト設定やローカル設定の値は、それら信頼済みソースが与える値より 厳しい場合にのみ 適用される。厳しさの梯子は accept < hold < refuse です。信頼済みソースがどれも値を持たない場合、プロジェクトやローカルの hold または refuse は、前述のメッセージ単位の既定を置き換えて適用されます。

ここは「全スコープの最大値を取る」のとは別物である点に注意が要ります。基準になるのは managed → --settings → ユーザーの順で最初に見つかった値であって、その 3 つの中で最も厳しい値ではありません。managed が accept、--settings が refuse なら、基準は managed の accept です。厳しさを $\sigma(\text{accept})=0$、$\sigma(\text{hold})=1$、$\sigma(\text{refuse})=2$ と数値化するなら、$\max$ が効くのは基準値と project / local の間だけ、ということになります。それでも運用上の含意は変わりません。リポジトリにチェックインされた .claude/settings.json は受信を締めることはできても、緩めることはできない。同じ思想は isolatePeerMachines にも現れていて、これを true にするとマシン外へ出るすべての SendMessage に明示的な承認が要るようになり、bypassPermissions モードでも承認を求められます。そして「どのスコープからの true も適用される（A true from any settings scope applies）」ため、プロジェクトファイルは要件をオンにはできてもオフにはできません。

送受信を止めたい場合、方向ごとに手段が分かれます。受信を止めるのは crossSessionInbound を refuse に。送信と列挙を止めるのは SendMessage と ListAgents を名指しした拒否ルールで、いずれも指定子なしの素のツール名で書きます。組織全体で両方向を止める managed 設定の例も掲載されています。ただし SendMessage を拒否すると、同じツールを使うサブエージェントやエージェントチームへのメッセージングも一緒に消える点は注意が必要です。

日本の開発現場で最初に決めること

実務で最初に効いてくるのは、claude -p の非対話セッションの扱いです。-p セッションも対話セッションと同様に受信箱ソケットをバインドし、一覧に現れます。しかし -p セッションは承認ダイアログを表示できません。機能ページには、保留されたメッセージはそこで保留されたまま止まり、後のモード変更や設定変更で通るようになるまで届かない、と書かれています。ただしここも版差があります。CHANGELOG の v2.1.225 には「ヘッドレスセッションと起動中に、セッション間メッセージが通知も期限切れもないまま保留され続ける不具合を修正した」とあり、通知なしで無期限に溜まり続ける状態は v2.1.225 で解消されている前提で読むのが安全です。

送信元の権限クラスを問わず無人で受け取らせたいなら、その --settings 値で crossSessionInbound を accept にして起動します。ユーザー設定に accept を書いても効きますが、それは自分が起動するすべてのセッションに適用されます。なお既定ルールでも権限クラスが一致するメッセージは配信されるため、accept が要るのは「クラスをまたぐ送信元からも受けたい」場合です。逆に managed 設定に値があれば --settings の accept はそもそも読まれず、project / local により厳しい値があればそちらが勝つ点も、前節の優先順位のとおりです。

もうひとつ、bare モードで起動したセッションはソケットをバインドせず、受信もできなければ一覧にも現れません。「起動したはずのセッションが /list-agents に出てこない」ときの最初の確認先はここです。

フックやスクリプトから自セッションのソケットへ投げ返す「own-child メッセージ」の検証精度は、OS によって差があります。crossSessionInbound の値がどこにも設定されていない場合、Claude Code は自セッションの子プロセス（フックや Bash コマンド）から来たと検証できたメッセージを配信します。この検証は Linux（WSL 2 内を含む）なら子プロセスが既に終了していても可能ですが、macOS では投稿プロセスが動いている間しか検証できず、Claude Code が PID 1 として動くコンテナ内ではまったく検証できません。検証できないときは権限クラスを主張しないメッセージとして扱われるため、バイパスするセッションでは承認待ちで保留されます。開発機が macOS、CI がコンテナという構成では、同じフックが環境によって届いたり保留されたりします。

サンドボックス内の Bash コマンドからソケットに到達できるかどうかは、サンドボックスの Unix ソケット設定（sandbox.network.allowAllUnixSockets と sandbox.network.allowUnixSockets）で制御します。

残された不確実性

公式ドキュメントで確認できた範囲でも、運用上まだ判断材料が足りない点があります。

第一に、提供対象外の環境が明示されています。Amazon Bedrock、AWS 上の Claude Platform、Google Cloud の Agent Platform、Microsoft Foundry では利用できません。エンタープライズで Bedrock 経由の利用が主流の組織では、そもそも検討対象に入らない。この線引きが今後変わるかどうかは、ドキュメントからは読み取れません。

第二に、機能フラグ評価に依存している点です。CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC、DISABLE_TELEMETRY、DO_NOT_TRACK、DISABLE_GROWTHBOOK のいずれかがこの機能の依存する機能フラグ評価を止めると、セッション間メッセージングはオフのままになると記載されています。プライバシー目的でこれらを設定している環境では、同一マシン内の通信すら（Anthropic サーバを経由しないにもかかわらず）使えないことになります。この依存関係が恒久的なものか、初期展開に伴う一時的なものかは明示されていません。

第三に、既定ルールが依拠する「送信側が自分をバイパスクラスだと申告する」という部分です。ドキュメントは一貫して identifies itself / asserts という語を使っており、申告に基づく判定であることを隠していません。同一 OS ユーザー配下のソケットに限定されている以上、申告ベースでも成り立つ想定だと筆者は評価しますが（同一ユーザー権限で動く悪意あるプロセスに対する技術的保証が公式ページに示されているわけではありません）、複数の信頼レベルのセッションを同じユーザーで走らせる運用では、この前提を自分で確かめる必要があります。

第四に、公式情報同士の食い違いです（公開日時点の記録。機能ページは 2026-08-11 までに更新され、この食い違い自体は解消されました — 冒頭の追記参照）。公開日時点の機能ページは「マシンをまたぐ側は返信のみ」「非対話セッションでは保留されたまま」と書いていましたが、CHANGELOG の v2.1.225 はどちらも変えていました。機能ページには版表記がないため、どの版の挙動を説明しているのかを読み手が判別できないという構造的な問題は残ります。新機能の直後は CHANGELOG を先に見て差分を突き合わせる運用が要ります。

第五に、拒否設定の可視性です。refuse を設定したセッションは、自分の /status にも他セッションの一覧にも変化を見せません。ドキュメント自身が「そのセッションの設定から確認せよ」と促しています。送ったのに届かない、という状況の切り分けコストはそれなりに残ります。

まとめ

「セッション同士が会話できるようになった」という一文で流れていく話ですが、公式ドキュメントを読むと、実装の重心が通信そのものではなく境界の定義に置かれていることがわかります。同一マシンはソケット直結で Anthropic サーバを経由せず、マシンをまたぐ側は Remote Control 接続に限られる（v2.1.224 では返信のみ、v2.1.225 で名指しの新規会話が加わった）。到達範囲はファイルシステムの可視性で決まり、コンテナ境界がそのまま通信境界になる。既定の配信可否は権限モードクラスの一致で決まり、方向を問わずクラス境界を越える通信は人間の承認を要求する。メッセージは承認の代わりにならず、スラッシュコマンドも実行されない。設定変更のほうは技術的な遮断ではなく、「別セッションに言われたからといって変えるな」と受信側 Claude に指示する形で守られている。ループはレート制限・重複破棄・キュー上限の 3 つで抑える。

エージェント間通信のガードレールを自前で設計する立場から見ると、参考になるのは個々の値より原則のほうです。信頼を半順序ではなく同値類として扱い、境界越えを一律に承認ポイントにする。増幅率を直接制御しようとせず、レート・重複・滞留量という測れる量に分けて上限を置く。受信制限は project / local 設定から、managed・--settings・user が与える基準より緩められない（isolatePeerMachines も、どのスコープの true も下位設定から無効化できない）。この 3 つは、Claude Code を使うかどうかにかかわらず、複数エージェントを同居させるシステムに持ち込める考え方です。

主要出典

  • Message your other Claude Code sessions - Claude Code Docs（Anthropic 公式ドキュメント）: v2.1.224 以降・macOS と Linux 限定、ListAgents / SendMessage、同一マシンはソケット経由で Anthropic サーバ非経由、crossSessionInbound の accept / hold / refuse、既定の権限クラス判定、保留 100 件・受理済みキュー 50 件、非対話セッションと own-child メッセージの挙動、提供対象外プロバイダを確認。公開日 2026-08-09 時点の記述は同日の保存版で参照できる（その後の更新は冒頭の追記参照）
  • Claude Code CHANGELOG v2.1.225（Anthropic 公式・版固定リンク）: v2.1.225 の「SendMessage が他マシンの Remote Control セッションへ名前指定で会話を開始できる」「ヘッドレスセッションと起動中の無通知・無期限の保留を修正」の 2 件を確認。機能ページは公開日時点でこの差分を未反映だった（2026-08-11 に反映を確認）。版の公開時刻は npm レジストリ（@anthropic-ai/claude-code）で確認し、v2.1.224 が 2026-08-07 10:36 JST（2026-08-07T01:36Z）、v2.1.225 が 2026-08-08 08:08 JST（2026-08-07T23:08Z）、v2.1.226 が 2026-08-08 10:53 JST（2026-08-08T01:53Z）
  • Claude Code settings - Claude Code Docs（Anthropic 公式設定リファレンス）: crossSessionInbound の特殊な優先順位（managed → --settings → user の先着、project / local は厳しいときのみ）、dialogExpiry のデフォルト 5m と指定可能値、設定スコープの優先順位を確認
  • Claude Code now lets sessions talk to each other on macOS - 9to5Mac 2026-08-07: 一般メディアでの取り上げ。会話履歴やファイルは送られないこと、承認の代替にならないことを紹介。掲載は Aug 7 2026 3:29 pm PT で v2.1.225 の公開よりおよそ 40 分前のため、現行仕様の根拠には使えない

関連する過去記事