Evidently を採用する前に読む、Report と Test Suite と monitoring UI の境界
Evidently is an open-source ML and LLM observability framework. Evaluate, test, and monitor any AI-powered system or data pipeline. From tabular data to Gen AI. 100+ metrics.
ひと目でわかる
- これは何？
- Evidently は表形式データと LLM 出力の評価を Report としてまとめ、条件を付ければ Test Suite になり、時系列で見たいときだけ monitoring UI に載る。オープンソース版と Evidently Cloud の役割分担、uv での起動、そして評価器を自作するときのコストまでを、リポジトリの記述だけを根拠に整理する。
- 誰に向いている？
- 採用すべきなのは、評価の単位を Report としてコード上で持ち、同じ定義を Test Suite に切り替えて CI で使いたいチームだ。逆に、コードを書かずに評価を組み立てたい場合や、アラートやユーザー管理まで含めた運用画面を最初から欲しい場合、README が推奨として挙げている Evidently Cloud 側が前提になる。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 5 日前です。
- 何の言語で書かれている？
- 主に Jupyter Notebook です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Evidently が埋めるのは、実験と本番のあいだにある評価の空白
機械学習や LLM を使うシステムでは、モデルを差し替えたときに何が良くなり何が悪くなったかを、同じ基準で何度も測り直す必要がある。ノートブックで一回だけ混同行列を見る運用では、その比較が属人的になる。Evidently はこの比較の単位を Report として固定し、同じ Report に合否条件を足せば Test Suite になる、という二段構えを提供する。README はこれを「Turn any Report into a Test Suite by adding pass/fail conditions」と表現している。
対象は、表形式データを扱うデータサイエンティストと、LLM の出力品質を継続的に見たいエンジニアの両方だ。README は「Works with tabular and text data」と明記し、分類から RAG までを射程に入れるとしている。データドリフト検出のような古典的な監視と、LLM-as-a-judge のような生成物の評価を、同じライブラリの同じ Report という抽象で扱える点が、単機能のドリフト検出ツールとの違いになる。
Report と Test Suite は別物ではなく、同じ計算結果の見せ方が違うだけ
Report はメトリクスを計算して要約する。README によれば出力は Python 上でそのまま表示でき、JSON、Python 辞書、HTML として取り出せる。my_eval.json()、my_eval.dict()、my_eval.save_html("file.html") という 3 つの出口が用意されているのは、同じ評価結果をノートブックでの目視、CI での機械判定、関係者への共有という別々の用途に流すためだ。HTML は保存先のフォルダから開く必要があると README が注記している。
Test Suite は Report に pass/fail 条件を足したものだと説明されている。条件の書き方は gt（greater than）、lt（less than）といった比較演算子ベースで、README は「Zero setup option: auto-generate test conditions from the reference dataset」とも書く。参照データセットから閾値を自動生成できるので、最初の一本目を書くコストは低い。ただし自動生成された閾値が業務上の許容範囲と一致する保証はどこにもなく、そこは人間が決める領域として残る。
DataDriftPreset と TextEvals で見る、評価の実際の書き方
表形式データの例として README が示すのは iris データセットに対する DataDriftPreset(method="psi") だ。先頭 60 行を current、残りを reference として report.run() に渡す。ここで注目したいのは引数の順序で、run() の第一引数が current、第二引数が reference になっている。逆に渡すと意味が変わるので、既存のバッチ処理から流用するときは注意が要る。
LLM 側は構造が少し違う。Dataset.from_pandas() でデータセットを作る際に descriptors を渡し、Sentiment("answer", alias="Sentiment")、TextLength("answer", alias="Length")、Contains("answer", items=['sorry', 'apologize'], mode="any", alias="Denials") のように列単位の評価器を登録する。descriptors は行レベルの評価器だと README は説明しており、eval_dataset.as_dataframe() でスコア付きのデータフレームを確認できる。そのうえで Report([TextEvals()]) を実行すると、スコアの分布が要約される。行ごとの判定と分布の要約という 2 段階を分けているのが、この設計の要点だ。
なお README の例では Dataset.from_pandas(pd.DataFrame(eval_df), ...) と、すでにデータフレームである eval_df をもう一度包んでいる。動作に影響しない冗長な記述と思われるが、そのまま写すと不要なコピーが 1 回入る。
monitoring UI は任意であり、uv なら 1 コマンドで試せる
Report を時系列で並べて眺めたい場合に使うのが monitoring UI サービスだ。README はセルフホストのオープンソース版と Evidently Cloud の 2 択を示し、Cloud を Recommended と書いている。ローカルで試す最短経路は uv を使う方法で、次の 1 行でデモプロジェクト込みの UI が起動する。
uv run --with evidently evidently ui --demo-projects all
uv を使わない場合は virtualenv で環境を作り、pip install evidently の後に evidently ui --demo-projects all を実行する。README によれば localhost:8000 で UI にアクセスできる。ここで押さえておきたいのは、Report と Test Suite は UI がなくても完結するという点だ。UI はあくまで可視化層であり、評価ロジックそのものは Python 側にある。したがって「まず評価を定義し、必要になったら UI を立てる」という順序が自然で、逆に UI から入ると何を評価しているのかが曖昧になりやすい。
オープンソース版と Evidently Cloud の線引き
README は両者の比較ページを docs.evidentlyai.com/faq/oss_vs_cloud として案内し、Cloud 側の追加機能として dataset and user management、alerting、no-code evals を挙げている。つまりオープンソース版で完結しないのは、評価ロジックではなく運用の周辺部分だ。誰がどのデータセットを見られるかという管理、閾値超過時の通知、コードを書かない評価の組み立ては Cloud の領域になる。
この分割は導入判断に直結する。評価そのものを内製したいが運用画面は買いたい、というチームには素直に合う。逆に、アラートまで自前で作りたい、データを外部に出せないという制約がある場合は、オープンソース版の monitoring UI をセルフホストする前提で設計することになる。どちらの場合も、評価定義は Python 側に残るので、後から移行しても作り直しになる範囲は限られる。
自作メトリクスは Python interface で書けるが、そこからが本番
README は「Python interface for custom metrics」と「100+ built-in metrics」の両方を挙げている。既製のメトリクスで足りない指標を自前で定義できるのは、評価対象が業務固有であるほど効いてくる。ただしここには見えないコストがある。自作メトリクスは Report の出力形式、Test Suite の条件、monitoring UI での時系列表示という 3 つの経路すべてに乗る必要があり、片方だけを想定して書くと後で手戻りが起きる。
また README は「Open architecture: easily export data and integrate with existing tools」とうたっているが、具体的な連携先の一覧は示していない。既存の監視基盤にメトリクスを流し込みたい場合、その接続部分が標準で用意されているのか、JSON 出力を自分で変換するのかは、この資料からは判断できない。ここは実際に導入を決める前に確認すべき空白だ。
向かないケースと、代わりに検討されるもの
Evidently が向かないのは、評価の単位が固定できず、その場ごとにアドホックな分析をしたい場合だ。Report という抽象に載せるには、何を比較し、どの列を評価し、どの閾値で判定するかを先に決める必要がある。探索的な分析を延々と続けるフェーズでは、Report の定義を維持するコストのほうが大きくなる。
もうひとつの限界は、これがライブラリであって監視基盤ではないという点だ。常時動くパイプラインに組み込むには、Report を定期実行し、結果を保存し、閾値超過を検知する仕組みを別途用意する必要がある。この層を自前で書くか Cloud に寄せるかが、実質的な分岐点になる。
比較対象として分かりやすいのは、評価とテストをモデル開発フレームワークの一部として提供するツール群だ。たとえば scikit-learn の model_selection は交差検証と指標計算を提供するが、対象は学習時のモデル評価に限られ、本番データの分布変化や LLM 出力の判定は扱わない。Evidently はそこを、学習済みモデルの外側にあるデータとテキストの評価として切り出している。逆に言えば、モデル選択のための指標が欲しいだけなら scikit-learn で足り、Evidently を持ち込む理由は本番側の継続的な評価にある。
ライセンスと更新の追い方
ライセンスは Apache-2.0 で、リポジトリの LICENSE ファイルへのリンクが README に置かれている。Apache-2.0 は特許許諾条項を含む寛容なライセンスだが、自組織の利用形態が適合するかの判断は法務の領域であり、ここで断言はしない。
更新の頻度は資料から読み取れる。直近のリリースは v0.7.21（2026-03-10）、v0.7.20（2026-01-09）、v0.7.19（2026-01-05）で、0.7 系のパッチが継続的に出ている。0.x 系である以上、マイナー番号の範囲でも API が動く可能性は残る。実際 README の例では from evidently import Report と from evidently.presets import DataDriftPreset という import 形式が使われており、過去のバージョンから移行する際はこの import パスが最初に確認すべき箇所になる。
依存関係の重さも判断材料だ。uv を使う場合、uv run --with evidently で本体を都度取得できるため、環境を汚さずに monitoring UI の挙動だけを確認できる。採用を決める前にこのコマンドで UI を起動し、自分のデータを Report に通したときの出力が期待どおりかを先に見ておくのが、最も無駄の少ない確認手順になる。
編集部の結論
採用すべきなのは、評価の単位を Report としてコード上で持ち、同じ定義を Test Suite に切り替えて CI で使いたいチームだ。逆に、コードを書かずに評価を組み立てたい場合や、アラートやユーザー管理まで含めた運用画面を最初から欲しい場合、README が推奨として挙げている Evidently Cloud 側が前提になる。導入前に確認するのは 3 点で、第一に自分のデータ型が Dataset.from_pandas と DataDefinition で表現できるか、第二に DataDriftPreset(method="psi") の判定が自分の分布で妥当か、第三に自作メトリクスを Python interface で書く工数を許容できるか。特に三つ目は、既製の 100 以上のメトリクスで足りるかどうかが導入の成否を分ける。
コミュニティノート