メモリスによる要約- v2.1.224でセッション間メッセージングが標準機能に
- 届くのは本文のみで会話履歴は渡らない仕様
- 情報共有と実行判断を分けて設計する発想が実務にも応用できる
複数の作業を同時に進めていると、片方で決めたことをもう片方に伝え直す手間が発生する。誰かに何かを伝える役目を、結局は人間が担っている場面は少なくない。
2026年8月、Claude Codeのv2.1.224で「クロスセッションメッセージング（Cross-session messaging）」がデフォルト有効になった。公式ドキュメントによれば、同じマシン上の別セッション同士がテキストメッセージを直接やり取りできる機能で、別マシンやWeb版とはRemote Control経由で連携する。バージョンの詳細はGitHubのリリースノートで確認できる。開発者向けメディアDevelopersIOの検証記事によれば、送れるのはプレーンテキストのみで、会話履歴やファイルは渡らない。受信側は「情報共有のみで、自分への具体的なアクションは求められていない」と趣旨を自律判断して待機する、といった挙動も報告されている。
この機能そのものはエンジニア向けだが、その設計思想は会議の記録を複数の相手・複数のツールに配る作業にも重なる。議事録を各方面に共有するとき、実際に困るのは「情報を渡すこと」と「渡した相手が何をすべきか判断すること」を、送り手が一緒くたに抱えてしまう点だ。クロスセッションメッセージングが分けているのは、まさにこの二つである。メッセージは配信されるが、それが受け手の同意や権限昇格にはならない、と前掲のDevelopersIO記事は指摘している。つまり「伝える」と「動く」を、仕組みの上で切り離している。
会議の記録を複数の関係者に配る運用でも、同じ切り分けを意識する価値がある。結論から言えば、共有する情報には「読めばよいもの」と「判断・実行を求めるもの」の区別を最初から付けておくべきだ。理由は単純で、区別のない共有は受け手全員に「これは自分がやるべきことか」を毎回考えさせるコストを強いるからだ。DevelopersIOの検証では、受信側が「情報共有のみ」と判断して待機した例が紹介されている。これは偶然ではなく、メッセージの文面自体に判断材料が含まれていたからこその挙動だろう。議事録の配布でも、決定事項・要対応事項・共有のみの情報を最初から分けて書いておけば、受け取った側が同じように迷わず仕分けできる。
もう一つ、受信側の制御機構も参考になる。同ドキュメントの整理では、メッセージの受け取り方を「配信する」「通知だけ表示して保留する」「破棄する」の三段階で設定できるとされている。これは、情報が届くことと処理することを別々にコントロールしたいというニーズが、ソフトウェアの外でも普遍的にあることを示している。会議の記録を複数チャネル（チャットツール・ドキュメント・メール）に配るときも、全員に同じ密度で流し込むのではなく、誰にとって「今すぐ見るべき」情報で、誰にとって「後で参照できればいい」情報かを切り分けて配布経路を分ける発想は、そのまま応用できる。
一つだけ気になる点も記事には残っている。バックグラウンドで動かす無人プロセスは、この検証時点では常駐リスナーとして機能しなかったという。常時待ち受けて処理する自動化の型はまだ発展途上らしい。人手を介さない情報の受け渡しがどこまで安全に自動化できるかは、記録・共有の実務全般に関わる問いとして、しばらく答えが定まらないままになりそうだ。