AIエージェントの評価と安全確認を判定モデルで毎回こなすOSS「jevals」を解説

「AIエージェントの答えや道具の使い方を全部確かめたいが、判定役のAIを毎回呼ぶと費用がかさみ、結局は一部を抜き出して見るだけになっている」「道具が返した結果に紛れ込んだ命令に、エージェントが従ってしまわないかを本番の動きの中で止めたい」——AIエージェントを業務に組み込み始めた企業の、開発や情報システムの担当者からよく聞く二つの悩みです。どちらも、評価や安全確認を「たまに、後から」しか回せていないところに根があります。けれど、問題は判定役のAIの賢さではありません。本当は、評価にかかる費用と時間が重いせいで、本番の一つひとつの動きを確かめられていないことが問題です。この記事では、判定専用のモデルを使って評価と安全確認を安く速く回そうとするOSS「jevals」について、一次情報で確かめられる仕組みと、導入前に企業が確かめておきたい注意点を整理します。導入や設定の手順は扱いません。

jevalsとは何か。2026年10月時点で確かめられる事実

jevals は、AIエージェントやAIを使った応答の仕組みを評価し、危ない動きを止める関門（ガードレール）としても使えるOSSです。GitHubのリポジトリと配布先の公開ページで、2026年10月23日に確かめられる事実から押さえます。公開しているのは、2021年2月に作られたOpenlayer 社の組織アカウントです。その組織が案内する公式サイトによると、Openlayer はAIの評価・監視・統制の仕組みを企業に提供している会社です。

リポジトリは2026年9月20日に作られ、最後の更新は10月15日です。スターはおよそ105、派生は11で、公開から約1か月の新しいOSSです。ライセンスはOSI承認のMITライセンスで、権利の表示は「jevals の貢献者」となっています。配布先の公開ページでは最新の版が0.1.4で、開発の段階は「アルファ（試作段階）」と表示されています。

README も自らを試作段階と書き、提供元への直接の接続や、各種の開発の枠組みとのつなぎ込みは、本物ではなく模擬の相手でしか試していないと明記しています。つまり、仕組みとしては面白くても、2026年10月時点で本番の重要な場面にそのまま入れる段階ではない、と提供側自身が示しているわけです。この記事も、その前提で読み解きます。

なぜ今、AIエージェントの評価の費用が問題になるのか

README は、多くのチームが本番の通信のごく一部しか評価していない理由を、費用だと説明しています。評価の判定役に高性能の汎用のAIを使う方式では、判定のたびに数回のやり取りが発生し、見本の文例を添えて、理由の文章と結果を一語ずつ書かせるからです。その結果、全体の1％だけを夜にまとめて評価する、という運用に落ち着き、評価の結果が本番の動きに間に合わない、というのが README の見立てです。

AIエージェントになると、確かめることが増えます。正しい道具を選んだか、道具の結果を使ったか、任された範囲から外れていないか、道具の結果に紛れ込んだ命令に従っていないか。記録も長くなります。さらに、汎用のAIによる判定は同じ記録でも実行のたびに結果がぶれることがあり、README は、他社の比較で汎用のAIの判定のぶれが判定専用のモデルの92倍から913倍だったと紹介しています。ただしこれは README が引用する他社の比較で、この記事では独立に確かめていません。

守る側から見ると、この話は品質の問題にとどまりません。紛れ込んだ命令や個人情報の漏れを、抜き取りの評価で後から見つけても、被害はもう起きているからです。評価を一つひとつの動きに間に合わせられるかどうかは、エージェントを本番で動かす企業にとって、守りの設計そのものに関わる論点になっています。

判定モデルという考え方：文章を書かせず確率だけを返させる

jevals の中心にあるのは、文章を生成しない「判定専用のモデル」です。README によると、このモデルには調べたい情報と、型の決まった質問の組を渡します。質問の型は、はい・いいえで答えるもの、候補から一つ選ぶもの、決めた基準で点数をつけるものの三つです。モデルは質問ごとに、どのくらい確からしいかを確率で返すだけで、理由の文章は書きません。

README は、判定役のAIに求めることの多くはこの三つの型に収まる、と説明しています。「この主張は根拠で裏づけられているか」ははい・いいえ、「どの道具を呼ぶべきだったか」は選択、「この答えはどれだけ質問に応えているか」は基準による採点、という具合です。汎用のAIは長い理由と結果を書きますが、最終的に使うのは結果の札だけだ、というのが設計の出発点です。

jevals はこの考え方の上に、評価の部品を組み直したものです。文の分割や道具の呼び出しの照合、秘密の情報の候補探しのように、ふつうのプログラムで確実にできる部分はプログラムで行い、判断が要る部分だけを型の決まった質問にします。汎用のAIを使うのは、判定専用のモデルでは扱えないごく一部に限る、と README は書いています。判断の要る部分と、機械的に決まる部分を分けている点が、この OSS の特徴です。

主な機能1：一つの記録をまとめて一回で評価する

jevals では、エージェントの一回分の動作記録（利用者の依頼、エージェントの答え、道具の呼び出しとその結果）に対して、複数の評価をまとめてかけます。README によると、一つの記録に対する評価は、何種類あっても一回の問い合わせにまとめて送られる作りです。質問は互いに独立に並べて処理されるため、質問の数が増えても待ち時間はほとんど変わらない、と説明されています。

評価の種類は、README の一覧で全部で37あります。大きく、エージェントの動き（道具の選び方、引数の妥当さ、道具の結果を使ったか、答えが根拠に基づくか、範囲を守ったか、同じ動きの繰り返し、目標の達成など）、安全面（後述）、答えの品質（根拠との一致、質問への関連、網羅性、指示への従い方など）の三つに分かれます。品質の評価の名前は、AIの答えの評価で広く使われている Ragas に倣ったものです。

README は、同じ評価の定義を、開発中の評価、本番の記録の監視、エージェントの中の関門の三つにそのまま使えるとしています。開発中に測ったことと同じ基準で、本番の動きを止められるという点は、評価と守りを別々に作りがちな現場にとって、考え方として参考になります。ただし、どの基準で止めるかを決めるのは使う側です。

主な機能2：安全面の評価項目（紛れ込んだ命令・個人情報・秘密の漏れ）

守る側にとって関心が高いのは、安全面の評価です。README の一覧には、利用者からの不正な指示、道具の結果や取り込んだ文書・電子メールに紛れ込んだ命令、安全の制約を外そうとする依頼、目標の乗っ取り、システムへの指示文の漏えい、権限を超えた行動、個人情報、健康に関する情報、秘密の情報の露出、有害な表現、偏り、専門的な助言の逸脱、話題の逸脱、といった項目が並んでいます。

個人情報と健康に関する情報は、二段階で見る作りです。まず、個人情報を見つけるための既存のOSSである Presidio、またはそれがない場合は文字の並びと検算による簡易の検出で候補を拾います。次に、判定モデルへの質問で、実在の人の健康の情報なのか、問い合わせ窓口の電子メールの宛先のような無害なものなのかを見分けます。README は、個人情報の誤検知の多くは、この見分けで減らせると説明しています。

秘密の情報（鍵や認証の情報）も、文字の並びで候補を探し、判定モデルが見本の値などを除く、という二段構えです。機械的な検出と判定モデルの見分けを組み合わせるやり方は、検出の漏れと誤検知の両方を抑えようとする考え方です。ただし、どの程度の精度が出るかは、README に安全面の項目ごとの数値がなく、この記事では確かめられていません。

主な機能3：評価をそのまま関門（ゲート）として使う

jevals の評価は、エージェントの動きを止める関門としても使えます。README によると、関門は評価と方針を組み合わせたもので、結果に応じて「通す」「人に回す」「止める」を決めます。健康に関する情報が含まれる場合は、その部分を置き換えて通す「書き換え」の判断もあります。それぞれの判断には、理由と評価ごとの結果、使った量が記録として付くため、後から監査できます。

README の例では、返金を求める顧客の依頼に対し、承認の確からしさと根拠の確かさが一定以上なら通し、危険の確からしさが一定以上なら止め、それ以外は人に回す、という方針が示されています。その例で、顧客が求めた少額の返金も、お金が動く操作なので人に回った、と書かれています。取り消せない操作は、判定が通っても人に回すという設計の向きは、エージェントを業務に入れる企業が押さえておきたい点です。

注意したいのは、判定サービスが止まったときの既定の動きです。README によると、一時的な失敗は間を置いて再試行しますが、それでも判定サービスが応答しないとき、関門は既定で「通す」側に倒れる（フェイルオープン）と明記されています。止める側に倒す設定もあり、README も取り消せない操作にはそちらを勧めています。導入するなら、この既定値を必ず見直す必要があります。

判定をどこで行うか：外部の判定サービスと手元で動かす選択肢

jevals 自体は判定モデルを含みません。README によると、判定はいくつかの「判定の担い手」から選べます。外部のサービスとしては、TypeSafe 社の判定モデル Jev を直接、または Vercel の中継サービス経由で使う方法、OpenRouter という複数のモデルを仲介するサービス上の判定モデルを使う方法があります。

手元で動かす選択肢もあります。README には、記憶容量の大きい Mac で動く Kev、Apple Silicon 上で通信なしに動く Laya、自前の演算装置一台で動く Eikos が挙げられており、手元や自社の機材で動かせば、評価に使う会話や道具の結果を外に出さずに済むとされています。判定専用のモデルが使えない場合は、ふつうの汎用のAIで代用できますが、遅く高くなり、確率がほぼ0か1でしか返らない、と README は書いています。

もう一点、判定の担い手を替えるときは、確率の目盛りがモデルごとにずれるため、自社の正解付きの記録で目盛りを合わせ直すよう README は求めています。担い手を替えれば、止める基準も合わせ直しが要るということです。費用や送信先の都合で担い手を替える場合も、基準の見直しを手順に入れておく必要があります。

想定される使い方・使う場面

README の説明から想定できる使い方は、大きく三つです。一つ目は、開発中の評価です。用意した記録の集まりに評価をかけ、道具の選び方や根拠に基づく答えの割合を測ります。二つ目は、本番の記録の監視です。抜き取りではなく全部の記録に評価をかけ、紛れ込んだ命令の疑いや範囲の逸脱が増えていないかを見ます。

三つ目が、エージェントの中に置く関門です。README には、OpenAI のエージェント開発の部品、LangGraph、Anthropic のエージェント開発の部品、Claude Code の動作前の確認の仕組みにつなぐ方法が案内されています。また、評価の作成や実行をAIの開発支援の道具から呼べるようにする MCP の窓口もあります。エージェントが道具を使う直前に判定を挟めるのが、この使い方の要点です。

一方で README は、できないことも明記しています。評価用の問題の自動作成や結果を見る画面はなく、複数の段階をたどる推論の採点や文章による講評については、汎用のAIによる判定の代わりにはならない、としています。社内でどの場面に使うかを考えるときは、速さと安さが効く場面と、汎用のAIや人の講評が必要な場面を分けるのが現実的です。

従来の評価の手段との違いを表で比べる

README は、Ragas の方式と jevals の方式を、2026年9月に同じ条件の記録で比べた結果を載せています。下の表は、その数値と README の説明をもとに、評価の手段の違いを整理したものです。数値は README の作者による測定で、この記事では独立に確かめていません。費用は外部の判定サービスの料金に左右されます。

観点	汎用のAIに採点させる方式	jevals（外部の判定モデル）	jevals（手元で動かす判定モデル）
1件あたりの問い合わせ	README の測定で平均6回	1回にまとめる	1回にまとめる
1,000件あたりの費用（README の測定）	約2.60ドル	約0.03ドル	機材の費用のみ
判定の返し方	理由の文章と結果	質問ごとの確率	質問ごとの確率
評価に使う情報の行き先	採点役のAIの提供元	判定サービスと中継サービス	自社の機材の中
向く場面	複雑な推論の講評	本番の全件の監視・関門	外に出せない記録の評価

表から分かるのは、jevals の利点が「判定を軽くして全件に回せること」にある一方、軽くした分だけ、判定できることの幅は型の決まった質問に限られるという引き換えです。README の測定では、根拠との一致などの判定結果は方式の間でほぼ一致したとされますが、少数の記録での比較であり、自社の記録で同じ結果になるとは限りません。

安全性の評価：紹介可とした根拠

このラインでは、OSSをクローン・インストール・実行せず、公開されている情報だけで安全面を精査しています。jevals は「紹介可」と判定しました。根拠は次のとおりです。まず、ライセンスはOSI承認のMITライセンスで、商用での利用や改変に特別な制約はありません。公開しているのは、2021年に作られ、AIの評価と統制の事業を営む会社の組織アカウントで、作られたばかりの匿名のアカウントではありません。

次に、2026年10月23日時点で、リポジトリには公開済みのセキュリティ勧告がありません。弱点の報告の窓口を定めた文書があり、GitHubの非公開の報告の仕組みを使うこと、3営業日以内の受け付けを目指すことが書かれています。精査の記録では、導入時に自動で動く処理も見つかっていません。スターの増え方も1日あたり約3で、不自然な水増しの兆候は見当たりませんでした。

ただし、問題が見つからなかったことは安全の保証ではありません。公開から約1か月で試作段階を名乗るOSSであり、勧告がないのは、まだ精査の目が十分に入っていないだけの可能性もあると考えるべきです。とくに、この OSS は評価のたびに会話や道具の結果を外部の判定サービスへ送れる作りなので、その点は次の章で注意点として取り上げます。

導入前に知っておきたい注意点：外部の判定モデルへ送られる情報

README によると、評価に使う情報、つまり会話の履歴・道具の定義・道具が返した結果は、設定した判定の担い手へそのまま送られる作りです。外部の判定サービスを使えば、エージェントが扱った顧客の情報や社内の文書の断片が、判定のたびに社外へ渡ることになります。

README には、外部の判定サービスや仲介サービスが送られた情報をどう保存し、どう扱うかの記述はありません。判定モデルの提供元、中継サービスの提供元、仲介サービスと、送り先が一社とは限らない点にも注意が要ります。これらのサービスの扱いの条件は、それぞれの提供元の規約で確かめる必要があり、この記事では確認できていません。

運営体制の面では、試作段階であることに加え、提供元への直接の接続や開発の枠組みとのつなぎ込みが模擬の相手でしか試されていない点が README に書かれています。配布先の公開ページの版の履歴を見ると、2026年9月20日に複数の版が続けて出ています。変更が速い時期のOSSは、版ごとに動きが変わる可能性があるため、本番に近い場面で使うなら、版を固定し、更新のたびに確かめ直す運用が前提になります。

悪用されうるリスクと、判定の限界

jevals は守りのための道具ですが、守りの道具ゆえのリスクもあります。一つは、関門の判定そのものがすり抜けられる可能性です。判定は確率であり、紛れ込んだ命令の書き方を工夫されれば見逃しが起きうる、と考えておくべきです。README も、目盛りはモデルや用途によって変わるので自社のデータで合わせ、取り消せない操作には人を残すよう勧めています。

二つ目は、判定サービスを止められたときの動きです。前述のとおり関門は既定で「通す」側に倒れるため、判定サービスへの通信が妨げられると、関門が働かないまま操作が通る可能性があります。これは推測を含む想定ですが、外部への通信に頼る関門を置く以上、止まったときにどちらへ倒すかは人が決めておく必要があります。

三つ目は、評価のために集めた記録そのものが狙われるリスクです。全件を評価すれば、会話や道具の結果が評価の仕組みに集まります。評価の記録は、それ自体が機密の情報の集まりになるため、保存先と閲覧できる人を絞る必要があります。なお、2026年10月時点で、jevals が攻撃に使われたという報告は確認できていません。

導入を検討するときに確かめること

jevals のような評価と関門の仕組みを検討するときは、機能の比較より先に、何を送り、何を止め、誰が決めるかを確かめます。下の順で進めると、試作段階のOSSでも判断の材料をそろえやすくなります。

この手順の中で、とくに見落としやすいのは三つ目です。判定サービスが止まっても業務が止まらないことは利点にも見えますが、守りの関門としては穴になります。どの操作なら通してよく、どの操作は止めて人に回すかを、導入前に紙に書いて合意しておくと、後から慌てずに済みます。

企業が取るべき対策

jevals を使うかどうかにかかわらず、AIエージェントの評価と関門を整えるときに企業が押さえたい対策を挙げます。一つ目は、評価に送る情報の区分を社内規程に入れることです。評価のための送信も、外部への情報の持ち出しの一つとして扱い、どの区分の情報をどの送り先に出してよいかを決めます。

二つ目は、関門の判断の記録を残し、定期的に人が見ることです。jevals のように判断ごとに理由と結果が残る仕組みなら、止めた件・人に回した件・通した件の傾向を見て、基準が厳しすぎないか、甘すぎないかを見直せます。三つ目は、評価の仕組みを調達するときの確認項目に、送信先、保存の条件、止まったときの倒れ方、版の更新の頻度を入れることです。

四つ目は、評価の結果を一つの仕組みだけに頼らないことです。判定モデルによる関門は、道具の権限を絞る、取り消せない操作に人の承認を挟む、といったほかの守りと重ねて初めて効きます。判定の関門は、守りの層の一つであって、最後の砦ではないという位置づけを、社内で共有しておくことが大切です。

AIに任せる範囲と、人が決める範囲

判定専用のモデルは、速く安く全件を見られる点で、人の目では追いきれない量を補う道具です。けれど、評価の基準そのものをAIに判断させないことが前提です。何を危険とみなし、どの確率で止め、どの操作を人に回すかは、人が確認する範囲を先に決めたうえで決めます。AIに任せてよいのは、決めた基準に沿って全件を素早く仕分ける部分です。

また、関門が止めた件や人に回した件については、判定の根拠を書かせる、つまり評価ごとの結果と理由を記録に残させ、人が確かめられるようにしておきます。根拠が残らない判定は、誤って止めたときにも、誤って通したときにも、原因をたどれません。避けたい使い方は次のとおりです。

• 判定の確率をそのまま信じ、自社の記録で目盛りを合わせないまま本番の関門にする
• 関門の既定の倒れ方（通す側）を確かめないまま、取り消せない操作の前に置く
• 評価に送る情報の範囲を決めず、顧客の情報を含む記録を外部の判定サービスへ全部送る
• 判定が通ったことを理由に、お金や外部への送信が絡む操作の人の承認を省く
• 試作段階の版を固定せずに使い続け、更新で判定の傾向が変わったことに気づかない

裏を返せば、人が決めるべきことははっきりしています。送ってよい情報、止める基準、止まったときの倒れ方、人に回す操作の四つです。この四つを決めたうえで使えば、jevals のような仕組みは、人の確認を減らす道具ではなく、人が確認すべき件を絞り込む道具として役立ちます。

よくある質問：jevalsを入れればエージェントの安全は確保できるか

答えは「確かめる場所は増やせるが、それだけでは足りない」です。jevals は紛れ込んだ命令や個人情報の漏れなどを判定し、関門で止める仕組みを提供しますが、判定は確率で、見逃しや誤検知はありえます。README 自身も、試作段階であること、目盛りを自社のデータで合わせること、取り消せない操作には人を残すことを求めています。

「外部の判定サービスを使わず、手元で動かせば安心か」という問いもありそうです。手元で動かせば会話や道具の結果を外に出さずに済みますが、機材の用意と、判定モデルそのものの更新や確からしさの確認という手間は自社に残ります。また、README に挙がる手元用の判定モデルの一部は、作者の公表値に基づく見積もりで、README の作者が測ったものではないと書かれています。

「汎用のAIによる採点はもう不要か」という問いには、README の説明に沿えば「不要にはならない」が答えです。複数の段階をたどる推論の採点や文章による講評は、汎用のAIや人の役割として残ります。全件の素早い仕分けは判定モデル、深い講評は汎用のAIや人、という分担が現実的と考えられます。

• jevals の機能・評価の一覧・判定の担い手・関門の既定の動き・測定値は、GitHubのリポジトリ（README・ライセンス・弱点の報告の方針・セキュリティの欄）と配布先の公開ページを2026年10月23日に確かめた範囲に基づきます。試作段階のOSSのため、版の更新で内容は変わる可能性があります
• README に載る費用・速さ・判定のぶれの比較は、作者や他社による測定の引用で、この記事では独立に確かめていません。外部の判定サービスや仲介サービスでの情報の保存と利用の条件は確認できていません
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

jevals は、AIエージェントの動作記録を、はい・いいえや選択肢で答える判定専用のモデルでまとめて評価し、紛れ込んだ命令や個人情報の漏れも確かめて、関門として止めることもできるMITライセンスのOSSです。汎用のAIに採点させる方式より軽くし、抜き取りではなく全件を確かめられるようにする、という狙いは、エージェントを本番で動かす企業にとって筋の通ったものです。

一方で、2026年10月時点では試作段階で、評価のたびに会話や道具の結果が判定の担い手へ送られ、関門は既定で判定サービスが止まると通す側に倒れます。送ってよい情報、止める基準、止まったときの倒れ方、人に回す操作を人が先に決め、判定の根拠を記録に残して人が確かめることが、jevals のような評価と関門の仕組みとの現実的な付き合い方です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。