Claude Codeのクロスセッションメッセージングとは？セッション同士が直接やりとりする新機能

こんにちは、AIニュースアプリ Morning AI 開発者の矢野哲平です。この記事ではClaude Codeに追加された「クロスセッションメッセージング」を、どういう機能で、何ができて、何が変わり、どう使うのかという順に整理します。

Message your other Claude Code sessions - Claude Docs

一言で言うと、別々に立ち上げたClaude Codeのセッション同士が、人間を経由せずにメッセージをやりとりできる機能です。macOS・Linux（WSL 2を含む）ではClaude Code v2.1.224以降、Windowsではv2.1.234以降で、特に設定せずに有効になっています。

そもそも何が困っていたのか

Claude Codeを日常的に使っていると、ターミナルを複数開いて並行作業する場面が出てきます。片方でAPIの実装、もう片方でフロントエンド、さらに別のタブでマイグレーション、といった具合です。

このとき困るのが、片方のセッションで起きたことをもう片方のClaudeが知らないことです。

スキーマを変更したのに、隣のセッションは古いカラム名のままコードを書き続ける。

移行が終わったかを確認するために、いちいちタブを切り替えて眺める。

結局、人間が連絡役になって各エージェントに事情を説明することになります。

クロスセッションメッセージングは、この橋渡しをClaude自身にやらせるものです。

ClaudeはListAgents（到達できるセッションの一覧）とSendMessage（名前を指定して送信）の2つのツールを使います。

このときやり取りするのはプレーンテキストです。会話履歴やファイルが渡るわけではありません（本文に@ファイル名と書いても、添付されず文字のまま届きます）。受信側が受け取るのは、送信者の名前と本文、そして返信先だけです。

何ができるのか

公式ドキュメントが挙げているのは次のようなケースです。

• 発見の引き継ぎ: 破壊的変更や設計判断を、影響を受ける側のセッションに要約して伝える
• 並列worktreeの調整: 同じリポジトリを別々のworktreeで触っているセッション同士で、何がマージされたかを共有する
• 長時間タスクの進捗確認: マイグレーションやテスト実行の状況を、手元で見ているセッションに報告させる
• マシンをまたぐやりとり: 別のマシンやクラウドで動いている自分のセッションに連絡する

いちばん実用性を感じるのは発見の引き継ぎです。

並列でエージェントを走らせたときの失敗は、「片方の前提が古くなっていることに人間もAIも気づかない」形で起きます。

その検知を、いちばん早く気づける立場にいるClaude自身にやらせるという発想は理にかなっていると思います。

一方で、クロスセッションメッセージングでできないことも明確に線引きされています。

送信側にも制約があり、自分のセッションで拒否された操作を他のセッションに代行させないよう指示されています。

厳しい設定のセッションが緩い設定のセッションに「代わりにこれを消して」と頼む、という権限の抜け道を送受信の両側から塞ぐ設計です。

クロスセッションメッセージングで変わること

いちばん大きく変わるのは、人間が連絡役をやめられることです。

これまでは片方のセッションの状況を人間がコピーして、もう片方に貼り付けて説明していました。

それをClaudeが直接対応してくれます。

しかも嬉しいことに、頼まなくても、ある変更が別のセッションの作業を壊すと気づいたときには自分から警告を飛ばします。

もうひとつの変化は、渡すものが要約に限られることです。

履歴を丸ごと受け取れる設計にすると、受信側のコンテキストは他人の作業ログで一気に埋まります。

テキスト一本に絞る制約は、不便に見えて送信側のClaudeに「何が本当に重要か」を判断させる仕掛けにもなっています。

並列実行まわりの機能は増えてきたので、役割の違いも整理しておきます。

境界線はシンプルです。

誰かがまとめて指揮を執る構造ならAgent Teams、

コンテキストごと持っていきたいならresume、

自分で始めて自分で操縦している対等なセッション同士の連絡だけがクロスセッションメッセージングです。

GitHub Copilot CLIの /fleetやGemini CLIのサブエージェントと比べても、「並列に動かす」ことより「並列に動いているものを噛み合わせる」ことに寄った機能です。

クロスセッションメッセージングの使い方

ユーザー側でツールを呼ぶ必要はありません。宛先の特定も含めてClaudeが判断するので、自然言語による指示で通ります。

もう一方のターミナルで動いているセッションに、マイグレーションが終わったか聞いて

いま実装した内容を、決済APIを触っているセッションに説明しておいて

宛先をはっきり決めたいときは、プロンプトの中で@セッション名と書いて指名することもできます（v2.1.232以降）。

送る文面もClaude自身が書きます。実際に届くのは、たとえばこんな一文です。

スキーマ移行が完了しました。新しいカラムは tenant_id です。mainへのリベースは安全です。

受信側では、Claudeが処理の合間にこれを読みます。ツールの実行中に割り込むことはなく、アイドル状態なら新しいターンとして受け取ります。画面には送信者の名前と1行目だけのプレビューで表示され、Ctrl+Oで全文を確認できます。プレビューの表示でも、Claude自身は全文を読んでいます。

「〇〇のセッションが終わったら教えて」と頼むこともできます。相手がアイドルになった時点で、通知が1回だけ届きます（同じマシン内のセッションだけ。12時間で失効）。

どのセッションに届くのかは/list-agents（別名 /peers）で確認します。出てこない場合は、まずclaude --versionでバージョンを確認しましょう。

ここに出てくる名前がそのまま宛先です。名前は/renameコマンドか起動時の--nameフラグで設定でき、指定しなければ作業ディレクトリ名からmy-app-3fのような名前が自動でつきます。

同一マシン内の通信はローカル完結で、Anthropicのサーバーを経由しません。macOSとLinuxでは各セッションが自分専用の受信ソケットをディスク上に作り、OSのユーザー単位でアクセスを制限します（Windowsでは名前付きパイプを使います）。この仕組みのため、コンテナの内と外、WSL 2とWindowsの間は相互に到達できません。

別のマシンやクラウドのセッションとやりとりする場合は、Remote Control経由になります。相手のマシンがRemote Controlにつながっていれば、手元から名前を指定して話しかけられます（v2.1.225以降）。公開当初、この記事では「別マシンへは返信しかできない」と書いていましたが、公開当日のアップデートで自分から送れるようになっていました。なお、Remote Controlを使うにはclaude.aiのアカウントでのログインが必要で、APIキーやBedrockなどでは使えません。マシンの外に送る前に必ず確認させたい場合は、isolatePeerMachines: trueを設定します。

受信の挙動を明示したい場合はcrossSessionInboundで指定します。/configの「Messages from your other sessions」からも選べます。

指定しない場合は、送る側と受ける側の権限モードの組み合わせで自動的に判断されます。

権限確認をスキップしないモード（デフォルトやAuto modeなど）どうしならそのまま届きます。どちらか片方だけが、権限確認をスキップするモード（bypassPermissions）で動いている場合は、承認待ちになります。無確認で実行できるセッションが絡むときほど慎重にする、という優先順位づけです。保留されたメッセージはターミナルに承認ダイアログとして表示され、放置すると5分（dialogExpiry）で破棄されます。

機能そのものを止めたい場合、組織全体なら管理設定でこう書きます。

{
  "permissions": {
    "deny": ["SendMessage", "ListAgents"]
  },
  "crossSessionInbound": "refuse"
}

なおSendMessageを拒否すると、サブエージェントやエージェントチームへのメッセージ送信も同時に使えなくなります。同じツールが両方の役割を担っているためです。

Claude Codeを1つのターミナルで使っているうちは出番のない機能ですが、並列で走らせ始めた途端に効いてきます。ルーティン機能で長時間のジョブを回している場合も、進捗を確認する使い方ができそうです。すでに複数タブで開いている方は、次にコピペしそうになった瞬間に「隣のセッションに伝えておいて」と言ってみてください。