見出し画像

Agent Frameworkはどれを使うべきか [タスク性能編]

はち

1. はじめに

2025年はAgentの年と言われ、近年多くのLLM-Based Agent用のフレームワーク/SDKが登場してきています。

これらの多くがツールユースを想定したReActエージェントの実装が簡単にできるようになっており、機能も近い中でライブラリをなんとなく選択されている人も多いのではないでしょうか。

例えば、SmolagentsとLangGraphではCodeAgentやcreate_react_agentなど、若干の違いはあるものの大まかな使い方はかなり似通っています。

フレームワークの類似性

その中で、フレームワークによって性能さが出たり、出力に違いは出るがあるのかということを調べてみました。
フレームワークの違いをそのタスク性能から比較してみようというのが今回の趣旨になります。

2. 検証概要

2.1 ベンチマーク

以下の2つの推論能力を測るベンチマークテストを個別フレームワークで実行できるように改造して結果を比較してみます。

  1. Travel Planner

  2. Sudoku-Bench

TravelPlannerは、旅行計画を指定された条件と選択肢の中から作成するテストです。指定された条件を見落としなく計画に反映するのが大変難しく設計されています。シングルターン形式です。

Sudoku-Benchはオリジナルに設計された数独パズルを解くテストです。初期状態から１ターンに１手ずつパズルを解いていくというマルチターン形式となります。

TravelPlannerは言語的な推論能力を、Sudoku-Benchは数学的な推論能力（に近いもの）を測れると個人的に考え、これらを選択しました。

テストの性質

2.2 対象フレームワーク

比較したフレームワーク・SDKは以下の６つです。
スター数が全てではないですが、現状多くの利用や注目を集めているプロジェクトと言えそうです。（スター数は2025/05/04時点のもの。）

各バージョンはそれぞれのrequirements.txt（TravelPlanner, Sudoku-Bench）を参照してください。他のライブラリとの兼ね合いでベンチマーク毎にバージョンが異なる点に注意してください。

2.3 利用モデル

テストはどちらともモデルに "gpt-4.1-2025-04-14" を用いました。
理由は以下の通りです。

  • 比較的最近のモデルであり、Agent Frameworkで使われることを想定して(おそらく)作られている

  • 100 万トークンまで無料である

3. Travel Planner

本検証では、Travel Plannerのsole planningモードを使用しました。これは、与えられた情報を元に旅行計画を作成するモードです。（もう1つのtwo stageモードでは情報は与えられず検索ツールを使用させます。）
また、検証はvalidationデータで行なっています。

3.1 評価指標について

Travel Plannerにはいくつかの評価指標があるので簡単にみていきます。

まず、1つ目はDelivery Rate (納品率)。これは「最終プラン」を返せた割合です。中身はともかく答えを作成できるかという最低限の能力を評価します。これは今回の全ての結果で100%だったので気にする必要はありません。

2つ目は、Commonsense Constrain (常識的制約)。これは、8 種類の常識的制約（同じ都市内で情報が完結しているか・レストランが偏っていないかなど）をどの程度守っているかを評価します。
計算方法によってMicro Pass RateとMacro Pass Rateが存在します。

3つ目は、Hard Constraint (ハード制約)。明示的に指定される必須要件（予算や食事制限など）を守れるかを評価します。
計算方法によってMicro Pass RateとMacro Pass Rateが存在します。

4つ目は、Final Pass Rate (最終合格率)。全てのCommonsense ConstrainとHard Constraintを通過したクエリの割合を表します。

これらの指標により、「プランを出せるか」「常識を理解しているか」「ユーザ要件を守れるか」「すべてを整合的に満たせるか」という段階的な難度を可視化できます。
一般的にスコアはDelivery Rate > Commonsense Constrain > Hard Constraint > Final Pass Rateとなります。

3.2 入出力トークン数

各指標の結果を確認する前に、各フレームワークで使用したトークン数を確認してみます。
BaseはTravel Planner元々の実装での結果です。

入出力トークン数（１）

まず目につくのが、ほとんどのフレームワークで同様の入力トークン数となっています。これは、ほとんどのフレームワークでフレームワーク固有の追加プロンプトや機能がないということです。（つまり、ユーザーのプロンプトのままAPIに送られる。）

一方で、SmolagentsとAutoGenは追加のプロンプトがあることが確認できます。特にSmolagentsは他と仕組みが大きく異なり複数ステップのAPI呼び出しが必ず発生するために、他の3倍近くの入出力トークンを使用しています。AutoGenは若干の追加プロンプトがあるようです。この影響かSmolagentsとは逆に出力トークン数は抑えられています。

入出力トークン数（２）

OpenAI Agents SDK, LangGraph, PydanticAI, Agno, Baseは入力トークンが同じであり、これらの出力もほぼ同様となる可能性が高いです。実際、出力トークン数を見るとほとんどがBaseの645トークンに近い630-645程度であることがわかります。
OpenAI Agents SDKのみ出力トークン数が700と、若干大きいのが気になりました。（ただの上振れの可能性もありますが。）

上記の結果より、Smolagents, AutoGen, OpenAI Agents SDKの結果に特異性があると考えて、これらの結果を中心に確認していこうと思います。

3.3 結果

結果は以下のようになりました。左からDelivery Rate, Commonsense Constraint (常識的制約), Hard Constraint (ハード制約), Final Pass Rateとなっています。（数値はAppendixに掲載）
BaseはTravel Planner元々の実装での結果です。

Travel Planner 結果グラフ

同じモデルを使用しているためそこまで大きな差はでないです。入出力が同じはずのLangGraph, PydanticAI, Agno, Baseにもある程度幅があるのは確率的なものだと考えられます。

入出力に特異性があったSmolagents, AutoGen, OpenAI Agents Frameworkを確認していきます。 

Smolagents

Travel Planner 結果 (SmolAgents)

Smolagentsは特にHard Constraint (ハード制約)が飛び抜けて高いです。入出力トークンが多くなるのを犠牲として、より複雑な問題や制約への対応力が高いと言えそうです。

一方で、若干Commensense Constraint (常識的制約)が低いようにも見えます。Final Pass RateはBaseの5%よりも高い6.1%であり、全体で2位となりました。

AutoGen

Travel Planner 結果 (AutoGen)

AutoGenはSmolagentsほど極端ではありませんが、 若干Hard Contstraint (ハード制約)が高く、Commonsense Constraintも高めです。
Final Pass RateはBaseの5%よりも高い5.6%であり、全体では3位となっています。

OpenAI Agents SDK

Travel Planner 結果 (OpenAI Agents SDK)

OpenAI Agents SDKは全体的にはBaseとほぼ同等のスコアでありながら、なぜかFinal Pass Rateが全体1位の6.7%でした。これが出力トークンが多いことと何か関係があるのか、ただの上振れなのかは不明です。

今回使用したのがOpenAIのモデルなので邪推してしまうところですが、このSDK以外のAPIコールに対して性能を下げる意味もそれほどない気もするので上振れの可能性が高いのではないでしょうか。

3.4 Travel Plannerまとめ

結果からの言えそうなことは以下の通りです。

  • 入出力になんらかの追加要素（プロンプトや機能）があるのはSmolagents, AutoGen。

  • これらの追加要素はハード制約の性能を向上させるものの、常識的制約には悪い影響を与えている可能性がある。

言語的な推論問題では、低難易度のタスクではSmolagents以外のどのフレームワークでも性能に差異はなく学習コストをかけずに使えるものを使えば良い気がします。
一方で、高難易度のタスクかつ高コストが許容できる場面では、Smolagentsの利用を検討すると良いかもしれないです。

4. Sudoku-Bench

Sudoku-Benchはマルチターン形式でありAPI利用料が高額になりそうだったため、

  • 対象パズルを "challenge_100" の4x4のみ

  • num_empty_cells（パズルを埋める数）を5

としました。

一方で、num_empty_cellsを-1 (全てのセルを埋める)としない限りある程度ランダム性が生まれてしまうため、各パズルを5回繰り返し実行する設定としました。（n_response_idxs 0 1 2 3 4）

4.1 評価指標について

Sudoku-Benchについては重要な評価指標は2つです。

  • num_correct_placements：正しく配置できたセルの数

  • final_solved：パズルが完全に解かれたか

今回はnum_empty_cells（パズルを埋める数）を5としたため、num_correct_placementsは0-5の間の数値となります。0であれば1つもセルを埋められなかったことになりますし、5であれば全てのセルを埋められたことになります。

主には各問題当たりのこれらの指標の平均をみていきます。

4.2 入出力トークン数

先ほどと同様に、フレームワーク毎の入出力トークン数の違いをまず確認します。
BaseはSudoku-Bench元々の実装での結果です。（元々の実装には入出力トークン数を計測する機能がなかったため未測定となっています。）

入出力トークン数

Travel Planner同様に、smolagents, autogenの入力トークン数が多いです。smolagentsの出力トークン数は多いけれど、autogenの出力トークン数は少なくなる挙動もTravel Plannerと同様でした。
マルチターン形式の影響でsmolagents, autogenとその他の利用トークン数の差が顕著に出ています。

一方、OpenAI Agents Frameworkの出力トークン数はTravel Plannerとは異なり平均的なものとなっており、やはりTravel Plannerでの挙動は上振れただけと言えそうです。

4.3 結果

各指標の結果は以下の通りとなりました。左がnum_correct_placementsの平均、右がfinal_solvedの平均です。（数値はAppendixに掲載）
BaseはSudoku-Bench元々の実装での結果です。

Sudoku-Bench 結果グラフ

結果は、smolagents以外ほとんど差異はなく、smolagentsのみ顕著に低いスコアとなりました。

Sudoku-Benchは１ターンに１セルを埋めるという以下のような形式での回答を行う必要があります。

<ANSWER>
rXcY: Z
</ANSWER>

smolagentsはデフォルトでコード生成と実行を行う挙動を各ステップで行うようにできています。この仕様により、総当たりで最初から全てのセルの答えを解いている挙動がみられました。
このような最初に全てを解いてしまう挙動や、利用トークン数の長さから、回答が上記の形式でないことが多かったです。（例えば全てのセルを埋めた結果を返したり、ANSWERタグなしで返答したり。）

4.4 実装上の制約

スコアはSmolagentsの一人負けとなりましたが、Sudoku-Bench用スクリプトの実装上で気づいたフレームワーク間の差異もここで連携しておきます。具体的にはSmolagentsとOpenAI Agents SDKに他のフレームワークにはない制約がありました。

Sudoku-Benchはマルチターン形式の会話を行うために、以下のような事前の会話を行ったこととして、2ターン目から具体的な数独の盤面を共有→1セルを回答という手順を始めます。

history_conversation = [
    {"role": "user", "content": rule_prompt},
    {"role": "assistant", "content": PREFILLED_ASSISTANT_RESPONSE}
]

絵にするとこんな感じの事前会話です。

事前会話イメージ

SmolagentsとOpenAI Agents Frameworkは、このような過去の会話を捏造することが出来なさそうでした。さらに、SmolagentsはSystemPromptをデフォルトから修正することが公式で非推奨となっています。
（従って、SmolagentsとOpenAI Agents Frameworkは他のフレームワークとは若干異なる入力となっています。）

なかなかのテクニックな気はしますが、過去の会話を捏造する必要があるタスクの場合はこれらのフレームワークは選択肢から外す必要があると思います。

4.5 Sudoku-Benchまとめ

数学的推論では、Smolagentsのみ大きく性能を落とす結果となりました。
また、マルチターン形式ではSmolagentsとAutoGenは他よりも顕著に利用トークン数が増加します。

使用面では、SmolagentsとOpenAI Agents Frameworkは過去の会話の捏造ができないという制約があることがわかりました。

これらを踏まえると、比較的簡単な数学的推論を含むタスクでの最初の選択肢はクセの少ないLangGraph, PydanticAI, Agnoあたりが好ましいと考えられます。

5. まとめ

今回は主要なエージェント用フレームワークでの性能比較をTravel Planner, Sudoku-Benchという2種類の推論能力を測定するベンチマークテストで行いました。結果は以下のような感じでした。

  • LangGraph, PydanticAI, Agnoはクセが少なく、まずこの辺りを検討。 (過去会話の捏造が不要であればOpenAI Agents SDKも初期候補に含む)

  • AutoGenは追加要素を持ちトークン数は増えるが、タスクによっては性能が向上する。

  • Smolagentsは追加要素を持ちトークン数が大幅に増えるため、マルチターンや簡単なタスクでは採用すべきではない。一方で、難易度の高い言語的推論タスクでは高い性能が得られる可能性がある。（公式の実装通り、Deep Researchなどには良いかもしれない。）

可能であればGPT-4.1以外のモデルでも試してみたいですが、結構API利用料がかかるのでやらないかもしれません。

議論や感想があればNoteやX(Twitter)でコメント・ご教示いただけると助かります。
X: https://twitter.com/CurveWeb

目を通していただきありがとうございました。
検証に使ったコードは以下に格納してあります。よければご参照ください。今回の検証でフレームワーク毎の実装方法の違い等も確認できて勉強になりました。

Appedix

Travel Plannerの具体的なスコアは以下の通り。

Travel Planner結果表

Sudoku-Benchの具体的なスコアは以下の通り。

Sudoku-Bench結果表

参照


いいなと思ったら応援しよう！

はち いただいたサポートは記事のためのAPI費用として役立てようと思います！