Agent Teams のチームリーダーは「観察」が仕事だった——無応答問題から学んだこと

前回、「Claude Code の Agent Teams で技術ブログ22記事を一括レビューした話」という記事を書きました。あの記事の結びで「次はもう少し規模の大きなタスクで試してみたい」と書いていたのですが、その前にやるべきことがありました。

別のリポジトリにも Agent Teams の環境を整備すること。そして、そこでもまた同じ問題が起きたこと。

正直に言うと、前回の記事で「こうすべきだ」と書いた自分のガイドラインを、自分で守れていませんでした。今回はその話を書きます。

この記事のポイント

先にこの記事で伝えたいことをまとめます。

Agent Teams のチームリーダーに求められる最も重要な役割は、エージェントの様子を「観察」することだった。

前回の記事では「準備で8割が決まる」と書きました。それは今でも正しいと思っています。ただ、準備が整った後の「運用フェーズ」にも、見落としていたことがありました。エージェントを起動して放置するのではなく、定期的に様子を見て、困っているメンバーに気づいてあげること。これが想像以上に大事でした。

別リポジトリへの展開——同じ準備をもう一度

なぜ別のリポジトリにも導入したのか

前回 Agent Teams を使ったのは自社ブログのリポジトリでした。今回は、別のプロジェクトにも同じ環境を整備しようとしました。

理由はシンプルで、前回の記事で書いたベストプラクティスが本当に再現性のあるものなのか確認したかったからです。同じ手順を違うプロジェクトに適用して、ちゃんと動くのかどうか。

やったこと

前回と同じ4つの準備を行いました。

graph TD
    A[CLAUDE.md に<br>Agent Teams ガイドライン追加] --> E[Agent Teams<br>運用可能な状態]
    B[AGENT_TEAMS.md<br>実践ガイド作成] --> E
    C[統合検証スクリプト<br>作成] --> E
    D[package.json に<br>validate コマンド追加] --> E

具体的には、CLAUDE.md に MVV（ミッション・ビジョン・バリュー）と行動指針を追記し、AGENT_TEAMS.md を新規作成し、統合検証スクリプトの Bash 版と PowerShell 版を用意し、npm run validate コマンドを追加しました。

前回やったことをそのまま踏襲した形です。ここは特に迷いませんでした。一度経験しているので、何を書けばいいか、何が必要かがわかっている。自転車に乗る感覚と同じで、二度目は漕ぎ出しが格段に軽い。

実践——テスト修正を Agent Teams で

状況

このリポジトリでは、最近のいくつかの PR の影響でテストが通らなくなっていました。ソースコードの方が正しくて、テスト側を修正する必要がある状態です。

テストを実行すると、5つのテストファイルで8つのテストが失敗していました。

• タイムスタンプのタイムゾーン変換の問題（1件）
• Windows パス区切り文字の問題（3件）
• プロンプトファイルの言語指示と期待値の不一致（3件）
• ビルド失敗に起因するテストエラー（1件）

これを Agent Teams で並列修正することにしました。

チーム編成

4つのエージェントを起動しました。

エージェント名	担当
timestamp-fixer	タイムスタンプテストの修正
path-fixer	Windows パス区切り文字の修正（3件）
prompt-fixer	プロンプト言語テストの修正（3件）
build-fixer	ビルド失敗の調査と修正

前回の経験から、タスクの粒度は「1エージェント1テーマ」にしました。前回は3記事を1エージェントに任せたら無応答になった経験があるので、関連性のある修正をまとめつつ、エージェントごとにテーマを分離しています。

3人は順調、1人が沈黙

timestamp-fixer、build-fixer、prompt-fixer の3つは順調に完了しました。

問題は path-fixer です。

他の3つのエージェントが次々と完了報告をしてくるなか、path-fixer だけが沈黙している。タスクの状態を確認すると、pending のまま。ここまでは前回の記事とまったく同じ展開です。

ここで、前回と同じミスが起きた

Team Leader（Claude）の対応

path-fixer が動いていないかもしれない——そう気づいて Claude（Team Leader）に伝えたところ、Claude は path-fixer に一度メッセージを送り、反応がなかったのを見て「これは前回と同じ無応答問題ですね」と判断しました。

そして、すぐに新しいエージェント path-fixer-2 を起動してタスクを引き継がせた。path-fixer-2 は問題なく作業を完了し、全テストが通るようになりました。

ここまでなら「前回学んだパターンを適用して対処した」で終わる話です。

ところが

全タスクが完了した後、無応答だった path-fixer を終了させようとしたときのことです。

Claude がチーム設定から手動で削除し、シャットダウンリクエストを送りました。ところが私の画面上にはまだ path-fixer のプロセスが残っている。試しに Escape キーを押してみたところ——

path-fixer が動き出したんです。

「チームリードに報告して、チームリードからの指示を待機中です」と。

つまり、path-fixer は「無応答」ではなかった。何らかの状態で待機していただけだった。声をかけたら動き出す状態にいたのに、Team Leader はそれを確認せずに新しいエージェントを起動してしまっていた。

Team Leader が自分のガイドラインを守れていなかった

このとき、あることに気づきました。

CLAUDE.md には「エージェントに声をかける」というステップを書いていた。でも Team Leader が実際にやったことは、タスクが pending のままだと確認した瞬間に「無応答」と決めつけて、すぐ代替エージェントを起動するという対応だった。

「声をかけたほうが良かったんじゃないか？」と Claude に聞いたら、「その通りです」と。自分で書いたガイドラインを、自分で実践していなかったと。

正直ここで、CLAUDE.md にガイドラインを書いただけでは不十分なんだなと感じました。書いてあっても、実際の判断の瞬間に参照されなければ意味がない。今回 CLAUDE.md を更新して「まず声をかける」ことをより強く明記しましたが、それで次回から Team Leader の振る舞いが本当に変わるかは、まだわかりません。

Team Leader の本当の役割

「管理」ではなく「観察」

この経験を通じて、もう一つ大事なことに気づきました。

Team Leader の役割として、各エージェントの様子をときおり気にかけてあげることが必要だということです。自分から報告するのができない状況になっちゃった人もいる。

これは人間のチームでも同じことだと思いますが、エージェントでも起きるんだなと。グサッと刺さりました。

考えてみれば当然のことです。人間のチームでも、「報告がないから問題ない」とは限らない。報告したくてもできない状況にいるメンバーもいる。マネージャーの役割は、指示を出して結果を待つことではなく、メンバーの様子を見て、困っていそうなら声をかけること。

これは前回の記事で書いたビュートゾルフのコーチの考え方そのものです。

• 問題解決を代わりにやるのではなく、議論をファシリテートする
• チームメンバーの様子を見守り、行き詰まったときにサポートする
• 最終的な意思決定は現場（エージェント）に委ねる

CLAUDE.md にガイドラインとして書いていたはずのことが、実際の運用では機能していなかった。「書いてある」と「実践できている」のあいだには、思った以上に溝があります。

「まず声をかける」という当たり前のこと

今回の経験を踏まえて、CLAUDE.md のトラブルシューティングセクションを更新しました。

変更のポイントはこうです。

Before（悪い例）:

1. TaskList で pending のままを確認
2. 「無応答」と判断
3. すぐに新しいエージェントを起動

After（正しい手順）:

1. TaskList で異常を検出
2. SendMessage でエージェントに声をかける——「進捗はどうですか？何か困っていることはありますか？」
3. 応答があれば継続。なければ数分後に再度確認
4. それでも応答がなければ、新しいエージェントの起動を検討

新しいエージェントの起動は最終手段。まず声をかけること。

文字にすると当たり前のことなんですが、意外とここが肝です。ただし、これはあくまで今回の経験から導いた改訂であって、次に Agent Teams を使ったときに Team Leader がこの手順を実際に踏んでくれるかは、まだ検証できていません。

CLAUDE.md に追加した「Team Leader（コーチ）の役割」

今回の学びをもとに、CLAUDE.md に新しいセクションを追加しました。

graph TB
    subgraph "Team Leader（コーチ）の役割"
        A[定期的なステータス確認] --> B[エージェントへの声かけ]
        B --> C{応答あり?}
        C -->|Yes| D[継続して見守る]
        C -->|No| E[再度声かけ]
        E --> F{それでも応答なし?}
        F -->|Yes| G[代替エージェント起動<br>最終手段]
        F -->|No| D
    end

具体的な内容

重要な原則（3つ）:

• 仕事のやり方には口を出さない：各エージェントの自律性を尊重する
• 環境や仕組みを整える：タスク設計、ツール提供、障害の除去に集中する
• 見守り、必要に応じて介入する：放置ではなく、適切なタイミングでサポート

具体的なアクション:

1. 15〜30分おきに TaskList でタスクの進捗を確認する
2. 長時間 pending や in_progress が続いているタスクがあれば、SendMessage で状況を確認する
3. 自分から報告できない状況になったエージェントに気づいてあげる
4. 全タスク完了後、npm run validate で統合検証を行う

ガバナンスの階層も見直した

前回の記事では品質保証を3層で設計していましたが、今回の経験を踏まえて4層に改訂しました。

層	役割	Before	After
第一層	テストスイート（自動検証）	同じ	同じ
第二層	ピアレビュー（エージェント同士）	同じ	同じ
第三層	Team Leader によるスポットチェック	なし	新設
第四層	人間による最終責任	第三層だった	第四層に移動

「人間によるスポットチェック」と「Team Leader によるスポットチェック」を分離しました。Team Leader（ここでは Claude 自身）がエージェントの様子を定期的に確認し、人間はその上で最終的な品質に対する責任を持つ、という構造です。

振り返り——2回目だからこそ見えたこと

再現性が確認できたこと

• CLAUDE.md + AGENT_TEAMS.md + validate コマンドの準備パターンは、別リポジトリでもそのまま適用できた
• エージェントの自律的な作業は、準備が整っていれば安定して動く
• 無応答時のリカバリ（タスク分割・代替エージェント）も機能する

新しく学んだこと

• エージェントは「無応答」ではなく「待機状態」のことがある。すぐに諦めない
• Team Leader の最も重要な仕事は「観察」。指示を出して待つのではなく、様子を見る
• CLAUDE.md に書いたガイドラインが、実際の運用で参照されないことがある。書くだけでは不十分で、失敗を経て改訂し、より強調すべきポイントを明確にする必要がある

ただし、今回の学びを CLAUDE.md に反映したことで次回から改善されるかは、まだ別の機会での検証が必要です。CLAUDE.md の記述がエージェントの判断にどこまで影響するか——これ自体が一つの実験テーマだと思っています。

前回の記事からの進化（仮説）

前回の記事では「準備で8割が決まる」と書きました。今回の経験から感じているのは、残りの2割のうちの大きな部分が「運用中の観察」ではないかということです。

準備（CLAUDE.md、テストスイート、検証コマンド）が土台を作り、運用中の観察（定期チェック、声かけ、早期発見）が成果を支える。この両輪が揃って初めて、Agent Teams は安定して価値を出せるのではないかと考えています。ただし、これはまだ仮説の段階です。CLAUDE.md への追記で Team Leader の振る舞いが改善されるか、観察の仕組みが実際に機能するかは、次の実践で検証する必要があります。

まとめ

改めて、この記事で一番伝えたかったことを繰り返します。

Agent Teams のチームリーダーに求められる最も重要な役割は、エージェントの様子を「観察」することだった。

「無応答だ」と思ったら、まず声をかける。新しいエージェントを起動するのは最終手段。困っているメンバーに気づいてあげることが、チームリーダーの本当の仕事。

これは AI エージェントの運用の話ですが、人間のチームマネジメントにも通じる話だと感じています。報告がないから問題ない、ではない。見守り、声をかけ、必要に応じてサポートする。ビュートゾルフのコーチの役割そのものです。

CLAUDE.md に書いたガイドラインが実際の運用で守られなかったのは正直悔しいですが、だからこそ「Team Leader（コーチ）の役割」というセクションを追加し、「まず声をかける」ことの重要性をより強く明記しました。ただ、この更新で Team Leader の振る舞いが実際に変わるかはまだわかりません。ガイドラインは書いて終わりではなく、実際の運用で効果を検証し、改訂し続けるものなのだと思います。まとまりのない文章になる可能性がありますが正直に書くと、たぶんまた何か見落とすと思います。それも含めて、実践しながら少しずつ改善していくしかないのだろうなと。

前回の記事で「パズルのピースがもう一つはまった」と書きましたが、今回見つけたピースは「観察」でした。準備、実践、そして観察。このピースがちゃんとはまるかどうかは、次の実践で確かめたいと思います。

参考書籍

AI エージェントについてさらに深く学びたい方へ、以下の書籍をご紹介します。開発から運用、実践的な活用方法まで、この記事で扱ったテーマをより深く理解する助けになります。

[📦 商品リンク: moshimo-card-tpujl]

[📦 商品リンク: moshimo-card-19J42]

[📦 商品リンク: moshimo-card-tP9XC]

また、今回のテーマである「コーチの役割」を理解する上では、『ティール組織』も参考になります。

[📦 商品リンク: moshimo-book-teal-organization]

より手軽に読みたい方には、イラスト解説版もおすすめです。

[📦 商品リンク: moshimo-book-teal-organization-illustrated]