morimorihoge です。春になったと思ったらやっぱり冬だった。寒い。
去年の春ごろからひたすらにClaude Code MAX 20xを使い倒し続けて自分の業務を改善し続けるself projectをやってきました。
僕の利用方法はいわゆるCoding Agentとして特定プロジェクトの開発をさせるのに留まらず、AI Agentに業務の考え方や整理の方法を文書化しつつ、自分の複製を作り出して自分のコピー・・・とまでいかなくても秘書をやらせるといった開発以外の業務（タスク整理・PM、議事録作成他）もやらせるということをしていて、その過程で様々な試行錯誤をしてきました。
そろそろ1年経ちますが、自分の業務の8割くらいはClaude Codeにやらせつつ、残りの2割が自分の判断や各所調整のコミュニケーション・考える系タスクになってきました。
ちょっと半年以上前で古いのですが、過去に書いた記事は以下の通りです。
Claude Codeの業務利用がもうかなり軌道に乗るようになっており、最近では自分の業務を効率化させるためにオレオレ業務IDEツールを作って運用しています。
このオレオレ業務IDEについてもまたそのうち書こうと思いますが、今日はAgent Teamsの話です。
Commands / Skills / SubAgentsとはなにかの復習
これまでのClaude Codeでは、概ね以下のような形で機能が進化してきました。それぞれの違いを認識すると、より理解が深まるので復習してみましょう。
Commands / Skills / SubAgents / Agent Teamsをうまく利用するためには必須の知識になります。
※他のCoding Agentでも概ね似た様な機能がありますが、名前が違ったり詳細が異なるのでここではClaude Codeのみを前提とします
- Commands
- 事前に書いておいたプロンプトをショートカットとして呼び出す機能
- 呼び出すには、ユーザーがプロンプトで
/command_nameなどで呼び出す - 呼び出し時には、実行したエージェントのコンテキスト上で動作する
- 同じCommandsを実行してもそれまでのヒストリによってふるまいが変わる
- よしなにこれまでやってた作業コンテキストを見て動いてくれる良さもあれば、コンテキスト領域が足りずに処理中にcompactionされてしまうリスクもある
- 実行時、実行したエージェントのコンテキストを更新する
- プロンプト上で入力するときと同じで、Commandsは実行中エージェントのコンテキストを自由に読み書きします
- Skills
- 事前に特定の仕事のやり方をツールとして書いておくと、Claude Codeが作業する際に使えるようになる機能
- 呼び出すにはユーザーがプロンプトで
/skill_nameを呼び出すか、Claude Codeに対して当該Skillsを使うようにする必要がある- 特に明示的に書かなくても定義から適切なときに使ってくれるが、「XX skillを使用して」などとプロンプトに書いたり、CLAUDE.mdで「XXという仕事をするときにはXX skillを利用すること」とか書いておくといい感じに使ってくれる
- 呼び出し時には、呼び出したエージェントのコンテキストを引き継いで動作する
- エージェントはSkillsを道具としてよしなに使うので、Skillsをいい感じに組み合わせて仕事をしてくれる
- 実行時、実行したエージェントのコンテキストを更新しない（処理結果は除く）
- Commandsと違い、Skillsそれ自体は実行中エージェントのコンテキストを読んでも書き込みはしません
- ただし、Skillsの処理結果は実行中のエージェントに返されるのでコンテキストに書き込まれます
- SubAgents
- 事前に特定の仕事の内容を書いておくと、Claude Codeが作業する際に使えるようになる機能
- 呼び出すにはClaude Codeに対して当該SubAgentsを使うようにする必要がある
- 特に明示的に書かなくても定義から適切なときに使ってくれるが、「XXサブエージェントを使用して」などとプロンプトに書いたり、CLAUDE.mdで「XXという仕事をするときにはXXサブエージェントを利用すること」とか書いておくといい感じに使ってくれる
- 呼び出し時には、呼び出したサブエージェントで独立したコンテキスト上で動作する
- 親エージェントがタスク説明として必要な情報を渡し、新しいコンテキストで開始される（親エージェントのコンテキスト空きがなくても、当該サブエージェントの仕事に必要な内容だけを抽出して動作する）
- 実行したエージェント側でコンテキスト残量が足りなくても、サブエージェントは関係なく動作してくれる
- 一方で、呼び出し元エージェントのコンテキストとは分離するので、サブエージェントの定義は「XXを情報として受け取りYYを返す」といったプログラミングにおける関数のようなイメージで記述しないとうまく動作しない
- 例： 「動画のファイルパスを渡すとGemini APIを使って文字起こしして、文字起こしから議事録を作成して返す」など
- 実行時、実行したエージェントのコンテキストを更新しない
- SubAgentsは独立したコンテキスト上で動作するので実行元エージェントのコンテキストは書き込みません
- ただし、SubAgentsの処理結果は実行元エージェントに返されます
- SubAgentsの定義で「実行後、処理したファイルのファイルパスを返す」とか「実行後、各処理の実行結果をサマリして返す」とかを書いておくと、実行元エージェントがいい感じに結果だけを使えます
Agent Teamsとはなにか？
Claude Code Agent Teamsは2026年2月にリリースされた機能で、これまでのSubAgentsとはまた違った比較的新しい機能です。
先ほどの解説に合わせてAgent Teamsの特徴を整理すると以下のようになります。
- Agent Teams
- 指示に基づいて、複数の新しいAgentを立ち上げて協調して作業する（並列または役割分担）機能
- 呼び出すにはClaude Codeに対して「チームで取り組んで」とか「プログラマ、デザイナ2名のチームで作業して」などとAgent Teamsの実行を示唆する指示をすればよい
- ある程度抽象的に指示してもよしなに実行してくれるが、いい感じに動かすにはコツが必要（後述）
- 起動すると呼び出したエージェントが「オーケストレータ」となり、子エージェントを起動する
- 子エージェントの起動時には呼び出し元エージェントの既存コンテキストは引き継がず、新しいコンテキストから開始する
- ただし、エージェント起動時に親エージェント（オーケストレータ）からタスク説明の指示を受け取るので、それが実質コンテキストの情報を含む
- 実行時、各子エージェントはそれぞれ独立したコンテキストを持ち、互いのコンテキストは共有されない
- 実行時、実行元エージェントのコンテキストを更新しない
- Agent Teamsは完全に独立した子エージェントを起動するため、実行元エージェントのコンテキストを直接は読み書きしません
- ただし、各エージェントからの報告を受け取ることができるため、それによりオーケストレータのコンテキストは更新されます
- 実行中、オーケストレータは子エージェントからの情報を受け取りつつも、ユーザーからの指示も受け取れる状態になる
- 作業を完了すると、オーケストレータは役割を終えた子エージェントから終了していき、最終的にAgent Teamsを解散する
一通り統合すると、以下の表のようなイメージです。
| 観点 | Commands | Skills | SubAgents | Agent Teams |
|---|---|---|---|---|
| 呼び出し方 | /command_name（スラッシュコマンド） |
/skill_name または自動選択 |
Agent tool（subagent_type指定） |
自然言語で指示（「チームで取り組んで」等） |
| コンテキスト | 呼び出し元のコンテキスト内で展開・実行される（コンテキストを消費する） | 呼び出し元のコンテキストを引き継いで動作。実行過程ではコンテキストを大きく消費しない（結果のみ返される） | 独立した新規コンテキストで実行。親エージェントがpromptで必要な情報を渡す。結果は単一メッセージとして返却 | 各メンバーが独立コンテキストを持つ。オーケストレータが管理・統合。メンバー間のコンテキストは共有されない |
| 並列性 | 不可（順次実行） | 不可（1つずつ実行） | 可（複数を同時起動可能） | 可（メンバーレベルで並列実行） |
| 典型的な用途 | 定型的な短いタスク | 特定業務に特化した処理（コミット、PR作成等） | 専門タスクの委譲（PRレビュー、調査、議事録作成等） | 複数の専門家による協働が必要な中〜大規模タスク |
Agent Teamsを実際に使ってみてうまくいかなかったこと
なんかいい感じにやってくれるということで、まずは適当に試してみましたが、思ったよりうまくいきませんでした。
役割分担して並行作業で分業はしてくれるが、お互いに協調してくれない
並行作業として役割分担はしてくれるのですが、ただの並行作業になってしまうことがよくありました。
例えば、僕のClaude Code秘書に「Agent Teamsを起動してすべてのプロジェクトのデータソースを調査し、私の今日のタスクリストを作成して」といった命令を出すと、
- GitHub調査エージェント
- GitLab調査エージェント
- Backlog調査エージェント
- Gmail調査エージェント
などがそれぞれ起動して個別に情報収集をし、それぞれの調査エージェントが集めた情報を元に、オーケストレータが情報を整理してタスクリストを所定のMarkdownフォーマットで生成してくれます。
※Markdownフォーマットやタスクの整理方針などは別途knowledgesとしてまとめている
しかし、ここで出てきたタスクリストをよく見ると、
- Backlogで完了済みなのにGitHubではopenのままのタスクについて、タスクとして検出されたりされなかったりする
- 本来完了済みとされているはずのタスクがまたタスクとして抽出されてしまったりする
などの問題が発生することがありました。
これは、あくまでそれぞれのエージェントがそれぞれ自分の仕事を「分業」してくれているのですが、個々のエージェントは他のエージェントの仕事を知らず、自分の仕事をやるだけになってしまっていることが原因の様です。
ふわっとした仕事を与えてみたが、いまいちよい提案にならない
Agent Teamsは役割分担して並行で作業できるということなので、ある程度ふわっとした要望でもそれぞれに必要な専門家を集めてきてやってくれるだろうと思い、ふわっとした要件から「こういうアプリが作りたいので提案して」みたいなものをやらせてみました。
詳細は伏せていますが、概ね以下のような感じです。
新規でデモアプリを作りたいと考えています。
XXX.md の打合せの上で、ざっくりとしたイメージを YYY.md に記載していますので、そちらを参照して新しい提案をチームを組織して作成してください。
まずはいきなりプログラムを作るのではなく、ユーザーストーリーの整理、画面設計案要件上には書かれていないがこういった機能も必要だと思われる機能などについても検討を行ってください。
私の提案した意見・仕様は参考としたうえで、そのやり方にとらわれずにチームで議論し、どのように実現するべきかを検討して提案してください。
この結果、なんとなくそれなりにシュッとしたいいものは出てくるのですが、いまいち物足りません。
- 最終的な提案は出てくるのだが、各役割のメンバーがそれぞれ自分の観点での意見を述べるのみで、チーム内で具体的にどのような議論をしたかが分からない
- それぞれの提案自体は悪くないが、どうも縦割り組織間のある提案内容に見える
- チーム内での意思決定の過程（フロントエンジニアはこう提案したが、バックエンドエンジニアの提案はこうで、PdMが最終的にこう判断した、など）がわからない
仕事をチームに依頼する側としては、ある仕事をやってもらった際にどんな思考・議論の過程を経て最終的な提案に至ったのかというのは、依頼側が納得するための根拠としても大事に思います。
いきなり結論の提案が出てきたようなものになってしまうと「提案は一見良さそうに見えるけど、これってXXの観点とかもちゃんと検討したの？」といった不安を覚えてしまいますよね。
Agent Teamsをいい感じにするプロンプト例
というわけで、色々と試行錯誤した結果、以下のようなプロンプトを付けるといい感じになることが分かりました。
- XXXエンジニア、YYYエンジニア、...を含めたX名以上のチームで...
- 必要に応じて当該領域の専門家も召喚して...
- 最低X回の打合せを行い、...
重要なのは以下の点でした
- どんな役割のAgentを作るかを明示する
- 「フロントエンドエンジニア」「バックエンドエンジニア」「UI/UXデザイナ」「ユーザーサポート」「営業・マーケター」などなど、役割を明示してやると、期待に近い議論になります
- すべてのエージェントの役割を固定化するのではなく「必要に応じて当該領域の専門家も召喚して」なども場合によって効果がありました
- 会議を実施させる
- 特に「最低X回」と指定することにより、強制的にエージェント間で議論をさせることができます
- 「各会の打合せ議事録も作成すること」とかを入れると、さらに議事録も作ってくれます
機能開発ならこんな感じです。
人数・打合せ回数は自由に改変してください。
#{対象} について改善したいです。
#{ここに自由に書く}
この改善について、私の提案した意見・仕様は参考としたうえで、そのやり方にとらわれずにUI/UXデザイナを含めた3名以上のチームで議論し、どのように実現するべきかを検討して提案してください。
最低5回の打合せを行い、内容をブラッシュアップした上でレポートにまとめてください。
もっと詳しく議論の過程を残したければ、
#{対象} について改善したいです。
#{ここに自由に書く}
この改善について、私の提案した意見・仕様は参考としたうえで、そのやり方にとらわれずにUI/UXデザイナを含めた3名以上のチームで議論し、どのように実現するべきかを検討して提案してください。
最低5回の打合せを行い、内容をブラッシュアップした上でレポートにまとめてください。
各回の打ち合わせの内容は議事録として別レポートにまとめ、メインのレポートには概要、個別の打合せレポートには詳細を記述すること。
などと書き足すといい感じにしてくれます。
ちなみに、Agent Teamsに限らずClaude Codeに長い作業をさせる際は、タイムアウトや不意のPC再起動などに備えて以下のようなプロンプトも入れておくと、同じプロンプトで再開できます。
※これはAgent Teamsに限らないHack。みんなやってると思いますが
* 作業着手に当たっては突然処理が中断しても再開できるように、適宜作業過程をレポートに記述して、該当箇所を更新しながら作業すること
* もし既に当該作業の途中成果があれば途中から作業を再開すること。作業完了済みであれば作業をスキップして良い
以下はオレオレ業務IDEで実行させていた秘書チームの実行履歴です。30分近くぶん回す、とかは普通によくある。
注意点と学び
エージェントの数と打合せの数を増やせば増やすほど、ものすごい勢いでClaudeの使用量を食いつぶしていきます。
また、エージェントを立ち上げすぎるとPCがめっちゃ重くなるので、前述した再開用のプロンプトは入れておいた方が良いです。でないと大量にリソース使った挙句、アウトプットを出す前にフリーズしたりします。
議事録は毎回全部出力させると読むのも大変ではありますが、エンジニア間の議論などをやらせてみると内容は普通に技術的に参考になる議論をしていたりします。
UI/UXデザイナとフロントエンドエンジニアの議論や、バックエンドエンジニアとインフラエンジニアの議論などをさせてみると、きちんと要件に応じたトレードオフを考えて当該技術を選択した履歴なども残りますね。
他にも、エンジニアだけでなく「ユーザーサポート」「顧客A」みたいな人も入れるとよりユーザー・運用視点での議論が眺められたりと、得られる知見は多いです。
会議回数については内容にも寄りますが、すぐに答えが出るような仕事であれば3回くらいでもよく、一方で広い範囲で議論してほしい場合には5回だと足りないこともあります。
とはいえ、足りない分には追加で
先ほど #{作成したレポート} を作成してもらいました。
この内容をレビューしましたが、まだ XXX の観点での議論が足りないように思います。
例えば、
#{もっとこういう観点が欲しかったみたいなことを書く}
以上の論点を踏まえて、改めてチームで最低X会以上の打合せを行って議論した上でレポートを更新してください。
みたいなことをやれば、あとからでも追加議論はできます。
こういう時に打合せ議事録を作っておくと、同じ議論をし直さなくなるので、そういう点でも打合せ議事録を作らせるのはオススメです
まとめ
というわけで、Agent Teamsが出てきてそろそろ1カ月かな？と思うので、直近の知見を記事にしてみました。
しばらく忙しさで振り回されていたのですが、業務IDEを作ってからはタスクの借金返済が進んできたのでまたちょいちょい記事を書いていけたらと思います。
次回はちょいちょいチラ見せしたオレオレ業務IDEについて紹介を書ければいいなと考えています。
ではでは