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

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

セッション間でSendMessageを使う基本的な仕組みとv2.1.224のクロスマシン対応は別記事で扱いました。本稿は、@メンション入力・同名セッションの自動解決・受信側の制御設定という、v2.1.232前後に追加された3つの機能に絞って掘り下げます。

背景

Claude Codeのセッション間メッセージングは、v2.1.224でクロスセッション対応が入ってから、宛先の指定方法と受信側の制御が段階的に整備されてきました。

セッション間メッセージングが動くのはmacOSとLinux(WSL 2内を含む)で、ネイティブWindowsでは提供されません。Amazon Bedrock、AWS版のClaude Platform、Google CloudのAgent Platform、Microsoft Foundry経由でも利用できません。

この一連の変更が示しているのは、宛先の指定と受信可否の判断を、Claude任せから利用者が直接操作できる形へ寄せる方向です。

@メンションでセッションを名指しする

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

Let @api-worker know the schema migration finished

Claudeはこのメンションを@api-workerという形でプロンプトに挿入し、それがどのセッションを指すかを把握したうえでSendMessageを呼びます。宛先の一覧を先に確認する必要はありません。

@のあと1文字も入力していない段階では候補は出ず、1文字以上打つと同一マシン上の他セッションが候補に並びます。クラウドセッションやRemote Control越しの他マシンセッションは、このセッションがすでに一度それらを一覧するかメッセージを送った後でなければ候補に出ません。ピッカーを使わず、メンションを直接タイプすることもできます。

メンションした名前に複数の稼働中セッションが答える場合、Claudeは送る前にどのセッションを指すかを確認します。

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

v2.1.232より前は、同じ名前を持つセッションが複数あっても特に調整はありませんでした。v2.1.232からは、この状況で自動解決が入ります。起動またはリネームしようとした名前を、同一マシン上の別の稼働中セッションがすでに使っている場合、名前は先に使っていたセッション側に残ります。あとから来た側にはname-word-word形式の別名が振られ、その旨が通知されます。

ただしこの重複回避は絶対ではありません。片方が古いバージョンのClaude Codeで動いている、または名前自体がClaude Codeの自動生成名である場合には、同名のまま共存することがあります。/list-agentsの出力には各セッションの作業ディレクトリが表示されるため、名前が重複していてもディレクトリで区別できます。

宛先解決自体も2パターンです。名前に応答するセッションが1つだけならその名前だけで届き、複数(または全セッションを確認しきれなかった場合)は、一覧の各行に短い識別子が付き、その識別子込みで宛先が指定されます。

受信側の制御 — crossSessionInbound

届いたメッセージをどう扱うかは、crossSessionInbound設定で選べます。

/configの「Messages from your other sessions」行からも選べます(v2.1.232以降)。この行はmanaged settingsや--settingsフラグが値を設定している間は表示されません。

どの値も適用されないときは、送受信双方の権限モードから既定の挙動が決まります。bypassPermissions(および利用可能な場合のplanモード)を1つのクラス、それ以外のauto・acceptEdits・dontAskを別のクラスとして扱います。受信側がプロンプトで確認するモードなら基本的に配信、受信側がバイパス系モードなら基本的に保留という判定です。

保留されたメッセージは承認ダイアログとして表示され、dialogExpiryの期限(既定5分)内に応答しないと自動的に破棄されます。ただしバックグラウンドセッションにターミナルが接続されていない間は期限が延長され、アタッチしてから改めて期限が計測されます。保留できるメッセージは最大100件で、それを超えると古いものから破棄されます。

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

宛先セッションがどこで動いているかによって、メッセージの経路は変わります。

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

配信されたメッセージは、利用者が打ち込んだプロンプトと同じように使用量へカウントされます。受信側のClaudeはツール呼び出しの合間にメッセージを読むため、実行中のツールが割り込まれることはなく、アイドル状態なら新しいターンとしてすぐ処理されます。受け取ったClaudeは送信元へ返信できますが、返信先の情報が付かない片方向のクロスマシンメッセージだけは例外です。

Bashコマンドやフックが自分のセッションのソケットへ書き込む「own-child」メッセージは、通常の他セッションからのメッセージとは別扱いです。検証方法は環境で変わります。Linux(WSL 2含む)ではプロセスの親子関係で検証でき、macOSでは投稿元プロセスが生きている間だけ検証できます。コンテナ内でClaude CodeがPID 1として動く場合はプロセス証拠が一切ないため、いずれもCLAUDE_CODE_MESSAGING_TOKENという認証トークンでの検証に切り替わります。サンドボックス化されたBashコマンドがこのソケットに届くかどうかは、サンドボックスのUnixソケット設定で別途制御します。

@メンションは何を変えたか

@メンション・重複名の自動解決・crossSessionInboundの/config行という3つの追加は、同じ利用者体験の欠落を埋めています。それは「宛先と受信可否を、Claudeの判断に委ねるしかなかった」という欠落です。

v2.1.232以前もSendMessage自体は使えましたが、宛先を名指しするには自然文で頼み、ClaudeがListAgentsで探すという間接的な手順が必要でした。@メンションはこの間接性を1ストロークで飛び越えます。同時に入った重複名の自動解決も、名指しした宛先が意図と違うセッションに届く事故を防ぐ設計です。

v2.1.234で修正された「200文字上限や絵文字を含む名前で宛先解決に失敗する」バグと、「アカウントのセッション一覧が多すぎて確認しきれないときは不在扱いにせずその旨を伝える」という改善も、同じ方向の仕上げです。宛先を名指しする体験の精度を上げる修正が連続している点は、この機能がクロスマシン対応の拡張フェーズから、日常的な指名の正確さを詰めるフェーズへ移ったことを示しています。

運用でつまずきやすい点

他セッションからのメッセージが権限を通過すると誤解する

他セッションから届いたメッセージは、送信者がどんな権限モードで動いていても、ユーザー自身の同意としては扱われません。保留中の権限確認をエージェント間のメッセージで通過させることはできず、CLAUDE.mdや権限設定を書き換える権限もありません。

isolatePeerMachinesを設定し忘れる

他マシンへのメッセージ送信前に必ず承認を挟みたい場合はisolatePeerMachinesをtrueにします。設定しない既定のままだと、bypassPermissionsモードのセッションから他マシンへ承認なしにメッセージが飛ぶことがあります。

メッセージのやり取りがループする

2つのセッションが互いに返信し続けるループは、Claude Codeが自動的にスロットルします。同じ送信者からの繰り返しはレート制限され、短い時間内に届いた同一内容の繰り返しは破棄され、Claudeが読む前に溜まったメッセージも1セッションあたり50件で頭打ちになります。

crossSessionInboundを切り替えても過去の保留分が動かないと思い込む

権限モードの変更などでこの区分自体が切り替わると、保留中のメッセージは再判定され、新しい区分で配信可能になったものはまとめて配信されます。refuseが適用されるようになった場合は、保留中の全メッセージが破棄され、届けられる送信元には拒否が通知されます。

よくある質問

@メンションはどのバージョンから使えますか?

v2.1.232以降です。セッション間メッセージング自体はv2.1.224以降で有効になっています。

同名のセッションが残るのはどんなときですか?

片方が古いバージョンのClaude Codeで動いている場合と、両方の名前がClaude Codeの自動生成名である場合です。/list-agentsの作業ディレクトリ表示で見分けられます。

crossSessionInboundはプロジェクト設定でも上書きできますか?

プロジェクトやローカル設定からのrefuseは他のどの設定よりも優先されます。ユーザー設定からの値は、managed settingsや--settingsフラグが値を設定していない限り適用されます。

-pのような非対話セッションでも保留ダイアログは出ますか?

出ません。-pセッションは承認ダイアログを表示できないため、dialogExpiryと同じ期限の間だけ保留されます。期限内にモードや設定の変更で配信可能になれば届き、そうでなければ破棄されて送信元に期限切れが伝えられます。

まとめ

@メンション・重複セッション名の自動解決・crossSessionInboundの/config行は、いずれもv2.1.232でまとまって入った変更です。宛先を1ストロークで名指しできるようになった一方、受信側はaccept・hold・refuseのどれを選ぶかで挙動が大きく変わります。複数セッションを日常的に並走させるなら、crossSessionInboundとisolatePeerMachinesを自分の運用に合わせて明示しておく価値があります。宛先そのものを見つける画面はagent viewにもあるので、合わせて確認してください。