AIの性能ベンチマーク｜仕事を最後までやり切る力を測る8つ（SWE-bench・Terminal-Bench・τ-bench）

「自分はコードを書かへんから、この回は関係ない」。そう思って離脱しそうになった人へ、先に言うとく。

この回でいちばん効くのは、コードの話やない。AIに文章を書かせたとき、指示をちゃんと守ってくれるかの話や。「400字以内で」「敬語で」「箇条書き3つで」と頼んだのに、なぜか守られへん。あの現象を測る試験が、ちゃんとこの回に出てくる。

第2回では、AIが「知っているか」「考えられるか」を扱った。この回は違う。作業を、最後まで崩さずにやり切れるかを測る8つの試験（HumanEval、SWE-bench、SWE-bench Verified、SWE-bench Pro、Terminal-Bench、BFCL、τ-bench、IFEval、AutomationBench、FrontierCode）を、同じ4行の型で開けていく。

「賢い」と「仕事が終わる」は、別の力や

第2回で扱った試験は、「知ってるか」「正しく推論できるか」を測るものやった。この回の試験は違う。作業を最後まで崩さずにやり切れるかを測る。

この2つは、同じモデルの中でも一致しません。知識も推論力も高いモデルが、長い作業の途中でルールを忘れたり、指示の一部を落としたりすることは普通に起こります。逆に、知識のクイズではそこまで目立たなくても、決められた手順を最後まで守り切るのが得意なモデルもいます。

「賢そうやから、仕事も丸ごと任せて大丈夫やろ」という判断は、この2つを混同したところから生まれる。この回は、その混同をほどくための8つや。

HumanEval｜1つの関数を書く164問

①HumanEvalは、Pythonのみを対象にした164問の試験です。関数のシグネチャと説明文（docstring）が渡され、その説明を読んで関数の本体を書きます。採点は生成したコードを実際に動かし、1問あたり平均7.7個のユニットテストを全通過したら正解です。OpenAIが2021年7月に発表しました。

問題文はすべて手書きで作られています。理由も論文に明記されていて、モデルがGitHubの大部分を学習データにしているため、既存の問題集をそのまま使うと、解答そのものが学習データに含まれてしまうからです。

②人間に例えると、新人プログラマーに「この説明どおりの、小さな関数を1つ書いて」と頼む小テストみたいなもんや。

③点数が高いモデルは、説明文から意図を正しく汲み取り、小さな部品を単体で正確に組み立てられるということになる。

④この点数が高くても、大きな仕事を任せて大丈夫、という意味やない。164問はどれも1つの関数の範囲に収まる話で、複数のファイルにまたがる作業や、既存のコードとの整合を取る作業は含まれてへん。ただ、AIに何か小さな作業を1つだけ頼むような場面（表計算の数式を1個作らせる、短い定型文を1つ生成させるなど）では、この力がそのまま活きる。

SWE-bench｜平均438,000行を渡される2,294件

①SWE-benchは、実在するGitHub Issueの本文と、リポジトリのスナップショット一式を渡し、そのIssueを解決するパッチを書かせる試験です。12のリポジトリ・Pythonのみを対象に、プリンストン大学などが2023年10月に発表し、ICLR 2024に採択されました。問題数は2,294件です。

渡されるコードベースの規模は、平均438,000行・3,010ファイルにのぼります。Issue本文は平均195語（最大4,477語）です。採点は、修正によって失敗から成功に変わるべきテスト（FAIL_TO_PASS）と、既存機能が壊れていないかを確認するテスト（PASS_TO_PASS、中央値51件）の両方を全通過して、初めて正解になります。部分点はありません。

②人間に例えると、新人エンジニアに「このバグ報告、直しといて」と頼むのに近い。ただし渡されるのは1つの関数やなく、438,000行のコードベースまるごとや。

③点数が高いモデルは、既にある大きなコードを読んで、原因を見つけて、直せるということになる。ここが、HumanEvalとの決定的な違いになる。「小テストで満点を取れる人が、会社の実際のバグを直せるとは限らへん」。この差が、そのまま438,000行という数字に表れとる。

④コードを書かない人には、点数そのものは関係が薄い。ただ、AIに作らせたプログラムの不具合を後から直してもらう、という場面には、この試験がそのまま効いてくる。

Verified と Pro で、何が変わるか

SWE-bench Verifiedは、OpenAIが2024年8月に発表した500件のバージョンです。オリジナルから1,699件をランダム抽出し、93名の経験あるPython開発者が人手レビューしました。3人が独立に0〜3の重大度を付け、最も重いラベルを採用する方式です。見つかった問題は、Issue記述が不十分なもの38.3%、テストが厳しすぎて正しい解答を落とすもの61.1%、開発環境の問題など。結果、オリジナルの68.3%が除外されました。難易度は15分未満／15分〜1時間／1〜4時間／4時間超の4段階で見積もられています。

SWE-bench Proは、Scale AIが2025年9月に発表した1,865件・41リポジトリのバージョンです。Python・JavaScript・TypeScript・Goを対象に、Public 11リポジトリ・Held-out 12リポジトリ（非公開）・Commercial 18（スタートアップの独自コード）の3分割で構成されています。汚染対策として、コピーレフト（GPL等）ライセンスのリポジトリを意図的に選んでいます。MIT・Apacheのような寛容ライセンスのコードは、事前学習コーパスに入りやすいためです。1〜10行の些細な修正は除外されていて、参照解答は平均107.4行・4.1ファイル、100問以上が100行を超えます。論文時点のスコアは、PublicでClaude Sonnet 4.5が43.6%、CommercialでClaude Opus 4.1が17.8%でした。

名前の後ろに何も付いていない「SWE-bench」と、「Verified」「Pro」の3つは、それぞれ中身も難易度も違う。数字を見るときは、どの版の話かを必ず確認する習慣をつけといたほうがええ。

Terminal-Bench｜パソコンを渡して、最後までやらせる

①Terminal-Benchは、スタンフォード大学とLaude Instituteが主導し、MIT・CMU・UC Berkeley含む43以上の組織が参加して作られた試験です。2.0版は89タスクで構成され、コミュニティ投稿229件から厳選されました（論文2026年1月）。各タスクは「指示文＋Dockerイメージ＋テスト群＋模範解答＋制限時間」の形で用意され、ターミナルで実際にコマンドを打ちながら、タスクを最後まで完遂させます。分野はソフトウェアエンジニアリングが最大で、ほかに動画処理、パーソナルアシスタント、暗号解析、ネットワーク設定、データ分析などが含まれます。1タスクあたり約3時間の査読工数がかけられ、不正な攻略手段（exploit）が使えないかまで確認されています。

②人間に例えると、パソコン1台を渡して「これ、最後まで自分でやっといて」と丸投げする試験になる。手取り足取りは、もうない。

③点数が高いモデルは、手順の長い作業を、途中で人の助けを借りずに最後までやり切れるということになる。熟練したエンジニアでも47.3%のタスクは1〜24時間かかると見積もられているほどの難易度です。それでもフロンティアモデルの正答率は、まだ65%に届いていない。

④コードを書かない人には直接関係が薄い。ただ、「複数の手順が絡む長い作業を、途中で放り出さずに最後までやれるか」という発想そのものは、日々の複雑な作業を任せるかどうかの判断材料になる。

BFCL｜正しい道具を、正しく使えるか

①BFCL（Berkeley Function Calling Leaderboard）は、UC Berkeleyが手がけるGorillaプロジェクトの試験です（論文はICML 2025）。論文時点で5,551件のquestion-function-answerペアがあり、Python・Java・JavaScript・REST API・SQLに対応しています。正しい関数を選び、正しい引数を作って呼べるかを、複数呼び出し・並列呼び出し・マルチターンを含めて採点します。採点はAST（構文木）照合、実際に関数を実行しての戻り値照合、マルチターンではバックエンドの状態照合、完全一致の4通りです。

②人間に例えると、いくつも並んだ道具の中から、いま必要な道具だけを選んで、正しい持ち方で使えるかを試す試験になる。

③この試験には、Irrelevance検出という重要な項目があります。ツールは与えられているが、呼ぶべきでない場面（必要な引数がない、適切な関数がない）では、呼ばないことを正解とする採点方式です。点数が高いモデルは、複数のツールを連携させたときに、余計な呼び出しをして暴走しにくいということになる。

④直接コードを書かない人には関係が薄い。ただ、AIに検索やカレンダー登録などの外部ツールを使わせている人にとっては、「いらんときに勝手に道具を使わへんか」がそのまま安心感につながる指標になる。

τ-bench｜話しながら、システムを操作する

①τ-bench（TAU＝Tool-Agent-User）は、Sierraが2024年6月に発表した試験です（ICLR 2025）。retail 115タスク（ユーザー500・商品50・注文1,000のデータベース）とairline 50タスクで構成されています。LLMがシミュレートする顧客と対話しながら、APIを呼び、業務ルール（社内規定）を守ってタスクを完遂させます。

②人間に例えると、電話サポートの窓口担当を、実際の顧客対応まで含めてAIにやらせる試験になる。

③採点は、会話の中身やなく、会話が終わった時点のデータベースの状態を、目標状態と比較して行われます。部分点はありません。「感じよく話せたか」やなく「注文が正しく変更されたか」で見る。仕事は結果で見られる、という当たり前が、そのまま試験の設計になっとる。

2025年6月にはτ²-bench（Dual-Control）が追加され、エージェントだけでなくユーザー側にもツールがある設定（電話サポートで顧客に端末操作を案内するイメージ、Telecom 114タスク）が加わりました。2026年3月のτ³-benchでは、非構造の社内ドキュメント698文書・21カテゴリ・約195Kトークンを検索させるτ-Knowledgeと、訛り・雑音・割り込みを含む音声評価τ-Voiceが追加されています。τ-Bankingはフロンティアモデルで約25%（該当文書を直接与えると40%）、τ-Voiceは音声26〜38%に対しテキストでは85%という水準です。

④直接コードを書かない人にも関係がある試験や。カスタマーサポートや予約対応をAIに任せたい人にとっては、この試験がいちばん実務に近い。

「たまにできる」と「毎回できる」は違う

τ-benchには、pass^kという独自指標があります。pass@k（k回の試行のうち1回でも成功すればカウント）とは逆に、k回の独立試行が全部成功する確率を測る指標です。

gpt-4oでも、retailのpass^8は25%未満でした。8回中1回でも成功すればいい基準やなく、8回続けて全部成功する確率でみると、この数字まで落ちる。「たまにできる」と「毎回できる」は、まったく別の話や。業務に組み込むなら、見るべきはこっちの数字になる。

IFEval｜賢さやなく、言うことを聞くか

①IFEvalは、Googleとイェール大学が2023年11月に発表した試験です。約541プロンプト・25種類の「検証可能な指示」を対象に、Keywords、Language、Length Constraints、Detectable Content、Detectable Format、Combination、Change Cases、Start with/End with、Punctuationの9群に分かれています。採点は完全な機械判定（LLMによる判定は使わない）で行われ、4つの指標のうちinstruction-levelは指示単位で数えるため部分点があります。

制約の実例はこうなる。

• 「400語より多く書け」
• 「カンマを一切使うな」
• 「マークダウンの箇条書きをちょうど3個にせよ」
• 「出力全体をJSON形式で包め」
• 「回答をすべて小文字にせよ」
• 「この語句で正確に終われ。余計な言葉を足すな」 ②人間に例えると、内容の正しさやなく「言われた形式を、そのまま守れているか」だけをチェックする試験になる。文章の質は関係ない。

③これ、AIに記事やSNS投稿を書かせている人が、毎日ぶつかっとることそのままや。「賢いはずやのに、字数を守らへん」「箇条書きの数が違う」の正体が、ここにある。GPT-4でも、prompt-level strictでは76.89%でした。4回に1回は、どこかの指示を落としているということになる。

④コードを一切書かない人にこそ、いちばん関係が深い試験や。AIに文章の分量や形式を指定して書かせている人は、この数字を思い出してほしい。守れないのは、あなたの指示が悪いからやなく、指示遵守そのものが、賢さとは別に鍛えられている能力やからや。

strict と loose の違い

IFEvalには、strictとlooseという2つの判定基準があります。looseは、マークダウン記号の除去、最初の行の除去、最後の行の除去とその組み合わせなど、8種類の変換をかけてから判定します。これは「実質は指示を守れているのに、前置きの一文があるせいで機械的に不正解にされてしまう」という偽陰性を減らすための工夫です。

同じIFEvalという名前でも、strictで見るかlooseで見るかで数字が変わります。数字を見るときは、どちらの基準かも確認しといたほうがええ。

AutomationBench｜業務そのものを、最後まで

①AutomationBenchは、Zapierが2026年4月に発表した試験です。公開600タスク（＋非公開セット）を、47のシミュレートSaaSアプリ・約500のAPIエンドポイントを使い、Sales・Marketing・Operations・Support・Finance・HRの6分野にまたがって実行させます。

させることは、コードを書くことやありません。使えるエンドポイントを自力で見つけ、相互に依存する複数の呼び出しを順に実行し、多層の業務ルールを守り、無関係・誤誘導のレコードが混じった環境を切り抜けることです。アプリをまたいだ調整も必要になります。採点は決定論的な最終状態アサーションで、LLMによる判定は使いません。主指標task_completed_correctlyは、全部通過して初めて1点になり、部分点は順位に反映されません。

②人間に例えると、複数の業務システムのログイン情報だけ渡されて、「この業務フロー、最後まで自分で回しといて」と言われる試験になる。

③点数が高いモデルは、複数の業務ツールをまたいで、ルールを一つも破らずに一連の作業をやり切れるということになる。Zapier公式リーダーボード（v1.0.6）では、Gemini 3.7 Flash (High)が30.44%で1位、Claude Opus 5 (Max)が26.94%、Claude Opus 5 (XHigh)が25.27%でした。

④コードを書かない人にこそ、いちばん本命の試験や。「業務をAIに丸ごと任せられるか」を測る試験がこれになる。1位でも30.44%という数字が、まだ人の確認が必要な段階であることを、正直に示しとる。

FrontierCode｜動くだけやなく、品質を見る

①FrontierCodeは、Devinの開発元であるCognitionが2026年6月8日に発表した試験です（1.1は2026年7月7日）。150タスク・36の主要OSSリポジトリ（Celery、Budibase、uppy、Mattermostなど）を対象に、20名以上のメンテナ本人が問題を作成しています。

②人間に例えると、実際にそのプロジェクトを運営している人が「これ、ちゃんとうちの基準で使えるレベルで直して」と依頼するのに近い。

③させることは、新機能の実装からリファクタリングまで幅広く、「正しく動く」だけやなく、プロダクション品質のコードかどうかまで見ます。採点はユニットテストとLLMによるルーブリック審査、研究者の手動レビューを組み合わせ、blocker基準でpass/failが決まったうえで、加重集計スコア（0〜100%）が出ます。1.1では、最難50問だったDiamondサブセットが廃止されました。解答率が低すぎてノイズが大きかったためです。

④直接コードを書かない人には関係が薄い。ただ「動けばOK」やなく「実際の現場基準を満たしているか」まで見るという発想は、AIの成果物をどこまで信用していいかを考えるときの、1つの物差しになる。

3行表の2列目を埋める

第1回・第2回で書き出した3つの仕事に、この回で出てきた指標を当てはめてみる。①長文の記事を書く仕事はIFEvalに効いた。②リサーチする仕事は、ツールを使わせるならBFCLに効いた。③作ったプログラムを直す仕事は、SWE-bench系・Terminal-Benchに効いた。

確認項目	AI大将の場合	あなたの場合
仕事① 長文の記事を書く	字数・構成・形式の指定を守ってほしい → IFEval	______
仕事② リサーチする	検索やツールを使わせるなら → BFCL	______
仕事③ 作ったプログラムを直す	既にあるものを読んで直す → SWE-bench系・Terminal-Bench	______

判定の目安はこうなる。書かせた文章の形が毎回崩れるなら、IFEvalを見て、strictとlooseのどちらの基準かも確認する。複数のツールを連携させたいなら、BFCL、特にIrrelevance検出を見る。業務そのものを丸ごと任せたいなら、AutomationBenchとτ-benchを見るが、1位でも30%台やから、まだ人の確認が要る。AIに作らせたプログラムを直してもらうなら、SWE-bench Verified（500件）を見る。オリジナルの2,294件とは数字が違う。

この群を見るときの落とし穴

• 名前の後ろを見ずに比べる：SWE-bench、Verified、Proはそれぞれ中身が違う。数字だけを並べて比較しない
• HumanEvalの高得点で実務を判断する：164問はどれも1つの関数の範囲。大きなコードベースを扱う力は測れていない
• pass@1とpass^kを混ぜる：「1回でも成功する確率」と「毎回成功する確率」はまったく別の数字
• IFEvalのstrictとlooseを混ぜる：判定基準が違えば、同じ試験でも数字が変わる この4つのどれかをやると、正しい数字を持っていても、間違った結論に着地してしまう。

よくある質問

Q. AIが文字数の指示を守らないのは、何の性能の問題ですか。 A. 知識量や推論力の問題ではなく、指示遵守という別の能力の問題です。この能力を測るのがIFEvalで、GPT-4のような高性能なモデルでも、prompt-level strictの正答率は76.89%にとどまります。

Q. HumanEvalで高得点なら、コードを任せて大丈夫ですか。 A. HumanEvalは1つの関数を書く164問の試験です。複数ファイルにまたがる修正や、既存コードとの整合を取る作業までは測れていません。実際の開発現場に近い作業を見たいなら、SWE-benchやSWE-bench Verifiedの数字を確認してください。

Q. SWE-benchとSWE-bench Verifiedは、どちらを見ればいいですか。 A. SWE-bench Verifiedのほうが、実務判断には適しています。オリジナルの2,294件には、Issue記述が不十分な問題や、テストが厳しすぎる問題が含まれていましたが、Verifiedはそれらを人手で除外した500件だからです。

Q. 業務をAIに丸ごと任せるのは、まだ早いですか。 A. AutomationBenchの1位でも30.44%という数字が、現状を示しています。業務ルールを一つも破らずに最後までやり切れる割合が3割程度ということで、丸ごと任せるより、人の確認を挟みながら使う段階です。

Q. 自分でコードを書かないのですが、この回は関係ありますか。 A. 関係があります。IFEvalは文章の指示遵守を測る試験で、記事やSNS投稿の分量・形式を指定して書かせている人に直結します。AutomationBenchやτ-benchも、業務ツールをAIに操作させたい人にとっての本命の指標です。

Q. pass@1とpass^kは何が違うのですか。 A. pass@1は1回の試行で成功したかを見る指標です。pass^kは、k回の独立した試行が全部成功する確率を見る指標で、τ-benchで使われています。「たまにできる」のか「毎回できる」のかという、違う問いに答える数字です。

次回は、資料と画像を読む力

この回では、賢さとやり切る力は別物やということを、8つの試験で見てきた。次回はまた視点が変わる。

第4回では、長い文書や画像、複数の資料をまたいで理解する力を測る指標を扱う。読む力もまた、知識とも、やり切る力とも別の能力になる。