Claude Code @メンションでセッション間の連携を制御する

「別ターミナルで動いているセッションに、スキーマ移行が終わったことを伝えて」と頼む代わりに、@と打って宛先の名前を選ぶだけで済むようになりました。Claude Codeはv2.1.232で、プロンプト中の@メンションから直接SendMessageを呼び出す入力方式に対応しています。

セッション間でSendMessageを使う基本的な仕組みとv2.1.224のクロスマシン対応は別記事で扱いました。本稿は、@メンション入力・同名セッションの自動解決・受信側の制御設定という、v2.1.232前後に追加された機能を掘り下げます。hookやBashコマンドから受信箱ソケットへ直接書き込む方法は別記事にまとめました。

送ったのに届かないときは何を疑うか

セッション間メッセージングで困るのは、送った側から見て何も起きないときです。原因は送信側・受信側・経路の3か所に分かれ、確認する順番もほぼ決まっています。

最初の分岐は/list-agents(別名/peers)が使えるかどうかです。コマンドが認識されないなら、そのセッションにはメッセージング自体がありません。claude --versionでバージョンを確認します。macOS・Linux(WSL 2内を含む)はv2.1.224以降、ネイティブWindowsはv2.1.234以降が必要です。手元のv2.1.287ではclaude --versionが2.1.287 (Claude Code)と表示されました。

/list-agentsが動くのに届かないときは、次の表で原因を絞れます。

古いクラウドセッションや他マシンのセッションが一覧に出ないこともあります。Claude Codeは一覧を新しい順に読み、一定のページ数で止めるため、そこから外れたセッションは名前では指定できません。

コンテナ内のセッションとホストのセッションは互いに届きません。WSL 2内のセッションと、同じPC上のネイティブWindowsのセッションも同じです。同一コンテナ内の2セッションは通常どおり送り合えます。

@メンションで宛先を名指しする

@に続けてセッション名の頭文字を数文字打つと、Claude Codeが候補をタイプアヘッド(入力補完)で示します。サブエージェントを@で明示的に呼び出すのと同じ入力方式です。

Let @api-worker know the schema migration finished

Claudeは宛先を一覧で探さずにSendMessageを呼べます。

候補に出ないセッションが2種類あります。1つは他マシンやクラウドのセッションで、Claudeが一度それらを一覧するかメッセージを送った後でないと候補に現れません。先にClaudeへ一覧を頼む必要があります。もう1つは、名前にスペースや、英数字・ハイフン・アンダースコア以外の文字が入っているセッションです。@"release notes"のように二重引用符で囲んで打ちます。候補から選べば引用符は自動で入ります。

ピッカーを使わず、メンションを直接タイプしても構いません。メンションした名前に複数の稼働中セッションが答える場合、Claudeは送る前にどれを指すかを確認します。

メンションを含む本文を受け取った側は、@付きのファイルやMCPリソースを添付として受け取りません。書かれたとおりの文字列として見え、Claudeが自分のツールで開きに行くだけです。そのため、送る側が@src/schema.sqlと書いても、受信側のClaudeにファイルが渡されるわけではありません。

同名セッションはどう解決されるか

v2.1.232より前は、同じ名前のセッションが複数あっても調整されず、どちらも同じ名前を保っていました。v2.1.232からは、起動・再開・リネームで名前が重なると、先に使っていたセッションが名前を保ちます。あとから来た側にはauth-refactor-graceful-unicornのような2語の接尾辞が付きます。その旨は通知されます。気に入らなければ/renameで付け直せます。

ただし、次の場合は重複を避けません。

• 片方が古いバージョンのClaude Codeで動いている
• 名前がClaude Codeの自動生成した名前や、既定の表示名である
• バックグラウンドや-pのセッションを、起動時に--nameで名付けた

名前は--nameフラグでも付けられます。v2.1.287のclaude --helpには-n, --name <name>が出ます。説明は「Set a display name for this session」で、表示先はプロンプト欄・/resumeのピッカー・ターミナルのタイトルです。宛先に使われる名前もこの表示名です。

宛先の解決は2通りです。名前に答えるセッションが1つなら、名前だけで届きます。複数あるときや、全セッションを確認しきれなかったときは、Claudeが一覧の各行に短い識別子を付け、識別子込みで宛先を指定します。/list-agentsはRemote Controlに接続していない間、各ローカルセッションの作業ディレクトリを表示します。同名でもディレクトリで見分けられます。

Remote Controlに接続している間は事情が変わります。作業ディレクトリ、人に帰属できないセッション名、自分自身の名前の行が出力から省かれ、名前が無い行は(unnamed session)と表示されます。自分の名前の行は、この端末で--nameか/renameで付けた名前なら省かれません。省いたことは出力末尾の注記で分かります。Claude自身が宛先を探すときに見える情報は、この省略で変わりません。

受信側の制御 — crossSessionInbound

届いたメッセージの結末は3つです。受信側のセッションが、メッセージごとに自分の制御と照らして決めます。

値はcrossSessionInbound設定で選べます。/configの「Messages from your other sessions」行からも選べます(v2.1.232以降)。この行はユーザー設定へ書き込みます。managed settingsや--settingsフラグが値を設定している間は表示されません。/config crossSessionInbound=値の省略形は受け付けられません。

どの値も適用されないときは、送受信双方の権限モードから既定の挙動が決まります。bypassPermissionsのセッションを1つのクラス、それ以外を別のクラスとして扱います。bypass可能な対話端末ではplanモードが前者に入り、auto・acceptEdits・dontAskは後者です。

• 受信側がプロンプトで確認するモード: 基本的に配信される。送信側が自分をbypassと名乗ったときだけ保留
• 受信側がバイパス系のモード: 基本的に保留される。送信側もbypassと名乗ったときだけ配信

既定で保留されたメッセージは、受信側に承認ダイアログとして出ます。ダイアログには送信者とプレビューが表示されます。承認でそのメッセージが配信され、拒否または閉じると破棄されます。dialogExpiryの期限(既定5分)を過ぎると自動で閉じて破棄されます。バックグラウンドセッションに端末がつながっていない間は期限が延びます。アタッチしたあと、まるまる1期限ぶん未回答だと破棄されます。保留は最大100件で、超えると古いものから捨てます。

-pの非対話セッションも受信箱ソケットを持つので、長時間動くワーカーとして一覧に出ます。ただし承認ダイアログを出せません。既定で保留されたメッセージはdialogExpiryと同じ期限だけ保持され、期限内にモードや設定の変更で配信可能になれば届き、過ぎれば破棄されて送信元に期限切れが伝わります。dialogExpiryを"never"にするとセッション終了まで保持します。明示のholdで保留された分は期限切れになりません。無人のワーカーに受け取らせたいなら、起動時の--settingsでcrossSessionInboundをacceptにします。--bareで起動したセッションはソケットを持たず、一覧にも出ません。

不正な値を書いた場合も挙動があります。v2.1.248で、crossSessionInboundの不正値は黙って無視されなくなりました。警告が出て、ユーザー設定ならメッセージを保留し、managed settingsなら拒否します。

メッセージが実際に届くまでの経路

自分から他マシンのセッションへ会話を始めるにはv2.1.225以降が必要で、それより前は返信しかできませんでした。送る側がRemote Controlへ接続していないと、メッセージ自体は通りますが返信先の情報が付かず、受信側は返信できません。

Amazon Bedrock、AWS版のClaude Platform、Google CloudのAgent Platform、Microsoft Foundryの経由でも送り合えます。ただし同じマシン上のセッション同士に限ります。条件はv2.1.248以降です。これらの経由やAPIキーでは、他マシンやクラウドのセッションは見つかりません。他マシンを探すにはclaude.aiのサインインでRemote Controlに接続する必要があります。

配信されたメッセージは、利用者が打つプロンプトと同じく使用量にカウントされます。受信側のClaudeはツール呼び出しの合間に読むので、実行中のツールは割り込まれません。アイドル状態なら新しいターンとしてすぐ処理されます。

受け取った側の画面には、メッセージが薄い1行のプレビューで出ます。送信者名と本文の1行目が› Message from @api-worker: Schema migration finished (ctrl+o to expand)の形で並びます。長ければ…で切られます。全文はCtrl+Oのトランスクリプトビューか、--verboseで起動したセッションで見られます。プレビューは表示だけの省略で、Claudeは常に全文を読みます。この表示はv2.1.247で入りました。

長い作業の完了を待つ — notify_when_idle

もう1つ、メッセージとは別に使える仕組みがあります。別セッションが次にアイドルになるか終了した時点で、通知を1回返してもらう機能です。アイドルとは、ターンを終えてキューが空の状態を指します。v2.1.236以降で、送る側と受ける側の両方に必要です。

依頼文は次のように書きます。

Tell me when the migration session finishes what it's working on

ClaudeはSendMessageのnotify_when_idle入力で購読します。単独で購読すると、監視される側のセッションではターンもトークン消費も起きません。対象がすでにアイドルなら通知はすぐ返ります。メッセージに添えた場合は、メッセージが先に届き、通知はあとから届きます。変更履歴では、この機能はmacOSとLinux向けと書かれています。

12時間たっても通知が来なければ、購読は破棄されてClaudeに伝わります。受信制御は通知にも効きます。どちらかの側がrefuseなら何も届きません。依頼する側がrefuseだと、そもそも購読しません。監視される側が購読要求を記録も返答もせずに捨てるので、購読は12時間後に無応答のまま期限を迎えます。どちらかがholdなら通知は簡略になります。監視される側は1行の状況を省き、依頼した側は通知を画面に出すだけでClaudeには渡しません。購読できるのはメイン会話のClaudeで、対象は同じマシンの自分のセッションだけです。チームメイト、サブエージェント、他マシンのセッションを対象にすると、添えたメッセージごと呼び出しが拒否されます。

権限と送信の制御

他セッションからのメッセージは同意にならない

他セッションから届いたメッセージは、送信者がどんな権限モードで動いていても、ユーザー自身の同意としては扱われません。保留中の権限確認をメッセージで通すことはできず、CLAUDE.mdや権限設定を書き換えさせることもできません。本文中の/compactのようなコマンドは単なる文字列で、実行されません。メッセージが頼む作業に必要な権限が受信側に無ければ、通常と同じ確認が出ます。

送る側のClaudeも、自分のセッションで拒否された操作や、自分の権限設定が止める操作を、他セッションに頼まないよう指示されています。

isolatePeerMachinesで他マシンへの送信を止める

他マシンへ送る前に必ず承認を挟みたいなら、isolatePeerMachinesをtrueにします。

{
  "isolatePeerMachines": true
}

bypassPermissionsモードでも、他マシンやクラウドへの送信は承認を求められます。どの設定スコープからのtrueも有効なので、リポジトリに入れたプロジェクト設定でオンにはできても、オフには戻せません。同じマシン内のメッセージは対象外です。

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

受信を止めるのはcrossSessionInbound: "refuse"、送信と一覧を止めるのはSendMessageとListAgentsのdenyルールです。組織全体で両方を止めるときは、managed settingsに次を置きます。

{
  "permissions": {
    "deny": ["SendMessage", "ListAgents"]
  },
  "crossSessionInbound": "refuse"
}

この設定でも受信箱ソケットは各セッションで作られ、届いたメッセージを捨てるだけです。SendMessageをdenyするとサブエージェントやagent teamのチームメイトへの送信も消えます。同じツールがその用途も担うためです。

refuseのセッションは、自身の/statusにも、同じマシンの他セッションの一覧にも変化が出ません。確認するには状態表示ではなく、そのセッションに適用される設定ファイルを見ます。

メッセージが拒否される場面と上限

送信側で止まるものがあります。

• 同じマシンの宛先へ、サイズが約100万文字(シリアライズ後)を超えるメッセージ
• 同じマシンの宛先への短時間の連投が、受信箱の許容量に達したとき
• 一覧でcan't receive cross-session messagesと出ている他マシンのセッション
• 返信先が安全確認に失敗したとき(シンボリックリンクなど)

理由はSendMessageの結果に出ます。連投の拒否はv2.1.236で、サイズ超過はv2.1.235で、黙って捨てる挙動から送信時の明示拒否に変わりました。

ループは受信側で止まります。同じ送信者からの繰り返しはレート制限され、短い間隔で届いた同一内容は破棄され、Claudeが読む前に溜まった分は50件で頭打ちです。互いに返信し続けるループは自然に止まります。

送れるのはプレーンテキストだけです。agent teamの構造化プロトコルのメッセージはチーム内に限られます。セッションの内容やファイルは運べません。会話ごと引き継ぎたいなら/resumeコマンドで再開します。

宛先の指定は何から何へ移ったか

v2.1.232より前は、宛先を名指しするには自然文で頼み、ClaudeにListAgentsで探させる手順が必要でした。@メンションはその手順を1ストロークにします。重複名の自動解決は、名指しした宛先が意図と違うセッションに届く事故を減らします。

その後の変更は、Not sentの理由表示、同じマシン宛てのrefusedの報告、連投の事前拒否と、黙って捨てていた場面の洗い出しが続いています。宛先を決める作業が、拡張から精度を詰めるフェーズに入ったと読めます。holdにも手当てが入っています。保留されたメッセージが痕跡を残さなかった問題は、ヘッドレスの送信側へ配信通知を返す形で直されました。

まとめ

宛先は@で1ストロークで指せますが、届くかどうかは受信側のcrossSessionInboundと権限モードの組み合わせで決まります。無人のワーカーに受けさせるならacceptを明示し、他マシンへの送信に承認を挟みたいならisolatePeerMachinesを使う、という分担です。宛先を見つける画面はagent viewにあります。全体像はClaude Code完全ガイドにまとまっています。