Claude Codeのセッション間メッセージが可能に 使い方とできないこと

AIのコーディングエージェントで開発するとき、私たちは必ずセッションを2つ立てます。片方は設計と相談を担当するアドバイザー役。もう片方は手を動かす実装役です。考える係と作る係を分けたほうが、判断の質も実装の速度も上がる。ここは経験上、はっきりしています。

問題は、その2つの間を人が往復していたことでした。アドバイザー役がまとめた実装指示をコピーして、実装役に貼る。実装が終わったら、その結果をコピーして、アドバイザー役に戻す。設計、実装、レビュー、修正と回るたびに、これを繰り返す。判断も実装もAIがやっているのに、その間で伝書鳩をやっているのは人間でした。

正直に言うと、ずっと待っていた機能です。この2つが直接話せればいいのに、と何度思ったことか。そのたびに、思いながらコピペを続けていました。

その機能が、Claude Codeに入りました。セッション同士が直接メッセージを送り合えるようになっています。

セッション同士が直接メッセージを渡せるようになった

機能の名前はcross-session messaging。公式ドキュメントによると、Claude Code v2.1.224以降で、要件を満たしていれば有効化の操作は不要です。気づかないうちに使える状態になっている人も多いはずです。

仕組みはシンプルで、Claudeが2つの道具を使います。ListAgents で届く相手を探し、SendMessage で名前を指定して届ける。どちらも人が直接呼ぶものではなく、Claudeが必要だと判断したときに自分で使います。

想定されている場面として、公式が3つ挙げています。

• 発見の受け渡し: 片方のセッションが破壊的な変更や方針を決めたとき、影響を受ける側のセッションに要約を送る
• 並行作業の調整: 同じリポジトリを別々の作業ツリーで触っているとき、何が反映されたかを伝える
• 長い処理の報告: マイグレーションやテスト実行の結果を、こちらが見ているセッションに返させる

私たちのアドバイザー役と実装役の往復は、1つ目と3つ目にまたがります。決めた方針を実装役へ渡すのが1つ目。実装役の完了報告をアドバイザー役へ返すのが3つ目。どちらも、これまでは人が手で運んでいました。それがセッション同士で直接流れるようになります。自社システムの改修をAIと一緒にやるようになってから同時に動かすセッションの数は確実に増えたので、この往復が消える効果は思っている以上に大きいはずです。

使い方は「隣のセッションに伝えて」と頼むだけ

構えなくて大丈夫です。日本語で頼むだけです。公式が挙げている例を日本語にすると、こうなります。

別のターミナルで動いているセッションに、マイグレーションが終わったか聞いて

もうひとつ、内容をClaudeに任せる書き方も示されています。

いま我々がやったことを、決済APIを触っているセッションに説明して

文面はClaudeが自分で書きます。こちらは「誰に」「何を伝えたいか」だけ指定すればよく、言い回しを考える必要はありません。受け取る側にはこんな形で届きます。スキーマの移行が終わったこと、新しい列の名前、mainへのリベースが安全になったこと。それだけの短い文です。

相手が見つからないときは、/list-agents を実行すると届く相手の一覧が出ます。/peers でも同じです。セッションの名前は /rename コマンドか起動時の --name で付けられます。付けなければ作業ディレクトリのフォルダ名から自動で命名される仕組みで、myapp-3f のような名前になります。並行で動かすなら、役割が分かる名前を付けておくほうが確実です。

届くタイミングも、よく考えられています。受け取る側が作業中ならツールの実行と実行の間に読まれるので、走っている処理が中断されることはありません。手が空いていれば、そのメッセージで新しいターンが始まります。なお、届いたメッセージは自分で打ったプロンプトと同じように使用量に数えられます。

送れるのはテキストだけ できないことのほうが重要

ここが今回いちばん伝えたい部分です。名前から想像するより、できることの範囲は狭く設計されています。

新しいセッションは立ち上がりません。 これはメッセージ機能であって、セッションを作る機能ではない。すでに動いているセッションに話しかけるだけです。Claudeがセッションを生成して束ねる働き方をしたいなら、それは別の機能(agent teams)だと公式が名指しで書き分けています。

会話履歴もファイルも渡りません。 送れるのはプレーンテキストのみです。文脈ごと引き継ぎたい場合は、メッセージではなくセッションのresumeを使え、と書かれています。この割り切りは正しいと思います。履歴が丸ごと流れる設計だったら、権限の話が一気にややこしくなる。

こちらから別マシンやWeb上のセッションへ、新しい会話を始めることはできません。 できるのは、Remote Control経由で向こうから届いたメッセージに返信することだけです。公式も、マシンをまたぐ場合は返信のみで、やり取りを開始することはできないと明記しています。同じマシンの中なら双方向です。通信経路も違っていて、同じマシン内はセッションごとのソケット経由でAnthropicのサーバーを経由しません。マシンをまたぐ場合だけサーバー経由になります。

そのほか、押さえておくべき制約を並べます。

• コンテナとホストの間は届きません。互いを見つけるために同じファイルが見える必要があるためです。同じコンテナの中同士なら届きます
• Windowsネイティブでは使えません。対応はmacOSとLinux、WSL 2の中のLinuxまでです
• Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundry経由では使えません
• メッセージのループは自動で止まります。同じ送信元からの繰り返しには制限がかかり、短時間の同一メッセージは捨てられ、読まれ待ちのメッセージは1セッション50件で頭打ちになります。なお、承認待ちで保留されるメッセージはこれとは別枠で、最大100件です

「AIエージェント同士が勝手に連携する」という言葉から想像するものより、ずいぶん抑制的です。個人的には、この慎重さのほうを評価したい。

CLIとデスクトップアプリで、見える範囲が違う

ややこしいのがここでした。デスクトップアプリにも似た機能があるのですが、見える範囲が同じではありません。

	見えるセッション	できること
cross-session messaging	同じマシン上のClaude Codeセッション(ターミナルのものも含む)。Remote Control接続中は他マシンやWeb上のセッションも一覧に出るが返信のみ	一覧、メッセージ送信
デスクトップアプリのセッション横断機能	アプリ自身が動かしているCodeタブのセッションのみ(ローカル、SSH、WSL)	一覧、状況の確認、メッセージ送信、リネーム、アーカイブ

デスクトップアプリ独自の機能からは、ターミナルのCLIやVS Code拡張で開いたセッションは見えません。同じプロジェクトの作業ツリーであっても見えない、と公式がはっきり書いています。ターミナルで9個開いていてアプリで2個開いている状態なら、アプリ側のClaudeが報告するのは「もう1つのアプリ側セッション」だけ。

一方で、cross-session messagingが有効なセッションでは、ターミナルのセッションも含めて同じマシン上のClaude Codeセッションを一覧・送信できます。つまりアプリを使っていても、こちらの経路ならターミナル側に手が届く。同じ「他のセッションに連絡する」でも経路が2つあり、届く範囲が違う、という理解でよさそうです。

アプリ側には固有の作法もあります。アーカイブの前には必ず確認を求める。誰も見ていないセッション(定期実行など)からの送信も、そこへの配信もできない。届いたメッセージは送信元を明示したカードとして表示され、どこから来たのか必ず分かるようになっています。

ちなみに、アプリ側のClaudeは新しいセッションを提案してきます。現在の作業の範囲外で直すべきものを見つけると、チップとして提示してくる。押すと専用の作業ツリー付きで新しいセッションが始まります。提案するのはAI、始めるのは人。ここも線が引かれています。

受け取る側の安全装置が丁寧に作られている

セッション同士が話せると聞いて、身構えた方もいると思います。他人の指示で自分のAIが動くわけですから。プロンプトインジェクションの記事で書いたとおり、外から来た文章を指示として扱ってしまうことが、AIを業務に組み込むときの最大の弱点です。公式ドキュメントも、そこにかなりの分量を割いていました。

まず、他セッションからのメッセージは、あなたの同意として扱われません。保留中の権限確認に代わりに答えることはできない。権限設定や CLAUDE.md を「別のセッションに言われたから」という理由で書き換えることもできない。メッセージ本文に /compact のようなコマンドが書かれていても、ただのテキストとして届き、実行されることはありません。メッセージに従って何かをするときも、受け取った側の権限確認は通常どおり出ます。

送る側にも制限があります。自分のセッションで拒否された操作や、自分の権限設定なら止まる操作を、別のセッションに代わりにやらせようとしないようClaudeは指示されています。権限の抜け道にしない、という設計です。

受け取り方は設定で変えられます。crossSessionInbound に3つの値を指定できます。

値	挙動
accept	届いたメッセージをそのままClaudeに渡す
hold	通知だけ出して渡さない。後で許可すれば届く
refuse	渡さずに捨てる

指定がない場合は、送信側と受信側の権限モードの組み合わせで自動的に決まります。権限確認を飛ばす側と、通常の権限確認を使う側が混在している場合は保留され、同じ種類同士なら基本的にそのまま届くという設計です。

言い換えると、片方だけが強い権限を持っている状態のときに、一度人に確認が回ります。権限の強い側から弱い側へ指示が流れるときも、弱い側から強い側へ指示が流れるときも、どちらも止まる。納得感のある線の引き方だと思います。保留時は承認ダイアログが出て、既定では5分で失効し、答えなければ破棄されます。

組織として止めることもできます。管理設定で SendMessage と ListAgents を拒否リストに入れ、crossSessionInbound を refuse にする。マシンの外へメッセージを出す前に必ず承認を求めたいなら isolatePeerMachines を有効にします。

正直に言うと、この機能で最初に読むべきはここだと思っています。便利さより先に、受け取る側が何を守られているかを知っておくほうが安心して使えます。

まとめ 人が伝書鳩をやる時間が減る

新機能を追いかけていると「これで何が変わるのか」が見えにくいことがありますが、今回は明確でした。人が伝書鳩をやる時間が減る、という一点です。

ターミナルを行き来して、片方で分かったことをもう片方に貼り付ける。あの作業には何の価値もありません。にもかかわらず、忘れると手戻りになる。私たちがアドバイザー役と実装役のあいだでコピペを続けていたのも、結局はそれでした。設計と実装を分けるほど、往復の回数は増えます。分けたほうが品質は上がるのに、分けるほど運び屋の仕事が増える。この矛盾がようやく解けます。

複数のセッションを並行で動かしている方は、まず /list-agents を叩いてみてください。自分がいま何個のセッションを抱えているか、それだけでも把握できます。Claude Codeをまだ触っていない方は、始め方の記事からどうぞ。

観察したいのは、この機能がどこまで自律的に使われるかです。Claudeは頼まれなくても必要だと判断すればメッセージを送ります。放っておいてどれだけ賢く連絡を取り合うのか。しばらく自社の運用で見てみるつもりです。