こんにちは！Algomatic ネオセールスカンパニーで営業AIエージェント 「アポドリ」を開発している只野です。
前回の投稿では、Cursorをはじめとしたコーディングエージェントの可能性についてご紹介しました。
私たちは、日々のちょっとした調べものから業務の自動化まで、あらゆる場面でAIの力を借りています。では、ソフトウェア開発の現場ではどうでしょうか？
SNSでは「AIでアプリを一晩で完成させた！」という話題も目にしますが、実際の開発現場では何が起きているのでしょう。
続きを読むOpenAI o3, Claude 3.7 Sonnet , Gemini 2.5 Proの評価と解釈[2025年4月版]
こんにちは。Algomatic AI Transformation(AX) のsergicalsix（@sergicalsix）です。
最近OpenAI の o3, o4-mini、Anthropic の Claude 3.7 Sonnet、Google の Gemini 2.5 Pro や Gemini 2.5 Flash など、次々と新しい大規模言語モデル（LLM）が登場しました。あまりのスピードに、最新動向を追い切れず困っている方も多いのではないでしょうか。
モデルを選ぶ際は、実際に触ってみた使用感や解きたい課題・利用環境を重視するのが理想です。しかし、すべてのモデルをあらゆるシナリオで試すのは現実的に難しいです。
そこで役立つのが公開ベンチマークのスコアです。自分で全モデルを試せなくても、共通データセットで測った成績をベースラインとして押さえておけば、おおまかな実力を比較できます。
本記事ではOpenAIからo3, o4-mini、ClaudeからはClaude 3.7 Sonnet、GoogleからGemini 2.5 Proで報告されているベンチマークの結果を整理し、結果から言えることや解釈などをまとめたいと思います。
余談ですが、関連記事として昨年Algomatic NEO(x) の宮脇（@catshun_）さんが「Claude 3.5 Sonnet の評価に関する備忘録」という記事をまとめられています。合わせてご確認ください。
おことわり
- 解釈や引用に誤りがありましたらご指摘いただけると幸いです。
- 本記事では詳細な解説を含みません。詳細な調査等は必ず参照元の論文等をご確認ください。
- プロダクト等の利用時は 必ずライセンスや利用規約を参照して下さい。
- 本記事の作成では一部 LLM を活用しています。
対象モデルとベンチマーク
今回はOpenAI o3、Claude 3.7 Sonnet、Gemini 2.5 Proのベンチマークのスコアを見ていきます。
取り扱うベンチマークはOpenAI o3、 Claude 3.7 Sonnet、Gemini 2.5 Proそれぞれの報告で2つ以上共通で紹介されている以下のデータセットとします。
- GPQA diamond(Rein et al., 2023)
- AIME 2024, AIME 2025(Mathematical Association of America)
- MMMU(Yue et al., 2024)
- Humanity's Last Exam(Phan et al., 2025)
- SWE-bench Verified(OpenAI, 2024)
- Aider polyglot(Aider, 2024)
- TAU-bench(Yau et al., 2024)
まずはベンチマークデータセットそれぞれについて簡単にまとめます。
知識・思考力
GPQA diamond(Rein et al., 2023)
GPQA (Graduate-Level Google-Proof Q&A) は、生物学・物理学・化学の分野で大学院レベルの難解な質問を集めたQ&Aベンチマークです。
全問題は専門家が作成した多肢選択式の質問であり、高度な専門知識と推論力が要求されます。 インターネット上に公開された答えがない「Google-proof」な問題が多く、モデルの科学分野における推論力や専門知識の応用力を測定できます。 人間の専門家でも正解率65%程度（明確なミスを除けば74%）、専門家でない人間がWeb検索を活用したとしても正答率は34%程度に留まり、容易には解けない難易度となっています。
2025年4月現在では人の専門家の最高スコア>LLMの最高スコアとなっています。
AIME 2024, AIME 2025(Mathematical Association of America)
AIME 2024, AIME 2025はAmerican Invitational Mathematics Examinationの問題を収集したベンチマークデータセットです。AIMEは米国の高校生向け数学競技試験であり、その問題は非常に難度が高いことで知られています。AIMEはLLMの数学的推論力と問題解決能力を評価を目的とします。
MMMU(Yue et al., 2024)
MMMU(Massive Multimodal Multidiscipline Understanding)は、テキストと画像が混在する大学レベルの問題を多数集め、マルチモーダルな知識理解と推論力を包括的に評価するベンチマークです。
MMMUの目的は、視覚情報とテキストの統合処理能力や専門知識に基づいて推論するという高度な知能を測ることにあります。
また余談ですが、直近で日本語版のMMMUであるJMMMU(Onohara et al., 2025)が発表されています。
Humanity's Last Exam(Phan et al., 2025)
Humanity’s Last Exam (HLE) は、人類の知識や能力のフロンティアを問う一問一答形式のベンチマークデータセットです。数学・人文・自然科学など対象範囲は多岐に渡ります。 2025年4月現在で最も難しいベンチマークデータセットの一つであり、LLMの精度が飽和気味であるGPQAやAIMEなどとは対照的にLLMのスコアに大きな伸び代があります。
Humanity’s Last Examは精度(Accuracy)とキャリブレーションエラーで評価されます。キャリブレーションエラーとは、モデルが出力した各回答に対する「正解の確信度（Confidence, 0%~100%）」と実際の正答率とのズレで計算されます。 キャリブレーションエラーが大きいほど、モデルが自らの限界を正しく認識できずに誤った情報を出力してしまうリスクが上がります。
Humanity's Last Examの最新リーダーボードは以下です。
コーディング能力
SWE-bench Verified(OpenAI, 2024)
SWE-bench Verifiedは2024年にOpenAIが提案したベンチマークデータセットであり、主にコーディング能力を確かめるために使われています。 2025年4月現在では「ソフトウェアエンジニアリングにおけるAI能力」を測る代表的指標として広く認知されています。
データセットはPythonプロジェクトから収集したIssueとそれを解決したPull Requestのペアで構成されており、ユニットテストが解決するかどうかで正否が判定されます。
SWE-bench VerifiedはSWE-bench(E. Jimenez et al., 2023)の改良版であり、SWE-benchのデータ2,294件から解決可能と判断された500件で構成されてます。 ただSWE-bench Verifiedですら一部のテストは依存ライブラリのバージョンや OS 差異でそもそもパスしない場合があると主張*1されていることもあり、報告されているスコアがscaffoldingありかなしかを確認する必要があります。
SWE-benchの最新リーダーボードは以下です。*2
Aider polyglot(Aider, 2024)
Aider polyglotはコード編集タスクのベンチマークで、複数のプログラミング言語(C++、Go、Java、JavaScript、Python、Rust)の課題に対するモデルの対応力を評価します。 既存のコードベースに対して指示どおりの変更を加え、テストを通過するコードを作れるかを試すものです。
モデルには指示に対する理解力の他、コードの文脈理解、言語仕様の知識、さらにバグを検出し修正する反復的な思考力・対応力が求められます。 またSWE-benchと異なり、複数プログラミング言語に対応するため、各言語特有の構文・標準ライブラリを使い分けるマルチリンガルなコーディング能力も試されています。*3
Aider polyglotの評価形式には、コード全体を書き換えるwhole形式と特定の箇所のみに変更を加えるdiff形式があり、多くのモデルにおいてwhole形式の方が精度が高い傾向があります。*4
Aider polyglotの最新リーダーボードは以下です。
ツール利活用
TAU-bench(Yau et al., 2024)
TAU-benchは現実世界のユーザ(User)とAIエージェント(Agent)の対話をシミュレートし、ツール(Tool)使用を伴う複雑なタスク達成能力を評価するデータセットです。TAUはツール(Tool)、エージェント(Agent)、ユーザ(User)も頭文字から取られています。
TAU-benchには航空券予約の変更等のAirlineタスクや小売サイトでの注文キャンセルなどのRetailタスクといった実務的な対話タスクが含まれています。
エージェントはデータベース、各種APIにアクセスすることでタスクを遂行します。
ベンチマークデータセットのスコアと解釈
OpenAI o3、Claude 3.7 Sonnet , Gemini 2.5 Proのベンチマークデータセットのスコアは以下です。
表1: 各モデルのベンチマークスコア
| ベンチマーク | o3 | Claude 3.7 Sonnet | Gemini 2.5 Pro | 備考 |
|---|---|---|---|---|
| GPQA diamond | 83.3% | 78.2% | 84.0% | pass@1 |
| AIME 2024 | 91.6% | 61.3% | 92.0% | |
| AIME 2025 | 88.9% | 49.5% | 86.7% | |
| MMMU | 82.9% | 75.0% | 81.7% | single attempt |
| Humanity's Last Exam | 20.3% | 8.9% | 18.8% | |
| SWE-bench Verified | 69.1% | 62.3% | 63.8% | without scaffold |
| Aider polyglot | 81.3% | 64.9% | 74.0% | whole |
| TAU-bench (Retail) | 70.4% | 81.2% | --- | |
| TAU-bench (Airline) | 52.0% | 58.4% | --- |
注: TAU-bench除くツール未使用の結果を採用しています。それぞれの数値はOpenAI、Anthropic、Google公式から引用しています。一部のWebサイトで報告されている数値とは異なります。
モデルを比較すると論理的な推論能力はGPQA diamond、AIME、Humanity's Last Examの結果からo3 ≒ Gemini 2.5 Pro > Claude 3.7 Sonnet と解釈できます。論理的な推論能力という文脈をコーディングタスクまで拡張すると、SWE-bench VerifiedとAider polyglotから性能はo3 > Gemini 2.5 Pro > Claude 3.7 Sonnetと解釈できます。
またエージェンティックなツール利用という観点だとTAU-benchの結果から性能はClaude 3.7 Sonnet > o3と解釈できます。
上記解釈はベンチマークスコアから読み取れる解釈の一つですが、次にもう少し実践的なレベルで解釈を加えたいと思います。
例えばコーディングについては、大量のコードをプロンプトに入力する必要がある場合があります。例えばモノレポ構成で、機能開発を行う場合はフロントエンドとバックエンドのコードを両方をプロンプトに入れる必要があります。
このようにプロンプトが長くなった際の性能は、上記のベンチマークで厳密に測ることができないため、①ロングコンテキストのベンチマークのスコアとSWE-bench Verifiedの結果を組み合わせるか②ロングコンテキスト×コーディングのベンチマークデータセットを探してスコアを見る or スコアを測る必要があります。
コーディングはある程度複雑なタスクなので、単純なNeedle In A Haystack(Machlab and Battle, 2024)ではなく、ロングコンテキストの横断的な理解が必要なLongBench v2(Bai et al,. 2025)などの結果を参考にすると良いかなと思います。
そしてSWE-bench Verifiedなどの結果と組み合わせて解釈することで、より実務に近い(ここではロングコンテキストに対応した)コーディング性能が確認できます。 (一方でLongBench v2のリーダーボードには上記3モデルの結果はないため、各自で計測する必要があります。。)
また他のデータセットに比べて相対的に信憑性は高くないものの、小説の理解度を測るFiction.LiveBench(Fiction.live, 2025)の結果によれば、120kまでのコンテキスト長における性能はo3 > Gemini 2.5 Pro > Claude 3.7 Sonnetの順で高いです。
データセットの信憑性から、あくまで参考値ですが先ほどの結果と合わせて120kまでのコーディングの性能は、o3 > Gemini 2.5 Pro > Claude 3.7 Sonnetと解釈できます。*5
このように公式で発表されているベンチマークの結果よりも一歩踏み込んで解釈を行いたい場合は、複数のベンチマークの結果を組み合わせて解釈すると良いかなと思います。一方でベンチマークスコアの信憑性については注意深く確認する必要があります。
また200kを超えるコンテキストをプロンプトに入れる場合は、そもそもコンテキストウィンドドウの観点からGemini 2.5 Proしか取り扱うことができないため、モデルの基礎スペックを合わせて確認することが大切です。
表2: 各モデルのコンテキスト長
| o3 | Claude 3.7 Sonnet | Gemini 2.5 Pro |
|---|---|---|
| 128k | 200k | 1M |
さらに別の観点でコーディングタスクについて(a)ブラウザでの画面表示を確認する(b)コマンドを打つといった、ある種ツールを使う部分までをエージェントに任せたいと思った場合はSWE-bench VerifiedとAider polyglotの他に、ツール使用というTAU-benchの結果も無視できなくなるため、現状どのモデルが優れているかは、スコアだけでは判別しにくくなります。
このように任せたいタスクの種類や定義によって解釈の結果が異なるため、注意が必要です。
おわりに
OpenAI o3, Claude 3.7 Sonnet , Gemini 2.5 Proの評価と解釈と題して、2025年現在よく使われているベンチマークセットの紹介と結果を整理し、解釈をまとめました。
冒頭でも述べた通り、実際にモデルを使ってみた結果が最も有効であるものの、ベースラインとしてベンチマークデータセットの結果も確認すると良いのかなと思います。
Algomaticではあらゆる領域で生成AIネイティブな事業を生み出すために多様なスキルを持った仲間を探しています。
特に私が所属がしているAI Transformation(AX)カンパニーでは「AXで世界における日本のプレゼンスを高める」ことをミッションに生成AIを中心とした最新技術を取り扱っています。
ご興味がある方、カジュアル面談でお待ちしております！
*1:https://www.anthropic.com/news/claude-3-7-sonnet
*2:SWE-bench Verifiedの他にも、SWE-benchの軽量版のSWE-bench Liteやマルチモーダル対応されたSWE-bench Multimodalの結果も確認できます。
*3:厳密に記述するとSWE-benchに関しては、複数のプログラミング言語に対応したMulti-SWE-bench(Zan et al,. 2025)が提案されています。
*4:一方でGPT-4.1はdiffの方が精度が高いです。 https://openai.com/index/gpt-4-1/
*5:Fiction.LiveBenchはデータセットとその評価方法が公開されていないので、相対的に信憑性が低いです。
【Cursor】命令では物足りない!? “問いかけ”で引き出すAIの思考力
こんにちは!
Algomatic ネオセールスカンパニーで営業 AI エージェント 「アポドリ」 を開発している 只野 です。
以前、Vercel v0からReact+Hono環境への移行戦略──Cursor活用で進める段階的マイグレーション では、Cursorを活用していることをお伝えしました。
今回は、Cursorを使った開発体験をより良くするための「問いかけ型プロンプト」についてお話しします。
続きを読むDify最大の弱点と、その克服方法について
ネタバレ
- Dify 最大の弱点は「ワークフローの大量実行が難しい」ことです
- 私たちはこの問題をGoogle スプレッドシート + GAS で克服しました
- コピーしてすぐに使えるテンプレートを公開するので、ぜひ取り入れてみてください
テンプレートはこちら。 docs.google.com
はじめに
こんにちは、Algomatic ネオセールスカンパニーで営業 AI エージェント 「アポドリ」 を開発している 末國 です。
前回の記事では「アポドリは 1日1万回 の Dify 呼び出しで回っている」とお伝えしました。
今回の記事では、非エンジニアでも Dify を大量実行できるようにした、すぐに真似できるワークフローの全容を紹介します。
続きを読むアポドリを「プロダクションレディ」にするためにやったこと
こんにちは、Algomatic ネオセールスカンパニーCTOのきくちです。
AIエージェント、話題ですね。これまではPoCやR&Dレベルと思われていたAIエージェントですが、いよいよ本格的にサービスが提供されてきました。わたしたちが提供する「アポドリ」もその1つであり、すでに「プロダクションレディな品質」が求められています。
本記事では、わたしたちがアポドリという「営業AIエージェント」サービスを開発・運用する中で「プロダクションレディなAIエージェント」とするために取り組んだ工夫や、「もっとこうしたいんだよね」という伸びしろ部分も交え、実例をご紹介します。この記事によって、AIエージェント開発についてイメージを持てない方にも、AIエージェント開発の醍醐味や面白さが少しでも伝われば幸いです。
続きを読むAzure Functionsで30分でMCPサーバーを構築する
はじめに
こんにちは！Algomaticネオセールスカンパニーでソフトウェアエンジニアをしている越川と申します。
先日、Azure FunctionsがMCPに対応したとのニュースがありました。 techcommunity.microsoft.com
弊カンパニーではインフラ基盤にAzureを利用しており、MCP対応は非常にいいニュースだと思っています。
早速試してみたんですが、toolの定義自体は数十行のコードで完結するのでその記述量の少なさに感動しました。
app.mcpTool('getCompanyInfo', { toolName: TOOL_NAME, description: TOOL_DESCRIPTION, toolProperties: { corporateNumber: z.string().describe(CORPORATE_NUMBER_PROPERTY_DESCRIPTION) }, handler: getCompanyInfo });続きを読む
なぜ、Difyなのか
はじめに
こんにちは！Algomatic ネオセールスカンパニーでエンジニアをしている末國と申します。
私たちが1月にリリースした営業AIエージェント「アポドリ」では、一部機能にDifyを組み込んでいます。
一部といっても、すでに100個近いワークフローが作られていたり、1日1万回呼び出したりするくらいには利用しています。
Difyはいわゆるローコードツールであり、「コードが書けない人が使うもの」「DifyはPoCで使って、本番はプログラムを書く」という印象もあるかもしれません。
しかし、私たちはむしろ積極的に「コードからDifyへの移行」を行ってきました。
この記事では私たちが「なぜDifyを利用しているのか」「何がそんなにいいのか」について書いていきます。
続きを読む