LLMでAIエージェントの出力を自動採点、OpenRouterが「LLM-as-a-Judge」の評価手法と実践手順を解説

要点

• OpenRouterは2026年9月14日、AIエージェントの出力を別のLLMで自動採点する「LLM-as-a-Judge」の手法と活用ガイドを公開した。

• 従来の決定論的テストでは検知が難しい自由記述の正確性や網羅性を、自然言語で定義した評価基準（ルーブリック）に基づいて測定できる。

• 審査役とテスト対象モデルの分離や偏向対策、3つの評価モード（Pointwise、Pairwise、Reference-based）の使い分けが示された。

• 同社の評価フレームワーク「Ori Eval」を用い、Bun環境でエージェントを自動評価・モデル比較する実装手順が紹介された。

• AIモデルのアクセス基盤を提供するOpenRouterは2026年9月14日、AIエージェントの応答品質を別のLLM（大規模言語モデル）を用いて自動採点する手法「LLM-as-a-Judge」に関する解説記事を公開した。従来の単体テストや文字列一致確認ではカバーしきれないオープンエンドな回答の品質を、自然言語の基準に沿って客観的にスコア化するアプローチをまとめている。あわせて、同社のテストフレームワーク「Ori Eval」を活用した具体的な評価手順についても明らかにしている。

決定論的テストと出力品質のギャップを埋める「LLM-as-a-Judge」

記事によると、AIエージェントはプログラムによる決定論的なテストをすべて通過しても、ユーザーにとって不適切な回答を生成してしまうケースがあるという。たとえば、サポートエージェントが適切な注文検索ツールを呼び出して正しい規約を取得したにもかかわらず、最終的な回答文から返金可能期間の記載を漏らしてしまうといった事態が挙げられている。ツールの実行自体に問題がなくても、最終的な回答が正確かつ完全で有用であるかを従来の仕組みだけで確認することは困難だと指摘する。

「LLM-as-a-Judge」はこの課題を解消するための評価手法である。テスト対象となる候補エージェントの出力結果やツール実行結果を別の「審査役（Judge）モデル」へ入力し、自然言語で記述された評価基準（ルーブリック）と照合してスコアを算出する。算出されたスコアが設定した閾値を下回った場合にテスト失敗と判定することで、多様な表現が存在する自由記述の品質を一貫した手順で検証できるとしている。なお、審査役が返すスコアは絶対的な真実ではなく、固定された設定下で取得された測定値として扱うべきだとしている。

審査役モデルの独立性と偏向対策

評価の信頼性を保つため、記事ではテスト対象の候補モデルと審査役モデルを分ける重要性が説明されている。候補モデルはユーザーへの応答やツール実行を担当し、審査役モデルは候補が生成した結果の採点のみを行う。

2023年の研究論文（Zhengらによる『Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena』）では、LLM審査役に「自己偏向（自身が生成した回答を優遇する傾向）」「位置偏向（特定の提示位置にある回答を好む傾向）」「長文偏向（品質に関わらず長い回答を高評価にする傾向）」といった偏りが存在することが示されているという。そのため、可能な限り両者には異なるモデルを採用することが推奨されている。また、審査役にはユーザーに見える応答文と採点に必要なツール結果のみを渡し、候補モデルの内部推論プロセス（hidden reasoning）は見せない設計にすることで、評価の独立性を確保できるとしている。

評価基準の設計と3つの評価モード

回答の判定基準には、人間が明確に判断できる具体的なルールを設定する必要がある。「親切に聞こえる」といった曖昧な表現ではなく、「14日間の返金期間に言及し、規約にない例外を勝手に作っていないか」のように、必要な根拠と不合格条件を明記したルーブリックが適切だと説明されている。なお、特定の一致を検証する場合は完全一致（Exact match）や、特定の必須語句が含まれるかを確認する決定論的チェック（Ori Evalにおける run.toMention() など）を使い分ける。

LLM審査役の運用形態としては、以下の3つのモードが挙げられている。

• Pointwise（点単位）: 1つの出力とルーブリックを照合する。継続的インテグレーション（CI）環境での品質閾値のチェックや、本番環境のサンプリング監視に用いる。
• Pairwise（対比較）: 2つの出力を比較ルーブリックで評価する。モデル間やプロンプト間、エージェントのバージョン間の比較に適しており、位置偏向を防ぐために提示順序を入れ替えた検証を行う。
• Reference-based（参照ベース）: 出力とルーブリックに加え、信頼できる参照データ（正解情報）を渡して評価する。表現の完全一致ではなく、保持すべき事実関係が網羅されているかを確認する際に用いる。

LLM審査役の適用対象と決定論的テストの役割分担

LLM審査役が適している領域として、検索データに基づいた回答（グラウンディング）の検証、規約引用や不要な行動回避などの指示遵守、複数要件に対する回答の網羅性、ブランドやサポートに適したトーンの確認、ツール実行結果の正しい要約などが挙げられている。

一方で、直接プログラムで検証可能な処理にLLM審査役を用いるべきではないとしている。JSONの構造チェックにはスキーマ検証ツール、計算処理には計算機、ツールの引数や副作用には単体テストを用いることが適している。また、安全上絶対に阻止すべき重要ポリシーの強制などについては決定論的なレイヤーで制御すべきであり、LLM審査役は最終応答の品質監査として位置づけるのが適切だとしている。

評価フレームワーク「Ori Eval」による実装手順

記事では、これらの評価を実行するための仕組みとして、TypeScriptとBunのテストランナーで動作する評価フレームワーク「Ori Eval」の利用手順が解説されている。1回の実行内でテストハーネスとモデルが固定されるため、途中で設定が変わることなくテストを実行できる。

コーディングエージェント向けには、環境導入から評価作成、モデル比較、スコアやコストに基づくモデル推奨までを一時ディレクトリ上で自動実行するスキル（spawn-ori-eval）が提供されている。手動でセットアップする場合は、Ori CLIをインストール（curl -fsSL https://openrouter.ai/labs/ori/install.sh | bash）してログイン（ori login）した上で、setupJudge() 関数により独立した審査エージェントを作成し、autoEvals() を呼び出して基準に基づく採点を行う流れとなる。