リリースされた機能と、実際に渡されるもの
セッション間メッセージングには、Claude Code v2.1.224以降が必要で、WSL 2内のLinuxを含むmacOSおよびLinuxで動作します。ネイティブのWindowsでは提供されていません。ドキュメントによると、セッションが要件を満たしている場合、「有効化するための設定は不要で、メッセージングはオンになります」。
この機能を支えるのは、Claudeが到達可能なエージェントを検出するListAgentsと、名前を指定してそのうちの1つにメッセージを配信するSendMessageという2つのツールです。ユーザーがどちらかを呼び出す必要はありません。「ClaudeがListAgentsで宛先を検出し、SendMessageで送信するため、ユーザー自身がどちらのツールも呼び出すことはありません。」例えば、「もう一方のターミナルで実行中のセッションに、マイグレーションが完了したか聞いて」のようにプロンプトを入力すると、Claudeが実際のメッセージを作成します。
届くメッセージは、ドキュメントの例にあるように以下のようになります。
`` Schema migration finished: the new column is tenant_id, and rebasing on main is safe now. ``
これが機能の全容であり、純粋に便利です。あるセッションが、別のセッションが構築中のものを破壊するような変更を加えた場合、あなたが気づく前にClaudeがそのセッションに警告できます。一方のセッションが、もう一方がブロックされている疑問を解決したとき、その回答が伝達されます。ドキュメントに記載されているユースケースは、発見事項の引き継ぎ、並行するworktreeの調整、長時間実行される作業からのステータス取得、およびマシン間での返信です。
限界を正確に知っておく価値があります。なぜなら、それによってあなたが依然として自分で解決しなければならないことが明確になるからです。
- テキストのみ。 制限事項のセクションには「プレーンテキストのみ」と記載されています。そして重要な一文は、「メッセージは、あるClaudeが別のClaudeに書き込むテキストの一部であり、会話履歴やファイルでは決してありません。会話全体またはそのコンテキストを移動するには、代わりにセッションを再開（resume）してください。」ということです。受信側のセッションは「そのテキストのみを受け取り、送信側の会話履歴やファイルは決して受け取りません」。
- マシン間は返信のみ。 同一マシン上のメッセージはセッションごとのソケットを介して送信され、Anthropicのサーバーを経由することはありません。他のマシンやWeb上のセッションへのメッセージは、Remote Controlを介してAnthropicのサーバーを経由します。この場合、Claudeは「返信することしかできず、やり取りを開始することはできません」。
- 検出はファイルシステムベース。 各セッションはディスク上のファイルに自身を登録し、そこにインボックスソケットをバインドします。そのため、2つのセッションは同じファイルを参照できる場合にのみ相互に到達できます。コンテナ内のセッションとホスト上のセッションは相互に到達できませんが、同じコンテナ内の2つのセッションは到達可能です。
- 配信は保証されません。 各メッセージは受信側セッションのインバウンドコントロールに対してチェックされ、
crossSessionInbound（accept/hold/refuse）によって制御され、最終的にDelivered（配信済み）、Held（保留）、またはRefused（拒否）になります。保留されたメッセージは承認ダイアログを開きますが、これには有効期限があります（dialogExpiryのデフォルトは5分）。Claude Codeは最大100件のメッセージを保留し、それを超えると古いものから破棄します。また、セッションごとに読み取り待ちの承認済みメッセージの上限は50件です。 - メッセージには権限がありません。 メッセージは「何も承認することはできず」、設定を変更することもできません。Claudeは、別のセッションから要求されたという理由で権限設定、
CLAUDE.md、またはその他の設定を変更しないよう指示されています。テキスト内の/compactは「プレーンテキストとして到着」し、実行されることはありません。また、受信側では依然として権限プロンプトが表示されます。 - 配信されるとコストが発生します。 配信されたメッセージは、「入力したプロンプトと同様に使用量としてカウントされます」。
これらは不満ではありません。適切に境界が定められた調整チャネルであり、その境界は意図的なものです。権限を承認したりCLAUDE.mdを書き換えたりできるメッセージは、機能ではなくセキュリティ上の問題になってしまいます。
なぜセッション間でコンテキストが共有されないのか
メッセージを渡すことは、メモリを共有することではない
この区別がすべてです。メッセージは、ある瞬間の、あるClaudeによる何かの要約を、別の1つのセッションに1回限り転送するものです。共有メモリとは、複数のセッションが同じ永続的な記録から読み取ることを意味します。そこでは、一度書き込まれた内容は、まだ存在しないセッションも含め、すべてのセッションで利用可能になります。
メッセージングが提供するのは前者です。これは、オフィスで大声で呼びかけることと、共有ドキュメントに書き込むことの違いに似ています。どちらも便利ですが、明日になっても残っているのは一方だけです。
メッセージは要約であり、要約は意図的に情報が欠落する
Claude自身がメッセージを作成します。ドキュメントには、同じプロンプトであっても「Claudeが送信する内容は異なる」と記されています。これは調整用のピングとしては正しい設計ですが、知識の伝達としては誤りです。本当に欲しかった注意書きこそが圧縮されて消えてしまい、後から何が削ぎ落とされたのかを記録する手段はありません。
同じパターンは、1つ下のレベルのサブエージェントでも見られます。サブエージェントはそれぞれ「独自のコンテキストウィンドウで実行」され、「要約のみを返し」ます。要約は、Claude Codeが全体を通してコンテキスト予算を保護するための手段です。そして、これが何も蓄積されない理由でもあります。
セッション終了後は何も残らない
3つのターミナルをすべて閉じると、それらの間でやり取りされたすべてのメッセージは、それらを保持していた会話とともに消え去ります。来週のセッションは、以前とまったく同じようにファイルから開始されます。先週の木曜日にセッション同士がどれほど上手く対話していたとしても、Claude Codeが依然としてプロジェクトのコンテキストなしで各セッションを開始するのはこのためです。
1つに混同されがちな3つの機能
ドキュメントではこれらを慎重に区別しており、誤った機能を使用することが、人々が失望する最も一般的な原因です。
- セッションの再開（Resume） — 1つの会話を別の場所で継続するか、そのコンテキストを新しいセッションと共有します。これはコンテキストを移動するためのドキュメント化された方法であり、1つの会話のコンテキストを移動します。
- セッション間メッセージング — ユーザーが開始して操作する独立したセッション間で、テキストを渡します。
- エージェントチーム — Claudeが生成して監視する、調整されたセッションのチーム。チーム内に留まる構造化されたプロトコルメッセージを使用します。
さらに、多くのセッションを監視するためのエージェントビュー、別のデバイスから操作するためのRemote Control、CIの結果などの外部イベントをセッションにプッシュするためのチャネルがあります。これら6つのメカニズムのいずれも、プロジェクトが把握している知識を保持しておく場所ではありません。
人々が試みること
メッセージングの代わりに再開（Resume）する。 実際にコンテキストが必要な場合には正しい選択であり、ドキュメントでも推奨されています。これにより1つの会話が継続されますが、3つのセッションがベースを共有するわけではありません。
すべてを`CLAUDE.md`に記述する。 標準的な回答であり、すべてのセッションがこれをロードするため、恒久的なルールの置き場所としては本当に適しています。ただし、リクエストごとのコストが発生するため、短く保つ必要があります。また、ここには「昨日学んだこと」ではなく、「書き留めることに決めたルール」が保持されます。
ターミナル間でのコピー＆ペースト。 メッセージングが置き換えるために構築されたものであり、Anthropicも「ターミナル間でコピー＆ペーストする代わりに」と表現しています。以前よりは改善されましたが、依然として要約の手動転送です。
複数のセッションの代わりに1つの巨大なセッションを使用する。 調整の問題は回避できますが、圧縮の問題が再発します。長いセッションは、自身のコンテキストの中間部分を失ってしまいます。
worktreeごとのメモを伴うworktree。 規律があり実行可能です。しかし、互いを知らないN個のメモセットを維持することになり、これはファイル形式における同様の分岐問題です。
すべてにエージェントチームを使用する。 1つの目標に対して監視されたチームを編成したい場合には適していますが、一般的なコンテキスト共有メカニズムとしては不適切です。チームのプロトコルメッセージはチーム内に留まり、チームが終了すれば消滅します。
解決策：すべてのセッションに読み込み用の単一ストアを提供する
調整チャネルは調整のために残し、知識はすべてのセッションが読み込める場所に配置します。
これこそが、6つの機能のいずれもカバーしていないレイヤーです。すべてのセッションよりも長生きし、どのセッションからでも発見事項を書き込むことができ、他のどのセッションからでも読み取ることができるストアです。これには、別のマシン上のセッション、コンテナ内のセッション、ネイティブWindows上のセッション、あるいはまったく異なるツール内のセッションも含まれます。消費されて消えるメッセージでもなく、ロードコストが高くなるまで肥大化するファイルでもありません。
MemoryLakeはその役割のために構築されています。セッションやエージェントがMCPまたはAPIを介して読み取る単一のメモリレイヤーであり、作業によって生み出された決定事項やドキュメントを保持します。メッセージングはセッションBに今すぐスキーマの変更を伝えますが、ストアがあるからこそ、セッションDは来週になってもその変更を知ることができます。
2つの明確な境界線があります。これはセッション間メッセージングを置き換えるものではなく、置き換えるべきでもありません。変更によって何かが壊れたというタスク途中の警告は今すぐ届く必要があり、それこそがメッセージングの目的です。また、共有ストアはセッションが読み取った内容に基づいて動作することを保証するものではありません。それはモデルの振る舞いです。これが変えるのは、知識が会話の中だけに存在するのではなく、永続的かつ検索可能な場所に存在するようになるということです。
ステップ 1: APIキーを作成する
キーを生成し、約30秒で最初のリクエストを送信できます。環境変数やシークレットマネージャーに保管してください。別のセッションからのメッセージは、設定の変更を明示的に禁止されているため、認証情報も同様に保護する必要があります。
ステップ 2: 最初のメモリをアップロードする
セッションが何度も再発見しがちな内容（アーキテクチャの決定事項、スキーマのメモ、先週誰かが直面した制約など）を保持するドキュメント、画像、ファイルを投入します。可能な限り、要約ではなくソース自体をアップロードしてください。渡されたメッセージの最大の問題は、それがすでに要約されてしまっていることだからです。
ステップ 3: AIとエージェントを接続する
Claude、Codex、OpenClaw、およびその他のAIエージェントに、MCPまたはAPIを介してメモリへのアクセスを許可します。Claude CodeはMCPサーバーをサポートしているため、各セッションは独自の設定から同じストアを読み取ることができます。これには、ネイティブWindows上のセッションや、ホストから隔離されたコンテナ内のセッションなど、メッセージングが到達できないセッションも含まれます。
実務における変化
最初の違いは、発見事項がメッセージではなく「事実」になることです。セッションAが、ベンダーAPIが失敗時に200を返すことを発見したとします。セッションBにピングを送信して両方のセッションが閉じたときにそれを失う代わりに、ストアに保存され、将来のすべてのセッションがそれを利用できるようになります。
2つ目は、メッセージングが橋渡しできないマシンやコンテナが問題にならなくなることです。マシン間メッセージングは返信のみであり、コンテナで隔離されたセッションは互いのソケットを認識できませんが、すべてがAPIに到達できます。仕事用のノートPCとコンテナの両方が同じ知識を読み取ります。これは、マシン間でコンテキストを失わないことの実用的なバージョンです。
3つ目は、メッセージがより短く、より洗練されることです。共有ベースがすでに存在する場合、メッセージは新しい情報（マイグレーションが何であったかを再説明する段落ではなく、「mainへのリベースが安全になりました」など）だけを伝えればよくなります。
そして、ツールを超えて存続します。スキーマの決定は、CodexやCursorでも同様に有効です。Claude Codeセッション間の会話に保持されている場合、それは Claude Codeの成果物にすぎませんが、ストアに保持されていれば、MCPに対応した任意のエージェントからアクセス可能になります。
複数セッションを実行するためのベストプラクティス
セッションに名前を付ける
セッションは、/renameまたは--nameフラグで設定した名前に応答します。名前がない場合、Claude Codeは作業ディレクトリのフォルダからmyapp-3fのような名前を派生させます。2つのセッションが同じ名前になることがありますが、/list-agentsでは作業ディレクトリによって区別されます。実行している作業（migration、payments-apiなど）にちなんで名前を付けることで、Claudeの宛先指定が確実になり、後でメッセージを読み返す際にも分かりやすくなります。
送信するためではなく、診断のために /list-agents を使用する
Claudeが自動的に宛先を見つけるため、送信を依頼する前にこれを実行する必要はありません。これが真価を発揮するのはトラブルシューティングです。/list-agentsが認識されない場合、そのセッションにはこの機能がありません。まずclaude --versionを確認してください。動作しているにもかかわらずメッセージが届かない場合は、権限拒否ルール、受信側のインバウンドコントロール、またはこのマシン以外のセッションに対する返信のみの制限など、より限定的な原因が考えられます。
無人ワーカーのインバウンドポリシーを慎重に決定する
claude -pワーカーはインボックスソケットをバインドし、リストに表示されますが、承認ダイアログを表示できないため、保留されたメッセージは保留されたままになります。ヘッドレスワーカーにメッセージを受け入れさせたい場合は、ユーザー設定（実行するすべてのセッションに適用されてしまうため）ではなく、そのワーカーの--settingsでcrossSessionInboundをacceptに設定してください。
決定事項はストアに、ステータスはセッションに送信する
優れた経験則として、今この瞬間だけ真実であること（「テスト実行が完了した」、「リベース中である」など）は、メッセージで送信します。来月になっても真実であること（「共有スキーマの制約により、org_idではなくtenant_idを選択した」など）は、ストアに書き込みます。ステータスには有効期限がありますが、決定事項にはありません。
メッセージングが利用できない場所では依存しない
OSの要件に加えて、セッション間メッセージングはAmazon Bedrock、AWS上のClaude Platform、Google CloudのAgent Platform、またはMicrosoft Foundryでは利用できません。また、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC、DISABLE_TELEMETRY、DO_NOT_TRACK、またはDISABLE_GROWTHBOOKなどの環境変数によって、この機能が依存する機能フラグの評価が無効化されている場合もオフのままになります。セットアップがこれらのいずれかに該当する場合、共有ストアが唯一のチャネルとなります。
結論
Claude Codeセッション間でのメッセージ送受信は真の改善であり、ワークフローに取り入れる価値があります。これにより、タスクの途中で一方のセッションがもう一方に何かを伝える必要がある場合に、ターミナル間でのコピー＆ペーストが不要になります。ドキュメント自体の表現を読んでみてください。メッセージはテキストであり、「会話履歴やファイルでは決してない」とし、会話のコンテキストを移動することはセッションを再開することを意味します。
したがって、このチャネルをその目的に合わせて使用してください。調整はメッセージングで行い、1つの会話の移動は再開（resume）で行い、監視されたグループはエージェントチームを使用します。そして、来月になっても有効であるべき知識は、すべてのセッションが読み取るストアに保存します。この最後のレイヤーこそが、Claude Codeに搭載されていないものであり、3つのターミナルを1つのプロジェクトのように感じさせるものです。