Andrew Ng の Agentic AI 講座 第1回
Andrew Ng 教授による Agentic AI 講座の第1回
Agentic AI とは何か、なぜ Agentic AI ワークフローはこれほど強力なのか
今日、私たちの多くが大規模言語モデル、つまり LLM を使うやり方は、たとえば「あるテーマ X についてエッセイを書いて」とプロンプトを与えるというものです。私はこれを、人間に対して、あるいはこの場合は AI に対して、「最初の一語から最後の一語まで、一度も Backspace を使わずに一気にエッセイを打ち込んでください」とお願いするようなものだと考えています。
実は私たち人間は、このように完全に線形の順序で書くことを強いられた状態では、最高の文章は書けません。そして AI モデルも同じです。しかし、このような制約の中で書くことの難しさにもかかわらず、私たちの LLM は驚くほどうまくやっています。
これに対して、エージェント的（agentic）なワークフローでは、プロセスは次のようになるでしょう。まず特定のテーマについてエッセイのアウトラインを書くよう依頼し、次にウェブでの調査が必要かどうかを尋ねます。そしてウェブ調査を行い、場合によってはいくつかのウェブページをダウンロードした後、初稿を書き、その初稿を読んでどの部分に修正やさらなる調査が必要かを確認し、それから草稿を修正する、といった具合です。
この種のワークフローは、少し考えて、少し調査して、それから修正して、さらに考えて……という進め方に近いものです。そして、この反復的なプロセスによって、agentic ワークフローは時間はかかるものの、はるかに優れた成果物を生み出すことがわかっています。
つまり、agentic AI ワークフローとは、LLM ベースのアプリが複数のステップを実行してタスクを完了するプロセスです。この例では、LLM を使って最初のエッセイのアウトラインを書き、次に LLM を使って、ウェブ検索エンジンにどんな検索語を入力するか、より正確には、関連するウェブページを取得するためにウェブ検索 API をどんな検索語で呼び出すかを決めさせるかもしれません。それに基づいて、ダウンロードしたウェブページを LLM に入力して初稿を書かせ、その後、別の LLM を使ってリフレクション（reflection）を行い、どこにさらなる修正が必要かを決めさせることもできます。
このワークフローをどう設計するかによっては、LLM が人間によるレビュー（たとえばいくつかの重要な事実の確認）を要求できる human-in-the-loop のステップを追加することもできるでしょう。そしてそれに基づいて草稿を修正し、このプロセスによってはるかに優れた成果物が得られます。
この講座で学ぶ重要なスキルのひとつは、エッセイを書くといった複雑なタスクを取り上げ、それを小さなステップに分解し、agentic ワークフローが一度に1ステップずつ実行して、望む成果物を得られるようにする方法です。タスクをステップに分解する方法と、個々のステップをうまく実行するコンポーネントを構築する方法を知ることは、難しいけれども重要なスキルであり、非常に幅広いエキサイティングなアプリケーションのために agentic ワークフローを構築できるかどうかを左右します。
この講座では、私と一緒に構築していく一貫した例として、リサーチエージェントを使います。これがどのようなものかの例を示しましょう。「SpaceX と競合する新しいロケット会社をどう立ち上げればよいか？」のようなリサーチテーマを入力できます。私自身は SpaceX と競合したいとは思いませんが、もしあなたがそうしたいなら、リサーチエージェントに背景調査を手伝ってもらうことができます。
このエージェントは、まずどんな調査を行うかを計画することから始めます。ウェブ検索エンジンを呼び出していくつかのウェブページをダウンロードし、次に発見事項を統合してランク付けし、アウトラインを起草し、エディター役のエージェントに一貫性をレビューさせ、そして最後に包括的な Markdown レポートを生成します。ここではそれが実行され、SpaceX と競合する新しいロケット会社の立ち上げについて、イントロ、背景、発見事項などが書かれています。
このレポートは、これが立ち上げの難しいスタートアップになるだろうということを適切に指摘していると思います。ですから私自身はこれをやるつもりはありませんが、もしこうしたことに取り組みたいのであれば、このようなリサーチエージェントが初期の調査を手伝ってくれるかもしれません。複数のソースを見つけてダウンロードし、深く考察することで、単に LLM にエッセイを書くようプロンプトを与えるよりも、はるかに思慮深いレポートが最終的に得られます。
私がこれに興味を持っている理由のひとつは、私自身の仕事の中で、かなりの数の専門的なリサーチエージェントを構築してきたからです。法的文書における利益相反のコンプライアンスであったり、いくつかの医療分野であったり、ビジネスの製品調査分野であったりします。ですから、この例を通して取り組むことで、他の多くのアプリケーションのために agentic ワークフローを構築する方法を学ぶだけでなく、もしあなた自身がカスタムのリサーチエージェントを構築する必要が出てきたときに、リサーチエージェント構築のアイデアの一部が直接役に立つことを願っています。
さて、AI エージェントについてよく議論される分野のひとつが、それらがどの程度自律的（autonomous）なのか、という点です。今ご覧いただいたのは、比較的複雑で自律性の高い agentic AI ワークフローでしたが、それ以外にも、非常に価値のあるもっとシンプルなワークフローもあります。
次の動画に進んで、agentic ワークフローがどの程度自律的になりうるか、そしてそれが、さまざまなアプリケーションをどう構築していけばよいか、またそれらがどれくらい簡単か難しいかを考えるためのフレームワークを与えてくれるかどうかについて話しましょう。
次の動画でお会いしましょう。
自律性の度合い
エージェントはさまざまな度合いで自律的でありえます。数年前、私は AI コミュニティの中で「エージェントとは何か」をめぐる論争が激しくなっているのに気づきました。ある人は「私はエージェントを作った」という論文を書き、また別の人は「いや、それは本当のエージェントとは言えない」と言うのです。私はこの論争は不要だと感じました。だからこそ私は agentic という言葉を使い始めたのです。「エージェントであるかないか」という二値ではなく形容詞として使えば、システムがさまざまな度合いで agentic でありうることを認めざるを得なくなるだろうと考えたからです。
全部まとめて agentic と呼んで、これらのシステムを構築するという本来の仕事に進みましょう。ほら、「これはエージェントと呼べるほど十分に自律的なのか、そうでないのか」などと議論するのではなく。
agentic reasoning についての講演を準備していたとき、実際にチームメンバーの一人が私のところに来て、「ねえ Andrew、もうひとつ新しい言葉なんて必要ないよ。agent という言葉があるのに、なぜ agentic なんて別の言葉を作るの？」と言ったのを覚えています。それでも私はその言葉を使うことにしました。その後、ニュースレターの The Batch に記事を書き、ソーシャルメディアにも投稿して、どの言葉を「真のエージェント」として含めるか除外するかを言い争うのではなく、システムが agentic でありうるさまざまな度合いがあることを認めよう、と呼びかけました。これは「真のエージェントとは何か」という論争を乗り越え、実際にエージェントを構築することに集中する助けになったと思います。
エージェントの中には、あまり自律的でないものもあります。ブラックホールについてのエッセイを書くという例を考えてみましょう。比較的シンプルなエージェントに、いくつかのウェブ検索語、あるいはウェブ検索クエリを考えさせることができます。そして、ウェブ検索エンジンを呼び出し、いくつかのウェブページを取得し、それを使ってエッセイを書く、という流れをハードコードします。これは、完全に決定論的なステップの並びを持つ、あまり自律的でないエージェントの例です。そしてこれでもそれなりにうまく動きます。
表記法の約束として、この講座全体を通して、ここで左側に見えるように赤色を使ってユーザー入力を表します。この場合はユーザーのクエリ、後の例では agentic ワークフローへの入力文書などです。グレーのボックスは LLM の呼び出しを表し、ここで見えるウェブ検索やウェブ取得のボックスのような緑のボックスは、ウェブ検索 API の呼び出しやウェブサイトのコンテンツを取得するコードの実行など、他のソフトウェアを使ってアクションを実行するステップを示します。
一方で、エージェントはもっと自律的にもなりえます。ブラックホールについてのエッセイを書くという依頼を受けたとき、ウェブ検索をするのか、最近のニュースソースを検索するのか、それとも arXiv のウェブサイトで最近の研究論文を検索するのかを、LLM に決めさせるかもしれません。それに基づいて、この例では人間のエンジニアではなく LLM が、この場合はウェブ検索エンジンを呼び出すことを選び、その後、何ページのウェブページを取得するか、PDF を取得した場合はそれをテキストに変換する関数、あるいはツールを呼び出す必要があるかどうかを LLM に決めさせることができます。この場合、上位数ページを取得し、それからエッセイを書き、リフレクションして改善するかどうかを決め、場合によってはさらにウェブページを取得しに戻り、最後に出力を生成するかもしれません。
したがって、このリサーチエージェントの例だけを見ても、プログラマーが決めた線形のステップの並びを実行するあまり自律的でないエージェントもあれば、LLM により多くの判断を任せ、実際に起こるステップの正確な並びさえ、プログラマーが事前に決めるのではなく LLM が決めるような、より自律的なエージェントもあることがわかります。
つまり、自律性の低いシステムでは、通常すべてのステップが事前に決められており、ウェブ検索のように呼び出される関数（この講座の第3モジュールで学ぶように、これをツール使用（tool use）と呼びます）は、人間のエンジニア、つまりあなたや私によってハードコードされているかもしれません。自律性の大部分は、LLM がどんなテキストを生成するかにあります。
スペクトルのもう一方の端には、高度に自律的なエージェントがあります。エージェントが多くの判断を自律的に行い、たとえばエッセイを書くためにどんなステップの並びを実行するかを決めることも含まれます。高度に自律的なエージェントの中には、新しい関数を書いたり、時には新しいツールを作ってそれを実行したりできるものさえあります。
その中間にあるのが半自律的なエージェントで、いくつかの判断を行い、ツールを選ぶことはできますが、ツールは通常もっと事前に定義されています。
この講座でさまざまな例を見ていく中で、自律性の低いものから高いものまでこのスペクトル上のどこにでもアプリケーションを構築する方法を学びます。そして、スペクトルの自律性の低い側には、今日多くの企業のために構築されている非常に価値のあるアプリケーションが山ほどあることに気づくでしょう。同時に、スペクトルのより自律性の高い側でも取り組まれているアプリケーションがありますが、それらは通常、制御しにくく、少し予測しづらく、また、こうした高度に自律的なエージェントをどう構築するかを解明するための活発な研究も多く行われています。
それでは、次の動画に進んでこれをさらに掘り下げ、エージェントを使うことのメリットや、なぜエージェントによって、以前の世代のアプリケーションではまったく不可能だったことができるようになるのかについて聞いていきましょう。
Agentic AI のメリット
agentic ワークフローの最大のメリットは、以前はまったく不可能だった多くのタスクを効果的にこなせるようになることだと思います。しかし、それ以外のメリットもあります。ある種のことをかなり速くこなせる並列性（parallelism）や、さまざまな場所から最良のコンポーネントを組み合わせて効果的なワークフローを構築できるモジュール性（modularity）などです。見ていきましょう。
私のチームは、さまざまな LLM が特定のタスクを実行するコードを書く能力をテストするコーディングベンチマークのデータを集めました。ここで使われているベンチマークは HumanEval と呼ばれるもので、GPT-3.5（最初に一般公開された ChatGPT のベースとなったモデル）に、コードを直接書くよう、つまりコンピュータープログラムをそのまま打ち込むよう依頼すると、このベンチマークで 40% の正答率になります。これは pass@k 指標です。GPT-4 ははるかに優れたモデルで、同じく非 agentic なワークフローで性能は 67% に跳ね上がります。しかし、GPT-3.5 から GPT-4 への改善がどれほど大きくても、その改善は、GPT-3.5 を agentic ワークフローの中に組み込むことで達成できるものに比べれば小さく見えてしまうのです。
この講座の後半で学ぶさまざまな agentic な手法を使えば、GPT-3.5 にコードを書かせ、それからそのコードについてリフレクションさせて改善できるかどうかを考えさせることができます。このような手法を使うと、実際に GPT-3.5 にはるかに高いレベルの性能を出させることができます。同様に、agentic ワークフローの文脈で使われた GPT-4 も、はるかに良い結果を出します。つまり、今日の最高の LLM を使っていても、agentic ワークフローによってはるかに良い性能が得られるのです。
実際、この例で見たのは、モデルの世代間の改善は巨大ではあるものの、前の世代のモデルに agentic ワークフローを実装したときほどの差にはならない、ということです。
agentic ワークフローを使うもうひとつのメリットは、一部のタスクを並列化でき、そのため人間よりもはるかに速く特定のことをこなせる点です。たとえば、agentic ワークフローにブラックホールについてのエッセイを書くよう依頼したとき、3つの LLM を並列に動かして、検索エンジンに入力するウェブ検索語のアイデアを生成させることができるかもしれません。最初のウェブ検索に基づいて、たとえば上位3件の取得すべき結果を特定し、2番目のウェブ検索に基づいて、取得すべき2番目のウェブページの組を特定し、といった具合です。
そして、人間がこの調査をする場合、これら9つのウェブページを順番に、つまり1つずつ読まなければならないのに対し、agentic ワークフローを使うと、9つのウェブページのダウンロードをすべて並列化し、最後にそれらすべてを LLM に入力してエッセイを書かせることができます。つまり、agentic ワークフローは、純粋に非 agentic なワークフロー、すなわち1回だけプロンプトを与える直接生成よりは時間がかかるものの、この種の agentic ワークフローを、人間がそのタスクをどうこなさなければならないかと比べるなら、多くのウェブページのダウンロードを並列化できる能力によって、一人の人間がこのデータを処理する非並列で逐次的なやり方よりも、特定のタスクをはるかに速くこなせるのです。
この例をさらに発展させると、実は、agentic ワークフローを構築するときに私がよくやることのひとつは、LLM のような個々のコンポーネントを見て、コンポーネントを追加したり入れ替えたりすることです。たとえば、ここで使っているウェブ検索エンジンを見て、新しいウェブ検索エンジンに差し替えたいと判断するかもしれません。agentic ワークフローを構築する際には、実際に複数のウェブ検索エンジンがあります。サーバー経由でアクセスできる Google をはじめ、Bing、DuckDuckGo、Tavily、you.com などです。LLM が使うために設計されたウェブ検索エンジンには、実にたくさんの選択肢があります。
あるいは、3回のウェブ検索をするだけでなく、このステップで新しいニュース検索エンジンを組み込んで、ブラックホール科学の最近のブレイクスルーに関する最新ニュースを調べられるようにするかもしれません。そして最後に、すべてのステップで同じ LLM を使うのではなく、私はよくさまざまな大規模言語モデルを試し、さまざまな LLM プロバイダーを試して、このシステムの各ステップでどれが最良の結果を出すかを確かめます。
まとめると、私が agentic ワークフローを使う主な理由は、単純に、多くのさまざまなアプリケーションで、はるかに良い性能が得られるからです。しかしそれに加えて、人間なら逐次的にやらざるを得ないタスクの一部を並列化することもできます。また、多くの agentic ワークフローのモジュール設計によって、ツールを追加・更新したり、時にはモデルを入れ替えたりすることもできます。
agentic ワークフローを構築する主要なコンポーネントについて多くを語ってきました。次は、さまざまな Agentic AI アプリケーションを見て、人々がすでに構築しているものや、あなた自身が構築することになるものの感覚をつかんでもらいましょう。次の動画に進みましょう。
Agentic AI のアプリケーション
Agentic AI アプリケーションの例をいくつか見てみましょう。
多くの企業が行っているタスクのひとつが、請求書処理（invoice processing）です。このような請求書があるとき、最も重要なフィールドを抽出するソフトウェアを書きたいとします。このアプリケーションでは、請求者（ここでは Tech Flow Solutions）、請求者の住所、請求額（3,000ドル）、そして支払期限（2025年8月20日のようです）だとしましょう。多くの財務部門では、人間が請求書を見て、最も重要なフィールド、つまり誰にいつまでに支払う必要があるかを特定し、期限内に支払いが実行されるようにデータベースに記録しているでしょう。
これを agentic ワークフローで実装するなら、次のようにできるでしょう。請求書を入力し、PDF からテキストへの変換 API を呼び出して、PDF を LLM が取り込める整形済みテキスト、たとえば Markdown テキストに変換します。次に LLM がその PDF を見て、これが本当に請求書なのか、それとも無視すべき別の種類の文書なのかを判断します。そして請求書であれば、必要なフィールドを取り出し、API やツールを使ってデータベースを更新し、最も重要なフィールドをデータベースのレコードに保存します。
この agentic ワークフローの一面は、従うべき明確なプロセスがあるということです。必要なフィールドを特定してデータベースに記録する、というものです。従わせたい明確なプロセスがあるこのようなタスクは、agentic ワークフローにとっておそらく比較的こなしやすい傾向があります。このタスクを確実に実行するための、比較的ステップバイステップな方法につながるからです。
もうひとつ、もう少しだけ難しい例があります。顧客の基本的な注文問い合わせに対応するエージェントを構築したいなら、ステップは次のようになるでしょう。重要な情報を抽出する、つまり顧客が正確に何を注文したのか、顧客の名前は何かを把握し、次に関連する顧客レコードを検索し、そして最後に、メールの返信が顧客に送られる前に人間がレビューするための返信の草稿を作成します。
つまりここでもやはり明確なプロセスがあり、これをステップバイステップで実装していきます。メールを受け取り、それを LLM に入力して注文の詳細を検証あるいは抽出させ、顧客のメールが注文に関するものだと仮定すると、LLM は注文データベースを呼び出してその情報を取り出すことを選ぶかもしれません。その情報は LLM に渡され、メールの返信を起草します。そして LLM は、レビュー依頼ツールを使うことを選ぶかもしれません。これはたとえば、LLM が書いたこの返信の草稿を人間がレビューするためのキューに入れ、人間がレビューして承認した後に送信できるようにするものです。
このような顧客注文問い合わせエージェントは、今日、多くの企業で構築・導入されています。
もっと難しい例を見てみましょう。顧客が行った注文についての質問だけでなく、顧客が尋ねるかもしれないあらゆることを含む、より一般的な質問に対応するカスタマーサービスエージェントを構築したいとします。顧客は「黒いジーンズか青いジーンズはありますか？」と尋ねるかもしれません。この質問に答えるには、データベースに複数回 API を呼び出して、まず黒いジーンズの在庫を確認し、次に青いジーンズの在庫を確認し、それから顧客に返答する必要があるでしょう。
これはより難しいクエリの例で、ユーザーの入力が与えられたとき、在庫を確認するためのデータベースクエリの並びを実際に計画しなければなりません。あるいは、ユーザーが「買ったビーチタオルを返品したい」と言った場合、これに答えるには、まず顧客が本当にビーチタオルを買ったことを確認し、次に返品ポリシーを再確認する必要があるかもしれません。返品は購入日から30日以内で、タオルが未使用の場合に限られるかもしれません。そして返品が許可されるなら、エージェントに返品用の梱包伝票を発行させ、データベースのレコードを「返品保留中」に設定させます。
つまりこの例では、顧客のリクエストを処理するために必要なステップが事前にわかっていない場合、より難しいプロセスになります。LLM ベースのアプリケーションが、このタスクに適切に対応するためにはこの3つのステップが必要だ、と自分自身で判断しなければならないからです。しかし、この種の問題にどう取り組むかについての最新の研究についても学びます。
そして最後の例として、おそらく特に構築が難しい種類のエージェントを挙げると、エージェントによるコンピューター操作（computer use）に関する多くの研究があります。エージェントがウェブブラウザを使い、ウェブページを読んで複雑なタスクをどうこなすかを解明しようとするものです。この例では、サンフランシスコからワシントン DC、つまり DCA 空港へのユナイテッド航空の特定の2便に空席があるかどうかを確認するよう、エージェントに依頼しました。エージェントは、このタスクを実行するために使えるウェブブラウザにアクセスできます。
ここの動画では、エージェントがユナイテッドのウェブサイトを自力で操作し、ページ要素をクリックし、ページ上のテキストフィールドに入力して、私がリクエストした検索を実行しているのが見えます。作業しながら、エージェントはページの内容について推論し、タスクを完了するために必要なアクションと、次に何をすべきかを判断します。
この場合、ユナイテッドのサイトでフライトを確認するのに少し手間取り、代わりに Google Flights のウェブサイトに移動して、利用可能なフライトを検索することにしました。ここで見えるように、Google Flights でユーザーのクエリに一致するいくつかのフライトの選択肢を見つけ、エージェントはそのひとつを選んでユナイテッドのウェブサイトに戻されます。今度は正しいウェブページにいるようで、私が尋ねたフライトに空席がある、と判断することができました。
コンピューター操作は現在、エキサイティングな最先端の研究分野であり、多くの企業がコンピューター操作エージェントを動かそうと取り組んでいます。ここで見たエージェントは最終的に答えを導き出しましたが、私はエージェントがウェブブラウザをうまく使えずに苦労するのをよく見かけます。たとえば、ウェブページの読み込みが遅いと、エージェントは何が起きているのか理解できないことがありますし、多くのウェブページは、エージェントが正確に解析したり読んだりする能力をまだ超えています。しかし、コンピューター操作エージェントは、今日のミッションクリティカルなアプリケーションで使えるほどまだ信頼性は高くないものの、将来の発展においてエキサイティングで重要な分野だと思います。
ですから、Agentic AI ワークフローの構築を検討するとき、比較的容易なタスクは、明確なステップバイステップのプロセスがあるもの、あるいは企業がすでに標準的な手順、標準業務手順を持っていて、それに従えばよいものになる傾向があります。その手順を取り上げて AI エージェントとしてコード化するのはかなりの作業になりえますが、それは実装をより容易にする傾向があります。
容易にする要素のひとつは、テキストのみの素材を使うことです。LLM、つまり言語モデルは本質的にテキストを処理して育ってきたからです。他の入力モダリティを処理する必要がある場合、十分に可能ではあるものの、少し難しくなるかもしれません。そしてスペクトルの難しい側では、より高度なカスタマーサービスエージェントで見たように、タスクをこなすために何が必要かというステップが事前にわかっていない場合、エージェントはその場で計画したり解決したりする必要があるかもしれません。これはより難しく、より予測しづらく、信頼性も低くなる傾向があります。そして前述のとおり、音声、視覚、オーディオなどのリッチなマルチモーダル入力を受け付ける必要がある場合も、テキストのみを処理する場合より信頼性が低くなる傾向があります。
これで、agentic ワークフローで構築できるアプリケーションの種類について感覚をつかんでいただけたと思います。こうしたものを自分で実装するとき、最も重要なスキルのひとつは、複雑なワークフローを見て、個々のステップが何かを把握し、それらのステップを一度にひとつずつ実行する agentic ワークフローを実装できるようにすることです。
次の動画では、タスク分解（task decomposition）について話します。つまり、リサーチレポートを書く、カスタマーエージェントに顧客へ返信させる、といった複雑にやりたいことがあるとき、それをどう離散的なステップに分解して agentic ワークフローとして実装するか、ということです。次の動画で見ていきましょう。
タスク分解：ワークフローのステップを特定する
人や企業は実にさまざまなことをしています。私たちが行うこうした有用なことを、どうやって agentic ワークフローが従える離散的なステップに分解するのでしょうか。見ていきましょう。
リサーチエージェントを構築する例を取り上げます。AI システムにテーマ X についてエッセイを書かせたいなら、できることのひとつは、LLM にプロンプトを与えて直接出力を生成させることです。しかし、深く調査してほしいテーマでこれをやると、LLM の出力は表面的なポイントしかカバーしていなかったり、明白な事実しか扱っていなかったりして、望むほど深く主題に踏み込んでいないと感じるかもしれません。
その場合、人間であるあなたなら、あるテーマについてエッセイをどう書くかを振り返ってみるとよいでしょう。ただ座って書き始めますか？ それとも、まずエッセイのアウトラインを書き、次にウェブを検索し、ウェブ検索からの入力に基づいてエッセイを書く、といった複数のステップを踏みますか？
タスクを取り上げてステップに分解するとき、私が常に自問している質問は、「このステップ1、2、3を見たとき、それぞれを LLM、短いコード、関数呼び出し、あるいはツールのいずれかで実行できるか？」ということです。この場合、LLM は、私が考えを整理する手助けをしてほしい多くのテーマについて、おそらくまずまずのアウトラインを書けるだろうと思います。ですから、最初のステップはおそらく大丈夫だと言えます。次に、LLM を使ってウェブを検索するための検索語を生成する方法は知っています。ですから2番目のステップも実行可能だと言えます。そして、ウェブ検索に基づいて、LLM はウェブ検索結果を入力としてエッセイを書けると思います。したがって、これは直接生成より深く踏み込んだエッセイを書くための agentic ワークフローの、妥当な最初の試みになるでしょう。
しかし、それからこの agentic ワークフローを実装して結果を見てみると、結果がまだ十分ではないと感じるかもしれません。まだ望むほど思慮深いとは言えない。もしかするとエッセイが少しまとまりに欠けている気がする。これは実際に私にも起こったことです。以前このワークフローでリサーチエージェントを構築したのですが、出力を読むと少しまとまりがない感じがしました。なんというか、記事の冒頭が中盤と完全に一貫しているとは感じられず、中盤も結末と完全に一貫しているとは感じられなかったのです。
この場合、人間であるあなたがエッセイに少しまとまりがないと感じたとき、ワークフローをどう変えるかを考えてみるとよいでしょう。できることのひとつは、3番目のステップである「エッセイを書く」を、さらに追加のステップに分解することです。一気にエッセイを書くのではなく、まず初稿を書き、次にどの部分に修正が必要かを検討し、それから草稿を修正させます。これは人間である私がやるであろうやり方です。最初の試みで最終的なエッセイを書くのではなく、初稿を書いてそれを読み返す。これは LLM がかなり得意とする別のステップです。そして、自分のエッセイに対する自分自身の批評に基づいて、草稿を修正します。
振り返ると、私はまず1ステップだけの直接生成から始め、それでは不十分だと判断して3つのステップに分解し、それでもまだ不十分だと判断して、ステップのひとつを取り上げてさらに3つのステップに分解した結果、エッセイを生成するためのこのより複雑で豊かなプロセスができました。そして、このプロセスの結果にどれだけ満足しているかによって、このエッセイ生成プロセスをさらに修正することを選んでもよいのです。
複雑なタスクを小さなステップに分解する2番目の例を見てみましょう。顧客の基本的な注文問い合わせに対応する例を取り上げます。人間のカスタマーサポート担当者が最初に行うステップは、まず重要な情報を抽出することでしょう。このメールは誰からか、何を注文したか、注文番号は何か、などです。これらは LLM ができることです。ですから、「LLM にやらせよう」と言えます。2番目のステップは、関連する顧客レコードを見つけることです。つまり、顧客が何を注文し、いつ発送したかなどを取り出すための関連するデータベースクエリを書いて生成します。注文データベースにクエリを投げる関数を呼び出す能力を持った LLM なら、これができるはずです。そして最後に、顧客レコード、つまり顧客の注文レコードを取り出したら、顧客への返信を書いて送ります。取り出した情報があれば、メールを送る API を呼び出す選択肢を与えれば、この3番目のステップも LLM で実行可能だと思います。
これは、顧客メールへの返信というタスクを3つの個別のステップに分解し、それぞれのステップを見て「そうだね、LLM、あるいはデータベースにクエリを投げたりメールを送ったりする関数を呼び出せる LLM なら、これができるはずだ」と言えるようにする、もうひとつの例です。
最後にもうひとつだけ、請求書処理の例です。PDF の請求書がテキストに変換された後、最初のステップは必要な情報、つまり請求者の名前、住所、支払期限、請求額などを取り出すことです。これは今の LLM でできるはずです。次に、情報が抽出されたことを確認して新しいデータベースエントリに保存したいなら、LLM がデータベースレコードを更新する関数の呼び出しを手伝えるはずだと思います。これを実装するには、基本的にこの2つのステップを実行する agentic ワークフローを実装します。
agentic ワークフローを構築するとき、私は自分がいくつもの構成要素（building blocks）を持っていると考えます。重要な構成要素のひとつは大規模言語モデル、あるいは画像や音声も処理したい場合は大規模マルチモーダルモデルでしょう。LLM はテキストの生成、何を呼び出すかの判断、情報の抽出などが得意です。非常に専門的なタスクのためには、PDF をテキストに変換する AI モデル、テキスト読み上げ、画像解析などの他の AI モデルも使うかもしれません。
AI モデルに加えて、いくつものソフトウェアツールも使えます。ウェブ検索をしたり、リアルタイムの天気データを取得したり、メールを送ったり、カレンダーを確認したりするために呼び出せるさまざまな API などです。また、データベースからデータを取り出したり、大規模なテキストデータベースを検索して最も関連性の高いテキストを見つける RAG（retrieval augmented generation、検索拡張生成）を実装したりするための、情報検索のツールもあるでしょう。あるいはコードを実行するツールもあります。これは LLM にコードを書かせ、そのコードをあなたのコンピューター上で実行して、非常に幅広いことを行えるようにするツールです。
これらのツールの一部が少し馴染みのないものに思えても、心配はいりません。最も重要なツールについては、後のモジュールでもっと詳しく説明します。しかし、エージェントワークフローを構築するときの私の仕事の多くは、人や企業が行っている仕事を見て、これらの構成要素を使って、システムに実行させたいタスクをこなすためにどう構成要素を並べて組み合わせられるかを考えることだと思っています。だからこそ、どんな構成要素が使えるかをよく理解していることが（この講座の終わりまでにその感覚もより身についていることを願っていますが）、これらの構成要素を組み合わせてどんな agentic ワークフローを構築できるかを、より良く思い描けるようにしてくれるのです。
まとめると、agentic ワークフローを構築する上での重要なスキルのひとつは、誰かが行っている一連のことを見て、それを実装できる離散的なステップを特定することです。そして個々の離散的なステップを見るとき、私が常に自問している質問は、「このステップは、LLM か、あるいは API や関数呼び出しなど私が使えるツールのどれかで実装できるか？」ということです。答えがノーの場合、私はよく「人間である私ならこのステップをどうやるだろう？」と自問します。そして、これをさらに分解して、LLM や手持ちのソフトウェアツールで実装しやすい、もっと小さなステップに分けることは可能か、と考えます。
これで、タスク分解についてどう考えるべきかの大まかな感覚をつかんでいただけたと思います。まだ完全には掴めていないと感じても、心配はいりません。この講座ではさらに多くの例を扱いますし、講座の終わりまでにはこれをはるかによく理解しているはずです。ただ、agentic ワークフローを構築していくと、最初のタスク分解、最初の agentic ワークフローを構築した後、望む性能レベルに達するまで、かなりの回数の反復と改善を続けたくなることが多いとわかります。
そして、多くのプロジェクトで重要だと私が感じてきたこの改善プロセスを推進するための重要なスキルのひとつが、agentic ワークフローをどう評価するかを知ることです。次の動画では、評価（evals）と、その主要な構成要素、どう構築するか、そしてどうワークフローを改善し続けて望む性能を得るかについて話します。次の動画で evals について話しましょう。
Agentic AI の評価（evals）
私は agentic ワークフローの構築で多くのさまざまなチームと働いてきましたが、誰かがそれを本当にうまくできるか、それとも効率が悪いかを最もよく予測する要因のひとつは、本当に規律ある評価プロセスを推進できるかどうかだとわかりました。つまり、agentic ワークフローの evals を推進する能力が、それを効果的に構築する能力に大きな違いをもたらすのです。
この動画では、evals の構築方法を簡単に概観します。これはこの講座の後のモジュールで実際にもっと深く掘り下げるテーマです。では見ていきましょう。
顧客の注文問い合わせに対応するこのような agentic ワークフローを構築した後、何がうまくいかない可能性があるかを事前に知るのは非常に難しいことがわかります。ですから、事前に評価を構築しようとするのではなく、私がおすすめするのは、まず出力を見て、もっとうまくやってほしいと思うところを手作業で探すことです。
たとえば、多くの出力を読んでいて、思いがけず競合他社について必要以上に言及していることに気づくかもしれません。多くの企業は、気まずい状況を生むだけなので、エージェントに競合他社に言及してほしくありません。こうした出力のいくつかを読むと、時々「当店でお買い物いただきありがとうございます。私たちは競合の ComproCo よりずっと優れています」と言っていたり、「もちろん、きっと楽しいですよ。RivalCo とは違って、当店は返品が簡単です」と言っていたりするかもしれません。そしてこれを見て、「うーん、競合には本当に言及してほしくないな」と思うでしょう。
これは、この agentic ワークフローを構築する前の段階で予測するのが本当に難しい問題の例です。ですから、ベストプラクティスは本当に、まず構築してから、それを調べて、どこがまだ満足のいくものでないかを把握し、それから、システムがまだ満足のいかない点を取り除くために、評価する方法と同時に改善する方法も見つけることです。
あなたの企業が、このように競合に言及することをエラーやミスとみなすと仮定すると、こうした競合への言及をなくす作業を進める中で、進捗を追跡するひとつの方法は、このエラーがどれくらいの頻度で起こるかを追跡する評価（eval）を追加することです。ComproCo、RivalCo、その他の会社といった競合の名前のリストがあれば、自分の出力の中でこれらの競合名にどれくらいの頻度で言及しているかを検索するコードを実際に書き、全体の応答に対する割合として、誤って競合に言及した頻度を数値で集計できます。
競合への言及という問題の良い点のひとつは、それが客観的な指標だということです。つまり、競合に言及したかしなかったかのどちらかです。客観的な基準については、この特定のエラーがどれくらいの頻度で起こるかをチェックするコードを書くことができます。
しかし、LLM は自由なテキストを出力するため、出力を評価したい基準の中には、より主観的で、白黒のスコアを出力するコードを書くのが難しいものもあるでしょう。この場合、LLM を審査員として使う（LLM-as-judge）のが、出力を評価する一般的な手法です。たとえば、さまざまなテーマについて調査するリサーチエージェントを構築しているなら、別の LLM を使って、「次のエッセイに1から5の品質スコアを付けてください。1が最悪で5が最良のエッセイです」のようにプロンプトを与えることができます。
ここでは、生成されたエッセイをここにコピー＆ペーストするという意味で Python の式を使っています。つまり、LLM にエッセイを読ませて品質スコアを付けさせるようプロンプトを与えられます。次に、リサーチエージェントに、たとえばブラックホール科学の最近の進展や、ロボットを使った果物の収穫など、さまざまなリサーチレポートをいくつも書かせます。そしてこの例では、審査員の LLM がブラックホールのエッセイに3、ロボット収穫のエッセイに4のスコアを付けるかもしれません。リサーチエージェントの改善に取り組んでいけば、時間とともにこれらのスコアが上がっていくのが見られるはずです。
ところで、実は LLM はこうした1から5のスケールの評価が実際にはあまり得意ではないことがわかっています。試してみてもよいですが、私個人としては、自分ではこの手法をそれほど多くは使わない傾向があります。しかし後のモジュールでは、1から5のスケールでスコアを出力させるよりも正確なスコアを LLM に出力させる、より良い手法を学びます。とはいえ、LLM-as-judge 型の eval の最初の試みとして、これをやる人もいます。
この講座の後半で学ぶ Agentic AI の evals のいくつかを予告しておくと、競合に言及したかどうかといった客観的な基準を評価するコードを書く方法や、このエッセイの品質はどうかといったより主観的な基準に LLM を審査員として使う方法については、すでにお話ししました。しかし後で、2つの主要なタイプの evals について学びます。ひとつはエンドツーエンド（end-to-end）で、エージェント全体の出力品質を測定するもの、もうひとつはコンポーネントレベルの evals で、agentic ワークフローの中の単一ステップの出力品質を測定するものです。これらは開発プロセスのそれぞれ異なる部分を推進するのに役立つことがわかっています。
私がよくやることのもうひとつは、中間出力（LLM のトレースと呼ぶこともあります）を調べて、どこが私の期待に届いていないかを理解することです。これをエラー分析（error analysis）と呼び、各ステップの中間出力をひとつずつ読み通して、改善の機会を見つけようとします。そして、evals とエラー分析ができることは、本当に重要なスキルであることがわかっています。
これについては、この講座の第4モジュールでもっと多くのことをお話しします。
この第1モジュールはもうすぐ終わりです。先に進む前に、agentic ワークフローを構築するための最も重要なデザインパターンだと私が考えるものをお伝えしたいと思います。次の動画で見ていきましょう。
Agentic デザインパターン
私たちは、構成要素を取り上げて組み合わせ、複雑なワークフローを順序立てることで agentic ワークフローを構築します。この動画では、いくつかの重要なデザインパターン、つまりこれらの構成要素をより複雑なワークフローに組み合わせる方法についての考え方のパターンをお伝えしたいと思います。見ていきましょう。
agentic ワークフローを構築するための4つの重要なデザインパターンは、リフレクション（reflection）、ツール使用（tool use）、プランニング（planning）、そしてマルチエージェント協調（multi-agent collaboration）だと思います。それぞれの意味を簡単に説明し、その後、この講座の後半でこれらのほとんどを実際に詳しく扱います。
主要なデザインパターンの1つ目はリフレクションです。たとえば私が LLM エージェントのところへ行ってコードを書くよう依頼すると、実は LLM はこのようなコードを生成するかもしれません。ここでは特定のタスクを行う Python 関数を定義しています。次に、このようなプロンプトを構成できます。「これは特定のタスクのためのコードです」と言って、LLM が今出力したものをこのプロンプトにコピー＆ペーストします。そして、コードの正確性、スタイル、効率を注意深くチェックし、建設的な批評をするよう依頼します。すると、同じ LLM モデルでも、このようにプロンプトを与えられると、コードの問題点をいくつか指摘できるかもしれないことがわかります。そしてこの批評をモデルにフィードバックして、「これはバグのようです。コードを修正してもらえますか？」と言えば、実際により良いバージョンのコードを出してくるかもしれません。
ツール使用の予告として、コードを実行してどこで失敗するかを見ることができるなら、それを LLM にフィードバックすることでも、反復してはるかに良い、たとえば v3、バージョン3のコードを生成できるようになります。つまり、リフレクションは一般的なデザインパターンで、LLM に自分自身の出力を検証させたり、コードを実行してエラーメッセージが出るかどうかを見るといった外部の情報源を取り入れたりして、それをフィードバックとして再度反復し、より良いバージョンの出力を生み出させることができます。このデザインパターンは魔法ではありません。すべてが100%うまくいくようになるわけではありません。しかし時には、システムの性能を大きく押し上げることがあります。
さて、私はこれを、あたかも私がプロンプトを与える単一の LLM であるかのように描きましたが、マルチエージェントワークフローの予告として、同じモデルに自己批評させる代わりに、批評エージェントを持つことも考えられます。それは、「あなたの役割はコードを批評することです。これは特定のタスクのためのコードです。コードを注意深くチェックしてください」といった指示でプロンプトを与えられた LLM に過ぎません。そして2番目の批評エージェントは、エラーを指摘したり、ユニットテストを実行したりするかもしれません。それぞれが特定のペルソナを取るようプロンプトを与えられた LLM に過ぎない2つのシミュレートされたエージェントを持つことで、それらを行き来させて反復し、より良い出力を得ることができます。
リフレクションパターンに加えて、2番目の重要なデザインパターンはツール使用です。今日、LLM にはツール、つまり仕事を成し遂げるために呼び出せる関数を与えることができます。たとえば、LLM に「レビュアーによると最高のコーヒーメーカーは何ですか？」と尋ね、ウェブ検索ツールを与えれば、実際にインターネットを検索してはるかに良い答えを見つけられます。あるいはコード実行ツールです。「100ドルを複利で投資したら、最後にいくらになりますか？」のような数学の質問をすれば、コードを書いて実行し、答えを計算できます。今日、さまざまな開発者が LLM に多種多様なツールを与えています。数学やデータ分析から、ウェブやさまざまなデータベースから情報を取得すること、メールやカレンダーなどの生産性アプリとの連携、画像の処理など、実に多くのものです。そして、LLM がどのツールを使うか、つまりどの関数を呼び出すかを決められる能力によって、モデルははるかに多くのことを成し遂げられます。
4つのデザインパターンの3つ目はプランニングです。これは HuggingGPT という論文の例で、システムに「少女が本を読んでいて、そのポーズが画像の中の少年と同じである画像を生成し、その新しい画像をあなたの声で説明してください」と依頼すると、モデルはこのタスクを実行するために、まず少年のポーズを把握するためのポーズ判定モデルを見つける必要があると自動的に判断できます。次にそのポーズで少女の画像を生成し、画像をテキストにし、そして最後にテキストを音声にします。つまりプランニングでは、LLM が取るべきアクションの並びを決めます。この場合は API 呼び出しの並びで、タスクをこなすために正しいステップの並びを正しい順序で実行できるようにします。開発者が事前にステップの並びをハードコードするのではなく、実際に LLM に取るべきステップを決めさせるのです。今日、プランニングを行うエージェントは制御が難しく、やや実験的ですが、時には本当に素晴らしい結果をもたらすことがあります。
そして最後に、マルチエージェントワークフローです。人間のマネージャーが複雑なプロジェクトに一緒に取り組むために何人かを雇うのと同じように、場合によっては、それぞれが異なる役割に特化した複数のエージェントの組を「雇い」、複雑なタスクを達成するために協力させることが理にかなうかもしれません。ここ左側に見える図は、ChatDev というプロジェクトから取ったものです。ChatDev は、Chen Qian と共同研究者たちが作成したソフトウェアフレームワークです。ChatDev では、最高経営責任者、プログラマー、テスター、デザイナーなど、異なる役割を持つ複数のエージェントが、まるで仮想のソフトウェア会社であるかのように協力し合い、さまざまなソフトウェア開発タスクを共同で完了できます。
別の例を考えてみましょう。マーケティングのパンフレットを書きたいなら、オンライン調査を行うリサーチャー、マーケティング文を書くマーケター、そして最後にテキストを編集して磨き上げるエディターという3人のチームを雇うことを考えるかもしれません。同じように、シミュレートされたリサーチエージェント、シミュレートされたマーケターエージェント、シミュレートされたエディターエージェントが集まって、あなたのためにこのタスクをこなすマルチエージェントワークフローの構築を検討してもよいでしょう。マルチエージェントワークフローは、エージェントが何をするかを常に事前に知ることはできないため制御がより難しいですが、伝記の執筆やチェスの指し手の決定など、多くの複雑なタスクでより良い結果をもたらしうることが研究で示されています。マルチエージェントワークフローについても、この講座の後半でさらに学びます。
これで、agentic ワークフローで何ができるか、そして構成要素を見つけて、おそらくこれらのデザインパターンを通してそれらを組み合わせ、agentic ワークフローを実装する上での主要な課題が何かについて、感覚をつかんでいただけたと思います。そしてもちろん、システムがどれだけうまく動いているかを確認して改善し続けられるように、eval を開発することも含まれます。次のモジュールでは、これらのデザインパターンの1つ目であるリフレクションについて深く掘り下げてお伝えしたいと思います。これは、実装が驚くほど簡単でありながら、時にシステムの性能を大きく押し上げてくれる手法だとわかるでしょう。それでは、次のモジュールに進んでリフレクションのデザインパターンを学びましょう。