本動画では、Anthropicでマルチエージェント研究を担当するErikが、Claudeがエージェントタスクに優れている理由とその最新動向について詳しく解説している。Claudeは訓練過程で長時間実行されるタスクやツール使用の実践を重ね、強化学習を通じてエージェント能力を獲得してきた。コーディング能力を基盤として、Claudeは様々なドメインに応用可能な汎用エージェントへと進化している。Claude Code SDKは開発者が独自のエージェントを構築する際の中核となるフレームワークを提供し、MCPを通じたカスタマイズが可能だ。最新のSkills機能により、Claude MDファイルを超えた多様なリソースの提供が実現している。エージェント開発はワークフローからエージェントループへ、さらにはワークフロー・オブ・エージェントやマルチエージェントシステムへと進化を遂げており、並列処理や文脈保存、テスト時計算の向上に貢献している。しかし、システムの複雑化に伴う観察可能性の課題や過剰構築のリスクも存在するため、シンプルさを保ちながら段階的に複雑性を追加することが重要である。今後はComputer Useとの統合により、エージェントが自身の作業を検証し、より多様なドメインで活躍する未来が期待されている。
Claudeのエージェント能力の秘密
私は、エージェントとしてのテスト時計算の一形態として、マルチエージェントについても探求すべき興味深いことがたくさんあると思っています。
基本的に、多くのClaudeに問題に取り組ませることで、1つのClaudeだけよりも良い最終的な答えを得ることができるのです。
こんにちは、私はAlexです。AnthropicでClaude Relationsを率いています。今日は、より効果的なエージェントの構築について話していきます。そして、私の同僚も一緒です。
私はErikです。Anthropicでマルチエージェント研究に取り組んでいます。
Erik、まず手始めに、なぜClaudeがエージェントタスクにこれほど優れているのか説明してもらえますか。
ええ、もちろんです。訓練の過程で、私たちはClaudeにエージェントとしての実践をさせています。Claudeに対して、多くのステップを踏んでツールを使用し、自分がどこにいて何に取り組んでいるのかを探索してから最終的な答えを出すような、オープンエンドな問題を与えています。
エージェントとしての実践を多く積むことで、Claudeはこれに本当に優れるようになるのです。
なるほど、つまりこれらの長時間実行されるタスクと、基本的に様々なドメインということですね。そして、強化学習や他の訓練メカニズムのプロセスを通じて、Claudeは基本的に限られたガイダンスやフィードバックでこれらのことを行う方法の目的を学習しているわけですね。
まさにその通りです。私たちはコーディングタスク、検索タスク、その他多くのことについて、Claudeが異なる環境でエージェントとして実践できるよう、多くの強化学習を行っています。
Claudeモデルについて、コードにおいて本当に、本当に強力だという認識があると思うのですが、それが必ずしも他のドメインに転用されるわけではない、あるいはコーディングは独立した別のものだという認識があります。それについて、あなたの一般的な見解はどうですか。
コーディングは私たちが本当に注力してきた最初のタスクですが、素晴らしいコーディングエージェントを持てば、コーディングエージェントは他のあらゆる種類の作業を行うことができます。
検索が必要なら、API経由でウェブ検索ができますし、スケジュールを作成することで週末の計画を立てることもできます。
私たちは、コーディングを、多くの波及効果をもたらすエージェントにとって非常に基本的なスキルとして捉えています。Claudeをあらゆる種類のことに優れさせることができ、まず最も難しいことで訓練すれば、他のすべてが簡単になるという考え方です。
最近、Claude AI on the webでリリースした機能で興味深いことを見たのですが、Claudeがコードを書くことによって実際のファイルを作成できる能力でした。
Pythonスクリプトを書いて、そのPythonスクリプトが実行されると、突然Excelシートが出てくるような感じでした。これが私たちが向かっている未来の方向性なのでしょうか。つまり、Claudeがスクリプトを書いて、コンピュータ上でアクションを起こしてファイルを作成したり、伝統的にコード関連ではないことを行ったりするということですか。
それはClaudeがこれらのことを行えるようになる本当に効果的な方法の1つだと思います。
実際、ほんの数日前、Claudeは私がプレゼンテーション用の図を作るのを手伝ってくれました。SVGを書き出すだけでファイルを作成できたのですが、その後、多くの繰り返しが必要なより詳細な図を作りたいと思いました。それで、Claudeは実際にSVGを生成するコードを書くことでこれを実行できました。これは、Claude自身が書く必要があるよりもはるかに、はるかに速く実行されました。それは非常に、非常に繰り返しの多い画像ファイルで、多くの詳細なパターンが含まれていました。
なるほど。
ですから、多くの場合、何らかの成果物を生成するためにコードを書くことは、その成果物を直接作成しようとするよりもはるかに優れていると思います。より難しいケースに対する1つの方法です。
なるほど、そうですね。コードは、人間がマウスでクリックやドラッグをしてコンピュータを使うのでは実現できないような、ある種のスピードアップを可能にします。
繰り返しのアクションのような。
まさに、Claudeはforループを手に入れるわけです。
ええ、開発者でClaudeを使ってエージェントを構築している場合、最近本当に人気が出始めているものの1つがこのClaude Code SDKです。それが何で、開発者がどのように使い始めているのか、説明してもらえますか。
ええ、開発者がClaude Code SDKを使用していることに、私たちは本当に興奮しています。
これまでは、コーディングエージェントや何らかのエージェントを構築したい場合、APIエンドポイントにアクセスすること以外何もないところから始めて、ループを自分で構築し、すべてのツールを構築し、これらのツールの実行、ファイルとのやり取り、MCPとのやり取りを構築しなければなりませんでした。私たちは基本的にそのすべてをClaude Codeにすでに組み込んでいます。その名前はClaude Codeですが、実際にはClaude Codeは、最も頻繁にコードに使用される汎用エージェントに過ぎません。
ええ、私たちは多くの開発者に、このSDKをエージェントループの中核として使用することを奨励しています。そうすることで、開発者は私たちがすでに多くの時間をかけて磨き上げ、完成させてきたコアエージェントループを再発明することに多くの時間を費やす必要がなくなります。代わりに、それを使用して、MCP経由で独自のカスタムビジネスロジックやアフォーダンスのためのツールを追加するだけで済むのです。
なるほど、つまりコーディング固有の部分を削除できるようなカスタマイズ性を提供しているわけですね。
まさにその通りです。
そして、必要なプロンプトやツールを入れることができ、スキャフォールドにうまくスロットするわけですね。
ええ、Claude Codeを使って、人々があらゆる種類のことに使っていると思います。Claude Codeの私の最も奇妙な使い方は、かつてデートの計画を立ててもらったことです。たくさんのウェブ検索をして、その地域の面白いアクティビティやレストランを見つけました。コードとは全く関係ありませんが、すべてのツールを持っています。
デートはどうでしたか。
とても良かったです。素晴らしかったですよ。
Claudeは良い仕事をしましたか。
ええ、Filoli Gardensと、その近くの中華料理店でした。
わあ、なるほど。
Claudeは良い仕事をしました。
感心しました。
ええ。Claude Codeに関するもう1つのことで、最近多くのソフトウェアエンジニアが使用している人気の機能は、Claude MDファイルです。
これらはプロジェクト内で定義するファイルで、Claudeにあなたのプログラミングスタイルやディレクトリのレイアウトなどに関する関連情報を与えます。私たちは今、おそらくそれをさらに一歩進めた、Skillsと呼ばれる類似のコンセプトをローンチしました。Skillsとは何で、開発者がどのように使い始めているのか、そしてそれがエージェントにとって何を意味するのか説明してもらえますか。
ええ、Claude SkillsはClaude MDファイルの非常にエキサイティングな拡張で、単にノートファイルを与えるだけでなく、あらゆる種類のファイルを与えることができます。
PowerPointテンプレートファイルであったり、使用してほしいコードやヘルパースクリプトであったり、画像やアセットであったりします。そして、単なる指示ではなく、エージェントが使用するリソースというこの拡張は、本当に、本当に強力なツールだと思います。たとえば、PowerPointプレゼンテーションを作成するための指示だけでなく、多くのプレゼンテーションで再利用する必要があるかもしれない、会社のリーダーシップ全員のヘッドショットがここにありますというように、すべてを再利用可能な形でClaudeに与えます。
Claudeが必要とするすべてをその場に持っているようにするわけです。
社内で聞いた1つのアナロジーで、私が本当に、本当に気に入っているのは、「マトリックス」でNeoが初めてカンフーを学ぶときのようなもので、カンフーの情報を注入すると、突然彼がカンフーマスターになるような感じです。それは、私がClaudeに何らかのタイプのスキル、たとえばスプレッドシートの作成方法を与えるときと非常に似ていると感じます。
すると、ああ、突然Claudeがバンカーのようになって、私のために財務モデルを作成できるようになるのです。
それと、装備やツールなどのラック全体をロードする場面ですね。
ええ。
それらを手に取れるようにするような感じです。
そうですね、単なる指示だけでなく、これらのものから始められるのです。
ええ、それは素晴らしいです。
少し話題を変えて、前回ここでカメラの前で話したのは数か月前で、エージェントについて話していました。当時、私たちはワークフローから移行していました。ワークフローとは、プロンプトをどのようにチェーンするかの非常に定義された方法から、モデルをループで実行する単一のエージェントシステムのようなものへの移行期でした。
それ以来、この分野ではどのような進化がありましたか。
ええ、私たちは、ワークフローからエージェントへの移行を本当に見てきました。Claudeはフィードバックに応答して自分の作業を修正することが非常に得意になり、今ではエージェントループは、絶対的な品質を最も重視するほとんどのことについて、ワークフローを劇的に上回るパフォーマンスを発揮しています。
ワークフローは、非常に低いレイテンシが必要で、Claudeにシングルショットで最良の答えを出してもらいたい場合には、依然として優れています。エージェントは今、本当に、本当に高性能です。それ以来発展したことの1つは、私がワークフロー・オブ・エージェントと呼んでいるものです。以前は、アプリケーションにワークフローがあり、ClaudeがシングルショットでデータをロードするためのSQLコマンドを書き、それがワークフローの次のステップに進み、そこでそのデータを表示するチャートを書くというものでした。
そして、SQLコマンドが失敗した場合、データを返していないことを知らず、ワークフローの2番目のステップが…
そうですね。
台無しになってしまいます。
完全に崩壊します。
しかし今では、ワークフローのそれぞれのステップが実際にはクローズドループになっているのを見てきました。SQLクエリへの単一の試行を書くだけでなく、それを実行し、Claudeが出力を見て、正しい値を得たことを確認するまで反復を続け、それからワークフローの次のステップに移行することができます。
なるほど、興味深いですね。つまり、プロンプトをチェーンすることから、今ではループ内のエージェント自体をチェーンすることへの進化ですね。そこからどこへ行くか見ていきましょう。もう1つの大きな議論のトピックで、最近はるかに多くの話題になっていると感じるのは、観察可能性と検証に関する質問です。
その課題は何で、人々はどのように考え始めているのか説明してもらえますか。
ええ、観察可能性はエージェントにとって非常に難しく、特にシステムがより複雑になるにつれてそうです。私がまだ本当に信じている理由の1つは、モデルが1年前よりも今日はるかに有能で、エージェントやさらに複雑なセットアップでよりうまく機能できるとしても、シンプルさは依然として本当に重要なことだということです。エージェントの大きなワークフローを構築できるとしても、
依然として最もシンプルなものから始めて、より複雑なソリューションへと進んでいくべきです。まず、シングルショットを試したり、Claude Code SDKへのシングルショットプロンプトを試したりします。これは今では非常にシンプルで使いやすいものです。そして、必要に応じてのみ、複雑さの層を追加していくべきだと思います。なぜなら、それが観察可能性を難しくするからです。
ワークフロー・オブ・エージェントと並行するもう1つの用語として、マルチエージェントがありますが、それは同じものですか、それとも違うものですか。
ええ、マルチエージェントは今の私の主な研究分野です。ワークフロー・オブ・エージェントとはかなり異なると言えます。
なるほど。
ワークフロー・オブ・エージェントは、1つのエージェントが進み、終了してから、次のエージェントに移行するか、その出力が次のエージェントに送られて作業を続けるというものです。
マルチエージェントは、基本的に複数のエージェントまたは複数のClaudeが同時に作業している場合で、おそらく1つの親エージェントが5つのサブエージェントにタスクを委任し、それぞれが並列に作業できるようなものです。これが私たちのDeep Researchサーチ製品の仕組みで、メインのオーケストレーターエージェントがいくつかのサブエージェントを決定して作成します。
それらは並列に多くの検索を行うことができ、これはユーザーにとってはるかに優れています。なぜなら、これらすべてが並列に行われ、答えがはるかに早く返ってくるからです。Claude Codeでもモデルがサブエージェントを使用するのを見ています。つまり、何らかのサブタスクが数万トークンを要する場合、たとえばクラスの特定の実装を見つけるような場合でも、答えは実際には非常に小さなものに要約されます。サブエージェントでその作業を行って、メインの作業に必要のないトークンすべてからメインコンテキストを保護することができます。
ええ、基本的に作業のこの部分をオフロードして、必要な最終的な答えだけを返してもらうことができるわけです。
では、この場合のサブエージェントを、Claudeが呼び出せるツールのようなものとして公開しているのですか。
まさにその通りです。
プロンプトをパラメータのようなものとして渡すのでしょうか。
まさに、ええ。Claudeにとって、サブエージェントはツールのように見えます。サブエージェントにプロンプトを渡すことができ、サブエージェントはそれを受けて作業を行います。
私の研究の一部は、Claudeをより良いマネージャーにして、どのように…訓練することです。
ああ、興味深い。
サブエージェントに明確な指示を与え、それらから正しいものや必要なものを確実に得られるようにする方法です。
これは、ツール呼び出し全体とどう違うのでしょうか、それともツール呼び出しの専門的な部分のようなものでしょうか、それとも何らかの形で異なるのでしょうか。
この通信プロトコルにツール呼び出しのフレームワークを使用していると言えます。それがたまたま、それ自体が別のClaudeによってバックアップされているツールであるというだけです。
Claudeはサブエージェントが何であるかについて直感的な理解を持っているのでしょうか、それとも教える必要があるのでしょうか。実際に別バージョンの自分自身と話しているんだよ、Claude、怖がらないでというような感じでしょうか。
Claudeは、初めてマネージャーになった人が犯すのと同じ間違いの多くを犯すと言えます。不完全だったり、やや不明確な指示を出したりするような。
そうですね、そうですね。
サブエージェントに対して。
そうですね。
そして、サブエージェントが正しいコンテキストを持っていることを期待しますが、実際には持っていません。サブエージェントに関する訓練中に見たことの1つは、Claudeがはるかに冗長になり、はるかに詳細になり、サブエージェントに何が起こっているのかの全体的なコンテキストを与えるようになることです。
興味深い。
彼らが全体に貢献するより良い作業ができるようにするためです。ですから、Claudeには学ぶべきことがたくさんあり、これについてより良くなるために学習していると言えます。
なるほど、わかりました。
ええ。
使用例は何ですか。検索が1つで、コンテキストの保存がありますが、人々が今マルチエージェントに使用している他のものはありますか。
ええ、コーディングには、サブエージェントの使用がたくさんあると思います。
並列化できるものやMapReduceできるものなら何でも。大量の出力を生成する必要がある場合や、作成している出力の10の部分がある場合、それを10のサブエージェントに分割できれば、コンテキストを節約して結果を速く得るのに本当に、本当に効果的です。テスト時計算の一形態としてのマルチエージェントには、探求すべき興味深いことがたくさんあると思います。
基本的に、多くのClaudeに問題に取り組ませることで、1つだけよりも良い最終的な答えを得ることができます。人と同じように、多くの人が頭を寄せ合うと、より良い結果を得られます。
その場合、これらのエージェントを何らかの形で専門化していますか。1つのタイプのペルソナまたは別のタイプに向けるのか、それとも単にどんな形でも取らせるのでしょうか。
どちらもできると思います。
時には、多くの人に全く同じタスクを与えて、彼らが考え出す異なる答えを見るのが役立つことがあります。時には、多くの人や多くのエージェントに同じ問題に対して異なるアプローチから取り組んでもらったり、それを分割したりするのが良いこともあります。私がよく見るのは、エージェントに使用してほしいツールがたくさん、おそらく100や200のツールを持っている顧客で、それらのツールをサブエージェント間で分割するのが本当に良いと分かっています。
メインエージェントが知っておく必要があるのは、このツールのバケツを使いたいということだけで、そこで実際の作業を行うサブエージェントがいます。各サブエージェントは、理解して使い方を知る必要があるツールが20程度だけです。
エージェントを完全にスケールアップするようなことを試したことはありますか。たとえば、1000バージョンのClaudeすべてが1つの問題に取り組んだらどうなりますか。単に混沌になりますか。
まだ試していません。
なるほど。
でも、後で報告します。
そこに良い研究アイデアがありますね。エージェントやマルチエージェントで今見られている他の失敗モードは何ですか。
ええ、あらゆる種類の複雑なシステムと同じように、何かを過剰に構築して、多くの効率を失い、多くの無駄な重さを生み出してしまうのは簡単だと思います。
過剰に構築されたマルチエージェントシステムが、お互いにやり取りすることに多くの時間を費やし、実際にはメインタスクで進歩を遂げていないのを見てきました。人間のエージェントや人間の組織も同じことに悩まされています。企業が大きくなるにつれて、コミュニケーションのオーバーヘッドが増え、実際に現場で物事を進めている人による作業がどんどん少なくなっていきます。
ですから、研究すべき興味深いことの1つは、オーバーヘッドを小さく保ちながら、Claudeの組織を非常に効果的にするにはどうすればよいかということです。
開発者で、Claude Code SDKで構築しようとしているか、単に自分で試そうとしているかにかかわらず、エージェントを始めたい場合、何かヒントやベストプラクティスはありますか。
ええ、ベストプラクティスは本当にシンプルに始めて、必要な複雑さのみを追加することだと思います。
もう1つの本当に重要なことは、エージェントの視点から考えることだと思います。Claudeにツールやプロンプト、または何らかのアフォーダンスを与える場合は、Claudeの立場になって、モデルとして実際に得るもの、見るものを読んで、問題を解決するのに十分な情報が実際にそこにあることを確認してください。
私たちがすべてを見ていて、モデルは私たちが見せたものだけを見ているということを忘れるのは非常に簡単です。
そうですね。
そうです。
ええ。
ええ、ツール呼び出しやログなどの生のトランスクリプトに戻って、それを見ることが常に重要だと感じます。
まさに、そして、人々がMCPのようなものをより多く構築し、Claudeをより多くのものに接続しようとしているときに、人々が持つ非常に自然な最初の本能で、非常に間違っているのは、MCPやツールがAPIと1対1であるべきだということだと思います。実際には、モデルのためのツールやMCPは、APIではなく、UIと1対1であるべきだと思います。なぜなら、最終的にモデルはこれらのものの利用者だからです。従来のプログラムのようには機能しません。ですから、APIには、たとえばSlackの会話をロードし、ユーザーIDをユーザー名に変換し、チャンネルIDをチャンネル名に変換するための3つの別々のエンドポイントがあるかもしれません。
それらがSlackを理解するためにモデルに与えるツールである場合、何かを理解するために、3回のツール呼び出しを行わなければならないことになります。一方、ユーザーとしては、すべてがきれいにレンダリングされて見えるだけです。
ああ、それは興味深い。
ですから、できるだけ少ないやり取りですべてを一度に提示するツールやMCPをモデルのために作成したいのです。
ユーザーにとって、Slackを使うたびにユーザーIDをクリックして名前を確認する必要があるなどしたら、ひどいことになるのと同じです。
そうですね、そうですね、それは好きですね。つまり、技術仕様を1対1でマッピングしようとするのではなく、ある種、最終状態から逆算して作業するような感じですね。
まさに、そして必要なコンテキストを周囲に配置するような感じです。
将来のエージェントには何が待っていると思いますか。今後6か月から12か月について何か予測はありますか。
エージェントは、ソフトウェアエンジニアリングのような検証可能な分野から始めて、はるかに広く普及していくと思います。コーディングエージェントはすでに私の働き方とAnthropicの多くの人々の働き方を変えており、そこにはまだ得られるべき膨大な量のものがあると思います。
本当にエキサイティングなことの1つは、エージェントがComputer Useのようなもので自分の作業を検証することに優れ始めることができれば、ウェブアプリを書くことができるが、実際にそれを開き、テストして、自分でバグを見つけることができるかどうかということです。あなたがそれをする必要がない代わりに。それが最もエキサイティングなことの1つだと思います。
ええ。
テストのループを閉じて、私がClaudeのQAエンジニアになる必要がないようにすることです。
そうですね、ソフトウェアエンジニアリング能力からComputer Use能力まで、これらすべてのピースをまとめると、ある種これらすべてを組み合わせるような感じですね。
ええ、Computer Useは、エージェントがこれまでロックアウトされてきた多くの他の道やドメインを本当に開くと思います。
それの例は何でしょうか。
Claudeに、Google Docであなたのために作業をしてもらいたい場合を考えます。
ええ。
今のところ、Claudeはあなたのために書くことができますが、あなたはコピー&ペーストを繰り返しています。
そうですね。
しかし、Computer Useがあって、「ねえClaude、このGoogle Docをきれいにしてくれますか」と言えば、そこであなたのためにそれを実行できます。
スクロールしたり、クリックしたり、テキストを編集したりして、それはコピー&ペーストを繰り返す必要があるよりもはるかに良い体験です。
ええ。
あなたがどこにいても、Computer UseがあればClaudeがあなたと一緒にいることができます。
まあ、私はClaudeに私のGoogle Docsを書いてもらい、すべてのコメントに返信してもらうことに非常に興奮しています。
まさに。
それは非常に素晴らしい未来でしょう。Erik、これは素晴らしかったです。会話をどうもありがとうございました。
もちろん、ありがとうございました。
コメント