クロスセッションメッセージとは何か

別々に動いている会話同士が連絡を取り合う仕組み

Claude Codeを使っていると、「セッション」という単語をよく見かけます。ざっくり言えば、Claude Codeを起動してから終了するまでの一連の会話のかたまりのことです。ターミナルでClaude Codeを立ち上げて、あれこれ指示して、終了する。この一区切りが1セッションです。

クロスセッションメッセージは、その名のとおり「セッションをまたいで(cross)やりとりされるメッセージ」を指す考え方です。ふつう、あるセッションでの会話は、そのセッションの中だけで閉じています。別のターミナルで開いたもう一つのClaude Codeは、隣で何が話されているかを知りません。そこに橋を架けて、あるセッションから別のセッションへ情報を届けようとするのがクロスセッションメッセージです。

身近な例で言うと

会社のオフィスを想像してください。会議室Aで打ち合わせをしているチームと、会議室Bで別の作業をしているチームがあります。壁で仕切られているので、Aでの決定事項はBには伝わりません。伝えたければ、誰かがメモを持って行くか、チャットで投げるか、共有ホワイトボードに書いておく必要があります。

セッションは、この「会議室」にあたります。中で交わされた会話は基本的にその部屋の中だけのもの。クロスセッションメッセージは、部屋と部屋のあいだをつなぐ「メモの受け渡し」や「共有ホワイトボード」に相当します。

なぜそんなものが必要になるのか

正直、最初は「一つのセッションで全部やればいいのでは」と思うかもしれません。実際、小さな作業ならそれで足ります。問題は、作業が長くなったり、並行して進めたくなったときです。

たとえば、片方のターミナルでテストを回しながら、もう片方で別の機能を実装する。あるいは、昨日の続きの作業を今日また始める。こういうとき、片方が知っている情報をもう片方が知らないままだと、同じ調査をやり直したり、食い違った前提で作業を進めてしまったりします。人間同士でも「それ、さっき隣のチームが解決してたよ」という話はよくあるはずです。

クロスセッションメッセージは、この「知識の分断」を埋めるための発想です。セッションAで得た結論をセッションBに渡せれば、Bは同じ調査を繰り返さずに済みます。

どうやって渡すのか

大事なのは、セッション同士は自動的にはつながらないという点です。何もしなければ、それぞれ独立して動きます。橋を架けるには、情報を「どこかに置いて、もう一方から読む」という形をとることになります。

もっとも素朴で確実なのは、ファイルに書くことです。調査結果をMarkdownのメモに残しておけば、別のセッションからそのファイルを読ませるだけで内容が共有されます。プロジェクト内のドキュメントやメモファイルが、実質的な「共有ホワイトボード」として機能するわけです。

コミットメッセージやIssueのコメントのような、もともとチームで情報を共有するための場所も同じ役割を果たします。人間が読むために書いたものを、別のセッションのClaudeにも読ませる、という使い方です。

初心者がつまずきやすいところ

いちばん多い誤解は、「さっきClaude Codeに話したことを、別のウィンドウのClaude Codeも覚えているはず」と思い込むことです。覚えていません。人格が同じでも記憶が別、と考えるとイメージしやすいかもしれません。同じ名前の人がふたり、別々の部屋にいるようなものです。

もうひとつは、渡す情報を書き出すのを面倒くさがってしまうこと。頭の中では文脈がつながっているので、つい「あれをやっといて」と省略して伝えてしまいます。受け取る側のセッションには「あれ」が何かわからないので、渡すときは省略せずに書く。ここは人間相手の引き継ぎと同じ心構えでいいと思います。

使いどころの感覚

ぜんぶをクロスセッションで共有しようとすると、かえって手間が増えます。実際に効くのは、「調べ直すのが高くつく情報」を渡すときです。ビルドが通らなかった原因、APIの仕様の落とし穴、この環境特有の設定。こういう「一度ハマって、やっと分かったこと」を書き残して次のセッションに渡せると、体感がかなり変わります。

逆に、その場限りの細かい試行錯誤まで残す必要はありません。引き継ぎ書に書く価値があるかどうか、で判断すると外しにくいはずです。