Anthropicは、Claude CodeにCross-session messagingの実験機能をリリースし、異なるSession間で直接メッセージを送信できるようにしました。この機能は完全なContextを伝送せず、タスクの結果と依存情報のみを伝送し、ListAgentsとSendMessageの2つの内部ツールを通じて実現されます。各ローカルSessionはディスクに登録され、Inbox Socketにバインドされ、ローカルメッセージはSocket経由で直接転送され、マシン間のメッセージはAnthropic Serverを介して転送されます。メッセージはSessionがアイドル状態になると新しいTurnをトリガーし、アクティブなTurnではTool Callの間で読み取られます。受信側はCross-sessionメッセージをUser Messageと区別し、ユーザーの承認を置き換えることはできません。また、accept/hold/refuseの3つのInbound Controlモードが設定されています。この機能は、Resume Session、Agent Teams、Worktreeなどの既存の機能と連携し、Claude CodeにSession間の調整レイヤーを提供します。

記事執筆者、出典：雷峰網

この数日間、AnthropicはClaude Codeに、Cross-session messaging、つまりセッション間メッセージ通信という新しい実験的機能を追加しました。

簡単に言えば、複数のClaude Codeセッションを同時に実行し、それらが直接メッセージを送信できるようにします。

たとえば、データベース用、バックエンドAPI用、テスト用の3つのClaude Codeセッションを開いたとします。以前は、これらの3つのセッションは並行して動作できましたが、互いにどの程度進んだかを知ることはできませんでした。データベースセッションでスキーマを変更しても、開発者は手動で別のターミナルに切り替えて、変更内容をバックエンドセッションに再入力する必要がありました。

Cross-session messaging を追加した後、このステップは Claude が直接完了できます。データベースセッションは、バックエンドセッションにどのフィールドが変更されたかを通知でき、テストセッションがインターフェースの回帰問題を発見した場合も、関連コードを修正中のセッションに結果を送信できます。Claude は、いつ他のセッションに通知する必要があるかを自ら判断でき、開発者の要請に応じて指定されたセッションに連絡することもできます。

それが具体的に何をしているかを理解するには、メッセージの完全なパスを追跡します。どのようなデータが送信され、どのように対象が特定されるか、メッセージがClaudeに到達するのはいつか、そして受信側がそのまま実行できない理由を確認します。

01 Contextではありません、一条のメッセージです

Cross-session messaging は、Claude Code の元のセッション隔離を変更していません。

セッションAがセッションBにメッセージを送信する際、自身の会話履歴、読み込んだファイル、または全体のコンテキストウィンドウを一緒に送信することはありません。公式規定では、セッション間で送信されるのはテキストのみです。完全な会話とコンテキストを別の端末に移行するには、セッション間メッセージングではなく、元のセッションを再開する必要があります。

これは複数のClaude間の協力方法を決定します。

データベースセッションがマイグレーションを完了するために数十のファイルを読み込み、複数のソリューションを試した結果、あるフィールドの変更が必要であると決定した。バックエンドセッションは、それまでのすべての分析プロセスを知る必要はなく、最終的な変更内容とその変更が自身のAPIに与える影響のみを把握すればよい。

したがって、Cross-session messaging は完全な作業メモリではなく、タスクの結果と依存情報を伝達します。

これにより、異なるタスクから生成される局所的な情報が他のセッションに次々と流入することはありません。データベースに関する詳細はデータベースセッションに、テストプロセスはテストセッションに留め、ある変更が他のタスクに影響を及ぼし始めるまで、関連情報はセッションの境界を越えません。

これは「すべてのエージェントが大きなコンテキストを共有する」という考え方とは異なるアプローチです。Cross-session messaging は、セッションを独立したまま保ち、タスク間に依存関係が生じた際に必要な状態を明示的に同期することを選択しています。

明確なメッセージが送信された以上、次の疑問は：Session A はどのように Session B を見つけるのでしょうか？

02 もう一つのセッションを見つける必要があります

Claude Codeは、クロスセッションメッセージングをサポートするセッションに独自の通信エントリを追加しました。

各ローカルセッションは関連情報をディスクに登録し、インボックスソケットをバインドします。ClaudeはListAgentsを用いて現在連絡可能なセッションを検索し、SendMessageを介して指定の宛先にメッセージを送信します。

ユーザーはこれらの内部ツールを自分で操作する必要はなく、Claudeにどのセッションに連絡したいかを伝えるか、タスクに依存関係が発生した際に自動で相手に通知してもらえばよいです。

セッションの名前もそのためアドレス指定に参加します。Claudeは名前で対象を検索できます；名前が重複した場合、システムは短い識別子を追加して区別し、同時にWorking Directoryを表示して、各セッションがどのプロジェクトまたはディレクトリを処理しているかを判断できるようにします。

目標を見つけた後、本機のメッセージは対応するセッションのSocketを介して直接送信され、Anthropicサーバーを経由しません。他のマシンまたはClaude Code Web上のセッションのみが、AnthropicサーバーとRemote Control関連の接続を介して通信します。

この発見メカニズムは、ローカル通信の境界を決定します。

Claude Code は、他のセッションがディスクに書き込んだ登録情報を読み取る必要があるため、2つのClaudeが物理的に同じコンピュータ上で実行されていても、ファイルシステムが相互に隔離されている場合、お互いを検出できない可能性があります。典型的なケースはホストと独立したコンテナです。2つのセッションが同じコンテナ内で実行されている場合、正常に通信できます。

Inbox Socket はオペレーティングシステムのユーザー権限の制限を受けるため、共有サーバー上の他のOSユーザーはあなたのセッションに直接アクセスできません。

したがって、ここで言う「ローカル通信」は、登録情報が表示可能かどうか、Socketが到達可能かどうか、およびオペレーティングシステムがアクセスを許可しているかどうかに依存しています。

メッセージはすでにターゲットを見つけ、Inbox に送信されました。次は Claude Code の Runtime が、このメッセージをモデルに渡すタイミングを決定する番です。

03 信息送达后

バックエンドのセッションがファイルを変更している最中に、テストセッションが最近発見されたインターフェースのリグレッション問題を通知しました。

Claude Code は、実行中のツールを即座に中断しません。

ターゲットセッションがアイドル状態の場合、メッセージは新しいターンをトリガーします。Claudeがすでにアクティブなターン中にいる場合、メッセージは2つのツールコールの間に読み込まれるまで待機します。

これは、Coding Agent の実行方法と関係があります。Claude はファイルを書き込み、テストを実行し、マイグレーションを実行したり、その他の時間のかかるタスクを処理している可能性があります。外部のメッセージがいつでも現在の動作を強制的に変更できると、ツールが一部のみ実行された状態で、Agent が新しい情報に基づいて再計画を開始してしまう可能性があります。

したがって、このメッセージはClaudeの今後の意思決定に影響を与えますが、進行中の操作を直接奪うことはありません。

これにより、Cross-session messaging が Claude Code の Agentic Loop に統合され、非同期の入力ソースとなりました。このエントリーポイントは、他の Claude Session だけでなく、他の用途にも利用できます。

Claude Codeは、現在のセッションのMessaging SocketをHookおよびBashで起動された子プロセスに暴露します。長時間実行されるバックグラウンドタスクが終了した後、Claudeがその完了を継続的にポーリングする必要なく、結果を現在のセッションに直接送信できます。

このチャネル自体は信頼できるメッセージキューではありません。重複メッセージはレート制限の対象となり、短時間内に同じ内容が削除される可能性があります。既に受信済みですがClaudeがまだ読み取っていないメッセージは、セッションごとに最大50件まで保持され、Hold状態のメッセージは別のバッファを使用し、最大100件まで保持されます。

したがって、状態の変化、タスクの結果、およびコラボレーション通知の送信に適しています。長期的に保存する必要のある事実は、依然として Git、ファイル、データベース、またはその他の永続化システムに記録する必要があります。

メッセージがRuntimeに到達しても、受信側はまだ直接実行アクションに移行できません。なぜなら、受信側は別のClaudeから送信された内容がどの程度の権限を持っているかをまず判断する必要があるからです。

04 権限はどのように継承されますか

Claude Codeは、User MessageとPeer Session Messageを明確に区別します。

他のセッションから送信されたコンテンツはユーザーの承認と見なされないため、ユーザーに代わってPermission Promptを承認したり、メッセージを通じて受信者にPermission SettingsやCLAUDE.mdその他の設定の変更を要求することはできません。メッセージにClaude Code Commandが含まれていても、通常のテキストとして扱われます。

セッションAがセッションBにファイルの削除を要求し、その操作がセッションBでユーザーの承認を必要とする場合、元の権限プロンプトが依然として表示されます。

Claude Codeは、別の権限回避方法も制限しています：ある操作が現在のセッションでPermission Systemによって拒否された場合、Claudeは別のセッションに代わって実行を依頼すべきではありません。

それ以外の場合、複数のセッションの権限が異なると、低権限セッションは自身では実行できない操作を高権限セッションに次々と転送し、元の権限境界が無効化されます。

権限の範囲を超えて、メッセージ自体にはインバウンドコントロールの層があります。受信側は、セッション間メッセージをaccept、hold、またはrefuseに設定できます：直接Claudeに渡す、さらに確認を待って一時的に保持する、または直接破棄する。

ユーザーが明示的にルールを設定していない場合、Claude Code は送信者と受信者の現在の Permission Mode を参照します。通常の Permission Prompt を回避できるセッションは、通常のセッションと同じメッセージソースとは見なされません。受信側の権限が高いため、外部メッセージは依然として Hold に保留される可能性があります。

ここには実際には二つの判断があります。まず、メッセージがClaudeに到達できるかどうかを決定し、次にClaudeがそのメッセージに基づいて実行しようとするアクションに権限があるかどうかを決定します。

この段階で、Cross-session メッセージの完全なパスが完了します：メッセージの生成からターゲットの発見、配信の完了、Runtime によるメッセージの読み取り、そして受信側の権限制御まで。

05セッション間の調整層

このリンクをClaude Codeの現在の機能に再配置すると、クロスセッションメッセージングの位置が明確になります。

Resume Session は、元の Conversation と Context を継続するために使用します。Agent Teams は、協力する Agent のグループを作成および管理します。Worktree は、異なる Session のコード変更を隔離します。Remote Control は、他のデバイスから Session を継続して制御する問題を解決します。

Cross-session messaging は、別の状況を処理します：元々独立して実行されていた複数のセッションが、タスクの実行中に依存関係を生じた場合に、必要な情報を相互に伝達する方法です。

以前は複数のClaude Codeセッションを開いて、並行処理の問題を主に解決していましたが、開発者は各ターミナルの進捗を監視し、人間とセッションの間でタスクの状態を繰り返し伝える必要がありました。現在、インターフェースの変更、テスト結果、移行完了などの情報は、直接影響を受けるセッションに送信されます。

Cross-session messaging は、複数のClaudeを1つのAgentに統合するのではなく、従来のコンテキスト、作業ディレクトリ、権限境界の外に通信機能を追加しています。

より大きなプロジェクトの文脈で見ると、この設計は、複数のエージェントが徐々に大きくなるコンテキストを共有することなく、明確な通信インターフェースを通じて協調する別のマルチエージェントのアプローチを提供する。タスク、ステータス、権限が分離されることで、システムはより拡張しやすくなる。

エージェントの数がさらに増加すると、問題は「単一のエージェントがどれだけのことを実行できるか」から、「これらのエージェント間で状態を安定して交換し、依存関係を処理し、引き継ぎを完了できるか」へと移っていきます。

Cross-session messaging はその一部にすぎないが、すでに Claude Code のマルチセッションワークフローに、より完成されたエンジニアリング構造をもたらしている。将来的には、このローカルネットワーク内のクロスセッションメカニズムが、マシンやエコシステムを越えた Agent-to-Agent 通信プロトコルへと進化するかもしれないが、今日のこの2つの Claude 間の短いやり取りこそ、高度な自動化ソフトウェアファクトリーが形成されるための鍵となる一歩である。