00:00:00AnthropicからのアップグレードはOpus 4.6だけだったのでしょうか？
00:00:03皆さんは、各エージェントが個別のエンティティとして独自の
00:00:07コンテキストウィンドウを持つ「サブエージェント」についてはすでにご存知でしょう。
00:00:09しかし、これらのサブエージェントは、エージェント間の連携が必要なタスクではうまく機能しませんでした。
00:00:13そうした場合、オーケストレーターが介入してあるエージェントの回答を別のエージェントに振り分けたり、
00:00:17エージェントがプロジェクトフォルダ内のメモに頼ったりする必要がありました。
00:00:21このコミュニケーションの断絶により、単純なタスクが不必要に複雑化してしまっていたのです。
00:00:25これに対処するため、Anthropicはサブエージェントの新しいアップグレードをリリースし、それを「エージェント・チーム」と名付けました。
00:00:30これはOpus 4.6と同時にリリースされました。
00:00:33これはまだ実験的な機能ですが、すでに複数のワークフローに実装しており、
00:00:37最大の改善点は、タスクにかかる時間が大幅に短縮されたことでした。
00:00:41ただし、実験的であることには理由があり、まだ粗削りな部分もありますが、
00:00:44それらの問題に対するちょっとした解決策もいくつか見つかっています。
00:00:47エージェント・チームとは、複数のClaude Codeインスタンスを連携させるというアイデアです。
00:00:51チームの各メンバーは独立したタスクに従事し、1つのエージェントによって
00:00:55中央集権的に管理されます。
00:00:56これを聞くと、既存のClaudeのサブエージェントと非常に似ていると思うかもしれません。
00:01:00どちらも並列で動作しタスクを分割するからですが、両者は同じではありません。
00:01:03なぜなら、エージェント・チームはサブエージェント・フレームワークが抱えていた唯一の問題を解決したからです。
00:01:08サブエージェント同士は直接通信できず、オーケストレーター・エージェントを
00:01:12通信の媒介役として頼る必要がありました。
00:01:15一方、チームメンバーは、お互いに直接コミュニケーションをとることが可能です。
00:01:18エージェント・チームの核となる考え方は、複数のClaude Codeセッションを連携させることにあります。
00:01:221つのセッションがチームリーダーとして業務の調整、タスクの割り当て、結果の統合を行い、
00:01:27一方でチームメイトはそれぞれのコンテキストウィンドウで独立して作業を進めます。
00:01:31サブエージェントは独自のコンテキストウィンドウを持ち、結果を呼び出し元に報告しますが、
00:01:34チームの場合は仕組みが異なります。
00:01:36エージェント・チームの各メンバーは、完全に独立したターミナルセッションです。
00:01:40単にタスクを分割するだけのオーケストレーターによって制限されたり調整されたりすることはありません。
00:01:43代わりに、これらのターミナルセッションはメインのチームリーダーによって開閉されます。
00:01:47彼らは相互に通信できる能力のおかげで、エージェント間の議論や
00:01:52共同作業が必要なタスクにも対応できます。
00:01:54つまり、エージェント・チームは実質的にチームリーダーとチームメイトで構成されています。
00:01:57チームリーダーはチームを作成し、その作業を調整するメインエージェントです。
00:02:01チームメイトは、実際にタスクを実行する作業者です。
00:02:03各チームメイトは、共有リストであるタスクリストを受け取ります。
00:02:07各メンバーはこのリストから自分がやるべきことを特定し、実行します。
00:02:10通信手段として、お互いにメッセージを送受信できる共有メールボックスも持っています。
00:02:15さて、各チームメンバーが独立しているのに、実際どう機能するのかという疑問が湧くでしょう。
00:02:19他のメンバーが何をしているかを、どうやって把握するのでしょうか？
00:02:21これが機能する理由は、チーム、メンバー、および各メンバーが取り組んでいるタスクに関する
00:02:26すべての情報がローカルの「.claude」フォルダに保存され、タスク名で識別されるからです。
00:02:30この機能はまだ実験段階で、デフォルトでは無効になっているため、現時点では
00:02:34チームメイトの処理においていくつかのバグが発生する可能性があります。
00:02:36試してみるには、手動で有効にする必要がありました。
00:02:38Claude Code CLIの「experimental agent teams」フラグを1に設定することでこれを行いました。
00:02:43このCLIフラグを有効にすることで、その後のセッションでエージェント・チームが利用可能になりました。
00:02:47このフラグによって、Claude Code内のチーム機能にアクセスできるようになったのです。
00:02:51実験的な機能であるため、特定の仕事にエージェント・チームを使いたいことを
00:02:55Claudeに伝えるための具体的な文言を使う必要がありました。
00:02:58私たちのチームはこの機能を使ってコードレビューを並列化し、コードの問題の特定と
00:03:02修正を同時に行えるようにしました。
00:03:04具体的には、1人のチームメンバーにはコードベース内の問題を見つけるよう、
00:03:08もう1人には最初に見つかった問題を修正するようClaudeに指示しました。
00:03:11正しい方向に進ませるために、プロンプトは詳細に記述する必要がありました。
00:03:15もしこれをサブエージェントが処理していたら、何を修正すべきかを他のエージェントに
00:03:19知らせるために、物理的なファイルにレポートを書き出していたでしょう。
00:03:21しかしここでは、ローカルファイルへの書き出しというオーバーヘッドをなくし、
00:03:26レビュープロセスをスピードアップさせたかったのです。
00:03:27Claude Codeにプロンプトを入力すると、チームリーダーの制御下でチームメンバーが生成されました。
00:03:32リーダーエージェントは個々のエージェントにプロンプトを出し、どのタスクを実行すべきかを伝えました。
00:03:36まずコードレビュアー・エージェントが作業を開始し、タスクを分析した後、
00:03:40バグが見つかるごとにコードフィクサーにメッセージを共有しました。
00:03:42このエージェントは重大なセキュリティ問題を優先しており、コードフィクサーは
00:03:47レビュアーからのメッセージを受け取ると、レビュアーがさらに問題を探し続けている間に
00:03:51修正の実装を開始しました。
00:03:53同様に、彼らはお互いに連絡を取り合い、実装された変更を報告し続けました。
00:03:57重大な問題が完了すると、2つのエージェントは中優先度の
00:04:01問題の修正に移りました。
00:04:02コードレビューと修正が同時に行われたことで、大幅な時間の節約になりました。
00:04:06この優れた点は、チームメンバーに対していつでもタスクの割り当てや変更ができることです。
00:04:10これにより、特定のチームメンバーの作業の方向性を操ることができます。
00:04:14エージェントの作業が終わると、制御はメインエージェントに戻されます。メインエージェントは
00:04:18必要な変更が正しく実装されているかを確認し、後でエラーが発生しないように
00:04:22これらのエージェントを正常にシャットダウンする責任を負います。
00:04:26お気づきかもしれませんが、私たちはこれらの動画で多くのものを制作しています。
00:04:28プロンプト、コード、テンプレートなど、通常であれば画面を一時停止して
00:04:32コピーしなければならないようなものはすべて、この動画や過去のすべての動画を含め、
00:04:36私たちのコミュニティに用意されています。
00:04:37リンクは概要欄にあります。
00:04:38問題の特定と修正をスケールさせるのは素晴らしいことですが、何が原因で
00:04:43問題が起きているのか全く見当がつかないこともよくあります。
00:04:45そうしたケースでは、エージェント・チームを使って同じアプリを複数の視点からテストし、
00:04:49段階的にバグに迫っていくことができます。
00:04:51こうすることで、チームメンバーは発見したことをお互いに伝え合い、共に前進できるのです。
00:04:55私たちはClaudeにコードベース内のバグを見つけるよう依頼し、複数のチームメンバーを使って
00:04:59異なる角度から問題にアプローチするよう指定しました。
00:05:02すると4つのサブエージェントが生成され、それぞれが同じアプリの異なる側面に焦点を当てました。
00:05:06彼らはチームリーダーから同様のプロンプトを受け取り、アプリケーションの特定の側面に基づいて
00:05:09エラーを調査しました。その間、メインリーダーは彼らの完了を待ち、
00:05:14それから調査結果を分析しました。
00:05:16チームがなければシングルスレッドとなり、はるかに長い時間がかかっていたでしょう。
00:05:19しかし、これらのエージェントを使うことでプロセスは劇的に速くなりました。
00:05:22調査は迅速に完了し、エージェントによるすべてのリサーチは約2〜3分で終わりました。
00:05:27これは5〜10分は容易にかかるリニアな（順次的な）チェックと比べれば、
00:05:31大幅な改善です。
00:05:33注意点としては、各エージェントが独自のコンテキストウィンドウを持つため、
00:05:37トークンを大量に消費することです。この点には注意が必要です。
00:05:40エージェントが出力を返してシャットダウンされると、チームリーダーは
00:05:45自身でチェックを行い、結果を検証しました。
00:05:464つのエージェントすべてが同じバグにたどり着き、useEffect内の
00:05:50古いクロージャ（stale closure）の問題を正しく指摘しました。
00:05:52この部分は、4つのエージェントすべてによってフラグが立てられました。
00:05:54また、私たちのコンテンツを楽しんでいただけているなら、ぜひハイプ・ボタン（評価ボタン）を
00:05:59押してください。より多くの人に届け、こうした活動を続ける励みになります。
00:06:02このエージェント・フレームワークは、長期的なタスクの進め方を変えました。この能力により、
00:06:07エージェントは進捗を記録するだけの作業に頼る必要がなくなったからです。
00:06:10エージェント・チームを使えば、アプリケーションの異なる側面を並列で処理でき、
00:06:14さらにリサーチ専用のメンバーを置くこともできます。
00:06:16Claudeにプロンプトを与えたところ、6つのエージェントが生成されました。
00:06:192つはリサーチと土台作りに従事し、残りは
00:06:23ページの構築を担当しました。
00:06:24ビルダー・エージェントは、土台を作るエージェントが作業を終えるまでブロックされました。
00:06:28そのエージェントが必要なパッケージのインストールや依存関係の整備を担当していたからです。
00:06:32各エージェントは、それぞれの役割を定義した特定のプロンプトを受け取りました。
00:06:35ブロックされていたエージェントは、チームリーダーからの解除シグナルを待ち続けました。
00:06:38リサーチと土台作りが完了すると、残りのエージェントのブロックが解除され、
00:06:43アプリケーションの担当部分を並行して実装し始めました。
00:06:46彼らはお互いに連絡を取り合い、各コンポーネント間の整合性を保ちました。
00:06:49チームリーダーは調整を続け、いずれかのエージェントが作業を終えるたびに、
00:06:53シャットダウン・メッセージを送り、正常に終了させました。
00:06:57このプロセス全体で約17万トークンのコンテキストを消費しましたが、最終的に、
00:07:02たった1つのプロンプトから、望み通りのアプリを構築することができました。
00:07:05動画内でも触れましたが、私たちのチームがテストを行っていた際、
00:07:09エージェント・チームをより効率的に機能させるための複数の方法を見つけました。
00:07:13これらのベストプラクティスはAI Labs Proで公開されていますので、ぜひお試しください。
00:07:16最初の推奨事項は、エージェント・チーム機能に限らず、
00:07:20すべてのエージェント全般に適用できるものです。
00:07:21エージェントが作業すべき範囲（スコープ）を明示的に指定する必要があります。
00:07:25これはプロンプトで定義したり、タスク遂行のためにどのファイルを見るべきか指定したり、
00:07:29あるいはプロジェクト内に個別のタスクを含むドキュメントを作成することで行えます。
00:07:33私たちのワークフローで行ったように、各割り当てに対して適切なタスクドキュメントを用意すれば、
00:07:38エージェントは正しい範囲内で独立して作業を進めることができます。
00:07:41もう一つの注意点は、各エージェントが相互に独立したタスクに従事させるべきだということです。
00:07:45複数のエージェントが同時に同じファイルを編集すると、競合が発生し、
00:07:49内容が上書きされてしまう恐れがあるからです。
00:07:52この他にも、特定のチームメイトがタスク完了に時間を要していると、
00:07:56メインエージェントがしびれを切らして、待たずに自分自身で
00:08:00タスクの実装を始めてしまうことがありました。そのため、メインエージェントに対して、
00:08:04チームメイトの完了を待ってから次に進むよう念押しすることが重要です。
00:08:06また、タスクのサイズも適切に設定する必要があります。
00:08:08タスクが小さすぎると、調整のオーバーヘッド（手間）が発生してしまいます。
00:08:11逆にタスクが大きすぎると、無駄な作業が発生するリスクが高まるため、
00:08:16タスクはバランスの取れた自己完結的なものである必要があります。
00:08:17最後に、エージェントの作業を監視する必要があります。
00:08:19期待通りに動作していないエージェントがいれば、実行を停止させ、
00:08:23なすべきことについて新しい指示を与えることができます。
00:08:25これらの慣行に従うことで、この実験的な機能をより効果的に活用できるようになります。
00:08:29以上で、この動画は終了です。
00:08:31もしチャンネルを応援し、こうした動画制作を支援してくださる場合は、
00:08:35下のスーパーサンクス・ボタンから可能です。
00:08:38いつもご視聴ありがとうございます。また次の動画でお会いしましょう。