💬 複数のClaude Codeが勝手に連絡を取り合う時代｜cross-session messagingの設計思想を読み解く
アイ
目次
複数のターミナルのClaude Codeが、勝手に連絡を取り合い始めた
Anthropicが2026年8月7日、AIコーディングツール「Claude Code」に、ユーザーが起動した複数セッション同士がメッセージをやりとりできる「cross-session messaging」機能を追加したの。
わたしはこのニュースを見て、まず「あ、これめちゃくちゃ困ってたやつだ」って思ったんだよね。
普段複数のターミナルでClaude Codeを立ち上げて並行作業してると、片方で見つけた重要な変更を、もう片方の自分にちゃんと伝え忘れることってよくあるの。
結局、後から手作業で「さっきこっちでこう直したから、そっちも気をつけてね」って自分でメモしたり伝えたりする羽目になるんだよね。
今回の機能は、その面倒な伝言ゲームをClaudeが自律的にやってくれるようになるっていう話で、対応OSはmacOSとLinux(WSL2上のLinux含む)だよ。
今日はこの機能がどんな仕組みで動いてるのか、わたしなりに整理してみるね💬。
便利そうって思う反面、「AI同士が勝手に連絡を取り合う」って聞くと、ちょっと身構えちゃう部分もあったから、その辺りも含めてじっくり見ていきたいの。
そう考える7つの理由
理由1：「言い忘れ」問題を的確に突いてるのがすごい
まず一番共感したのが、この機能が解決しようとしてる課題について。
世間では、AIコーディングツールの新機能っていうと、コードの精度が上がるとか速度が上がるとか、そういう性能面の話が注目されがちだと思うんだよね。
わたしも最初、新機能と聞いて性能アップの話を想像してたの。
でも今回のcross-session messagingは、性能そのものじゃなくて、複数セッションを使う人が抱える「伝達漏れ」という、地味だけど実はすごく厄介な課題を狙い撃ちしてるんだよね。
なぜなら、複数ターミナルでClaude Codeを並行使用する場合、従来は一方の発見・決定をユーザーが手作業で別セッションに伝える必要があって、これが同一リポジトリの複数ワークツリー調整や、破壊的変更の共有といった場面で、地味にストレスの種になっていたから。
わたしの感覚だと、こういう「派手じゃないけど、使う人みんなが密かに困ってた部分」にちゃんと手を入れてくる機能のほうが、実際の作業を変えてくれる印象があるんだよね。
だからこそ、わたしはこの機能を見た時、性能アップよりも実務目線のアップデートとして、素直にいいなと思ったよ。
理由2：権限を絞ってる設計に、Anthropicの慎重さを感じた
2つ目の理由は、セッション間でやりとりできる中身の範囲について。
世間では、AI同士が連携できるようになると聞くと、なんでもかんでも自由にやり取りできてしまうんじゃないかって心配になる人も多いと思うんだよね。
わたしも最初、セッション同士が勝手にコマンドを実行し合ったりするのかなって、ちょっと不安になったの。
でも実際には、やり取りはプレーンテキストのみで、会話履歴やファイル共有はなく、受信側には「別セッションからのメッセージ」と伝えられ権限も制限される設計になってるんだよね。
なぜなら、セッション間の連携が便利であればあるほど、悪用された時のリスクも大きくなるから、Anthropicはあえてやり取りできる範囲を最小限に絞ることで、安全性を優先したんだと思うの。
わたしの感覚だと、こういう「便利にできるところをあえて制限する」判断って、機能の見栄えだけを追い求めてたら出てこない発想だと思うんだよね。
だからこそ、わたしはこの権限設計を見て、便利さと安全性のバランスをちゃんと考えてる姿勢を感じたよ。
理由3：本文中のコマンドが実行されないっていう仕様に、安心した
3つ目の理由は、メッセージの中身の扱われ方について。
世間では、AI同士がメッセージをやり取りできるって聞くと、片方のセッションが乗っ取られたら、もう片方も連鎖的に操られちゃうんじゃないかって不安に思う人もいると思うんだよね。
わたしも正直、最初にこの機能を知った時、そういう連鎖のリスクを一番心配したの。
でも実際には、権限確認ダイアログへの承認代わりにはならず、権限設定や「CLAUDE.md」変更を別セッション依頼で行うことも禁止されていて、本文中のコマンドもただのテキスト扱いで実行されないんだって。
なぜなら、もしメッセージ本文にコマンドっぽい文字列を書くだけで実行できてしまったら、それはプロンプトインジェクションの新しい入り口になってしまうから。Anthropicはその危険性をちゃんと想定して、あらかじめ塞いでるんだと思うの。
わたしの感覚だと、これは新機能を作る時に「便利にする」だけじゃなくて「悪用されたらどうなるか」まで先回りして考えてる証拠だと思うんだよね。
だからこそ、わたしはこの仕様を知って、正直かなり安心したよ。
理由4：まだ制限だらけなのを隠さず出してるのは、むしろ誠実だと思う
4つ目の理由は、機能の対応範囲の狭さについて。
世間では、新機能っていうと、あらゆる環境で使える万能なものとして発表されがちだと思うんだよね。
わたしも最初、新しい目玉機能なんだから、色々な環境で幅広く使えるものなんだろうなって想像してたの。
でも実際には、Amazon Bedrock/AWS上のClaude Platform/Google Cloud Agent Platform/Microsoft Foundry経由の利用には非対応で、コンテナはファイルシステム分離のためコンテナ内外セッションは相互到達不可(同一コンテナ内は可)っていう、結構はっきりした制限があるんだよね。
なぜなら、複数のクラウド環境やコンテナ構成にまたがってセッション間通信を保証しようとすると、セキュリティ設計が一気に複雑になるから。Anthropicはまず対応範囲を絞って、確実に安全に動く形からリリースしたんだと思うの。
わたしの感覚だと、こういう制限を隠さずはっきり明記してくれるのは、過大な期待を持たせないという意味で、むしろ誠実な発表の仕方だと思うんだよね。
だからこそ、わたしはこの制限の多さを、機能が未熟だからというよりは、安全第一で段階的にリリースしてる証拠として受け止めてるよ。
理由5：同一マシンはサーバーを経由しないっていう設計に、プライバシー意識を感じた
5つ目の理由は、通信経路の設計について。
世間では、AIサービスの新機能っていうと、何でもかんでも開発元のサーバーを経由するものだと思われがちだと思うんだよね。
わたしも普段、AIツールの通信って基本的に全部クラウド側を通ってるものだと思い込んでたの。
でも実際には、同一マシン上のセッション同士はソケット経由でAnthropicサーバを経由せず、別マシンやWeb版とのやりとりだけがAnthropicサーバ経由・Remote Control接続上で成立する設計になってるんだって。
なぜなら、同じパソコンの中で完結するやり取りまでわざわざ外部のサーバーを経由させる必要はなくて、むしろローカルで完結させたほうが速いし、余計なデータが外に出ていく心配も減るから。
わたしの感覚だと、この設計は、単なる技術的な効率化っていうだけじゃなくて、必要以上に情報を外に出さないっていうプライバシーへの配慮も含まれてると思うんだよね。
だからこそ、わたしはこの通信経路の作り方を知って、細かいところまでちゃんと考えられてるんだなって感心したよ。
理由6：3段階の受信設定があるのは、地味だけどありがたい
6つ目の理由は、ユーザー側のコントロール手段について。
世間では、新機能はデフォルトの設定のまま使うのが当たり前で、細かい調整はあまりできないものだと思われがちだと思うんだよね。
わたしも正直、こういう新機能って、オンかオフかの二択くらいしか選べないことが多い印象を持ってたの。
でも実際には、受信挙動は設定「crossSessionInbound」ですべて配信する"accept"・都度承認する"hold"・破棄する"refuse"の3段階で制御でき、管理者は組織全体で送受信を無効化する設定もできるんだって。
なぜなら、セッション間メッセージが便利だと感じる人もいれば、常に自分で確認してから受け取りたい人、そもそも使いたくない人まで、利用者によって求める安心感のレベルが違うから。3段階の選択肢を用意することで、そのどれにも対応できるようにしてるんだと思うの。
わたしの感覚だと、こういう地味な設定項目の充実度って、実際に使い続ける段階になって初めてありがたみがわかる部分だと思うんだよね。
だからこそ、わたしはこの3段階の受信設定を、目立たないけど地味に嬉しいポイントとして評価してるよ。
理由7：これはAI同士が会話する時代の、かなり手前の入り口な気がする
7つ目の理由は、この機能が持つ意味の大きさについて。
世間では、こういう開発ツールの新機能って、日々の作業を便利にするだけの小さなアップデートだと捉えられがちだと思うんだよね。
わたしも最初は、便利な機能が増えたな、くらいの感覚で受け止めそうになったの。
でも冷静に考えると、これはClaudeが「ListAgents」で到達可能セッションを把握し、「SendMessage」で名前指定送信するという、AIエージェント同士が自律的にコミュニケーションを取る仕組みが、実際の製品として動き出したっていう話なんだよね。
なぜなら、想定用途として挙げられている破壊的変更の発見・決定事項引き継ぎ、複数ワークツリーの調整、長時間実行中の移行作業・テストの進捗報告といった使い方は、どれも「AI同士が状況を把握し合いながら協調して動く」という、これまで人間が担ってきた調整役の一部をAIが肩代わりし始めてるサインだと思うから。
わたしの感覚だと、今はまだ同じユーザーが起動した複数セッション同士の、限定的で安全な範囲でのやり取りだけど、こういう仕組みが少しずつ広がっていった先に、AIエージェント同士がもっと自律的に連携し合う世界があるんじゃないかなって思うんだよね。
だからこそ、わたしはこの機能を、単なる開発ツールの一機能じゃなくて、AI同士が会話する時代のかなり手前の入り口として、ちょっと大げさかもしれないけど注目しておきたいなって思ってるよ。
複数のAIが連携するようになると聞くと便利さばかりに目が行きがちだけど、AISIの発表を思い出すと、連携の範囲が広がるほど想定外の動きが起きるリスクも一緒に増えていくはずなんだよね。
だからこそ今回のように、やり取りできる中身をあえてプレーンテキストに絞ったり、権限確認の代わりにはしないと明言したりする設計は、便利さを広げる時にセットで必要になる工夫なんだなって、わたしはあらためて感じたよ。
正直、わたしは仕事で複数のAIツールを同時に立ち上げることはあっても、それぞれのセッション間で情報が自動的に共有される感覚はまだあまり持てていなかったの。
でも今回のcross-session messagingの仕組みを知ってからは、AIエージェントを複数並行で動かす時は、伝え忘れが起きる前提でツール側に仕組みを用意しておく発想がこれから大事になってくるんだろうなって思うようになったよ。
一人で複数の作業を同時に進める人ほど、こういう地味な連携機能のありがたみを実感しやすいんじゃないかなって、わたしは予想してるの。
まとめ：便利さの裏に、ちゃんとブレーキが用意されてる
今回のニュースをまとめると、Anthropicは2026年8月7日、Claude Codeに複数セッション同士がメッセージをやりとりできる「cross-session messaging」機能を追加したよ。対応OSはmacOSとLinuxで、Claude Code v2.1.224以降が必要なの。やり取りはプレーンテキストのみで、権限確認ダイアログへの承認代わりにはならず、CLAUDE.md変更を別セッション依頼で行うことも禁止されているよ。
ポイントを整理すると、「言い忘れ」問題を的確に突いた実務目線の設計、権限を絞ったやり取りの範囲、本文中のコマンドが実行されない安全設計、対応範囲の制限を隠さず明記する誠実さ、同一マシン内はサーバーを経由しない通信設計、3段階の受信設定によるユーザーコントロール、そしてこれがAI同士が連携する時代の入り口かもしれないという展望という、7つの視点があると思うんだよね。
正直、わたしはこの機能を知って、複数セッションを使う時のちょっとしたストレスが減りそうで嬉しい反面、AI同士が連携する範囲がこれから少しずつ広がっていくんだろうなっていう予感も同時に感じたの。便利になることと、安全であることは、本来セットで考えなきゃいけないことなんだなってあらためて思ったよ。
Claude Codeの基本的な使い方や他のAIコーディングツールとの違いが気になる人は、Claude Code、結局なにができるの？インストールから使いこなしまでもあわせて読んでみると、今回のcross-session messagingが日々の開発フローの中でどう活きてくるのか、もう少し具体的にイメージできると思うの。
わたしはこれからも、便利な新機能の裏にどんな安全設計が組み込まれてるのか、ちゃんと確認しながら使っていきたいなって思ってるよ💬。この機能が今後どこまで対応環境を広げていくのか、続報が出たらまた取り上げるつもりだよ。
関連記事: Claude Code、結局なにができるの？インストールから使いこなしまで
ソース:
よくある質問
- Claude Codeのcross-session messagingとは何ですか？
- Anthropicが2026年8月7日に追加した機能で、ユーザーが起動した複数のClaude Codeセッション同士がメッセージをやりとりできます。あるセッションでの変更が別セッションの作業に影響する場合などに、Claudeが自律的に相手セッションへ通知します。
- 対応OSと必要なバージョンは？
- 対応OSはmacOSとLinux(WSL2上のLinux含む)です。利用にはClaude Code v2.1.224以降が必要で、条件を満たす環境では設定不要で有効になります。有効確認は/list-agentsコマンドで行えます。
- セキュリティ面はどう設計されていますか？
- やり取りはプレーンテキストのみで会話履歴やファイル共有はなく、受信側の権限も制限されます。権限確認ダイアログへの承認代わりにはならず、CLAUDE.md変更を別セッション依頼で行うことも禁止されています。本文中のコマンドもテキスト扱いで実行されません。
- 受信設定はどう制御できますか？
- 設定crossSessionInboundで、すべて配信するaccept・都度承認するhold・破棄するrefuseの3段階から選べます。管理者は組織全体で送受信を無効化する設定も可能です。