Podcastの主な内容

ReAct：推論と行動は交互に行う

ReActの中核的な考えは、LLMが一度に回答を生成するだけでも、闇雲にツールを呼ぶだけでもいけないというものです。現在の状態を先に考え、検索、API呼び出し、コード編集、テスト実行などの行動を一つ取り、その結果を観察して、再び考えるloopを作ります。ReAct論文は、LLMがreasoning traceとtask-specific actionを交互に生成すると説明しています。推論はmodelが計画を維持し、例外を処理するのを助け、行動はmodelを外部知識ベースまたは環境へ接続します。(arXiv)

この回におけるShunyuのReActの説明は、特に興味深いものです。ReActは外部世界を変えたのではなく、実際に変えるのは モデル内部のcontext状態 だと説明します。つまり、「考えること」自体がaction、すなわちinternal actionです。gradientでモデルweightを更新するのではなく、context内の中間推論、観察結果、ツールfeedbackを使い、一つのタスク内でモデルへ方向性を与えます。

Harrisonは、現在の多くのAgent frameworkが明示的に「ReAct Agent」と呼ばれなくなっても、本質的にはReActの二点を受け継いでいると述べます。一つは、汎用的な方法で異なる環境とinteractionすること、もう一つは「内的独白/推論」とツール利用を組み合わせることです。字幕では、純粋なfunction callingにこのinner monologueが欠ける場合が多いため、実務ではツールparameterへthought fieldを加え、parameterを埋める前にモデルへ意図を整理させることがあるとも述べています。(Latent Space)

Reflexion：従来のRLにおける数値rewardを言語feedbackで置き換える

Reflexionの発想は、従来の強化学習がscore 0.7やreward +1のようなscalar rewardに依存し、その後gradientでモデルを更新する一方、人は必ずしもそのように学ばないという点から始まります。人は「この段階は良かったが、そこでedge caseを見落とした」といった言語feedbackを受け、それを次の行動の経験へ変えます。

Reflexion論文は、この方法をverbal reinforcement learningと呼びます。Agentがタスクfeedbackに基づいて振り返りを書き、それをepisodic memory bufferへ保存し、後の試行でその文字による記憶を使って判断を改善します。モデルweightは更新しません。(arXiv)

彼らはReflexionの制約も強調します。すべてのタスクに適するわけではありません。重要なのは、良いevaluatorがあるかどうかです。コードでは、テスト失敗、compile error、stack traceが強いfeedbackになります。非常に難しい数学推論で、考え方の正しさを評価すること自体が問題を解くのと同じくらい難しければ、reflectionの価値は下がります。別の制約はレイテンシです。カスタマーサービスAgentを使うユーザーは、2時間の振り返りを待てません。そのためreflectionは、offline training、データ生成、複雑タスクのsearch、または明確なfeedback signalがあるタスクにより適しています。

Tree of Thoughts：search型タスクに適し、すべてのリアルタイムタスクには適さない

Tree of Thoughtsは、「思考」自体をsearch可能なactionとして扱います。通常のChain of Thoughtは一つの道を下りますが、Tree of Thoughtsは複数の中間的な考えを生成、評価し、必要に応じて戻ります。論文では、ToTが複数のreasoning pathを検討し、自己評価して選択し、必要に応じてlookahead/backtrackingを行うと説明します。Game of 24では、GPT-4 + CoTの成功率は4%でしたが、ToTは74%に達しました。(arXiv)

ただし、番組ではToTを過度に評価しません。Harrisonは、ReActが最も普及した理由は、単純、低コスト、実装しやすいことにあると判断します。Tree of Thoughtsは計算コストが高く、実装も複雑なため、実際の利用は大幅に少なくなります。Shunyuもタスクを二種類に分けます。「search型タスク」は、数学の証明や複雑なコード問題のように、正解を一つ見つけられるなら100回試せるものです。「反応型タスク」は、カスタマーサービス、予約、Web操作のように、高速、安定、低レイテンシを求めるものです。ToTは前者、ReActは後者により適しています。

Memory：Agentの記憶は「ベクトルデータベースを加える」だけではない

彼らはsemantic memory、episodic memory、procedural memoryを議論します。簡単に言えば、次のようになります。

Semantic memoryは、「ユーザーはイタリア料理を好む」のような、世界やユーザーの好みに関する知識です。Episodic memoryは、「前回このタスクが失敗したのはAPI parameterが誤っていたため」のような、経験した軌跡や出来事です。Procedural memoryは、Voyagerが保存したコード片やSkillのような、「何かを行う方法」の技能です。Shunyuは、これらの分類が認知科学に由来し、思考には役立つものの、分類を具体的な実装へ固定してはいけないと述べます。Semantic memoryは必ずしもvector retrievalである必要はなく、procedural memoryもfine-tuneである必要はありません。最初に次を問います。この情報はどの種類か。どの程度保存するか。いつ取得するか。取得後にどう使うか。(Latent Space)

Harrisonは、memoryがエンジニアリング上、依然として大部分未解決だと述べます。知識graphの場合も、単なるinstruction listの場合もあります。実際の製品で「何が関連する記憶か」は、アプリケーションへ強く依存します。Shunyuのたとえも示唆的です。人にも統一された記憶systemはありません。Google Docsを使う人、Notionを使う人、紙とpenを使う人がいます。Agentの将来のmemoryも、一つの統一memory storeではなく、選択して使い方を学べる記憶ツールの集合かもしれません。(Latent Space)

Benchmarkとenvironmentは、方法そのものより重要

Shunyuは、AI Agent分野に不足しているのは方法ではなく、良いタスク、環境、benchmarkだと繰り返し強調します。学術界では単純なタスクへ複雑な方法を積み重ねて2%改善することがありますが、それが分野を前進させるとは限りません。benchmark設計はproduct managerの仕事に似ており、現実性、scalability、自動評価、難易度、実用性の均衡が必要だと考えます。

WebShop、InterCode、SWE-bench、τ-benchを話題にした理由もここにあります。WebShopは、118万点の実在商品と12,087件のcrowdsourcingによる指示を含む模擬EC環境です。自然言語の要件に従って、AgentがWebを閲覧、検索、選択し、商品を購入できるかを評価します。(arXiv) InterCodeはプログラミングをinteractiveな環境へ変えます。コードがaction、実行feedbackがobservationです。人も一度で完全なprogramを書かず、実行、error、修正、再実行を繰り返すからです。(arXiv) SWE-benchはさらに進み、実際のGitHub issueと対応PRからソフトウェアエンジニアリングタスクを作り、modelへcodebaseの理解と複数ファイルの変更を求めます。(arXiv)

SWE-agentとACI：人向けソフトウェアと同様に、Agent向けツールを設計する

この回で、エンジニアリング上最も示唆的な部分です。SWE-agent論文の題名は Agent-Computer Interfaces Enable Automated Software Engineering です。LM Agentは独自の能力と制約を持つ新しいend userであり、専用に設計したinterfaceが必要だと提案します。SWE-agentのcustom ACIは、Agentがコードを作成、編集し、リポジトリを閲覧し、テストを実行する能力を高めます。(arXiv)

Shunyuは番組で、さらに直接的に述べます。Agent自体を議論する前に、使用する環境とツールを議論すべきです。ツールが悪ければ、たとえばファイル編集後にfeedbackがなく、モデルがsyntax errorを持ち込んだか分からなければ、planning、search、prompt engineeringを追加しても救うのは困難です。ツールが使いやすくなると、Agent設計ははるかに単純にできます。「ツールを良く、信頼できるものにすることがAgent全体の90%かもしれない」とさえ述べています。(Latent Space)

これがACI、Agent-Computer Interfaceです。従来のHCIは人向けにinterfaceを設計しますが、ACIはmodel向けに設計します。ツール入力schema、結果の形式、error message、context size、modelへ十分なfeedbackを与えるか、自己修正しやすいかを含みます。番組では良い例を挙げています。長すぎるerror messageは人には煩わしい一方、LLMにとって詳細なerror情報は、次の修正を可能にするpromptになる場合があります。

Prompt engineeringは「秘伝の技」から「明確なcommunication」へ変わりつつある

Shunyuの姿勢は明確です。実際のタスクではminimalistであるべきです。最も単純な方法から始め、うまくいかなければツールを追加します。それでも明確な理由がある場合に、reflection、tree searchなど複雑な仕組みを追加します。「祖母が死にそうなので必ず答えなければならない」といった奇妙なprompt hackを好みません。CoT、tool use、Agentの振る舞いに合わせてmodelが最適化されるほど、良いpromptは同僚とのcommunicationに近づくと考えます。明確、具体的、合理的であることです。(Latent Space)

この点はengineerに特に重要です。将来の能力は「promptの呪文」を暗記することではなく、spec、制約、例、失敗条件、評価基準を明確に書くことです。言い換えると、prompt engineeringは、より基礎的で重要な能力、意図の表現とinterface設計 へ還元されます。

CoALA：Agentをmemory、action space、decision processへ分解できる

CoALA論文は、language agentへより体系的な認知アーキテクチャframeworkを提供しようとします。Agentを、modular memory、structured action space、generalized decision-making processを持つsystemとして説明します。(arXiv)

番組では、このframeworkをエンジニアリングへ落とし込みます。Agentは一つのLLMではなく、「neural network + neural networkを呼ぶコード + ツール + memory + decision logic」です。LangGraphは、Agentのdecision structureの一部をコードで定義することに対応します。Harrisonは、LLMがまだ複雑なplanningを得意としないため、コードで計画を助けられると述べます。必須のcheck、loop、branch、state transitionは、すべてをpromptへ詰め込むのではなく、明確なworkflowとして書けます。LangGraph公式文書も、long-runningでstatefulなAgentを構築、管理、deployする低レベルorchestration frameworkと定義し、durable execution、human-in-the-loop、memory、debugを強調します。(LangChain Docs)

τ-bench：実際のアプリケーションで最も難しいのは安定性とruleの遵守

τ-benchはカスタマーサービスAgentを対象にします。一つのLLMがユーザーを模擬し、もう一つのAgentがサービス担当者として、domain APIを呼び、policy ruleに従います。「modelが時々驚くほど良い結果を出せるか」ではなく、「100人のユーザーに対して99回安定して正しく行えるか」を重視します。論文abstractは、既存benchmarkがAgentと人のinteractionやdomain rule遵守能力を十分にtestしていないと指摘します。τ-benchはsimulated user、API tools、policy guidelinesで実際の場面を再現し、複数回の試行での信頼性を測るpass^kを提案します。実験では、GPT-4oのようなfunction-calling Agentでも成功率は50%未満で、retail domainのpass^8は25%未満でした。(arXiv)

製品化にとって重要な点です。研究demoは平均scoreを見ますが、商用systemはtail risk、安定性、回復可能性、compliance、user experienceを見ます。

本当に有望なアプリケーションとUXは、まだ定まっていない

最後にアプリケーションを議論します。Harrisonは、すでに比較的明確に有効な領域としてcustomer supportを挙げます。codingは非常に注目されていますが、当時は成功したと言い切りませんでした。research-style Agentにも機会があり、SDRのデータ補完、企業調査、法律調査などが考えられます。特に「non-chat UX」を強調します。たとえばspreadsheet-style Agentでは、各cellが小さなAgentとなり、企業調査を一括実行できます。background/ambient Agent、たとえばmail assistantは裏で処理し、確認が必要なときだけユーザーを中断します。(Latent Space)

LangGraph Studioの議論も、この方向に属します。HarrisonはStudioをAgentのIDEにたとえます。コードでgraphを定義し、Studioがgraphを表示し、interaction、test、persistence layerを使ったtime travel/debugを可能にします。さらに重要なのは、Agent構築がチーム協働になることです。engineerがcognitive architectureを定義し、productまたは業務担当者がprompt、設定、RAG設定を調整する可能性があります。(Latent Space)

何を学べるか

最も重要な点：Agentは「LLM + prompt」ではなく、「LLM + ツール + memory + 環境 + decision process + 評価system + human-computer interface」である

modelだけを見ると、成功を本当に決める多くの要素を見落とします。modelはもちろん重要ですが、Agent systemでは、ツール設計、feedback設計、error recovery、状態管理、評価データ、権限境界、context圧縮、log、可観測性が同じか、それ以上に重要な場合があります。

第2：単純なアーキテクチャから始め、最初から複雑なAgent patternを積まない

ReActが大きな影響を与えたのは、複雑だからではなく、単純、汎用、低コストだからです。Tree of Thoughts、Reflexion、MCTS、multi-Agentには価値がありますが、デフォルトの答えではありません。複雑な仕組みを追加するか判断するときは、四つの問いを使います。このタスクは本当にsearchを必要とするか。信頼できるevaluatorがあるか。高いレイテンシを許容できるか。利益が追加の複雑さを上回るか。答えが明確でなければ、単純なReAct loop + 良いツール + 良い評価から始めます。

第3：ツールの戻り値、error message、schemaは、本質的にすべてpromptである

従来のbackend engineerはAPIを設計するとき、type、field、idempotency、error code、互換性を考えます。Agent engineeringでは、もう一層を考えます。このAPIはLLMにとって理解、修正、回復が可能か。たとえばerror messageにfailedだけを書くのではなく、失敗原因、修正できる方向、関連contextを伝えます。ツール出力は読みづらい巨大なJSONではなく、明確な構造、意味のあるfield名、適切な結果量を持つべきです。

第4：Memoryは技術componentだけでなく、製品設計の問題である

Memoryと聞いてすぐにvector DBを選ばないようにします。最初に、記憶するものを区別します。ユーザーの好み、過去の対話、成功した軌跡、失敗経験、操作skill、業務上の事実のどれでしょうか。情報の種類ごとにlifecycle、privacy level、読み出し方法、更新方法が異なります。Backend engineerなら、memoryを「event logのmaterialized view」と考えられます。元logを保存し、抽出した好み、rule、経験を、編集、監査、圧縮できる状態として扱います。

第5：BenchmarkはAI製品の基礎である

評価がなければ、Agentが本当に改善したか分かりません。良い評価はaccuracyだけでなく、実際のタスク、edge case、失敗回復、複数turnのinteraction、rule遵守、安定性を網羅します。カスタマーサービスAgentなら、「一つの質問に答えられるか」だけでなく、複数turnの対話で返金policyを守るか、APIを正しく呼ぶか、情報不足時に追加質問するか、繰り返し実行して安定して成功するかをtestします。

第6：将来のAI engineerの価値は、「system designer + product engineer + evaluation engineer」に近づく

backend systemで使ってきた階層化、状態管理、interface設計、error処理、権限制御、log観測、test coverageは、Agent時代に古くなったのではなく、さらに重要になりました。違いは、systemに不確実なLLM componentが加わったことだけです。何をmodelへ渡すか、何を決定的なコードにするか、何をツールへ入れるか、何をmemoryへ置くか、何を人の確認へ委ねるかを決めます。

実践から本当の理解を得る

この回の内容を自分の能力へ変えるには、次の手順を参考にします。

まず最小のReAct Agentを作ります。最初からmulti-Agentを目指しません。ユーザータスク → modelが次のstepを考える → 一つのツールを呼ぶ → observationを得る → 続ける、というloopを作ります。ツールは単純な検索、calculator、ファイル読み取り、Python実行、テスト実行から始められます。機能数ではなく、observationが次の判断をどう変えるかを自分で経験することが重要です。

次にツールinterfaceを専門に改善します。コード編集ツールなら、「編集成功」だけを返さず、diff、syntax check結果、test結果、考えられるerror位置を返します。ツールを製品、LLMをユーザーとして扱います。多くのAgentが「賢くなる」のはmodelが強くなったからではなく、環境がようやく使えるfeedbackを与えたからだと気づきます。

続いて、小さなeval harnessを作ります。toy caseだけでなく、30〜100件の実際のタスクを選びます。各タスクに、入力、期待結果、利用可能なツール、採点方法、失敗原因の分類を定義します。prompt、ツール、modelを変更するたびに実行します。「Agentが強くなった気がする」から、「どの場面で強くなり、どの場面で弱くなったか分かる」へ進みます。

その後memoryを導入します。最初から複雑なアーキテクチャを使わず、ユーザーの好み、タスク経験、失敗例という三つのtableから始められます。各タスク終了後、modelまたはruleで監査可能なmemoryを一件抽出します。次のタスク開始前に、ユーザー、タスク種類、ツール種類から関連memoryを取得します。black-boxなベクトルデータベースではなく、ユーザーが閲覧、削除、変更できる状態にします。

最後に、LangGraphのような明示的workflowを試します。価値は「LLMのツール呼び出しを簡単にすること」ではなく、Agentの状態、branch、loop、人の確認、失敗回復を制御しやすくすることです。LangChainの現在の文書も、Agentが単純なtool bindingではなく、連続tool call、並列tool call、結果に基づく動的なtool選択、retry、tool call間の状態永続化を支えると強調します。(LangChain Docs)

Key Points

第1に、Agentの知能をmodelだけへ置かない。多くの知能をツール、環境、feedback、評価へ置くべきです。

第2に、単純なものから始めて複雑化する。ReActがデフォルトの出発点であり、Reflection、ToT、MCTSは明確に必要な場合だけ追加する強化要素です。

第3に、Agent向けAPIの設計は、人向けUIの設計に似ています。error message、field名、schema、戻り値の形式がmodelの性能へ影響します。

第4に、Memoryはデータベース選択の問題ではなく、情報lifecycle設計の問題です。

第5に、AI Agent製品の中核的な難しさはdemoで一度成功することではなく、安定し、制御でき、説明でき、評価できる形で何度も成功することです。

結び

LLM Agentの進歩はmodel能力だけの進歩ではなく、「model + ツール + memory + 環境 + 評価 + UX」というエンジニアリングsystem全体の進歩です。 ソフトウェアengineerにとって最も直接的な示唆は、従来のbackendアーキテクチャ能力が今後のAI engineeringでさらに価値を持つことです。ただし、「人が使うAPI」を「人とmodelの両方が使うAPI」へ拡張する必要があります。