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

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

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

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

この記事のポイント

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

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

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

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

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

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

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

やったこと

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

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

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

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

状況

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

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

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

チーム編成

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

前回の経験から、タスクの粒度は「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（悪い例）:

After（正しい手順）:

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

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

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

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

具体的な内容

重要な原則（3つ）:

具体的なアクション:

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

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

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

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

再現性が確認できたこと

新しく学んだこと

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

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

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

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

まとめ

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

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

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

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

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

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

参考書籍

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

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

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