Claude Codeを複数のターミナルで同時に動かしている人にとって、かなり面白い進化が登場しています。

それが、セッション間メッセージング（Cross-session messaging）です。

これまでClaude Codeを並列で使う場合、

セッションA：データベース設計
セッションB：API実装
セッションC：テスト作成
セッションD：ドキュメント更新

と役割分担することはできても、それぞれのセッションは基本的に独立していました。

そのため、

「DBのカラム名を変更したからAPI側にも伝えたい」

となった場合、人間がセッションAの結果をコピーし、セッションBへ貼り付けて説明する必要がありました。

つまり、AIを複数動かしているのに、人間自身がAI同士の「伝言係」になっていたわけです。

セッション間メッセージングは、この問題を大きく変える可能性があります。

Claude Codeの「セッション」とは？

まず前提として、Claude Codeでは複数の作業を並行して進められます。

たとえば大きなWebサービスを開発している場合、

Claude A
└─ DB設計

Claude B
└─ API実装

Claude C
└─ フロントエンド

Claude D
└─ テスト・レビュー

という形で、それぞれ別のClaudeに作業を担当させることができます。

人間の開発チームに置き換えれば、

DB担当
バックエンド担当
フロント担当
QA担当

のようなものです。

問題は、これまで各セッション間の情報共有に人間の介入が必要だったことです。

従来は「人間」がメッセージルーターだった

たとえばDB担当Claudeが次の変更を行ったとします。

usersテーブルを変更しました。

user_name
↓
display_name

API担当Claudeにも、この変更を知らせる必要があります。

従来なら、

Claude A
   ↓
 人間
コピー＆ペースト
   ↓
Claude B

という流れになります。

複数セッションを動かせば動かすほど、この作業が増えていきます。

3セッション程度ならまだ管理できますが、5個、10個と増えてくると、

「どのClaudeに何を伝えたか」

を人間が管理しなければならなくなります。

AIを増やした結果、人間側の管理コストが増えるという矛盾がありました。

Cross-session messagingで何が変わる？

セッション間メッセージングでは、Claude Code側から別のセッション・エージェントへ情報を渡せるようになります。

概念的には、

Claude A（DB）
   │
   │ メッセージ
   ▼
Claude B（API）

という連携が可能になります。

人間がコピー＆ペーストする必要がありません。

さらに複数のClaudeを組み合わせれば、

              ┌→ DB担当
              │
リーダーClaude ├→ API担当
              │
              ├→ Frontend担当
              │
              └→ Test担当

のような、小さなAI開発チームに近い構成が見えてきます。

カギになる「ListAgents」と「SendMessage」

この仕組みを理解するうえで重要なのが、エージェントの検出とメッセージ送信です。

考え方としては非常にシンプルです。

ListAgents

まず、

誰がいる？

を調べます。

たとえば、

database-agent
api-agent
frontend-agent
test-agent

のように、現在連携可能なエージェントを把握します。

人間でいえば、

「今、このプロジェクトには誰が参加している？」

を確認するようなものです。

SendMessage

送り先が分かれば、今度は必要な情報を送ります。

たとえばDB担当が、

users.user_name を
users.display_name に変更しました。

API実装を更新してください。

とAPI担当へ通知するイメージです。

つまり、

ListAgents
     ↓
相手を探す
     ↓
SendMessage
     ↓
情報を渡す

という流れになります。

Claude Codeの公式CHANGELOGでも、SendMessage を使ったバックグラウンドエージェントの再開や、メッセージの誤配送防止、エージェント間メッセージングのトークン削減など、関連機能の改善が継続的に行われています。

会話履歴を丸ごと渡すわけではない

ここは重要なポイントです。

AI同士が連携すると聞くと、

「Claude Aの巨大なコンテキストをClaude Bにも全部コピーするの？」

と思うかもしれません。

しかし、それでは非常に非効率です。

仮にClaude Aが10万トークンの会話履歴を持っていたとして、それをClaude Bへ丸ごと渡せば、トークン消費もコンテキストも一気に膨らみます。

必要なのは多くの場合、

DB変更完了。

変更：
user_name → display_name

API側の型定義を更新してください。

という数行の情報だけです。

つまり重要なのは、

「コンテキストを共有する」のではなく、「必要な情報をメッセージとして共有する」

という考え方です。

これはトークン節約にもつながる

個人的にかなり重要だと思うのが、この部分です。

これまで1つのClaudeに、

調査
↓
設計
↓
実装
↓
テスト
↓
レビュー

を全部やらせると、コンテキストがどんどん巨大化していました。

一方、役割を分ければ、

Research Claude
↓
結論だけ送信
↓
Coding Claude
↓
実装結果だけ送信
↓
Review Claude

という構成が可能になります。

たとえば調査セッションが大量のWeb情報やコードを読み込んだとしても、実装セッションが必要なのは、

調査結果

・方式Aを採用
・理由：〇〇
・注意点：△△

だけかもしれません。

これは、人間の会社で「100ページの調査資料を全社員に読ませる」のではなく、

結論だけ会議で共有する

のと同じです。

実用例① 調査Claude → 実装Claude

かなり相性がよさそうなのが、

Research AgentとCoding Agentの分離

です。

Research Claude
│
├─ 公式ドキュメント調査
├─ GitHub Issue調査
├─ API仕様確認
└─ ライブラリ比較
        │
        ▼
    結論を送信
        │
        ▼
Coding Claude
│
└─ 実装

Coding Claudeは大量の調査履歴を抱える必要がありません。

調査担当から、

調査完了。

推奨方式：A
理由：
1. 公式サポート
2. 将来互換性
3. 実装量が少ない

注意点：
○○は非推奨。

という情報だけ受け取ればよいわけです。

実用例② DB担当 → API担当

複数人開発に近い使い方もできます。

Database Claude
│
│ schema変更
│
▼
API Claude
│
│ API修正
│
▼
Test Claude

DB担当が変更を終えたらAPI担当へ通知。

API担当が修正を終えたらテスト担当へ通知。

最終的には、

DB変更
↓
API修正
↓
テスト
↓
レビュー

という作業フローをClaude同士で引き継ぐ形が考えられます。

実用例③ 「司令塔Claude」を置く

さらに面白いのが、1つのClaudeをリーダーとして使う方法です。

                 Manager Claude
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
 Research Claude   Coding Claude   Test Claude
        │              │              │
        └──────────────┼──────────────┘
                       ▼
                  Review Claude

人間はManager Claudeに、

この機能を実装してください。

と依頼する。

Manager Claudeが、

Research担当
→仕様を調査

Coding担当
→実装

Test担当
→テスト

Review担当
→最終確認

という形で仕事を分解する。

こうなるとClaude Codeは単なる、

「AIコーディングアシスタント」

ではなく、

「AI開発チームを動かす環境」

へ近づいていきます。

実は以前からユーザーが求めていた機能

興味深いのは、Claude CodeのGitHubでも以前から「複数セッション間で直接情報を共有したい」という要望が出ていたことです。

典型的なのが、

Migration Claude
Database Claude
Search Claude
Dashboard Claude
Monitor Claude

など複数セッションを並行稼働させているケースです。

たとえばMigration担当がサーバーIPを変更した場合、他のClaudeは古いIPをコンテキストとして持ったまま作業してしまいます。

従来は人間が全セッションへ変更内容を伝える必要がありました。

これは複数Claudeを本格利用すると、かなり大きな問題になります。

ただし「AI同士が勝手に全部やってくれる」わけではない

便利な仕組みですが、注意も必要です。

セッションが増えるほど、

Claude A
Claude B
Claude C
Claude D
Claude E

それぞれがモデルを利用します。

つまり、

エージェントを増やせば計算資源やトークン消費も増える

という基本構造は変わりません。

「10個立ち上げれば10倍速い」と単純にはいきません。

むしろ重要なのは、

必要な仕事だけ分離する

ことです。

情報の食い違いにも注意

もう一つ注意したいのが状態管理です。

たとえば、

Claude A
「APIはv2になった」

Claude B
「まだv1だと思っている」

という状況が起こる可能性があります。

メッセージングがあったとしても、

プロジェクト全体の状態が自動的に完全同期されるとは限りません。

そのため実際の開発では、

Git
README
CLAUDE.md
設計書
Issue
テスト

など、「最終的な正解となる情報源」を決めておくことが重要です。

Claude同士のメッセージは、

情報伝達の高速道路

として使い、コードや仕様の最終状態はGitなどで管理するのが安全でしょう。

Gitとの組み合わせがかなり強そう

特に相性がよいのがGit Worktreeです。

たとえば、

main
│
├─ worktree/database
│      └─ Claude A
│
├─ worktree/api
│      └─ Claude B
│
├─ worktree/frontend
│      └─ Claude C
│
└─ worktree/test
       └─ Claude D

という構成です。

それぞれ独立した作業環境でコードを書きながら、必要な情報だけをメッセージで共有する。

最終的に、

Claude A
↓
commit

Claude B
↓
commit

Claude C
↓
commit

Claude D
↓
test

Manager
↓
merge / PR

という開発フローが見えてきます。

Claude Codeは「1人のAI」から「AIチーム」へ

今回のセッション間メッセージングで重要なのは、単に、

「Claude同士でメッセージを送れるようになった」

という機能追加だけではないと思います。

Claude Codeの使い方そのものが、

人間
 ↓
Claude

から、

              人間
               ↓
          Manager Claude
               ↓
     ┌─────────┼─────────┐
     ↓         ↓         ↓
 Research    Coding     Testing
 Claude      Claude      Claude
     └─────────┼─────────┘
               ↓
          Review Claude

へ変わる可能性があるからです。

これまで人間が担当していた、

誰に仕事を振るか
進捗を確認する
仕様変更を伝える
結果を別担当へ渡す

という「AIの管理作業」の一部まで、Claude側へ移せる可能性があります。

まとめ

Claude Codeのセッション間メッセージングは、派手に見える機能ではありません。

しかし、複数のClaude Codeを並列で使っている人ほどインパクトは大きいでしょう。

これまでは、

Claude A
↓
人間
↓
Claude B

だった情報伝達が、

Claude A
↓
Claude B

へ変わる。

この違いは小さく見えて、実は非常に大きいものです。

AIを1つ使う時代から、

複数のAIに役割を与え、互いに連携させる時代へ。

Claude Codeは「優秀なコーディングアシスタント」から、徐々にAIエージェントを束ねる開発環境へ進化しているように見えます。

今後注目したいのは、単純なメッセージ送信だけではありません。

タスクの依存関係、共有状態、レビュー、承認、Gitとの連携まで、どこまでAI同士で自律的に回せるようになるのか。

セッション間メッセージングは、その入口になる機能かもしれません。