評価ループと、これからやっていきたいこと ─ LLM プロダクトの研究を回し続けるために
こんにちは！Scene Live・New Standard室のまっすーです。
2025年からデータサイエンティスト兼データエンジニアとして、Scene Liveに中途入社しました。bqというサービスのLLMを用いた検証・研究をおこなったり、プロダクトに関するデータ収集から利活用までの『データ基盤』を作ったりしています。
前回：プロダクトのゴールに向けた研究の話 ─ 普段やっている “研究”を分解してみる
関連：なぜ Airflow から Dagster に乗り換えたのか ／Dagster 移行、500 テーブル超を止めずに引っ越した話／Dagster の“ネイティブ統合”が効いた話／データの消費者は「ヒト」だけじゃない ─ AI ネイティブなデータ基盤の実態／プロダクトに Langfuseを入れた話／LangfuseとBigQueryを繋いだ話
既刊：【1ヶ月半で構築】bq事業のモダンデータスタック
はじめに
前回は、 「プロダクトのゴールから PoC を組むまで」 の話を書きました。研究リポジトリと本番リポジトリの二層構造、 実験管理ツール+ experiments/ フォルダの二重管理、 PoC を本番想定で書く工夫 ─ ここまでが研究の“前半戦” でした。
今回はその続きで、 「評価して、 落として、 ループを回す」 という研究の “後半戦” の話を書きます。具体的には、
評価の物差しをどう揃え続けるか
比較してボツになる研究のほうが、むしろ多いという話
研究と運用を一周のループとして見る視点
これからやっていきたいこと
の 4 つです。前編と同じく、 研究の中身そのものではなく 「研究をどう進めているか」 にフォーカスします。
この記事の前提（用語の整理）
前編で出てきた用語（PoC / MLflow / SOTA / ハイパラ / リファクタ / 乱数シード / CRJ / LLM-as-a-judge / 研究リポジトリ / 本番リポジトリ / experiments/ フォルダ）は引き続き使います。本記事で新しく深く扱う用語を以下に整理します。
オフライン評価：本番に出す前に、 手元で過去データに対して評価することの呼び方。 「すでに正解 (またはラベル) が付いているデータセット」 に対してモデルを当て直して、 スコアを計算する。 本番に出して実ユーザーの反応で測る オンライン評価 (A/B テストなど) と対になる概念
人手アノテーション：人間が出力に対してラベル付けやスコア付けをする作業。 「この出力は良い / 悪い」 「このスコアは 3 / 5」 のように、 人の判断を教師データや評価基準として残す
MAE (Mean Absolute Error)：予測値と正解のズレの絶対値を平均した指標。 「予測がだいたい何単位ズレているか」 を直感的に表す。 値が小さいほど精度が高い
AUC (Area Under the Curve)： 二値分類モデル (Yes/No を判定するモデル) の性能を表す指標。 ROC 曲線という図形の下の面積で、 0.5 (ランダム) から 1.0 (完璧) の範囲をとる。 値が大きいほど分類精度が高い
ドリフト： モデルや評価器の出すスコアが、 入力データの傾向変化やモデル更新によって、 知らないうちにずれていく現象。 連載で何度か触れている概念
GTM (Go-To-Market)： プロダクトを市場に届けるための一連の活動 (営業・マーケティング・カスタマーサクセスなど) を総称した呼び方。 後半の「これからやっていきたいこと」 で登場
6. 評価ループ ─ 物差しを揃え続ける
PoC ができたら、 評価をどう設計するかが次の論点です。
機械学習でも LLM でも、 研究の進み方は 「変えて → 測って → 良ければ採用」 という小さなループの繰り返しです。このとき一番大事なのが、 「測る側」 の物差しを動かさないこと。 物差し自体が動くと、改善が出たのか、 単に基準が緩んだのか分からなくなります。 具体的にやっているのは、 たとえばこういう運用です。
オフライン評価セットを最初に固定する： 本番に出す前に手元で評価するための「テスト用データ一式」 を決め打ちにして、 改善のたびに使い回す。 同じデータに対してスコアを並べることで、 「先週よりこれだけ良くなった / 悪くなった」 を同じ目盛りで比較できる
少量の人手アノテーション + 大量の自動評価を組み合わせる：全件を人手で見るのはコストがかかりすぎるので、 代表ケースだけを人手で評価し、 残りは自動評価で広く回す
両者のズレを定期的に監視する：自動評価が人手と乖離してきたら、 評価器のほうを直す (= モデルではなく “物差し” を直す) という判断をする
LLM のような 正解が一意に決まらないタスク だと、 自動評価には LLM-as-a-judge を使うことが多く、 以前の Langfuseの記事で書いたのはまさにその話です。一方で、 数値予測のような 正解が決まっているタスク なら、 自動評価は MAE や AUC のような統計指標 ─ 予測と正解のズレを集計するための、 機械学習で広く使われている物差し ─ になります。仕組みの骨格はどちらも同じ で、 評価器がツールに変わるだけです。
ここで意識しているのは、 物差し自体を動かさない期間を作る という運用ルールです。改善したいときに評価器も同時に直してしまうと、 改善幅が測れなくなります。 「測る側」 と「測られる側」 を交互にしか触らない という規律は、 研究と運用の両方で効きます。
正直、 ここを徹底できずに 「モデルも評価器も同時に変えてしまって、 何が効いたのか分からなくなる」 をやらかしたことが過去何度もあります。これまでに「やらかしたら正直に書く」 と言ってきた手前、 これも書いておきます。物差しを動かさない、というのは言うほど簡単ではないです。
7. 比較してボツにする研究のほうが、 むしろ多い
前編で「本番に着地した研究」 の話を書いてきましたが、 実態としては 研究リポジトリには「乗らなかった研究」 のほうがずっと多く残っています。
そもそも研究は、 複数のパターンを作って比較して、 一番いいものを選ぶ という作業の繰り返しです。比較する以上、 選ばれなかったパターンが必ず出てくる ─ つまり「ボツ」 が大量に生まれる、 というのが研究の自然な姿です。
比較には大きく 2 つのレベルがあります。
機能レベルの比較：ゴールに対して、 全然違うアプローチを複数試して、 どの切り口が筋がいいかを見極める段階。SOTA 論文をなぞった手法 / 既存プロダクトから着想を得た手法 / 自分たちで考えた手法、などを横並びで比較する
改善中の比較：切り口が決まったあと、 同じ枠の中でハイパラやプロンプトを振り直して、 どの設定が一番効くかを詰める段階。ここでは細かい差分の積み重ねで進む
どちらの比較でも、 選ばれなかったパターンは「乗らなかった研究」 として研究リポジトリに残ります。たとえばこういう例です。
新しい技術の探索的検証： 公開されたばかりのモデルやアーキテクチャを、 複数パターン試して効くか確かめる。プロダクト化に至るのはそのうちのほんの一部
ドメイン横断の情報収集： プロダクトの本筋とは少し離れた領域の論文や他社事例を読んで、 応用できる発想がないか探す
MLOps 道具の選定：評価器・ドリフト監視・トレース基盤の候補を比較して、 採用しなかったほうの記録を残す
こういう 「乗らないと判断するための研究」 も、 立派な研究の出力です。試して「効きません」 と書いて捨てる、 という判断は、 次に同じ問題に当たったときに無駄打ちしないための投資 でもあります。
捨てる判断は捨てる判断で重いんですが、 その判断の記録を残しておくほど、 次のゴールが来たときの初速が上がる という実感があります。「本番に乗ったもの」 が研究の成果として見えがちですが、 その裏に積み上がっている「比較して落としたもの」 こそ、 研究の蓄積そのもの だと考えています。
8. 研究と運用が一周し続けるループ
ここまでの話は、 それぞれ単発の作業のように見えますが、 研究側と運用側を1周のループとして捉えると、 これまでに書いてきた記事の構図が見えてきます。
ユーザーの行動データが基盤の Bronze 層に貯まる
Silver / Gold で整形され、 研究側から見える形になる
研究側でモデルやプロンプトを更新し、 評価ループで物差しを保ちながら本番に着地させる
本番で出した結果（推論ログ・スコア・人手フィードバック）が、 また基盤に貯まる
そのデータが、 次の研究の入力になる
このループの一周を 何回まわせるか が、 LLM プロダクトの改善速度に直結します。論文を1本書くより、 ループを 10周まわすほうがプロダクトとしては前に進む、 というのが今のところの肌感です。
このループを成り立たせるための配管が、 以前の Dagsterの記事で書いた基盤移行であり、 以前の Langfuseの記事で書いた LLMOps導入でした。配管 (基盤側) と中身 (研究側) は、 別々の話に見えて、 実はこの1つのループのために両方やってきた、 という見方をするとここまでの記事が1本につながります。
9. これからやっていきたいこと
ここまで「今やっていること」 を分解してきましたが、 次にやっていきたいこと にも少し触れておきます。
ここで挙げるのは、 個人の興味だけで動く話ではなく、 会社・プロダクトのためにもなる方向 に整理したものです。「研究の出口をプロダクトの中だけに閉じず、 外への発信・知財・他社の文脈とも繋ぐことで、 会社の競争力にもフィードバックする」 というのが、 共通の WHY です。
対外発信を増やす
この記事のような note記事の発信 は、これからも続けたいと思っています。普段の仕事から 再利用可能な形で残せる知見 を切り出して、 月に1度くらいのペースで書いていく、という形を意識しています。
会社にとっての WHY：採用ブランディング・技術広報・既存ユーザーへの信頼形成。「データ基盤と LLMOpsをここまでやっている会社」 という認知が積み上がると、仲間集めにも事業の信用にも効く
学会・論文の方向
ドメイン特化（LLM × 業務支援 / 会議・対話の構造化 / データ基盤 × LLMOpsなど）で、 国内外の学会や論文の場に何か出していきたい という気持ちが少しずつ強くなっています。LLM プロダクトを抱えているからこそ書ける、 現場で動いている評価ループや運用知見 には、 学術的にも面白い切り口があると思っていて、そのあたりを言葉にしていきたいです。
会社にとっての WHY：学術コミュニティへの還元と、そこから戻ってくる外部視点。 査読を通して言語化された知見は、 社内の研究プロセスをもう1段強くしてくれる
特許・知財の方向
事業価値と結びついた仕組み ─ プロダクトを賢くしていくループの設計、 評価運用のノウハウ、 リバース ETL の工夫など ─ は、 知財として残す方向 も検討しています。これは自分1人ではできないので、 社内の関係者と相談しながら進める領域です。
会社にとっての WHY：競争優位の保護と、 ライセンス・パートナーシップの選択肢を増やすこと。 自社で培った仕組みを「他社に真似されにくい形で残す」のは、 中長期の事業基盤を厚くする
技術的な探求
技術側でやりたいことも色々あります。たとえば、
評価器そのものを評価する研究（LLM-as-a-judge の信頼性をどう検証するか）
ハーネスエンジニアリング（AI エージェントが安全に動くための足場 ─ ツール権限・実行環境・人間との合意点 ─ を設計する領域）
プロダクトに留まらない、事業最適の GTM エンジニアリング（プロダクト内の改善に閉じず、 営業・マーケ・カスタマーサクセスの導線まで含めて、 データと AI でレバレッジをかける動き方）
判断系 LLM の信頼性向上（プロダクトに組み込まれる“判断するAI” の安全性・説明可能性）
会社にとっての WHY：いずれもプロダクトの土台を太くする話で、 評価器・ハーネス・GTM・判断系 LLM のどれも、 「LLM プロダクトを信頼して長く使ってもらう」 ための足場になる。 これまで書いてきた LLMOpsの延長線上で、 中の人が普段やっている運用知見を、 もう1段抽象化して使える形にする ことができれば、 自社の競争力にも、 対外発信・学術の文脈にも繋がっていきます。
おわりに
LLM プロダクトを抱えながらのデータサイエンティストの研究は、 「論文を書く研究」 ではなく「研究と運用が1周し続けるループを作る研究」 だと考えています。
出発点はプロダクトのゴール
論文や先行事例を読むのは、 地雷を避けるため
研究リポジトリと本番リポジトリの2層構造で、 殴り書きと再現性を両立させる
実験はツールとフォルダで二重に痕跡を残す
評価の物差しを揃えたまま改善する
比較で落としたボツ研究も、 次のゴールへの投資として残す
出口は学術論文ではなく、 明日のリリースに乗る1行のロジック です。それでも、 問いを立てて、 仮説を組んで、 評価して、 書き残す という研究の骨格は何も変わっていません。むしろ LLM プロダクトを抱えながらの研究のほうが、 評価の物差しが現場で動き続けている分、 研究としては手強い面もある という印象です。
ここまで読んでくださり、 ありがとうございました。
関連記事
最後に
まだまだ発展途上のデータ基盤。これからも生成AI・LLMを使った改善を続けていきます！ データ基盤に興味がある方、LLMを活用した開発やデータ分析に興味がある方、ぜひお話ししましょう。
▼Scene Live 採用情報
▼新規AIプロダクトのエンジニア採用
