>
>
公開日
最終更新日
Claude Codeのセッション間メッセージングは、別ターミナルで動く複数のClaude Codeセッションが、必要な要約テキストを交換する機能です。人間が結果をコピー&ペーストする回数を減らせますが、会話履歴・ファイル・権限を共有する機能ではありません。
本記事は、Claude Codeを法人導入している、または複数セッションによる並列開発を検討している開発部門・情報システム部門を対象に、通信仕様、プロバイダ制約、受信制御、作業ディレクトリの分離方法を整理します。便利さだけで導入すると、同一ファイルの競合、未検証メッセージによる誤誘導、無人実行セッションの統制漏れを招きます。
この記事で確認したこと（確認日: 2026年08月24日）：AnthropicのClaude Code公式ドキュメントに掲載されたセッション管理・設定仕様、国内企業のClaude導入事例、経済産業省・総務省のAI事業者ガイドライン、およびEU AI Actの人間による監視に関する要件を確認対象としました。
Claude Codeセッション間メッセージングとは
Claude Codeセッション間メッセージングとは、独立して起動したClaude Codeセッション同士が、作業に必要なテキスト情報を送受信する機能です。
本記事のポイント
クロスセッションメッセージングで送られるのは要約テキストであり、会話履歴・ファイル・権限は送られません。
並列開発では通信機能だけでなく、Git Worktreeによる作業場所の分離が必要です。
受信メッセージは未検証の入力として扱い、権限操作や本番反映には人間の承認を残します。
Amazon Bedrockなど経由のClaude Codeでは、同じ機能を利用できない提供形態があります。
AnthropicはClaude Code v2.1.224でクロスセッションメッセージングを追加しました。ユーザーが別々のターミナルで起動したClaude Code同士が、発見事項、作業完了、破壊的変更、確認依頼などを伝えられるようにした仕組みです。従来は、開発者が「APIの戻り値を変更した」「テストが失敗している」といった情報を別のターミナルへ手作業で渡す必要がありました。
利用条件や提供範囲はバージョンで変わるため、導入前にはAnthropicのClaude Codeセッション管理ドキュメントで、組織が配布しているバージョンの仕様を確認します。公式案内では、macOSとLinux、WSL2上のLinuxが主な対象です。ネイティブWindowsの扱い、段階提供中の機能、接続形態による制約は変動し得るため、OSとCLIのバージョンを固定した検証環境で可否を判定します。
対象読者と利用判断
この機能が適するのは、同じリポジトリで設計・実装・テスト・レビューを並行させ、各作業の結果を短い文章で共有できるチームです。単発の修正や、1人が1セッションだけを使う開発では、通信設定や運用ルールを増やす利益が小さくなります。
反対に、複数のClaude Codeセッションが同じ仕様書やコードベースに触れる環境では、情報伝達の漏れを減らす効果があります。ただし、メッセージを送れることと、作業状態を同期できることは別です。ソースコードの正本はGit、設計判断の正本はADRやチケット、実行中の変更は各ブランチに置くという役割分担を崩さないことが前提になります。
対象プロバイダと提供状況
プロバイダ制約は、情シスが最初に判断すべき項目です。Anthropic公式ドキュメントやコミュニティの技術検証では、Amazon Bedrockなど一部のクラウドプロバイダ経由の接続ではクロスセッションメッセージングが利用できないケースが報告されています。ただし、対応状況はCLIバージョン、契約プラン、リージョン、段階提供の状況により変わり得るため、「利用できない」と一律に判断するのではなく、組織が実際に使用している認証・接続経路と同じ条件でListAgentsの動作を検証し、その結果を採用基準にします。クラウド基盤経由でClaude Codeを統一配布している組織では、検証前に機能の利用を前提とした運用設計を進めないことが原則です。
対象・提供状況は、CLIのリリース、契約プラン、リージョン、段階提供で変わる可能性があります。社内標準の経路でセッション一覧が取得できれば限定検証へ進み、取得できなければコピー&ペーストまたはGit上のチケット連携を標準手順として維持します。
ListAgentsとSendMessageの機能と通信仕様
Claude Codeのセッション間通信は、到達可能な相手を見つけるListAgentsと、テキストを渡すSendMessageで構成されます。
ListAgentsは、現在のセッションから到達できるClaude Codeセッションを列挙するツールです。利用者は/list-agentsまたは/peersで候補を確認できます。表示された相手が存在しても、その相手の会話履歴、ローカルファイル、承認状態、実行権限を取得できるわけではありません。
SendMessageは、検出した相手にテキストを配送するツールです。実務では「feature/authブランチでログインAPIのエラー形式を変更した。呼び出し元はcodeとmessageを参照する」「migration-024を適用済み。本番反映前にインデックス作成時間を確認する」のように、対象・変更内容・次の判断を含めた短いメッセージにします。相手に長い調査ログを渡す目的には向きません。
送信対象と非共有情報
Claude Codeのセッション間通信で送られるのは、送信側が作成したメッセージ本文だけです。会話コンテキスト全体、開いているファイル、トークン使用量、シェル履歴、操作権限が自動転送されることはありません。あるセッションの会話を継続したい場合は、別セッションへメッセージを送るのではなく、Claude Codeの再開機能である/resumeを使います。
この区別は機密情報の扱いにも関係します。メッセージ本文に顧客データ、アクセストークン、秘密鍵、未公開の脆弱性詳細を書けば、そのテキストは送信先のコンテキストに入ります。「ファイルは送られないから安全」とは言えません。メッセージにはチケット番号、マスク済みの識別子、リポジトリ内のパスを記し、秘密情報そのものを貼り付けない規則を設けます。
関連機能との役割比較
複数のエージェント関連機能は似た名前でも、親子関係、通信方向、用途が異なります。独立セッションを連携したい場合はクロスセッションメッセージング、1つの依頼を分解したい場合はSubagentsというように、作業単位で使い分けます。
機能 | 構造 | 通信とライフサイクル | 向く作業 |
|---|---|---|---|
クロスセッションメッセージング | 人間が起動した独立セッション | 相手を検出し、必要なテキストを送受信します | 仕様変更、進捗、破壊的変更の通知 |
Subagents | 親セッションが子を一時起動します | 子は親へ結果を返し、タスク終了後に終了します | 調査、限定的な実装、テスト観点の洗い出し |
Agent Teams | リーダーと複数のチームメイト | 共有タスクリストやメールボックスで協働します | 設計・実装・レビューを並行させる大きな作業 |
Agent View | 実行中セッションの表示画面 | 通信機能ではなく監視・切替用のTUIです | 入力待ち、失敗、放置セッションの把握 |
Subagentsは親が管理する一つの仕事の内部並列化です。一方、Claude Code複数セッションの運用は、人間が別々に始めた仕事を後から情報連携する形です。親子関係がない独立セッションを、Subagentsのように同じ状態を共有するものと誤解すると、設計判断の食い違いが起きます。
ローカル通信経路
同一マシン内の通信はUnixドメインソケットを使い、Anthropicの外部サーバーを経由せずローカルで完結します。この性質は、社内ネットワークの外へメッセージ本文を新たに送る経路ではない点で有用です。ただし、端末上に複数の利用者アカウントやコンテナがある場合は、OSのユーザー境界、マウント設定、実行ユーザーを別途管理します。
コンテナとホスト、または異なるコンテナは、ファイルシステムとソケット名前空間が分かれるため、相互に検出できない場合があります。ヘッドレス実行でListAgentsが0件となる「No reachable agents」は、相手がいないのではなく、対話型セッションと実行環境が分離されていることが原因になり得ます。バッチ処理にはメッセージ連携を前提にせず、CIの成果物、Issue、通知システムへ結果を出す設計に切り替えます。
▲ Claude Codeセッション間通信における共有・非共有情報の違い
並列開発における活用シーンと実務での運用手法
Claude Codeセッション間通信は、並列作業の結論だけを適切な相手へ渡す場合に、最も効果を発揮します。
典型例は、設計担当がAPI仕様の変更を見つけ、実装担当とテスト担当へ影響範囲を通知するケースです。設計担当が長時間の調査内容を丸ごと送る必要はありません。「決済APIはamountを整数から文字列へ変更する。影響箇所はcheckoutとrefund。互換処理は6月末まで」という要約を送れば、受信側は必要なファイルだけを確認できます。
変更通知：型、インターフェース、データベーススキーマなどの破壊的変更を、影響するブランチへ通知します。
作業完了通知：マイグレーション、テスト、静的解析、レビューが終わった時点で、結果と未解決事項を伝えます。
判断依頼：実装を開始する前に、仕様上の選択肢と推奨案を担当セッションへ渡します。
障害共有：再現条件、ログの保管場所、暫定回避策を短く共有し、別担当の作業停止を防ぎます。
トークン節約は、セッション数そのものを減らすことではなく、不要なコンテキスト再読込を減らすことにあります。調査担当が数十ページのドキュメントを読み込んでも、実装担当に必要なのが結論3行なら、全履歴を再度読ませるより短い要約を渡す方が合理的です。一方、10個のセッションを立ち上げれば10倍速くなるわけではありません。依存関係の強い作業は、調整コストとトークン消費が増えます。
国内企業の導入成果
国内企業では、Claudeを含む生成AIを開発工程へ組み込む取り組みが進んでいます。Anthropicの楽天グループに関する公式ケーススタディは、新機能の市場投入リードタイムを24日から5日へ短縮し、79%の短縮を達成したと紹介しています。また、同社は重大エラーを97%削減し、Claudeが7時間にわたりコードリファクタリングを行った事例を公表しています。この数値は楽天グループの業務・評価条件での成果であり、別企業で同じ削減率を保証する値ではありません。
Anthropicのクラスメソッド株式会社に関する公式ケーススタディでは、同社がClaude EnterpriseとClaude Codeを全社約1,000名規模へ展開し、コードレビュー時間を80%削減したと紹介しています。レビュー自動化の効果を再現するには、AIの出力をそのまま承認するのではなく、レビュー対象の範囲、テスト基準、最終承認者を明確にする必要があります。
株式会社メルカリは、全社AIツール利用率95%、社内コードの70%をAI生成へ切り替えるAIネイティブ体制を公表しています。株式会社マネーフォワードは、開発者1人あたり週7時間の業務削減を示しています。これらは各社が公表した導入成果であり、組織のコード品質、開発プロセス、教育、利用ツールの組み合わせで結果が変わります。情シス部門では、他社の数字を費用対効果の保証値として使うのではなく、限定チームで「レビュー待ち時間」「手戻り件数」「生成AI利用後の修正回数」を導入前後で測定します。
メッセージの記載テンプレート
情報量が不足すると受信側は誤解し、情報量が多すぎると重要事項を見落とします。送信する内容は次の形式に揃えると、担当者が後から監査するときにも追跡しやすくなります。
項目 | 記載内容 | 記載例 |
|---|---|---|
対象 | ブランチ、サービス、チケット | checkout-api / PROJ-124 |
事実 | 確認済みの変更・結果 | レスポンスのamountが文字列へ変更済み |
影響 | 影響を受ける箇所 | refund、管理画面CSV出力 |
依頼 | 受信側に求める作業 | テストケース追加後に結果を返信 |
根拠 | PR、チケット、文書の場所 | PR #842、ADR-017 |
「この方法で進めて」「すべて自動修正して」といった曖昧な文面は避けます。特に本番環境、顧客データ、認証設定に触れる依頼は、メッセージではなくチケットや承認フローを正本にします。
Git Worktreeによるファイル競合の防止策
Claude Code複数セッションで同じリポジトリを扱う場合は、Git Worktreeで作業ディレクトリを分離しない限り、メッセージ通信だけでは競合を防げません。
最も多い失敗は、2つのセッションが同じ作業ディレクトリ内の同一ファイルを同時に書き換えるケースです。一方が型定義を更新し、もう一方が古い状態を前提にファイル全体を書き戻すと、先に入れた修正が消える「先祖返り」が起きます。メッセージで変更を通知しても、すでに読み込んだ古いコンテキストまでは自動更新されません。
作業ディレクトリの分離
Git Worktreeは、1つのGitリポジトリから複数のブランチを別ディレクトリとしてチェックアウトする機能です。たとえば、設計確認用、実装用、テスト修正用に作業場所を分ければ、各Claude Codeセッションは別々のファイルツリーで編集します。作業の分離後に、PRまたはマージで変更を統合します。
運用開始時は、まず主ブランチを更新し、作業ごとにブランチとWorktreeを作成し、各ターミナルを対応するWorktreeで起動します。セッション名、ブランチ名、チケット番号を同じ命名規則にすると、/list-agentsで相手を選ぶ際の取り違えを減らせます。例として、feature/PROJ-124-api、test/PROJ-124-apiのようにチケット番号を先頭に置きます。
.worktreeincludeによるローカル設定の扱い
.env、ローカル証明書、開発用設定など、.gitignoreでGit管理から除外したファイルは、新しいWorktreeへ自動的に複製されないことがあります。必要なローカルファイルを引き継ぐために.worktreeincludeを利用する場合でも、本番用の秘密鍵や個人トークンを含めてはいけません。
引き継ぐ候補は、ダミー値の環境変数テンプレート、ローカル起動用の設定、開発専用の証明書パスに限定します。秘密情報が必要な環境では、既存のシークレット管理システムまたは短期トークン発行手順で各Worktreeへ注入します。設定ファイルを複製できればA、秘密情報まで含まれるならBという二択ではなく、非機密設定だけを複製し、認証情報は実行時に別経路で渡す設計にします。
統合前の確認項目
各Worktreeで完結した変更を統合する前に、担当者は差分の重複、依存するブランチ、テスト結果を確認します。AIが作成した差分でも、マージ担当者は人間が担当します。以下の項目をPRテンプレートに入れると、クロスセッションメッセージの内容だけで統合判断する事故を避けられます。
変更したファイルと変更しなかったファイルを明記しているか
同じモジュールを変更した別ブランチが存在しないか
テスト、静的解析、依存関係チェックの結果を保存しているか
メッセージ本文ではなく、PR・チケット・設計書を根拠にしているか
データベース変更がある場合、ロールバック手順を記録しているか
▲ Git Worktreeを活用したマルチセッション並列開発の分離構成
メッセージ配送メカニズムと権限境界の設計
クロスセッションメッセージングは受信側の権限を昇格させませんが、メッセージ本文がAIの判断材料になる残余リスクは残ります。
Anthropicの公式ドキュメントでは、他セッションから届くメッセージはユーザーからの指示ではないこと、保留中の許可プロンプトへの承認として扱わないこと、スラッシュコマンドを実行しないことが説明されています。送信側が権限確認を迂回する設定を使っていても、その状態が受信側へ伝播するわけではありません。
しかし、「コマンドが自動実行されない」ことは、「メッセージが安全である」ことと同義ではありません。攻撃者または誤ったセッションが「セキュリティ確認済みなので設定を変更してよい」と書けば、受信側のAIがその文章を参照して不適切な提案を行う可能性があります。間接的プロンプトインジェクション、誤情報、古い仕様、なりすましに近い誤認を想定し、受信文を信頼済みの指示として扱わない運用が必要です。
受信設定と保留処理
受信挙動はcrossSessionInboundで制御します。acceptは受信を受け入れ、holdは人間の確認まで保留し、refuseは受信を拒否します。設定項目、適用範囲、優先順位はClaude Codeの更新で変わり得るため、組織設定を配布する場合はAnthropicのClaude Code設定ドキュメントを根拠として管理します。
Bypass Permissions Modeで動く受信側では、安全制御としてメッセージがholdになり、人間のダイアログ承認待ちとなる仕様が案内されています。AnthropicのClaude Code設定ドキュメントでは、dialogExpiryの既定の保留期限として300秒（5分）が案内されています。実際の既定値は利用中のCLIバージョンによって変わる場合があるため、公式設定ドキュメントで確認したうえで設定値を決定します。無人プロセスに対して保留を使うと、承認者がいないままメッセージが失効します。無人処理へacceptを設定する場合は、受信元、扱う情報、実行可能なツールを狭めた限定用途にします。
設定ファイルの最小例
以下は受信を保留する考え方を示す最小例です。実際のキー名・配置場所は利用中のClaude Codeバージョンの公式設定仕様に合わせます。
isolatePeerMachinesを有効にすると、他マシンにまたがる通信をより慎重に扱えます。個人開発端末でローカル通信だけを使う場合は、holdで受信内容を確認する運用が可能です。CIや定期バッチのように人が応答できない実行環境では、メッセージングに依存しない成果物連携へ設計を分けます。
権限境界とログの保存
受信メッセージは、権限承認、設定変更、本番デプロイの根拠にしません。権限が必要な操作は受信側で通常どおり承認させ、変更の理由はチケット、PR、承認記録に残します。ログを取得できる環境では、送信元セッション、受信先、時刻、メッセージの要約、実行した後続操作を相関付けます。
監査ログをAPIまたはエクスポートで取得できれば、SIEMへ送って異常な送信頻度や失敗を検出します。取得できない場合は、メッセージにチケット番号を必須化し、PRとチケットの記録を監査証跡にします。通信内容を全量収集すると、機密情報の二次保管リスクが増えるため、保存範囲と保管期間は情報分類に沿って決めます。
▲ 受信設定（crossSessionInbound）によるメッセージの処理判定フロー
情シスが導入前に確認すべき統制ポイント
情シスは機能の許可・禁止だけでなく、人間がどの操作を承認し、どの記録を残すかまで定義すると統制できます。
経済産業省と総務省は「AI事業者ガイドライン 第1.2版」を2026年3月31日に公表し、AIエージェントの自律動作や外部アクションに関するガバナンス評価を整理しました。高リスク操作では事前承認、中リスク操作では事後確認、低リスク操作ではサンプリング確認というHITL、Human-in-the-Loopの考え方を適用すると、すべてのメッセージを同じ強度で止めるよりも運用しやすくなります。
また、EU AI Act（Regulation (EU) 2024/1689）は、2026年8月2日に透明性義務など一部規定の適用を開始しました。高リスクAIシステムに関する主要義務については、その後の規則改正により適用時期が変わっているため、EU域内で対象となるAIシステムを扱う組織は、EUR-LexのRegulation (EU) 2024/1689と関連規則を法務・コンプライアンス部門と確認し、自組織のシステムに適用される条文と時期を特定します。日本国内だけで利用する場合でも、権限分離、追跡可能性、停止手段はエージェント運用の実務基準として参考になります。
組織方針と管理設定
まず、クロスセッションメッセージングを許可する対象を決めます。開発用端末では許可し、本番運用端末と共有サーバーでは拒否する、といった環境単位の区分が実務的です。許可する場合でも、ListAgentsとSendMessageの利用範囲、受信設定、ログの保管先を利用規程に記載します。
組織で一括統制する場合は、managed settingsで許可・拒否ルールを配布し、個人の設定より優先される状態を作ります。設定監査では、配布した設定ファイル、CLIバージョン、環境変数、実行モードを同時に確認します。環境変数だけを見て機能の有効・無効を判断すると、ユーザー設定や管理設定による差異を見落とします。
リスク別の人間介入
メッセージの送受信そのものは低リスクとして扱えますが、受信後に何を行うかでリスクは変わります。たとえば、コードコメントの更新やテスト失敗の通知は低リスクです。依存パッケージの更新、設定ファイルの書換え、外部APIへのデータ送信は中リスクとして、担当者が差分を確認します。本番デプロイ、アクセス権変更、顧客データの削除、シークレットの更新は高リスクとして、職務分離された承認者を置きます。
リスク区分 | 該当する行為 | 人間の介入 | 記録 |
|---|---|---|---|
低 | 進捗通知、テスト結果の共有 | 定期的なサンプリング確認 | チケット番号、実行ログ |
中 | コード修正、依存関係更新、設定変更案 | 差分確認後に実行 | PR、レビュー記録、テスト結果 |
高 | 本番反映、権限変更、顧客データ操作 | 事前承認と緊急停止手段 | 承認記録、監査ログ、ロールバック記録 |
無人実行セッションの棚卸し
claude -pなどのヘッドレスセッションは、対話画面がないため、承認ダイアログに依存する設計と相性がよくありません。無人実行にcrossSessionInbound: acceptを設定すると、人間の確認なしに外部入力を受け取る経路ができます。
無人実行を使う場合は、実行目的、受信設定、アクセスできるリポジトリ、利用可能なコマンド、ネットワーク到達先、停止担当者を台帳化します。受信設定を確認した結果、実行目的が「定期テスト結果の通知」だけなら受信を拒否して成果物連携へ変更します。双方向の連携が不可欠で、かつ監査ログと停止手段を用意できる場合だけ、限定したaccept設定を採用します。
導入判断チェックリスト
以下を導入前のレビュー票として使うと、設定・運用・監査の抜け漏れを減らせます。
対象端末のClaude Codeバージョン、OS、認証プロバイダを一覧化したか
標準経路でListAgentsとSendMessageが利用可能かを検証し、結果を記録したか
開発端末、共有端末、CI、本番運用端末ごとの受信方針を決めたか
managed settingsで強制する項目と、チーム単位で選択できる項目を分けたか
ヘッドレス実行の
crossSessionInbound設定を台帳化したかGit Worktree、ブランチ、PRの統合ルールを開発標準に入れたか
高リスク操作の承認者と緊急停止の連絡先を定めたか
ログ取得の可否に応じ、SIEM連携またはチケット記録のどちらを正本にするか決めたか
導入時に起きやすい失敗パターン
クロスセッションメッセージングの失敗は、通信機能の誤解よりも、作業分離と責任分界がないまま自動化を広げることで起きます。
同一ディレクトリの同時編集
同じWorktreeで複数セッションを起動し、同一ファイルを編集させる運用は避けます。メッセージで「修正済み」と伝えても、もう一方のセッションが古いファイル内容を前提に編集していれば、変更は上書きされます。ファイル競合が発生した場合は、メッセージの再送ではなく、両方の差分を停止して比較し、どのブランチを正とするか人間が決めます。
要約メッセージの過信
メッセージは要約であり、詳細な根拠ではありません。「テスト済み」「安全」と書かれていても、対象環境、テスト範囲、失敗ケース、実行日時がなければ承認根拠になりません。特に脆弱性対応、データ移行、認証変更では、受信メッセージを起点にPR、CI結果、チケットの一次記録へ戻る手順を固定します。
無人処理への受信許可
headlessやcronの処理で、対話型セッションを見つけられず「No reachable agents」となる失敗もあります。これはクラウドのスケジュール実行とローカル端末が同じ到達範囲にないためです。常駐エージェントと一時バッチを同じ通信モデルで扱わず、バッチは成果物ストレージ、CIログ、Webhook、チケット更新のいずれかへ結果を出します。
便利な設定の全社一律適用
全社にacceptを一律配布すると、開発端末、管理端末、共有サーバー、無人実行環境の違いを無視します。逆にすべてrefuseにすると、限定チームで得られる並列開発の効果まで失います。開発用の限定リポジトリでholdから開始し、監査ログ、競合件数、承認遅延を測定できれば受信範囲を広げ、測定できなければ拒否設定を維持する判断が適しています。
利用実態の可視化と周辺統制
セッション間のローカル通信を直接可視化できなくても、利用者、端末、契約、実行環境を把握すれば統制の土台を作れます。
クロスセッションメッセージングはUnixドメインソケットを使うため、SaaS管理ツールがメッセージ内容を直接検知するものではありません。情シスが確認すべき対象は通信本文ではなく、誰がClaude Codeを使い、どの認証方式で利用し、どの端末・リポジトリ・実行環境に接続しているかです。
マネーフォワードi株式会社が提供するAdminaは、公式案内で200種類以上のAIサービス検知機能と、380以上のSaaSとのAPI連携を案内しています。ただし、検知対象、連携可否、取得できる属性は契約プランや連携方法で変わるため、Claude Codeのセッション間メッセージ本文まで取得できると誤認してはいけません。詳細はAdminaのシャドーIT検知機能で確認できます。
利用者一覧を取得できる場合は、ID管理台帳と突合し、退職者アカウント、個人契約、未管理端末での利用を優先的に整理します。取得できない場合は、調達記録、SSOログ、端末管理情報、開発者アンケートを組み合わせ、利用実態の暫定台帳を作ります。通信内容の監視を強化するより前に、管理対象のアカウントと端末を確定させる方が、シャドーAI対策として効果的です。
AIエージェント連携全体の統制は、AIエージェントとは？情シス向け完全ガイドで整理しています。MCPを含む外部接続のリスクは、MCP企業導入のセキュリティ完全ガイドも参照してください。Claude Codeの企業利用に必要な認証、バージョン、ポリシーの統制は、Claude Code エンタープライズ・ガバナンスガイドにまとめています。
よくある質問
Claude Codeのセッション間通信で検索されやすい疑問に、仕様と運用の両面から回答します。
Claude Codeセッションとは何ですか
Q：Claude Codeセッションとは何ですか？
A：Claude Codeセッションは、ターミナルで開始した一連の対話・作業単位です。別ターミナルで起動したClaude Codeは別セッションとして扱われ、通常はそれぞれ異なる会話コンテキストを持ちます。
セッション一覧の確認方法
Q：Claude Codeのセッション一覧はどのように確認しますか？
A：到達可能な相手は/list-agentsまたは/peersで確認できます。表示されない場合は、OS、実行ユーザー、コンテナ境界、プロバイダ、対話型かヘッドレスかを確認し、同一環境で検出できる場合だけメッセージ連携を使います。
SendMessageによる送信内容
Q：Claude CodeのSendMessageで会話履歴やコードファイルも送信されますか？
A：送られるのは送信側が作成したテキストメッセージです。本文に秘密情報を書けばその内容も送信されるため、アクセストークンや顧客データをメッセージ本文に含めず、チケット番号やリポジトリパスに置き換えます。
AWS Bedrock経由の利用可否
Q：AWS Bedrock経由のClaude Codeでもクロスセッションメッセージングは使えますか？
A：Anthropicのコミュニティ報告や技術検証では、Amazon Bedrock経由の接続でクロスセッションメッセージングが利用できないケースが確認されています。ただし、対応状況はCLIバージョン、契約プラン、リージョンによって変わるため、組織が実際に使用している接続経路と同じ条件でListAgentsの動作を検証し、その結果で判断します。検証で取得できなければ、PR・チケット・CI成果物を正本とする既存の連携手順を維持します。
受信メッセージによる自動実行
Q：他セッションからのメッセージで勝手にコード変更やコマンド実行が起きますか？
A：メッセージ本文のスラッシュコマンドはプレーンテキストとして届き、権限承認も代行されません。ただし、本文がAIの判断材料になる可能性は残るため、受信文だけを根拠に本番操作や設定変更を行わないことが必要です。
まとめ
Claude Codeのクロスセッションメッセージングは、独立したClaude Codeセッション間で作業の結論を共有し、並列開発の伝言コストを下げる機能です。ただし、会話履歴やファイルを同期する機能ではなく、同じディレクトリを複数セッションで編集すれば競合や上書きは起きます。
明日から着手する最初の一歩は、社内で使われているClaude CodeのOS・バージョン・認証プロバイダ・無人実行の有無を一覧化することです。その結果、対応環境と監査ログを確認できれば、Git Worktreeを使う限定チームでhold設定から検証を始めます。確認できなければ、セッション間通信は拒否し、PR・チケット・CI成果物を正本とする既存の連携手順を維持します。
認証・認可の統制についてはClaude Enterprise認証管理 完全ガイド、AIエージェントの事故から点検事項を整理する際はOpenAIのAI暴走・他社に不正侵入｜情シスが点検すべき10項も参照できます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
