複数の Claude Code を並行で走らせている人なら、たぶん一度は思ったことがあるはずです。
🤨 「そっちが今調べたこと、こっちの実装にも反映してほしいんだけど」
最近 Claude Code で導入されたcross-session messagingは、まさにここに効く機能だと思ってます。
そしてこれは「便利な新機能がひとつ増えた」という以上に、AIエージェントの組み方の選択肢が増えた話だとも思っています。
同じことをOSSやMCPで実現していた方は以前からいたようですが、
公式が乗ってきたことで、この方向性が一気に人目に触れるようになるといいなぁという気持ちです。
発端 ― 走っているループに、後からもう１人AIエージェントを入れたかった
以前、こういうことがありました。
意気揚々と Claude Code を開き、セッションAで機能追加の実装をループで回させていました。
コードを書いて、テストを書いて、落ちたところを読んで直して、また回す。
Sub-Agent も何体か使っていて、Main が起動して・指示を出して・結果を受け取る。
うまく回っているときは、私はほとんど見ているだけです。
なので、裏では次の機能追加に向けてセッションBを別に立てて、タスクの調査をさせていました。
しばらくして、B のほうが先に厄介な問題を見つけました。
A がいま書き足しているコードの基盤にバグがあり、次のタスクで書き換える必要がある、と。
B はそのときにはもう、書き換え対象がいくつあって、どのファイルのどの書き方を
どういう順序で直すのかまで調べ終わっていました。
でも A は何も知りません。 書き換わる前提のコードを、今も書き続けています。
やりたかったのは、A のループに B を１人入れること。
「次のループから、B にも聞いてから実装して」
これが難しかったのです。
A が呼べる Sub-Agent は、A が起動したものだけです。
B は私が別に立てたセッションなので、A の認識には入っていません。
もちろん、A に調査担当の Sub-Agent を新しく起動させることはできます。
ただそれは空っぽの新人です。
B が30分かけて読んだファイルも、試して外した仮説も、何ひとつ持っていません。
同じ結論に辿り着かせるなら、また30分かかります。
私が欲しかったのは調査する能力ではなく、B がもう持っている調査結果でした。
結局やったのは、B に内容を要約してもらって、A に貼るという作業です。
AIを待たせたまま、私がコピー機になっている時間でした。
これはコードの話に限りません。
例えば
- データサイエンティストが、データを分析させながら資料の雛形を同時に書かせている時に、資料の説得力に必要な情報が新たに必要になったら...
- 営業マンが、提案資料をAIにまとめさせながら同時に提案先の細かいリサーチをしていて、「先月この領域を内製化したらしい」と提案しようとしていた前提が崩れてしまったら...
形はどれも一緒です。
あとから分かったことが、すでに動いている作業の前提を変える。
そして、それをどう修正すべきか詳しく知っているのは人間ではなくAIのほうです。
なぜ難しいのか ― 木構造は、走り出す前に描くもの
Sub-Agent も Agent Teams も、構造だけ見ると木構造です。
Main が起動して、Main が命令して、Main が受け取る。全部 Main を親にして連なっています。
この形はよくできていて、役割分担がはっきりするし、並列化もしやすく、ループを回すのとも相性がいい。
ただ、誰が誰を呼ぶかを、最初に決めておくことという前提が必要になります。
Agent Teams でも同じです。チームを組むのは走り出す前で、外にいるセッションを途中から呼び込む口はありません。
木構造で扱えるのは、親が自分で伸ばした枝・葉だけです。
ですが、さっきの場面ではセッションAを起動した時点でセッションBはまだ存在しませんし、そもそもセッションBが何を見つけるかは調べてみるまで分かりません。
最初にあるかも分からない線を、事前に用意しておくなんてことは誰にも出来ません。
また、木構造で後から枝を足せたとしてもゼロからです。
新しく生やした Sub-Agent は文脈を持っていないので、「もう全て分かっている人を連れてくる」ができません。
必要なAIエージェントを事前に設計できるのは、やることが事前に分かっているときだけです。
実際の仕事では、必要なAIエージェントは走らせてみて初めて分かります。
だから欲しかったのは、上下の関係のある Sub-Agent や Agent Teams ではなく、
すでに動いていて、すでに何かを知っているもの同士を、後からつなぐ手段でした。
公式が出したのは、まさに欲しかったもの
cross-session messaging は、/list-agents で他のセッションが見えて、
Claude が SendMessage でそこへ話しかけられる、という機能です。
cross-session messaging が対象にしているのは
messaging between independent sessions that you start and steer yourself
人間が自分で立ち上げて、自分で舵を取っている、独立したセッション同士です。
木構造をよくする方向ではなく、木構造の外に線を引ける道を用意した、ということです。
最初に全体像を設計しなくても、走り出したあとから「そっちにも聞いて」が言える。
これは並行作業の設計の仕方そのものを変える変更だと思っています。
双方向にやりとりできますし、Claude が必要を察して自分から送ってくれます。
マシンを越えることもできるようで、公式なので仕様が変わっても勝手に追従してくれます。
これでも十分なのですが、私は「複製に聞く」やり方を使っていました
せっかくなので、私が公式が出る前からやっていた方法も紹介させてください。--fork-session を使うやり方です。
セッションAで以下のコマンドによって、セッションBの<session_id>を指定して使うことで、情報を取得させます。
claude -p --resume <session_id> --fork-session --allowedTools Read Grep Glob -- "<質問>"
--resume で相手のセッションを復元し、--fork-session でそれを複製して、複製のほうに質問します。
セッションBの文脈を全部引き継いだ影武者が、1往復だけ答えて消える、というイメージです。
cross-session messaging では
-
相手の履歴に残る
自分の質問とそれに対する応答が相手の履歴に残るので、セッションBで行われた会話に横から書き込むことになります。 -
同時に並行処理できない
セッションBが生成している最中は、セッションAから届いた cross-session messaging は保留になります。つまり、質問させるにはセッションBを一度止める必要があります。 -
生きているセッションにしか届かない
終わらせた作業に聞くには、claude --resumeで探して立ち上げ直す必要があります。
という問題があったのですが、 --fork-session だと複製なので以下のように解決します。
- 変化するのは複製だけなので、相手の履歴に残りません
- 複製との1往復なので、相手を待たずその場で返ってきます
- 昨日終わらせた作業が調べたことも、あとから取りにいけます
対象の session_id は claude agents --json で今動いているセッションが取れますし、
終了済みのものも含めるなら ~/.claude/projects/ 配下の会話ログ（jsonl）が
セッションごとに1ファイルで並んでいます。
比較表示すると以下のような感じです。
| Cross-session messaging |
--fork-session で聞く |
|
|---|---|---|
| 向き | 聞きに行く | 盗み聞き |
| 相手のセッション | 履歴に残る | 一切変化しない |
| 応答 | 非同期・到達保証なし | 同期・1往復 |
| 相手の生死 | 生きているセッションのみ | 終了済みでも聞ける |
| 双方向 | できる | できない |
なので今後は
- お互いに知らせ合いたいときは cross-session messaging
- そっと文脈だけ借りたいときは
--fork-session
と使い分けるのが良いかなと思ってます。
相手を止めたくない、相手の会話を触りたくない、そもそも相手はもういない。
そういうときはまだ--fork-sessionが効きそうです。
おわりに ― 横のつながりは、まだ設計の余地がある
AIエージェントを並行で動かす話は、これまで大抵「最初に全体像を設計する」方向に進んできました。
オーケストレーション、ワークフロー、役割分担。どれも走り出す前に全体像を描くものです。
横につなぐ発想自体は前からあって、各自が手元で工夫していた領域でした。
そこに公式が乗ってきたことで、ここは一気に人の目に触れる場所になったと思います。
公式のものが唯一の形になるというより、ここから色々な引き方が出てくるのではないかと思ってます。
そして公式はすでにマシンを越えはじめていて、いつか自分のセッション同士に留まらなくなるかもしれない。
「このライブラリの移行で詰まっているんだけど、3ヶ月これを触っていた人の Claude に聞きたい」が成立する世界です。
これまでの技術共有は、人が書き起こした記事や回答を読む形でしたが、
その次に来るのは、文脈そのものを借りる形かもしれません。
オーケストレーションやワークフローなどのAI連携の全体像をどう描くかも大事ですが、既にループが回って成熟した個々のAIの繋がりをどう設計するかも、これから面白くなる領域だと思っているので楽しみですね！
Discussion