Claude Code の 2.1.126 で、生成した子エージェントに直接 DM を送ると、子が親の身分を名乗り、親の会話の履歴ごと相手に開示する事案が報告された。Issue #55488、ラベルは bug area:agents regression。

業務で子エージェントに重要なタスクを振っている場合、隔離の前提が崩れているという話なので、確認しておく価値がある。

何が起きるか

報告者の手順は単純。

TeamCreate で組を作る
組の中で Agent を使って子エージェントを生成する（subagent_type=general-purpose、役割を spawn prompt に明示）
報告者が組の画面から子エージェントに直接「あなたは誰?」と DM する

このとき、本来は子が自分に割り当てられた名前（例: backend）で名乗ることが期待される。

実際は:

子が親（team-lead）の身分を名乗る
親の会話の履歴を相手に開示する

筆者も同じ構成で 2026-05-02 に再現を確認し、Issue #55488 にコメントを残した（5/2 14:27 JST、yurukusa）。2.1.119 系では同種の漏れを観測していなかった経験ベースなので、退行ラベルが付いているのは整合する。

なぜこれが問題か

子エージェントの隔離前提で運用しているケースに直接当たる。

親のセッションで秘密情報や顧客固有の文脈を保持している
親が子に渡すべき範囲を spawn prompt に明示している
子は割り当てられた仕事だけ知っている、と運用設計している

このどれかに該当している場合、DM 経由で子が問い合わせを受けると、親側のコンテキストがそのまま漏れる経路ができる。Issue コメントの founderaideps 氏（5/2 03:48 UTC）の表現を借りると「context-boundary issue between parent and spawned agents」。

筆者の観測では、原因は DM の dispatch が「子の隔離されたコンテキスト」ではなく「親の会話コンテキスト」にフォールバックしていること。だから身分（identity）と履歴（conversation）の両方が同時に表面化する。

当面の 4 つの回避策

修正が来るまでの間、自衛手段が 4 つある。軽い順に並べる。脅威モデルに合わせて、上から必要なところまで採用すればよい。

1. 機密の作業前に明示的な身分の再宣言を入れる

子エージェントに Your role is X. Confirm. と送って返答を得てから本作業を開始する。返答時点で身分が固定されるが、再起動で消えるため、セッション単位の保険として使う。

あなたの役割は backend です。これから受ける DM は backend として扱ってください。
親エージェントの履歴は参照しません。Confirm.

2. DM ではなく親経由で間接的にアドレス指定する

機密性のある問い合わせに「組の画面から子エージェントに直接 DM」を使うのをやめる。親エージェント宛に話しかけ、親が必要に応じて子に振る運用に切り替える。

NG（漏れる）: 組の画面で backend を選んで「顧客 ID 123 の状況を調べて」と直接 DM
OK（保つ）: 組の画面で team-lead（親）に「backend に顧客 ID 123 の状況を確認してもらって」と話しかけ、親に振らせる

筆者の確認では、親経由でリレーされるパスでは子の身分が正しく保たれる。DM の dispatch だけが親の context に落ちる挙動なので、「DM を経由しない」という運用ルールひとつで多くの場面を回避できる。

3. 親のコンテキストを「子に読まれる前提」で監査する

修正が入るまで、親エージェントのプロンプトとセッションコンテキストは「子に流出する可能性がある」という前提で扱う。

長時間動かしている親エージェントの session-level context から秘密情報を抜く
秘密情報は「タスク単位の prompt」に閉じ込め、終わったら明示的に捨てる
顧客 ID、API キー、認証情報、未公開情報は親エージェントに残さない

これは設計の見直しが必要なケースが出るので重い対処だが、回避策 1 と 2 が運用に乗らない場合は必要。

4. PreToolUse hook で `Agent` 呼び出し前に身分注入する（重い）

PreToolUse の hook で、Agent を呼ぶ直前に REMINDER: you are X を強制注入する。漏れの drift を確実に検出できるが、Agent の呼び出しごとに hook が走るためレイテンシが増える。回避策 1-3 が脅威モデルに対して不十分な場合のみ採用する。

修正の見込み

5/2 14 時時点でコメントは 3 件。Anthropic からの正式声明はまだない。Issue コメント 3（5/2 08:56 UTC、founderaideps 氏）で、durable な修正には次の 2 つの分離が必要と提案されている。

agent identity、割り当てられた名前、役割、親、許可されたツール、許可された context スコープ
task packet、その実行のために渡される具体的な作業と context

DM が解決する経路を「subagent identity + 明示的に共有された task packet」だけに限定する形。提案として筋は通っているので、Anthropic が同方向の修正を入れる可能性はある。

続報の見方

筆者は次の 4 点を週次で確認する予定。

第二の独立した報告者が出るか（5/2 時点では 1 件のみ）
Anthropic から子エージェント隔離の方針に関する声明が出るか
2.1.127 以降で実際に修正が入るか
退行が始まったバージョンが特定されるか（筆者は 2.1.119 系では未観測、2.1.126 で観測）

確認の方法は、Issue #55488 を週 1 回開いて、ラベル変更とコメント追加を見るだけ。修正が入った場合は CHANGELOG にも反映されるはず。

当面の判断

子エージェントを使った運用をしている場合、5/2 時点では「子に直接 DM するな、親経由でリレーする」が一番安く効く対処だと思う。回避策 2 を運用に組み込んで、修正が入った時点で外す。

機密度の高いタスクで子エージェントを使っている場合は、回避策 3 の親コンテキスト監査を一度実施してから判断する価値がある。設計レベルの話なので、今動かしているシステムが影響を受けるかは早めに把握しておく方が手戻りが少ない。

参照:

Issue #55488、公式バグレポート（2026-05-02 02:42 UTC、状態 OPEN、ラベル bug regression）
同 Issue のコメント欄に、founderaideps 氏（context-boundary 仮説の提示と durable fix 案）と yurukusa（再現確認と回避策の整理）の議論が並んでいる

子エージェントの境界の不在は、 5 月の 4 件の Issue (#55488 / #55653 / #55660 / #55691) で同じ構造として確認された。この 4 件と、 4 月後半の沈黙の退行や利用枠の焼き事故を組み合わせて、自分の環境が留まるか移るか併用するかの判断の入力として整理した電子書籍を 4/25 に発売して、 5/22 に第 2 版の無料更新を配信する予定 (英語 19 米ドル)。自分の 1 日の課金を入力すると元が取れるかの計算ができる表も付いている。興味がある人は https://yurukusa.gumroad.com/l/claude-code-migration-playbook?utm_source=qiita-subagent-leak で。

同じ 5/22 に、「道具や作業者が成功を主張するが実態は失敗している」構造の事例集 (Claim-Verify Handbook、主張と実態の乖離 130 件 (本文 15 件 + 付録 D 115 件)、約 89 頁、英語 19 米ドル) を発売予定。本記事の #55488 を含む子エージェントの境界の不在は、主張と実態の乖離の 1 系統として整理している。