>
>
公開日
Claude Code v2.1.224で追加された「クロスセッションメッセージング（Cross-session messaging）」は、複数のClaude Codeセッションが人間を介さずにテキストをやり取りできるようにする新機能です。
特別な有効化操作は不要で、条件を満たすセッションでは既定で動作します。開発現場の生産性を高める一方、AIエージェント同士が自律的に情報をやり取りする経路が社内に増えることを意味するため、情シス部門はガバナンス設計の見直しが必要になります。
この記事でわかること
Claude Codeクロスセッションメッセージングの仕組みと、
ListAgents・SendMessageという2つのツールの役割並列開発・研究エージェント連携における具体的な活用シーンとトークン節約効果
情シスが導入判断の際に確認すべき権限境界・受信制御・監査ログの統制ポイント
Admina等のSaaS管理プラットフォームで補完できる可視化・棚卸しのアプローチ
Claude Codeクロスセッションメッセージングとは？機能の概要と登場の背景
この機能は「人間がAI同士の伝言係をしていた作業」をClaude自身に引き継がせる仕組みです。
従来、複数のターミナルでClaude Codeを並行稼働させている場合、あるセッションの変更や発見を別のセッションに伝えるには、ユーザーが結果をコピーして貼り付ける必要がありました。Anthropicの公式ドキュメントによれば、この機能はmacOSとLinux（WSL2上のLinuxを含む）で、Claude Code v2.1.224以降であれば追加設定なしに動作します。ネイティブのWindowsでは提供されていません。
対応プロバイダにも制約があります。Amazon Bedrock、AWS上のClaude Platform、Google CloudのAgent Platform、Microsoft Foundryでは利用できず、公開時点ではAnthropicの直接APIやClaude.ai経由の利用に限られます。複数のクラウド基盤でClaude Codeを併用している組織は、どの経路で使っているかによって挙動が変わる点を最初に確認しておく必要があります。
背景として、Qiitaに投稿された解説記事（「Claude Codeが『セッション同士で会話』できるように」）が指摘するとおり、データベース設計・API実装・テスト作成・ドキュメント更新のように役割分担してClaude Codeを並列稼働させる使い方は以前から広がっていました。セッションが増えるほど「どのClaudeに何を伝えたか」を人間が管理するコストが増大するという矛盾があり、この機能はその管理コストを引き下げるために追加されたと理解すると位置づけが分かりやすくなります。
何ができるのか？ListAgentsとSendMessageの役割
重要なのは、この機能が会話履歴やファイル、操作権限を一括で共有するわけではなく、「必要な情報だけをテキストで渡す」設計になっている点です。Claude Codeは2つのツールでこれを実現します。
ListAgentsは、Claudeが到達できる他セッションを検出するツールです。同一マシン上の他のローカルセッション（バックグラウンドセッションを含む）や、Remote Control接続中の他マシン上のセッション、Claude Code on the webのセッションが対象になります。ユーザー自身が/list-agents（別名/peers）を実行すれば、Claudeが到達可能な相手を一覧で確認できます。
SendMessageは、ListAgentsで見つけた相手にメッセージを届けるツールです。送られるメッセージはあくまで一つのClaudeが書いたテキストであり、送信元セッションの会話履歴やコンテキストそのものは相手に渡りません。Qiitaの記事が的確に表現しているとおり、重要なのは「コンテキストを共有する」のではなく「必要な情報をメッセージとして共有する」という考え方です。同じSendMessageツールは、サブエージェントやAgent Teamのチームメイトへのメッセージ送信にも使われますが、本機能が対象とするのはユーザーが個別に起動した独立セッション間のやり取りです。
同一マシン上のセッション間では、メッセージはセッションごとのUnixドメインソケットを経由し、Anthropicのサーバーを一度も通過しません。マシンをまたぐ場合はRemote Controlの接続を経由してAnthropicのサーバーを通過しますが、公開当初は「返信のみ」に制限されており、こちらから新しい会話を始めることはできません。コンテナ環境では、コンテナ内のセッションとホスト上のセッションはファイルシステムが異なるため互いに到達できず、同一コンテナ内のセッション同士（セルフホストランナー上を含む）は通信可能という制約もあります。
並列開発・研究連携における活用シーンとトークン節約効果
この機能が特に効いてくるのは、複数セッションに役割を分担させ、結論だけを橋渡しする使い方です。Anthropicが例示する典型的な活用シーンは次の3つです。
知見の引き渡し：あるセッションが破壊的変更や重要な決定を発見した際に、影響を受ける作業をしている別セッションへ要約を送る
並列worktreeの調整：同じリポジトリを複数のworktreeで分担している場合に、他のセッションへ最新の反映内容を伝える
長時間実行タスクの状態報告：マイグレーションやテスト実行など時間のかかる処理から、監視しているセッションへ進捗を報告する
Qiitaの解説記事は、この設計がトークン消費の観点でも合理的だと指摘しています。調査担当のセッションが大量のWebページやコードを読み込んでいても、実装担当のセッションが必要とするのは「推奨方式とその理由、注意点」といった数行の結論だけであることが多く、会話履歴を丸ごと引き渡すよりも効率的です。ユーザーが明示的に「マイグレーションが終わったか、隣のターミナルで動いているセッションに聞いて」と指示することもできますし、Claudeが変更後の影響に気づいて自発的にメッセージを送ることもあります。
一方で、セッションを増やすほど計算資源とトークン消費も比例して増えるという基本構造は変わりません。「10個のセッションを立ち上げれば10倍速くなる」という単純な話ではなく、分担すべき仕事の単位を見極めることが実務上のポイントです。また、複数セッションが並行して状態を持つ以上、GitやCLAUDE.md、設計書といった「最終的な正解となる情報源」を別途決めておかないと、セッション間で認識がずれるリスクも残ります。メッセージングは情報伝達を速くする経路であって、状態管理そのものを代替するものではない、という位置づけの理解が現場への浸透度を左右します。
メッセージ配送の仕組みと権限境界—なぜ「勝手に何かされる」ことはないのか
情シスが最初に確認したいのは、受信側セッションが送られてきたメッセージにどこまで従うのかという境界線です。Anthropicは、受信側のClaudeに「このメッセージは他のセッションから来たものであり、ユーザーからの指示ではない」と明示させる設計を採っています。具体的には次の3点が制約として組み込まれています。
権限確認の代行はできない：他セッションからのメッセージは、ユーザーの承認が必要な操作の承認として扱われません。保留中の許可プロンプトに対する回答にはなりません
設定変更はできない：受信側のClaudeは、他セッションからの依頼を理由に許可設定やCLAUDE.md、その他の設定ファイルを変更しないよう指示されています
コマンドは実行されない：メッセージ本文に
/compactのようなスラッシュコマンドが含まれていても、プレーンテキストとして届くだけで実行はされません
さらに、送信側のClaudeにも「自分のセッションで拒否・ブロックされた操作を、別セッションに依頼してはいけない」というルールが適用され、そうした要求は人間に差し戻す設計になっています。受信側で実際に権限が必要な操作をする場合は、通常どおりその場で許可プロンプトが表示されます。
受信の挙動はcrossSessionInboundという設定値（accept／hold／refuse）で制御でき、値を明示しない場合はデフォルトで、送受信双方のセッションが「許可確認をスキップするモード（Bypass Permissions Mode）」かどうかによって自動的に判定されます。受信側が許可確認を求める通常モードであればメッセージは配送され、受信側がスキップモードであれば承認ダイアログが表示され、ユーザーの承認があるまでメッセージは保留されます。保留は最大100件、配送待ちの受信キューは最大50件までという上限も設けられており、メッセージのループが発生しても自動的に頭打ちになる設計です。
マシンをまたぐ送信を制限したい場合はisolatePeerMachinesをtrueに設定すると、Bypass Permissions Modeであっても他マシンへの送信前にユーザーの承認が必須になります。
情シスが導入前に確認すべき4つの統制ポイント
ここまでの仕組みを踏まえると、情シスが実務で押さえるべき論点は次の4つに整理できます。導入を止める・許可するという二択ではなく、既存のAI利用ガイドラインの中にこの機能を位置づける作業だと捉えるのが実務的です。
1. 機能のオン／オフを組織方針として明文化する
クロスセッションメッセージングは、追加設定なしに条件を満たせば動作する「デフォルトオン」の機能です。つまり、情シスが把握していないうちに、並列開発をしているエンジニアの間で実質的な利用が始まっている可能性があります。組織として利用を許可する場合も禁止する場合も、まずは方針として明文化することが最初のステップです。送信・一覧取得を止める場合はSendMessageとListAgentsに対する許可拒否ルールを、受信を止める場合はcrossSessionInboundをrefuseに設定します。組織全体で統一したい場合は、管理設定（managed settings）でこれらを一括指定することで、個々の開発者の設定ファイルより優先させることができます。
2. 受信メッセージを「未検証の入力」として扱う運用を周知する
受信側のClaudeは、他セッションから届いたメッセージを設定変更や権限承認の根拠にはできません。しかし、メッセージの本文自体はテキストとして受信側の判断材料になります。複数セッションを横断した業務フローを構築する際は、メッセージの内容を鵜呑みにして重要な判断（デプロイ判断、機密情報の取り扱い変更など）を行わないよう、開発者への周知が必要です。この考え方は、AIエージェントが受け取った外部入力を無条件に信頼しないという、プロンプトインジェクション対策の基本方針とも一致します。
3. 無人稼働セッションの受信設定を個別にレビューする
claude -pのような長時間稼働のヘッドレスセッションは、通常起動であれば受信用ソケットをバインドしメッセージを受け取れます。ただし、これらのセッションは承認ダイアログを表示できないため、保留されたメッセージはそのまま保留され続けます。無人稼働のワーカーにメッセージを自動的に処理させたい場合は、そのセッションの--settingsでcrossSessionInboundを明示的にacceptに設定する必要があります。これは「人間の確認なしにAIへの入力経路を開く」判断そのものなので、どのセッションでこの設定を使っているかを個別に棚卸しし、対象を最小限に絞ることが望まれます。
4. 機能フラグの無効化条件とバージョン運用ルールを把握する
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC、DISABLE_TELEMETRY、DO_NOT_TRACK、DISABLE_GROWTHBOOKのいずれかの環境変数が機能フラグの評価を無効化する値に設定されていると、クロスセッションメッセージングは動作しなくなります。これらはシェル、設定ファイルのenv項目、管理設定のいずれからでも設定できるため、意図せず機能が無効化されている、あるいは意図せず有効化されているケースを避けるには、どの経路でこれらの変数が設定されているかを確認しておく必要があります。加えて、本機能はバージョン依存の機能追加であるため、Claude Code エンタープライズ・ガバナンスガイドで解説している「バージョン運用ルールの明文化」が、この機能の統制にもそのまま当てはまります。
見落としやすいリスク：シャドー化と情報伝達経路の増加
クロスセッションメッセージングそのものは、AIに新たな実行権限を与える機能ではありません。しかし情シスの観点では、社内のAI活用がどのように広がっているかを可視化する上での「見えにくさ」を増やす要因になり得ます。エンジニアが個人の判断で複数の並列セッションを立ち上げ、セッション間で自動的に情報をやり取りする運用に発展した場合、その全体像は個々の開発者の頭の中にしかない、という状態が生まれやすくなります。これは、これまでの記事で整理してきたシャドーAIの検知・対策ガイドや、MCP企業導入のセキュリティ完全ガイドで指摘してきた「利用実態の把握が管理より先行してしまう」構造と同じ根を持っています。
また、MCPの仕様がステートレス化した際の解説記事でも触れたとおり、AIエージェント連携の運用負荷が下がるほど、社内での接続や連携の数は増えやすくなります。クロスセッションメッセージングも同様に、「便利になった分だけ、情シスが把握すべき連携経路が増える」というパターンに当てはまる機能だと捉えておくと、導入判断がしやすくなります。
マネーフォワード Adminaで補完できる可視化・統制のアプローチ
クロスセッションメッセージングは、セッション間のソケット通信という性質上、SaaS管理プラットフォーム側から直接その通信内容を検知することはできません。この点は、MCPサーバー本体を直接検知できないという制約と同様です。しかし、周辺の統制であれば既存の仕組みで補完できます。
マネーフォワードi株式会社が提供するSaaS管理プラットフォーム「Admina」は、200種類以上のAIサービス検知機能により、社内でClaude CodeやCursor、Codexなどがどの程度利用されているかを可視化します。クロスセッションメッセージングの利用実態そのものは検知できませんが、「そもそも社内でClaude Codeを使っているのは誰か」「個人契約による未申請利用（シャドーClaude Code）が広がっていないか」を把握することが、この機能に関するガバナンス設計の前提になります。また、380以上のSaaSとのAPI連携により、従業員・デバイス・SaaSの利用状況を一元管理し、Claude Codeの利用者リストと社内のIT資産情報を紐付けて棚卸しすることも可能です。並行して社内のAIエージェント連携全体を管理したい場合は、AIエージェントとは？情シス向け完全ガイドや、AdminaのシャドーIT検知機能の詳細もあわせて参照してください。
導入判断チェックリスト
情シスが実務で確認すべき項目を、以下のチェックリストとして整理します。
✅ 社内で稼働しているClaude Codeのバージョンが v2.1.224 以降か、対応プロバイダで利用しているかを確認したか
✅
SendMessage／ListAgentsを許可するか拒否するか、組織方針として明文化したか✅
crossSessionInboundのデフォルト挙動（許可確認モードかBypass Permissions Modeか）が、想定する運用と合っているか確認したか✅ ヘッドレスセッション（
claude -p）でcrossSessionInbound: acceptを使っている箇所を棚卸ししたか✅ マシンをまたぐ送信を制限する
isolatePeerMachinesの適用要否を検討したか✅ 4つの環境変数（
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC等）による機能フラグ無効化の設定状況を確認したか✅ AdminaなどのSaaS管理プラットフォームで、Claude Codeの利用者・アカウント状況を可視化できているか
よくある質問（FAQ）
Q：クロスセッションメッセージングは、有効化しないと使えませんか？ A：いいえ。Claude Code v2.1.224以降で、対応OS（macOS／Linux）かつ対応プロバイダの条件を満たせば、追加の有効化操作なしに動作します。逆に利用を止めたい場合は、許可拒否ルールやcrossSessionInboundの設定で明示的に無効化する必要があります。
Q：他のセッションから送られたメッセージによって、意図しない操作が実行されることはありますか？ A：受信したメッセージは、保留中の許可プロンプトへの回答や、設定変更の根拠にはできません。スラッシュコマンドもプレーンテキストとして届くだけで実行されません。ただし、実行に許可が必要な操作であれば、受信側でも通常どおり許可プロンプトが表示されます。メッセージの本文を無条件に信頼しない運用を周知することが重要です。
Q：会話履歴やファイルの内容も、別セッションに送られてしまいますか？ A：送られるのはメッセージとして書かれたテキストのみです。会話履歴やファイル、操作権限そのものは相手のセッションに渡りません。会話全体を引き継ぎたい場合は、セッションの再開（resume）という別の機能を使う設計になっています。
Q：AdminaはClaude Codeのセッション間メッセージングを検知できますか？ A：セッション間の通信内容そのものを直接検知する機能はありません。ただし、Claude Codeの利用者・アカウントの可視化や、シャドーAIの検知機能を通じて、この機能を使う前提となる「社内でのClaude Code利用実態」を把握する用途で活用できます。
まとめ
Claude Codeのクロスセッションメッセージングは、これまで人間が担っていた「セッション間の伝言」をAI自身に引き継がせる機能です。会話履歴やファイル、権限は共有されず、受信側は届いたメッセージを承認や設定変更の根拠にできないという境界線が設計段階で組み込まれている点は、情シスにとって安心材料になります。一方で、追加設定なしに動作する「デフォルトオン」の性質上、組織が把握しないうちに並列セッション運用が広がる可能性があり、既存のAI利用ガイドラインへの反映が必要です。
情シス部門としては、送受信の許可方針を明文化し、無人稼働セッションの受信設定を個別に棚卸しし、Claude Codeのバージョン運用ルールを継続的に見直すという3点を軸に対応を進めることを推奨します。社内のAI利用実態そのものの可視化については、SaaS管理プラットフォーム「Admina」の活用もあわせてご検討ください。
Claude Codeの企業導入全体における統制設計は、Claude Code 企業利用の統制ガイドで詳しく解説しています。認証・認可の観点はClaude Enterprise認証管理 完全ガイド、AIエージェントの暴走事例からの教訓はOpenAIのAI暴走・他社に不正侵入｜情シスが点検すべき10項もあわせてご覧ください。
AIエージェントの利用実態を可視化し、シャドーAI対策とセキュリティ統制を一体で進めたい方は、マネーフォワード Adminaの詳細をご確認ください。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
