AI活用術
Claude Code のセッション同士が、直接やり取りできるようになりました
株式会社Blue Leaf は、1つ1つの挑戦を通して、世界を変えることができると信じています。その挑戦を形にする場として、この会社を「発明工房」と呼んでいます。
今回は、その工房の中の仕事の回り方が一段変わった、という話です。
何ができるようになったか
2026年8月7日、Claude Code に「別のセッションにメッセージを送れる」機能が入りました。開発元の告知の原文はこうです。
New in Claude Code: your sessions can now message each other.
Instead of having to re-explain yourself in another session, you can now tell Claude to do it. It sends a summary (not your history or files), and the other session picks it up mid-task.
（出典: @ClaudeDevs、2026年8月7日の投稿）
「別のセッションで説明し直す代わりに、Claude に説明させられる」「送られるのは要約であって、履歴やファイルではない」「受け取った側は作業の途中でそれを拾う」。この3点がそのまま機能の性格を表しています。
これまでは、人がコピペで橋渡しをしていた
Claude Code には以前から、自分が起動したサブエージェントとやり取りする仕組みはありました。親が子を起動して、指示を出して、結果を受け取る。この形は以前の記事でも触れています。
ただしそれは、あくまで自分が起動した子です。独立して立ち上がっている別のセッションとは、つながりませんでした。
私はいつも4〜5画面の Claude Code を並行で動かしています。調査は調査のセッション、実装は実装のセッションで、扱っている文脈がまったく違うからです。そうすると、こういうことが起きます。
- 調査セッションが、一次資料を読んで結論を出す
- その結論は、実装セッションこそが必要としている
- でも実装セッションはその会話を知らない
- だから私が、片方の画面から本文をコピーして、もう片方の画面に貼る
この橋渡しが、そのまま人間の仕事として残っていました。しかも私が気づいて動かない限り、情報は片側に置き去りになります。
使い方は2ステップ
1. 宛先を一覧する（ListAgents）
まず、いま送れる相手を一覧します。実際の出力（社内の固有名は伏せています）はこんな形です。
Peer sessions (20):
<プロジェクト名>-84 [11dfa0] · interactive · idle · started 3d ago
<プロジェクト名>-d1 [d57b69] · interactive · busy · started 2d ago
<ラベル> [a05c4e] · Remote Control · running
各行の名前がそのまま宛先になります。idle / busy / running という状態と、いつ始まったセッションかも一緒に出ます。
宛先には3つの種類があります。
| 種類 | 一覧での見え方 | 何か |
|---|---|---|
| 同じマシンの別セッション | interactive |
隣のターミナルで開いている、別プロジェクトのセッション |
| 別のマシン／クラウドのセッション | Remote Control |
常駐機やスマホからつないでいるセッション |
| 自分が起動したサブエージェント | 付けた名前で表示 | 従来からある、親子のやり取り |
同じマシンの中だけでなく、別のマシンで動いているセッションにも届きます。私の場合は、常時稼働させている Mac mini 上のセッションが手元のノートPCから宛先に選べる状態になっています（Mac mini の常駐運用はこちらの記事に書きました）。
2. 送る（SendMessage）
宛先を決めたら、見出しと本文を渡すだけです。
SendMessage({
to: "<宛先の名前> [ref]",
summary: "IFC開口表現の確定版＋移行の要点",
message: "（本文）"
})
受け取った側の画面には、こういう形で届きます。
Another Claude session sent a message:
<cross-session-message from="bridge:session_XXXX" from-name="CADの戦略セッション" ...>
（本文）
受け取った側は、from に入っているアドレスをそのまま宛先にして返信できます。一覧を引き直す必要はありません。つまり、往復の会話になります。
実際にやってみた：調査セッションと実装セッションを直接つないだ
自社で試作しているツールの開発で、この形を試しました。2026年8月11日、セッションは2つです。
| セッション | 役割 | 送っていた内容 |
|---|---|---|
| 調査・戦略側 | 一次資料を読む | 業界標準フォーマットの仕様原文、関連法令の条文、制度が求めている範囲 |
| 実装側 | 実際に動くものを作る | 実測した性能値、仕様と現状の突き合わせ結果、実装してみて分かったこと |
この2つの間で、この日だけで10通が行き来しました。私が間に入ってコピーした本文は1つもありません。
行き来した中身の例を挙げます。
実装側から調査側へは、実際に測った数字が飛びました。「三角形は5,534、描画コールは541、表示は毎秒86コマ、初回読み込みは2.19秒で197KB」。そのうえで「規模が大きくなったときに先に頭打ちになるのは三角形の数ではなく描画コールの数だった」という、動かしてみないと出てこない所見が付いていました。
調査側から実装側へは、仕様の原文が飛びました。開口部（窓やドアの穴）を階層構造のどこにぶら下げるべきか、公式の解説文の逐語つきです。実装側はそれを受けて、自分のデータ構造と1項目ずつ突き合わせ、「4点が未対応」という返事を返しています。
いちばん価値があったのは、訂正の往復でした
やり取りの中で、片方がこう書きました。
壁倍率は令46条4項が告示に委任していて、政令のXMLに表が無いので、数値を書いていません。
これに対して、もう片方が調べて訂正を返しました。「表が見つからない」のではなく、「2025年4月1日の施行で、その表が法律から削除された」のだと。
観察は合っていて、理由が違っていた、というケースです。この違いは実務では大きくて、「見つからない」なら「探し方が悪いのかもしれない」で止まりますが、「削除された」なら「では告示を見に行くべきだ」と次の行き先が確定します。
訂正を受けた側は、自分のドキュメントの記述が間違っていたことに気づいて、その場で修正のコミットを入れました。
片方のセッションだけで作業していたら、この誤りは残ったままだったはずです。 観察が正しいので、自分では違和感を持てないからです。別の文脈を持っている相手がいて初めて出てきました。
使ってみて引っかかったこと
新しい機能なので、実際に触って分かった点も書いておきます。
名前だけでは送れないことがある。 一覧に出ている名前をそのまま指定したら、こう返ってきました（セッション名は伏せています）。
'<セッション名>' is not an agent in this conversation.
Re-send with the ref to confirm you mean:
<セッション名> [a05c4e] — Claude session, on another machine (Remote Control), active 1m ago
同姓同名を防ぐために、[a05c4e] のような識別子まで含めて指定し直す必要があります。誤爆を防ぐ作りなので、ここは親切な仕様だと思います。
別マシンのセッションは、名前を付けて起動しておく。 起動時にラベルを指定していないセッションは、一覧で 203-0-113-45-static-example-jp-twinkly-parrot のような自動生成の名前になります。私の環境では、この形の名前が8本並んでいて、どれがどれか区別できませんでした。起動時に名前を付けておけば、その名前が一覧に出ます。
相手はこちらの会話を一切知らない。 届くのは書いた本文だけで、履歴もファイルも渡りません。これは仕様の説明どおりです。裏を返すと、引き継ぎ書と同じ密度で書く必要があります。「確認済みの事実は数値ごと書く」「まだ確認していないことは確認していないと書く」を守らないと、受け取った側が同じ調査をやり直します。
相手の作業に割り込む形で入る。 一覧に busy と出ている相手に送ると、その作業の途中に差し込まれます。状態を見てから送るのが無難です。また、送った本文は相手側の記録に残るので、渡す情報の範囲は普通のメールと同じ感覚で考えておくのがよいと思います。
ここから何が変わりそうか
正直に言うと、機能そのものは地味です。メッセージが送れるようになった、というだけの話です。
それでも、私にとっては手が届く範囲が一段広がったという実感があります。理由は2つあります。
1つは、人が橋渡しをやめられたこと。これまでは、片方が出した結論を私が読んで、価値を判断して、もう片方に貼る、という工程が毎回挟まっていました。今は、必要だと思った側が直接送ります。私が席を外していても往復は進みます。
もう1つは、役割の違うAIを常時ぶつけられるようになったこと。今回のいちばんの収穫が「訂正の往復」だったのは、偶然ではないと思っています。1つのセッションの中で自己チェックさせても、同じ文脈にいる以上、同じ思い込みを共有してしまいます。資料を読んだ側と、実際に手を動かした側は、持っている情報が違う。だから片方の誤りにもう片方が気づけます。
一人でやっている会社でも、「調べる担当」と「作る担当」を別々に立てて、その2人に議論させておくことができる。今回いちばん面白かったのはそこでした。
これまで、AIに任せられる仕事の単位は「1つのセッションで完結すること」でした。その壁が1枚外れたところです。ここから先どう組むのが一番よいかは、まだ手探りです。分かったことはまた書きます。