Claude Codeのセッション間通信｜使い方と安全設定

2026年8月15日

こんにちは。AIあれこれ散歩道、運営者のもっちゃんです。

Claude Codeを2つのターミナルで動かしていると、「片方の調査結果をもう片方へどう伝えるの？」「同じ会話を開き直す方法とは違うの？」と迷いますよね。2026年8月に追加された新機能を使うと、独立したセッション同士で短いテキストメッセージを受け渡せます。

結論からいうと、Claude Code v2.1.224以上をmacOS、Linux、またはWSL2で動かし、2つの独立セッションを開けば、Claudeへ「作業中の別セッションを確認して、この内容を伝えて」と頼めます。ただし、ファイルや会話履歴を丸ごと共有する機能ではありません。受信設定や権限の境界を理解して使うことが大切です。

この記事では、公式ドキュメントとv2.1.224以降の更新内容をもとに、始め方、対応OS、届かない原因、Remote Controlとの違い、安全な並列開発まで順番に説明します。

別ターミナルのClaudeへ連絡する手順が分かる
macOS・Linux・Windowsの対応状況を確認できる
受信を許可・保留・拒否する設定を理解できる
メッセージが届かない時の確認順を整理できる

Claude Codeのセッション間通信を始める

最初に押さえたいのは、この機能が「2つのClaudeを一体化する仕組み」ではなく、独立して動く作業担当の間に連絡路を作るものだという点です。片方を実装担当、もう片方をテスト担当に分け、必要な結果だけを短く伝えると効果を発揮します。

何ができる新機能なのか

Claude Code v2.1.224では、実行中の別セッションを探すためのListAgentsと、相手へテキストを送るSendMessageが追加されました。利用者が毎回ツール名を直接入力するのではなく、「別セッションを一覧にして」「テスト担当へこのエラーを伝えて」のようにClaudeへ自然な言葉で依頼すると、必要に応じてClaudeがツールを使います。

Anthropicのv2.1.224公式リリースでは、独立セッション間のメッセージングに加え、受信方針を決めるcrossSessionInboundと、承認待ちの期限に関係するdialogExpiryも案内されています。速報で「Claude同士が会話できる」と紹介されることがありますが、実際には短い連絡を安全に中継する設計です。

送れるのはテキストであり、相手の会話履歴やファイルそのものが自動共有されるわけではありません。たとえば「テスト結果は3件失敗。ログはreports/test.logに保存した」と送り、受信側が自分の権限でファイルを読み直す形になります。これなら、各担当のコンテキストを必要以上に膨らませずに済みます。

resumeやforkとの違いも重要です。resumeは保存済みの同じ会話へ戻る操作、forkはその会話を別の枝として複製する操作です。今回の機能は、別々の会話を保ったまま必要な要点だけを渡します。元の会話を続けたいのか、同じ履歴から別案を試したいのか、独立担当へ連絡したいのかで使い分けてください。公式の違いはClaude Codeのセッション管理Docsでも確認できます。

独立した担当者に短い引き継ぎメモを渡す感覚です

セッションAが実装し、セッションBがレビューする場合、コード全体をメッセージへ貼る必要はありません。変更したファイル、確認してほしい観点、成果物の保存先、終了条件だけを伝えると、重複作業を減らせます。

Claude Codeがそもそも何を自動化できるか整理したい方は、先にClaude Codeでできることを読むと、今回の連携機能をどの作業へ使うか判断しやすくなります。

対応OSと必要バージョン

公式ドキュメント上の最低条件はClaude Code v2.1.224以上です。ターミナルでclaude --versionを実行し、古い場合は普段使っているインストール方法に合わせて更新します。新機能は公開後も修正が続いているため、2026年8月15日の確認時点では最新版のv2.1.233へ上げてから試すのが無難です。

実行環境	公式上の対応	確認ポイント
macOS	対応	v2.1.224以上へ更新
Linux	対応	2つの独立プロセスを起動
Windows上のWSL2	対応	両方をWSL2環境で実行
native Windows	非対応	WSL2へ切り替えて確認

Windows利用者が注意したいのは、Windows Terminalを使っているだけではWSL2とは限らないことです。PowerShellやコマンドプロンプトで直接Claude Codeを動かしている場合はnative Windowsです。UbuntuなどのWSL2ディストリビューションを開き、そのLinux環境内で2つのセッションを起動してください。

導入段階で止まっている場合は、Claude CodeをWindowsにインストールする方法で、WSL2を含む準備を先に確認できます。対応状況は今後変わる可能性があるため、公開後に試す場合も公式のCross-session messaging Docsを最終確認してください。

2つの作業画面を準備する

同じパソコンで試すなら、ターミナルを2つ開き、それぞれでClaude Codeを新規起動します。重要なのは、同じ保存済みセッションを2画面から再開するのではなく、独立した2つのセッションを用意することです。同じ会話を分岐せず複数ターミナルで開くと、メッセージが一つのトランスクリプトへ混在し、今回の機能を試したことになりません。

ターミナルAを開き、対象プロジェクトでClaude Codeを起動する
「実装担当として認証処理を確認して」と役割を伝える
ターミナルBを開き、別のClaude Codeセッションを起動する
「レビュー担当としてテストと権限を確認して」と伝える
両方のセッションを終了させず、そのまま待機させる

最初は同じリポジトリで小さな読み取り作業から試してください。両方に同じファイルを同時編集させると競合しやすいため、実装とレビュー、調査と要約、テスト実行とログ分析のように役割を分けます。Gitを使う開発では、必要に応じてworktreeや別ブランチも併用すると変更の衝突を抑えられます。

役割、成果物の場所、確認してほしい条件を最初に決めると、連絡が短くても相手が迷いません。「終わったら知らせて」だけでなく、「失敗したテスト名とログの保存先を知らせて」のように、返してほしい情報を具体化しましょう。

2台のノートパソコンでClaude Codeの作業を分担する2人の開発者 — 実装とテストのように役割を分けると連絡内容を短くできます

相手を見つけてメッセージを送る

2つのセッションを起動したら、一方で/list-agentsまたは/peersを使い、認識されている相手を確認します。表示されない場合は、両方のバージョンと実行環境を先に見直してください。相手が見つかったら、Claudeへ自然文で送信内容を指示します。

「実行中の別セッションを一覧で確認して」
「レビュー担当へ、変更ファイルはsrc/auth.tsだと伝えて」
「テスト担当へ、失敗したケース名とログの場所を聞いて」
「相手の回答を受け取ったら、次の修正案を3つに整理して」

Claudeが内部でListAgentsを使って相手を特定し、SendMessageで連絡します。相手が複数いる時は「レビュー担当」「別マシンのセッション名」のように対象を明示してください。v2.1.225では同名セッションの選択に関する修正も入っているため、名前が重複している環境は最新版へ更新した方が安全です。

送信結果は、すぐ届いたdelivered、承認待ちになったheld、受信側が拒否したrefusedのように分かれます。heldは失敗とは限りません。権限モードの違いなどにより、受信側の人が内容を確認してから通す設計です。

別セッションへ作業結果だけを短く共有するClaude Code利用者 — ファイルを丸ごと送らず、保存先と要点を共有します

届かない時に確認する順番

送信できない時は、設定を手当たり次第に変えず、バージョン、検出、受信方針、実行環境の順に確認します。特にv2.1.224公開直後は、保留メッセージの扱いやRemote Control宛の送信に修正が続きました。古いバージョンのまま原因を探すと、設定では直らない不具合に時間を使ってしまいます。

両方でclaude --versionを実行し、v2.1.224以上か確認する
/list-agentsまたは/peersで相手が見えるか確認する
受信側のcrossSessionInboundがrefuseになっていないか確認する
heldなら受信側の承認画面と期限を確認する
native Windowsや非対応プロバイダー環境ではないか確認する
別マシンならRemote Controlの接続と同じアカウントか確認する

配信されないからといって権限を無制限にしないでください

bypassPermissionsへ切り替えると確認が減りますが、原因の切り分けにはなりません。まず最新版へ更新し、相手が検出されているか、受信側が保留または拒否にしていないかを確認します。安全設定を弱めるのは最後の手段ではなく、原則として避ける判断です。

v2.1.225では、起動時やヘッドレス環境で保留メッセージを処理しにくい問題、Remote Controlセッションへ名前を指定して会話を始める機能などが更新されました。v2.1.226にも不具合修正があります。エラー文が出る場合は、その文を保存し、最新版のChangelogと照合すると原因を絞りやすくなります。

認証経路も確認してください。公式Docsでは、Amazon Bedrock、AWS上のClaude Platform、Google Cloud Agent Platform、Microsoft Foundryなど一部のプロバイダー環境で、このメッセージ機能を利用できないと案内されています。また、機能フラグやテレメトリーを止める環境変数の組み合わせで無効になる場合もあります。会社管理の環境では、個人判断で設定を解除せず、管理者へ利用可否を確認しましょう。

Claude Codeのセッション間通信を安全に使う

便利な連絡路ほど、誰から何を受け入れるかを決めておく必要があります。Claude Codeは、他セッションのメッセージをそのままユーザー命令として扱わない設計です。その境界を理解したうえで、個人開発はholdから、企業環境は管理方針に合わせた設定から始めましょう。

受信設定は3段階で選ぶ

crossSessionInboundは、別セッションから届いたメッセージをどう扱うか決める設定です。選択肢はaccept、hold、refuseの3つです。最初から常時受信にする必要はありません。用途が固まるまでは保留にし、人が内容を確認してから通す方が安心です。

設定値	動作	向いている場面
`accept`	受信を許可	信頼できる同一マシン内の定型連携
`hold`	人の確認まで保留	初回テスト、権限モードが異なる連携
`refuse`	受信を拒否	通信を使わない端末、機密作業

dialogExpiryは、保留された確認ダイアログの有効時間に関係します。公式ドキュメントの既定は5分です。席を外すことが多いからといって長くしすぎると、古い依頼を後から誤って通す可能性があります。反対に短すぎると、正常な依頼まで期限切れになります。作業中に確認できる時間へ合わせてください。

迷った場合の初期値は、受信をholdにして短いテストメッセージだけを送ることです。期待した相手、内容、承認画面が確認できてから、信頼できる同一マシンの定型作業だけacceptを検討します。

メッセージに権限が付かない理由

他セッションから届く文章は、受信側にとって参考情報であり、ユーザー本人の承認ではありません。公式Docsでは、受信メッセージから権限を承認したり、設定を変更したり、スラッシュコマンドを実行したりできないと説明されています。送信側が「このコマンドを無条件で実行して」と書いても、受信側の権限確認を飛び越えることはできません。

これは不便な制限ではなく、プロンプトインジェクションや誤った権限中継を防ぐための重要な境界です。受信側Claudeがファイル編集やコマンド実行を必要と判断した場合は、受信側のpermission modeに従って、受信側の利用者へ承認を求めます。送信側の権限が強くても、その強さは引き継がれません。

連絡と承認を分けて考えます

セッションAは「テストを実行して」と依頼できますが、セッションBの危険な操作を承認することはできません。Bが必要な権限をB側の利用者へ確認するため、誰がどの端末で判断したかを追いやすくなります。

AIエージェントへ任せる範囲の決め方は、AIエージェントの権限管理と安全設定でも整理しています。通信機能だけでなく、書き込み可能なフォルダ、実行可能なコマンド、外部送信の可否をセットで見直してください。

別マシンとRemote Controlの注意点

同じパソコン内のセッションは、セッションごとのローカルなソケットを使って連絡します。一方、別のパソコンにあるセッションとの通信はRemote Controlの基盤を通ります。つまり「すべてローカルだけで完結する」とは限りません。社外秘の文字列、顧客情報、APIキー、未公開コードをメッセージ本文へ直接貼らない運用が必要です。

Remote Control公式Docsでは、コマンド実行とファイル操作はローカル環境に残る一方、Remote Control中の会話トランスクリプトはAnthropic側へ保存されると説明されています。別マシン連携を始める前に、契約プラン、組織管理者の許可、同じアカウントでの接続、社内のデータ取り扱いルールを確認してください。

v2.1.225のChangelogには、名前を指定してRemote Controlセッションへ会話を開始できる更新があります。ただし、Cross-session messaging Docsには古い制約を示すように読める部分が残っています。文書の更新差や段階提供が考えられるため、最新版へ更新し、/list-agentsに対象が出るかを実機で確認するのが確実です。

企業や複数端末の環境では、isolatePeerMachinesを使い、マシンの外へメッセージを出す前に承認を求める設計も検討できます。使わない端末ではcrossSessionInboundをrefuseにし、必要ならSendMessageとListAgents自体を拒否します。

ホテルラウンジで別マシンのClaude Codeを確認する女性 — 別マシン連携ではRemote Controlとデータ方針を確認します

並列開発で役割を分けるコツ

通信できるようになると、多くのセッションを立ち上げたくなります。しかし、人数を増やすほど成果が比例して増えるわけではありません。連絡の回数、同じファイルの競合、確認待ちも増えます。まずは2セッションで、成果物がはっきり分かれる作業を試してください。

実装担当は変更ファイルと動作確認結果を残す
テスト担当は失敗したケースと再現手順を返す
調査担当は公式URLと確認日を添える
レビュー担当は修正必須と提案を分ける
送信文には目的、成果物の場所、終了条件を書く
同じファイルを同時編集する時はブランチを分ける

たとえば、実装担当へ「ログイン処理を直して。変更後は対象ファイルとテスト名をレビュー担当へ伝えて」、レビュー担当へ「通知が届いたら差分と権限漏れを確認し、重大度を付けて返して」と指示します。相手へ渡す情報が決まっているため、長い会話を丸ごと共有するより判断が速くなります。

受信できる待機メッセージには上限があり、メッセージはテキストに限られます。大量のログやコードを本文へ貼るのではなく、必要なファイルへ保存し、場所と要点だけを伝えます。通信をタスク管理の代わりにせず、重要な決定はIssue、Pull Request、作業記録にも残してください。

もっちゃんのワンポイントアドバイス

最初の成功条件は「2人のClaudeを自律的に動かすこと」ではなく、「片方の結果が、意図した相手へ短く正確に届くこと」です。小さな読み取りタスクで送信先と承認の流れを確かめてから、編集やコマンド実行を含む作業へ広げると失敗を減らせます。

チャット型Claudeと開発用CLIの役割がまだ曖昧な方は、Claude CodeとClaudeの違いも参考になります。通常の相談、コード操作、複数セッションの分担を分けると、必要以上に複雑な構成を作らずに済みます。

よくある質問

Q1. Windowsでも利用できますか？

A. WSL2上のLinux環境では利用できますが、公式Docsではnative Windowsは非対応です。Windows Terminalを使っているかではなく、Claude Code自体をWSL2内で動かしているか確認してください。

Q2. ListAgentsやSendMessageを直接入力しますか？

A. 通常は「別セッションを確認して」「レビュー担当へ結果を伝えて」と自然文でClaudeへ頼みます。Claudeが必要に応じて内部ツールを使います。相手の検出確認には/list-agentsまたは/peersを利用できます。

Q3. ファイルや会話履歴を送れますか？

A. メッセージはテキストです。ファイルや会話履歴を丸ごと転送する機能ではありません。成果物をファイルへ保存し、保存先、要点、確認してほしい条件を相手へ伝える使い方が適しています。

Q4. 送信側が受信側の操作を承認できますか？

A. できません。他セッションのメッセージにユーザー権限はなく、受信側の設定変更やスラッシュコマンド実行、権限承認は行えません。必要な操作は受信側のpermission modeに従い、受信側の利用者が判断します。

Q5. セッション間の送信に別料金はかかりますか？

A. 公式資料では、この通信機能だけの独立した追加料金は案内されていません。ただし、各セッションはClaude Codeの利用量を消費します。別マシンでRemote Controlを使う場合は対象プランも必要です。契約画面と最新の公式Pricingを確認してください。

Claude Codeのセッション間通信まとめ

Claude Codeの独立セッション同士へ短いメッセージを送れるようになると、実装、テスト、調査、レビューを分けやすくなります。始める条件はv2.1.224以上のmacOS、Linux、またはWSL2です。2026年8月15日時点では最新版のv2.1.233へ更新し、2つの小さなセッションで試す方法が安心です。

今回の重要ポイント