2024-12-07 AWS re:Invent 2024: ツール使用とエージェントの最前線 - LLMアクションの高度なテクニック

※本記事は、AWS re:Invent 2024で開催されたセッション「Tool use & agents at the frontier: Advanced techniques for LLM actions (AIM306)」の内容を基に作成されています。このセッションでは、John Baker氏（Amazon Bedrock）とNicholas Marwell氏（Anthropic）が、LLMのツール使用とエージェント技術について解説しています。本記事では、セッションの内容を要約しておりますが、原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご覧いただくことをお勧めいたします。動画は https://www.youtube.com/watch?v=nLrDOTuIMDA でご覧いただけます。また、AWS関連の詳細情報については、公式ウェブサイト（https://aws.amazon.com/ ）もご参照ください。AWSイベント情報は https://go.aws/3kss9CP でご確認いただけます。

1. イントロダクション

1.1 セッションの目的と概要

このセッションでは、LLM（大規模言語モデル）と自動化の可能性について探求します。過去1年間でLLMは急速に進化し、これらのモデルを使った自動化の約束が現実のものになってきています。このトークは特に、LLMを使って業務を自動化したい方、推論、計画、オーケストレーション、ツール使用における最新の進歩を確実に活用したいと考えている方を対象としています。

セッションでは、まず「ファンクションコーリング」あるいは「ツール使用」とは何か、その起源について掘り下げます。次に、ファンクションコーリングとAnthropicのClaudeのようなパワフルなモデルに内蔵されているビジネスドメイン知識をどのように組み合わせて複雑な問題を解決できるかを探ります。さらに、ツール使用とコーリングに関するベストプラクティスを共有し、「エージェントとは何か、そしてファンクションコーリングとどのように関連しているのか」という問いについても検討します。「エージェントとは何か」という問いは一見簡単に思えるかもしれませんが、エージェントの定義の複雑さとそれがプロジェクトに与える影響について理解を深めることができます。また、エージェントのオーケストレーションの詳細や、そのオーケストレーションが重要である理由、行わなければならないトレードオフなどについても掘り下げます。そして最後に、Claudeのビジネスドメイン知識とエージェントのパワーを組み合わせて、さらに複雑な問題に取り組む方法を探ります。

このセッションは、LLMの能力を拡張し、外部世界と接続するために必要な技術や概念について、実践的かつ理論的な観点から理解を深める貴重な機会となります。

1.2 発表者の紹介（John Baker, Amazon Bedrock と Nicholas Marwell, Anthropic）

このセッションは、Amazon BedrockとAnthropicからの二人の専門家によって進行されます。まず最初の発表者はJohn Bakerで、Amazon Bedrockのプリンシパルエンジニアとして働いています。彼はBedrockのエージェント機能を専門としており、エージェント技術の開発と実装に深く関わっています。このセッションでは主に、Amazon Bedrockのエージェント機能の詳細、オーケストレーション戦略、実際の使用例などについて解説を担当します。

もう一人の発表者はNicholas Marwellで、Anthropicのテクニカルスタッフメンバーです。Anthropicは大規模言語モデルClaudeを開発している企業です。Nicholasはツール使用とエージェント技術に関する専門知識を持ち、特にClaudeモデルのファンクションコーリング機能の仕組みや、ベストプラクティスについて詳しく説明します。また、エージェントの定義や、モデル能力の進化についての洞察も提供します。

二人の発表者は互いの専門分野を補完しながら、理論から実践まで、LLMのツール使用とエージェント技術の全体像を提供します。

2. ファンクションコーリング（ツール使用）の基礎

2.1 問題提起：LLMの制約とリアルタイムデータへのアクセス

Nicholas: まずツール使用とエージェントに関する背景について、少し歴史的な観点から始めたいと思います。「ロンドンの今の天気はどうですか？」という質問に、LLMがどのように答えてきたかを見てみましょう。最初、モデルはテキストのみでした。claude.aiでロンドンの現在の天気を聞くと、「申し訳ありませんが、リアルタイムの天気情報にアクセスできません」と回答していました。これはClaudeが天気データを必要としていることを理解しているからです。Claudeは1996年6月20日のロンドンの天気のような過去のデータは参照できるかもしれませんが、リアルタイムデータへのアクセスがなく、また5秒前にトレーニングされたわけではないので、この質問に正確に答えるための情報を持っていません。この点でしばらく行き詰まり、これがモデルができることを大きく制限していました。

そこで私たちは、モデルが外部世界から読み取りや書き込みができるようにする方法を必要としていました。ここで関数（一部の人はツール使用、一部の人は関数呼び出しと呼んでいますが、このプレゼンテーションではこれらの言葉を互換的に使用します）が始まりました。実際にはclaude.aiではこのようにはしませんが、何が起こっているかを理解するのに役立つ方法として、ユーザーからの質問を聞く前に、モデルに質問に答えるときに使用できるツールのセットがあることを伝えます。ここでは、get_weatherツール、order_pizzaツール、send_emailツールへのアクセスを提供したとします。

そして、ユーザーの質問も渡すと、Claudeは利用可能なツールを確認し、1つまたは複数のツールが関連しているかどうかを判断し、ユーザーのリクエストを満たすために必要なデータを取得したりアクションを実行したりするためにそのツールを呼び出します。この場合、「get_weather London」とします。その後、従来のソフトウェアプロセスを使用してモデルからのリクエストを処理し、結果を返します。Pythonで書かれたget_weather関数をargument「London」で実行し、「ロンドンの天気は華氏47度です」というデータをモデルに返すかもしれません。モデルはこれを受け取り、ユーザーの質問に答えるのに十分な情報を持っていることを理解し、元のクエリへの回答を出力します。

「get_weatherツールによると」という表現を避けたい場合もあるでしょうから、プロンプトを使ってそれを削除することもできます。このように、モデルが外部世界から読み書きできるようにするという問題の解決が始まりました。

2.2 ファンクションコーリングの歴史的背景とMRKL（miracle）システム

John: ファンクションコーリングがなぜ必要なのか、その歴史をたどってみましょう。LLMは「100 + 100」のような問題を解けるでしょうか？おそらく「それよりもっと難しい問題も解けるよ」と思うかもしれません。しかし「strawberry（いちご）にはrの文字がいくつあるか」という有名な問題があります。驚くべきことに、これが正確に答えられないことがありました。「100 + 100を解く」ことと「strawberryにはrがいくつあるか数える」ことは同じような問題なのです。

ツール使用のアイデアを遡ると、2022年頃の論文「Miracle Systems MRKL: Modular, Reasoning, Knowledge, Language」にたどり着きます。一般的には「miracle（ミラクル）」と発音されています。この論文は当時の生成AIに大きな影響を与えました。実際、Langchainのようなエージェンティックソフトウェアには、この論文のアイデアに基づいたクラスが作られています。このクラスは今は非推奨になったと思いますが、コメントにはまだこの論文への参照が見つかります。

この論文では何が発見されたのでしょうか？彼らは2桁の簡単な数学、例えば「10 + 10」をモデルが約100%の正確さで答えられることを示しました。3桁の数学、例えば「100 + 100」は約80%、つまり10回中8回は正解でした。4桁の数学は約25%、5桁の数学は9%でした。これは全て単純な算術（足し算、引き算、掛け算、割り算）だったことを覚えておいてください。彼らは5桁の基本的な数学で、正解率が10回に1回未満だということを発見しました。

何が起きていたのでしょうか？LLMは数学が苦手なのでしょうか？実はそうではありません。この特定のモデルのトレーニングデータを調査すると、トレーニングで見た数学の問題のほとんどは2桁の数学で、3桁の数学もかなりあり、4桁の数学はごくわずか、5桁の数学はほぼゼロだったのです。そのため、モデルがあまり見慣れていないものを与えられたとき、この世代のモデルでは非常に正確さに欠けていました。

彼らはどうやってこの問題を解決したのでしょうか？なんと、ほぼ100%の正確さまで戻したのです。解決策は、モデルに問題を解かせるのではなく、計算機があると伝えることでした。

私はBedrockコンソールでClaude Sonnet 3.5を選択して、「数学の問題があるときはいつでも計算機を使ってください。そして『Calculation』または『Calculator, Operation, Operand, Operand』という形式で出力してください」と指示しています。例も提供しています。そして「10 + 10は？」と尋ねると、モデルは出力を提供します。

これによって、文章問題でさえも正確さが100%近くになりました。もはや「10 + 10は？」のように尋ねる必要はなく、「りんごが10個あって、さらに10個買いました。合計でりんごはいくつありますか？」と聞くこともできます。

なぜ正確さが100%近くに戻ったのでしょうか？それはトランスフォーマーモデルが注意機構を持っており、これによってLLMは非常に優れた分類器になっているからです。文章内の単語や操作を組み合わせて「計算機」として分類し、操作を選び出し、オペランドを解析することが非常に得意なのです。非常に高い精度で行えます。

これで問題は解決したように思えます。しかし、一つの問題を解決すると、何が起こるでしょうか？新しい問題が生まれますよね。

2.3 LLMの数学的能力の限界と計算ツールの必要性

John: MRKL論文から得られたデータは非常に興味深いものでした。モデルのトレーニングデータを調査した結果、桁数によって計算の正確さが大きく変わることがわかりました。具体的には、2桁の数学（10+10など）では正確さが約100%、3桁の数学（100+100など）では約80%、4桁の数学では約25%、5桁の数学では9%と急激に低下していきます。さらに基本的な5桁の数学では、正解率が10回に1回未満という結果でした。

この現象の原因はトレーニングデータにありました。モデルが見たトレーニングデータのほとんどは2桁の数学問題で、3桁の数学問題もそれなりにありましたが、4桁の数学問題はごくわずか、5桁の数学問題はほぼ皆無だったのです。つまり、モデルがトレーニングであまり見慣れていないものに対しては、正確さが著しく低下するというパターンが確認されました。

この問題の解決策として彼らが採用したのが、モデルに計算機能をツールとして提供するアプローチでした。具体的には、「あなたには計算機があります。数学の問題があるときはいつでも計算機を使ってください」というプロンプトを与え、「Calculation」または「Calculator, Operation, Operand, Operand」という形式で出力するよう指示しました。

例として「10 + 10は？」と質問すると、モデルはこの形式に従って出力します。この方法により、複雑な数学問題でも正確さが100%近くまで回復しました。さらに、直接的な数式だけでなく、「りんごが10個あって、さらに10個買いました。合計でりんごはいくつありますか？」のような文章問題でも高い正確さを達成できるようになりました。

この劇的な改善が可能だった理由は、トランスフォーマーモデルが持つ注意機構にあります。LLMは分類タスクが非常に得意で、文章中の単語や操作を「計算機」として適切に分類し、操作と被演算子を正確に抽出することができます。つまり、モデル自体に計算させるのではなく、モデルには「何を計算すべきか」の判断だけをさせ、実際の計算は別のツールに任せるという分業が効果的だったのです。

2.4 初期のツール使用の課題：幻覚、プロンプトインジェクション、構文解析の問題

John: 計算ツールを使って一つの問題を解決したとき、何が起こるでしょうか？新たな問題が生まれるのです。初期のツール使用にはいくつかの重要な課題がありました。

まず一つ目は幻覚の問題です。「計算機があります。計算が必要なときにはこの計算機を使ってください」というように例を含めると、モデルは多くの場合、自分がアクセスできるツールの例を提示されていると誤解していました。その結果、計算機に似た新しいツールを勝手に作り出してしまうことがあったのです。

二つ目の問題はプロンプトインジェクション攻撃です。すべてを同じプロンプトに入れていたため、ツールの説明とユーザー入力が同じ場所に配置されていました。これによりユーザーはツールについて質問できるようになり、公開したくない情報が露出する可能性がありました。

三つ目の問題は入力と出力の冗長性です。これは非常に多くの入力トークンをもたらしました。LLMのレイテンシーは基本的に入力トークンの関数なので、効率が悪くなります。

さらに、一貫性のない応答が構文解析の問題を引き起こしました。ツールを使いたいのか最終的な回答を提供したいのかを認識し、解析できる特定の構文が必要になります。当時のLLMはそれが得意ではありませんでした。多くの場合、ツールを自然言語で出力したり、ツールのように見える最終的な応答を出力したりして、オーケストレーションに問題を引き起こしていました。

これが、Anthropicなどのモデルプロバイダーがツール専用の特殊な構文に移行した理由です。いくつかの重要な点に注目してください。Nicholas氏がツール使用について詳しく説明する際に、これらの要素を見てください。

特殊な構文によって、ユーザーの質問をシステムプロンプトやツール定義から分離できます。モデルは提供されたツールを使用するようにトレーニングされているため、入力をそれほど冗長にする必要がありません。また、モデルは停止理由を提供し、それは決定論的です。「tool use（ツール使用）」と言うでしょう。Nicholasが実例を示すと思いますが、これに依存すれば、出力テキストを解析するよりも信頼性が高くなります。

Nicholas: それでは、ツール使用について詳しく説明していきましょう。

3. ツール使用の詳細と実装

3.1 ツール使用の基本的な仕組み

Nicholas: このセッションにいる皆さんは、既にLLMを使った開発を少しはされていると思います。また、おそらくモデルが外部世界から読み取りや書き込みをする必要があるとか、モデルにスキル不足がある場合など、いくつかの課題に直面し始めているのではないでしょうか。現在のモデルは以前よりも5桁の計算が少し得意になりましたが、知識や知能を補完したい領域はまだまだ多くあります。

多くの方は、ツール使用の「どのように」を抽象化するパッケージやライブラリから始めたかもしれません。これはAnthropicのツール使用API、Bedrockエージェント、Langchainなどかもしれません。次の数分間でやりたいのは、この抽象化のレイヤーを剥がして、フードの下で何が起こっているのかを見せることです。そうすることで、(A)思っているよりも単純であることと、(B)開発者にとっての優れたドキュメントを書くのと同じように、ツールの素晴らしい仕様を書くことがなぜ重要なのかを理解していただけると思います。

ツール使用は実際にはこのような形で行われます。これは写真を撮っておくといい図です。実は非常にシンプルです。まず、プロンプトでモデルに対して従うべき関数呼び出し構文と、アクセスできる関数やツールのセットを説明します。次に、これをユーザーメッセージ、つまりモデルに試行してほしいことと同じプロンプトで組み合わせます。

これらをモデルに渡して完了を生成します。次に、そのモデルの完了結果を取得し、関数呼び出しが含まれているかどうかをチェックします。含まれている場合は、モデルが行っている関数呼び出しを解析し、従来のソフトウェアを使用してクライアント側、サーバー側、どこであれ実行します。

それが完了したら、従来のソフトウェアの結果を、前のプロンプトで与えたすべての情報とともにモデルに戻します。そして、モデルに別の応答を生成させます。モデルが関数呼び出しを行わなくなるまで、これを繰り返します。それは、モデルが作業が完了し、尋ねたタスクへの回答を持っていることを意味すると解釈します。

そして、その最終的なタスクを取り、舞台裏で行われていたすべてのツール使用をユーザーから隠し、最終的な結論だけをユーザーに返すことができます。または、もし望むなら、途中で使用したプロセスも共有できます。おそらくユーザーに何が起こっているのか監査してもらいたい場合などですね。

3.2 ツール使用の実装ステップ：関数の定義、ユーザーメッセージ、モデル応答

Nicholas: それでは、これらの各ステップをもう少し詳しく見ていきましょう。これらは実際にどのようにプロンプトやコードで機能するのでしょうか？

まず必要なのは、関数呼び出し構文と利用可能な関数です。ここではとてもシンプルな例を示します。関数呼び出し構文は次のようなものかもしれません：「この環境では、functions タグで定義された一連の関数にアクセスできます。以下の構文を使用して関数を呼び出します」、そして、XMLの構文を示していますが、これを機能させるためには実際にはいくつかの異なる方法を使用できます。

また、「以下の関数にアクセスできます」とし、この例では1つしか示していませんが、Claudeは現在、数十、場合によっては数百のツールを一度に処理できます。これについては後ほど詳しく説明します。ここではJSON仕様を使って関数を記述していますが、ここでも、モデルが簡単に解釈できると思うものであれば何でも構いません。JSONは良いスタート地点です。

次に、ユーザーメッセージが必要です。示したツールに関連する例を使って、実際に使用できるようにしましょう。「私はオースティンにいます。今日はコートが必要ですか？」というようなユーザーメッセージが考えられます。モデルがこの判断をするためには、まず天気を知る必要があることがすぐにわかりますね。なぜモデルがこれに答える必要があるのかすぐにわかります。

これらをすべて収集しました。皆さんの多くは完了APIを呼び出したことがあると思いますが、システムメッセージとユーザーメッセージを持つことができます。これをメッセージリストにコンパイルします。そして次のステップは、それらからモデル応答を生成することです。

この質問をしたとき、モデル応答はおそらく次のようになります。モデルは、ツール関数呼び出しに使用すべきと説明した構文を出力し、呼び出したい関数の名前、渡したいパラメータ、この場合は都市「Austin」と州「Texas」を出力しています。

ここで本当に重要なことは、見えていないことですが、John氏が先ほど言及したように、Claude APIの呼び出しに追加の停止シーケンスパラメータを追加していることです。通常、これらの完了APIでの言語モデルを呼び出すとき、モデルがトークンの生成を停止して何かを返すべきときを知るためにトレーニングされた、デフォルトの停止シーケンスセットがあります。しかし、実際には望む追加の停止シーケンスを追加することができます。そして、ツール使用ではこれを活用しています。

ツール呼び出しの構文を知っているので、モデルが完了したときに出力する特定のトークンを知ることができ、そのトークンの直後に停止させることができます。なぜそうしたいのでしょうか？トークンを節約しようという理由もあるかもしれませんが、もっと重要な理由があります。モデルは次のトークン予測マシンであり、関数呼び出しの記述を終えた後も生成を続けさせると、次に見られるのは関数呼び出しからの回答または応答だと予想します。

実際、モデルはここから先に進ませると、答えを作り出してしまいます。これは関数の結果をシミュレートしたい場合の優れた方法ですが、この停止シーケンスを使用しないと、モデルは関数呼び出しで停止せず、続行して関数への結果を作り出し、ユーザーに回答を提供します。

そこで、モデルを停止させ、今度はチェックを行う必要があります。これは、Claude APIからの回答に関数呼び出し構文が含まれているかどうかをチェックする非常にシンプルなPythonコードスニペットです。停止理由が停止シーケンスであり、停止シーケンスが予想される関数呼び出し終了シーケンスであるかどうかをチェックします。そうであれば、これが関数呼び出しを含んでいると確信を持って知ることができます。

3.3 停止シーケンスの重要性

Nicholas: ツール使用において停止シーケンスの使用が非常に重要である理由について深掘りしておきたいと思います。通常、言語モデルのCompletions APIを呼び出す際には、モデルがいつトークン生成を停止して結果を返すべきかを知るために、デフォルトの停止シーケンスのセットが用意されています。しかし、ツール使用においては追加の停止シーケンスを指定することが不可欠なのです。

なぜかというと、モデルは本質的に「次のトークン予測マシン」だからです。モデルが関数呼び出しの記述を終えた後も生成を続けさせると、何が起こるでしょうか？モデルは次に表示されるべきものは関数呼び出しへの応答や結果だと予測します。そして、実際にその関数が実行されていなくても、モデルは自ら答えを作り出してしまうのです。

例えば、天気を調べる関数を呼び出した後に停止させなければ、モデルは「オースティンの現在の気温は75度です。雨の確率は10%です」というような結果を自ら生成してしまうでしょう。これは実際のデータではなく、モデルが作り出した情報なので幻覚（ハルシネーション）と言えます。

この問題を回避するために、私たちはモデルが関数呼び出しを完了した直後に停止するよう、特定の停止シーケンスを設定します。ツール呼び出しの構文を知っているため、モデルが関数呼び出しを完了したときに出力する特定のトークンを特定でき、そのトークンの直後に生成を停止させることができます。

これは単にトークンを節約するためだけのことではありません。実際のツールを呼び出し、実際のデータを取得して、それをモデルに戻すというワークフローを保証するために必要なステップなのです。もし、関数の結果をシミュレートしたい場合には、意図的に停止シーケンスを使用せず、モデルに続行させることで、モデルが予測する結果を得ることもできますが、これは通常のツール使用のフローではありません。

停止シーケンスを適切に実装することで、モデルが外部ツールの結果を幻覚することなく、実際のデータに基づいた信頼性の高い応答を提供できるようになります。

3.4 関数呼び出しの解析と実行

Nicholas: さて、今私たちはモデルからの応答をチェックしました。そして実際にはツール使用を含んでいることがわかりました。これで図の「はい」の部分にいるわけです。次に必要なのは、Claudeが行おうとしている関数呼び出しを解析し、ソフトウェアで実行することです。

簡潔にするために解析の部分は省略しますが、実行部分はどのようになるでしょうか。おそらく私たちはget_weatherという名前のPython関数を作成したでしょう。この関数はClaudeに伝えたのと同じパラメータを受け取ります。そして、some_weather_api.current_weatherのようなAPIを呼び出し、Claudeが呼び出した関数への自然言語フレーズの答えを返すかもしれません。

これは必須ではありませんが、関数の結果を自然言語で返すと、モデルが見ている結果をより理解しやすくなることがよくあります。ここでは、単に現在の天気を返すだけでなく、補間された文字列を返しています。「現在の気温はweather.current_tempです。今日は雨の可能性がweather.precipitation_chanceあります」というように。

次に何をするでしょうか？これらの結果を取得し、モデルに示します。しかし重要なのは、モデルが何をしようとしていたかという以前のコンテキストすべてとともに、これをモデルに示す必要があるということです。これらの結果をコンテキストなしで与えるだけでは、モデルはそれをどう扱えばいいのかわからないでしょう。

そのため、実際には前の会話から継続します。関数呼び出し構文と利用可能な関数を含むシステムメッセージはまだ保持しています。「オースティンの天気は？」というユーザーメッセージもあります。そして、拡張されたアシスタントメッセージもあります。

これは注意すべき重要な落とし穴です。考えられる一つのことは、関数結果を新しいユーザーメッセージとして渡すことです。アシスタントが関数を要求し、ユーザーがそれを返すという形です。しかし、私たちが発見したのは、これらを関数が呼び出されたアシスタントメッセージの継続として渡す方がはるかに効果的だということです。

これはClaudeを使った便利なテクニックで、メッセージリストがユーザーメッセージで終わる場合、応答で自動的に新しいアシスタントメッセージを開始します。しかし、メッセージリストがアシスタントメッセージで終わる場合、新しいユーザーメッセージや新しいアシスタントメッセージを開始する代わりに、そのアシスタントメッセージが終わる地点からサンプリングを続けるだけです。

したがって、関数を呼び出して結果を得たのと同じアシスタントのターンから、この会話のサンプリングを続けることになります。

3.5 結果のモデルへのフィードバックと応答生成

Nicholas: では、次に何をするのでしょうか？サンプリングを行い、モデル応答を取得します。今回はモデルが良い回答をするのに必要な情報を持っているかもしれません。そのため、「オースティンの今日の気温は摂氏30度で、雨の確率は5%です。雨に備えたい場合を除いて、どんなコートも必要ありません」のような回答をするかもしれません。

ここで私たちは再び、モデルの応答に関数呼び出しが含まれているかどうかをチェックするポイントに戻ります。先ほどと同じコードスニペットを使用します。今回は関数呼び出しがありませんでした。モデルは実際の回答を提供しました。これをモデルが完了し、ユーザーに結果を返す準備ができているという指標と見なすことができます。

従って、このテキストを取得してユーザーに表示することになるでしょう。以上が「どのように機能するか」の説明です。次はJohnにこの仕組みの使い方についてさらに説明してもらいましょう。

John: 素晴らしい説明をありがとう。ここまでファンクションコーリングの起源と、それを活用するための詳細な方法、ベストプラクティスを見てきました。次に、モデルの事前学習とトレーニングのパワー、言語の知識、そしてビジネスドメインに関する知識を、ファンクションコーリングと組み合わせて本当にクールなことをやってみましょう。

ソフトウェア開発者として、特定の技術を知っていること以上に、ドメイン知識が重要であることは知っています。あなたのビジネスについて知っていることが、より生産的になるのに役立ちます。ほぼすべての経験豊富なソフトウェアエンジニアが同じことを説明するでしょう。ビジネスとのコミュニケーションに役立ち、暗黙の要件も理解できるようになります。

4. ビジネスドメイン知識とツール使用の組み合わせ

4.1 金融業界の例：株価の変動率計算

John: モデルの事前学習とトレーニング、言語の知識、そしてさらにビジネスドメインに関する知識と、ファンクションコーリングを組み合わせて何か面白いことをやってみましょう。ソフトウェア開発者として、ドメイン知識が特定の技術を知っていること以上に重要であることは皆さんご存知のはずです。ビジネスについての知識があると生産性が向上します。ほぼすべての経験豊富なソフトウェアエンジニアがそう言うでしょう。ビジネスとのコミュニケーションを助け、暗黙の要件も理解できるようになります。

金融会社の新人ソフトウェア開発者になったと想像してみてください。初日の簡単な仕事として、与えられた株式シンボルの変動率をパーセンテージで表示するタスクが与えられました。priceツールも提供されており、日付範囲と株式シンボルを入力すると、始値/高値/安値/終値のリストが出力されます。

マネージャーは「さあ、やってみて」と言い、あなたは「はい、できます。簡単そうですね。パーセンテージなら知っていますから」と答えます。しかし、いくつかの暗黙の要件があります。例えば、始値/高値/安値/終値を含む価格シリーズのパーセンテージリターンをどのように計算するのでしょうか？

それはどういう意味でしょうか？始値から終値を使うと、ある数値が得られます。安値から高値だと、別の数値になります。始値から始値（例えば当日の始値から翌日の始値）を使っても別の数値になりますし、終値から終値もまた違う数値になります。どうすればいいのでしょうか？

これは初日なので、皆さんとは違うかもしれませんが、私は新しいことに取り組むとき、質問するのが恥ずかしいこともあります。だから「本当に違いがあるのだろうか？マネージャーもどうせわからないだろうから、適当にどれかを選んでもいいのではないか」と考えるかもしれません。

しかし考えてみると、これは単純なことかもしれませんが、毎日金融ニュースを見ると、パーセンテージリターンが表示されています。「S&Pは本日〇〇%のリターン」というように表示されますが、そのパーセンテージをどのように計算しているかは説明されていません。つまり、みんなが理解していることが前提なのでしょう。

では具体的に見てみましょう。10月14日のS&P500のパーセンテージリターンを計算するとどうなるでしょうか？始値から終値を使うと約0.5%になります。始値から始値を使うと約0.95%とほぼ倍になります。終値から終値を使うと、また少し違って1.5倍ほどになります。これらは大幅に異なります。そして、この日は使用する方法によってリターンが正から負に変わることもあります。

これを見ると「やはり重要かもしれない。マネージャーに気づかれるかもしれない」と思います。良い仕事をしたいので、Claudeに聞いてみることにしました。Amazon BedrockのコンバースAPIを使います。これにはベストプラクティスの多くが組み込まれています。停止トークンを処理し、ツール使用構文を標準化しています。

プレミアモデルを選択して「あなたは金融会社のソフトウェア開発者で、計算機があります」と設定し、priceツールから取得したデータを渡して「各日のパーセンテージリターンは何ですか？」と尋ねます。

Claudeからの回答は次のとおりです：「過去5日間のパーセンテージリターンを計算するには、終値を使用する必要があります。」つまり、始値から終値ではなく、終値を使うというのです。そして、Claudeは正しい2つの日の値を取り出し、ツールを使って計算をしています。マイナスを計算し、それを割り算して、正しい結果を出しています。

でも初日なので、さらに「なぜ？」と知りたくなります。ビジネスドメインの知識が欲しいのです。終値から終値を使う理由がビジネス上の理由なのか、それともClaudeが適当に選んだだけなのか？暗黙の要件はあるのでしょうか？

そこでClaudeに聞いてみました：「なぜ金融商品のパーセンテージ変化を始値から終値ではなく、終値から終値で測定するのですか？」

Claudeはいくつかの理由を挙げていますが、2つに注目してください。一つ目は一貫性です。終値はより信頼性が高いと考えられており、最終的に合意された価値を表しています。これらは通常、取引所によって設定されます。法律用語では「時価評価」と呼ばれます。GAAP会計（一般に認められた会計原則）でも、商品を評価するためにこのタイプの価格が必要です。つまり、これらは法的な価格なのです。通常、その日の終値は取引所によって公表されます。

二つ目はデータの完全性です。一晩の変動性を取り込みたいのです。多くの商品は一晩中や朝の市場前に取引されます。始値から終値を使うと、これを見逃してしまいます。

つまり、Claudeはこの知識を持っていました。ファンクションコーリングのパワーを見てきましたが、これからエージェントとは何かについて考えてみましょう。

4.2 金融ドメインの暗黙の要件：終値から終値への比較の重要性

John: ファンクションコーリングを使って株価のパーセンテージリターンを計算したとき、モデルが選択した方法に注目してください。Claudeは様々な選択肢（始値から終値、高値から安値、始値から始値、終値から終値）がある中で、特に終値から終値のリターンを計算しました。この判断の背景にはどのような金融ドメインの知識があるのでしょうか。

具体的な例を見てみましょう。10月14日のS&P500のパーセンテージリターンを異なる方法で計算すると、結果は大きく異なります：

• 始値から終値を使用：約0.5%のリターン
• 始値から始値を使用：約0.95%のリターン（ほぼ倍）
• 終値から終値を使用：前者の約1.5倍のリターン

これらの違いは単なる誤差ではありません。場合によっては、計算方法によってリターンが正から負に変わることもあります。つまり、同じ日のデータを使っても「株価が上がった」とも「下がった」とも報告できてしまうのです。

このような状況では、業界で標準とされている方法を知ることが極めて重要です。そこでClaudeに金融商品のパーセンテージ変化を終値から終値で測定する理由を尋ねたところ、いくつかの重要な理由が示されました：

1. 一貫性：終値はより信頼性が高いとされています。これは最終的に市場が合意した価値を表し、多くの場合、取引所によって公式に設定されます。法律用語では「mark to market（時価評価）」と呼ばれるこの価格は、GAAP会計（一般に認められた会計原則）でも金融商品の評価に要求されています。つまり、終値は法的にも認められた公式な価格であり、取引所によって公表される数値です。
2. データの完全性：終値から終値を使用することで、一晩の変動性も考慮に入れることができます。多くの金融商品は市場が閉まった後も一晩中や朝の市場開始前に取引されています。始値から終値のみを使用すると、この重要な時間帯の価格変動を見逃してしまいます。

このように、金融ドメインには「当然こうすべき」という暗黙の了解があり、それを知らずに独自の判断で計算方法を選ぶと、業界標準と異なる結果を報告することになりかねません。このケースでは、Claudeが金融ドメインの知識に基づいて適切な計算方法を選択できたことがわかります。ドメイン知識と技術的能力を組み合わせることで、より価値の高いソリューションを提供できるのです。

4.3 Claudeによるビジネスドメイン知識の活用

John: 私たちは今、Claudeが金融ドメインの暗黙知をどのように活用できるかを見てきました。このケースでは、株価のパーセンテージリターンを計算する際、Claudeが終値から終値への計算方法を自動的に選択しました。そして、その理由を尋ねたところ、一貫性とデータの完全性という金融業界の重要な考え方について説明することができました。

Claudeが「なぜ金融商品のパーセンテージ変化を始値から終値ではなく、終値から終値で測定するのですか？」という質問に対して提供した回答は、業界標準の実践に完全に沿ったものでした。Claudeは終値が取引所によって正式に設定され、法的な「時価評価」とみなされること、GAAP会計でも要求されていることを理解していました。また、一晩の変動性を捉える重要性も認識していました。

これらはまさにビジネスドメイン知識であり、単なるプログラミングや数学の知識ではありません。金融業界で何年も働いていないと習得できないような業界固有の知見です。Claudeはこれらの知識をトレーニングプロセスから習得し、適切なコンテキストで活用できることを示しています。

ファンクションコーリングと組み合わせることで、Claudeは単に計算だけでなく、業界標準に従った正しい方法での計算を行うことができます。これにより、新人ソフトウェア開発者でも、経験豊富な金融業界の専門家のように振る舞うことが可能になります。

このアプローチは金融だけでなく、法律、医療、エンジニアリングなど、特定の専門知識が重要な他の多くの業界にも応用できます。モデルが持つドメイン知識を活用することで、専門家レベルの洞察と技術的な実装能力を組み合わせた強力なソリューションを構築することができるのです。

Nicholas: この例は、大規模言語モデルの真の価値を示しています。単に命令に従って計算するだけでなく、その業界のコンテキストを理解し、暗黙の標準や慣行に従って適切な判断を下すことができるのです。次に、このようなツール使用の能力をさらに発展させた「エージェント」について考えていきましょう。

5. AIエージェントの定義と進化

5.1 エージェント定義の多様性と混乱

Nicholas: エージェントに取り組み始めた約1年前、「エージェントとは何か」という質問を自分自身にしました。当時はかなり良い答えを持っていると思っていました。私の答えについては後ほどお話しするかもしれません。そして、エージェントの採用を試みていた最初の顧客たちと話し始めると、すぐに気づいたのは、私の答えが彼らの答えと同じではないだけでなく、彼らの答えもお互いに同じではなかったということです。

この「エージェント」という用語は、誰も本当に合意できないほど多様な意味を持つようになっていました。そして今でもそうです。次のスライドで明確な定義を示せればいいのですが、代わりにこのようなものを示さなければなりません（笑）。インターネット上の「ホットドッグはサンドイッチか？」という論争を解決するために使われるグラフのようなものです。これで「エージェントとは何か」という問題も解決できるでしょう。

私は現在、エージェントをこの2つの軸で考えています。一つは「エージェンシー（自律性）」の軸で、もう一つは「エフェクト（影響力）」の軸です。エージェンシーの軸は選択に関するものです。モデルが何をするか、いつするか、いつ停止して答えを出すか、その出力の何をエンドユーザーやエンドカスタマーに表示するかについて、モデルにどれだけ自分で決定させるかということです。

もう一方の軸であるエフェクトは、モデルが行っていることの影響に関するものです。ここでツール使用が関わってきます。純粋主義者は、モデルが外部世界から読み書きの両方ができる場合のみ、それをエージェントと呼ぶでしょう。一方、過激派は「エフェクトはエージェントにとって重要ではない」と言うかもしれません。

そのため、「モデルからの任意の応答はエージェントである」と言う人もいれば、「AI エージェントになるためには仮想従業員に近いものでなければならない」と言う人もいます。

この図をもう少し詳しく見てみましょう。これは「エフェクト・ラジカル+エージェンシー・ラジカル」のバージョンの図です。ここでは、任意の言語モデルの応答がエージェントとされています。ツール使用をする必要もなく、単一ステップで良く、モデルがしなければならないことについて非常に規範的であっても構いません。これが現在市場に展開されているエージェントの大部分だと思います。

次に「エフェクト純粋主義者+エージェンシー中立」です。これは何らかのレベルでツール使用を行う必要があるというものです。読み取りと書き込みの両方である必要はありませんが、モデルに何らかのエージェンシーを持たせて決定を下させる必要があります。ただし、人間に与えるような完全な自律性を与える必要はありません。

なぜこのフローがエージェンシー中立であり、エージェンシー純粋ではないのでしょうか？それは、これらのピンク色のボックスのそれぞれで、モデルの自律性を実際に制御し制限しているからです。ユーザーメッセージを受け取り、モデルに見せる前に、別の分類器を実行してClaudeにどのようなプロンプトを与えるべきか、どのようなツールを持たせるべきか、プロンプトにどのような種類の指示を含めるべきかを決定します。これにより、すぐにモデルの選択肢の範囲と指示のセットを制限しています。

その後、モデルに多くの非常にエージェント的に感じる作業をさせます。ツール使用を行ったり、いくつかの回答を思いついたりします。しかし、それをカスタマーに表示する前に、人間のオペレーターに何を表示するかをチェックさせるかもしれません。そして、モデルの自律性に対するもう一つの制御ポイントがあり、モデルは完全にはコントロールしていません。

これは、市場で最も先進的なエージェントを構築している人々の多くに見られるものです。そして、面白いことに、左上隅に行くと、真のエージェンティック純粋主義者であれば、基本的にツール使用のチャートに戻ります。モデルが何をするか、いつするか、おそらく最も重要なことは、完了までに何ステップ必要かをモデルが決定するループ内ツールです。これが、エージェント純粋主義者の考えるエージェントの形です。

面白いことに、ツール使用の元々の考え方は、実際にはエージェントを最も厳密に定義する人々にとってのエージェントのコンセプションだったのです。

5.2 エージェンシー（自律性）とエフェクト（影響力）の2軸による分類

Nicholas: エージェントを定義する際の混乱を整理するために、私は2つの軸でエージェントを考えるようになりました。これによって、さまざまな立場や見解を整理することができます。

一つ目の軸は「エージェンシー」、つまり自律性です。これは選択に関するものです。モデルにどれだけ自分自身の決定を許可するかという度合いを表しています。具体的には、何をするか、いつするか、いつ停止して回答を提供するか、そして最終的にエンドユーザーやカスタマーに何を表示するかといった決定についてです。高いエージェンシーを持つモデルは、より多くの意思決定を自分自身で行い、低いエージェンシーのモデルは厳格に定義されたプロトコルに従います。

二つ目の軸は「エフェクト」、つまり影響力です。これはモデルが行っていることの実際の影響に関するものです。ここでツール使用が重要な役割を果たします。エフェクトの高いモデルは外部世界から読み取りと書き込みの両方ができます。例えば、データベースを更新したり、APIを呼び出したり、電子メールを送信したりするような実質的なアクションを実行できます。

これら2つの軸を組み合わせることで、エージェントについての様々な見解を理解することができます：

• エフェクト純粋主義者は、モデルが外部世界から読み書きの両方ができる場合のみ、それをエージェントと見なします。
• エージェンシー純粋主義者は、モデルが自律的に決定を下し、いつ完了するかを自分で判断できる場合のみ、それをエージェントと見なします。
• エフェクト・ラジカルは、モデルが外部世界に影響を与える能力を持っていなくても、それをエージェントと見なす可能性があります。
• エージェンシー・ラジカルは、モデルが厳密に制御された環境で動作していても、それをエージェントと見なす可能性があります。

このフレームワークを使用することで、「モデルからの任意のテキスト生成はエージェントである」と主張する人から、「エージェントになるためには仮想従業員のような高度な自律性と影響力を持つ必要がある」と考える人まで、さまざまな見解を整理することができます。

この分類法の重要な点は、特定の定義が「正しい」かどうかを主張することではなく、むしろ異なる立場を明確にし、エージェントについて議論する際の共通言語を提供することです。これにより、開発者やユーザーは自分たちのニーズに最も適したエージェントのタイプをより明確に識別できるようになります。

5.3 さまざまなエージェント定義のモデル

Nicholas: エージェンシーとエフェクトの2軸を使って、実際にさまざまなエージェント定義のモデルを見ていきましょう。これにより、市場に存在するさまざまなタイプのエージェントと、それらがどのように分類されるかを理解できます。

まず、図の右下にあるのは「エフェクト・ラジカル+エージェンシー・ラジカル」の立場です。この定義では、言語モデルからの任意の応答がエージェントとみなされます。ツール使用を行う必要もなく、単一ステップでも構いません。また、モデルが行うべきことについて非常に規範的な指示を与えても良いとされています。これは現在市場に展開されているものの大部分で、多くの人がエージェントと呼んでいるものです。単一の質問に対する単一の応答であっても、それをエージェントとして位置づけるのがこの立場です。

次に「エフェクト純粋主義+エージェンシー中立」の立場を見てみましょう。この定義では、モデルが何らかのツール使用を行う必要があります。読み取りと書き込みの両方が必要とされ、モデルにはある程度の自律性を持たせて決定を下すことが求められますが、人間に与えるような完全な自律性は必要ありません。

この流れがエージェンシー中立と呼ばれ、エージェンシー純粋ではない理由は、図に示されたピンク色のボックスのそれぞれでモデルの自律性を実際に制御・制限しているからです。例えば、ユーザーメッセージを受け取った後、モデルにそれを見せる前に、別の分類器を実行してClaudeにどのようなプロンプト、ツール、指示を与えるべきかを決定します。これにより、最初からモデルの選択肢と指示セットを制限しています。

その後、モデルにツール使用やいくつかの回答の生成など、エージェンティックに感じる作業を行わせますが、それをカスタマーに表示する前に人間のオペレーターによるチェックを入れることもあります。これはモデルの自律性に対するもう一つの制御ポイントであり、モデルは完全には自律していません。このアプローチは、市場で最も先進的なエージェントを構築している多くの組織に見られるものです。

興味深いことに、図の左上隅にある「エージェンシー純粋主義+エフェクト純粋主義」の立場では、基本的に元のツール使用のチャートと同じになります。これは、モデルが何をするか、いつするか、そして最も重要なことに、完了までに何ステップ必要かをモデルが自分で決定するループ内ツールです。エージェントを最も厳密に定義する人々にとっては、ツール使用の元々の概念こそがエージェントの本質なのです。

これらの異なるモデルは、「エージェント」という言葉がなぜこれほど多様に解釈されるのかを理解する助けになります。また、自分たちのニーズに合ったエージェントタイプを選択する際の指針にもなります。エージェンシーとエフェクトのバランスをどのように設定するかによって、構築されるシステムの性質や機能が大きく変わってくるのです。

5.4 LLMの能力進化：ツール数の増加とタイムホライズンの拡大

Nicholas: ではなぜ、ツール使用からエージェントへのこの変化に関心を持つべきなのでしょうか？私が観察している点、そして正直なところ私自身も常に驚かされているのは、指数関数的な成長の初期段階にいる人間は、その成長を認識するのが苦手だということです。モデルは急速に扱えるツールの数と、取り組める複雑さやタイムホライズンのタスクを拡大しています。

以前、つい1年も経っていない段階では、Claudeは限られたツールセット（最大でも1〜6個程度）と、狭く短いタイムホライズンのタスクを与えられた場合にのみ、信頼性を持ってアクションを実行できました。広告の分野で例えるなら、「Claudeよ、私の広告キャンペーンのCTR（クリック率）はいくらですか？」といった質問です。これには基本的に、Claudeが関連データを検索するためにおそらく1度のツール呼び出しを行い、その後計算を実行するだけで済みます。

今日では、すでにClaudeが多数のツール（数十のツール）を与えられ、複雑ではあるが短いタイムホライズンのタスクで信頼性を持ってアクションを実行できることを確認しています。中には数百のツールを扱う例も見たことがあります。「Claudeよ、私たちの広告予算の現状について完全なレポートを作成できますか？」というようなタスクです。

しかし将来的には、これらの能力がさらに拡大し続けるにつれて、Claudeが多数のツールと複雑なタスクだけでなく、中長期のタイムホライズンを持つタスクでも信頼性を持ってアクションを実行できるようになると予想しています。完了までに数十または数百のステップが必要で、作業単位がより原子的でなくなるようなタスクです。「Claudeよ、昨年分のデータを分析し、そのデータに基づいて新しい広告キャンペーン戦略を提案し、それを開始できますか？」というようなタスクです。これは現在の従来の運用では多くの人が多くのステップを実行している作業です。

しかし、このような進歩が起きていることについて、私のスライド上の仮説だけを信じるのではなく、実際のデータを見てみましょう。

6. エージェントの進化と能力向上のデータ

6.1 コーディングエージェントのベンチマーク結果

Nicholas: 今日、世界で最も注目されている二大エージェンティックユースケースの一つはコーディングです。エージェンティックコーディングは、数年前のコード補完（コードの行を書いていて、モデルがその行の最後の2つのトークンを補完するような）とは少し異なります。エージェンティックコーディングでは、モデルにタスクとコードベースを与え、プルリクエストを提出するようなことを依頼します。

私たちはエージェンティックコーディングのための内部ベンチマークを持っています。外部にも素晴らしいベンチマークがたくさんありますが、私たちの内部ベンチマークでは、Claudeにオープンソースのコードベースと、機能追加やバグ修正のための自然言語リクエストが与えられます。これらは実際にこれらのオープンソースコードベースに対して実際のGitHubチケットとして開かれたリクエストです。

Claudeの仕事は、人間の介入なしにコードベースの変更を実装することです。私たちは、それらの変更が少なくとも3つのファイルの検索、表示、編集を必要とし、場合によっては最大20ファイルに及ぶような問題を選んでいます。

重要なのは、Claudeが単にコードを書いて終わりではないということです。サンドボックス内でコードを実行して、変更をテストし、タスクを達成しているかどうかを理解することができます。そのため、何か間違いがあったり、何かが機能するかどうか不確かだったりする場合、開発者が他の人にレビューのためにプルリクエストを開く前にするように、自分自身でそれを試して解決することができます。

その後、Claudeはコードベースのテストがこの変更に対して実際にパスするかどうかで評価されます。

私たちが1年も経っていない時期にClaude 3をリリースした際、Claude 3 Haiku、Sonnet、Opusをリリースしました。これはモデルのサイズと知性の順に増加しています。当時、Claude 3 Sonnetはこのタスクで約21%のスコアでした。Claude 3 Sonnetよりもはるかに大きく、より能力の高いClaude 3 Opusは約38%のスコアでした。

6ヶ月も経たないうちに、このファミリーの最初のモデルアップグレードをリリースしました。これはSonnetのアップグレードでした。Claude 3.5 Sonnetはこのタスクのスコアが21%から64%に向上しました。これは前の世代の約3倍良く、わずか6ヶ月前のはるかに大きなモデルより2倍近く良いスコアでした。

つまり、この進歩は観察や直感だけではなく、実際に私たちが重視するベンチマークで、そしてモデルの実際の応用を代表すると感じるベンチマークで確認されているのです。

これを踏まえて、Johnに戻して、Bedrockとエージェント、ファンクションコーリングについてもう少し詳しく話してもらいましょう。

6.2 Claude 3 SonnetからClaude 3.5 Sonnetへの劇的な性能向上（21%→64%）

Nicholas: コーディングエージェントのベンチマークでは、モデルの性能向上の速度を具体的に測定することができます。私たちが見てきた結果は驚くべきものです。Claude 3のリリース時、Claude 3 Sonnetはコーディングエージェントのベンチマークで約21%のスコアでした。一方、より大きく強力なClaude 3 Opusは約38%のスコアを記録していました。

そして、わずか6ヶ月も経たないうちに、Claude 3.5 Sonnetをリリースしました。このモデルは同じベンチマークで64%のスコアを達成しました。これは前世代（Claude 3 Sonnet）の約3倍の性能向上です。さらに驚くべきことに、わずか半年前にリリースされた、はるかに大きなモデルであるClaude 3 Opusの38%という成績よりも、大幅に上回っています。

この急速な進歩が示していることは、モデルが複雑なタスクを遂行する能力が指数関数的に向上しているということです。特に、複数のファイルを検索・編集し、自分でコードをテスト実行し、エラーを修正するような、人間の開発者に近い作業を行う能力が飛躍的に向上しています。

これは単に「より良くなった」というだけの話ではありません。同じサイズクラスのモデルで、わずか6ヶ月で3倍の性能向上を達成したことは、AIの進化の速度が加速していることを示しています。この種の急速な進歩は、「エージェント」という概念が理論的なものから実用的なものへと移行していることを示す証拠です。

以前は「ここまでしかできない」と思われていた制限が、新しい世代のモデルでは打ち破られています。この速度で進化が続けば、複数のツールを使用し、長期的なタイムホライズンを持つ複雑なタスクを遂行できるエージェントがすぐに現実のものになるでしょう。

John: これらの素晴らしい結果を踏まえて、今度はBedrockエージェントがどのようにこれらの能力を活用し、洗練されたエージェントアーキテクチャを提供しているかについて見ていきましょう。

7. Amazon Bedrock Agentsの詳細

7.1 Bedrock Agentsのアーキテクチャと機能

John: Nicholas氏から共有された進化と能力向上の話を踏まえて、Bedrock Agentsがこれまで説明してきたことをどのように活用できるかを見ていきましょう。

このスライドではBedrockエージェントの内部アーキテクチャを示しています。極秘情報ですよ（笑）。エージェントは、さまざまな方法でツールを利用することができます。皆さんがLambdaで提供するツールや、「制御の返却」と呼ばれるもの（ローカルでホストしたものを使用し、ツールを呼び出すタイミングを伝える）をサポートしています。関数のシグネチャ、説明、パラメータを提供します。

また、ナレッジベースも使用できます。ナレッジベースを設定すると、私たちが自動的にプロンプトエンジニアリングを行い、それをツールとして設定します。そして、リクエストを受け取ると、Converse APIを使用して、適切なツールブロックとともにそのリクエストをモデルに送信し、プロンプトエンジニアリングを代行します。

ツール使用のレスポンスが返ってきたら、ツールを実行するか、制御の返却を使用している場合は実行するように指示します。では、これは内部的にどのように機能するのでしょうか？

BedrockエージェントはデフォルトでReActという戦略を使用しています。ReActは「Reason and Action（推論と行動）」の略です。これはNicholas氏が示したものとほぼ同じで、ユーザーリクエストを受け取り、オーケストレーター（内部コードを指します）がそれを処理します。ユーザーのリクエストを受け取り、提供されたツールを含むConverse APIリクエストを構築し、選択したモデルに送信します。

その後、どのアクションを実行すべきかが示され、そのアクションを実行し、元のリクエスト、ツール、および結果を組み合わせます。最終的な回答が得られるまでこれを繰り返し、その回答をInvoke Agent APIとして返信します。

ReActはオーケストレータースタイルとプロンプトスタイルとしていくつかの利点があります。通常、ReActを見るとき、オーケストレーターまたはプロンプトスタイルという用語が使われます。その利点の一つは、各アクションでモデルが次のステップについて決定を下すことです。計画を立て、それを出力し、そのアクションに基づいて次のアクションを決定します。途中で計画を修正することもあります。そのため、他のプロンプトスタイルと比較して、非常に正確で回復力があります。

また、ツール使用と自然に連携します。ほとんどのモデルベンダーはReActスタイルのプロンプト、そして思考連鎖（chain-of-thought）スタイルのプロンプトもトレーニングしています。

しかし、このアプローチには欠点もあります。まず一つはレイテンシーです。ツール呼び出しが2回あれば、モデル呼び出しは3回になります。多くの場合、これらのモデル呼び出しは6〜10秒かかることがあります。そのため、2、3、4回のツール呼び出しがあると、簡単に1分近くのレイテンシーになります。

また、より長い軌道や計画では、時間の経過とともに計画を忘れてしまう可能性があります。これがNicholas氏が話していた複雑なタイムホライズンの問題です。さらに、ReActループでは事前定義された計画に従うことが難しいです。「これら5つのステップを実行してほしい」と入力しても、必ずしもそのとおりに実行されないことがあります。「なぜ？私は5つのステップを実行するように言ったのに」と思うかもしれませんが、ReActはモデルに計画を確立させるためのものだからです。

7.2 オーケストレーション戦略：ReAct（Reason and Action）

John: Bedrock Agentsが採用するデフォルトのオーケストレーション戦略はReActです。ReActは「Reason and Action（推論と行動）」の略で、これはまさにNicholas氏が先ほど示したツール使用の流れに非常に近いものです。ReActの仕組みを詳しく説明しましょう。

まず、ユーザーからリクエストを受け取ります。Bedrockエージェント内のオーケストレーター（私たちの内部コード）がそのリクエストを取得し、ユーザーが提供したツールを含むConverse APIリクエストを構築します。そして、選択したモデルにそれを送信します。

モデルはリクエストを処理し、どのアクションを実行すべきかを決定します。このとき、モデルは思考プロセスを示し、計画を立て、その計画に基づいて次に実行すべきアクションを特定します。オーケストレーターはそのアクションを実行し、元のリクエスト、ツール、そしてアクションの結果を組み合わせてモデルに返します。

モデルはこの新しい情報を受け取り、計画に基づいて次のアクションを決定するか、あるいは十分な情報が得られたと判断して最終的な回答を生成します。最終回答が得られるまで、このプロセスが繰り返されます。最終回答が生成されたら、それをInvoke Agent APIの応答として返します。

ReActアプローチの大きな特徴は、各ステップでモデルが自らの推論を表示し、次のアクションを決定することです。モデルは明示的に計画を立て、その計画を出力し、各アクションの結果に基づいて次のステップを決定します。必要に応じて途中で計画を修正することもできます。

この方法は、複雑な問題に対して高い正確性と回復力を提供します。モデルが各ステップで推論し、結果を評価し、次のアクションを調整できるため、単一の計画を前もって立てて盲目的に実行するよりも柔軟です。また、ほとんどのモデルプロバイダーがReActスタイルやChain-of-Thoughtスタイルのプロンプトでモデルをトレーニングしているため、このアプローチはツール使用と自然に連携します。

ReActが特に優れているのは、予期しない結果や新しい情報に適応できる点です。各アクションの後でモデルが再評価するため、初期の仮定が間違っていた場合でも、途中で軌道修正することができます。これにより、複雑な問題解決においても高い成功率を達成できます。

7.3 ReActの利点と欠点：精度と柔軟性 vs レイテンシーと長期記憶

John: ReActアプローチには多くの利点がありますが、同時に考慮すべき欠点もあります。これらのトレードオフを理解することで、特定のユースケースに最適なオーケストレーション戦略を選択できるようになります。

まず、ReActの主な利点について説明しましょう。最も重要な利点は、各アクションのステップでモデルが次に何をすべきかを決定できることです。モデルは計画を立て、その計画を明示的に出力し、各アクションの結果に基づいて次のアクションを決定します。場合によっては途中で計画を修正することもあります。

このアプローチにより、他のプロンプトスタイルと比較して高い精度と回復力が実現します。各ステップで結果を評価し、必要に応じて軌道修正できるため、予期しない状況にも適応できます。また、ほとんどのモデルプロバイダーがReActスタイルのプロンプトやChain-of-Thoughtスタイルのプロンプトでモデルをトレーニングしているため、ツール使用との相性も良好です。

しかし、ReActには重要な欠点もあります。最も顕著な問題はレイテンシーです。例えば、2回のツール呼び出しがある場合、合計で3回のモデル呼び出しが必要になります。一般的にモデル呼び出しは1回あたり6〜10秒かかることがあるため、2〜4回のツール呼び出しがあると、合計のレイテンシーは簡単に1分近くなってしまいます。対話型のアプリケーションでは、これは深刻な制約になる可能性があります。

また、長い軌道や計画では、モデルが時間の経過とともに元の計画を忘れてしまう可能性があります。これはNicholas氏が言及していた複雑なタイムホライズンの問題に関連しています。多数のステップがある長期的なタスクでは、モデルは元々の目標や計画の詳細を見失うことがあります。

さらに、ReActループでは事前定義された計画に厳密に従うことが難しいという問題もあります。例えば、「これら5つの特定のステップを順番に実行してください」と指示しても、モデルが必ずしもその通りに実行するとは限りません。ユーザーが「なぜ指示通りに5つのステップを実行しないのか」と疑問に思うかもしれませんが、それはReActの設計上の特性です。ReActはモデルが自ら計画を立て、各ステップで次のアクションを決定することを前提としているため、細かく事前定義された手順に正確に従うには適していません。

これらの欠点は、特定のユースケースによっては別のオーケストレーション戦略を検討する理由になります。特に、レイテンシーが重要な場合や、厳密に定義された手順に従う必要がある場合は、ReActとは異なるアプローチが必要かもしれません。

7.4 代替オーケストレーション：ReWoO（Reason Without Observation）

John: ReActの限界を克服するための代替オーケストレーション戦略として、ReWoO（Reason Without Observation、観察なしの推論）があります。これはどのように機能するのでしょうか？

ReWoOの仕組みは、リクエストとツールを送信するという点ではReActと似ていますが、プロンプトがより詳細になります。モデルに対して「次のステップだけでなく、すべてのステップを一度に出力してほしい」と伝えます。これにより、モデルはアクションの完全な計画を提供し、その後あなたがそのアクションのシーケンスを実行します。その後、オプションとして結果を戻すことも可能で、その場合モデルは自然言語での応答を提供します。

ReWoOの最大の利点はレイテンシーです。例えば、4つのツールを呼び出す必要がある場合、たった1回のモデル呼び出しでそれを実現できます。モデルに一度にどのツールを使用すべきかを伝えさせることができます。また、計画に従うことも非常に得意です。

しかし、トレードオフもあります。実際には、モデルの応答からツール実行を解析するためのコードを多く書く必要があります。ツールの出力が別のツールの入力に依存する場合、ReActではモデルがその依存関係を処理しますが、ReWoOではあなた自身がそれを処理する必要があります。

つまり、もう少しコードが必要で、少し脆弱になります。ReActでは、コードが少なく、プロンプトもそれほど詳細ではないため、時間の経過とともにモデルが向上すれば自動的にその恩恵を受けることができます。一方、ReWoOのようなものはモデルの新しいアップグレードに対して少し脆弱で、プロンプトエンジニアリングを再度行う必要があるかもしれません。

BedrockエージェントのデフォルトオーケストレーターはReActですが、ReWoOも使用できますし、実際には任意のオーケストレーションタイプを使用できます。これは先週の金曜日に発表されたばかりです。「Amazon Bedrock Custom Orchestratorの使用開始」というブログ記事があります。今日使用できるReWoOの例があり、デフォルトのReActと比較して、どちらが良いか確認できます。

カスタマイズ可能で、コードをLambdaに入れるだけです。私たちのコードを取り、Lambdaに入れて、エージェントと一緒に実行できます。プロンプトを再定義したい場合は、それも可能です。ブログ記事を読むことをお勧めします。そこではReActやReWoOのような計画・解決タイプのプロンプトについて詳しく掘り下げています。

つまり、現在は任意のオーケストレーションスタイルを使用できるようになっています。では、これからエージェントを使った、ファンクションコーリングよりも複雑な例を見ていきましょう。

7.5 カスタムオーケストレーターの活用方法

John: Bedrock Agentsでは、デフォルトのReActオーケストレーターに加えて、カスタムオーケストレーターを使用できるようになりました。これは先週の金曜日に発表されたばかりの新機能です。この機能を活用することで、特定のユースケースに最適化されたオーケストレーション戦略を実装できます。

カスタムオーケストレーターを使用するプロセスは比較的シンプルです。私たちが提供するブログ記事「Amazon Bedrock Custom Orchestratorの使用開始」には、ReWoOの実装例が含まれています。このコードを取得して、自分のLambda関数に配置し、エージェントと一緒に実行するだけです。

例えば、ReWoOオーケストレーターを実装する場合、このLambda関数はモデルに対して「すべてのステップを一度に計画してください」と指示するプロンプトを構築します。モデルから返された計画を解析し、必要なすべてのツール呼び出しを順番に実行し、最終的な結果を生成します。

カスタムオーケストレーターの大きな利点は、プロンプトを完全にコントロールできることです。独自のプロンプト設計やオーケストレーション戦略が必要な場合は、Lambda関数内でそれらを自由に実装できます。例えば、特定のドメインに特化したプロンプトや、特定のツールセットに最適化された指示を含めることができます。

このアプローチは、レイテンシー要件が厳しい場合や、厳密に定義された手順に従う必要がある場合に特に有効です。例えば、金融取引や医療診断など、特定の順序で複数のステップを確実に実行する必要があるアプリケーションでは、カスタムオーケストレーターが理想的な選択となるでしょう。

ブログ記事では、ReActとReWoOの両方の詳細な実装例と比較、そしてそれぞれの利点と欠点について詳しく説明しています。これを読むことで、自分のユースケースに最適なオーケストレーション戦略を選択するための良い基盤が得られるでしょう。

カスタムオーケストレーターを使用することで、Bedrock Agentsの機能を拡張し、特定のニーズに合わせてエージェントの動作をカスタマイズすることができます。これにより、より効率的で効果的なAIエージェントソリューションを構築する可能性が大きく広がります。

8. 複雑な問題解決の例

8.1 金融データを用いた年間ボラティリティの計算

John: ファンクションコーリングよりも複雑な例をエージェントで見ていきましょう。再び、モデルのビジネスドメイン知識をエージェントと組み合わせて活用したいと思います。

引き続き、金融会社の新人ソフトウェア開発者という設定です。まだ初日ですが、問題を解決すると何が起こるか、すでに述べましたよね？新しい問題が発生します。パーセンテージ変化の計算ができたことをマネージャーに見せたところ、「あなたは新入社員なのにこんなに知識があるんですね、もっと難しいことをお願いしましょう」と言われました。

今度は、より複雑なタスクが与えられました。「過去30日間のデータに基づいてS&P500の年間ボラティリティを計算してください」。これは複雑そうに聞こえますね。しかし、初日なので、マネージャーに感銘を与えたいと思います。もしかしたら2日目に昇給があるかもしれませんしね。

いくつかの疑問があります。第一に、ボラティリティとは何か？第二に、計算するための業界標準の方法は何か？第三に、どのようなデータが必要か？そこで、単純にClaudeに聞いてみましょう。「金融市場におけるボラティリティとは何ですか？」

Claudeはいくつかの重要なポイントを出力しました。まず、金融市場でのボラティリティとは、価格が時間の経過とともに変動する度合いを指します。つまり、15%のボラティリティがあれば、15%の上下変動、あるいは8%上昇して7%下落するなど、そのような変動を予想できます。もちろん、これは金融アドバイスではありませんが、基本的にそれがボラティリティの意味です。

ボラティリティの測定方法は標準偏差です。高い標準偏差はより高いボラティリティを意味します。標準偏差の正式な定義は、平均からの平均距離と思います。

3つ目の重要なポイントは、ヒストリカルボラティリティです。「過去30日間に基づく」と言われたので、将来を予測する暗示的ボラティリティではなく、ヒストリカルボラティリティを計算することになります。

これで要件が分かりました。30日分のデータが必要で、パーセンテージ変化を計算し、そのシリーズの標準偏差を取ります。これで過去30日間の日次標準偏差が得られます。しかし、質問は年間ボラティリティについてでした。日次ボラティリティしか得られないのに、1年間で予想されるボラティリティに変換するにはどうすればいいでしょうか？

ここでエージェントを構築してみましょう。今回は単純な計算ツールではなく、Bedrock Agentでコードインタープリターのチェックボックスを選びます。コードインタープリターはPythonのリプルのサンドボックス実行で、Claudeがコードを生成するとそれを実行して出力を提供します。私たちはプロンプトエンジニアリングを代行し、環境をサンドボックス化してセッションを管理します。

また、実際の市場データツールも提供して、クエリできるようにします。簡単なUIでデモを構築しました。これから質問を入力し、トレースイベントが流れていくのを見ていきましょう。トレースイベントとエージェントは中間イベントで、どのツールを使用しているか、モデルをいつ呼び出しているか、モデルからの応答をいつ受け取っているか、そしてコードの生成など、すべてを示します。

8.2 コードインタープリターとデータツールの活用

John: Bedrock Agentを活用してこの複雑な問題を解決する方法を具体的に見ていきましょう。私はデモ用に2つのツールにアクセスできるエージェントを作成しました。一つはコードインタープリターで、もう一つは価格ツールです。

コードインタープリターは、Claudeが生成したPythonコードをサンドボックス環境で実行できる強力なツールです。エージェントを作成する際に、Bedrock Agentの設定画面でコードインタープリターのチェックボックスを選択するだけで有効になります。私たちがプロンプトエンジニアリングを行い、環境をサンドボックス化し、セッションを管理するので、ユーザーは特別な設定をする必要はありません。

価格ツールは、銘柄と日付範囲を指定すると株価データを取得できるツールです。このツールを使えば、S&P500の過去30日間のデータを簡単に取得することができます。

これから、実際にこのエージェントを使って年間ボラティリティを計算する過程を見ていきます。デモのUIでは、質問を入力するとトレースイベントが表示されます。トレースイベントとは、エージェントが実行する中間ステップのことで、どのツールを使用しているか、モデルをいつ呼び出しているか、モデルからの応答はいつ受け取ったか、そしてどのようなコードが生成されたかなど、すべての情報が含まれています。

このデモでは、「過去30日間のデータに基づいてS&P500の年間ボラティリティを計算してください」という質問を投げかけます。エージェントはまず問題を理解し、必要なデータを取得するために価格ツールを呼び出します。次に、そのデータを使って計算を行うためのPythonコードを生成し、コードインタープリターでそれを実行します。

最終的に、エージェントは計算プロセスの各ステップを説明しながら、S&P500の年間ボラティリティを13.07%として提示します。このプロセス全体がトレースイベントとして表示されるので、エージェントがどのように結論に達したのかを透明に確認することができます。

コードインタープリターとデータツールを組み合わせることで、エージェントは複雑な金融計算を実行できるだけでなく、その計算過程も可視化できます。これにより、ユーザーは結果だけでなく、エージェントの思考プロセスも理解することができます。

8.3 ドメイン知識とツール使用の組み合わせ実演

John: それでは、実際にエージェントが問題をどのように解決したのか、トレースイベントを追って見ていきましょう。最終的な解答として「SPYの過去30日間の年間ボラティリティは13.07%です」という結果が得られました。この結果に至るまでのプロセスがトレースイベントに記録されています。

まず、データツールの呼び出しを見つけてみましょう。ここで価格ツールが呼び出されていることがわかります。パラメータとしてSPYというシンボル（S&P500のETF）、from_dateが10/15/2024、to_dateが11/14/2024（現在の日付）が使用されています。これにより、過去30日間の価格データが取得されました。

次に、このデータをどのように活用したかを見ていきます。データが取得されると、モデルはそれをコードに組み込みました。30日間だけのデータなので、単純に定数として含めることを選んでいます。そして、対数リターンを計算するコードを生成しています。

重要なのは、ここでもモデルが金融ドメイン知識を活用していることです。先ほどのファンクションコーリングの例で議論したように、パーセンテージ変化を決定するには終値から終値への計算を行います。モデルはこの知識を自動的に適用し、適切な計算を行っています。

モデルは対数リターンを計算し、その標準偏差を求めています。これにより日次ボラティリティが得られます。しかし、元の質問は年間ボラティリティを求めるものでした。ここでモデルは、ボラティリティを年間の数値にスケールするには時間の平方根によってスケーリングする必要があることを知っていました。252は1年間のビジネス日数の概算値です。モデルは252の平方根を取り、標準偏差をそれに乗じることで年間ボラティリティにスケールしています。

これにより、SPYの過去30日間に基づく年間ボラティリティとして約13%という最終答えが得られました。モデルはツールの使用とトレーニングプロセスから学んだビジネスドメイン知識を組み合わせて、この問題を解決したのです。

特に注目すべきは、モデルが1年間のビジネス日数（252日）の平方根を使うことを知っていたことです。これは金融の専門知識に属する情報です。さらに興味深いのは、あなたのビジネスドメインにおいて、プロンプトエンジニアリングやコンソールとの対話を通じて、Claudeがあなたのビジネス、ビジネスプロセス、または業界標準的なプラクティスについてどのような知識を持っているかを探ることができるという点です。

このデモが示しているのは、エージェントが複雑な問題を解決するために、ツールの使用（価格データの取得とコード実行）とドメイン知識（終値から終値への計算、年間スケーリングのための平方根法則など）を組み合わせる能力です。これにより、専門知識を持たないユーザーでも、複雑な金融計算を行い、正確な結果を得ることができるのです。

9. ベストプラクティスと考慮点

9.1 オーケストレーション選択の判断基準

John: これまでの内容を踏まえて、どのような意味を持つのか考えてみましょう。エージェントのオーケストレーションのプロンプトスタイルは、計画・実行・解決のようなReWoOのように特定の問題に合わせたものも、ReActのようにより汎用的なものもあります。どのような場合に特定のスタイルを選び、どのような場合に汎用的なものを選ぶべきでしょうか？エージェント純粋主義者やファンクション純粋主義者、あるいはファンクションラジカルになるのはいつが適切でしょうか？

特定の計画に従う必要がある場合や、厳しいレイテンシー要件がある場合は、ReWoOのような計画・実行・解決アプローチが良い選択肢かもしれません。一方、非同期処理を行う場合や、使用するツールで発生する可能性のある事象に対して回復力を持たせたい場合は、ReActがより適切な選択かもしれません。

計画を変更する自由度を制限したい場合は、ReWoOや計画・解決型のアプローチが良いでしょう。これらはオーケストレーション選択において考慮すべきトレードオフの一部です。

また、私が使用していたツールが非常に汎用的なものだったことにも気付いたかもしれません。計算機やコードインタープリターなどです。これをS3やデータベースなどにも拡張できるでしょう。

ツールを非常に汎用的にすべきでしょうか？例えば、S3バケットへのアクセスを単純に提供したり、テキストからSQLへの変換でデータベースへのアクセスを提供したり、コードインタープリターを提供したりするべきでしょうか？それとも非常に特定のツールにすべきでしょうか？パーセンテージ変化ツール、ボラティリティツール、データAPIツールなどを作成することもできます。

どのような場合に一方を選び、どのような場合に他方を選ぶべきでしょうか？非常に汎用的なツールを使用すると、モデルにより多くの自由度を与え、より多くのユースケースを処理できますが、少し精度が落ちる傾向があるかもしれません。非常に特定のツールを与えると、エージェントが処理できるユースケースを制限することになりますが、少し精度が向上する可能性があります。これらはテストする必要のあるトレードオフの一部です。

結論として、ファンクションコーリングはClaudeのような高度なモデルによってサポートされる強力な構成要素であり、ツールとビジネスドメイン知識を活用して複雑な問題を標準化された構文で解決できます。エージェントはファンクションコーリングの上に構築され、計画とオーケストレーションを提供し、より複雑な問題を解決し、Amazon Bedrockの生成AIモデルを使用した作業の自動化を実現します。

9.2 汎用ツールvs特定ツールの選択トレードオフ

John: エージェントを設計する際に直面する重要な意思決定の一つが、どのようなタイプのツールをエージェントに提供するかという点です。私たちのデモではコードインタープリターやシンプルな計算機といった汎用ツールを使用しましたが、この選択には重要なトレードオフがあります。

汎用ツールと特定ツールの違いを詳しく見てみましょう。汎用ツールには、S3へのアクセス、データベースへのテキストからSQLへの変換によるアクセス、コードインタープリターなどがあります。一方、特定ツールとは、パーセンテージ変化計算ツール、ボラティリティ計算ツール、特定のデータAPI用に設計されたツールなど、特定の機能に最適化されたものです。

汎用ツールを使用する利点は、モデルにより多くの自由度を与え、より広範なユースケースを処理できるようになることです。例えば、コードインタープリターを提供すれば、モデルはさまざまな計算、データ変換、分析、可視化などを実行できます。同様に、S3へのアクセスを提供すれば、モデルはさまざまなタイプのファイルやデータを処理できるようになります。

しかし、この柔軟性には代償があります。汎用ツールを使用する場合、モデルは問題を解決するための具体的なアプローチを自分で決定する必要があり、特定の問題に対して最適でない方法を選択する可能性があります。例えば、ボラティリティを計算する方法にはいくつかのバリエーションがあり、汎用ツールを使用する場合、モデルは最適でない方法を選択してしまうかもしれません。これは精度の低下につながる可能性があります。

一方、特定ツールは特定のタスクに最適化されており、より高い精度と一貫性を提供できます。例えば、ボラティリティ計算用の専用ツールを作成すれば、その計算が常に正確で一貫したものになることを保証できます。特定ツールはまた、業界標準や会社固有の方法論に従うことを保証するのにも役立ちます。

しかし、特定ツールの主な欠点は、エージェントが処理できるユースケースの範囲を制限することです。各タスクに特定のツールが必要な場合、エージェントが処理できるタスクは提供されているツールに限定されます。これは特に、ユーザーのリクエストが事前に定義されていないタスクを含む場合に問題となります。

最適なアプローチを選択するには、以下の要素を考慮する必要があります：

1. ユースケースの多様性：エージェントが処理する必要があるタスクの範囲が広い場合は、汎用ツールがより適しているかもしれません。
2. 精度の要件：高い精度と一貫性が極めて重要な場合（例：金融計算や医療診断）は、特定ツールがより適切かもしれません。
3. 実装の複雑さ：汎用ツールは少数で済みますが、それぞれが複雑なインプリメンテーションを必要とするかもしれません。一方、特定ツールはより単純ですが、多数必要になる可能性があります。
4. メンテナンスの考慮：特定ツールは各ツールが特定のタスクに限定されているため、更新やメンテナンスがより簡単かもしれませんが、多数のツールを管理する必要があります。

多くの場合、最適な解決策は汎用ツールと特定ツールを組み合わせることです。頻繁に実行され、高い精度が要求される重要なタスクには特定ツールを提供し、より多様で予測不可能なタスクには汎用ツールを提供するアプローチです。

最終的には、エージェントの目的、ユーザーのニーズ、精度の要件に基づいて、このトレードオフを慎重に検討する必要があります。どちらのアプローチも完璧ではなく、特定のユースケースに最適なバランスを見つけることが重要です。

9.3 結論と次のステップ

John: 今日のセッションで多くの内容をカバーしてきました。ここで改めて重要なポイントをまとめておきましょう。

ファンクションコーリングは、Claudeのような先進的なモデルがサポートする強力な構成要素です。これにより、モデルはツールとビジネスドメイン知識を組み合わせて、標準化された構文を使用して複雑な問題を解決できるようになります。我々が見てきたように、モデルは単なる計算能力だけでなく、金融業界の暗黙知のような専門知識も活用できます。

エージェントはファンクションコーリングの上に構築されており、計画立案とオーケストレーションの機能を追加します。これにより、より複雑な問題を解決し、Amazon Bedrockの生成AIモデルを使用した業務の自動化を実現できます。Nicolas氏が示したように、短期間でモデルの能力が劇的に向上しているため、エージェントの可能性は急速に拡大しています。

オーケストレーション戦略の選択はユースケースに依存します。ReActは柔軟性と回復力を提供しますが、レイテンシーの問題があります。ReWoOはレイテンシーを減らし特定の計画に従うのに優れていますが、より多くのコードが必要で、モデルの進化に対して若干脆弱です。Amazon Bedrockのカスタムオーケストレーターを使えば、特定のニーズに最適化されたアプローチを実装できます。

同様に、ツール選択も重要な考慮事項です。汎用ツールは幅広いユースケースに対応できますが、特定のタスクでは精度が落ちる可能性があります。特定ツールは高い精度を提供しますが、エージェントの適用範囲を制限します。多くの場合、両方のアプローチを組み合わせることが最適解です。

今日のセッションの内容をさらに深く掘り下げたい方は、私たちのブログや資料を参照してください。特に「Amazon Bedrock Custom Orchestratorの使用開始」のブログ記事では、今日説明したさまざまなオーケストレーション戦略の実装詳細を確認できます。

もしスライドの内容をもっと記録しておきたいと思った方は、このトークはYouTubeにアップロードされますので、そちらで確認することができます。

皆さんの貴重なお時間をいただき、本当にありがとうございました。セッションのサーベイにぜひご協力ください。また、私やNicholasとLinkedInでつながりたい方は、ぜひお気軽にご連絡ください。

Nicholas: 私からも感謝の言葉を述べたいと思います。このトピックはとても刺激的で、技術が急速に進化している分野です。皆さんがこの知識を活用して、素晴らしいエージェントソリューションを構築されることを楽しみにしています。