この動画は、AIエージェントの効果的なツール構築について解説したものである。従来のソフトウェア開発とは異なり、エージェントシステムでは自然言語による入力から非決定論的な応答を生成するため、ツール設計の根本的な見直しが必要となる。適切なツール選択、コンテキスト管理、プロンプトエンジニアリング、評価手法といった重要な原則を具体例と共に紹介し、実世界での運用を想定した実践的なアプローチを提示している。
エージェント用ツール構築の基本原理
さあ、エージェント用のええツールをどうやって作るかについて話していこうか。なんでかって言うたら、エージェントの効果っちゅうのは、使えるツールとモデルの賢さに左右されるからや。ほんで、これを細かく分解して実践的な洞察を見ていって、最後にはツール実装の考え方を根本から変えてもらえるように話していくで。
この動画のアイデアは、Anthropicが書いたブログ投稿「エージェントでエージェント用の効果的ツールを作る」から来てるんや。主要な発見と実践的な洞察を見ていくけど、その前にエージェントシステムでソフトウェア工学がどう変わってるかを考えんとあかん。
従来のソフトウェア工学では、ツールの中核機能を実装してそれを関数でラップするやり方やったな。これは決定論的システムで、入力を与えたら決定論的な応答が期待できる。でもツールになると話が変わってくるんや。
普通、入力は自然言語のクエリになる。それからエージェントが自分の計画に基づいて、取るべき手順を決めるんや。ツール呼び出しをするか、内部知識を使うか、はたまた追加質問をするかもしれん。
同じ質問を毎回しても、エージェントが思いつく手順は違ってくるんや。そしてこういうエージェントシステムは従来のソフトウェア工学スタックの一部になってるから、これらのシステムの実装方法を根本から見直す必要があるで。
ツール構築の4段階プロセス
ブログ投稿では、ええツールを作るための4段階プロセスについて話してる。うちらの焦点は主にええツールを書くための重要な原則についてやけど、完全性のために言うとく。
まずは中核機能を実装する初期プロトタイプから始めたい。それから実装したツールで評価を実行する。それからコーディングエージェントと協力する。
基本的にコーディングエージェントの知能を使って、ツールの説明と実装を改善してもらうんや。最終的には評価を実行したい。測定できひんもんは改善でけへんからな。これは反復プロセスが普通や。
でもツール自体の実装に関しては、頭に入れといてほしい重要な原則があるで。
ツール実装の重要原則
最初は実装する適切なツールを選ぶことや。心配せんでええ、これ全部詳しく話していくから。それから異なるツールをグループ化できるようにする。これでエージェントがええツールを選びやすくなる。
それからコンテキストエンジニアリングについてたくさん話すで。ツールへの入力が意味のあるもんになるようにしたい。また、ツールからの戻り値もLLMに渡せる意味のあるコンテキストにしたい。
これはトークン効率にも関わってくる。無駄な情報でモデルのコンテキストを埋めたくないからな。プロンプトエンジニアリングは死んでへん。LLMが適切なツールを選ぶのに役立つツール説明を効果的にプロンプトエンジニアリングする方法について話していく。
それから、ツールが多いからって必ずしもええ結果になるとは限らん。従来のソフトウェア工学と同じで、小さな改良が劇的な改善をもたらすんや。
タスク実行フローの理解
このフローを見てほしいんや。エージェントにタスクが与えられたとする。エージェントはサブタスクごとに異なるツールをいくつか選択できる。ツールの入力と出力がモデルやLLMやエージェントのコンテキストウィンドウに追加されて、このコンテキストウィンドウに有用な情報だけを保持する方法を慎重に考える必要があるんや。
AIエージェント用のええツールの例がBrowser Baseや。AIエージェントとアプリケーション用のウェブブラウジング機能を提供してくれる。PuppeteerやPlaywrightみたいなツールをホストできるクラウドプラットフォームやと思ってもらったらええ。AIエージェントと連携できて、今日の動画のスポンサーでもあるんや。
拡張性、速度、セキュリティが高いプラットフォームで、ブラウザ自動化用の独自カスタムエージェントを作成できる。既存のブラウジングツールがあって、ワークフロー自動化を可能にして、ウェブサイトからのウェブスクレイピングもできる。
でも一番気に入ってる機能はStage Handっちゅうやつや。これはオープンソースのAIブラウザ自動化フレームワークで、アクションを定義してエージェントにタスクを割り当てることでブラウザ自動化を可能にしてくれる。これには非常に強力なSDKが付いてて、自分のアプリケーションで使い始めることができる。
このSDKにはコンピュータ使用エージェントを含む既存エージェントがいくつかあって、Playwrightと完全互換やからStage Handでブラウザ自動化は非常に簡単や。自然言語でPlaywrightとやりとりできるんや。
例えば、ウェブページに行きたかったら、こういうコマンドを使う。何かアクションを取りたかったら、自然言語で記述するだけでええ。コンピュータ使用エージェントも使える。一番ええのは、どのウェブサイトからでもデータをスクレイピングしたい時に独自のカスタムスキーマを定義できることや。エージェントがそのデータを抽出して返してくれる。
ウェブブラウザとやりとりするエージェント用の非常に有用なツールや。ぜひチェックしてみてな。リンクは動画の説明欄にあるで。それでは動画に戻ろう。
適切なツール選択の原則
最初の原則はタスクに適したツールを選ぶことや。ツールが多いからってええ結果が得られるわけやない。よくある間違いは、既存のソフトウェア機能やAPIをツールでラップしてエージェントにツールとして提示することやって言うてる。
そういう風にツール実装を考えたらあかん。LLMのコンテキストウィンドウについて考えなあかん。ツールは複数の異なる操作のカスケードを持つことができて、エージェントが使える意味のある結果だけを生成したいんや。
住所録検索の非常に簡単な例を見てみよう。従来のソフトウェア工学では、全連絡先をメモリに読み込むシステムを実装できる。それから各連絡先を反復処理して、マッチするものがあったらその結果が返される。
エージェントシステムで使いたかったら、これに対して複数の異なるツールを書くことができる。例えば、連絡先をリストアップするツールがあって、500の連絡先を全部返すとする。各連絡先が50トークンやとしたら、約25,000トークンになる。
それからエージェントにそれらを一つずつトークンごとに見させるか、別のツールでトークンごとに処理させるかもしれん。結局、エージェントのコンテキストウィンドウを無駄な情報で埋めてしまうことになるんや。
これの代わりに、ええアプローチは従来のソフトウェア工学の設定を使って検索して、意味があると思われる連絡先の非常に小さなサブセットだけを返すツールや。シンプルなRAGシステムでもええから、その結果をエージェントに渡す。エージェントは1つか2つの連絡先を探してるだけやからな。
考え方としては、ツールを設計する時は人間がそれらのツールとどうやりとりするかを考えるべきや。例えば、検索メカニズムが欲しい、ブラウズやない。フィルターが欲しい、スキャンやない。ナビゲートが欲しい、物事を反復処理するんやない。
ツールのグループ化とネームスペース
もうちょっと例を挙げるで。ユーザーリスト、イベントリスト、イベント作成っちゅう3つの別々のツールを実装する代わりに、可用性を見つけてイベントをスケジュールするイベントスケジュールツールの実装を考えてみ。基本的に複数の異なるステップを単一のツールの中にラップしてるんや。
もう一つの例は、ログ読み取りツールを実装する代わりに、関連するログと周辺テキストだけを返す検索ツールの実装を考えることや。また検索や、スキャンやない。
もう一つのアイデアはツールの名前空間化や。似たようなツールをまとめてグループ化したいんや。今現在、エージェントがアクセスできるMCPが何十個もあって、それぞれが非常に似た機能を実装してるかもしれん。エージェントがどのツールを選ぶか決めなあかん時、混乱する可能性が高いんや。
これは非常にシンプルな表現や。異なるMCPサーバーがいくつかあって、それぞれが検索、作成、更新、削除などを実装してるとする。MCPサーバーに基づいてグループ化せずに似たような名前を使ってたら、エージェントは混乱してしまう。
でも、グループ化したらどうや。例えば、Slackメッセージ用の名前空間があって、Jira専用のツールがある。これらのプレフィックスを各ツールに追加したら、どのタスクにどのツールを使うかエージェントが決めるのに本当に役立つで。
興味深い洞察があるんや。エージェントのツール使用評価に関して、プレフィックスとサフィックスを使う場合に違いがあるみたいやな。だから両方実験してみた方がええ。ツール名の前か後に名前空間を置いて、ツール使用やツール呼び出しパフォーマンスに影響があるかどうか見てみるんや。
これらのシステムはどんどん賢くなってるけど、こういう非常に小さなニュアンスの変化で躓くことがあるんや。
ツールからの情報返却の最適化
次のパターンは、ツールから情報をどう返すかの考え方や。ツール呼び出しをした時、結果が得られる。その結果に何を追加するか？
一般的なロジックは可能な限り多くの情報を追加することやけど、それは実際に裏目に出ることがある。ツール実装はエージェントに高シグナル情報だけを返すように注意すべきで、その情報が実際に意味をなすようにしたいんや。
UUIDや暗号化された画像URLみたいな低レベルの技術識別子を返す代わりに、名前、画像URLみたいなより記述的なフィールドを返したい。
低レベルの技術識別子も役立つ場合があるから、低レベルと高レベルの詳細の両方を保持する構造化出力や構造化フォーマットで返したい。彼らによると、エージェントは暗号的な識別子よりも自然言語の名前、用語、識別子の方をはるかにうまく扱う傾向があるらしい。
別の質問として、XML形式、JSON、Markdownのどれで返すべきか？今のところ、これはモデルがどう訓練されたかによるな。例えばClaudeはXML形式が大好きで、OpenAIモデルもXMLを好む傾向がある。以前はJSONがかなり得意やったけどな。実際に使ってるモデルを見て、それに基づいて返すデータ形式を決めたいんや。
トークン効率とコンテキスト管理
次は、返すトークン数の観点からツール応答を最適化することを考えたい。コンテキスト管理が重要になってくる。コンテキストの質を最適化することも大事やけど、ツールの応答として返されるコンテキストの量を最適化することも同じくらい重要や。
返される長いコンテキストについては、ページネーション、範囲選択、何らかのフィルタリングや作成メカニズムの使用を提案してる。デフォルトでは、Claudeはツール応答を25,000トークンに制限してる。
操作を実行するのに12回のツール呼び出しをするとしたら、これは積み重なっていく。実際に返したい情報の量について本当に注意深く考えなあかん。一つの方法は単純にレスポンスを作成することや。いくつかの戦略がある。
例えば、知識検索タスクで単一の幅広い検索の代わりに小さくて的を絞った検索をするみたいな、よりトークン効率的な戦略を追求するようエージェントを直接奨励できる。さっき話した連絡先帳の例に非常に似てるな。
プロンプトエンジニアリングとツール説明
最後やけど重要なのは、ツール説明のプロンプトエンジニアリングや。これは人がよく無視する部分やけど、もっと注意が必要やと思う。考え方としては、エージェントがツールを選択する時、主にツールの説明と入出力を見るんや。
ツールが何をするべきかに細心の注意を払いたい。機能の仕様と共に入力変数とツールからの出力を適切に名前付けしたい。
これを考える非常に簡単な方法は、新しいインターンを雇ったとして、システムや設定について何も知らないと仮定して、どんな情報が必要かということや。それを念頭に置いて、特殊なクエリ形式の定義、ニッチな専門用語の定義、基礎リソース間の関係も提供して明示的にしたい。
アイデアはエージェントが仮定を立てなあかん曖昧さを避けることや。これは重要や。本当にええエージェントシステムと、ツール選択で混乱した失敗したエージェントシステムの間の主な鍵はコミュニケーションや。
エージェントでのツール改善
記事の残りの部分は主にエージェントでこれらのツールをどう改善するかに焦点を当ててる。アイデアは非常にシンプルや。ツールの初期実装を思いつく。それから実世界の評価テストケースを作成する必要がある。
これは重要で、よく見るのは人が実際の実世界のユースケースと何の関係もない合成例を思いつくことや。そして非常に悲しいことに、これらのシステムはそういう合成評価では本当にうまくいくけど、実世界のテストになると失敗するんや。
理由は、これらのテストセットや評価セットを構築する時に、実際の実世界のユースケースをキャプチャしてないからや。全ての推奨事項に従ったら、エージェントでそれらのツールを反復したい時は、可能な限り多くの情報を提供したい。
それには必要な全てのドキュメントが含まれる。アイデアとしては、エージェントをテストできる評価セットを作成することや。また、ツールを単独でテストする代わりに、複数の異なるツールを組み合わせる複雑なシナリオでテストしたいことも確認したい。
例えば、これは弱いテストタスクや。ツールやエージェントに来週誰かとミーティングをスケジュールしてと聞いたら、エージェントはそのツール一つだけを選択してミーティングをスケジュールするかもしれん。
でも、テストはこんな感じにすべきや。来週Janeと最新のプロジェクトについて話し合うミーティングをスケジュールして、最新のプロジェクト計画ミーティングのノートを添付して、会議室を予約して。
これでエージェントは計画を立てて、その計画を達成するために複数の異なるツールを選択することになる。これは評価データセットで非常にシンプルな単一ツール選択例を持つより、現実的な実世界のテストケースやと思う。
そして繰り返すけど、これは重要や。システムを構築しながらシンプルな評価テストを実行する失敗例をたくさん見てきたけど、実世界の複雑さのためにそれらのシステムは失敗するんや。
その後、エージェントループを持つことができる。基本的に与えられた評価セットでこれをループで実行する。情報を集めて、システムが生成するフィードバックも見る。それからそのフィードバックをエージェントと一緒に使ってツールを改善するんや。
彼らの内部テストに基づくと、エージェントを使ってツールを改善すると、実際に大幅にええパフォーマンスが得られるって示してる。評価設定についてより詳細な動画を作ってほしいかどうか教えてな。いくつかのノートブックがあるから、動画の説明欄に載せとく。
この動画が役に立ったと思うし、ええシステム構築でヘルプが必要やったら連絡してな。詳細は動画の説明欄にある。とにかく、この動画が役に立ったと思う。見てくれてありがとう。いつものように、また次回で会おう。
コメント