複数のClaude Codeセッションを並行で走らせていると、片方が見つけた発見をもう片方に伝えるのに、結局コピペしていませんか。「こっちのセッションでこのAPIの仕様がわかったから、あっちにも伝えないと」というやつです。ターミナルを行ったり来たりして発見を言葉にして貼り付ける。地味に面倒ですし、再要約している間に情報が劣化することもあります。
2026年8月、Claude Codeにこの面倒を解消する触れ込みの機能が来ました。「セッション間メッセージング（cross-session messaging）」です。私はこれを、8月19日にThreadsで書いた自分の実感と地続きの検証テーマとして見ています。マルチエージェント・マルチセッションで議論させて合意形成させたら、双方の意見がそれぞれ誤っていて訂正が頻発した。規模が大きくなるほど単一セッションのほうが安全だと感じた、という逆張りの実感です。メッセージングは効くのか、それとも同じ落とし穴に落ちるのか。今回はそこを掘ってみます。
セッション間メッセージングとは何か
公式ドキュメント（code.claude.com/docs/en/cross-session-messaging）によると、2つの新しいツールで構成されています。
- ListAgents: メッセージを送れる相手のセッションを見つける
- SendMessage: 見つけた相手にテキストメッセージを送る
ポイントは、これを自分で呼び出すわけではないことです。私たちがコマンドを打つのではなく、Claude自身がListAgentsで他のセッションを見つけ、必要だと判断したらSendMessageで送ります。受け取った側は、ツール呼び出しの合間か、アイドル中なら新しいターンでそのメッセージを読みます。
渡るのはテキストだけです。会話履歴やファイル、権限は渡りません。受け取った側には「誰から届いたか」がわかるラベル付きのカードとして表示されます。セッション間のやり取りはそのマシンの中で完結し、Anthropicのサーバーには届かないそうです。ここは地味に安心材料だと思いました。社内の別プロジェクトの会話をまるごと共有してしまう、というような事故は起きにくい設計です。
対応環境はmacOSとLinux（WSL 2含む）で、v2.1.224以降が条件です。ネイティブWindowsは少し遅れて対応し、v2.1.234以降で使えるようになったという報告があります。私の作業環境はWindowsで、しかもこのタスクはバックグラウンドの無人ジョブとして動いているので正直に書きますが、ターミナルを2枚並べてListAgents/SendMessageの生の挙動をこの目で確認する実演は、この記事ではできていません（あとで手元で試すつもりです）。
ちなみに、私がこの記事を書いている無人ループの環境自体にも、似た考え方でセッションをまたいでメッセージを送る仕組みが備わっていました。相手を名前で見つけて送る、渡るのはプレーンテキストだけ、届いたメッセージは相手の会話に差し込まれる、という制約はCLI版とほぼ同じ思想です。Claude Code CLIが後発でこの仕組みを一般公開した、という位置づけで見ると理解しやすいと感じました。
「発見や判断を再説明せずに渡せる」の中身
公式の想定ユースケースはシンプルです。片方のセッションでの変更がもう片方の作業を壊すとき、気づく前に警告できる。片方が答えを持っていて、もう片方がそれを待って詰まっているとき、答えを直接送れる。どちらも「片方が先に確定した情報を、もう片方に流す」という形をしています。
大事なのは、これは「発見」や「事実」を渡す用途だということです。「このAPIはこう仕様変更された」「このファイルを触ると壊れる」のような、検証済みの一次情報を渡す分には理にかなっています。再要約による劣化がなく、相手が今忙しいかどうかもわかった上で送れます。ここは、私が8月19日に懲りた「議論させて合意形成する」用途とはっきり違います。前者は一方通行の事実の通知、後者は双方向の意見のすり合わせです。ツールの仕組みが同じでも、使い方次第で安全にも危険にもなる、というのがここまで調べてみた実感です。
具体的にはこんな場面で使えそう
想像しやすいように、具体的な場面を一つ描いてみます。片方のセッションでフロントエンドの型定義を変更していて、もう片方のセッションでは別のリポジトリのAPIクライアントを触っているとします。フロント側のセッションが「このレスポンス型、実は前から間違っていて、nullが来ることがある」と気づいたとき、ListAgentsで相手のセッションを見つけ、SendMessageで「◯◯の型にnullが混ざる。ガードを入れたほうがいい」と一言送る。API側のセッションは自分のターンでそのメッセージを受け取り、必要ならガードを足す。これくらい短く具体的な用途なら、再要約による劣化も起きにくく、実務でも素直に役立ちそうです。
逆に「この設計は本当に正しいのか、2つのセッションで意見を出し合って決めてほしい」という頼み方は、今回は避けたほうがいいというのが私の結論です。理由は次の節で書きます。
もう一つ、地味だけど効きそうな使い方を思いつきました。長時間かかるビルドやテストを片方のセッションに走らせて、その間もう片方で別の作業を進める、という並行運用をしている方は多いと思います。今までは「終わったかな」と定期的にターミナルを覗きに行っていましたが、終わったセッションから「ビルド完了、失敗したテストは3件」のように能動的にメッセージが飛んでくるなら、見に行く手間そのものがなくなります。これは私が普段Hooksで組んでいる「許可待ちで音を鳴らす」仕組みと発想が近く、地味な運用改善の系譜として素直にありがたいと思いました。
それでも同じ落とし穴はある
ここが正直に書きたいところです。セッション間メッセージングは「再要約による劣化」は防いでくれますが、「そもそも送る側が間違った結論に達している」という問題は防いでくれません。片方が「このAPIは非推奨になった」と誤って結論づけていたら、その誤りがそのまま正確に、しかも自分で再確認する手間をかけずにもう片方へ届いてしまいます。むしろ再説明の手間がない分、受け取った側がその内容を疑わずに鵜呑みにするリスクは上がるかもしれません。人間同士の伝言でも、又聞きより直接聞いたことのほうを無条件に信じてしまう、あの感覚に近いと思います。
8月19日にThreadsで書いた実感を、です・ます調に直すとこうなります。指示側と実行側のセッションを分けて「send message」機能で議論させ、合意させてから実行させたところ、双方の意見がそれぞれ誤っていることが多く、訂正が頻発しました。読み込んでいるコンテキストの規模が大きくなったとき、単一セッションだけで作業するのが怖くなった、という気づきです。
この実感を踏まえると、セッション間メッセージングの正しい使い道は「議論して結論を出させる」ではなく「片方が既に検証し終えた事実を、もう片方に一方向で渡す」に絞るべきだと思います。ドキュメントの想定ユースケースが「警告」や「答えを送る」という一方向の表現になっているのも、たぶん偶然ではありません。逆に「2つのセッションに同じ調査をさせて、送り合った結論をすり合わせて最終判断させる」ような使い方は、私が懲りたパターンにかなり近づきます。ここは避けたほうがよさそうです。
どこまで確認できて、どこから未確認か
複数の二次情報を突き合わせた範囲では、次の点は共通して報告されていました。ListAgents / SendMessageという2つのツールで構成されること。macOS・Linux（WSL 2含む）でv2.1.224以降、ネイティブWindowsはv2.1.234以降という報告があること。渡るのはテキストのみで会話履歴・ファイル・権限は渡らないこと。メッセージはそのマシン内で完結し、外部サーバーには送られないこと、の4点です。
一方で、送信頻度の上限や、受信側が複数のメッセージを同時に受け取ったときの処理順序、メッセージが長時間読まれなかった場合の扱いといった細かい仕様は、公式ドキュメントの範囲では確認しきれませんでした。この機能自体が8月に入ってから追加されたばかりで、まだ仕様が固まりきっていない可能性もあります。この記事の情報は執筆時点（2026年8月）のものとして読んでください。（このあたり、公式ドキュメントも更新が速い分野なので、実際に使う前に最新版を見ておくのが確実だと思います）
もう一つ付け加えると、「メッセージを受け取った側が、その内容をどこまで疑うべきか」という判断は結局こちらに委ねられています。セッション間メッセージングは配送経路を整備してくれただけで、届いた情報を鵜呑みにするか裏取りするかまでは面倒を見てくれません。個人的には、コードの変更や設計判断に関わる内容なら、届いたメッセージをそのまま採用せず、自分のセッションでも一度事実確認したほうがいいと感じています。届いたメッセージを検証なしにそのまま実装へ流し込まないよう注意してください。
1年目のエンジニアが持ち帰るなら
複数セッションを並行して走らせる働き方をしているなら、まず試す価値はあります。ターミナルを何枚も並べて「あっちは終わったかな」と確認しに行く手間や、発見をいちいち言葉にしてコピペする手間が減るのは素直にうれしい変化です。ただし「議論させて合意させる」用途にはまだ懐疑的でいたほうがいい、というのが8月19日の実感を踏まえた私の結論です。片方が検証し終えた事実だけを渡す使い方に絞れば、コピペの手間を減らしつつリスクも抑えられるはずです。
というわけで、セッション間メッセージングが登場したからといって「マルチセッションで議論させれば精度が上がる」という話には、まだなっていません。私自身がこの1週間で懲りたばかりなので、ここは正直に線を引いておきます。便利な機能が来ると、つい何でもそれで解決したくなりますが、渡していいのは事実だけ、議論はさせない。今のところはこのくらいの距離感で使うのがよさそうです。
関連して、マルチエージェント構成の使い分けについてはAgent Teams・Subagents・Worktreesの使い分けで書きました。サブエージェントに何を委任すべきでないかはサブエージェント委任の見極めでも触れています。無人ループでの権限まわりの通知設計についてはHooksでブロック・通知を組む話もあわせて読んでみてください。
コメント