2026/08/11Claude Code

AIエージェントAI活用非エンジニア向け

Claude Codeのセッション間メッセージング｜使い方と設定

「別のターミナルで動かしているAIに、こっちで分かったことを伝えたい」「同じ内容を2回説明するのが面倒」——複数のセッションを並走させていると、誰でもこの手間に突き当たります。

結論から言うと、Claude Code にはセッション同士がメッセージを渡し合う機能があり、条件を満たしていれば設定なしで使えます。ただし渡るのはテキスト1本だけで、会話履歴もファイルも渡りません。この性質を知らずに使うと「伝えたつもりが伝わっていない」が起きます。

株式会社Fyveは日常的に複数のセッションを並走させて業務を回しており、この記事では公式ドキュメントの仕様と、実際に自分の環境で26セッションを並べてみて分かった運用の勘所の両方をお伝えします。

Claude Codeのセッション間メッセージングとは何か

セッション間メッセージング（cross-session messaging）は、あるClaude Codeセッションから別のClaude Codeセッションへメッセージを届ける機能です。

これまで、片方のターミナルで分かったことを別のターミナルに伝えるには、人間がコピー＆ペーストで運ぶしかありませんでした。この機能があると、Claudeが自分で相手を見つけて文面を書いて届けてくれます。

頼まなくてもClaudeの判断で送ることがあります。あるセッションが加えた変更が、別のセッションが作っているものを壊す場合に、気づいた側から先に警告が飛ぶ、という動きです。もちろん「あっちのセッションに聞いてきて」と自分から頼むこともできます。

公式が挙げている4つの使いどころ

発見の受け渡し：片方が破壊的な変更や設計上の判断に気づいたとき、影響を受ける側のセッションに要約して伝える
並列作業の調整：同じリポジトリを別々の作業ツリーで触っているセッション同士に、何が取り込まれたかを伝える
長時間かかる処理の状況報告：データ移行やテスト実行に、見ている側のセッションへ報告させる。逆にこちらから問い合わせる
マシンをまたぐ連絡：別のパソコン上のセッション、あるいはWeb上の自分のセッションに届ける

どれも共通しているのは「片方のセッションが持っている情報を、もう片方が今すぐ必要としている」場面だということです。逆に言えば、あとで自分が読めばいい情報をわざわざ送る必要はありません。

いちばん大事な性質：渡るのはテキスト1本だけ

ここが機能の性格を決めている部分です。受け取る側に渡るのは、送信者の名前・本文のテキスト・返信先の3点だけです。送った側の会話履歴もファイルの中身も、一切渡りません。

だから「会話をまるごと引き継ぎたい」「今の文脈ごと別のターミナルで続けたい」という用途には向きません。それはセッションの再開（resume）という別の機能の仕事です。

公式ドキュメントには、実際に届いたメッセージの例が載っています。

「スキーマ移行が完了しました。新しい列は tenant_id で、main へのリベースはもう安全です」

この程度の分量です。長い報告書ではなく、短い伝言だと考えると実態に近くなります。

セッション間で渡るのはテキスト1本だけ。送信者の名前・本文・返信先の3点は渡るが、会話履歴・ファイルの中身・これまでの経緯は渡らない

使えるかどうかを最初に確かめる

この機能は「オンにする操作」がありません。条件を満たしていれば勝手に有効になっており、満たしていなければ何をしても使えません。だから最初にやるのは設定ではなく確認です。

前提条件

Claude Code v2.1.224 以降が必要
別のパソコン上のセッションへ、こちらから会話を始めるのは v2.1.225 以降。それより前は、向こうから届いたメッセージに返信することしかできませんでした
macOS と Linux のみ（Windows上のWSL 2の中のLinuxを含む）。ネイティブのWindowsでは使えません
Amazon Bedrock、Claude Platform on AWS、Google Cloud の Agent Platform、Microsoft Foundry の各プロバイダ経由では使えません

加えて、機能フラグの評価を止める環境変数が設定されていると、この機能もオフになります。該当するのは CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC、DISABLE_TELEMETRY、DO_NOT_TRACK、DISABLE_GROWTHBOOK の4つです。シェルの設定、設定ファイルの env、管理者が配布した設定のどこから来ていても効きます。

確認は2つのコマンドで足りる

/list-agents（別名 /peers）を打ちます。ここで挙動が2つに分かれ、原因の切り分けができます。

コマンドが認識されない：そのセッションに機能自体がありません。まず claude --version でバージョンを確認します
コマンドは通るのにメッセージが届かない：機能はあります。原因はもっと手前で、権限の拒否ルール・受信側の設定・相手の所在のいずれかです

もう1つ、/status に Peer address という行が出ていれば有効です。ここには自分の受信アドレスが表示されます。

読者特典・無料ダウンロードClaude Codeを「素のまま」使うな無料でダウンロード →

実際の使い方

Claudeは ListAgents と SendMessage という2つの道具を使ってこれを実現しています。前者が「届く相手を一覧する」、後者が「名前を指定して届ける」役です。

ただしこの2つを自分で呼ぶことはありません。普通の日本語で頼めば、Claudeが相手を探して文面を書いて送ります。

頼み方の例

次のように書きます。これはClaudeに打つプロンプトであって、送られるメッセージ本体ではありません。

「別のターミナルで動いているセッションに、データ移行が終わったか聞いてください」
「今やったことを、決済まわりを触っているセッションに説明しておいてください」

文面はClaudeが書くので、こちらが一字一句決める必要はありません。「何を知らせたいか」「何をしてほしいか」だけ伝えれば足ります。

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

メッセージの宛先はセッションの名前です。名前は /rename コマンド、または起動時の --name で決まります。

付けなかった場合はClaude Codeが作業ディレクトリのフォルダ名から自動で作ります。myapp-3f のような、フォルダ名に2文字足した形です。

名前は重複しえます。/list-agents は各セッションの作業ディレクトリを併記して見分けられるようにしており、Claude側の一覧では短い識別子を足して宛先を一意にしています。

届いたメッセージはどう見えるか

会話の中に送信者名つきで表示されます。Claudeが読んだあとは Message from という1行に畳まれ、Ctrl+O で展開できます。

読まれるタイミングは受信側の状態で変わります。相手が作業の途中なら、道具の呼び出しの合間に読みます。実行中の処理が中断されることはありません。相手が何もしていない状態なら、そのメッセージで新しい作業を始めます。

26セッションを並べてみて分かったこと

ここからは自分の環境での実測です。2026年8月12日に /list-agents を実行したところ、26セッションが宛先として見えました。

同じパソコン上のローカルセッション：15本。全て作業ディレクトリが同一。14本が待機中、1本が入力待ち。起動から18時間経過が13本、11時間が1本、1時間が1本
別のパソコンのセッション：11本。1本が接続待ち、10本が待機中。作業ディレクトリの欄は表示されません

この一覧を見て分かったことが3つあります。仕様には書いていない、運用側の話です。

名前を付けていないと見分けられない

ローカルの15本は、自動生成の名前（フォルダ名＋2文字）と、自分で付けた意味のある名前が混在していました。

自動生成名は一覧の中で区別がつきません。しかも作業ディレクトリの併記も助けになりませんでした。15本すべてが同じディレクトリで動いていたからです。単一のリポジトリで作業する使い方だと、この併記は機能しません。

つまり、複数セッションを日常的に並走させるなら、起動時に名前を付ける習慣が実質的な必須条件になります。「AIに宛先を探してもらう」以前に、人間が宛先を指定できる状態でないと指示自体が書けません。

畳まないと一覧が読めなくなる

起動から18時間経った待機中のセッションが13本残っていました。使い終わったセッションを閉じないまま次を開いていくと、宛先の一覧がこうなります。

宛先を探すのはClaudeですが、その候補が26本あって大半が用済みだと、正しい相手に届く確率が落ちます。セッションを畳む運用は、画面の整理ではなく宛先の精度の問題だと考えた方が実態に合います。

別マシンのセッションは名前しか手がかりがない

別のパソコンのセッションは、作業ディレクトリが表示されません。どのマシンのどのリポジトリなのかは名前からしか判断できません。

ここでも命名が効きます。ローカルは最悪ディレクトリで見分けられますが、別マシンにはその逃げ道がありません。

効く場面と、効かない場面

ここが「機能を知っている」と「使える」の差が出るところです。渡るのがテキスト1本だけという性質から、設計上の制約がいくつも導かれます。

素材はファイルで渡し、メッセージはポインタだけにする

調査結果や仕様を本文に詰め込む設計は破綻します。テキスト1本しか渡らないので、長くなるほど欠落と誤読が増えます。

同じパソコン上のセッション同士はファイルシステムを共有しています。だから次の2段構えにします。

素材は先にファイルとして保存する
メッセージにはファイルの場所と、何をしてほしいかだけを書く

実体はファイル経由で渡り、メッセージは短く保てます。この形にすると、渡す情報量に上限がなくなります。

受信側の文脈はゼロだと考える

会話履歴が渡らないということは、受け取った側はこれまでの経緯を何も知らないということです。「さっきの件」「例のファイル」「前回と同じように」は一切通じません。

先日、別のセッションから作業の指示が1本届きました。本文に入っていたのは、参照すべき素材ファイルの絶対パス、使ってほしい手順の名前、そしてやってはいけないことの3点だけでした。

送り手の側は、この制約を最初から分かって書いていたわけです。「これだけで完結するように書いています」と本文に明記されていました。実際、受け取った側はそれ以外の情報を持っていないので、この書き方でなければ動けません。

つまりメッセージを頼むときは、使ってほしい手順の名前・出力先・やってはいけないことまで1本に書き切る必要があります。ここを省くと、相手のClaudeは善意で埋めようとして、こちらの意図とずれたものを作ります。

マシンをまたぐとファイルの場所が無効になる

別のパソコンのセッションは、ファイルシステムを共有していません。ローカル宛に有効だった「ファイルの場所を書いて渡す」が、そのまま使えなくなります。

別マシン宛に何か渡したいときは、先にリポジトリへ反映して、相手側から実体に辿り着ける状態を作ってから送ります。ここを飛ばすと、相手は存在しないパスを探し続けます。

同じ理由で、コンテナの中と外も互いに届きません。コンテナは自分のファイルシステムを持つためです。同じコンテナの中同士なら届きます。

他の機能と取り違えない

複数のセッションを扱う機能は他にもあり、公式が用途を整理しています。やりたいことが下の表に当てはまるなら、メッセージングではなくそちらを使う方が早いです。

会話を別のターミナルで続けたい／文脈ごと新しいセッションに渡したい：セッションの再開（resume）
Claudeが自分で立てて監督するチームを作りたい：エージェントチーム
たくさんのセッションを1箇所から見て操縦したい：agent view
スマホなどから自分でセッションを操縦したい：Remote Control
CIの結果やチャットなど外部の出来事を流し込みたい：channels

メッセージングが担当するのは、自分で立てて自分で操縦している独立したセッション同士の連絡です。

やりたいことで使う機能が変わる。並走中の相手に情報を渡すならセッション間メッセージング、会話をまるごと引き継ぐならresume、Claudeが監督するチームならエージェントチーム

Claudeが自分でチームを組んで動かす方式については、こちらで詳しく解説しています。

Claude CodeClaude Code Agent Teams｜AIチーム協働術

放置して進めさせるバックグラウンドセッションの使い方は、この機能と組み合わせる前提知識になります。

Claude CodeClaude Codeのバックグラウンドセッション｜放置で進む

届かないときに見る場所

配送は常に保証されるわけではありません。届いたメッセージは受信側の設定で3つの結末に分かれます。

accept：Claudeに配送する
hold：通知だけ出して配送しない。後から accept が適用されると、保留していた分をまとめて解放する
refuse：配送せずに破棄する

この値を明示していない場合、Claude Codeが両セッションの権限モードから1通ごとに判断します。セッションを「権限の確認を飛ばす側」と「確認を出す側」の2つに分けて扱います。

受信側が確認を出すセッション：基本的に配送します。送信側が「自分は確認を飛ばす側だ」と名乗った場合だけ保留して承認を求めます
受信側が確認を飛ばすセッション：基本的に保留して承認を求めます。送信側も飛ばす側のときだけ配送します

保留されると受信側に承認ダイアログが出ます。送信者とプレビューが表示され、承認すればその1通が配送され、拒否または閉じると破棄されます。

無回答のまま dialogExpiry の期限を過ぎると閉じて破棄されます。期限の既定値は5分です。ただしバックグラウンドのセッションにターミナルが接続されていない間は期限を過ぎても開いたままにし、接続後にあらためて期限いっぱい待ちます。

保留しておける数には上限があり、100通です。超えると古いものから捨てられます。

気づきにくい落とし穴が2つある

1つ目。送信側に通知が来るかどうかが場合によって違います。相手が同じパソコンにいて保留された場合は、送信側に通知が出て、その後の配送・拒否・期限切れも追って報告されます。ところが到着した時点で refuse されたメッセージについては、送信側に通知が出ません。送ったつもりで話が進んでしまう形です。

2つ目。拒否設定にしているセッションは、自分の /status にも他のセッションの一覧にも変化が現れません。外から見て「このセッションは受け取らない設定だ」と分かる手がかりがないので、設定ファイルを見ないと判断できません。

「送ったのに反応がない」ときは、相手のClaudeが無視しているのではなく、この2つのどちらかであることが多いです。

届いたメッセージはaccept・hold・refuseの3つの結末に分かれる。値が未設定なら両セッションの権限モードで1通ごとに判断される

無人で動かしているジョブに指示を差し込む

定期実行しているジョブに、外から指示を入れたい場面があります。claude -p で動かしているセッションもこの機能の対象です。

claude -p のセッションも対話セッションと同様に受信の口を開き、一覧にも載ります。長時間動かすジョブがメッセージを受け取れます
ただしbare mode で起動した場合は口を開きません。受信できず、一覧にも載りません

問題は承認ダイアログです。-p のセッションはダイアログを出せません。既定の判断で保留になった場合、ダイアログと同じ dialogExpiry の期限（既定5分）だけ保持され、期限内に設定やモードの変更で許可されなければ破棄されます。

つまり誰も見ていない無人ジョブに指示を送っても、既定のままだと5分で消える可能性があります。

これを避けるには、起動時の --settings の値に crossSessionInbound を accept として入れます。ユーザー設定に書いても効きますが、その場合は自分が動かすすべてのセッションに適用されてしまいます。特定のジョブだけ受け取らせたいなら起動時に指定する方が安全です。

dialogExpiry を "never" にすると、既定の判断で保留されたものをセッション終了まで保持します。なお明示的に hold を設定して保留されたものは、そもそも期限切れになりません。後から accept が適用されたときだけ配送されます。

事故を防ぐ設定

便利な機能ですが、別のパソコンへメッセージが出ていく点は意識した方がいいところです。ここには専用の設定があります。

マシンの外へ出る通信だけ承認を必須にする

isolatePeerMachines を true にすると、このパソコンの外にあるセッション宛のメッセージが出る前に、必ず承認を求めるようになります。

効き方が強いのがこの設定の特徴です。通常の権限確認を飛ばす bypassPermissions モードであっても承認を求めます。そしてどの設定スコープの true も有効なので、チェックインしたプロジェクト設定でオンにすることはできますが、それをオフにすることはできません。

同じパソコン内のメッセージには承認を求めないので、ローカル同士の軽い連絡はそのままの手軽さを保ったまま、外へ出る通信だけ人間のゲートを挟める形になります。並走させるセッションが増えてきたら、まずここから入れるのが実務的です。

受信と送信は別々に止める

止め方は方向ごとに分かれています。

受信を止める：crossSessionInbound を refuse にします。プロジェクト設定・ローカル設定からの refuse は他のあらゆる指定に優先します。ユーザー設定からの refuse は、管理者が配布した設定と起動時の --settings には負けます
送信と一覧を止める：SendMessage と ListAgents を名指しした権限の拒否ルールを足します。どちらも指定子なしのツール名そのままで書きます

ここで注意したい副作用があります。SendMessage を拒否すると、サブエージェントやエージェントチームへの連絡も同時に消えます。同じ道具が両方の役を兼ねているためです。セッション間の連絡だけを止めるつもりで、セッション内の連携まで止めてしまうことになります。

また、両方向を止めても受信の口自体は開かれ続けます。届いたメッセージを配送せずに捨てる、という動きです。

受け取った側でできることは最初から制限されている

これは設定ではなく、機能に組み込まれている性質です。安心材料になるので押さえておくとよい部分です。

セッションAからBへ送ると、Claude CodeはBのClaudeに「これはユーザーではなく別のセッションから来た」と伝え、できることを制限します。

承認の代わりにならない：他セッションからのメッセージはユーザーの同意として扱われません。保留中の権限確認に代理で答えることはできません
設定を変えられない：権限設定や CLAUDE.md を「別のセッションに言われたから」変更してはならないと指示されています
コマンドは実行されない：本文に /compact のようなコマンドが書かれていても、ただのテキストとして届きます
権限確認は通常どおり出る：メッセージに沿って動くのに権限が必要なら、いつもと同じ確認が出ます

送信側にも制約があります。Claudeは、自分のセッションで拒否・ブロックされた行為や、自分の権限設定が禁じる行為を、他のセッションに肩代わりさせてはならないと指示されており、その仕事はユーザーに差し戻します。権限の境界はセッションごとに保たれる設計です。

加えて、メッセージのループは自動で止まります。送信者ごとの回数制限、短時間の同一内容の破棄、そして未読の上限（1セッション50通）の3つが働くため、2つのセッションが延々と送り合う状態は自然に停止します。

この機能を業務で使うかどうかの判断

ここまでの仕様と実測を踏まえて、どういう場合に投資対効果が出るかを整理します。

この機能をきっかけに「そもそもAIに何をどう分担させるか」を考える話は、別の記事で整理しています。本記事は道具の使い方の側、そちらは設計思想の側です。

Claude CodeClaude Codeのセッション連携に学ぶAIの役割分担設計

効くのは「並走させている作業が実際に干渉する」場合

1人〜少人数で複数の作業を同時に進めていて、片方の結果がもう片方に影響する場合に効きます。設計判断が変わった、データの持ち方が変わった、この関数はもう使わない、といった情報は、遅れて伝わるほど手戻りが大きくなります。

逆に、並走させている作業が互いに独立しているなら、この機能の出番はほぼありません。それぞれが終わってから自分が結果を見れば足ります。「複数セッションを使っているから導入した方がいい」わけではありません。

そもそも並列で動かす作業をどう切り分けるかについては、こちらで整理しています。

Claude CodeClaude Codeの並列作業｜自動と手動の使い分け

コストとして意識する点

配送されたメッセージは、自分が打ったプロンプトと同じように使用量を消費します。セッション同士に自由に喋らせると、その分の消費が乗ります。頻繁に細かい連絡をさせるより、要点だけを渡す設計の方が経済的にも合理的です。

まず整える3つ

実測から言うと、機能を有効にする作業は要りません。代わりに次の3つを整えるだけで、使える状態と使えない状態が分かれます。

セッションに名前を付ける：同じディレクトリで並走させるなら、自動生成名では宛先を書けません
使い終わったセッションを畳む：宛先候補が増えると、正しい相手に届く確率が落ちます
渡すものはファイルに置く：メッセージには場所と依頼だけを書きます

どれも設定ではなく習慣の話です。この機能で詰まる原因は、機能そのものより運用の側にあることが多いです。

まとめ

Claude Code のセッション間メッセージングは、条件を満たせば設定なしで使える機能です。並走しているセッション同士で、片方が持っている情報をもう片方へ渡せます。

押さえるべき点をもう一度整理します。

必要なのは Claude Code v2.1.224 以降。別マシンへこちらから会話を始めるなら v2.1.225 以降。macOS と Linux のみで、ネイティブWindowsでは使えません
渡るのはテキスト1本だけ。会話履歴もファイルも渡らないので、素材はファイルに置き、メッセージには場所と依頼だけを書きます
受信側は経緯を何も知りません。手順の名前・出力先・やってはいけないことまで1本に書き切ります
届かないときは相手の受信設定を見ます。到着時に refuse されたものは送信側に通知が出ず、拒否設定は外から見えません
無人の claude -p ジョブに送るなら、起動時の --settings で crossSessionInbound を accept にします。既定のままだと5分で消える可能性があります
事故を防ぐなら isolatePeerMachines を true に。ローカルの手軽さを保ったまま、マシンの外へ出る通信だけ承認を挟めます

そして実測からの結論は、この機能を活かせるかどうかは、セッションに名前を付けて使い終わったものを畳む、という地味な運用習慣で決まるということです。26本の宛先が並んだ一覧を見ると、機能の性能より先にそこが効いていると分かります。

本記事の仕様に関する記述は、Claude Code 公式ドキュメントの Message your other Claude Code sessions に基づいています（2026年8月12日時点）。バージョンや既定値は更新される可能性があるため、導入前に一次情報での確認をおすすめします。

この記事を読んでいるあなたへ無料プレゼント