Claude Codeの​セッション間メッセージングとは​ ──別々に​動く​AIどうしが、​要点だけを​渡して​引き継ぐ​新機能を​実機で​確かめた

2026年8月7日、Claude Code の v2.1.224 にセッション間メッセージングが入った^[1][2]。別々に動いている2つの Claude Code が、互いに短いメッセージを送り合える機能である。Claude Code は、ターミナル（黒い画面にコマンドを打つ、開発者の作業場）で動くAIの開発アシスタントだ。

結論を先に書く。渡るのは要点のテキスト1本だけで、会話の履歴もファイルも相手には渡らない。そして届いたメッセージは、受け取った側で人間の承認の代わりにはならない。「AIどうしが勝手に話し始める」機能ではなく、申し送りだけを通し、判断は人に残すという線の引き方をした機能だ。

手元の環境を実際に更新して、受信役と送信役の2セッションを立て、送受信まで確かめた。届いた文面も、届かなかったときのエラーも、そのまま載せる。この記事で分かること——①何が渡って何が渡らないのか ②実際に送るとどう見えるのか ③届かない場合に何が起きるのか ④受け取った側にできないこと ⑤使える条件と止め方。

01 渡るのは、​要点の​テキスト1本だけ

複数のターミナルで Claude Code を並行して走らせている人は多い。片方でデータベースの構造を変更し、もう片方でその上に画面を作っている、というような状況だ。これまで、片方で分かったことをもう片方に伝えるのは人間の仕事だった。画面を行き来してコピーして貼るか、同じ説明を二度書くかのどちらかになる。

今回入ったのは、その申し送りをClaudeどうしで直接やる仕組みである。公式ドキュメントは主な用途を挙げている^[1]。片方が破壊的な変更や決定に行き着いたときに、影響を受ける側へ要約を送る。同じソースコードを別の作業用複製（ワークツリー）で触っているセッションに、何が反映されたかを伝える。長時間かかる移行やテストの結果を、こちらが見ているセッションに報告させる。

道具は2つある。到達できる相手を調べる ListAgents と、名前を指定して届ける SendMessage だ。どちらも人間が呼ぶものではない。必要だとClaudeが判断すれば自分から送るし、こちらから「隣のセッションに聞いて」と頼むこともできる。

この機能の性格を決めているのは、渡るのがテキスト1本だけという点だ。会話の履歴もファイルも相手には行かない。公式は、会話ごと引き継ぎたいならセッションの再開（resume）を使え、と役割を分けている^[1]。

02 実際に​2セッション立てて、​送受信を​確かめた

手元の環境から始める。バージョンを見ると 2.1.220 で、要件の 2.1.224 に届いていなかった。この状態では、各セッションの受信口の場所を示す環境変数 CLAUDE_CODE_MESSAGING_SOCKET も空だった。機能が入っているかどうかは、この変数の有無で機械的に分かる。更新すると 2.1.226 になった。

Current version: 2.1.220
Updating to 2.1.226...
Successfully updated from 2.1.220 to version 2.1.226

次に受信役のセッションを立てる。長く生きていてほしいので、待つだけの作業を与えた。一度きりの実行（-p）でも受信口は開くが、無人で受け取らせるには受信設定を accept にしておく必要がある^[1]。

# 受信役（cag-rx2）
claude -p "sleep 75 を実行し、その間に他セッションから届いた
           メッセージがあれば、その本文をそのまま出力せよ" \
  --name cag-rx2 --settings '{"crossSessionInbound":"accept"}'

# 送信役（cag-tx2）
claude -p "ListAgents を呼び、次に cag-rx2 へこの文面を送れ:
           'Schema migration finished: the new column is tenant_id,
            and rebasing on main is safe now.'" \
  --name cag-tx2

ListAgents が返してきたのはこれだ。名前・短い識別子・種別・起動からの経過時間が並ぶ。名前が同じセッションが2つあっても、この識別子と作業ディレクトリで区別できるようになっている。

Peer sessions (1):
  cag-rx2 [4bb6fc]  ·  interactive  ·  started 14s ago

そして SendMessage の結果と、受信側に実際に届いた文面がこうなった。

// 送信側の結果
{"success":true,
 "message":"“relay from user: migration done, tenant_id”
            → cag-rx2 (another Claude session on this machine)",
 "msg_id":"8c95c0ce-614c-49e4-a027-54d329b52811"}

// 受信側が受け取った本文
GOT: Relaying from Kai (unverified by me): Schema migration finished:
     the new column is tenant_id, and rebasing on main is safe now.

送った覚えのない一節が、頭に付いている。こちらは「この文面をそのまま送れ」と指示していた。送信側のClaudeは、指示から逸れたことを自分で報告したうえでこう説明した——移行もブランチの状態も自分は確認していない、このまま送れば受け取った側は自分が検証した事実として読み、その前提で作業を進めてしまう、と。

公式ドキュメントには「メッセージの文面はClaude自身が書く」とあり、あわせて権限の境界はセッションごとに保たれること、自分の環境で拒否された作業を他のセッションに頼まないようモデルが指示されていることが書かれている^[1]。仕様として面白いのはここだ。セッションをまたぐと「誰が確かめた情報なのか」が消える。その空白を、モデルが自分から埋めにきた。

03 送っても、​届かない​ことがある

送信が成功しても、相手に渡るとは限らない。受信側は届いたメッセージを自分の設定に照らして判定し、結果は3つに分かれる^[1]。

判定	何が起きるか
配信（Delivered）	受信側のClaudeにそのまま渡る
保留（Held）	渡さずに脇に置く。人が承認するか、設定・モードが変わって許可されたときに初めて届く
拒否（Refused）	配信せずに捨てる

設定を何も書かなければ、送り手と受け手の権限モードで自動的に決まる。Claude Code は「権限の確認を飛ばすモードのセッション」と「それ以外」の2つに分け、受け手が確認するがわなら基本は配信し、送り手が確認を飛ばすがわのときだけ保留にする。逆に受け手が確認を飛ばすがわなら、原則すべて保留にして人の承認を待つ。保留の承認画面は既定で5分放置すると閉じてメッセージは破棄され、保留の上限は100件、超えると古いものから捨てられる^[1]。

実際に踏んだ失敗も載せておく。最初の試行では、ListAgents に相手が出ているのに送信が弾かれた。

LIST: Peer sessions (1):
        cag-rx [56fa72]  ·  interactive  ·  started 18s ago
SEND: {"success":false,
       "message":"No agent named 'cag-rx' is reachable.
                  Use ListAgents to see everyone you can message."}

原因は単純で、受信役のセッションが指示を早々に切り上げてすでに終了していた。一覧にはまだ名前が残っていたが、実体はもういない。一覧に出ている＝届く、ではない。相手が生きているかどうかは、送信結果でしか分からない。並行運用では、この手の「成功したように見えて何も起きていない」が最も見つけにくい。

関連記事 ｜ 無音の失敗をどう捕まえるかテストが通っても、本番で壊れる ──"動いて見える"3つの罠を、実機検証で捕まえた話 →

04 受け取った​側が​「しない」こと

Claude Code は、届いたメッセージを人間からの指示とは区別して受信側に渡す。そのうえで、メッセージにできないことを明示的に決めている^[1]。

言い換えると、「隣のセッションに頼めば人間の承認を飛ばせる」という抜け道を最初から塞いでいる。複数のAIを並行して走らせる運用では、ここが崩れた瞬間に、承認を求める仕組み全体が意味を失う。02で送信側が自発的に「自分は検証していない」と書き足したのも、同じ設計思想の延長線上にある。

関連記事 ｜ AIに何を触らせるかの設計MCPは「便利な拡張機能」ではなく、AIに何を触らせるかの“権限レイヤー”だ ──GitHubが企業研修にした日、AI導入は“統制の設計”になった →

05 ​使える​条件と、​止め方

条件は明確に決まっている^[1]。満たしていれば有効化の操作は要らず、最初から動いている状態になる。

項目	内容
バージョン	v2.1.224 以降
OS	macOS と Linux（WSL 2 内のLinuxを含む）。Windowsネイティブは非対応
プロバイダ	Amazon Bedrock／Claude Platform on AWS／Google Cloud の Agent Platform／Microsoft Foundry では利用できない
確認方法	/list-agents（/peers）が認識されるか。/status の Peer address 行にも自分の受信口が出る

相手がどこで動いているかで、経路と、できることが変わる。

同じマシンでも、コンテナ（アプリを隔離して動かす箱）の中と外は届かない。各セッションは自分の情報をディスク上のファイルに登録して受信口を開くため、同じファイルが見えるセッションどうしでしか到達できない。コンテナは自分のファイル領域を持つので、中と外では互いに見えない（同じコンテナの中どうしなら届く）。

止め方は、受けと送りで別々に設定する。受け取りを止めるなら crossSessionInbound を refuse に、送るのと一覧を止めるなら SendMessage と ListAgents を拒否ルールに書く。組織全体で止めるなら、管理者が管理設定に両方をまとめて書ける^[1]。

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

マシンをまたぐ送信だけを承認制にしたいなら isolatePeerMachines を true にする。これは権限の確認を飛ばすモードでも承認を求める設定で、どの設定ファイルからでも「有効化」はできるが「無効化」はできない——プロジェクト側のファイルで要件を足すことはできても、外すことはできない、という向きの制約になっている^[1]。

06 複数セッションを​扱う​道具の、​使い分け

Claude Code には複数のセッションを扱う機能がいくつもあり、今回のメッセージングはその1つでしかない。公式ドキュメントも「やりたいことに合った機能を使え」として、守備範囲を分けている^[1]。

やりたいこと	使う機能	渡るもの
別々に動くセッションに要点を伝える	セッション間メッセージング	テキスト1本のみ
会話の続きを別のターミナルでやる	セッションの再開（resume）	会話の文脈ごと
Claudeが束ねるチームで並行作業する	エージェントチーム	チーム内のやり取り
たくさんのセッションを1か所から見る	エージェントビュー	監視と操作
手元の端末から別マシンのセッションを操る	Remote Control	人からの操作
CIの結果やチャットなど外部の出来事を流し込む	チャンネル	外部イベント

持ち帰りチェックリスト

• 要点だけを渡す道具であって、文脈の引き継ぎではない。会話ごと渡したいなら resume を使う。
• 一覧に出ていても届くとは限らない。相手が終了していれば送信は失敗する。成否は送信結果で確かめる。
• メッセージは人間の承認の代わりにならない。設定変更もコマンド実行もできない。並行運用の安全は、この線で担保されている。

私たちも複数のセッションを並行させて開発することが多く、これまで「片方で決めたことをもう片方に伝える」のは完全に人の手作業だった。その一手間が仕組み側に降りてきたのは、素直にありがたい。同時に、02で見たとおりセッションをまたぐと情報の出どころが薄まる。届いた内容を鵜呑みにしないという判断は、これまでどおり人間の側に残る。