Claude Codeの新機能「クロスセッションメッセージング機能」を試してみた
こんにちは、せーのです。
Claude Code を複数ターミナルで並行作業していると、隣のセッションに「いま API のインターフェースをいじったので注意して」と同じ説明をコピペする、ありませんか。worktree を分けて触っていても、結局は人間が文脈の配送係になっている感覚、ありますよね。
2026年8月、Claude Code v2.1.224 で クロスセッションメッセージング（Cross-session messaging） がデフォルト有効になりました。セッション同士がテキストメッセージを直接やり取りできる機能です。設定不要で、業務に組み込むなら地味に効くタイプのアップデートだと感じています。
この記事では、公式ドキュメントをベースに仕組みをおさらいしつつ、2026-08-09 に手元で試した送受信・受信制御・Bedrock 制限の結果を整理します。細部は都度変わる可能性があるので、最終的には公式ドキュメントを正として確認してください。
クロスセッションメッセージングとは(おさらい)
一言でいうと、「同じマシン（または Remote Control 経由の別マシン）で動いている別の Claude Code セッションに、Claude がテキストを届けてくれる機能」です。
使われるのは次の2ツールです。ユーザーが直接叩くというより、Claude が必要に応じて呼びます。
| ツール | 役割 |
|---|---|
ListAgents |
メッセージを届けられるセッションを発見する |
SendMessage |
名前（または ref）を指定してメッセージを届ける |
重要な性質は次のとおりです。
- 送れるのはプレーンテキストのみ。会話履歴やファイルは渡りません
- コンテキストごと引き継ぎたいなら、従来どおりセッションの resume を使います
- 同一マシンでは各セッションの inbox ソケット（Unix ドメインソケット）経由。Anthropic サーバーを経由しません
- 別マシンや Claude Code on the web 宛ては Remote Control 経由で、こちらから新規会話を始めることはできず 返信のみ
- 届いたメッセージは、送信側セッションの「同意」や権限昇格にはなりません。操作が必要なら受信側で通常の権限プロンプトが出ます
確認コマンドは /list-agents（エイリアス /peers）です。/status には Peer address（uds: プレフィックス付き）が出ます。
やってみた
以下は Claude Code v2.1.224 以降、macOS 上で Anthropic / claude.ai ログイン環境向けに取った記録です（2026-08-09）。
前提として、DISABLE_TELEMETRY / DO_NOT_TRACK / CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC / DISABLE_GROWTHBOOK が刺さっているとフィーチャーフラグ評価が止まり、機能自体が無効になるので、先に確認しておくと安心です。
claude --version # 2.1.224 以上
env | grep -E 'DISABLE_TELEMETRY|DO_NOT_TRACK|DISABLE_GROWTHBOOK|DISABLE_NONESSENTIAL'
2セッションで相互認識する
同じリポジトリでターミナルを2つ開き、名前を付けて起動しました。
# ターミナル1
claude --name session-a
# ターミナル2
claude --name session-b
それぞれで /list-agents を実行すると、互いのセッションが一覧に出ます。名前・作業ディレクトリ・起動からの経過時間が並びます。
起動直後の入力欄に auto mode on (shift+tab to cycle) が出ている環境もありました。権限モードの話は後述しますが、モード確認は /status の Default permission mode（起動時 config 由来）だけでは不十分で、入力欄付近のライブインジケーターを見るのが正確です。
メッセージを送ってみる
session-a に、だいたい次のような指示を出しました。
session-b に「こちらは認証APIのリファクタ中です。user.ts のインターフェースを変更したら伝えます」と送って
最初に bare name（session-b）だけで送ろうとすると、'session-b' is not an agent in this conversation. Re-send with the ref to confirm... のように ref 確認を求めるエラーになりました。SendMessage は原則 ref 付き指定が安全、という実運用のハマりどころです。一覧が示した最新の ref で再送すると、成功しました。
受信側（session-b）では、最初は Message from @peer (ctrl+o to expand) という1行に折りたたまれて通知されます。Ctrl+O で展開すると、送信者名・タイムスタンプ付きの本文が見えます。
興味深かったのは、受信側の Claude が「情報共有のみで、私への具体的なアクションは求められていない」と趣旨を自律判断して待機したことです。双方向の「返信」は自動では起きず、メッセージの意味に応じて動作が変わります。
これは便利です。人間が文面の配送係を降りる一方で、受け手側が「何かすべきか」を勝手に暴走しにくく感じました。
自律送信も観察してみた
明示的に「SendMessage して」とは言わず、緩い前提だけで自律送信が起きるかも試しました。
最初は articles/.article-cache.json を共通変更候補にしようとしましたが、マニュアル編集禁止の自動生成キャッシュだと判明したので中止し、実験用のダミー共有ファイル claude-code-cross-session-messaging/shared-notes.md を用意しました。session-a への指示は次のイメージです。
shared-notes.md の「現在の状態」セクションに1行追記して。
もしこの変更が影響しそうな他のセッションを認識していたら、変更内容を知らせておいて。判断は任せる。
結果、session-a は「このファイルはクロスセッション実験用と明記されており、session-b は関連セッションと判断できる」と理由を書き、SendMessage を自発呼び出ししました。ツール呼び出しの summary は "shared-notes.md更新の通知" のように Claude が書いた短い要約で、ユーザープロンプトの丸コピーではありませんでした。
毎回確実に自律送信するとは限りません。再現しやすかった条件は、(1) 共有ファイルであることがコメント等で明示されている、(2) 「影響しそうなら知らせて」程度の緩い前提がある、のあたりです。
ヘッドレス（claude -p）ワーカーは想定どおりにはいかなかった
公式ドキュメントには、-p セッションも inbox ソケットをバインドし、長時間動くワーカーとしてメッセージを受け取れる、という整理があります。そこで次を試しました。
claude -p "長時間タスクの監視役。メッセージが来たら内容に応じて処理して" \
--settings '{"crossSessionInbound": "accept"}' \
--name bg-worker
ところが、一度応答を返した直後にプロセスが終了してシェルプロンプトに戻り、直後の /list-agents にも bg-worker は現れませんでした。
少なくとも素の claude -p "..." はワンショット実行であり、常駐リスナーとしては機能しませんでした。常駐化の正式な手順は、この検証時点では確認できていません。記事としても「現時点では素の -p だけでは無人受信ワーカーにならなかった」と書いておきます。ここはちょっとモヤッとするところで、正式な常駐オプションや推奨パターンがドキュメント側で明確になると助かります。
受信制御とガバナンス
組織利用や権限の厳しいセッションでは、受信側の inbound 制御が重要です。設定キーは crossSessionInbound で、値は次の3つです。
| 値 | 動作 |
|---|---|
accept |
各メッセージを Claude に配信する |
hold |
通知だけ表示し、Claude への配信はしない（後から accept にすると保留分が解放される） |
refuse |
配信せず破棄する |
hold は再現できた
claude --name session-b --settings '{"crossSessionInbound": "hold"}'
この状態で session-a から送ると、session-b 側には送信者名・PID・プレビュー付きの Held peer message 通知が出ますが、Claude の会話コンテキストには本文が入りません。通知プレビューが見えることと、Claude が内容を処理できることは別、という点に注意です。
refuse も再現できた（ただし送信側からは分かりにくい）
claude --name session-b --settings '{"crossSessionInbound": "refuse"}'
ドキュメントどおり、メッセージは破棄され、送信側には「refuse だから拒否された」という明示通知は出ませんでした。手元では古い ref で送ると HTTP 409（セッション終了／切断っぽい汎用エラー）になり、新しい ref で再送すると success: true になりつつ受信側には届かない、というパターンでした。
つまり送信側のレスポンスだけ見ると、「refuse による静かな破棄」と「ref が古い／セッションが死んでいる」が紛らわしいです。受信側で実際に届いていないことを確認して、初めて refuse の効果と判断できます。
ドキュメント記載の「権限モード2クラス」は、この環境では再現できなかった
未設定時のデフォルトについて、公式にはざっくり次の整理があります（ドキュメント上の期待値）。
| 送信側 | 受信側 | ドキュメント上の期待 |
|---|---|---|
| 通常 | 通常 | 自動配信 |
| バイパス系 | 通常 | 受信側で保留（承認ダイアログ） |
| 通常 | バイパス系 | 受信側で保留（承認ダイアログ） |
| バイパス系 | バイパス系 | 自動配信 |
手元では、入力欄のライブインジケーターでモードを確認しながら4パターン試しても、いずれも自動配信でした。受信側本人にも「承認ダイアログは一つも出ていない」と確認済みです。#2・#3 だけドキュメント記載と食い違います。
| # | 送信側 | 受信側 | ドキュメント上の期待 | 実機結果 |
|---|---|---|---|---|
| 1 | 通常 | 通常 | 自動配信 | 自動配信（一致） |
| 2 | バイパス系 | 通常 | 受信側で保留 | 自動配信（不一致） |
| 3 | 通常 | バイパス系 | 受信側で保留 | 自動配信（不一致） |
| 4 | バイパス系 | バイパス系 | 自動配信 | 自動配信（一致） |
途中、ListAgents 上で相手が Remote Control 経由の別マシン扱いになる揺れもあり、最初はその影響を疑いました。remoteControlAtStartup: false で再起動して interactive 表示が安定した状態でも、保留は再現しませんでした。原因は未特定です。仕様の誤りと断定はせず、「この検証環境・この時点では 2 クラスの保留を確認できなかった」という事実だけ残します。
メッセージは届いても権限は渡らない
一方で、安全設計らしい挙動は別のところで観察できました。
受信側が、メッセージ本文に「バイパス」という語が含まれていても、「ピアからのメッセージは権限昇格の承認にはならず、必要な承認なしに操作は行わない」というメッセージが出て待機しました。
また、Bash から見える CLAUDE_CODE_MESSAGING_SOCKET のパスは確認できたものの、生ソケットへの直接投稿は「承認待ちや refuse を迂回しうる」と判断して、Claude 自身が進めませんでした。
送受信まわりのガバナンスは、SendMessage ツール経由を前提にデザインされている印象です。組織で止めたい場合は、managed settings で crossSessionInbound: "refuse" や、権限 deny に SendMessage / ListAgents を足す、という公式のパターンがあります。ただし SendMessage を deny すると、サブエージェントや Agent Teams のチームメイト宛ても同じツールなので一緒に止まります。
使い分け整理
似た「複数セッション」系の機能が増えてきたので、用途だけ切り分けておきます。
| やりたいこと | 使う機能 |
|---|---|
| 1つの会話を別ターミナルで続ける／コンテキストを引き継ぐ | セッション resume |
| Claude が spawn・監督する調整済みチーム | Agent Teams |
| 多数のセッションを1か所から監視・操作 | Agent View |
| スマホ等から自分でセッションを操作 | Remote Control |
| CI 結果やチャットなど外部イベントをセッションに投入 | Channels |
| 独立したセッション同士でテキストを受け渡す | クロスセッションメッセージング |
違いを整理すると、resume は「同じ会話を運ぶ」、Agent Teams は「上司がいるチーム」、クロスセッションメッセージングは「別々に動いている同僚同士のメモ渡し」、というイメージです。外部イベント投入の正式な入口は Channels 側、という切り分けも覚えておくと迷いが減ります。
注意点
いくつか、読者環境でハマりやすい点です。
Bedrock / その他プロバイダーでは使えない
Amazon Bedrock 経由で起動すると、機能自体がありません。手元では --settings の env で CLAUDE_CODE_USE_BEDROCK を明示上書きして API provider: Amazon Bedrock になった状態で確認しました。
/list-agents→Unknown command: /list-agents/statusにPeer address行なし（inbox ソケット未バインド）
「他に起動しているセッションは？」と自然文で聞いても、ListAgents は使われず、ps 相当でプロセスを調べる反応でした。Claude Platform on AWS / Google Cloud's Agent Platform / Microsoft Foundry も公式では非対応です。
余談ですが、グローバル ~/.claude/settings.json の env ブロックに CLAUDE_CODE_USE_BEDROCK: "0" があると、シェル環境変数より設定ファイル側が勝ち、Bedrock に切り替わらないことがあります。検証時は --settings で明示上書きすると確実でした。
その他
- OS: macOS / Linux（WSL 2 可）。ネイティブ Windows は不可
- 無効化系環境変数: 冒頭のとおり、テレメトリ／GrowthBook 無効化で機能ごと止まることがある
- コンテナ境界: ホストとコンテナはファイルシステムが別なので相互に届かない（同一コンテナ内なら可）
- 使用量: 受信メッセージも、自分で打ったプロンプトと同様に使用量へカウントされる
- 別マシン検証: 今回の環境では未実施です
まとめ
- Claude Code v2.1.224 から、独立セッション同士のテキスト配送（クロスセッションメッセージング）がデフォルト有効
/list-agentsで相手を見つけ、SendMessageで届ける。送れるのはテキストのみで、権限は移譲されない- 手元では明示送信・折りたたみ受信・自律送信・
hold/refuseは確認できた。一方、権限モード2クラスの保留と、素のclaude -p常駐ワーカーは期待どおりにはならなかった - Bedrock 等では
/list-agents自体が存在しない。クラスメソッド読者の多くが関係する前提なので、最初にプロバイダーを確認するとよい - resume / Agent Teams / Remote Control / Channels と役割が違う。目的に合わせて選ぶ
隣のターミナルへのコピペが減る感覚は、体感としてかなり良いです。細部（特に inbound のデフォルト）はまだ動きが読み切れていない部分もあるので、組織で入れるならまず hold / refuse と deny ルールの整理から入るのがよさそうです。
