何が変わったのか
これまでClaude Codeを複数のターミナルで並行して使う場合、片方のセッションで得た調査結果や設計判断を、人間が手でコピーして別のセッションに貼り付ける必要がありました。今回の変更で、セッション同士が直接メッセージを送り合えるようになります。
できることは主に3つです。ひとつは、Claudeが別セッションへテキストの要約を送ること。ふたつめは双方向のやり取りで、Anthropicによれば、ユーザーが別セッションに質問を投げ、その答えを直接受け取れます。みっつめが自発的な送信で、ある変更が別セッションの作業に影響する場合、Claudeが自分の判断でメッセージを出せます。ドキュメントでは、知見の共有、並列ワークフローの調整、長時間タスクの進捗確認といった用途が挙げられています。
なぜ「小さな機能」で終わらないのか
注目すべきは、コーディング支援の単位が「1ターミナル＝1タスク」から「複数セッションが状態を共有するチーム」へ移り始めている点です。従来、並列作業の同期はすべて人間の頭とコピペが担っていました。そこが自動化されると、人間の役割は各セッションの実務ではなく、全体の分業設計とレビューに寄っていきます。
とくに重いのが「自発的な送信」です。人間が指示していないタイミングで、エージェントが別のエージェントに文脈を渡す。これは複数エージェントの協調に一歩踏み込んだ挙動であり、レビューの観点も変わります。出力されたコードだけを見ていると、その判断がどのセッション由来なのかを追えなくなる可能性があります。
通信経路と制限を先に押さえる
実務上、最初に確認すべきは経路の違いです。同一マシン上のセッション同士はローカルで通信します。一方、異なるコンピュータ間ではAnthropicのサーバーを経由し、しかもその場合は「返答」しかできません。つまり、離れた端末をまたぐ利用は機能が絞られたうえ、通信が外部を通ることになります。
さらに、管理者は設定でこの機能を制限できます。そしてAmazon Bedrock、Google Cloud Agent Platform、Microsoft Foundryでは利用できません。クラウド事業者経由でClaudeを調達している組織は、そもそも対象外という点を前提に検討する必要があります。
💼 事業会社視点：これは自社にどう効くか
影響が最も直接的なのは、受託開発・SIerとSaaSの開発組織です。複数リポジトリや複数ブランチを同時に走らせる現場では、セッション間の文脈共有がそのまま並列度の上限を引き上げます。まず着手すべきは「どの作業を別セッションに切り出し、どのタイミングで同期させるか」という分業設計で、これは機能を入れれば自然に得られるものではありません。
一方、経営側が先に決めるべきはガバナンスです。異なるコンピュータ間の通信はAnthropicのサーバーを経由します。顧客のソースコードや仕様を扱う受託開発、決済・個人情報に触れるEC事業者では、情報システム部門の審査対象になり得ます。管理者が設定で制限できる以上、「使わせない」ではなく「同一マシン内は許可、端末間は制限」といった粒度の方針を、現場が使い始める前に出すことが実務的です。
もうひとつ見落とされがちなのが調達チャネルの問題です。この機能はAmazon Bedrock、Google Cloud Agent Platform、Microsoft Foundry経由では使えません。セキュリティ要件からクラウド事業者経由でLLMを調達している日本の大企業・金融系ほど、機能面で差がつく構図になります。既存の調達方針を維持するのか、用途別に併用するのか。ここは現場判断ではなく、役員レベルで整理すべき論点です。