結論：Claude Code v2.1.224以降、独立した複数のセッション（別ターミナル・別マシン・Claude Code on the webを含む）はListAgentsとSendMessageという2つのツールを通じてテキストメッセージを送り合える。会話履歴やファイルは運ばれず、送るのは「文章」だけ。macOS/Linux対応で、Bedrock・Claude Platform on AWS・Google Cloud Agent Platform・Microsoft Foundriaでは利用できない。
- 要点1：ユーザーはツールを直接呼ばない。「隣のセッションに◯◯を伝えて」と頼むと、Claudeが
ListAgentsで宛先を探しSendMessageで送る。 - 要点2：受信側の既定動作は
crossSessionInbound設定と送受信双方の権限モード（プロンプトあり/bypassPermissions）の組み合わせで決まり、Delivered（配信）/ Held（保留・要承認）/ Refused（破棄）の3通りに分岐する。 - 要点3：受信メッセージは「あなたの承認」にはならない。設定変更・保留中の権限プロンプトへの回答・スラッシュコマンドの実行はできない設計になっている。
対象読者：複数のworktreeやターミナルでClaude Codeを並行運用している開発者・チームリード。
今日やること：2つ以上のセッションを開いて/list-agents（エイリアス/peers）を実行し、いま自分から見えているセッションを確認する。
worktreeを分けて2つ、3つとClaude Codeのセッションを同時に走らせていると、「片方の変更がもう片方の作業を壊していないか」を確かめるためだけに、ターミナルを行き来してコピー&ペーストする時間が積み上がる。2026年8月時点のClaude Codeには、この行き来をClaude同士に任せる仕組み——セッション間メッセージング（cross-session messaging）——が入っている。本記事では、公式ドキュメント（code.claude.com/docs/en/cross-session-messaging）とv2.1.224〜v2.1.235の公式changelogに基づいて、仕組み・設定・実践パターン・制限事項を整理する。
本記事の位置づけ：本記事は公式ドキュメント・公式changelogの内容整理と、それに基づく一般化された実装パターン解説（想定シナリオ）です。固有の顧客名・実在の導入事例・実測の削減率は含みません。数値・挙動はすべて公式ドキュメント記載の仕様であり、シナリオ部分は「想定シナリオ」であることを明記しています。
Claude Codeのセッション間メッセージングとは
セッション間メッセージングは、あなたが起動した独立したClaude Codeセッション同士が、Claudeを介してメッセージをやり取りできる機能。片方のセッションで見つかった破壊的変更や決定事項を、影響を受ける作業をしているセッションへ、あなたが再説明しなくてもClaudeが要約して伝える——というのが公式ドキュメントの説明。
重要なのは「メッセージは一方のClaudeがもう一方のClaudeに向けて書く文章であり、会話履歴やファイルそのものではない」という点。会話全体やコンテキストごと引き継ぎたい場合は、この機能ではなくセッションのresumeを使う、と公式ドキュメントは明確に線引きしている。
ClaudeはListAgentsで「メッセージを届けられる相手」を発見し、SendMessageで名前指定して届ける。同じSendMessageツールは、単一セッション内のサブエージェントやagent teamsのチームメイトへのメッセージにも使われるが、本記事が扱うのは「独立したセッション同士」の話に限定する。
なぜ必要か — worktree並行開発の同期コスト
公式ドキュメントが挙げる典型的な使いどころは次の4つ。
- 発見事項の引き渡し：あるセッションが破壊的変更や決定事項を見つけたとき、影響を受ける領域を作業しているセッションへClaudeが要約して伝える
- 並行worktreeの調整：同じリポジトリを別々のworktreeで作業している複数セッションに、何がマージされたかを伝える
- 長時間タスクの状態確認：マイグレーションやテスト実行の完了を、監視しているセッションへ報告させる
- マシンをまたいだやり取り：別マシンやRemote Control経由でのセッションに届ける
一方で公式ドキュメントは「独立して自分で操作するセッション同士」に使う機能だと明言しており、他の目的には専用の機能を使うよう案内している。同じ会話を別ターミナルで続けたいならresume、Claudeが自分でスポーンして監督するチームならagent teams、多数のセッションを1箇所から見て操作したいならagent view（バックグラウンドセッション）、スマホなど別デバイスから自分で操作したいならRemote Control、CI結果やチャットのような外部イベントをセッションに流し込みたいならchannels——という使い分けが公式に整理されている。
仕組み — ListAgentsとSendMessageの動作
ユーザーがListAgentsやSendMessageを直接呼ぶことはない。プロンプトで「隣のターミナルのセッションに、マイグレーションが終わったか聞いて」のように頼むと、Claudeが宛先を探して送る。
他のターミナルで動いているセッションに、マイグレーションが終わったか聞いて本文の内容までClaudeに任せることもできる。
決済APIを触っているセッションに、いま何をしたか要約して伝えて宛先を自分で指定したい場合は、プロンプト内で@に続けてセッション名の頭文字を打つと候補が出る（v2.1.232以降）。サブエージェントの@メンションと同じ操作感。
@api-worker にスキーマ移行が終わったことを伝えて自分から見えている相手を確認したいときは/list-agents（エイリアス/peers）を実行する。サブエージェント・同一マシン上の他セッション（inboxソケットを持つセッションのみ）・Remote Control接続中のクラウドセッション／他マシンのセッションが一覧表示される。
/list-agentsセッションが答える「名前」は/renameコマンドか--nameフラグで設定したものが優先され、未設定なら作業ディレクトリ名から自動生成される（例: my-appディレクトリならmy-app-3f）。同名のセッションが複数動いている場合は、Claude Codeが識別子を付けて区別する。
メッセージが「何を運ぶか」「何を運ばないか」
受信側が実際に目にするのは、送信元セッション名・返信先（ある場合）・本文テキストのみ。送信元の会話履歴やファイルは一切渡らない。公式ドキュメントに掲載されている、Claudeが書いたメッセージの実例は次の通り。
Schema migration finished: the new column is tenant_id, and rebasing on main is safe now.メッセージが届くタイミングは2通り。受信側Claudeがターン実行中なら、動いているツール呼び出しを中断せず、ツール呼び出しの合間に読む。受信側がアイドル状態なら、そのメッセージで新しいターンが始まる。配信されたメッセージは、あなたが打ち込んだプロンプトと同様に使用量にカウントされる。
受信側の制御 — crossSessionInboundと3つの結果
送信はSendMessageツールでサイズ上限を超えた時点で拒否されるが（後述の「制限」参照）、通過したメッセージは受信側の設定で最終的に次の3通りのいずれかになる。
| 結果 | 意味 |
|---|---|
| Delivered（配信） | Claude Codeがメッセージを受信側Claudeにそのまま渡す |
| Held（保留） | 通知だけ表示し配信しない。承認するか、後で設定がaccept側に変わると解放される |
| Refused（破棄） | 配信せずに削除する |
この結果を決めるのがcrossSessionInbound設定。
| 値 | 挙動 |
|---|---|
accept |
届いたメッセージをすべてClaudeに配信する |
hold |
通知を表示し配信しない。後でacceptが適用されたら保留分を解放する |
refuse |
届いたメッセージをすべて配信せず破棄する |
crossSessionInboundが未設定の場合、Claude Codeは送信側・受信側それぞれの権限モードから既定値を判断する。bypassPermissionsモードで動くセッション群を1つのクラス、それ以外（acceptEditsやauto、dontAskを含むプロンプトあり系）をもう1つのクラスとして扱う。
- 受信側が通常どおりプロンプトで確認するモードなら、基本は配信。送信側がbypass系だと自己申告した場合のみ承認待ちで保留
- 受信側がbypass系なら、基本は承認待ちで保留。送信側も同じくbypass系だと自己申告した場合のみ配信
承認ダイアログが既定の期限（dialogExpiry、既定5分）内に回答されないと、Claude Codeはダイアログを閉じてメッセージを破棄する。/configの「Messages from your other sessions」行からもcrossSessionInboundを選べる（v2.1.232以降。管理設定や--settingsフラグが値を制御している場合はこの行自体が表示されない）。
マシンをまたぐ場合の経路
宛先セッションがどこで動いているかによって、メッセージの経路とAnthropicサーバーを経由するかどうかが変わる。
| 宛先セッションの場所 | 経路 |
|---|---|
| 同一マシン上 | セッションごとのソケット経由。Anthropicサーバーは経由しない |
| 自分の別マシン | Anthropicサーバー経由。宛先マシンのRemote Control接続で受信 |
| Claude Code on the web | Anthropicサーバー経由。クラウドセッションに直接届く |
別マシンの相手とのやり取りを新規に「開始」するにはv2.1.225以降が必要で、かつ/list-agentsの一覧にその相手が表示されている状態が前提になる（v2.1.225より前は、相手から届いたメッセージへの返信しかできなかった）。自分の別マシンやクラウドセッションを一覧に出すには、このセッション自身がRemote Controlに接続している必要がある。
マシンを越えるメッセージすべてに事前承認を必須にしたい場合は、設定でisolatePeerMachinesをtrueにする。
{
"isolatePeerMachines": true
}これを設定すると、bypassPermissionsモードで動いているセッションからのメッセージであっても、機外（このマシンの外）へ出る前に承認が必要になる。同一マシン内のセッション同士には、このプロンプトは出ない。
実践パターン（想定シナリオ）
事例区分：想定シナリオ — 以下は公式ドキュメントに掲載されている挙動をもとに構成した、一般的な開発チームの実装パターン解説です。特定企業の実測値・固有の環境ではありません。
シナリオ1: worktreeを分けたAPIスキーマ変更のハンドオーバー
バックエンドとフロントエンドを別worktreeで並行開発しているとき、バックエンド側セッションでスキーマ移行が終わったら、Claudeがフロントエンド側セッションへ要約を送る、という使い方が想定できる。公式ドキュメントに掲載されている実例のメッセージ文面は「Schema migration finished: the new column is tenant_id, and rebasing on main is safe now.」——スキーマ移行の完了・変更点・mainへのrebaseが安全かどうか、を1文で伝える形になっている。人間が2つのターミナルを行き来して状況を伝える手間を、Claude同士のやり取りに置き換えるイメージ。
シナリオ2: 長時間マイグレーション・テストの監視
大規模なデータマイグレーションやE2Eテストのように数十分単位で終わるタスクを、別セッションで監視しながら本来の作業を続けたい場合。「テストが終わったら教えて」と頼んでおけば、監視セッションが完了を検知した時点でメッセージを送ってくる想定になる。受信側がアイドルなら新しいターンとして即座に扱われ、作業中なら現在のツール呼び出しを中断せず、合間で読まれる。
シナリオ3: Remote Control経由でのクロスマシン通知
デスクトップでRemote Controlに接続したまま、自宅のノートPCで動かしているセッションへメッセージを送る場合。このとき受信側には送信元のRemote Control名（例: laptop-graceful-unicorn）で表示され、その名前宛に返信できる。送信側がRemote Controlに接続していない状態で機外へ送ると、返信先情報のないメッセージとして届く——つまり相手は返信できない片道メッセージになる、と公式ドキュメントは注記している。
制限を理解する
公式ドキュメントの「Limitations」節に明記されている、機能そのものの制約は次の3つ。
- プレーンテキストのみ：Claudeが送れるのはプレーンテキストのみ。agent teamsの構造化されたプロトコルメッセージはチーム内に閉じる
- 同一マシン内メッセージのサイズ上限：シリアライズ後のサイズが約100万文字を超えると、Claude Codeは同一マシン内のセッションへのメッセージを拒否する。受信側には何も届かない
- メッセージループの抑制：同じ送信元からの繰り返しメッセージはレート制限され、短時間内の同一内容の連投は破棄され、Claudeが読む前に溜まる受信待ちメッセージは1セッションあたり最大50件に制限される。これにより2セッション間のメッセージループは自然に止まる
利用可否については、v2.1.224以降であることに加えて、対応OS（macOS・Linux、WSL 2上のLinuxを含む）、プロバイダ（Bedrock・Claude Platform on AWS・Google Cloud Agent Platform・Microsoft Foundryは非対応）、そしてCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICやDISABLE_TELEMETRY、DO_NOT_TRACK、DISABLE_GROWTHBOOKといった環境変数の設定次第で機能が無効化されている場合がある、と公式ドキュメントに明記されている。
セキュリティ境界 — 受信メッセージは「あなたの承認」にならない
セッションAからセッションBへメッセージが届いたとき、Claude CodeはB側のClaudeに「これは他のセッションからのメッセージであり、あなたから送られたものではない」と伝え、次のように行動を制限する。
- 何も承認できない：他セッションからのメッセージは、あなたの同意にはならない。保留中の権限プロンプトに代わって答えることはできない
- 設定を変更できない：他セッションに頼まれたからといって、権限設定や
CLAUDE.mdなどの設定を変更してはいけない、とClaudeは指示されている - コマンドは実行されない：メッセージ本文に
/compactのようなコマンド文字列が含まれていても、プレーンテキストとして届くだけで実行はされない - 権限プロンプトは通常どおり発火する：メッセージの依頼を実行するのに権限が必要なら、他の作業と同じ確認プロンプトが表示される
権限境界はセッションごとに独立している。「自セッションで拒否・ブロックされた操作を、他セッションに肩代わりさせるよう頼んではいけない」とClaudeは指示されており、送受信を止めたい場合は次の設定で塞げる。
{
"permissions": {
"deny": ["SendMessage", "ListAgents"]
},
"crossSessionInbound": "refuse"
}これを管理設定（managed settings）に入れると、組織単位で送信・一覧表示・受信のすべてを止められる。SendMessageを拒否するとサブエージェント・agent teamsへのメッセージ送信も同時に無効になる点は、既存のサブエージェント運用を止めていないか確認してから適用したい。
【要注意】よくある失敗パターンと回避策
失敗1：会話ごと引き継ぎたいのにメッセージ機能を使う
❌ 「セッション間メッセージングでコンテキストを丸ごと移せる」と誤解して使う
⭕ 会話全体・ファイル・コンテキストを引き継ぎたいならresumeを使う
なぜこれが重要か：公式ドキュメントは「メッセージは一方のClaudeが書いた文章であり、会話履歴やファイルではない」と明言している。移したいのが「文脈」なのか「1件の連絡事項」なのかで、使うべき機能が変わる。
失敗2：受信側の権限モードを確認せずに「届かない」と思い込む
❌ メッセージが届かないのを機能不良だと判断する
⭕ 受信側がbypassPermissions系のモードで動いていないか、crossSessionInboundがrefuseやholdになっていないかを先に確認する
なぜこれが重要か：既定の挙動は送受信双方の権限モードの組み合わせで自動的に決まる。特にbypassPermissionsで動く受信セッションは、既定で承認待ちの保留になる設計であり、故障ではない。
失敗3：コンテナ内のセッションと結びつけようとする
❌ ホスト側セッションとコンテナ内セッションを同一マシン扱いで一覧に出そうとする
⭕ 各セッションはディスク上のファイルで自己登録し、同じファイルが見えるセッション同士しか発見できない前提で設計する
なぜこれが重要か：コンテナは独自のファイルシステムを持つため、コンテナ内のセッションとホスト側のセッションは互いに発見できない。同一コンテナ内の2セッション同士やself-hosted runner上の複数セッションは引き続きメッセージし合える。
失敗4：大量の状態通知をループさせる設計にする
❌ 2つのセッションに互いへ頻繁に通知させ続ける設計にする
⭕ ハンドオーバーや完了報告など「一度きりの伝達」に用途を絞る
なぜこれが重要か：Claude Codeは同一送信元からの繰り返しメッセージをレート制限し、短時間の同一内容連投は破棄し、受信待ちキューも1セッションあたり50件で上限を設けている。恒常的な相互通知を前提にした設計は、この抑制機構に引っかかりやすい。
関連機能との使い分け
| やりたいこと | 使う機能 |
|---|---|
| 同じ会話を別ターミナルで続ける・コンテキストごと引き継ぐ | セッションのresume |
| Claudeが自分でスポーンして監督するチームを組む | agent teams |
| 多数のセッションを1箇所から見て操作する | agent view（バックグラウンドセッション） |
| スマホなど別デバイスから自分で操作する | Remote Control |
| CI結果やチャットなど外部イベントをセッションに流し込む | channels |
| 独立して自分で操作する複数セッション同士で連絡し合う | セッション間メッセージング（本記事） |
FAQ
Q1. セッション間メッセージングはどのバージョンから使えますか？
A. v2.1.224以降が必要です（公式ドキュメント記載、2026年8月時点）。@メンションでの宛先指定はv2.1.232以降、自分の別マシンとの新規会話開始はv2.1.225以降が必要と明記されています。バージョン要件は今後変わる可能性があるため、最新情報は公式ドキュメントで確認してください。
Q2. WindowsやAWS Bedrock環境でも使えますか？
A. 公式ドキュメントによると、対応OSはmacOSとLinux（WSL 2上のLinuxを含む）のみで、ネイティブWindowsは非対応です。プロバイダはAmazon Bedrock、Claude Platform on AWS、Google Cloud Agent Platform、Microsoft Foundryでは利用できません。
Q3. メッセージに会話履歴やファイルは含まれますか？
A. 含まれません。運ばれるのはテキスト本文のみで、送信元の会話履歴やファイルは受信側に渡りません。文脈ごと引き継ぎたい場合はresumeを使う設計です。
Q4. 受信側は届いたメッセージの指示を無条件に実行しますか？
A. いいえ。受信メッセージは送信元の承認とはみなされず、保留中の権限プロンプトへの代理回答や、設定変更の実行はできない設計です。メッセージの依頼を実行するのに権限が必要な操作は、通常どおり確認プロンプトが表示されます。
Q5. 組織として無効化することはできますか？
A. できます。管理設定でpermissions.denyにSendMessageとListAgentsを指定し、crossSessionInboundをrefuseにすることで、組織単位で送信・一覧表示・受信のすべてを止められると公式ドキュメントに記載されています。適用前に、既存のサブエージェント・agent teams運用への影響を必ず確認してください。
Q6. メッセージのサイズに上限はありますか？
A. あります。同一マシン内のセッションへのメッセージは、シリアライズ後のサイズが約100万文字を超えると送信段階で拒否され、受信側には何も届きません。
Q7. resumeやagent teamsとどう違いますか？
A. resumeは同じ会話・コンテキストを別の場所で続ける機能、agent teamsはClaudeが自分でスポーンして監督するチーム内のやり取りです。セッション間メッセージングは、ユーザーが個別に起動・操作している独立したセッション同士の「連絡」に使う機能で、公式ドキュメントも用途ごとに使い分けるよう案内しています。
まとめ
セッション間メッセージングは、worktreeを分けた並行開発や長時間タスクの監視で「ターミナルを行き来してコピペする」手間をClaude同士のやり取りに置き換える機能。会話履歴やファイルは運ばれず、受信側の既定動作はcrossSessionInbound設定と権限モードの組み合わせで決まり、受信メッセージがそのまま実行権限になることもない——という設計を理解したうえで、まずは/list-agentsで自分の環境から何が見えているかを確認するところから始めたい。組織で使う場合は、isolatePeerMachinesや管理設定での無効化オプションも含めて、権限設計を事前に決めておくことを推奨する。
参照・確認ソース
- Message your other Claude Code sessions — Claude Code Docs（公式・2026年8月確認）
- Claude Code Changelog — v2.1.224〜v2.1.235（公式・2026年8月18日時点）
- Agent teams — Claude Code Docs（公式）
- Remote Control — Claude Code Docs（公式）
- Sessions（resume）— Claude Code Docs（公式）
著者：佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。
