Claude Codeのセッション間メッセージングで並列作業する

Claude Codeのセッション間メッセージングとは、別々に起動した独立セッション同士が、SendMessageとListAgentsを使ってテキストを送り合える機能です。結論から言えば、2026年8月7日公開のv2.1.224で追加され、macOSとLinuxなら追加設定なしで使えます。片方のセッションで起きた変更や結論を、もう片方の作業中セッションへ自動で伝えられるため、複数ターミナルを行き来してコピペする手間が消えます。この記事では、筆者が毎日記事を自動publishしている無人運用の視点もふまえ、何ができるのか、これまでのサブエージェントやresumeと何が違うのか、使い方と受信制御の設定、そしてサイト制作・自社ツール開発での実践までまとめます。

01Claude Code セッション間メッセージングとは｜何ができる機能か

Claude Codeのセッション間メッセージング（cross-session messaging）とは、別々に起動した独立セッションの間で、片方のClaudeがもう片方のClaudeへ一片のテキストを届けられる機能です。Anthropicの公式ドキュメントでは、あるセッションでの変更が別セッションの作業を壊すときに事前に警告したり、あるセッションが片付けた疑問の答えを、それに詰まっている別セッションへ渡したりする用途が挙げられています。筆者で確認したところ、2026年8月7日公開のv2.1.224で追加され、対応OSであれば有効化の操作は要りません。

使うツールは2つです。到達できる相手を一覧するListAgentsと、名前を指定して届けるSendMessageです。重要なのは、人がこれらのツールを直接呼ぶわけではない点です。「別ターミナルのセッションに、マイグレーションが終わったか聞いて」のように用件を伝えると、Claudeが相手を探して文面を書き、送信まで行います。ユーザーが決めるのは「何を伝えたいか」だけです。

使う場面は主に4つ

公式が挙げる典型例は、大きく4つです。ひとつ目は発見の受け渡しで、あるセッションが破壊的変更や設計判断に気づいたとき、影響を受ける領域を触っている別セッションへ要約を送ります。ふたつ目は並列worktreeの連携で、同じリポジトリを別々の作業ツリーで進めているセッションに、何がマージされたかを伝えます。3つ目は長時間処理の状況取得で、マイグレーションやテスト実行に結果を報告させられます。4つ目はマシンをまたいだ返信で、別端末やWebから届いたメッセージへ応答できます。

向いているユーザー像

複数のClaude Codeを同時に走らせて開発する人に向いています。1つのターミナルで完結する使い方では出番はありません。フロントとバックエンドを別セッションで並行して直す、片方に長い移行処理を任せてもう片方で別作業を続ける、といった並列運用をしている個人開発者やチームが主な対象です。筆者のように、記事生成の裏で別セッションに検証を走らせる無人運用でも接点があります。

02何が送られるのか｜テキストのみで履歴・ファイルは渡らない

この機能で相手に渡るのは、一片のプレーンテキストだけです。会話履歴もファイルも権限も相手には渡りません。公式ドキュメントは「A message is a piece of text one Claude writes to another, never conversation history or files（メッセージは、あるClaudeが別のClaudeへ書く一片のテキストであり、会話履歴やファイルではない）」と明記しています。会話や文脈ごと別セッションへ移したいときは、この機能ではなくセッションのresume（再開）を使う、という切り分けです。

受信側に届くと、そのメッセージは送信者の名前つきで会話に現れます。たとえば「Schema migration finished: the new column is tenant_id, and rebasing on main is safe now.（スキーマ移行が完了。新しい列はtenant_idで、mainへのリベースはもう安全）」のような一文が、相手のClaudeが自分で書いて届けた文面です。受信側は名前と本文だけを受け取り、送信側の履歴やファイルは一切見えません。

送られた側はどう扱うのか？

受信側のClaudeには「これはユーザーからではなく別セッションから来た」と明示され、できることが制限されます。具体的には、別セッションのメッセージは保留中の権限プロンプトへの同意にはならず、権限設定やCLAUDE.mdなどの構成変更の根拠にもなりません。本文に/compactのようなコマンドが書かれていても、それはただのテキストとして届き、実行はされません。作業に権限が要るなら、通常どおり承認プロンプトが出ます。他セッションの一言で勝手に危険な操作が走らないよう、境界が引かれています。

03これまでとの違い｜サブエージェント・resumeとの比較表

これまでとの一番の違いは、つなぐ相手が同一セッション内の子エージェントではなく、別々に起動した独立セッションである点です。Claude Codeには以前からサブエージェントやresumeなど複数のセッションを扱う仕組みがありますが、今回のメッセージングはそのどれとも役割が異なります。混同すると使いどころを外すため、既存の手段との違いを表で整理します。

項目	これまで（サブエージェント／resume）	今回（セッション間メッセージング）	実務での意味
つなぐ相手	同一セッション内の子エージェント、または同じ会話の再開先	別々に起動した独立セッション同士	すでに走っている別ターミナルの作業へ割り込める
渡るもの	サブエージェントは親の文脈を共有、resumeは会話ごと引き継ぐ	一片のテキストのみ（履歴・ファイルは渡らない）	文脈は渡さず、要点だけ軽く伝える用途に向く
指揮系統	親がサブエージェントを生成・監督する上下関係	対等な独立セッション間のP2P（1対1）通信	人が別々に立てて操るセッションをつなげる
権限	親の権限方針の影響を受ける	権限はセッションごとに分離、指令は同意にならない	片方が危険操作を肩代わりさせられない
マシンをまたぐ	基本は同一環境内	Remote Control経由で他マシン・Webへ返信可（返信のみ）	別端末のセッションへ答えを返せる

同じSendMessageツールは、単一セッション内のサブエージェントやAgent Teamsの相手にも使えます。今回追加されたのは、その宛先に「自分が別々に立てた独立セッション」が加わった点だと整理すると分かりやすいです。チームとして束ねて監督したいならAgent Teams、多数のセッションを一望して操作したいならagent view、というように、目的ごとに別の機能が用意されています。

アウトプットに出る差（想定）

ここは筆者の実測ではなく、仕様差からの想定として書きます。これまでは、別ターミナルで進む作業の結果を反映するには、人が両方を見て要点をコピペし直す必要がありました。セッション間メッセージングでは、片方のClaudeが変更や結論を自分で要約して相手へ渡せます。この仕様差から、並列で複数箇所を直す作業では、共有ファイルの変更に気づくのが早くなり、片方の変更を知らずにもう片方が古い前提で書き進める手戻りが減ると想定されます。ただし渡るのはテキストだけなので、文脈まるごとの共有が要る場面ではresumeを併用する判断が必要です。

04セッション間メッセージングの使い方｜基本の流れ

ここからは実際の使い方を、名前付け・相手確認・送信の順で紹介します。前提として、対応バージョン（v2.1.224以降）かつmacOS/Linuxであれば、有効化の操作は不要です。

①セッションに名前を付ける

セッションは名前で宛先を指定します。名前は/renameコマンド、または起動時の--nameフラグで設定します。付けなかった場合はClaude Codeが作業ディレクトリのフォルダ名からmyapp-3fのような名前を自動で振ります。並列で複数立てるときは、役割が分かる名前を明示しておくと、後で宛先を間違えません。

# 起動時に名前を付ける
claude --name frontend

# 起動後に付け直す
/rename frontend

同名セッションの見分け方

2つのセッションが同名になることもあります。/list-agentsの出力には各セッションの作業ディレクトリが表示されるため、同名でも別ディレクトリなら区別できます。Claude自身の一覧では各行に短い識別子が添えられ、名前が衝突したときはその識別子込みで宛先を指定します。

②到達できる相手を確認する

いま自分がどのセッションに届けられるかは、/list-agentsコマンドで確認します。/peersという別名でも同じです。一覧には、現在のセッション内で動くサブエージェント、同じマシンの他のローカルセッション、そしてRemote Control接続中であれば他マシンやWeb上のセッションが並びます。他マシンのセッションにはRemote Controlのラベルが付き、こちらからは会話を開始できず返信のみという扱いです。

③メッセージを送る

送信はツールを直接触らず、用件をClaudeに伝えるだけです。文面はClaudeが書きます。たとえば次のように頼みます。

もう片方のターミナルで動いているセッションに、
マイグレーションが終わったか聞いて

決済APIを担当しているセッションに、
いま共通の型定義を変えたことを伝えて

受信側がアイドル状態なら、メッセージは新しいターンとして始まります。作業の途中なら、実行中のツールを中断せず、ツール呼び出しの合間に読み込まれます。届いたメッセージは、いったんClaudeが読むと一行の「Message from」表示に畳まれ、Ctrl+Oで展開できます。

05受信の制御と安全設計｜inbound制御と越境の承認

受け取る側が主導権を握る設計です。届いたメッセージをどう扱うかは、受信側のcrossSessionInbound設定で決まり、選べる値は3つあります。

値	受信時の挙動
accept	届いたメッセージを毎回Claudeへ渡す
hold	通知だけ出して渡さない。後からacceptが適用されると保留分を解放する
refuse	届いたメッセージを渡さずに破棄する

値を明示しなかった場合は、送受信2つのセッションの権限モードから自動で決まります。受信側が通常の権限プロンプトを出すモードなら基本は配信され、送信側が権限プロンプトをスキップするモードのときだけ承認のために保留されます。逆に受信側が権限プロンプトをスキップするモードなら、各メッセージはいったん承認のために保留される扱いです。保留のダイアログは、返答がないままdialogExpiryの期限（既定5分）を過ぎると閉じ、メッセージは破棄されます。

別セッションの指令が承認にならない設計

他セッションからの一言で、権限確認をすり抜けられないようにするためです。受信側のClaudeには「これは別セッションから来た」と伝えられ、保留中の権限プロンプトへの同意にはならず、設定やCLAUDE.mdの変更根拠にもならず、本文中のコマンドも実行されません。もし作業に権限が要るなら、通常どおり受信側で承認プロンプトが出ます。送る側のClaudeも、自分のセッションで拒否・ブロックされた操作を相手に肩代わりさせないよう指示されています。

マシンをまたぐ通信を止めるには？

マシンの外へ出る送信すべてに自分の承認を必須にするには、isolatePeerMachinesをtrueにします。これを設定すると、通常のプロンプトを飛ばすbypassPermissionsモードでも、他マシンのセッションへ返信が出る前に承認を求められます。プロジェクトの設定ファイルからは有効化はできても無効化はできない、という片方向の仕様です。

{
  "isolatePeerMachines": true
}

受信も送信も完全に止める設定

受信を止めるにはcrossSessionInboundをrefuseにします。送信と一覧の両方を止めるには、SendMessageとListAgentsを権限のdenyルールに入れます。組織単位で止めるなら、Managed Settingsでdenyルールとrefuseを組み合わせます。ただしSendMessageをdenyにすると、サブエージェントやAgent Teamsへの送信も同時に使えなくなる点に注意します。

06サイト制作・LP制作の並列作業での使い方【実践】

ここからは筆者の実務、まずサイト制作・LP制作の並列作業での使い方を、手順の粒度で紹介します。制作では、共通のCSSや型定義を複数人（複数セッション）が同時に触りやすく、片方の変更がもう片方を崩す事故が起きがちです。ここをメッセージングで縮めます。

①フロントとスタイルを別セッションで並行して直す

1枚のLPを直すときでも、マークアップを直すセッションと、共通スタイル（例：assets/style.css）を整えるセッションを分けると速く回ります。名前を役割で付けておきます。

# ターミナルA：マークアップ担当
claude --name lp-markup

# ターミナルB：共通スタイル担当
claude --name lp-style

スタイル側でクラス名やブレークポイントを変えたら、マークアップ側へその一言を送らせます。

lp-markupのセッションに、
.hero の余白クラスを .hero--lg にリネームしたと伝えて

マークアップ側は古いクラス名のまま書き進めず、変更を受けて追随できます。人が両方の差分を見比べる前に、崩れの芽を潰せるのが利点です。

②worktreeで複数ページを同時に組む

コーポレートサイトのように複数ページを同時に作るときは、ページごとにgitのworktreeを分け、それぞれにセッションを立てると衝突しません。共通ヘッダーやフッターを触ったセッションから、他ページのセッションへ「共通パーツを更新した」と流します。

実際の頼み方

# 共通ヘッダーを直したセッションで
他のページを組んでいるセッションに、
共通ヘッダーのナビ構造を変えたので取り込むよう伝えて

渡るのはテキストだけなので、実際のマージやファイル取り込みは各セッションが自分の権限の範囲で行います。「変わったよ」という合図を配るのがこの機能の役割で、危険な操作まで肩代わりはしません。制作案件では、破壊系コマンドは各セッションのdenyで止めておく前提で使うのが安全です。権限設計の基本はClaude Codeプランモードの使い方もあわせてご覧ください。

07自社ツール開発・自動化での使い方【実践】

次は、効率化のための自社ツール開発・自動化での使い方です。この記事では記事を自動publishする無人運用を回しており、その経験から、無人ワーカー同士の連絡にこの機能を組み込む勘所を設定値まで落として紹介します。

①ヘッドレスのワーカーにメッセージを受け取らせる

claude -pで起動したヘッドレスセッションも、通常のセッションと同じく受信用のソケットを持ち、一覧に現れます。ただしヘッドレスは承認ダイアログを出せないため、既定のままだと保留されたメッセージは届きません。無人ワーカーに受信させたいときは、起動時の--settingsでcrossSessionInboundをacceptにします。

claude -p "検証タスクを待機" \
  --name verify-worker \
  --settings '{"crossSessionInbound":"accept"}'

これで、監督役のセッションから「検証を走らせて」と送ると、ヘッドレスワーカーが受け取って動けます。ユーザー設定にacceptを入れても同じ結果になりますが、その場合はあなたが起動する全セッションに適用される点に注意します。

②hooksやスクリプトからセッションへ投げ込む

各セッションは受信用のソケットを持ち、そのパスは環境変数CLAUDE_CODE_MESSAGING_SOCKETとしてhooksやBashコマンドに渡されます。/statusのPeer address行でも確認できます。これを使うと、フックやスクリプトから自セッションへ結果を投げ込む運用が組めます。

自動化に組み込むときの注意

自分の子プロセス（フックやBashコマンド）からの投げ込みは、既定の判定で自セッションへ届きます。ただしコンテナ内でClaude CodeがプロセスID 1として動く場合は送信元の検証ができず、権限プロンプトをスキップするセッションでは承認のために保留される、という挙動になります。無人運用では、この検証可否とOS差（Linuxは終了済みの子でも検証可、macOSは実行中のみ）を踏まえて設計します。

③メッセージのループを恐れなくてよい理由

2つのセッションが延々と返信し合う無限ループは、仕組み側で止まります。Claude Codeは送信元ごとに繰り返しをレート制限し、短時間に届いた同一メッセージを破棄し、読み待ちのメッセージは1セッションあたり50件で頭打ちにします。この上限のおかげで、自動化に組み込んでもメッセージの応酬が暴走しにくい設計です。自動実行の詳しい前提は非エンジニアのClaude Codeスラッシュコマンド12選でも触れています。

08導入前に確認すること｜対応条件と制限

使い始める前に、自分の環境が対応しているかを確認します。条件を満たさないと、そもそも機能自体が現れません。

対応バージョンとOS

セッション間メッセージングはv2.1.224以降が必要で、macOSとLinux（WSL 2内のLinuxを含む）で動きます。ネイティブのWindowsでは提供されていません。まずclaude --versionでバージョンを確認し、古ければclaude updateで更新します。

claude --version   # v2.1.224 以上か確認
claude update      # 古ければ更新

使えない環境と条件

あります。Amazon Bedrock、AWS上のClaude Platform、Google CloudのAgent Platform、Microsoft Foundryといったプロバイダ経由では利用できません。またCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICやDISABLE_TELEMETRYなど、機能フラグの評価を止める環境変数が設定されていると、この機能はオフのままになります。導入できないときは、まず/list-agentsが認識されるかを見て、コマンド自体が無効ならバージョンから、コマンドは通るのに届かないなら受信側の設定やdenyルールから切り分けます。

同じマシンの外へは自動では出ない

同一マシン内の通信は、各セッションがディスク上のファイルとソケットで互いを見つけて成立し、Anthropicのサーバーを経由しません。コンテナは独自のファイルシステムを持つため、コンテナ内のセッションとホストのセッションは互いに到達できません。マシンをまたぐのはRemote Control接続時の返信だけで、しかもこちらから会話を開始することはできない点は、設計上の制限として押さえておきます。

FAQよくある質問

09まとめ：まず名前を付けて片方向から試す

Claude Codeのセッション間メッセージングは、別々に立てた独立セッション同士がSendMessageとListAgentsでテキストを送り合う機能で、v2.1.224以降のmacOS/Linuxなら追加設定なしで使えます。渡るのはテキストだけ、別セッションの指令は承認にならない、という安全側の設計が土台にあります。最初の一歩は、並行して動かすセッションに--nameで役割の分かる名前を付け、片方の変更を「もう片方に伝えて」と頼む片方向の使い方から始めることです。慣れたらcrossSessionInboundやisolatePeerMachinesで受信と越境の制御を詰めていくと、並列開発の連絡が安全に自動化できます。関連して、権限まわりの前提はClaude Code 権限バイパスとは？、拡張の全体像はClaude Codeプラグインの使い方もあわせてご覧ください。

10出典

• Anthropic「Claude Code Docs — Message your other Claude Code sessions（cross-session messaging）」（機能仕様・設定値を筆者が確認）
• Anthropic「Claude Code CHANGELOG」（v2.1.224の追加項目を筆者が確認）