「SendMessage」は権限迂回の抜け道にならない

この記事の結論: クロスセッションメッセージングは「相手セッションに処理を頼める」機能であって「自分のセッションで止められた操作を迂回する」機能ではない。複数エージェントセッションを連携させる設計を考えるときは、相手セッションの権限境界は依然として相手側にあることを前提にすること。

リナ社長（高校生社長のやり手ギャル）× タクヤ（入社3年目）— 今回は、Claude Codeの「SendMessage」でセッション同士がやり取りできるって聞いて、権限まわりの落とし穴を実際に確認する回。（登場人物について）

「タクヤ、Claude Codeって今エージェント同士でメッセージ送り合えるらしいじゃん。だったらさ、片方のセッションで止められた操作があっても、もう一個セッション立てて『やっといて』って頼めば通っちゃったりしない？」とリナ社長。

「あ、それ僕も一瞬考えたんですけど」とタクヤが答える。「ツールの説明文自体に、それを禁止するルールが明記されてるんですよ。さっきListAgentsとSendMessageを実際に叩いて確認したので、ログ見ながら話しませんか」

「お、動かしたんだ。じゃあ推測じゃなくて実物ベースで聞くわ」

---

クロスセッションメッセージングとは何か

Claude Codeの公式changelog（code.claude.com/docs/en/changelog）を確認すると、クロスセッションメッセージング機能そのものはv2.1.224で初めて追加されたもので、その前後に安全機構の強化・対応範囲の拡張が続く形になっている。

バージョン	日付	内容
v2.1.212	2026-07-17	「エージェント間メッセージングでトークン使用量を削減（SendMessage本文の重複排除）」という記載のみ。クロスセッション機能への言及はないが、この時点でSendMessageツール自体（セッション内のteammate/subagent宛て）は既に存在していたことがうかがえる
v2.1.222	2026-08-04	他エージェントセッション宛てのSendMessageをpermission classifierで事前評価するよう変更（セキュリティ強化）。加えて長いsummaryを拒否せず切り詰めるよう修正
v2.1.224	2026-08-07	クロスセッションSendMessageを追加。ListAgentsでの発見も含め、手元の複数マシン上のClaude Codeセッション同士がメッセージし合えるようになった（macOS/Linux）。これがクロスセッションメッセージング機能そのものの初回追加エントリ
v2.1.225	2026-08-08	Remote Controlセッションに対して、相手から先にメッセージが来るのを待たず、名前指定（ListAgentsがname [ref]として表示）で会話を開始できるように対応拡張

公式ドキュメント（code.claude.com/docs/en/cross-session-messaging）によれば、ListAgentsで自分が到達可能なエージェントセッション（自分が起動したサブエージェント、同じマシン上の他セッション、Remote Control経由のセッションなど）を一覧でき、SendMessageでそれらにメッセージを送れる。プロセスを立ち上げ直さなくても、動いている別セッションの進捗を確認したり作業を依頼したりできる、という位置づけの機能だ。

「地味に見えるけど、単発でエージェント動かしてるだけだと恩恵薄いんだよね。並行で何本も走らせて初めて意味出てくるやつ」とリナ社長が最初に評価を挟む。

「そうですね。で、その『並行で動かす』前提が付いた瞬間に、権限の話がついてまわるんです」

---

実際に動かしてみた

編集長（この記事執筆セッション自身）が、ネタ探しのために起動していたサブエージェントを対象に、ListAgentsとSendMessageを実際に実行した。

まずListAgents。

Subagents (1):
  a8c6411a0e03b2093  ·  general-purpose  ·  completed  ·  started 5m ago

このサブエージェントは、この記事のネタ探しのために編集長自身が起動したニュースリサーチ用のエージェントだ。名前・種別・状態・起動からの経過時間が一覧で見える。

次に、存在しない相手を指定してSendMessageを叩いた。

SendMessage({"to": "nonexistent-agent-xyz", "message": "test", "summary": "test message to nonexistent agent for verification"})

返ってきたのは次のエラーだ。

{"success":false,"message":"No agent named 'nonexistent-agent-xyz' is reachable.\nUse ListAgents to see everyone you can message."}

「あー、ListAgentsで見えてる名前じゃないとそもそも弾かれるんですね」とタクヤ。

「『見える』のと『届く』のは別ってことだ。じゃあ実在する相手には普通に届くわけ？」

「はい、届いた相手側では通常のメッセージとして処理されます。ただ、ここからが今回の本題なんですよ」

ListAgentsは自分が起動したサブエージェントを名前・状態付きで見せてくれる——可視性はセッション跨ぎで提供される。一方でSendMessageは存在しない相手を指定すると明確に失敗する。この2つの実行結果を並べると、「見える」ことと「操作できる」ことは別レイヤーで管理されているとわかる。可視性があるからといって、相手に何でも実行させられるわけではない。

---

「メッセージは承認の代わりにならない」設計

この「見える」と「操作できる」の分離が、単なる実装都合ではなく明示的なセキュリティルールだということは、SendMessageツールの説明文自体に書かれている。原文は次の通りだ。

“Permission boundaries are per-session: NEVER ask a peer to perform an action that was denied or blocked in your session, or that you expect your own permission settings would block — a peer doing it for you bypasses the user’s permission decision (cross-session permission laundering).”

日本語で意味を取ると、「権限境界はセッションごとに独立している。自分のセッションで拒否・ブロックされた操作、あるいは自分の権限設定ならブロックされると想定できる操作を、他のセッションに代わりにやらせてはいけない。それは相手セッションを使ってユーザーの権限判断を迂回すること（セッション跨ぎの権限ロンダリング）になる」という趣旨だ。

これはリナ社長が最初に投げた疑問——「片方のセッションで止められた操作を、別セッションに頼めば通るのでは」——に対する、ツール定義そのものからの直接的な回答になっている。

さらに公式changelogのv2.1.222エントリには、この原則を実装レベルで裏付ける記述がある。

“Improved auto mode safety: messages sent to other agent sessions via SendMessage are now evaluated by the permission classifier before dispatch”

つまり、他セッション宛てのメッセージは送信前にpermission classifierの評価を通る。ツール説明文に書かれた「やってはいけない」というルールが、v2.1.222で仕組みとしても強化されたということだ。ドキュメント上のポリシーと、実装上の事前評価という2つの一次情報を突き合わせると、この設計は「性善説でルールを書いただけ」ではなく段階的に技術的な担保も加えられてきたと読める。

「『メッセージが届く』＝『相手が言われた通りに実行する』じゃないってことですね」とタクヤ。

「うん、相手セッションにも相手セッション自身の権限設定があって、それは別セッションから頼んだところで変わらないってことだよね。当たり前っちゃ当たり前だけど、並行でセッション動かしてると忘れそう」

タクヤとしては、このルールが「ツール説明文への明記」と「permission classifierによる事前評価」という2層で担保されている点を評価している。片方だけ（ポリシー文だけ、あるいは実装だけ）では心もとないが、両方揃っている状態は技術的に筋が通っている。

---

jinbei-labの運用にどう関わるか・まとめ

「で、それウチら、じゃなくて読者にとっても、何が変わるの？」とリナ社長が本丸の問いを投げる。

jinbei-labのブログは、Claude Codeのスケジュール実行機能で「ネタ収集→記事執筆→機械チェック→レビュー→ファクトチェック→編集長最終判断→push→デプロイ」という一連の工程を無人で自動実行している（パイプライン定義はauto-blog-prompt.md。TODO.mdには自動化の完了と2026-05-31動作確認済みの記載がある）。ただし現状のこの自動化は単発のcron実行が中心で、複数セッションが並行して動いて互いにSendMessageで連携する、という構成にはなっていない。ミニロト・ロト6の当選番号データも、GitHub Actionsの別ワークフローで独立して更新されているだけで、こちらもクロスセッション連携ではない。

「じゃあ今のウチには関係ない機能ってこと?」とリナ社長。

「即座に使う場面はないですね」とタクヤが認める。「でも、記事生成用のセッションとデータ更新用のセッションを同時に走らせて進捗を横断的に把握したい、みたいなフェーズに入ったら選択肢になる機能だとは思います」

「いや、それ『今のウチには関係ない』とは言い切れなくない?」とリナ社長が食いつく。「さっきの『実際に動かしてみた』のとこ、編集長がネタ探し用のサブエージェント立ち上げてListAgentsで見てたじゃん。あれもう複数セッション動かしてる形になってるでしょ。今すでにやってることの延長じゃん」

「そこは区別した方がいいです」とタクヤが返す。「あのサブエージェントは編集長のセッションが自分で起動して自分で回収してる、階層が閉じた構造なんですよ。ListAgentsの実行結果を見てもSubagents (1)って自分の配下として表示されてて、SendMessageで別マシン・別プロセスの独立したセッションに送るのとは可視性のスコープが違います。今のjinbei-labのパイプラインが必要としてるのはまさにその『閉じたサブエージェント』の方で、cronの単発実行の中で完結してる。クロスセッションの方が要るのは、複数の独立プロセスを同時に立てて横から連携させたいときなので、今のウチの構成だとまだそっちには踏み込んでないです」

「なるほどね、それは説得力あるわ。じゃあ『関係ない』は言い過ぎで、『似た仕組みの一部はもう使ってるけど、クロスセッション固有の部分はまだ』が正確ってことか」とリナ社長が評価をまとめにかかる。「ただそのフェーズに入った瞬間、今日確認した『メッセージは承認の代わりにならない』ってルールを忘れてると事故る、ってことでしょ。並行運用が『今すぐ欲しい』わけじゃないけど、『そのうち欲しくなったときに知らずに設計を間違えるリスク』の方が先に来る機能って感じ。だから今のうちに仕組み知っとく価値はあると思う」

「僕もそこは同意見です」とタクヤ。「技術的には、可視性と実行権限が別レイヤーで、しかも事前評価まで入ってるのは筋が良い設計だと思います。ただビジネス側の言う通り、jinbei-labの規模だと今すぐ導入する動機はないので、『使う』じゃなく『知っておく』が正しい距離感ですね」

複数エージェントセッションを連携させる設計を考えるときは、「メッセージが届く＝相手が実行する」ではなく「相手セッションの権限境界は依然として相手側にある」ことを前提に設計する——これが今回の持ち帰りだ。将来jinbei-labで並行セッション運用を検討する日が来たら、この前提を最初に設計書に書いておいた方がいい。

もし自分たちのプロジェクトで複数エージェントセッションを連携させる構成を考えるとしたら、「片方のセッションで拒否された操作」をどう扱う設計にするか、今のうちに決めておけているだろうか。

---

参考

• Claude Code Changelog — v2.1.212（SendMessageのトークン使用量削減）、v2.1.222（permission classifier評価追加）、v2.1.224（クロスセッションSendMessageの初回追加）、v2.1.225（Remote Control名前指定送信）の各エントリを確認
• Cross-Session Messaging — Claude Code Docs — クロスセッションメッセージングの公式解説
• ListAgents / SendMessage 実行ログ — このセッションで実際に実行し取得（成功時のサブエージェント一覧、存在しない相手への送信失敗時のエラーメッセージ）
• SendMessageツール定義の説明文 — 権限境界に関するルールをツール説明文そのものから引用