Claude Codeセッション間メッセージング解説：仕様・権限境界・組織での無効化設定¶
導入前に決める境界
| 利用場面 | 判断 |
|---|---|
| 同一マシンの独立セッションで調査結果や破壊的変更を伝える | セッション間メッセージングを使う |
| 会話履歴やファイルを別セッションへ引き継ぐ | メッセージではなくresumeを使う |
| 無人ワーカーが受信する | crossSessionInbound: "accept"を明示し、受信後の権限は別に制限する |
| 組織で機能を停止する | 送信ツールのdenyと受信のrefuseをmanaged settingsで併記する |
Anthropicは2026年8月7日、Claude Codeのセッション間メッセージング（Cross-Session Messaging）を公開した。2 セッション間メッセージはテキストだけを運び、権限判断は受信側のセッションに残る。1 組織導入では「連絡できるか」だけでなく、受信を受け入れる条件と、機能全体を止めるmanaged settingsまで先に決める必要がある。
利用者によるセッション間の中継作業がClaude側へ移る¶
複数のClaude Codeセッションを並行稼働させる環境では、片方で得た情報を他方へ伝える作業を利用者が担ってきた。 セッション間メッセージングは、この中継作業をClaude側へ移す。 一方のセッションで発生した変更が他方の作業を壊す場合、Claudeは警告メッセージを送れる。
メッセージは会話履歴やファイルを運ばない¶
これまでの中継は、ターミナル間でのコピー＆ペースト、または同じ内容の再説明だった。 一方で解決した論点を、それを待つ別セッションへ伝えることもできる。1
送られるのはプレーンテキストだけで、会話履歴やファイルは渡らない。 会話全体やコンテキストを別の場所へ移す場合は、メッセージングではなくセッションのresumeを使う。1
ClaudeがListAgentsとSendMessageを内部で使う¶
利用者が直接ツールを呼び出す必要はない。 ClaudeはListAgentsで到達可能な相手を探索し、SendMessageで名前を指定してメッセージを送る。1SendMessageは同一セッション内のサブエージェントやエージェントチームのメンバーにも使われる共通ツールである。
セッション名がメッセージの宛先になる¶
セッション名は/renameコマンドまたは起動時の--nameフラグで設定する。 指定しない場合、Claude Codeが作業ディレクトリのフォルダー名から名前を生成する（例：myapp-3f）。1
同名のセッションが複数存在する場合、/list-agentsはローカルセッションの作業ディレクトリを併記する。 Claude側の一覧には短い識別子も付き、名前が衝突した宛先を区別する。
到達可能な相手はlist-agentsで確認できる¶
/list-agents（別名/peers）には次の相手が表示される。1
- 現在のセッション内で動作するサブエージェント。エージェントチームのメンバーはチームの名簿を使うため含まれない
- 同一マシン上の他のセッション。バックグラウンドセッションも含む
- Remote Control接続中に見える、他マシンおよびClaude Code on the webのセッション
受信側はツール呼び出しの合間に読む¶
受信側のClaudeは、実行中のターンにおけるツール呼び出しの合間にメッセージを読む。 動作中のツールは中断されない。 受信側がアイドルなら、メッセージを起点に新しいターンが始まる。1
配送されたメッセージは、利用者が入力したプロンプトと同様に使用量へ計上される。
他セッションのメッセージは利用者の承認にならない¶
受信側のClaudeには、メッセージが利用者ではなく別セッションから来たことが伝えられる。 この区別によって、次の権限境界が維持される。1
- 承認を代行しない：別セッションのメッセージは利用者の同意とみなされず、保留中の権限プロンプトへ応答できない
- 設定を変更しない：別セッションから頼まれても、権限設定、
CLAUDE.md、その他の設定を変更しない - 本文中のコマンドを実行しない：
/compactなどが含まれてもプレーンテキストとして扱う - 通常の権限プロンプトを保つ：対応に新しい権限が必要なら、受信側で通常どおり確認する
送信側にも制約がある。 Claudeは、自分のセッションで拒否またはブロックされた操作や、自分の権限設定なら止められる操作を別セッションへ依頼せず、利用者へ差し戻すよう指示されている。1
受信ポリシーはDelivered、Held、Refusedへ分かれる¶
到着したメッセージは受信側の制御に照らされ、次のいずれかになる。1
| 結果 | 挙動 |
|---|---|
| Delivered | Claudeへ配送する |
| Held | 通知だけ表示し、承認、または後続の権限モード／設定変更まで配送しない |
| Refused | 配送せずに破棄する |
crossSessionInboundを明示しない場合、Claude Codeは双方の権限モードから判断する。 権限プロンプトをバイパスするセッションを一つのクラス、それ以外をもう一つのクラスとして扱う。 バイパスが利用可能な環境でのplanモードは前者、auto、acceptEdits、dontAskは後者に入る。1
- 受信側が権限プロンプトを出す場合：原則として配送する。送信側がバイパスを申告している場合だけ保留する
- 受信側が権限プロンプトをバイパスする場合：原則として保留する。送信側もバイパスを申告している場合だけ配送する
保留時には送信者とプレビューを含む承認ダイアログが出る。 無応答のままdialogExpiry（既定5分）を過ぎると、ダイアログは閉じてメッセージを破棄する。1 保留中のメッセージは配送キューと別に最大100件まで保持し、上限を超えると古いものから破棄する。
非対話セッションは受信設定を明示する¶
claude -pによるヘッドレスセッションも受信ソケットをバインドするため、長時間稼働するワーカーとしてメッセージを受け取れる。1 ただし承認ダイアログを表示できないため、保留されたメッセージは保留のまま残る。 無人で受信させる場合は、--settingsでcrossSessionInboundをacceptに設定して起動する。
bareモードで起動したセッションはソケットをバインドせず、受信も一覧表示もされない。1
受信ソケットもセッション固有の権限境界になる¶
Claude Codeは受信ソケットをOSユーザーに制限するため、共有マシン上の別ユーザーのセッションからは到達できない。1 ソケットの場所は/statusのPeer addressに表示され、hookとBashコマンドにはCLAUDE_CODE_MESSAGING_SOCKET環境変数として渡される。 各セッションは自分のソケットだけを公開し、親プロセスから継承した別セッションのアドレスを使わない。
明示的なcrossSessionInboundがない場合、自分の子プロセスから来たと検証できるメッセージは受け入れる例外がある。 Linux（WSL 2を含む）は終了後の子プロセスも検証できるが、macOSは送信プロセスが動作中の場合に限られ、Claude CodeがPID 1になるコンテナでは検証できない。1 検証できないメッセージは通常の受信ルールへ戻る。
sandbox内のBashからソケットへ到達させる範囲は、sandbox.network.allowAllUnixSocketsまたはsandbox.network.allowUnixSocketsで別に制御する。 無人ワーカーへacceptを設定しても、Unixソケットへ書き込めるプロセスの範囲まで自動的に安全になるわけではない。
マシンをまたぐ通信は返信だけに制限される¶
相手セッションの場所によって、メッセージの経路と送信できる内容が変わる。1
| 相手の所在 | 経路 | 送信できる内容 |
|---|---|---|
| 同一マシン | セッションごとのソケット。Anthropicのサーバーを経由しない | 新規メッセージと返信 |
| 別マシン | Anthropicのサーバーを経由し、Remote Control接続へ届く | 返信のみ |
| Claude Code on the web | Anthropicのサーバーを経由してクラウドセッションへ届く | 返信のみ |
別マシンから届いたメッセージへの返信は、返信側がRemote Controlへ接続していない場合でもAnthropicのサーバーへ送れる。 ただし、その返信にはreply addressが付かないため、受信側から再返信できない。1
同一マシン内の到達性は、各セッションがディスク上へ登録するファイルを相互に参照できるかで決まる。 コンテナは独自のファイルシステムを持つため、コンテナ内とホスト側のセッションは相互に到達できない。 同一コンテナ内のセッション同士は到達できる。
組織は送信と受信を別々に制御する¶
企業環境で導入可否を判断する場合、送信と受信が別の制御である点を外せない。
マシン外への送信に承認を必須にする¶
{
"isolatePeerMachines": true
}
isolatePeerMachinesをtrueにすると、マシンをまたぐ返信の送出前に明示的な承認を求める。1 通常の権限プロンプトを飛ばすbypassPermissionsモードでも承認が必要になる。 いずれかの設定スコープでtrueなら適用されるため、リポジトリにコミットしたプロジェクト設定から有効化できるが、下位スコープから無効化できない。
組織全体で機能を無効化する¶
管理者が組織全体で停止する場合は、managed settingsで送信側のツール拒否と受信の拒否を併記する。1
{
"permissions": {
"deny": ["SendMessage", "ListAgents"]
},
"crossSessionInbound": "refuse"
}
この設定でも各セッションは受信ソケットをバインドするが、到着したメッセージをすべて破棄する。 SendMessageの拒否は、同じツールを共有するサブエージェントやエージェントチームへのメッセージングも止める。
拒否設定が入ったセッションは、自身の/statusにも他セッションの一覧にも目立つ変化を出さない。 適用状況はmanaged settings側から確認する必要がある。
利用可否はバージョン、OS、プロバイダ、環境変数で決まる¶
対応条件を満たしたセッションでは、追加の有効化操作なしで最初から利用できる。1 必要条件は次のとおりである。1
- バージョン：Claude Code v2.1.224以降
- 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のいずれかが評価を止めると、機能も無効になる
環境変数はシェル、設定ファイルのenvマップ、managed settingsから供給され得る。 プライバシー対策としてテレメトリを一括無効化した組織では、意図せず機能が使えない場合がある。
切り分けは/list-agentsで行う。1
- コマンドが認識されない：機能自体がない。
claude --versionから要件を確認する - コマンドは動くが送信が届かない：機能は有効で、denyルール、受信制御、マシン外への返信専用ルールなど、限定的な要因が働いている
チャネルはプレーンテキストとスロットリングに限定される¶
構造化されたエージェントチームのプロトコルメッセージはチーム内に留まり、独立セッション間ではプレーンテキストだけを送る。1
メッセージループには、送信者ごとのレート制限、短時間に届いた同一内容の重複排除、Claudeが読む前の受け入れ済みメッセージをセッションあたり50件に制限する仕組みがある。 無限往復を業務上の排他制御やワークフロー管理の代わりにはできない。
既存機能との使い分けは作業の所有関係で決まる¶
公式ドキュメントは、複数セッションを扱う目的ごとに別の機能を示している。1
| やりたいこと | 使う機能 |
|---|---|
| 会話を別のターミナルで続ける、コンテキストを新セッションと共有する | セッションのresume |
| Claudeが生成、監督する協調グループを作る | エージェントチーム |
| 多数のセッションを一箇所から監視、操作する | エージェントビュー |
| 別デバイスからセッションを自分で操作する | Remote Control |
| CI結果やチャットなど外部イベントを流し込む | チャネル |
| 自分で起動した独立セッション同士で情報を渡す | セッション間メッセージング |
セッション間メッセージングが埋めるのは最後の行である。 利用者が個別に立ち上げ、Claudeの統制下にない独立セッション同士の情報伝達を担う。
改善対象は複数セッション利用者に限られる¶
同一マシン上で複数のClaude Codeセッションを並行稼働させる利用者には、手動の中継を減らす直接的な改善になる。 単一セッション運用の利用者には挙動の変化がない。
この要件は以前から可視化されていた。 Anthropicのリポジトリには2026年2月、大規模プロジェクトを並行セッションで進める利用者が直接的なワークフロー連携を求めるIssueを提出している。3 そこでは、Markdownファイルによる手動ハンドオフや、利用者自身がセッション間のメッセージバスになるコピー＆ペーストが回避策として挙げられていた。
2026年7月の別Issueは、単一リポジトリと単一作業ツリーへ多数の独立セッションを走らせる構成に、一次的な協調手段がないと報告した。4 セッション間メッセージングは、この空白のうち情報伝達を一次機能として提供した。 排他制御、共有状態ストア、作業ツリーの競合防止までを提供する機能ではない。
公開直後ほど一次情報の照合が必要になる¶
v2.1.224の公式リリースには31件の変更が並び、セッション間メッセージングと同時にTeamおよびEnterprise向けのclaude self-hosted-runnerも追加された。2 同じリリースに複数の大型機能が含まれるため、紹介記事の見出しだけでは対応OS、設定キー、受信ポリシーの例外を取りこぼしやすい。
導入判断では、バージョン番号、対応OS、プロバイダ、設定キー、件数上限を公式ドキュメントとリリースノートで追跡する。 SNS上の反応規模や導入効果の試算を使う場合は、仕様とは別の証拠として出典を確認する必要がある。