Claude Code の Agent Team が突然動かなくなった — TeamCreate 削除（v2.1.178）の裏取りと追従術

📖 背景 — Agent Team が、ある朝いきなり動かなくなった

ある朝、Claude Code の Agent Team が動かなくなった。 正確には、Agent Team を使って TDD を回していた自作 command（Red → Green → 検証を連続実行するもの）が、起動した瞬間にエラーで止まった。2 日前まで何事もなく動いていたものが、だ。

Claude Code の CLI は頻繁に自動更新される。ありがたい一方で、experimental（実験的）機能の API 形状は予告なく変わる。今回まさにそれを踏んだ。原因は、CLI の自動更新でマルチエージェント機能（Agent Team）の入口ツール TeamCreate / TeamDelete が削除されたことだった。

ただ「動かない」で終わらせず、憶測ゼロで一次ソースから原因を確定し、公式の後継へ正しく追従する——その手順を再利用可能なテンプレートとしてまとめる。題材は Agent Team の TeamCreate 削除だが、手法はあらゆる破壊的変更に効く。

裏取りは Anthropic 公式 CHANGELOG・Agent Teams 公式 docs を 2026-06-23 時点・Claude Code v2.1.186 で確認している。

🔍 症状 — ツールが「無い」

自作 command は、マルチエージェントのチームを TeamCreate で作る前提で書かれていた。それが、こう壊れた。

• 実行すると TeamCreate 系の処理が動かない
• harness が提示する deferred ツール一覧（<system-reminder>）に SendMessage / Monitor / TaskCreate 系はあるのに、TeamCreate だけが無い
• ツール検索でも TeamCreate が返らない

ここで「なんか壊れた、たぶんバグ」で済ませると再発する。ツールの有無は観測できる。観測で詰める。

🧪 裏取りの方法論 — 5 つの一次ソース

破壊的変更を疑ったら、次の 5 点を順に当たる。いずれも一次ソースで、推測が一切入らない。

① ツールレジストリ — まず「棚卸し」

最初にやるのは、自分の環境で実際に使えるツールを実地で棚卸しすること。ツール検索で名指しすると、TeamCreate は No matching deferred tools found を返した。一方 SendMessage / Monitor は返る。「協調用ツールは生きているが、作成ツールだけ消えた」という非対称が、ここで見える。

② CHANGELOG の grep — 決定的証拠

Claude Code はローカルにも CHANGELOG をキャッシュしている。公式 GitHub の生ファイルと両方を grep すると、v2.1.178 のエントリにこうあった。

## 2.1.178
- Agent teams: removed the `TeamCreate` and `TeamDelete` tools.
  With `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` set, every session now has
  one implicit team — spawn teammates directly with the Agent tool's `name`
  parameter, no setup step needed. The `team_name` parameter on the Agent
  tool is still accepted but ignored.

これで「なぜ消えたか」「何に置き換わったか」が公式の言葉で確定する。grep 一発で済む。CHANGELOG を読む癖がそのまま裏取りになる。

③ 公式 docs — 仕様の正典

Agent Teams 公式 docs には、ご丁寧に “This page describes agent teams as of v2.1.178” の Note があり、こう明記されている。

Before v2.1.178, you asked Claude to create and name a team first, and Claude used the TeamCreate and TeamDelete tools to set it up and remove it. Both tools no longer exist. The team_name input on the Agent tool is accepted but ignored […] and is deprecated.

CHANGELOG が「変更点」なら、docs は「あるべき姿」。後継 API の正しい呼び方は docs で確定させる。

④ 更新ログ — 「いつ跨いだか」

「2 日前は動いていた」という記憶が正しいかも確認できる。~/.claude/.last-update-result.json に自動更新の記録が残っている。

{ "timestamp": "2026-06-22T20:52:11Z", "version_from": "2.1.185", "version_to": "2.1.186", "outcome": "success" }

削除は v2.1.178。記録は 2.1.185 → 2.1.186。つまり数日前まで ≤2.1.177 で動かしており、自動更新の過程で削除版を跨いだ。記憶は正確だった、と裏が取れる。「自分の勘違いでは」という疑いをここで潰せる。

⑤ strings — 機構が死んだのか、入口だけか

最後に、これが効く。ツールが消えた = 機能ごと消えた、とは限らない。バイナリを strings で覗くと、現行 v2.1.186 でもこうなっていた。

$ strings $(which claude) | grep -oiE "TeammateTool|SendMessage|spawnTeam|TeamCreate" | sort | uniq -c
     65 SendMessage
      4 spawnTeam
      3 TeamCreate     ← 残骸（deprecation / 互換用）のみ
     56 TeammateTool   ← 機構は健在

TeammateTool / SendMessage / spawnTeam の実装はまるごと残っている。TeamCreate は残骸が 3 回見えるだけ（team_name の「accepted but ignored」互換処理など）で、レジストリには登録されていない。

結論：teammate を動かす機構そのものは生きていて、削除されたのは「team を作る入口ツール」だけ。①〜③ の「協調ツールは生存・作成ツールだけ消滅」という非対称が、ここで腑に落ちる。

🧭 確定した事実

5 つの一次ソースが、推測抜きで同じ絵を指す。

• TeamCreate / TeamDelete は v2.1.178 で削除された
• 後継は 「セッションごとに暗黙の team が 1 つ」＋ Agent ツールの name 引数で直接 spawn。事前のセットアップ手順は不要、終了時に自動クリーンアップ
• team_name は accepted but ignored（hook payload の team_name も deprecated）
• 協調プリミティブ SendMessage（teammate へ直接送信）は存続。teammate 同士・Lead との通信はこれで行う
• 有効化フラグは CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1（従来どおり）

⚠️ 勘違いしてはいけない — これは「GA 化」ではない

ここが要注意点だ。v2.1.178 で起きたのは experimental 機能の API 形状の変更であって、ステータスが experimental → GA に変わったわけではない。Agent Teams は今も実験的機能で、フラグ前提のままである。公式 docs 冒頭も明言している。

Agent teams are experimental and disabled by default. Enable them by adding CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS […]. Without that variable, no team is set up at session start […].

GA かどうかは挙動でも確認できる。GA なら通常フラグ無しでも team 系ツールが出るはずだが、現状はフラグを立てて初めて出る。つまり「入口の形が変わった」だけで、成熟度の段階は据え置き。

運用判断としては一貫させる。CTS-EC のソロ・逐次中心のワークフローでは以前から 「評価のうえ deferred（常用しない）」という結論だったが、ステータス的にもまだ前のめりに常用するフェーズではない。API が変わったことと、常用すべきかは別問題だ。破壊的変更に振り回されないためにも、experimental は「使うかどうか」を別途判断し続ける。

そもそも Agent Team は運用が「面倒」な機能だった

正直に書くと、今回入口ツールが消えても痛手は小さかった。Agent Team の split-pane 運用は元々それなりに面倒だからだ。bypassPermissions を DevContainer 内に閉じ込めて安全に使い、tmux をセットアップし、VS Code 統合ターミナルでは split-pane が成立しないので別ターミナルから入る——この手間と前提条件は、Agent Teams 編（bypassPermissions / DevContainer / tmux の安全運用）で詳述したとおりで、ここでは繰り返さない。

つまり「常用は deferred」という判断は、ステータス（experimental のまま）だけでなく運用コスト（tmux + bypassPermissions の手間） の面からも妥当だった。今回の TeamCreate 削除は、その判断を裏側から後押しした格好になる。面倒で常用していなかった機能の入口が消えた——だから慌てる必要はなく、淡々と裏取りして追従すれば済んだ。experimental に深く依存しないという普段の姿勢が、破壊的変更のダメージを最小化していた。

🔁 追従 — 旧方式から新方式への置換マップ

確定したら、自作 skill / command を公式の後継に書き換える。やることは機構の差し替えだけで、設計思想は変えない。

書き換えの実務ポイントは 3 つ。

1. team_name への依存を全部抜く（渡しても無視されるので、残すと誤解の元）
2. ツール検索の対象から TeamCreate を外し、SendMessage / Monitor に直す（棚卸しで見当たらないツールを前提にしない）
3. subagent 定義を teammate として再利用できる。.claude/agents/ のロールを subagent_type に指定すれば、その tools allowlist と model を尊重したまま teammate として spawn される（公式 docs 記載）

なお、入口ツールに依存しない subagent（fire-and-forget）の連鎖は今回の変更の影響を受けない。teammate 間通信が要らないなら、そもそも Agent Teams ではなく subagent で組むのが、破壊的変更に対して堅い。

🛠️ 実例 — 自作 TDD command を Agent+SendMessage に書き換える骨子

上の対応表を、実際の自作 command（TDD を Red → Green → 検証まで連続実行するマルチエージェント command）に落とすとどうなるか。機密を除いた設計の骨子を示す。机上の対応表ではなく、現に動いている形だ。

なぜ「TDD」command なのか

この command が TDD を軸にしているのは偶然ではない。TDD は AI 駆動開発の肝だからだ。AI エージェントはコードを大量・高速に書けるが、それは同時に「もっともらしいが間違ったコード」も高速に生む。先にテスト（仕様）を固定し、それを満たすことだけを実装の合格条件にする——この縛りが、AI の生産性を暴走させず正しさに収束させる唯一の安全装置になる。テストは AI 時代に「書く手間」から「AI を御する手綱」へと役割が変わった。詳しくはTDD 編 — AI エージェント時代の「superpower」に書いたとおりで、本記事のマルチエージェント編成もその思想の実装にすぎない。

だから役割分担も TDD の順序そのものに対応する。テストを書く者（test-writer）と実装する者（implementer）を分離し、テストを「動く仕様」として独立に検証（test-reviewer）してから実装に渡す。AI が自分の実装に都合よくテストを書き換える事故を、責務分割で構造的に防ぐ。

6 体の専門エージェント — ハーネス＋ステアリングの真骨頂

正直、ここは自慢させてほしい。ステアリング（仕様の単一情報源）× ハーネス（層で責務を分離）× 専門特化したエージェント群が噛み合うと、AI に「TDD を最初から最後まで自走」させられる。その心臓部が、責務をきれいに分けた次の 6 体だ。Lead（Opus）は自分で production / test を一切書かず、調整と state 保持に徹し、各エージェントを Agent で named background agent として spawn して SendMessage で駆動する。

設計の妙は 3 つ。①責務分割が TDD の順序そのもの——テストを書く者と実装する者を分け、テストを独立に検証してから実装へ渡すことで「AI が自分の実装に都合よくテストを書き換える」事故を構造的に封じる。②model tiering で知能をコスト最適化——判断の重い Lead とレビューに Opus、定型作業の worker は Sonnet に寄せ、全 spawn で model を明示しないことで agent 定義の tier を効かせる（後述 ②）。③Gate を最後に 3 重化——機械チェック・設計レビュー・多観点検証を別人格に分け、観点の重複と見落としを同時に減らす。

各エージェントの定義（責務・tools:・model）は .claude/agents/<name>.md に 1 ファイル 1 役割で置く。「仕様はステアリング、責務はエージェント、変わりやすいものは層に隔離」——この三位一体が、TeamCreate 廃止のような破壊的変更が来ても骨格を保てた理由でもある。

Phase 0  通信路ヘルスチェック（PONG）→ 継続可否を判定、不可なら fallback 宣言
Phase 1  Red 作成（test-writer）↔ 網羅性レビュー（test-reviewer）の収束ループ（最大 2 周）
Phase 2  実装（implementer）— レビュー済テストを緑にする。テスト追加・修正は禁止
Phase 3  pre-push 3 ゲートを並列実行 → 全 PASS でも STOP（push はユーザー承認後）

書き換えで効いた、他の自作ツールにもそのまま移植できる勘所は次の 6 つ。

① spawn は Agent、継続は SendMessage — 再 spawn しない

teammate は名前付き background agent として 1 度だけ spawn し、以降は同じ名前へ SendMessage で継続する。fresh context で起動し直すコールドスタートと再説明を避けられる。

# 初回だけ spawn（name が以降の宛先になる）
Agent(subagent_type: "test-writer", name: "test-writer", run_in_background: true, prompt: ...)

# 2 回目以降は同じ agent に継続（context 保持）
SendMessage({ to: "test-writer", message: "mode:1c（R1 指摘の反映のみ）…" })

② model tiering — 呼出時に model を書かない

Agent の model 解決は「呼出時 model → agent 定義 frontmatter → 親から継承」の順。呼出時 model を省略すると .claude/agents/<name>.md の model: が効き、worker は意図した tier（例：worker=Sonnet、レビュー系のみ Opus）で起動する。ここで model: "opus" などと書くと Lead の知能が worker に継承され、コストが膨らむ。「全 spawn に model キーが 1 つも無いこと」を不変条件にする。

③ SendMessage は tools: に列挙しなくても使える（公式仕様）

ここは移行時に誤解しやすい。「teammate は tools: 許可リストのツールしか持たないのだから、SendMessage を明示列挙しないと Lead と通信できないのでは」と考えがちだが、公式仕様では協調ツールは常時利用可能だ。docs にこう明記されている。

Team coordination tools such as SendMessage and the task management tools are always available to a teammate even when tools restricts other tools.

つまり SendMessage やタスク管理ツールは、tools: が他のツールを制限していても teammate に自動注入される。agent 定義に - SendMessage と書いても無害だが、必須ではない。「通信できないのは tools 列挙漏れのせい」と決めつける前に、まずこの公式仕様を当たること——思い込みより一次ソース、という本記事のテーマがここにも効く。

④ Phase 0 で通信路を疎通確認し、fallback を用意する

本番ループに入る前に、teammate へ「応答に PONG を含めて」と投げて SendMessage 継続が効くか確かめる。効かない環境なら full-context を prompt に詰めた Agent 再 spawn に自動で切り替える。結果の主経路は Agent の戻り値（最終メッセージ）で常に信頼でき、SendMessage はあくまで context 保持の副経路、という整理が fallback を成立させる。

⑤ レビュー指摘は要約せず verbatim で file に逃がす

test-reviewer の指摘（具体テスト案を含む）は、Lead の長期 context に積むと汚れる。全文を .claude/tmp/ 配下の file に verbatim で書き出し、test-writer には path を渡して Read させる。要約すると改善案が落ちて収束が遅れる。context 衛生と再現性の両取り。

⑥ 独立した検証は 1 メッセージで並列発行する

Phase 3 の 3 ゲート（pre-push / code-review / implementation-validation）は観点が重複しない。1 つのメッセージ内で 3 つの Agent を同時に発行して並列実行し、wall-clock を縮める。ただし全 PASS でも push はしない——完了報告して STOP し、ユーザー承認を待つ（破壊的操作は人間が最終ゲート）。

この 6 点はいずれも Agent Teams 固有ではなく、「named agent を spawn して継続駆動する」あらゆる自作ツールに効く。TeamCreate 廃止のような破壊的変更が来ても、機構（spawn + 継続 + 検証）を入口ツールから切り離してあれば、差し替えはこの粒度の書き換えで済む。

📌 ついでに見つかった周辺の陳腐化

同じ Agent Teams 機能で、TeamCreate 以外にも更新で変わった点があった。裏取りの過程で拾えたので記録しておく（古い記事・古い手順書を直すときの参考に）。

特に teammateMode 既定が "auto" → "in-process" に変わったのは要注意。アップグレードしたセッションは、明示設定しない限り従来出ていた split-pane が出なくなる。「pane が出ない＝壊れた」ではなく既定変更だ。また VS Code 統合ターミナルは split-pane 非対応なので、拡張のチャットから起動して tmux ペインを期待しても成立しない——これも公式の裏付けがある。

🧰 再発防止 — 破壊的変更に強いハーネス設計

最後に、同じ目に遭いにくくする設計の話。experimental を触る以上、破壊的変更はまた来る。来る前提で備える。

• 入口ツールに密結合しない。 「TeamCreate ありき」で書くと、入口が消えた瞬間に全部止まる。機構（teammate）と入口（作成ツール）を分けて考え、入口が変わっても設計が生き残る形にする。
• fallback を最初から組み込む。 ツールの有無を実行時に判定し、無ければ subagent 連鎖など別経路に落とす。今回の自作 command も「TeamCreate 不在時は Agent ツールへ fallback」を持っていたため、致命傷にはならなかった。
• CHANGELOG 監視を運用に入れる。 experimental に依存している機能があるなら、更新のたびに該当キーワードを grep する癖をつける。grep -i <feature> CHANGELOG.md は 1 秒で終わる保険だ。
• experimental は「使うか」を別途判断し続ける。 API が変わっても、常用フェーズに入ったとは限らない。成熟度（GA かどうか）と利便性は分けて評価し、deferred なら deferred で一貫させる。
• モデル・機能依存の記述を層に閉じ込める。 7 層ハーネス・Opus 4.8 移行で繰り返した原則と同じ。変わりやすいものを特定の層に隔離しておけば、破壊的変更の影響範囲をその層に閉じ込められる。

✅ まとめ

• Agent Team が突然動かなくなった——原因は CLI 自動更新で TeamCreate / TeamDelete が v2.1.178 で削除されたこと。記憶（2 日前は動いていた）は正確で、更新ログで裏が取れた
• 裏取りは 5 つの一次ソース（①ツール棚卸し ②CHANGELOG ③公式 docs ④更新ログ ⑤strings）で、憶測ゼロで確定できる。これはあらゆる破壊的変更に効くテンプレ
• strings まで見ると 「機構は生存・入口ツールだけ削除」と分かる。後継は 暗黙 team ＋ Agent の name ＋ SendMessage
• これは experimental の API 形状変更であって GA 化ではない。フラグ前提は据え置き。API 変更と常用判断は別問題として一貫させる
• そもそも Agent Team の tmux + bypassPermissions 運用は面倒で常用を見送っていた（別記事で詳述）。だから入口が消えても痛手は小さく、deferred 判断とも整合した
• 追従は 置換マップに沿って機構を差し替えるだけ。team_name 依存を抜き、SendMessage 前提に直す。teammate 間通信が要らないなら subagent で組む方が堅い
• 再発防止は 入口に密結合しない・fallback を持つ・CHANGELOG を grep する。変わりやすいものを層に隔離するハーネスエンジニアリングの原則そのもの

experimental を使うなら、壊れることは織り込み済みにする。大事なのは壊れたときに慌てず、推測せず、一次ソースで詰めること。ツールは観測できる。観測で勝つ。

🔗 参考資料

• Claude Code CHANGELOG（anthropics/claude-code） — v2.1.178 の TeamCreate / TeamDelete 削除エントリ
• Orchestrate teams of Claude Code sessions — 公式 docs — 暗黙 team / Agent name spawn / SendMessage / 表示モード / Limitations の正典

🔗 関連記事

• 開発手法ガイド：TDD 編 — AI エージェント時代の「superpower」 — 本記事の TDD command が依拠する「なぜ TDD が AI 駆動開発の肝か」の正典
• Agent Teams 編：12 体のサブエージェント構成とマルチエージェント並列協調 — チーム構成と並列協調の運用（一部 v2.1.178 以前の記述を含む）
• Claude Code を Opus 4.7 → 4.8 に移行する — モデル世代交代を層で吸収する姉妹編
• Claude Code 7層ハーネスエンジニアリング — 変わりやすいものを層に隔離する設計の上位概念

🔗 関連用語

• Claude Code — 本記事の対象 CLI
• Agent Teams — 本記事が扱う実験的機能
• ハーネスエンジニアリング — 破壊的変更の影響を層に閉じ込める構造
• コンテキストエンジニアリング — レビュー指摘の verbatim 逃がしなど context 衛生の設計思想
• SSOT（信頼できる唯一の情報源） — ステアリング＝仕様の単一情報源という前提
• DevContainer — bypassPermissions を安全に閉じ込める実行環境
• tmux — split-pane 表示モードで使う端末多重化ツール