Enterprise AIベンチマーク実験室

Enterprise AIの評価は、公開leaderboardの単一scoreやmodel単体の比較だけで受入可否を決めず、実際に使うmodel・prompt・retrieval・tools・permissions・runtime・agent scaffoldを含む System Under Test (SUT) を、再現可能なfixtureとversion固定したgraderで測る。agentでは最終結果だけでなく、tool call、retrieval/file access、state transition、edit、test、retryなど観測可能なtrajectoryを保存し、OUTCOME / EFFICIENCY / ARTIFACT QUALITY / PROCESS QUALITYを分離して評価する。trajectoryはchain-of-thoughtではなく、監査可能な外部挙動と成果物の証拠である。

公開benchmarkやleaderboardは有用なprobeだが、組織固有の業務、権限、データ境界、tool、cost ceiling、validation policyまで保証しない。受入判定は組織内fixtureとauthoritative readbackを持つ試験へ接続する。

EA-011は、長文保持、権限付き検索、引用精度、表計算、文書更新、コード修正、tool useなどを共通の評価契約で比較するためのTEVV基盤を扱う。

• SUT manifestとversion provenance
• task / fixture / trial / trace / outcome / graderの分離
• final outcomeとobservable trajectoryの多軸評価
• deterministic telemetryとsemantic judgeの分離
• failure stageの診断
• private fixture / holdout / contamination対策
• cost / latency / retry / tool usageの運用計測
• organization-specific acceptance threshold

EA-016はeval lifecycleやrelease gateを専門化し、EA-902/EA-961はtrajectory-level acceptanceおよびoutcome/trajectory/side-effectの専門論点を扱う。EA-011では共通fixture/SUT基盤を主題とする。

• JetBrains Junie, “From Leaderboards to Model Profiles: A Deep Dive Evaluation of LLMs for Agentic Coding”, 2026-08. Locator: https://blog.jetbrains.com/junie/2026/08/from-leaderboards-to-profiles/ — resolve rateだけでなくoutcome/processを分離し、execution efficiency、patch quality、process quality、failure stageを診断するmodel profileを提示。Junie scaffold依存であり、model一般の恒久的性格へ外挿しない。
• JetBrains Research, “The Benchmark Meaning Gap”, 2026-07. Locator: https://blog.jetbrains.com/research/2026/07/benchmark-meaning-gap/ — benchmark scoreを広い能力へ外挿するconstruct-validity問題、task type間のranking不安定性、単一scoreではなくperformance profileと多様なtask probeを使う必要性を支持。
• Jiawei He et al., “ProcBench: Evaluating Process-Level Defects and Control Preservation in LLM Coding Agents”, arXiv:2605.20251, 2026-05-18. Locator: https://arxiv.org/abs/2605.20251 — final outcomeだけではmulti-step agentのprocess defectを捉えにくいこと、trajectory representationとprocess-level scorecardの診断価値を独立研究として支持。annotation dependence、partial observability、外部妥当性は限界として残す。
• ＠IT / ITmedia, 2026-09-29, JetBrains報告の日本語解説。Locator: https://atmarkit.itmedia.co.jp/ait/spv/2609/29/news042.html — discovery/context source。新規claimの唯一根拠にはしない。
• Current continuation canonical research artifact: Google Doc 1XpjZC_R1eHlIckvUaEaJ_mcj6YW6j0ihZ0b91z5vewU, EA-011-REFRESH-20261006-R1 section. Base historical canonical: COMM-011-EA0011 / proposal lineage retained in EA_MASTER provenance.

同じmodelでもscaffoldやtool、permission、retrievalが変われば別SUTとして扱う。

private fixtureは万能golden setではない。version、coverage、criticality、provenanceを持つliving artifactとして更新する。

trace retentionはprivacy/security境界を持ち、secret、PII、不要なraw transcriptを無制限保存しない。

単一総合点へ潰さず、最低限次を別軸で保持する。

失敗を一括してFAILにせず、改善先を切り分ける。 - LOCALIZATION: 対象箇所・必要情報を特定できない - DIAGNOSIS: 原因や要求を誤る - IMPLEMENTATION: 修正・生成が不正 - VALIDATION: test/readbackを実施しない、または誤判定 - EFFECT: 外部副作用が期待状態と一致しない - GOVERNANCE: 権限・承認・policy・scope boundary違反 - HARNESS_OR_FIXTURE: SUTではなくtest環境、fixture、oracle、judgeの欠陥

failure taxonomyはtask classに応じて拡張するが、異なるfailureを一つの平均scoreに埋めない。

検証可能なものは決定論的に取る。 - schema / exact field / normalized value - unit/integration test - file/cell/document diff - DB/API authoritative state - permission/tool log - changed-target count - retry/tool count / latency / cost

意味評価が必要な箇所だけLLM judgeまたはhuman rubricを使う。judgeのmodel、prompt、rubric、version、reference artifact、order、calibration setをprovenance化する。LLM judgeをground truthとみなさない。reference solutionやgolden patchへの過適合、position/order bias、rubric ambiguityを監査する。

公開benchmarkのscoreは、そのbenchmark、harness、task distribution、scaffold、version、evaluation method上の観測値である。次を自動的には証明しない。 - 組織固有taskで同じ順位になる - 別scaffold/toolで同じprocess profileになる - permission / security boundaryを守る - cost/latencyが組織SLOを満たす - non-coding taskへ同じ傾向が転移する - 最新provider product modeで同じ挙動になる

したがってleaderboardは候補探索・回帰probe・外部比較には使えるが、組織受入試験を置き換えない。

• 変更ごとにSUT manifestを固定し、model aliasだけで比較履歴を持たない。
• business-critical journeyから再現可能fixtureを作り、initial stateとauthoritative oracleを固定する。
• final answerだけでなくartifact、tool side effect、readback、observable trajectoryをtrial IDへ結合する。
• deterministic evidenceを先に判定し、semantic judgeは限定領域へ分離する。
• judge変更をSUT変更と同様にversioned changeとして扱い、score discontinuityを説明可能にする。
• aggregate scoreとは別にcritical permission/safety failureをhard gateとして保持する。
• success率が同じSUT同士でもefficiency、artifact quality、process qualityを比較する。
• failure stage分布からprompt/scaffold/tool/fixture/oracleの改善先を切り分ける。
• private/holdout fixtureを開発ループへ常時露出させず、contaminationやshortcutを監視する。
• trial costにはinferenceだけでなくtool/API、test/build、judge、storage、human adjudication、maintenanceを含める。

• JetBrainsの具体的比較値とtrajectory profileはJunie scaffoldとcoding taskに依存し、別agentや非coding業務へそのまま一般化できない。
• ProcBenchはprocess-level評価の独立支持になるが、annotation dependence、partial observability、broader external validation不足を残す。
• observable trajectoryでも、観測されない内部state、external system state、hidden side effectを完全には表せない。
• deterministic graderも仕様やoracleが誤れば誤判定する。
• semantic judgeはbias、reference-solution bias、prompt/version driftを持つ。
• private fixtureも既知caseへのoverfit、distribution drift、coverage gapを起こす。
• repeated trialsでvarianceを測っても、将来のproduction distribution全体を保証しない。

• traceにsecret、credential、PII、customer contentを無制限保持しない。必要なstructured evidence、hash、redacted locatorを優先する。
• holdout answer、grader criteria、reference patchをSUTから隔離する。
• tool permission testはisolated environment、least privilege、reversible fixtureを使う。
• SUT manifest、fixture version、model/tool/runtime、trace、outcome oracle、grader provenance、reference artifact、cost-as-ofをtrial IDへ結合する。
• inference tokenだけでなくtool/API、test/build、judge、storage、human adjudication、review burdenを別計上する。
• profile悪化時にmodel能力、scaffold、tool、fixture/oracle、judgeのどこが変わったか切り分けられるversion provenanceを必須とする。

• JetBrains結果がJunie以外のagent scaffoldへどこまで一般化するか
• codingで得たprocess profileが文書更新、表計算、RAG、業務tool agentへどこまで転移するか
• process scorecardとincident rate / maintenance costの相関
• privacy-preserving trace redactionによるdiagnostic information loss
• organization-specific task mix、criticality、acceptance threshold、trial count
• semantic judgeの最適な校正方式とreference-solution biasの扱い
• tenant固有のprovider/model/tool/runtime挙動

UNKNOWNを公開資料から推測で閉じない。組織固有値はfixture設計と実測で確定する。

エージェント評価では、成功率だけでは実務上の差が消れる。同じ成功でも、必要な検証を行ったか、変更範囲が過剰でないか、無駄な探索や失敗ループがないか、所要時間と費用がどう違うかを別々に記録する。失敗も一括せず、問題箇所の発見、原因特定、実装、検証、実状態のreadbackのどこで止まったかを分ける。ただしtrajectory評価は特定のagent scaffold、task、tool、graderに依存し、modelそのものの普遍的な「性格」を証明するものではない。