「複数のClaude Codeセッションを連携させるには、実験機能のAgent Teamsを有効化しないと無理」——そう思い込んでいる方が意外と多いようです。実はこれ、2026年8月13日公開のv2.1.232以降は誤解です。Agent Teamsの環境変数を一切触らなくても、同じマシンで動いている通常のClaude Codeセッション同士は、プロンプトで@を打って相手セッションを指名し、SendMessageツールで直接メッセージを渡し合えるようになりました。
さらに同じバージョンで、サブエージェントのforking（会話を丸ごと引き継ぐ分岐）が既定で有効になっています。検証環境で実際に2つのターミナルを並べて試したところ、片方のセッションで「@+セッション名」を入力するだけで、もう片方に調査結果が届く挙動を確認できました。単一セッション内のサブエージェント管理とは別次元の、「セッション同士が会話する」マルチエージェント運用が標準機能になったわけです。公式CHANGELOGと公式ドキュメントを突き合わせながら、変更点と実践手順、ハマりどころを整理していきます。
v2.1.232の変更点を3行で押さえる
公式CHANGELOGのv2.1.232エントリから、今回のテーマに関わる変更を抜き出すと次の3つです（公開日はGitHub Releases APIで2026-08-13T23:29:59Zを確認）。
| 変更点 | 原文の要旨 | 影響 |
|---|---|---|
| subagent forkingの既定化 | 「Subagent forking is now on by default: a subagent_type: “fork” subagent inherits the full conversation and prompt cache」。加えて対話セッションでのエージェント起動は既定でバックグラウンド実行に | 会話全体＋プロンプトキャッシュを引き継ぐ分岐が設定なしで使える |
| @メンションでのセッション指名 | 「Type @ in the prompt to mention another Claude session by name; Claude then uses SendMessage to reach that session directly」 | 別セッションへの連絡が入力補完付きで指名可能に |
| セッション名の一意化 | 既存の稼働セッションと同名を付けると「name-word-word」形式の変種名に自動リネームされ、その旨が通知される | SendMessageの宛先が名前だけで一意に決まる |
あわせてSendMessageは、名前に一致する稼働セッションが1つだけなら確認なしでそのまま配送されるようになり、/configには「Dialog expiry」と「Messages from your other sessions」（受信の accept / hold / refuse 切り替え）の行が追加されています。
forkサブエージェントは何が違うのか
従来のサブエージェントは、まっさらなコンテキストで起動し、親から渡されたプロンプトだけを頼りに作業する仕組みでした。詳しい実装方法はClaude Agent SDKのサブエージェント実装ガイドで扱った通りです。一方、公式ドキュメントによるとforkは「それまでの会話全体を引き継ぐサブエージェント」で、親のシステムプロンプト・ツール・モデル・全メッセージ履歴を継承します。
ポイントはコストです。公式ドキュメントには、forkのシステムプロンプトとツール定義が親と同一であるため、初回リクエストが親のプロンプトキャッシュを再利用でき、新規サブエージェントの起動より安くなると明記されています。「経緯を全部知っている分身に、脇道の調査だけ任せる」使い方が、追加の説明コストなしで成立します。
forkの起動方法は2通りです。
# 方法1: Claudeに任せる（fork型サブエージェントとして自動スポーン）
# 方法2: /subtask コマンドで明示的に分岐（v2.1.212以降）
/subtask この認証バグの再現条件だけ調査して報告して
forkモード自体は環境変数CLAUDE_CODE_FORK_SUBAGENTで制御でき、1で有効、0で無効です。v2.1.232からは既定が有効側になったため、従来挙動（毎回まっさらなサブエージェント）に戻したい場合だけ0を設定します。また、対話セッションでのエージェント起動が既定でバックグラウンドになった点も地味に大きく、フォアグラウンドに固定したい場合はCLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1を使います。
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
@メンションで別セッションに話しかける手順
ここからが本題のセッション連携です。前提条件はシンプルで、macOS / Linux（WSL 2内のLinux含む）ならv2.1.224以降でクロスセッションメッセージングが有効化なしで使えます。ネイティブWindowsはv2.1.239のCHANGELOGで対応が明記されており、公式ドキュメント上の要件はv2.1.234以降です。@メンションの入力補完だけはv2.1.232以降が必要です。
使い方は3ステップです。
ステップ1: 相手セッションの名前を確認する
# どのセッションに届くかを一覧表示（/peers でも同じ）
/list-agents
# 1行目に「自分のセッション名」（他セッションから見た宛先名）
# 以降の行にサブエージェント・同一マシンの他セッション・
# クラウドセッション（Remote Control接続時）が並ぶ
セッション名は/renameコマンドや起動時の--nameフラグで自分で付けられます。ローカルセッションには作業ディレクトリも表示されるので、似た名前でも見分けられます。
ステップ2: @で指名してプロンプトを書く
# プロンプト内で @ に続けて名前の頭文字を打つと候補が出る
@api-worker にスキーママイグレーションが完了したと伝えて
# 名前を出さず、意図だけ伝えてもClaudeがListAgentsで探して送る
決済APIを触っているセッションに、いま入れた変更の要約を送って
注意点として、候補が出るのは@の後に1文字以上打ってからです。@単体ではセッション候補は表示されません。実際に送られる本文はClaudeが書くため、こちらのプロンプトは「何を知らせたいか」だけで足ります。
ステップ3: 受信側の挙動を理解する
受信側では、送信元セッション名付きでメッセージが会話に表示されます。相手が作業中ならツール実行の合間に読まれ、アイドル中なら新しいターンが始まります。届くのはプレーンテキストのみで、会話履歴やファイルは渡りません。会話ごと引き継ぎたい場合はセッションのresumeを使う、という棲み分けです。
受信制御とセキュリティ設計を確認する
「勝手に他のセッションから指示が届くのは怖い」と感じた方のために、受信制御の仕組みを押さえておきましょう。設定キーはcrossSessionInboundです。
| 値 | 挙動 |
|---|---|
| accept | 各メッセージをそのままClaudeに配送 |
| hold | 通知だけ表示して配送保留。承認するか、後からacceptが適用されると配送 |
| refuse | 配送せずに破棄 |
値を設定していない場合は、送受双方のパーミッションモードから1通ごとに判定されます。受信側が通常の許可プロンプトを出すモードなら基本配送、bypassPermissions系のセッションが絡む場合は承認ダイアログで保留、という設計です。/configの「Messages from your other sessions」行からも切り替えられます。
受信メッセージの権限も明確に制限されています。公式ドキュメントによると、別セッションからのメッセージは「あなたからの指示ではない」とClaudeに明示され、（1）保留中の許可プロンプトへの同意にはならない、（2）パーミッション設定やCLAUDE.md等の設定変更の根拠にできない、（3）本文中の/compactなどのコマンドはただのテキストとして扱われ実行されない、（4）メッセージ起点の作業でも受信側自身の許可プロンプトは通常通り発火する、という4点が保証されます。同一マシン内の配送はセッションごとのUnixドメインソケット（WindowsはNamed Pipe）経由で、Anthropicのサーバーを通りません。別マシンやWeb版セッション宛のみAnthropicサーバー経由となり、これを承認制にしたい場合はisolatePeerMachinesを使います。
// settings.json — マシン外への送信を毎回承認制にする
{
"isolatePeerMachines": true
}
// 組織で送受信を丸ごと止める場合（managed settings）
{
"permissions": {
"deny": ["SendMessage", "ListAgents"]
},
"crossSessionInbound": "refuse"
}
同名セッションの自動リネームという地味に重要な仕様
名前で配送する以上、同じマシンに「api-worker」が2つあると宛先が決まりません。v2.1.232ではここに手当てが入り、既に稼働中のセッションが使っている名前で新しいセッションを起動・リネームすると、元の持ち主が名前を保持し、新しい側が「name-word-word」形式の変種（例: api-worker-brave-otterのような3語連結）に自動変更され、その旨が通知されます。
運用上の含意は2つあります。第一に、スクリプトや手順書に「セッション名は◯◯にする」と固定で書いていると、2枚目のターミナルでは別名になっている可能性がある、ということ。送信前に/list-agentsで実名を確認する癖をつけましょう。第二に、旧バージョンのClaude Codeが混在する環境や自動生成名では名前重複が残り得るため、複数セッションが同名の場合はClaude側が短い識別子を付けて区別する挙動になっています。
実践例: worktree並行開発でセッション同士に報告させる
検証環境で試して効果的だったのは、git worktreeで分けた2セッションの連携です。マルチエージェント構成の設計判断そのものはマルチエージェントの設計パターン3選で整理した通りですが、今回の機能で「人間がターミナル間をコピペで往復する」工程が消えます。
# ターミナル1: スキーマ変更担当
claude --name schema-work
# 作業後にこう指示する:
# 「マイグレーション完了。変わったカラム名を @feature-work に伝えて」
# ターミナル2: 機能実装担当
claude --name feature-work
# schema-work からのメッセージが届き、
# 例: 「Schema migration finished: the new column is tenant_id,
# and rebasing on main is safe now.」
v2.1.236以降なら、SendMessageのnotify_when_idle入力を使った「相手セッションが次にアイドルになったら1回だけ通知」も組み合わせられます。長いテスト実行やマイグレーションを別セッションに走らせておき、「終わったら教えて」で放置できるのは体感がかなり変わります。通知は一度きりで、12時間届かなければ購読が破棄される仕様です。
なお、実験機能のAgent Teams（CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1）とは役割が異なります。Teamsはリードが共有タスクリストでチームを編成する仕組み、クロスセッションメッセージングは「自分が個別に立てた独立セッション同士」がメッセージを渡す仕組みです。正直なところ、現時点で安定して業務に組み込みやすいのは後者だと感じています。
4つの並列化手段をどう使い分けるか
今回の変更で、Claude Codeの「複数エージェントを動かす手段」は実質4系統になりました。名前が似ていて混同しやすいので、公式ドキュメントの記述を基準に一枚の表へ整理しておきます。
| 手段 | コンテキスト | 有効化 | 向いている用途 |
|---|---|---|---|
| 通常サブエージェント | まっさらな独立コンテキスト。結果だけ親に返る | 標準機能 | 結果だけ欲しい調査・レビューの委任 |
| forkサブエージェント | 親の会話全体＋プロンプトキャッシュを継承 | v2.1.232から既定有効 | 経緯の説明が面倒な脇道タスクの分岐 |
| クロスセッションメッセージング | 独立セッション同士。テキストのみ受け渡し | v2.1.224以降は有効化不要 | worktree並行開発の相互報告・完了通知 |
| Agent Teams | リード＋チームメイトが共有タスクリストで協調 | 実験機能。環境変数で明示有効化 | 複数仮説の並行検証など協調が必要な調査 |
迷ったときの判断基準はシンプルで、「会話の文脈を引き継ぎたいか」「相手は自分で立てたセッションか」の2軸です。文脈を引き継ぐならfork、自分で立てた独立セッション間の伝言ならクロスセッションメッセージング、そのどちらでもない協調作業だけAgent Teamsを検討する、という順番で考えると外しません。トークンコストもこの順に重くなります。
ヘッドレスワーカーにメッセージを受けさせる
応用として面白いのが、claude -pで起動した非対話セッションとの連携です。公式ドキュメントによると、-pセッションも対話セッションと同様にインボックス（受信用ソケット）を持ち、/list-agentsの一覧に現れます。つまり長時間走らせるワーカーを-pで立てておき、対話セッションから@メンションで指示や問い合わせを送る構成が組めます。
# 受信を無人で許可したワーカーを起動する
claude -p "テストスイートを回し続けて、指示が来たら対応して"
--name test-runner
--settings '{"crossSessionInbound": "accept"}'
ポイント:
-pセッションは承認ダイアログを表示できないため、既定判定で保留されたメッセージは期限（既定5分のdialogExpiry）を過ぎると破棄される。無人受信させたいなら上記のように--settingsでacceptを明示する- ユーザー設定に
acceptを書く方法もあるが、その場合は全セッションに適用されてしまうため、ワーカー単位の--settings指定が安全 - bare modeで起動したセッションはソケットを持たず、受信も一覧表示もされない
動作環境: Claude Code v2.1.232以降（macOS / Linux。検証は2026-08-23時点の安定版で実施）。
【要注意】よくある失敗パターンと回避策
失敗1: 会話やファイルまで渡ると思い込む
❌「相手セッションにこのファイルを送って」
⭕「相手セッションに変更点の要約をテキストで伝えて」
なぜ重要か: 渡るのはプレーンテキストのみです。同一マシン宛はシリアライズ後およそ100万文字で送信側が拒否するサイズ上限もあります。コンテキストごと引き継ぎたいならメッセージではなくセッションのresumeを使います。
失敗2: コンテナ・WSL境界を越えられると思う
❌ ホストのセッションからDevContainer内のセッションへ@メンション
⭕ 同じファイルシステムを共有するセッション同士で連携する
なぜ重要か: 同一マシン配送はディスク上の登録ファイルとソケットに依存するため、コンテナ内と外、WSL 2内とネイティブWindowsは相互に到達できません。またAmazon BedrockやGoogle CloudのAgent Platform等のプロバイダ経由では機能自体が利用不可です。
失敗3: 大量メッセージの連投
❌ 進捗を1行ずつ細かく送らせる
⭕ 節目ごとに1通へまとめて送らせる
なぜ重要か: 短時間の連投は受信側インボックスの上限に達すると送信側で拒否され、受信側でも送信者ごとのレート制限・重複破棄・最大50件のキュー上限が働きます。メッセージのループが自然停止するよう設計されている、と理解しておくのが正確です。
よくある質問
Q. 追加設定なしで今すぐ使えますか？
macOS / Linuxではv2.1.224以降なら有効化不要で使えます（@メンション入力補完はv2.1.232以降）。/list-agentsが認識されなければ、そのセッションはまだ機能を持っていないのでclaude --versionから確認してください。テレメトリ系の環境変数（DISABLE_TELEMETRY等）でフィーチャーフラグ評価を止めていると無効のままになる点にも注意が必要です。
Q. forkサブエージェントと@メンションはどう使い分けますか？
forkは「同じ会話の続きを知っている分身」に脇道タスクを任せる機能で、1セッション内で完結します。@メンション+SendMessageは独立したセッション間の伝言です。自分の文脈を引き継いだ調査ならfork、worktree並行開発の相互報告ならセッション連携、が目安です。サブエージェントの並列数上限やネスト仕様はサブエージェント上限の変更経緯で別途まとめています。
Q. 別セッションからの指示で勝手に危険な操作をされませんか？
受信メッセージは「ユーザーではなく別セッション発」と明示され、許可の代行・設定変更・コマンド実行はできない設計です。それでも心配ならcrossSessionInbound: "refuse"で受信を止められますし、権限まわりの過去の修正事例はサブエージェントの権限分離修正の記事が参考になります。
要点の整理
- v2.1.232（2026-08-13公開）でsubagent forkingが既定有効に。forkは会話全体とプロンプトキャッシュを継承し、新規サブエージェントより安く起動できる
- プロンプトで
@+名前を打てば別セッションを指名でき、ClaudeがSendMessageで直接連絡する。Agent Teamsの有効化は不要 - 同名セッションは「name-word-word」変種に自動リネームされるため、送信前の
/list-agents確認を習慣にする - 受信は
crossSessionInbound（accept / hold / refuse）で制御でき、届いたメッセージは許可の代行や設定変更ができない
まず今日やるなら、ターミナルを2枚開いてclaude --nameで名前を付け、/list-agentsで互いが見えることを確認してから、片方に「@もう片方 に挨拶を送って」と打ってみてください。5分で仕組みが体感できます。
あわせて読みたい:
- サブエージェント上限、Claude Codeが10日で3回変えた理由 — 並列数・ネスト仕様の変更経緯
- Claude Agent SDK サブエージェント実装ガイド — SDKからのサブエージェント実装
参考・出典
- Claude Code CHANGELOG — Anthropic（参照日: 2026-08-23）
- Claude Code v2.1.232 Release — GitHub / Anthropic（公開日: 2026-08-13、参照日: 2026-08-23）
- Message your other Claude Code sessions — Claude Code公式ドキュメント（参照日: 2026-08-23）
- Subagents — Claude Code公式ドキュメント（参照日: 2026-08-23）
- Orchestrate teams of Claude Code sessions — Claude Code公式ドキュメント（参照日: 2026-08-23）
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。著書『AIエージェント仕事術』。100社以上の企業向けAI研修・導入支援を手がける。
