複数のターミナルが、
お互いに声をかけ合うようになった。

daily_updates の見出しは「セッションが記憶を共有」と読めるが、これは正確ではない。The Decoder が明確に指摘している通り、セッション同士は互いの会話履歴やコンテキスト状態、ファイル内容を共有するわけではない。渡せるのはあくまでテキストの伝言だけだ。混同されやすい別機能「Session Memory」——同一セッションの過去作業内容を自動で覚えておく機能——とは別物であることに注意したい。

なぜ今これが重要か。エージェント型コーディングツールが「1人のユーザーが1つのセッションを操作する」から「複数のセッションを同時並行で束ねる」働き方へ踏み出した最初の一歩だからだ。並列ワークツリーでの開発が、より本格的な分業に近づく。

誰に・どう効くか。複数の worktree を切って並行開発するエンジニア、バックエンドとフロントエンドを別ターミナルで同時に進める人には、手動での情報伝達が減る実利がある。単一ウィンドウ・単一タスクで作業する人には、今のところ縁のない機能だ。PM や QA のように、複数のエンジニアが立てたセッションの進捗をまとめて把握したい役割の人にとっても、伝言のログが残ることで状況把握のコストが下がる可能性がある。

次に何をすべきか。①まずは同一マシン上の2セッションで、片方の発見をもう片方へ伝える簡単なユースケースから試す、②別マシン間の連携が必要な場合はAnthropicサーバー経由になる点を踏まえ、機密情報を含む伝言を避ける、③チームで使う場合は「何を伝言していいか」の運用ルールを決めておく——の3手が現実的だ。想定される実用例としては、長時間走らせているバッチ処理のセッションから「終わったよ」という進捗通知を別セッションへ飛ばす、あるいは片方のセッションで見つけたバグの原因を、修正担当の別セッションへそのまま渡す、といった使い方が挙げられている。

反対視点・リスク。権限承認の代行や設定変更ができない設計は安全側だが、テキストとして届いた伝言の中身自体をどこまで鵜呑みにしてよいかは利用者の判断に委ねられている。悪意あるプロンプトインジェクションを含む伝言が渡された場合の挙動は、記事執筆時点で十分に検証されていない。またWindows未対応のため、Windows開発者は当面この恩恵を受けられない。別マシン経由の伝言はAnthropicのサーバーを経由するため、社外秘のコードやログを丸ごと伝言に含める運用は避けたほうがよいだろう。