UAEFとは｜AIエージェントを7次元36メトリクスで評価するAWS公式のPython評価フレームワーク

AIエージェントを作ったあと、「それが良く動いているか」をどう測るかは難問です。AWS の awslabs が公開した UAEF（Universal Agent Evaluation Framework） は、この「エージェントの採点」を標準化しようとする Python フレームワークです。README は自らを “A framework-agnostic evaluation system for AI agents” と説明します。

特定のエージェント基盤に縛られず、LangGraph・Bedrock・Strands などのトレースを共通形式に変換して、7次元36メトリクスで採点するのが核です。本記事では GitHubリポジトリ awslabs/uaef（2026-11-12 時点、v0.2.0・タグ無し）のコードとドキュメントを一次情報に、何を測り、どう使い、どこまで成熟しているかを整理します。

エージェント基盤そのものの選び方は AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 にまとめています。UAEF はその「作ったあと、どう採点するか」を担う位置づけです。

UAEFとは——エージェント採点を標準化するフレームワーク

エージェント評価のつらさは、基盤ごとにトレースの形が違い、「何を・どう測るか」がばらばらになる点にあります。UAEF は、各基盤のトレースを共通形式（AgentTrace）に変換するアダプタ層を挟み、その上で統一されたメトリクスを走らせます。README いわく、対応は “LangGraph, LangChain, AWS Bedrock, Langfuse, Strands, AgentCore, or any custom framework via adapters”。

評価エンジンには SingleAgent・MultiTurn・MultiAgent・Offline（バッチ） のモードがあり、トレースの種類に応じて自動で選ばれます（マルチエージェントのトレースなら MultiAgent、それ以外は SingleAgent 側でマルチターンも扱う実装）。「1回の応答」から「複数エージェントの連携」まで、同じ入口で測れる設計です。

何を測るのか——7次元36メトリクス

UAEF の中心は 36 の組み込みメトリクスです。README は “36 built-in metrics across 7 dimensions” とし、内訳はドキュメントから次のように数えられます。決定的な指標（正規表現や集合計算で機械的に決まる）と、LLM が判定する指標が混在しているのが特徴です。

合計36のうち、ドキュメントの表から数えると決定的が約12、LLM判定が約24です。さらに RAGAS・DeepEval との統合で15前後を足せます（Stickler 統合は作業中）。決定的な指標は再現性が高く安く回せ、LLM判定の指標は曖昧な品質を拾える——この使い分けが、評価の設計として参考になります。

UAEFの使い方——evaluate()一発と、Bedrockによる判定

導入は、リポジトリを clone して uv で依存を入れます（PyPI 配布は無く、README は .whl か clone での導入を示します）。いずれも公式READMEの記載で、筆者が実行して確認したものではありません。

# 公式READMEの導入手順（Python 3.10+ / uv 必須）。未実行
git clone https://github.com/awslabs/uaef.git
cd uaef && uv sync

Python ライブラリとしての最小の使い方は、トレースと正解データを渡して evaluate() を呼ぶだけです（README の Quick Start より）。

# 公式READMEの記載（Quick Start）。未実行
from uaef.api import evaluate

result = evaluate(trace=trace, ground_truth=ground_truth)
print(f"Score: {result.overall_score:.2f}")

結果を AWS に残すには、persist=True と実験名を付けます。

# 公式READMEの記載。未実行
result = evaluate(
    trace=trace,
    ground_truth=ground_truth,
    persist=True,
    experiment_name="my-agent-v1",
    experiment_objective="baseline",
)

LLM が判定するメトリクスは、AWS Bedrock の Claude（既定は us.anthropic.claude-sonnet-4-6、temperature 0・max_tokens 2048）で動きます。設定を見ると、判定モデルは Anthropic Claude 系以外を受け付けない検証が入っています。正解データ（ground_truth）は、メトリクスによって「必須／任意／不要」が分かれます（たとえば網羅性の指標は必須、応答の関連性は不要）。導入は Python 3.10 以上と uv、そして Bedrock・DynamoDB・S3 を使う AWS 認証情報が前提です。

AWSへの保存とデプロイ——DynamoDBとS3、サービス一式

評価結果の永続化は、実験ごとに DynamoDB に1行（平均スコアや結果の保存先パスなど）、全結果の JSON を S3 に置く構成です。チームで評価をAPIとして使うための uaef-service も同梱され、Cognito・API Gateway・Worker Lambda・Step Functions・DynamoDB+S3・CloudFront の UI で構成されます。./scripts/cloud_deploy.sh 一発でのデプロイや、FastAPI コンテナを EKS 上で動かす選択肢も用意されています（事前に cdk bootstrap が必要）。

「評価を1回する」だけなら Python ライブラリで完結しますが、「チームの評価を継続的に回す」ところまで AWS 上に用意されているのが、awslabs 公式らしい作りです。

UAEFの注意点と現在地——v0.2.0・star 63 の初期段階

有用な設計ですが、成熟度は正直に見るべきです。

• 初期段階：v0.2.0・タグ無し・star 63（2026-11-12 時点）・PyPI 配布なし（リポジトリの .whl か clone で導入）。API や既定値は今後変わり得ます。本番の評価基盤にするなら、バージョンの固定と自分の環境での再現確認を前提にしてください。
• AWS 前提：LLM判定は Bedrock、永続化は DynamoDB/S3 と、AWS に乗ることが前提です。別のクラウドやローカルだけで完結させる作りではありません。
• 判定の限界：LLM判定のメトリクスは、判定に渡す出力を “untrusted data”（信頼できないデータ）として扱う注意がドキュメントにあります。評価する対象の出力にプロンプトインジェクションが混じり得る、という前提です。

エージェントの「良し悪し」を何で測るかは、作る側が最後まで悩む部分です。UAEF は、そのメトリクスの一覧と、決定的／LLM判定の使い分けを具体的に見せてくれる点で、自分の評価を設計する際の良いたたき台になります。エージェント評価そのものの難しさは、ベンチマーク側からの視点として Continual-ARCとは｜エージェントの「メモリ」は学習になっていたか も合わせて読むと立体的になります。エージェント基盤の選び方は AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 に、永続メモリの実装は agentmemory徹底解説 にまとめています。

参照ソース

• awslabs/uaef（GitHub） — 公式リポジトリ。README・src/uaef/・docs/・uaef-service/・LICENSE（Apache-2.0）を一次情報として確認（2026-11-12、v0.2.0・タグ無し）
• Amazon Bedrock のモデル（AWS 公式） — UAEF の LLM 判定が使う Bedrock 上のモデルの公式リファレンス