本番環境にLLM（大規模言語モデル）を組み込んだシステムを運用していると、モデルやプロンプトを変更するたびに「本当に品質が上がったのか」を検証する仕組みが必要になります。この記事は、社内でAIモデルの評価・比較の仕組みをどう整備するか悩んでいる運用担当者やSRE（サイト信頼性エンジニア）向けに、判断材料を整理します。
AIモデルの評価というと開発初期の話に聞こえますが、実際には運用フェーズでも継続的な課題です。モデルのバージョンアップ、プロンプトの微調整、埋め込みモデルの入れ替えなど、変更のたびに品質劣化がないかを確認する必要があります。これは通常のアプリケーション監視と似ていて、デプロイ前後でメトリクスを比較する作業に相当します。
なぜ評価基盤の整備が後回しになりやすいか
AIモデルの評価は、データセットの読み込み、モデルAPIへのリクエスト、採点ロジック、結果の保存、過去実行との比較という複数の工程を繋ぐ必要があります。これらがスクリプトやNotebook、ログファイルに散在していると、再実行のたびに手順が変わってしまいます。
スコアが1つ出ても、それだけでは判断できません。モデル自体が変わったのか、データセットが変わったのか、採点方法（スコアラー）が変わったのか、サンプル数が変わったのかを切り分けられないと、根本原因分析（RCA）ができないためです。これは障害対応で「メトリクスが1つ悪化した」だけでは原因を特定できないのと同じ構造です。
オープンソースのAI評価CLI「Quantiles」（Apache 2.0ライセンスで公開されているコマンドラインツール）は、この一連の工程をqtという単一コマンドにまとめています。たとえばqt run simpleqa-verifiedを実行すると、Google DeepMindとGoogle Researchが作成した1,000問のベンチマーク「SimpleQA Verified」を、データセット読み込みから採点、集計まで一気通貫で処理します。実行結果はrun_idごとに保存され、qt show 1 --jsonのようにJSON形式で後から参照できます。
判断軸1: 評価対象の再現性をどこまで担保したいか
自作スクリプトでの評価は柔軟ですが、環境やライブラリのバージョンが変わると同じスコアが出なくなりがちです。評価の実行日時、入力データセットのバージョン、採点ロジックのバージョンを紐付けて保存する仕組みがあるかどうかが、再現性を左右します。
Quantilesの場合、実行のたびにrun_idが振られ、qt listで過去の実行一覧を確認できます。各runには評価名、ステータス、タイムスタンプ、所要時間、入出力、エラー状態、集計メトリクスが記録されます。これはCI/CDパイプラインのビルド履歴に近い発想です。障害対応で「先週のデプロイと比べて何が変わったか」を追う際の考え方と共通しています。
判断軸2: 監視・アラートの仕組みと統合できるか
運用中のシステムでは、評価結果を単発で見るだけでなく、既存の監視基盤（Prometheus、Datadog、Grafanaなど）にメトリクスとして流し込みたい場面があります。SimpleQA Verifiedの実行例では、max_similarity、mean_similarity、p95_similarity、p99_similarityといったパーセンタイル値が集計されます。これらはレイテンシ監視でおなじみのp95・p99の考え方をそのまま品質スコアに応用したものです。
CLIツールがJSON出力に対応していれば、--jsonフラグの結果をパースして外部の監視基盤に転送するパイプラインを組めます。逆に、GUI専用のSaaS型評価プラットフォームだと、この統合作業に追加のAPI連携コストがかかる場合があるため、既存の監視スタックとの親和性を事前に確認しておく必要があります。
判断軸3: ローカル実行かクラウドAPI依存か
Quantilesのデモモデルは、埋め込みモデルfastembedをローカルで動かし、レスポンスと正解データをコサイン類似度で比較する仕組みです。これはLLMプロバイダーへの課金なしに評価ワークフローを試せる設計です。一方で、実際の運用モデルを評価する際は、GPT-4.1のようなオートレーター（自動採点用モデル）をAPI経由で呼び出す構成に切り替える必要があります。
この選択はオンプレ運用かクラウド移行かの判断とよく似ています。ローカル完結型は初期コストが低く、機密データを外部に出さずに済む利点がありますが、大規模なベンチマークを回す際の計算資源をどう確保するかが課題になります。クラウドAPI依存型は拡張性が高い一方、API呼び出し課金と外部依存によるレイテンシ変動というランニングコストを継続的に見込む必要があります。
判断軸4: 運用チームの学習コストと導入の手間
インストールのしやすさも軽視できません。QuantilesはmacOSとLinuxのx86-64・Arm64環境向けに、curl -fsSL https://cli.quantiles.io/install.sh | bashという1行でインストールできます。外部からダウンロードしたスクリプトをそのまま実行することに抵抗がある場合は、install.shの中身を事前に確認してから実行する運用ルールにするのが無難です。
自作の評価基盤は柔軟にカスタマイズできますが、構築と保守にエンジニアの工数がかかり続けます。オープンソースCLIは公開されている分、コミュニティのアップデートに追従できますが、内部のスコアリングロジックや依存ライブラリの挙動を把握しておかないと、障害時の切り分けが難しくなる点は留意が必要です。
選択肢の比較
| 観点 | 自作スクリプト・Notebook運用 | Quantilesのようなオープンソース評価CLI |
|---|---|---|
| 再現性 | 環境依存で低くなりやすい | run_id単位で実行履歴を保存 |
| 初期導入コスト | 設計・実装に工数がかかる | 1行インストールで即開始 |
| 監視基盤との統合 | 自由に設計できるが手作り | JSON出力で外部連携しやすい |
| API課金 | 呼び出し設計次第 | デモモデルはローカル完結、無課金で試行可能 |
ケース別の推奨
モデルやプロンプトの変更頻度が高く、変更のたびに品質劣化を素早く検知したいなら、Quantilesのようなオープンソース評価CLIを試す価値があります。特にrun_idベースの履歴管理は、障害対応時に「いつからスコアが悪化したか」を追跡する助けになります。
既存の監視基盤にAI品質メトリクスを統合したいチームも、JSON出力を起点にパイプラインを組みやすい点で相性が良いといえます。まずはデモモデルでqt run simpleqa-verifiedを実行し、出力される集計メトリクスの形式が自社の監視ダッシュボードに取り込めそうか確認してみるのが手堅い進め方です。
一方で、評価対象のデータや採点ロジックが極めて特殊で、既存ツールの採点方式（コサイン類似度による意味的な比較など）では表現しきれない場合は、自作の評価パイプラインを維持したほうが柔軟性を保てます。また、社内ポリシーで外部インストールスクリプトの実行が禁止されている環境では、ソースコードを取得してから社内レジストリ経由で配布するなど、導入手順自体を見直す必要があります。
あえて見送るべき条件
すでに評価用の内製基盤があり、社内の監視・アラートと密結合している場合は、無理に切り替える必要はありません。移行コストと得られるメリットを天秤にかけ、既存基盤の保守で困っていないなら現状維持が妥当です。
また、評価対象のモデルがごく少数で、変更頻度も低いプロジェクトでは、CLIツールを学習するコストの方が高くつく場合があります。手動でのプロンプトテストと簡単なログ確認で十分なケースも珍しくありません。
導入前に確認しておきたいこと
AIモデルの評価基盤を選ぶ際は、再現性・監視統合・実行環境・導入コストの4つの軸で自分たちの状況を棚卸しすることが出発点になります。
具体的な次の一歩としては、まずデモモデルでqt run simpleqa-verifiedを実行し、qt show 1 --jsonで出力形式を確認してみることをおすすめします。そのJSON構造が、既存の監視基盤に無理なく取り込めるかどうかを見極めれば、自作か既存ツール活用かの判断材料が揃います。
評価基盤は一度作って終わりではなく、モデルやデータセットの変更に合わせて継続的に運用していくものです。障害対応と同じ発想で、変更前後の比較ができる仕組みを最初に整えておくことが、後々の切り分け作業を楽にしてくれます。