Claude Codeのセッション間通信を構築する手順

症状： 複数のClaude Codeを起動すると、進捗の転記、同じファイルの編集、権限確認が増えてしまいます。
最短解決策： まずmacOSまたはLinuxの同一マシンで、独立したGit worktree、明確なセッション名、制御した受信設定を使って小さく検証してください。メッセージは状態・判断・阻害要因だけに限定し、共有記憶、ファイル同期、権限付与には使いません。

本稿は、複数のClaude Codeターミナルを使う個人開発者、フロントエンド・バックエンド・テストを並行させるAI開発チーム、遠隔Macで常時稼働する開発環境を設計するプラットフォーム担当者向けです。
最初から別マシンへ広げるのではなく、1台で通信の成立条件と失敗時の表示を確認してから、運用規模を増やします。

最終更新：2026年8月12日。Claude Code公式リリース情報と公式ドキュメントを同日確認しています。

機能の境界と前提条件

Claude Codeの公式ドキュメントでは、各セッションは独立したコンテキストとして扱われます。会話履歴、ツール実行、結果はセッション単位で保存され、過去のセッションをそのまま共有する仕組みではありません。

2026年8月11日時点の公式リリース記録では、v2.1.224でSendMessageとListAgentsによるセッション間通信が導入され、v2.1.225で別マシンからの対話開始と非対話メッセージ処理に関する修正が追加され、v2.1.227が最新リリースです。環境によって配布タイミングが異なる可能性があるため、手元ではclaude --versionと公式のClaude Code Releasesを照合します。

ここで混同しやすいものは4つあります。

• セッション間通信：独立したClaude Code同士が短い情報を交換する機能です。
• Agent Teams：複数のエージェントをチーム単位で動かす仕組みです。今回の単純な2セッション検証とは運用単位が異なります。
• 子Agent：親セッションから作業を委譲する構成です。別セッションを人間が並列起動する方式とは、状態管理と権限の境界が異なります。
• セッション復元・Remote Control：既存セッションへ戻ったり、別端末から操作したりする仕組みです。SendMessageによる通知経路と同一視しないでください。

公式セットアップでは、macOS 10.15以降、Ubuntu 20.04以降やDebian 10以降などが案内されています。WindowsはWSLやGit Bash経由の条件が示されていますが、今回の通信検証ではmacOSまたはLinuxを基準にしてください。Node.js 18以降、4GB以上のメモリ、認証とAI処理のためのインターネット接続も必要です。 公式セットアップ要件を確認できます。

なお、原生Windows環境や一部の第三者モデル提供経路は、機能の組み合わせによって対象外になる場合があります。配布チャネル、認証方式、モデル提供元を固定せず、サポート範囲を公式資料で確認してから導入してください。

最初の1時間で行う同一マシン検証

最初のテストでは、コードを変更させません。通信だけを検証することで、失敗原因をGit、モデル、権限、接続のどこに切り分けるかが明確になります。

1. バージョンを確認します。
   各ターミナルでclaude --versionを実行し、最低条件を満たしているか確認します。更新が必要なら公式CLIのclaude updateを使い、更新後に新しいターミナルで再起動します。主要コマンドは公式CLIリファレンスで確認できます。

2. セッション名を役割で分けます。
   例としてfrontend-reviewとbackend-apiのように、担当と目的が分かる名前を付けます。session-1のような名前は、送信先を誤る原因になります。

3. 別々のターミナルで起動します。
   同一プロジェクトでも、通信テスト時は読み取り専用の確認を指示します。「現在のブランチ名、作業状態、次に必要な確認だけを回答してください」と依頼し、編集、シェル実行、設定変更を禁止します。

4. /list-agentsで可視性を確認します。
   相手のセッション名が一覧に出るかを確認します。表示されない場合は、バージョン、同一ユーザー、同一ホスト、作業ディレクトリ、起動直後の状態を順番に見直します。

5. SendMessageで短文を送ります。
   送る内容は「APIのレスポンス項目をstatusからstateへ変更予定。バックエンド側で確認後、テスト結果を返してください」のように、変更点と返答条件に限定します。

6. 画面の結果を記録します。
   送達、保留、拒否の表示を記録し、受信側が返信できるか確認します。成功しても、通信がファイル内容や会話全体を共有しているとは判断しません。

注意： SendMessageの受信を確認するために、APIキー、顧客データ、秘密鍵、社内URLを送らないでください。最初の確認は「ping」「担当」「次の確認」のような非機密情報で十分です。

並行作業をGit worktreeで隔離する

通信が成立したら、次はファイル競合を止めます。複数のClaude Codeを同じ作業ディレクトリで動かすと、片方が編集中のファイルをもう片方が読み替えたり、テスト前の変更を上書きしたりする危険があります。

Git worktreeを使い、担当ごとに作業場所を分けます。例えば、フロントエンドはfeature/frontend、バックエンドはfeature/backend、テストはchore/regressionというように、ブランチとディレクトリを1対1で対応させます。

git worktree add ../project-frontend -b feature/frontend
git worktree add ../project-backend -b feature/backend
git worktree add ../project-test -b chore/regression

このコマンド自体はGitの標準機能です。重要なのは、Claude Codeのセッションをそれぞれ別のworktreeで起動することです。

• フロントエンド担当は画面と型定義だけを変更します。
• バックエンド担当はAPI実装とレスポンス仕様を変更します。
• テスト担当は両方のコミットを取り込み、回帰テストを実行します。
• SendMessageでは、変更したファイル名の一覧ではなく、インターフェース、コミットID、テスト結果、未解決の阻害要因を伝えます。

実務では、バックエンドがstatusをstateへ変更した時点で、フロントエンドへ通知します。フロントエンド側は自分のworktreeで型と表示を更新し、テスト担当は統合後に回帰テストを実行します。これにより通信は衝突を減らせますが、レビュー、マージ、CIの代わりにはなりません。

通信に向く情報と向かない情報

向いている情報

• 仕様変更の決定事項
• コミットIDとブランチ名
• テストの成功・失敗
• 他の担当が確認すべき阻害要因
• 次の担当者と返答期限

向いていない情報

• 大きなログ全文
• ソースコード全体
• 長い会話履歴
• 認証情報や個人情報
• 「全部確認しておいて」のような曖昧な依頼

Claude Codeの設定はユーザー、プロジェクト、ローカルなどのスコープで管理され、権限ルールは単純な上書きではなく、複数の設定範囲を考慮して評価されます。 公式設定ガイドを確認し、通信機能だけを追加したつもりで、ツール権限まで広げないようにします。

別マシンへ広げる前の経路確認

同一ホスト上の通信と、別マシン上のセッションとの通信は、同じ感覚で扱えません。後者では、認証、接続先、セッションの公開条件、ネットワーク制限、接続断後の再接続を確認する必要があります。

最初の跨マシン検証は、次の順番で進めます。

1. 両方のマシンで対象バージョンを確認します。
2. 送信元と受信先に、役割を含む一意なセッション名を付けます。
3. /list-agentsで、対象セッションが期待した名前で表示されるか確認します。
4. 「接続確認、返信はREADYのみ」という非機密メッセージを送ります。
5. 返信の有無、遅延、保留、拒否、切断後の挙動を記録します。
6. 成功後にだけ、コミットIDやテスト結果の通知へ進めます。

Claude Codeは認証とAI処理にインターネット接続を必要とします。企業プロキシを使う場合は、公式案内にあるHTTP・HTTPSプロキシ、証明書、許可対象URLの条件も確認してください。SOCKSプロキシやNO_PROXYの扱いには制約があります。 公式プロキシ設定を参照してください。

コンテナ内のClaude Codeとホスト側のClaude Codeが互いに見えない場合、機能不良とは限りません。プロセス、ソケット、ユーザー、ファイルシステムが分離されているため、同一マシンでも別環境として扱われることがあります。コンテナを含む構成では、検出可能性を導入前の設計条件にしてください。

FAQ：導入時に詰まりやすい5つの確認

Claude Codeの2つのターミナルからメッセージを送るにはどうしますか？

まず両方のセッションを起動し、/list-agentsで相手が見えることを確認します。送信側でSendMessageを使い、宛先名、変更点、返答条件を短く指定してください。長文の文脈やファイル本体を送るのではなく、Gitのコミットとテスト結果を受け渡す運用が適しています。

Claude Codeのセッション間通信はどのOSで利用できますか？

最初の検証にはmacOSまたはLinuxを選びます。公式セットアップではWindowsもWSLやGit Bash経由で案内されていますが、セッション間通信の対応条件はバージョンと提供チャネルによって変わる可能性があります。原生Windowsで始める場合は、対象リリースと公式ドキュメントの記載を照合してください。

複数のClaude Codeが同じファイルを変更しない方法はありますか？

Git worktreeを担当ごとに作り、各Claude Codeを別ディレクトリから起動します。変更はブランチとコミットで管理し、通信ではインターフェース変更、コミットID、テスト結果だけを伝えます。同じworktreeを共有したままメッセージ機能を追加しても、編集競合は解消されません。

Claude Codeの別マシンへのメッセージはサーバーを経由しますか？

同一マシン上のセッションと別マシン上のセッションでは、確認すべき経路が異なります。公式の対応条件、認証方式、接続設定を確認し、まず機密性のない短文で送受信を検証してください。経路を説明できない状態では、ソースコードや顧客情報をメッセージに含めないでください。

SendMessageでメッセージを受け取れない場合はどうしますか？

最初にバージョン、セッション名、/list-agentsの表示、同一ユーザーかどうか、コンテナや別ユーザーを挟んでいないかを確認します。送信結果が送達、保留、拒否のどれかを記録し、非機密の短文で再現します。受信側のツール権限が広がっているかどうかも別に確認してください。

上線前の受入れチェック

次の項目をすべて確認できるまでは、別マシンへの拡張や無人運用へ進めません。

• [ ] 各セッションのClaude Codeバージョンを記録した
• [ ] macOSまたはLinuxの同一ホストで送受信を確認した
• [ ] セッション名に担当と用途を含めた
• [ ] /list-agentsで対象セッションの表示を確認した
• [ ] SendMessageで送達、保留、拒否の表示を記録した
• [ ] 機密情報を含まないテストメッセージを使った
• [ ] フロントエンド、バックエンド、テストのGit worktreeを分離した
• [ ] インターフェース変更をコミットとレビューで受け渡した
• [ ] 別マシンでは接続断と再接続の挙動を確認した
• [ ] コンテナ内外や別ユーザーの検出条件を確認した
• [ ] 受信メッセージが命令実行や権限承認を自動化しないことを確認した
• [ ] 失敗時に単一セッションへ戻す手順を決めた

受信権限と1週間の運用記録

受信メッセージの扱いは、セッションの役割に応じて分けます。対話型の開発セッションなら確認後に受け入れる設定、権限確認を省略するセッションなら保留、無人タスクや外部接続を持つセッションなら拒否を基本にします。

特に別マシンからのメッセージは、追加承認を要求する運用が安全です。機密プロジェクトでは、ListAgentsとSendMessageを許可しない選択肢も検討してください。メッセージを受信しても、対象セッションのコマンド実行、設定変更、ツール権限、ファイル編集が自動的に承認されるわけではありません。公式の権限設計とCLIの許可・拒否設定を基準に受入れ条件を作ります。

最初の1週間は、機能の印象ではなく運用記録で判断します。最低限、次の項目を残してください。

• メッセージの送達数と失敗数
• 人手による承認回数
• 同じ内容を再送した回数
• 同一ファイルや同一APIへの作業衝突
• セッションが待機していた時間
• 通知後に実際の作業が進んだか

作業が高度に直列で、同じファイルを頻繁に触り、メッセージの往復が増えるなら、複数セッションは適していません。単一セッション、子Agent、または通常のプルリクエスト運用へ戻した方が、監査とレビューは簡単です。

反対に、担当が明確で、worktreeが分離され、通知がコミットやテスト結果に集約されるなら、常時稼働する遠隔Macを検討できます。個人の開発機を占有せず、時差のあるチームでセッションを引き継ぐ場合は、Claude Codeの遠隔Mac運用に関する案内と、導入前の利用サポート情報を確認してください。

ローカルのノート型Macや一時的なクラウド環境で続ける方法もありますが、前者はスリープ、回線切断、個人作業との資源競合が起こりやすく、後者はGUI操作、永続ディスク、認証情報の保管方法を別途設計する必要があります。複数のClaude Codeを長時間動かし、時差をまたいで引き継ぐなら、必要な期間だけ専用の遠隔Macをレンタルする方が、作業場所の競合と復旧手順を整理しやすい場合があります。

一方、単一開発者が短時間だけ試す用途、物理デバイス接続が必要な作業、長期間の固定負荷で自社資産として管理したい用途では、レンタルが最適とは限りません。セッション数、worktree数、オンライン時間を見積もったうえで、kvmsyncの料金情報と自前運用の管理コストを比較してください。