Claude Codeのセッション間メッセージ機能とは｜v2.1.224で追加・別ターミナルのClaude同士が要約を送り合う仕組みと使い方【2026年8月最新】

Claude Codeのセッション間メッセージ（cross-session messaging）は、別々のターミナルで独立して動いている自分のClaude Codeセッション同士が、短いテキストを送り合える機能です。2026年8月7日公開のv2.1.224で追加され、対応OSはmacOSとLinux（WSL 2内のLinuxを含む）。ネイティブWindowsでは提供されていません。

渡るのはClaudeが書いたプレーンテキスト1通だけで、会話履歴もファイルも権限も一切渡りません。要件を満たしたセッションでは有効化操作なしで最初からオンになっています。

この機能は「並列セッションのコピペ往復を減らす小さな配管」であり、Agent Teamsのような協調フレームワークではありません。導入判断で見るべきポイントは3つ、(1) 対応OSとバージョン、(2) 受信側の権限モードによっては既定で保留されること、(3) 配信されたメッセージは自分で打ったプロンプトと同じくusage（利用量）を消費することです。

この記事でわかること

• セッション間メッセージで実際に何が起きるのか（渡るもの／渡らないもの）
• ListAgents と SendMessage という2つのツールの役割と、「SendMessage は前から存在した」という正確な時系列
• 動作要件（v2.1.224以降・macOS/Linux・プロバイダ制限）と、stableチャンネル運用だと2026年8月10日時点でまだ使えないという実測
• 同一マシン／別マシン／Webで、送れるものがどう変わるか
• crossSessionInbound・dialogExpiry・isolatePeerMachines によるセキュリティ設計と、組織単位で止める方法
• 「バージョンを上げたのに動かない」ときの切り分け手順
• Agent Teams・/resume・Agent view・Remote Control・Channels との使い分け

この記事の対象読者：ターミナルを2〜4枚開いてClaude Codeを並列に走らせている開発者、git worktreeで並行開発しているチーム、claude -p の常駐ワーカーを運用している人、そして社内でClaude Codeを配布していて「エージェント同士が横につながる」ことの安全性を判断したい情報システム部門の方。

Claude Code本体の基本仕様から確認したい場合は、Claude Codeとは？できること・料金・使い方を先に読むと以降の内容が理解しやすくなります。

セッション間メッセージとは何か

出典: Anthropic公式ドキュメント「Message your other Claude Code sessions」

セッション間メッセージは、片方のセッションが得た情報を、もう片方のセッションのClaudeに要約テキストとして届ける機能です。公式ドキュメント「Message your other Claude Code sessions」では次のように説明されています。

Cross-session messaging lets Claude deliver a message from one of your Claude Code sessions to another.（セッション間メッセージは、あなたのClaude Codeセッションの1つから別のセッションへ、Claudeがメッセージを届けられるようにするものです）

想定されている典型的な場面は、片方のセッションで加えた変更が、もう片方のセッションが前提にしている構造を壊してしまうケースです。人間が気づく前に、変更した側のClaudeが影響範囲を要約して相手のセッションへ警告できます。

渡るもの／渡らないもの

ここが誤解されやすい最重要ポイントです。

会話そのものを別のターミナルで続けたい、あるいはコンテキストごと新しいセッションに引き継ぎたい場合は、この機能ではなくセッションの再開（/resume）を使えと公式が明示しています。

届くメッセージは、実際にはこの程度の粒度のテキストです（公式ドキュメントの例）。

Schema migration finished: the new column is tenant_id, and rebasing on main is safe now.

ユーザーはツールを直接叩かない

もう1つ重要なのは、ユーザーが SendMessage を自分で呼ぶわけではないという点です。ユーザーがやるのは、いま開いているセッションに日本語（または英語）で頼むことだけです。

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

決済APIを触っているセッションに、いま何を変更したか説明して

文面はClaude自身が書きます。さらに公式には「Claude can decide to send a message without being asked」とあり、頼まれなくても必要と判断すれば自発的に送る設計です。並列でセッションを回している人は、この「勝手に届く」挙動を前提に設定を確認しておく必要があります。

仕組み — ListAgents と SendMessage の2ツール

出典: Anthropic公式ドキュメント「Tools reference」

Claudeはこの機能で2つのツールを使います。どちらも公式のツールリファレンス上は Permission required: No（既定で権限プロンプトなし）です。

「権限プロンプトなし」は送信すること自体に承認が要らないという意味であり、受信側に届くかどうかは別問題です。受信側の可否は crossSessionInbound 設定と権限モードの組み合わせで決まります。この区別を曖昧にしたまま「承認なしで何でも通る」と理解しないでください。

なお、Auto Modeで動いているセッションでは、他エージェントセッションへの SendMessage は送信のたびに権限分類器（permission classifier）が事前評価するとツールリファレンスに記載されています（v2.1.222以降）。Auto Modeそのものの2層防御についてはClaude Code Auto Modeとは｜2層防御・自律コーディングの仕組みで整理しています。

セッションの「名前」の決まり方

メッセージの宛先はセッション名です。

• /rename コマンド、またはCLIの --name フラグで指定した名前に応答する
• 指定しない場合はClaude Codeが自動命名する。対話セッションは作業ディレクトリのフォルダ名由来（例：myapp-3f）
• 同名のセッションが複数存在しうる。/list-agents の出力は各ローカルセッションの作業ディレクトリを併記するので人間側で区別でき、Claude側の一覧には短い識別子が付与され名前衝突時のアドレスに使われる

複数セッションを並列で回すなら、起動時に --name migration --name payments のように役割名を付けておくと、Claudeが宛先を取り違えるリスクを下げられます。スラッシュコマンドの扱いに慣れていない場合はClaude Code スラッシュコマンド 作り方｜.claude/commands 完全ガイドも参照してください。

メッセージの通り道

同一マシン上の配信は、Anthropicのサーバーを経由しません。

• 各セッションはディスク上のファイルに自身を登録し、セッションごとのUnixドメインソケット（inbox socket）をバインドする
• Claudeがローカルセッションを列挙・送信するとき、Claude Codeはその登録ファイルを読んで相手を見つける
• ソケットはOSユーザー単位に制限され、共有マシンでも他ユーザーのセッションからは到達できない

「同じファイルが見えるセッション同士でしか到達できない」という性質から、コンテナ内のセッションとホスト側のセッションは相互に到達できません。同一コンテナ内の2セッション同士なら可能です。

自分のセッションのソケットのパスは、/status の Peer address 行（uds: プレフィックス付き）で確認できます。パスの具体的な場所は公式が明示していないため、環境ごとに /status で確認するのが確実です。

「SendMessage は新登場」ではない — 正確な時系列

「v2.1.224で SendMessage が新登場」と説明されることがありますが、これは不正確です。公式CHANGELOGを遡ると、より古いバージョンにも cross-session messaging の記述があります。

つまり SendMessage 自体はサブエージェントやAgent Teams向けに先行して存在していました。v2.1.224で新しくなったのは、「自分が独立して立ち上げた別セッション同士を ListAgents で発見して送り合えるようになった」という到達範囲の拡張です。同じツールがサブエージェントにも使われている点は、Claude Code サブエージェント 使い方｜Task tool・並列処理完全ガイドと併せて読むと理解しやすくなります。

動作要件 — v2.1.224以降・macOS/Linux（WSL 2含む）

出典: Anthropic公式ドキュメント「Claude Code changelog」

公式が挙げる要件は次の3層です。

加えて、フィーチャーフラグ評価を無効化する環境変数（CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC / DISABLE_TELEMETRY / DO_NOT_TRACK / DISABLE_GROWTHBOOK）のいずれかが効いていると、バージョンとOSを満たしていても機能はオフのままです。これらはシェル、設定ファイルの env マップ、managed settingsのいずれからも入り込みます。

見落としやすい落とし穴：stableチャンネルではまだ届いていない

Claude Codeの自動更新には latest と stable の2チャンネルがあり、autoUpdatesChannel 設定で切り替えます。公式のセットアップ文書によれば、stableチャンネルはおおむね1週間前のバージョンを配信します。

npmレジストリで実測したdist-tagは次のとおりです（2026年8月10日時点）。

つまり、stableチャンネルで運用している環境は、2026年8月10日時点ではまだ2.1.220でセッション間メッセージを使えません。「最新に上げたつもりなのに /list-agents が通らない」ケースの多くはこれが原因です。バージョンとチャンネルは次のコマンドで確認できます。

claude --version
npm view @anthropic-ai/claude-code dist-tags

企業で配布バージョンを固定している場合も同様で、社内配布ポリシー側の確認が必要です。組織展開の考え方はClaude Code チーム導入ガイド｜Team/Enterpriseプラン・権限設計・管理者設定にまとめています。

リリース日と関連バージョン

v2.1.224で試して動かなかった／保留のまま消えなかったという人は、2.1.225以降に上げてください。

使い方の流れ

操作は単純で、専用のセットアップはありません。

1. ターミナルを2枚以上開き、それぞれでClaude Codeを起動する。役割が分かれるなら claude --name payments のように名前を付けておく
2. 片方のセッションで /list-agents（または /peers）を実行し、相手が一覧に出るか確認する
3. 送りたい側のセッションに、日本語で頼む（例：「別ターミナルで動いているセッションに、DBスキーマを変更したことを伝えて」）
4. Claudeが ListAgents で宛先を探し、SendMessage で本文を書いて送る
5. 受信側の画面に、送信者名付きのカードでメッセージが表示される

受信側の見え方と割り込みの挙動

• 受信側のClaudeはツール呼び出しの合間にメッセージを読む。実行中のツールが中断されることはない
• 受信セッションがアイドル状態なら、メッセージを起点に新しいターンを開始する
• 読み終えると Message from の1行に折りたたまれる。Ctrl+O で展開できる

名前が被ったとき

同名セッションが並ぶと宛先が曖昧になります。/list-agents の出力は各ローカルセッションの作業ディレクトリを併記するため人間側では区別できますが、確実に運用するなら /rename で明示的な名前を付けるのが安全です。v2.1.225では同名セッションへの取り違え防止も入っています。

相手セッションの場所で「送れるもの」が変わる

同じマシンの中でしか、こちらから会話を始められません。 ここは誤解が多いので表で整理します。

別マシンやWeb上のセッションは、Remote Controlが接続されているあいだ /list-agents に Remote Control ラベル付きで表示されます。ただし表示されていても、こちらから会話を開始することはできず、相手から届いたメッセージへの返信だけが可能です（2026年8月10日時点の公式ドキュメント本文の記述）。

なお、CHANGELOG v2.1.225には「SendMessage がRemote Controlセッションへ名前指定で会話を開始できるよう改善した」と読める記述があり、ListAgents の表示が name [ref] 形式になるとも書かれています。公式ドキュメント本文は依然「返信のみ」表記のため、本記事では現時点の仕様として「返信のみ」を前提に扱い、CHANGELOG側に改善記載がある事実を併記するにとどめます。

もう1つの注意点として、Remote Controlに接続していない状態で別マシンのセッションに返信すると、リクエスト自体はAnthropicサーバー経由で通るものの返信アドレスが付かず、相手はそれに返せません。Claudeにはその旨が伝えられます。

セキュリティ設計 — 「他セッションからの指示」はユーザーの同意ではない

出典: Anthropic公式ドキュメント「Claude Code settings」

この機能の核心はセキュリティ設計にあります。 セッションAがセッションBにメッセージを送ると、Claude CodeはB側のClaudeに「これはユーザーからではなく別セッションから来た」と明示し、できることを制限します。

送信側にも制約があります。自分のセッションで拒否・ブロックされた行為、あるいは自分の権限設定が止める行為を、他セッションに代行させるよう頼んではならないとClaudeは指示されており、その場合はユーザーに差し戻します。これはv2.1.166の「中継メッセージはユーザー権限を持たない」という強化を引き継いだ設計です。

権限モードやサンドボックスの全体像はClaude Codeのセキュリティと安全な使い方｜サンドボックス・権限・--dangerously-skip-permissions徹底解説で扱っています。

受信制御 crossSessionInbound（v2.1.224以降）

受信側で挙動を明示的に決める設定です。

優先順位が独特なので注意してください。 公式のsettingsリファレンスによれば、managed settings → --settings フラグ → user settings の順に読み、最初に見つかった値が適用されます。project / local settings の値は、これら信頼できるソース（managed settings / --settings / user settings）が与える値より accept < hold < refuse のラダー上で厳しい場合にのみ適用されます。信頼できるソースがどれも値を設定していない場合は、project / local の hold または refuse がメッセージごとの既定を置き換えます。

つまり、リポジトリにチェックインしたプロジェクト設定で受信を緩めることはできず、締める方向にしか効きません。

値を明示していないときの既定 — 権限モードの2クラス判定

crossSessionInbound を書いていない場合、Claude Codeは送信側と受信側の権限モードからメッセージごとに判断します。判定は2クラスに単純化されています。

• bypassクラス：bypassPermissions（権限プロンプトをスキップするモード）。plan モードは、bypassが使えるセッションではbypass側にカウント
• promptクラス：それ以外。auto / acceptEdits / dontAsk はこちらにカウント

要点は、--dangerously-skip-permissions で回しているセッションは、外から勝手に指示を注入されないという設計思想です。逆に言えば、bypassで回している人が「メッセージが届かない」と感じるのはバグではなく既定動作です。

承認ダイアログと dialogExpiry

保留になると、受信セッションに送信元とプレビュー付きの承認ダイアログが出ます。

• Approve で1通だけ配信、Deny／閉じるで破棄
• 無回答のまま dialogExpiry（既定 "5m"） を過ぎるとダイアログが閉じ、メッセージは破棄される
• 指定可能値は "60s" / "5m" / "10m" / "never"（無効化）。環境変数 CLAUDE_CODE_USER_DIALOG_TIMEOUT_MS が優先。この設定は user / managed / --settings からのみ読まれ、project・local は無視される（v2.1.224以降）
• 権限プロンプトと AskUserQuestion はこの期限の対象外
• 保留中に権限モードのクラスが変わると受信ルールを再適用し、通るものは配信して通知する。refuse が適用されるようになった場合は保留分を全破棄し、到達可能な送信者へ拒否を報告する
• 送信元が同一マシンなら、保留・配信・拒否・期限切れの結果が送信側に通知される。ただし到着時点で refuse されたものは送信側に通知されない

保留メッセージは配信キューとは別枠で最大100件保持され、超過分は古いものから破棄されます。

越境送信に承認を必須化する isolatePeerMachines

企業導入で最も重要な設定です。

{
  "isolatePeerMachines": true
}

• true にすると、このマシンの外にあるセッションへ SendMessage が届く前に必ず明示的な承認を求める
• bypassPermissions モードでも承認を求める
• どのスコープの設定でも true が優先される。チェックイン済みのプロジェクトファイルで「オンにはできるがオフにはできない」
• 同一マシン内のメッセージには承認プロンプトは出ない

「ローカル完結なら許容するが、Anthropicサーバーを経由する越境送信は人が見る」という運用を、設定1行で担保できます。

組織単位で完全に止める

受信と送信は別制御です。両方止めるならmanaged settingsで次のように書きます（公式の例）。

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

• 受信を止める：crossSessionInbound: "refuse"
• 送信・列挙を止める：権限のdenyルールに SendMessage と ListAgents を指定子なしのツール名だけで追加する

運用上の落とし穴が3つあります。

1. この設定でもClaude Codeはinbox socketをバインドし続けます。届いたものを配信せず捨てるだけです
2. SendMessage をdenyすると、サブエージェントやAgent Teamsのチームメイトへの送信も一緒に止まります（同じツールが両方を担うため）。Agent Teamsを業務で使っている組織は、この副作用を必ず検証してください
3. 拒否設定のセッションは見た目が変わりません。自身の /status にも他セッションの一覧にも変化が出ないため、設定ファイル側で確認するしかありません

エージェント同士が横につながること自体のリスク整理はAIエージェントのセキュリティガイドも参考になります。

制限と、見落としがちなコスト

出典: Anthropic公式ドキュメント「Manage costs effectively」

公式が明記する制限

課金への影響 — メッセージはusageを消費する

配信されたメッセージは「自分が打ったプロンプトと同じように利用量（usage）にカウントされる」と公式が明記しています。

これは並列運用のコストに直結します。4枚のターミナルを開いて互いに状況共有させると、その通知1通ごとに受信側で新しいターンが立ち上がり、レート上限やクレジットを消費します。「便利だから常時オンで連携させる」より、必要な局面（マイグレーション完了、破壊的変更の通知）に絞る方が費用対効果は高くなります。プラン別の消費感はClaude Code 料金、節約の考え方はClaude Code コスト最適化完全ガイドを参照してください。

なお、プランによる可否の差は公式ドキュメントに明記されていません。「Proでは使えない」「Max限定」といった断定は現時点では根拠がありません（v2.1.224で同時に追加された claude self-hosted-runner はTeam / Enterprise限定と明記されていますが、これは別機能です）。

技術的な限界ではないが理解しておくべきリスク

• 要約の正しさは誰も検証しない。 送信側Claudeが誤った要約を書けば、それがそのまま別セッションの前提として伝播します。重要な変更ほど、届いたメッセージを鵜呑みにせず人間が確認する運用が要ります
• 自発送信がある。 頼んでいないのにメッセージが飛ぶことがあるため、機密性の高いリポジトリを別セッションで開いている場合は crossSessionInbound を明示しておくのが安全です

「使えない」ときの切り分け手順

上から順に潰してください。

切り分けの分岐点は#2の /list-agents の反応です。「Unknown command」なら機能自体がない（#1・#3〜#6を確認）、コマンドは通るのに送信が届かないなら、より狭い原因（#8〜#12）に絞り込めます。この切り分けは公式のAvailabilityセクションが示す判定方法をそのまま実務手順に落としたものです。

ヘッドレスワーカーとフックからの活用

claude -p ワーカーに受信させる

claude -p セッションもソケットをバインドするため、長時間稼働のヘッドレスワーカーがメッセージを受け取れ、一覧にも表示されます。ただし -p セッションは承認ダイアログを出せないため、保留になったメッセージは保留のままです。

無人で受け取らせたい場合は、起動時に --settings で crossSessionInbound を accept にします。

claude -p "テストが落ちたら原因を要約して報告" \
  --settings '{"crossSessionInbound":"accept"}'

user settings に accept を書いても効きますが、その場合は自分が起動するすべてのセッションに適用される点に注意してください。

なお、v2.1.225では「ヘッドレスセッションおよび起動中に、メッセージが通知も期限もないまま保留され続ける」不具合が修正されています。ワーカー運用をするなら2.1.225以降が実質的な前提です。

フックやBashから自分のセッションへ投函する

各セッションのinbox socketのパスは、フックとBashコマンドに CLAUDE_CODE_MESSAGING_SOCKET 環境変数としてエクスポートされます。エクスポートは SessionStart を含むあらゆるフックの実行前に行われ、各セッションは常に自分自身のソケットを渡します（親セッションから継承したものではありません）。

自セッションの子プロセス（フックやBashコマンド）から自分のソケットへ投函した「own-child メッセージ」は、crossSessionInbound の指定がなければ配信されます。ただし検証可能かどうかはOSで差があります。

検証できない場合は「権限クラスを主張しないメッセージ」と同じ扱いになり、bypass系のセッションでは保留されます。また、サンドボックス内のBashからソケットに到達できるかは sandbox.network.allowAllUnixSockets / sandbox.network.allowUnixSockets で制御します。

フックの書き方全般はClaude Code Hooks 使い方｜PreToolUse/PostToolUse/Stop完全ガイドで解説しています。

他の並列実行機能との使い分け

Claude Codeには「複数セッションを扱う機能」が6つあり、目的ごとに使うべきものが違います。 公式が「これにはこっちを使え」と明示している対応関係を1表にまとめます。

判断の目安はシンプルです。

• Claudeにチーム編成そのものを任せたい → Agent Teams（使い方はこちら）
• 自分で立てたセッションの独立性は保ったまま、要点だけ横に流したい → セッション間メッセージ
• コンテキストごと引き継ぎたいだけ → /resume

「並列で動かす」という表面的な機能が似ているため混同されがちですが、Agent Teamsは1つのチームとして協調させる仕組み、セッション間メッセージは独立したセッション同士の連絡線、という違いが本質です。

実務でどう使うか — 並列開発での活用シーン

公式が挙げるユースケースを、実際の開発フローに落とすと次のようになります。

運用のコツは3つです。

1. セッションに役割名を付ける（--name migration など）。宛先の取り違えが減る
2. 通知させる局面を決める。全部を共有させるとusageが膨らむうえ、受信側のコンテキストがノイズで埋まる
3. 届いた内容を鵜呑みにしない。要約の正しさは検証されない

日常的な並列作業の組み立て方はClaude Code 使い方ガイド、実務での使いどころはClaude Code 活用事例も併せてどうぞ。

こんな人におすすめ

• 常時2〜4枚のターミナルで同一リポジトリを触っている人。セッション間のコピペ往復が実際に発生している人ほど効果が出ます
• git worktreeで並行開発しているチーム。何がマージされたかを人間が伝え直す手間が減ります
• 長時間のマイグレーションやテストを別セッションで回す人。完了報告を待つあいだ、手元の作業を止めずに済みます
• claude -p の常駐ワーカーを持っている人。crossSessionInbound: "accept" で無人受信させられます
• macOS / Linux（WSL 2含む）で、Anthropic公式経由でClaude Codeを使っている人

おすすめしない人・現時点で使えない人

• 単一セッションで完結している人。送る相手がいないため恩恵がありません
• Agent Teamsで完結しているチーム。チーム内は構造化メッセージでやり取りできるため、この機能を追加する理由が薄い
• コンテキストごと引き継ぎたいだけの人。それは /resume の役割です
• ネイティブWindows環境の人。WSL 2上のLinuxで起動すれば使えます
• Amazon Bedrock / Claude Platform on AWS / Google CloudのAgent Platform / Microsoft Foundry 経由で使っている組織。現時点では提供されていません
• エージェント間の自動連絡を統制できない組織。まずmanaged settingsで crossSessionInbound: "refuse" にし、isolatePeerMachines の運用方針を決めてから解禁する方が安全です
• stableチャンネル固定の環境。2026年8月10日時点では2.1.220のため、まだ届いていません

よくある質問

Q. 有効化の設定は必要ですか？

不要です。要件（v2.1.224以降・macOS/Linux・対応プロバイダ・フィーチャーフラグ評価が有効）を満たしたセッションでは、公式の表現どおり「messaging is on with nothing to enable」の状態です。逆に言えば、止めたい場合は明示的に設定する必要があります。

Q. 相手のセッションの会話内容は読まれますか？

読まれません。渡るのは送信側Claudeが書いたテキスト1通と送信者名・返信アドレスだけで、会話履歴もファイルも渡りません。

Q. 同一マシンのやり取りはAnthropicのサーバーを通りますか？

通りません。同一マシン上の配信はセッションごとのUnixドメインソケット経由で、公式が「never through Anthropic servers」と明記しています。別マシンやWeb宛ての返信はAnthropicサーバーを経由します。

Q. 別マシンのセッションに、こちらから話しかけられますか？

2026年8月10日時点の公式ドキュメントでは返信のみとされています。CHANGELOG v2.1.225にはRemote Controlセッションへ名前指定で会話を開始できるようにした旨の記載があるため、今後ドキュメント側の記述が更新される可能性があります。

Q. SendMessage をdenyすれば安全に止められますか？

送信と列挙は止まりますが、サブエージェントやAgent Teamsのチームメイトへの送信も同時に止まります。同じツールが両方を担っているためです。受信を止めるには別途 crossSessionInbound: "refuse" が必要です。

Q. 無限にメッセージを送り合ってループしませんか？

公式にスロットリングが実装されています。送信者ごとのレート制限、短時間の同一内容の重複破棄、未読の受理済みメッセージが1セッションあたり50件上限、保留は最大100件。結果として2セッション間のループは自然に止まります。

Q. 追加料金はかかりますか？

本機能に対する追加料金や専用プランは公式に記載されていません。ただし配信されたメッセージは自分で打ったプロンプトと同じくusageを消費します。並列で頻繁に連絡させるほどレート上限やクレジットを消費する点は前提にしてください。

Q. bypassPermissionsで動かしているのにメッセージが届きません

既定動作です。bypassクラスの受信セッションは、送信側もbypassクラスでない限りメッセージを保留し、承認を求めます。承認ダイアログは dialogExpiry（既定5分）で閉じ、メッセージは破棄されます。常時受信させたい場合は crossSessionInbound: "accept" を明示してください。

まとめ

Claude Codeのセッション間メッセージは、別ターミナルで動く自分のセッション同士に、要点だけを流すための細い連絡線です。派手な協調フレームワークではありませんが、並列で開発している人にとっては「人間がコピペで橋渡ししていた作業」が確実に減ります。

導入前に押さえるべき点を整理します。

• 要件：v2.1.224以降（実質は保留バグを修正した2.1.225以降）、macOS / Linux（WSL 2含む）、Bedrock・AWS・Google・Foundry経由では不可
• 2026年8月10日時点の実測：latest 2.1.226 / stable 2.1.220。stable運用ではまだ使えない
• 渡るのはテキストだけ。会話履歴・ファイル・権限は渡らない。コンテキストを渡したいなら /resume
• 別マシンへは返信のみ。同一マシン内だけが双方向
• 既定の保留ロジック：bypassで回しているセッションは、外からの指示を勝手に受け付けない
• 止めるなら：受信は crossSessionInbound: "refuse"、送信は SendMessage / ListAgents のdeny（Agent Teamsも止まる副作用に注意）、越境は isolatePeerMachines: true
• コスト：配信されたメッセージはusageを消費する

バージョンとdist-tagは日々変動します。導入判断の前に claude --version と npm view @anthropic-ai/claude-code dist-tags で手元の状況を確認してください。

次に読むべき記事

• Claude Codeとは？できること・料金・使い方 — 機能の前提となる本体の全体像
• Claude Code Agent Teams の使い方 — Claudeが監督する協調チームとの違い
• Claude Codeのセキュリティと安全な使い方 — 権限モードとサンドボックスの整理
• Claude Code チーム導入ガイド — managed settingsによる組織的な統制