複数のClaude Code（Anthropic製のコーディングエージェント）セッションを並行運用しているエンジニアに向けた話です。セッション同士が直接メッセージを送り合う「クロスセッションメッセージング」という機能を、非機能要件の観点から見ていきます。
並列でエージェントを走らせるとき、互いの作業がぶつかる衝突リスクや、待ち合わせのための調整コストは無視できません。この機能はその調整を自動化しようとするものですが、実際に何を運んでいるのかを確認してから採用判断をした方がよさそうです。
クロスセッションメッセージングとは何か
Claude Codeには現在、複数の実行単位が互いにメッセージを送れる仕組みが3種類あります。
見分けにくいのは、受信側のトランスクリプト（実行ログ）に現れるマーカーがどれも似た見た目をしている点です。ピアセッション間の通信は<cross-session-message>、エージェントチーム機能は<teammate-message>、サブエージェントの結果報告はまた別のメッセージ形式を使います。
| 仕組み | 特徴 | 調整構造 |
|---|---|---|
| ピアセッション | 並列セッション同士が自由に送信 | 役割なし・リーダーなし |
| エージェントチーム | 名前付きロール・リード役が存在 | 可用性通知・遵守を促す文言あり |
| サブエージェント | タスク完了時に結果を報告 | 親エージェントの受信箱に配送 |
この3つを区別せずに数えると、集計そのものが汚染されます。送信側のツール実行結果を見れば、どの仕組みを使ったかは製品側のログから機械的に判定できます。運用ログを分析する際は、まずこの切り分けが前提条件になります。
メッセージはいつ届き、何を運ぶのか
最初に検証すべき仮説は「タスクの途中でメッセージが割り込む」というものでした。マイルボックス（受信箱を能動的に読みに行く方式）とは違い、作業中に通知が飛んでくるなら、エージェントの見落としを防げるはずだという発想です。
ところが五日間・179件のメッセージを追跡した記録では、受信イベント138件すべてがターン境界（エージェントの1回の応答が終わった区切り）で発生していました。ツールを実行している最中に割り込んだ例はゼロです。
受信前には必ずキュー操作のログが記録されており、キューに溜まったメッセージはターンが閉じたタイミングでまとめて処理されます。送信から受信ログへの記録までの遅延は中央値で2.6秒でした。つまりトランスクリプトが記録しているのは「到着」であって「エージェントがそれを読んだ瞬間」ではありません。
これは重要な区別です。メッセージが届いた時点でエージェントは既にアイドル状態にあり、次のターン開始時にコンテキストへ自動的に取り込まれます。割り込みではなく、次のターンの入力に自動追加される仕組みだと理解した方が実態に近いといえます。
メッセージの中身をカテゴリ分けする
179件のメッセージは2名のコーダーがそれぞれ独立に、同じコードブックを使って二重にラベル付けしています。一致率はカテゴリ分類で91.1%、コーエンのカッパ係数（偶然の一致を除いた信頼性指標）は0.90でした。
内訳を見ると、進捗報告が23.3%、作業範囲の宣言が18.4%、リソースの受け渡しが12.9%と続きます。一方で相手の作業の不具合指摘が12.3%、主張の訂正が11.0%含まれており、単なる報告以上の相互チェックが起きています。
アクションリクエスト（何かをやってほしいという依頼）は3.1%、待機要求は1.8%と少数派でした。つまりメッセージの大半は状況共有であり、明示的な指示や依頼はごく一部にとどまります。
関連する検証結果との比較で見えてくる限界
この通信機能を評価する上で参考になるのが、スタンフォード大学のベンチマークCooperBenchを使った別の検証です。そこでは複数エージェントの協調作業を試した結果、2つの気になる事実が示されています。
1つ目は、エージェント同士が最初から通信チャネルを持っていて、指示されなくても勝手に使っていたという点です。つまり「コードに触る前にハンドシェイク（合意形成の手続き）を強制する」という仕組みを用意しても、そもそも発動しませんでした。
2つ目はさらに重要です。実際に性能を回復させたレバーは通信チャネルの有無ではなく、最終的な統合作業を1つのエージェントに担当させる責任の一本化でした。もっと厳しい失敗例もあります。あるエージェントが「調整すべきだ」と自分の内部推論には書きながら、実際には返信も担当作業もせずに終わったケースです。
この事実は、新しいメッセージング機能が解決しようとしている課題と、実際に性能を左右していた課題がずれている可能性を示しています。通信路を太くしても、フォロースルー（言ったことを実行し切る責任）の欠如は直らないという指摘です。
今日確認できること
並列エージェント運用を検討・運用しているなら、次の点をログから確認しておくと判断材料になります。
- トランスクリプト内で
cross-session-messageとteammate-messageのタグを区別して集計しているか - メッセージの受信タイミングがターン境界に集中しているか、ツール実行中に割り込んでいないか
- 送受信間の遅延がキュー処理に起因するものか、それとも実処理の遅延か
- 統合作業（マージやコンフリクト解消）の責任者が明示されているか、通信任せになっていないか
- 「対応する」という宣言だけで実行が伴っていないメッセージがないか
アーキテクチャ判断としては、通信チャネルの追加を「協調の解決策」として過大評価しないことが肝心です。責任の所在を1つの実行単位に集約する設計の方が、性能への寄与が大きいことが示されています。
並行実行の可用性を上げたいなら、まず統合フェーズの一本化を先に検討し、通信機能はその補助として位置づけるのが無理のない順番といえます。
まとめ
Claude Codeのクロスセッションメッセージングは、ターン境界でのみメッセージが到着し、割り込みではなく次ターンへの自動取り込みという設計でした。
メッセージの大半は進捗報告や作業範囲の宣言であり、明示的な指示は少数派です。相互チェックの機能はあるものの、通信チャネル自体が協調の鍵ではないという検証結果が別途存在します。
運用ログでは受信タイミング・遅延・統合責任の所在を確認し、通信機能の追加だけで並行実行の信頼性が上がると期待しすぎないことが判断のポイントになります。