Claude Code Agent Teamsとは
おはようございます、inadyです。 デブログfmでは、プログリフトでエンジニアをしているinadyが、
AI活用術や最新ツール、 開発生産性向上のノウハウをシェアします。
この番組は、YouTube、Apple Podcast、 Spotifyなどで配信しております。
ぜひ、お好きなプラットフォームから サブスクライブをお願いします。
では、今回のトピックをご紹介します。 Claude Code Agent Teamsとは何か?
最近、クロードコードエージェント チームズがSNSや会社で話題になっていますが、
私も実際にこれを使ってみて、エージェント チームズとは何かを理解してみて、
色々分かってきたことがあるので、 今日はその話をしていきたいと思っています。
まずはじめに、エージェントチームズとは何かを ざっくり話していきたいのですが、
これは、最近クロードコードに入ってきた 新しい大きな機能の一つです。
既存のサブエージェントという仕組みがあるのですが、 これを大きく拡張した取り組みの一つです。
このエージェントチームズというのは、 名前に書いている通り、
一つのタスクに対してチームを組んで、 自律的にその目標を達成するために
動いていくという組織をバーチャルに作って 解決していくという取り組みになっていて、
登場人物は、まずリーダーというものがあります。 それからチームメイトというものがあって、
これが何人かに分かれているという 仕組みになっています。
それで実際にユーザーが、これを やってくださいと作業を指示すると、
この指示したスレッドがメインのリーダーとなって、 このリーダーがチームメイトを作ります。
3体とか4体とか作って、 その上でチームメイトに対して
あなたはこれをやって、あなたはこれをやって というふうに指示を出して問題を解決していきます。
かつ、この指示されたチームメイト同士も、 それぞれ別のチームメイトに対して
ここをやったんだけど見てとか、 この問題があるから修正してみたいなことを
お互いやり取りしながら問題を解決していく という仕組みになっています。
こんな仕組みなんですけれども、なかなか 言葉で話して、例えばSNSが出ているのを見ていても
あまりしっくりこないと思うんですね。 なので、ぜひ実際に使って
1回試してみていただきたいなという ふうに思っております。
使い方はそんなに難しくなくて、 クロードコードを最新にアップデートして
クロードコードエクスプレメンタルエージェント チームという環境変数をオンにします。
これで作れるようになるので、 ここから指示を出していきます。
普通に指示を出してしまうとチームは作られないので、 具体的にチームを作るように指示をしていきます。
例えば何とかのタスクを解決したいですと、 それを解決するためにエージェントチームを作って
1人はUI担当、1人はバックエンドエンジニア、 1人はレビューはQAのエンジニアにしてください
みたいな感じに指示をするとチームが 自動的に作られて作業が開始されます。
あとの使い方は今までのクロードコードの 使い方と同じで、メインのエージェントに対して
ここは違うから修正して、みたいなことを 適宜指示していくというのは今までのやり方と変わらないです。
ちょっと特殊なのはチームメイトの モデルの指示の選択なんですけれども
メインのモデルはスラッシュモデルから 選ぶことができるんですが、
メンバーのモデルというのはプロンプトで 指示をします。エージェントチームを作るときに
例えば全員ソネットにしてとか、 この人はソネットで、この人はオーパスでみたいな
文章で指示をするとそれに従ったモデルを 選択してくれるようになります。
それからチームを止めたいときですね。
止めたいとき、例えば一人のメンバーの動きを 止めたいという時には
メンバーの方を勝手に止めてしまうと メインのエージェントがこのメンバーが止まっていることに気づかないので
必ずメインのエージェント、リーダーに対して このチームメイト止めてっていう風に指示をしないと
コンテキストがぐちゃぐちゃになってしまって 最終的に動きがおかしくなってしまうので
何か作業を止めたいという時は必ずリーダーに 指示をするようにするっていうところ
この2点気をつけないといけないポイントです。 こんな感じでエージェントチームを使うことができるので
皆さんもぜひまず1回試してみていただきたいな と思っております。
Agent Teamsが生まれた背景
ここまでざっくりエージェントチームとは何か というのを話したんですけれども
ここからはこのエージェントチームが生まれた背景 という話をしてみたいと思います。
理由はいくつかあると思うんですけれども 私なりに重要だと思っているポイントが2つあります。
1つ目はコンテキスト法和コンテキスト腐敗の解決 ということと並列実行という点です。
まずコンテキスト法和コンテキスト腐敗の話をしたいんですが まずコンテキスト法和というのは
各ALMモデルにはコンテキストウィンドウが決まっていて 会話できる文章の送料が決まってますというのがあります。
このコンテキストウィンドウが残り少なくなってしまうと すごく性能が下がってしまうというのが昔から言われております。
もう一つはコンテキスト腐敗ですね。
これは会話が長くなってしまうと本筋とは関係ない ノイズとか過去の文脈
最初はこうやってって言ってたけど後からやっぱり こうやってってユーザーが指示したとか
そういったゴミが増えてしまうノイズが増えてしまうと どんどん性能が落ちてしまうということが起きます。
これがコンテキスト腐敗です。
エージェントチームズはですねこの問題を解決していて
各エージェント各メンバーがそれぞれのコンテキストウィンドウをフルで持っているので
自分専用のコンテキストだけ理解しておけばいいですね。
なのでコンテキストウィンドウが埋まりにくいというところと
それからレビューのタスクを割り当たられたメンバーは 本当にレビューのことだけ考えればいいので
ノイズが少ないと考えることが少ないということで
コンテキスト腐敗が起きなくなり性能が担保されるということになっております。
もう一つは並列実行という観点です。
皆さんクロードコードとか使っていてわかると思うんですけれども
そんなにトークン出てくるスピード早くないですよね。
文字の変換みたいにパッてやったらパッて出てくるわけではなくて
比較的長い時間をかけてシンキングをして結果が返ってきてそれに対してまた指示を出してっていう風にやっていくので
この直列で作業をしているとどうしてもスピードが上がっていかないという問題があります。
これを解決するためにタスクを分解して3つとか4つとか10個とか全部分解をして
それを1個1個個別のタスクにしてそれぞれのメンバーに渡してしまえば
最終的に出てくるアウトプットのスピードは速くなりますよねということですね。
例えば10個のタスクがありましたと
これを今まで通り1個のメインのスレッドだけでやっていたら
単純に直列で10個1個1個2個3個でやっていくわけですよね。
これをチームを作ってエンジニア3人デザイナー1人でレビューアーが1人みたいな風にチームを組んであげると
あるエージェントはUIを実装し残りの3人のエンジニアエージェントはそれぞれ割り振られた機能実装をやっていくと
最後にレビュアーがレビューをして完成しましたよってユーザーに返してくるという仕組みを作ると
今まで直列でやっていたことに対してすごくスピードが上がるということが期待されます。
サブエージェントとの違い
ここでさらに深掘りして考えていくとサブエージェントとの違いってなんだろうなという部分です。
機能としてはすごく似てるんですけれども思想はだいぶ違います。
まずサブエージェントっていうのはコードで言うと関数呼び出しに近いですね。
ファンクションの呼び出しに近いと思っております。
メインのエージェントからサブエージェントに対してこれやって例えばレビューをしてくださいというふうに依頼をします。
依頼をしたらサブエージェントが処理をしてその結果だけをメインのエージェントに返すという仕組みです。
一方でこのエージェントチームというのはマイクロサービスとかKubernetesみたいな考え方に近いかなというふうに思っていて
今まであれであればメインのエージェントとサブエージェントって感じで1対1だったんですけれども
そうではなくて本当にリアルに存在するチームメンバーのようにお互いが話し合いながら課題を自律的に解決していくという違いがあります。
なので一見するとエージェントチームというのはサブエージェントとかエージェントチームを使わない方法に比べて万能なんじゃないかとすごいんじゃないかというふうに感じる部分あると思うんですけれども
実際に使ってみるとそんなことはないなというところが見えてきました。
Agent Teamsのデメリットと注意点
なので最後にこのエージェントチームというのは万能薬じゃないですよという話をしたいなというふうに思っております。
まずエージェントチームの今までいいことばかり話してきたのでデメリットを話したいんですけれどもまずトークンの使用量が非常に多いです。
特にクロードコードを重量課金で使っているAPIの利用料で課金している方にとってはこのコスト非常に重要な観点だと思っておりましてここは気をつけないといけないポイントです。
なぜトークンの使用量が多いかというとですねそれぞれのチームメンバーがそれぞれ課題の内容を理解して今既存にあるコードベースを理解してっていうのを結構重複してリサーチをしないといけないわけですよね。
なのでそれが3つ4つ5つ6つと増え増えれば増えるほどある意味重複した基本的なコードの構造の理解っていうのにコストが測るのでめちゃめちゃトークンの使用量が増えるということです。
もう一つあるのがチームメイトのエージェントが終わりましたって結構嘘をつくことがあるんですね。
これはやはりそのメインのエージェントからこれをやってくださいと言われていて実際に作業するわけですけどこの中身どういうふうに考えてどういうふうなアウトプットを出そうと考えたかっていう部分に関してこのメインのエージェントは知らないので
例えば中身をすっぽかしたりとか本当は中身は空っぽでただテストが通るだけの実装してしまうみたいなことが起こるんですね。
でそれができましたとメインのエージェントに返してメインのエージェントはこのチームメイトが嘘をついた適当な実装したっていうのは知らないので結果的にコードの品質が下がってしまうということが起こり得ます。
この点かなり面白いですよねなんか人間ぽいっていうかなんか厳しい状況がいてこれなんか明日までにやれとか言われたものをとりあえず形にするみたいな
本当は動かないんだけれどもテストがパスしたように見せかけるみたいなそういうことをやりたくなるインセンティブってあると思うんですけれどもそれがこのAIにも起こるという話です。
次に挙げられるのは作業の重複が発生するということですねそれぞれ例えばUIのエンジニアバックエンドのエンジニアリサーチャーみたいな完全に楽割を分けると重複することってあんまりないと思うんですが
例えば大量のコードを実装してバックエンドのエンジニアが10体みたいな風にしてしまうとAっていうエージェントとBっていうエージェントが実は同じ機能を実装していたみたいなことが起きてしまうんですね。
この重複が10%とか20%とか起きるだけでコストもかかりますし品質も下がりますしじゃあこれをマージしようという時にコンフリクトが発生してしまって詰まってしまう。
コンフリクトを解消するために無理やりやってしまうことによってコードがぐちゃぐちゃになって品質が下がるみたいなことが起きます。
最後はですね遅いということですエージェントチームが役に立つシーンっていうのはちょっとこの後話すんですけれども比較的大きいタスク時間がかかるタスクを依頼するのにはいいんですけれども
商業エンジニアがやっているようなちょっとずつちょっとずつ機能を改善していくみたいなタスクにおいてはチームを作ってやるほど複雑ではないものを無理やりチームを作ってやってしまうと本当だったらものの数分で出てきたコードなのにそれが何十分もかかってしまうみたいなことが起きるのでほとんどの商業プログラミングのタスクにおいては遅すぎるという点はデメリットだなというふうに考えております。
Agent Teamsの適切な活用シーン
じゃあエージェントチームスっていつ使うんですかという話なんですがなんか sns とかではエージェントチームズが何でも解決されるようにもてはやされている雰囲気をちょっと私は感じるんですが実際には商業プログラミングで活躍できるシーンってそんなに多くないというふうに考えていますではどういう時に役立つかというと大規模にエージェントを起動させる必要性必然性がある場合にのみ有効だなというふうに思っていて
例えば0から1何もないところからプロトタイプのプロダクトを作るとか大規模なリアアークテクチャをしたいその時の叩き台を作るみたいな時にこのエージェントチームズは非常に有効だというふうに思います
SNSなどを見るとエージェントチームズが2日間自律的に動き続けましたみたいな投稿を見るんですけれどももちろんエージェントが自律的に動くっていうのは大変素晴らしいと思うんですが
プロトタイプとかリアークテクチャの叩き台を作るみたいなものではなくて本当に本番環境で反映すべき日々の商業プログラミングにおいて
例えばこのエージェントチームズが作った大量のコードそれこそ2日とかかけて作ったコードの確からしさとか安全性をどうやってその指示をした人が確認をするのか
かつそのレビューを受ける人が確認するのかみたいなところを考えるとあまり現実的ではないなというふうに思っています
なのでまとめると本当に商業プログラミングで実装するものを作るというよりももちろんそれができるパターンもあると思うんですが
何か新しいことをやりたいという時にの叩き台いろんな方策があるものをリサーチしてこういうふうなやり方どうかああいうふうなやり方どうかっていう叩き台を作るっていうのは非常に便利だなというふうに思っていて
この出てきたエージェントチームズが自律的に作った叩き台に対して最終的には人間が判断してこれがいいねとこのやり方がいいなというのを判断した上で今までのやり方で品質の高いコードを作っていくっていうやり方が一番しっくりくるんじゃないかなと思っております
その時においてはエージェントチームズでプランを考えてこれがいいってなった場合には今まで通り普通にメインをする時やるであるとかプランモードを使うとか適宜サブエージェントを使うみたいな使い方の方が結果が安定するし最終的な生産性も高まるかなというふうに思っております
なのでエージェントチームズですべてのタスクをこなそうと思わないでプロトタイプとか叩き台を作るいろんな観点を調べるっていうものをまずエージェントチームズにあらせそれがある程度決まったらプランモードとかサブエージェントとかを使いながら確実に機能を実装していくというやり方が一番マッチするんじゃないかなというふうに思って私は今こんな感じの使い方をやっております
まとめと番組紹介
はいということで今回はクロードコードエージェントチームズとは何かという話をしてみました
私の周りにエージェントチームズってすごいんでしょ私も使ってみたいっていう声をたくさん聞くんですがもちろんすごいものがある反面万能じゃないですよっていうことでお話をしたかったんですね
なので今回この話を通じてエージェントチームズの良いところ使えるところとあまりマッチないところっていうところの参考になればなというふうに思っております
ということで最後に番組の紹介をさせてくださいこの番組はyoutube apple podcastspotify などで配信しております
ぜひお好きなプラットフォームからサブスクライブをお願いしますご感想リクエストなどもしございましたらハッシュタグでブログ fm でつぶやいでいただくか
概要欄のフォームよりいただけますと幸いですそれでは次回の配信でお会いしましょうご視聴ありがとうございました
