agent 評価システム 2026 — Inspect AI・Promptfoo・Phoenix・LangSmith・OpenAI Evals 徹底比較（モデルではなく agent を測る）

プロローグ — 「うまく動いています」は評価ではない

2026 年、どのチームでも一度は起きる会話。

PM: 「agent はどう？」 エンジニア: 「うまく動いてます。デモしますか？」 PM: 「先週より良くなった？」 エンジニア: 「うーん…体感では。」

これが 2026 年でも普通の光景だ。agent は作れるが、agent が実際にどれくらいうまく動くかを数字で言えない。モデル会社は MMLU・GPQA・SWE-bench を毎月更新しているのに、自分たちの agent については vibe check しかない。

問題の根っこは、agent 評価が LLM 評価と別の問題であること。LLM 評価は「このモデルがこの入力でどんな出力を出すか」を測る。agent 評価は「このモデル + harness + tool がこの作業を最後まで完遂するか」を測る。後者は非決定的で、多段階で、環境依存だ。一発のベンチマークで終わる話ではない。

この記事は 2026 年の agent 評価システムの地図を描く。Inspect AI（UK AISI）、Promptfoo、Arize Phoenix、LangSmith、OpenAI Evals、Braintrust、Helicone、Langfuse — それぞれの位置と、eval の分類学と、最初の agent eval suite をどう組むかまで。

1 章 · モデル eval vs agent eval — 別の問題

まずは用語から。両者は混同されがちだが、別の問題だ。

核心: モデルはコモディティ化していく。差別化は agent システムから生まれる。 そして agent システムは自分たちが責任を持つ。モデル会社が SWE-bench を上げても、自分たちのドメインでチケットがうまく処理されるとは限らない。自分たちのドメインで動くかは、自分たちが測る。

もう一点: agent 評価は harness 評価でもある。同じモデル + 違う harness = 違う結果。だから「モデル比較」は harness を固定したときに意味があり、「harness 比較」はモデルを固定したときに意味がある。どちらも評価インフラが下支えしないと成立しない。

2 章 · eval の分類学 — 何を測れるのか

agent eval を組むとき最初の問いは「何を測るのか」だ。よく使う 6 軸。

1) 決定論的 eval（deterministic）

ゴールデンテストセット。入力 → 期待出力。比較は機械的（完全一致・正規表現・構造比較・コードを実行して結果を比較）。

• 長所: 速く、安く、再現可能。
• 短所: 自由形式テキストに弱い、構築コストが高い。
• いつ: 分類・抽出・計算・コード生成 — 「正解」が存在するとき。

2) LLM-as-judge

別の（多くは強い）モデルが、prompt にルーブリックを渡して出力の品質を採点する。

• 長所: 自由形式出力を採点できる、スケールが速い。
• 短所: 採点者バイアス（positional bias・verbosity bias・自己選好）、コスト、採点モデル更新時のスコア drift。
• いつ: 要約・説明・創作 — 評価軸が定性的なとき。

3) Human eval

人が直接採点。多くはペア比較（A vs B）か 1〜5 のスケール。

• 長所: 真値に最も近い。
• 短所: 遅く、高く、一貫性の確保が難しい。
• いつ: モデル/harness の大変更の最終検証、LLM-as-judge の校正。

4) Task-completion（作業完遂）

agent が作業を終えたか — 二値結果。SWE-bench の「テストが通るか」、WebArena の「目的状態に到達したか」など。

• 長所: 最も意味のあるシグナル — 実際に動くのか。
• 短所: 環境構築コスト、部分点の与えづらさ。

5) Trajectory eval（過程の評価）

終えたかどうかだけでなく、どう終えたか。tool 呼び出しの順序、論理の流れ、途中の推論。

• 長所: 運で終えたケースと本当にできたケースを区別できる。
• 短所: 採点ルーブリックそのものが難しい。

6) Efficiency eval

同じ作業をより少ない資源で終えたか。ステップ数・トークン量・実行時間・tool 呼び出し数・コスト。

• 長所: production のコスト/遅延に直結。
• 短所: 作業難度と絡む — 難しい作業はステップが多いのが普通。

実務の組み合わせ: task-completion（二値）+ trajectory（サンプリング）+ efficiency（連続）。LLM-as-judge は自由形式出力に限定、human は会回帰の最終ゲートに限定。一軸だけ見ると必ず騙される。

3 章 · Inspect AI — 事実上の gold standard

Inspect AI は UK AI Safety Institute（AISI）が作った OSS フレームワーク。2024 年 5 月公開。2026 年現在、agent safety eval の事実上の標準になっている。Apollo Research・METR・Anthropic・OpenAI といった frontier lab が Inspect ベースで risk evaluation を公表している。

加速の理由:

• agentic eval を最初から想定 — tool 使用・多段階・sandbox 環境が一級市民。
• Python 一級 — task・solver・scorer デコレータで構成。
• 再現可能なログ — 評価 1 回 = 直列化されたログ 1 ファイルにスコアと trajectory の両方が残る。
• AISI 由来 — 政府機関が作っているという出自が、ガバナンス・政策の文脈で決定的に効く。

典型的な Inspect task:

from inspect_ai import Task, task
from inspect_ai.dataset import Sample
from inspect_ai.scorer import includes
from inspect_ai.solver import generate, use_tools
from inspect_ai.tool import bash, python

@task
def ctf_challenge():
    return Task(
        dataset=[
            Sample(
                input="Find the flag in /flag.txt",
                target="flag{example}",
            ),
        ],
        solver=[
            use_tools([bash(), python()]),
            generate(),
        ],
        scorer=includes(),
        sandbox="docker",
    )

これを inspect eval ctf_challenge.py --model anthropic/claude-3-7-sonnet で実行すれば終わり。採点・ログ・trajectory が 1 ファイルに落ちる。Inspect View という web UI も付いてきて、同じ作業で agent がどの tool をどの順で呼んだかを視覚的に追える。

2026 年に Inspect を使うシナリオ:

• モデル safety eval — Anthropic/OpenAI などの frontier lab が外部評価に Inspect を採用。
• AISI 公式評価 — 英国政府のモデル事前評価が Inspect 上で動く。
• 研究機関の agentic 能力測定 — SWE-bench・CTF・biosecurity・自律性の評価が Inspect 形式に集まる流れ。

短所: 学習曲線がある。デコレータ・solver・scorer モデルを覚える必要がある。そして「production app の日次回帰」より「厳密な評価キャンペーン」のほうが筋がいい。

4 章 · Promptfoo — OSS、CLI 一級

Promptfoo は OSS で、CLI を一級として扱う。YAML 1 ファイルに「prompt・テストケース・assertion」を書き、promptfoo eval を打つ。結果は表で出て、web viewer で見られる。

典型的な設定:

description: "顧客サポート agent の回帰"
providers:
  - id: anthropic:messages:claude-3-7-sonnet
  - id: openai:gpt-4o
prompts:
  - file://prompts/support_agent.txt
tests:
  - vars:
      ticket: "返金してほしい"
    assert:
      - type: contains
        value: "返金ポリシー"
      - type: llm-rubric
        value: "共感的なトーンでポリシーの上限を明示"
      - type: latency
        threshold: 4000
  - vars:
      ticket: "パスワードを再設定したい"
    assert:
      - type: javascript
        value: "output.includes('reset_link')"

魅力ポイント:

• 入口の速さ — CLI 一本、YAML 一枚。
• provider 多様性 — OpenAI・Anthropic・Bedrock・local model を同じ interface で。
• assertion の種類が豊富 — 完全一致・正規表現・LLM-rubric・JavaScript・Python・外部ツール。
• CI フレンドリー — 終了コードと JSON 結果で GitHub Actions に自然に入る。
• red-teaming 機能 — promptfoo redteam で jailbreak/PII 漏洩テストを自動生成。

2026 年に入って Promptfoo は単なる prompt-eval から agent 評価へ守備範囲を広げた。tool-calling 対応、multi-turn シナリオ、「agent simulator」（ユーザー応答を LLM に演じさせる）モードまで。ただし「agent 実行を直接 orchestrate」する筋は Inspect AI のほうが強い。Promptfoo は「prompt と応答を表で並べる比較」で最も輝く。

いつ Promptfoo: 速い回帰スイート、モデル A/B 比較、CI で毎日回す検証。

5 章 · Arize Phoenix — OSS observability + eval

Arize Phoenix は LLM/agent の tracing + eval を OpenTelemetry ベースで統合した OSS。Arize AI が OSS として公開、OpenInference という GenAI 専用の trace 仕様も併せて推進している。

核となる発想: agent は分散システムだ — APM のように trace してデバッグせよ。 一つの作業の trace には LLM 呼び出し、tool 呼び出し、retrieval、sub-agent 呼び出しが木構造で入る。Phoenix はこの trace を捕まえ、その上で evaluator（LLM-as-judge・regex・custom）を回す。

from phoenix.evals import (
    HallucinationEvaluator,
    RelevanceEvaluator,
    run_evals,
)
import pandas as pd

df = pd.DataFrame({
    "input": ["返金ポリシーは？"],
    "reference": ["30 日以内の返金可"],
    "output": ["30 日以内なら返金可能です"],
})

hallucination = HallucinationEvaluator(model="gpt-4o")
relevance = RelevanceEvaluator(model="gpt-4o")

results = run_evals(
    dataframe=df,
    evaluators=[hallucination, relevance],
    provide_explanation=True,
)

魅力ポイント:

• trace そのものが eval の入力 — production の trace の上で直接 eval を回せる。
• OpenInference 標準 — ベンダーロックインなし。LangChain・LlamaIndex・Haystack の自動計装。
• self-host — phoenix serve 一行、もしくはコンテナ。
• RAG 評価が内蔵 — relevance・hallucination・QA correctness の evaluator が箱出し。

いつ Phoenix: RAG/agent の production observability が必要で、「production trace の上に eval を乗せる」筋に合うとき。self-host 志向。

6 章 · LangSmith — LangChain の hosted

LangSmith は LangChain Inc. の hosted な tracing/eval プラットフォーム。LangChain・LangGraph に最も滑らかに繋がるが、SDK 経由で他フレームワークの trace も受けられる。

機能セット:

• trace UI — 多段階の agent 実行を tree/timeline/message ビューで。
• dataset 管理 — production の興味深い trace を dataset に昇格。
• eval runner — dataset 上で LLM-as-judge や custom evaluator を実行。
• A/B 実験 — 違う prompt/モデル/chain を同じ dataset で比較。
• prompt hub — prompt のバージョン管理。

2026 年に入って LangSmith は「LangChain 専用」のイメージを意図的に脱しようとしており、SDK 経由の任意 trace 取り込み、HTTP API、OTel 互換を強化している。LangGraph ユーザーには事実上の標準。

いつ LangSmith: LangChain/LangGraph スタック、hosted を好む、dataset → 実験 → production モニタリングを一つに束ねたいとき。

短所: SaaS の単価、データガバナンス制約（特に規制業界）、LangChain 依存が（一部利用者には）負担。

7 章 · OpenAI Evals — 元祖

OpenAI Evals は 2023 年 3 月に OpenAI が公開した OSS eval フレームワーク。「agent eval」という言葉が一般化する前から存在する。YAML で eval を宣言し、OpenAI モデルの上で回す筋。

2024〜2025 年は後発の Promptfoo・Inspect AI のほうが速く進化したが、OpenAI Evals は今も OpenAI 自身のモデル評価に使われており、GitHub に公開されたケースが広いため「他人がどんな eval を書いているか」のリファレンス置き場として機能する。

2026 年の OpenAI Evals の立ち位置:

• OpenAI モデル利用者にとっても 第一選択ではなくなった — いまは Promptfoo・Inspect が普通。
• 価値は リファレンス集 — 100 を超える eval 定義が公開。
• OpenAI Platform Evals（web コンソール上の hosted UI）は別物 — CLI/SDK の Evals とは別系。

いつ OpenAI Evals: OpenAI モデル中心で、既存の公開 eval を再利用したいとき。新規プロジェクトであえてここから始める理由は薄くなった。

8 章 · 残り — Braintrust・Helicone・Langfuse

Braintrust — 有料 SaaS、eval/モニタリング/playground を統合した UX に強み。dataset → 実験 → production 回帰のループが速い。dataset の diff・side-by-side・自動回帰検出が磨かれている。AI ネイティブ系のスタートアップに採用が多い。

Helicone — OSS + hosted。「LLM API gateway」として始まった — 全モデル呼び出しを proxy で受けてキャッシュ・rate-limit・ロギング・コスト追跡。そこに eval 機能を後付けした。trace より request/response モニタリングに近い筋。

Langfuse — OSS、trace + eval + prompt 管理。Phoenix・LangSmith に近いが OSS first + self-hosting が第一の deployment モデル。Europe 拠点のチームに採用が多い（GDPR フレンドリー）。

この 3 つは「agent 評価」を中心価値に押し出してはいないが、いずれも production の trace を取り、その上で eval を回せる。 どれを選ぶかは「すでにどんな observability を使っているか」と「self-host か SaaS か」で大半が決まる。

フレームワーク比較マトリクス

9 章 · 最初の agent eval suite を作る — 7 ステップ

理論はおしまい。自分たちの agent に eval を初めて付けるやり方。

1) 作業定義 — 「成功」とは何かを 1 文で

最もよく抜ける段階。「顧客サポート agent」は作業ではない。「返金リクエストのチケットを受け、ポリシー準拠の判断とユーザーへの返信を生成 — 判断は 4 択、返信は自由形式」 — これが作業。入力形式・出力形式・成功の定義を明文化する。

2) ゴールデン dataset 30〜100 件

production トラフィックがあればそこから抽出、なければ手書きで作る。多様性（易・中・難・edge）が量より重要。ラベル付けが高ければ 50 件で始めても良い。

dataset 1 件の最小構造:

• 入力（作業仕様 + コンテキスト）
• 期待結果（reference か採点ルーブリック）
• メタデータ（難度・カテゴリ・タグ）

3) 採点関数 — 二値の task-completion から

最もシンプルな採点から始める: 成功/失敗。二値。部分点は後で。「テストが通るか」または「JSON 出力が schema に合い、判断フィールドが reference と一致するか」など。

4) 一度回してベースライン

現在のシステムを dataset に回す。スコアはたいてい最初の予想より低い。それが普通。この数字が出発点だ。

5) trajectory と efficiency を添える

二値スコアだけ見ると「運で終えたケース」を逃す。だから trajectory（tool 呼び出し列）をサンプリングして眺め、平均ステップ・トークン・コストも一緒に記録する。回帰時にこれらが連動して動くかを見る。

6) CI に組み込む

eval を CI に組む。PR が開いたら dataset から 30〜50 件を回し、表を comment に貼る。回帰が見えたら merge をブロック。 コストの関係でフルセットは nightly、PR は速い subset で。

7) production trace で dataset を育てる

production の興味深いケース（失敗・低スコア・苦情）を捕まえて dataset に追加する。1 ヶ月でゴールデンセットが倍になる。eval は作り捨てではない — 生きて動く。

アンチパターン

• ベンチを 1 回回して終わり — eval は回帰ツール。
• LLM-as-judge 1 つで全採点 — 採点者の drift とバイアスが全シグナルを汚染。
• CI に組み込まない — 誰も見ない。
• dataset が production を反映しない — 通っても production で壊れる。

10 章 · 実例

事例 1 — SWE-bench Verified を agent eval として

SWE-bench は最初「coding 能力ベンチマーク」だったが、2024 年に OpenAI が選別した SWE-bench Verified（検証済み 500 タスク）は実質 agent eval だ — モデル単独では解けず、モデル + harness + tool が必要。

leaderboard を見ると、同じモデルが harness 違い（SWE-agent・Aider・Claude Code・Devin）で違うスコアを取る。これが agent 評価そのもの。2026 年初頭時点で上位は正答率 60〜70%台 — 1 年前の 30%台から倍。そしてその向上の相当部分が モデルではなく harness 側から来た。

実務的含意: 自分たちのチームも harness を固定してモデルを変える と モデルを固定して harness を変える の両方を測れる必要がある。

事例 2 — Anthropic の Inspect ベース事前 safety eval

Anthropic は新モデルのリリース前に Responsible Scaling Policy（RSP）に基づき事前評価を行う。その相当部分が Inspect AI 形式で書かれている — 外部評価者（METR・Apollo・AISI）が同じ評価を再現できるように。

典型的な評価カテゴリ:

• 自律性（autonomous replication・long-horizon agentic タスク）
• サイバー（CTF チャレンジ）
• 生物関連（専門知識・合成経路）
• モデルの欺瞞（deception）

それぞれが Inspect の task で表現され、結果は trajectory とログを保ったまま公開される。再現性がガバナンスの核で、Inspect の直列化ログがそれを可能にする。

事例 3 — production agent の daily eval

仮想的（だがよくある）シナリオ。顧客サポート agent を production で運用するチーム。

• 毎晩: 200 件のゴールデン dataset + 50 件の production サンプルで eval（Promptfoo）。
• 回帰検出時に Slack 通知。
• 週次: production trace 100 件を人が直接採点、LLM-as-judge との相関を確認。
• 月次: dataset 更新 — production で新たに見つけた失敗 30 件を追加。
• 四半期: モデル/harness 変更キャンペーン — フルセット + human eval 30 件 + コスト/遅延の回帰確認。

この 4 ループが揃うと、「体感では良くなったと思います」が消える。

11 章 · 再現性の問題 — 非決定的 agent をどう測るか

agent 評価で最も難しいのが 再現性。モデルは temperature でほぼ決定的にできるが、agent はそうはいかない。

非決定性の発生源:

• モデル sampling（temperature・top-p）。
• tool 副作用（現在時刻・外部 API・ファイルシステム状態）。
• 並行性（並列 tool 呼び出しの順序）。
• 外部サービス（検索 index の変化）。

緩和策:

• 複数 seed で平均 — 同じ入力を N 回（多くは 3〜5 回）回し、平均と分散を一緒に見る。単一実行のスコアは noise に騙される。
• 環境を固定 — Docker/sandbox で tool 環境を固定。Inspect AI が初日から sandbox を一級にした理由。
• 時刻を固定 — date などの tool を mock して固定時刻を返す。
• 外部依存を減らす — 評価実行では外部 API を mock またはキャッシュ。
• trajectory の分布 — 同じ入力で trajectory がどれだけ散るか自体がシグナル。散らばりが大きければ別の軸（temperature を下げる・seed を増やす）が必要。

核となる心構え: agent のスコアはスコアではなく分布だ。 単一の数字は嘘をつく。

12 章 · 評価すべきでない時

忘れがち: eval はタダではない。評価のコストが価値を上回ることがある。

• システムが速く変わりすぎる — prompt が毎週変わり dataset も追いかけるなら、ゴールデンセットの構築コストが回収されない。この段階では vibe check + 5〜10 個の単体テストで十分。
• 使用量が少なすぎる — 1 日 10 件の agent に 200 件 dataset は過剰なインフラ。
• 「成功」の定義が固まっていない — 作業定義が揺れる段階の評価は偽の安定感を与える。定義を固めるのが先。
• 人のほうが速い — 小さな dataset で頻繁に回らない評価なら、人が 5 分で手で見るほうが正確。

eval は 回帰と比較が必要なシステムに価値がある。「作って終わり」のプロトタイプには過剰。だから最初の問いは常に同じだ: このシステムをどれくらいの頻度で変えるか？ その変更の影響をどう知るか？ 答えがなければ、まず eval を作る必要はない。

13 章 · ツール選び — 1 行ガイド

• すでに LangGraph 使用 → LangSmith。摩擦が最も少ない。
• OSS 優先、agentic 評価を真面目に → Inspect AI。
• CI に速く回帰スイートを付けたい → Promptfoo。
• production trace の上に eval、self-host → Arize Phoenix または Langfuse。
• prompt 回帰が主で SaaS UX が欲しい → Braintrust。
• コスト/リクエスト監視先行 → Helicone。
• safety/ガバナンス eval、外部再現が必須 → Inspect AI。
• 複数ツール併用 — よくある。trace 収集（Phoenix/Langfuse）+ CI 回帰（Promptfoo）+ safety キャンペーン（Inspect） — これが 2026 年の現実によくあるスタック。

エピローグ — 測れるものが、改善できるもの

この記事の 1 文要約: モデルではなく agent を測れ。そして 1 回ではなく毎日測れ。

2024 年の AI engineering は「どのモデルが賢いか」だった。2026 年の AI engineering は「自分たちのドメインで自分たちの agent がどれくらいうまく動くか」だ。モデルはどんどん似てくる。差は そのモデルの上にどんなシステムを作るかから生まれ、そのシステムは自分たちの責任だ。

eval はその責任のツールだ。スコアが毎日見えれば、「うまく動いてます」の代わりに「今週の回帰 0.7%、平均 trajectory ステップ 4.2 → 3.9」と答えられる。PM の次の質問が変わり、優先順位が変わり、何を直して何を残すかが変わる。

次の 10 年の AI engineering は、モデルではなく システム engineering だ。そしてシステム engineering の最初のツールは測定だ。

12 項目チェックリスト

1. 作業の定義が明文化されているか（入力・出力・成功基準）？
2. ゴールデン dataset があるか（最低 30〜50 件）？
3. dataset は production を反映しているか（難度分布）？
4. 採点は task-completion（二値）から始めたか？
5. trajectory をサンプリングして眺めているか？
6. efficiency（ステップ・トークン・コスト）も併記しているか？
7. eval は CI に組まれているか？
8. PR ごとに回帰が自動検出されるか？
9. production trace から dataset を育てるループがあるか？
10. 非決定性を複数 seed で扱っているか？
11. LLM-as-judge に頼るなら human eval で校正しているか？
12. 評価ツールは self-host 可能か（または SaaS の選択に納得しているか）？

アンチパターン 10

1. eval なしで「うまく動いてます」 — 測定なしに改善なし。
2. ベンチを 1 回回して終わり — eval は回帰ツール。
3. LLM-as-judge 1 つで全採点 — バイアスと drift。
4. dataset が production を反映しない — ローカル通過、production で破綻。
5. trajectory を見ない — 運で成功したケースを逃す。
6. cost/latency を測らない — production でコスト爆発。
7. 単一 seed のスコアを信じる — noise をシグナルと取り違える。
8. eval が CI にない — 回帰が production に届く。
9. モデル変更だけ評価、prompt/harness 変更は評価しない — 一番大きな変更軸を逃す。
10. 「agent eval = モデル eval」と混同 — 別の問題。

次の記事の予告

候補: LLM-as-judge を深掘り — 採点者バイアスと校正、production trace から eval dataset を作る — 流れとツール、agent 回帰アラート — Slack/PagerDuty との接続。

「測れないものは改善できない。そして agent はモデルではなく、システムだ。システムを測れ。」

— agent 評価システム 2026、終わり。

参考 / References

• Inspect AI — UK AI Security Institute
• Inspect AI GitHub — UKGovernmentBEIS/inspect_ai
• Inspect AI Documentation
• Promptfoo — Open-source LLM eval
• Promptfoo GitHub — promptfoo/promptfoo
• Promptfoo Red Teaming
• Arize Phoenix — OSS observability
• Phoenix GitHub — Arize-ai/phoenix
• OpenInference — trace spec
• LangSmith — LangChain Inc.
• LangSmith Documentation
• OpenAI Evals GitHub — openai/evals
• OpenAI Platform — Evals
• Braintrust — eval/observability SaaS
• Helicone — LLM observability/gateway
• Langfuse — OSS LLM engineering
• Langfuse GitHub — langfuse/langfuse
• SWE-bench Verified — OpenAI announcement
• SWE-bench leaderboard
• Anthropic — Responsible Scaling Policy
• METR — Model evaluations
• Apollo Research
• WebArena benchmark
• OSWorld benchmark
• tau-bench — Sierra AI