プロダクトに Langfuseを入れた話 ─ LLM 運用を“見える化”するまで
こんにちは！Scene Live・New Standard 室のまっすーです。
2025年からデータサイエンティスト兼データエンジニアとして、Scene Liveに中途入社しました。bqというサービスのLLMを用いた検証・研究をおこなったり、プロダクトに関するデータ収集から利活用までの『データ基盤』を作ったりしています。
連載：「Langfuse × データ基盤」 第 1 回 ／ 全 2 回
関連：なぜ Airflow から Dagster に乗り換えたのか ／Dagster 移行、500 テーブル超を止めずに引っ越した話／Dagster の“ネイティブ統合”が効いた話(dlt / dbt + リバースETL)
既刊：【1ヶ月半で構築】bq事業のモダンデータスタック
はじめに
ここまで複数回にわたって、データ基盤の設計・移行・運用の話を書いてきました。今回からは少し趣を変えて、データサイエンティストとして活動している話を書きます。
私はデータエンジニアの仕事もしますが、本来の専門はデータサイエンティスト（機械学習・AIエンジニアを含む広義）です。
bq 事業本部（現在、New Standard 室）に入ってから「データ基盤の整備」と並行で進めていたもう一つの仕事が、 LLM プロダクトを支える観測の仕組みづくり ─ いわゆるLLMOpsの導入でした。
今回はその第1回として、LangfuseというLLMOpsツールを選び、社内に持ち込んでいくまでの話を書きます。
この記事の前提（用語の整理）
以前の記事で出てきた用語（BigQuery / dlt / dbt / Dagster / リバース ETL 等）は引き続き使います。本記事で初めて深く登場するのは LLM 運用周りの言葉です。 まずは LLM そのものに馴染みがない方向けの用語から並べます。
LLM（Large Language Model）：大量のテキストを学習させた言語モデル。ChatGPTやClaude、GeminiなどのチャットAIの中身がこれです。文章を入力すると、続きや回答を確率的に生成する。同じ入力でも毎回少し違う出力になる、というのが従来のソフトウェアと一番違う点
プロンプト：LLM への入力文。「次の文章を要約してのような指示だけでなく、 役割や制約 (「丁寧な敬語で」「3 文以内で」等) も含む。プロンプトの細かい違いで出力品質が大きく変わるので、 LLM プロダクトの設計ではプロンプトの管理がそのまま品質管理になります
モデル： LLM の "種類" の単位。 例えば、同じ Claudeでも claude-sonnet-4-6 / claude-opus-4-7 のようにバージョンや系統がある。提供側 (Anthropic / OpenAI 等) のアップデートで挙動が変わることがある
トークン：LLM が文章を処理するときの単位。 だいたい英単語 1 つ or 日本語 1〜2 文字で 1 トークン。 入力 + 出力の合計トークン数で課金が決まるので、 コスト管理の単位でもある
ここから LLM 運用周りの用語に移ります。
LLMOps：LLM を組み込んだプロダクトを「運用しながら品質を保つ・改善する」ための仕組みや実践全般。 LLM の振る舞いを観測する / プロンプトを管理する / 品質を継続的に評価する / 改善を定量比較する、といった一連の活動を総称した呼び方
可観測性（Observability）：システムの内部で起きていることを外から後追いできる状態。ログ・メトリクス・トレースの 3 本柱で語られることが多い
Langfuse：LLM 呼び出しの trace / プロンプト管理 / 評価データセット / Score 記録 / Experiment などを 1 つにまとめた OSS の LLMOps プラットフォーム
trace / observation / score：Langfuse の中心概念。1回の LLM 呼び出しの一連を表す trace、その中の個別ステップ (LLM 呼び出し / 検索 / 加工等) が observation、出力に対する評価が score
なぜ LLM 運用は難しいのか
具体的な話に入る前に、そもそも LLM をプロダクトに組み込むと何が難しくなるのかを整理しておきます。
うちのプロダクト (bq-Recruit) では、 採用面接の進行中にリアルタイムで LLM が深掘り質問等を提示する、 という AI ライブアシスト という機能があります。面接官の発言と応募者の発言を逐次受け取って、 文脈に応じた質問を裏側で LLM が生成する仕組みです。 こういう機能を運用していると、 従来のソフトウェアとは別物の難しさがいくつも出てきます。
出力が確率的で、同じ入力でも毎回少し違う
プロンプト 1 行の修正で、挙動が大きく変わる
モデル提供側のアップデートで、こちら側は何もしていなくても振る舞いが変わる
出力品質を 自動で測る道具 が、そもそも存在していない (人間が見ないと分からない)
「ログを見て直す」という今までのデバッグ手法では、これらに太刀打ちできません。観測・評価・改善を体系化する仕組が要る ─ これがLLMOps の出発点です。
そこで観測の仕組みがないと、こう困る
前のセクションが LLM 運用一般の難しさだったとすると、ここからは 「観測の仕組みを入れない場合に、 具体的にどう困るか」に絞ります。
私が把握する限り、 運用面で具体的に困りそうだなと感じたのは、こんな点でした。
再現できない: ユーザーから「この出力おかしくない？」 という報告が来ても、どのプロンプトで・どの入力で・どのモデルが・どんな出力を返したか をあとから完全に再現する手段が限定的。 通常のアプリケーションログだと、構造化されていないor部分的な記録になりがち
コストが見えにくい: 月末にGCP / OpenAIなどの請求が来て初めて「今月コストかかったな」 と気づく。 どの機能の・どのプロンプトが・どれくらいトークンを消費しているかが、ダッシュボードを開いて即座に分かる状態ではない
品質劣化に気づけない: LLM の出力品質は なんとなく落ちていくことがあります。ベースモデルのアップデート、プロンプトの後付け改修、ユーザー側の入力傾向の変化。「気づいたら悪くなっていた」 を防ぐには、品質を継続的にスコアリングする仕組みが要る
プロンプト改善の議論が定量で語れない: 「このプロンプトの方が良さそう」という議論が、エンジニアの肌感ベースでしか進まない。 v1 と v2 を 同じデータセットで評価して比較 できないと、前に進めない
これらは LLM プロダクトを運用するチームならどこでも直面する話だと思います。裏返せば、 観測の仕組みを入れさえすれば、これらは全部「見える化」 できる ─ そう考えて、道具選定に入りました。
道具選定：なぜLangfuseを選んだか
LLMOpsの選択肢はいくつかありました。大きく整理すると、だいたい以下の4類型に分かれていた印象です。
マネージド SaaS 型： 機能は豊富で導入が一番楽。ただし料金体系がスケール時に読みづらい / 社内データを外部に預ける形になる
OSS 型 (マネージド版もある)： セルフホストとマネージド版を選べて、機能はSaaS 型に遜色ない。コミュニティもある
プロキシ型： LLM API 呼び出しの間に挟むだけで導入できる手軽さがある反面、trace観測寄りでExperiment やScore まわりは薄め
自前構築：自前のデータ基盤上で組めばできなくはないが、Prompt 管理 / Experiment / judge 機能を全部自作するのは工数が大きい
一通り検討した中で、 最終的に Langfuse を選びました。
決め手は 3 つです。
OSS なので、 ホスティングの選択肢を握れる: Langfuse は OSS で、 マネージド版 (Langfuse Cloud) も自前ホストも選べます。 まずマネージド版で始めましたが、「いざとなったらセルフホストに移れる」 という選択肢を最初から持っておけるのは安心材料でした。 純粋な SaaS だとそうはいかない
multi-project が使える: うちは「プロダクト系の LLM」「研究用の LLM」「社内エージェント」 と用途が違うものが並走する想定だったので、プロジェクト単位で分けて管理できるのは大きかったです (後述)
観測と改善が同じ場所で揃う: trace の観測、 Prompt 管理、 評価用 Dataset、 Experiment、 Score 記録が 1 つの製品で揃っている。 「観測する道具」 と 「改善する道具」 が分かれていると改善ループが断絶しがちなので、 同じ場所で全部できることに価値があると判断しました
特に3つ目が重要だと思っていて、 Langfuseの機能を整理すると「観測する」 2本 +「改善する」 2本 の4本柱になります。
「観測する」 ツールはたくさんあるけど、 「改善する」 側の Score・Dataset・Experiment まで揃っているものは意外と少ない。ここが選定の決め手でした。
社内展開とmulti-project構成
選定が終わったあとは、社内に展開する話です。
ここはプロダクトチームが中心となって、 プロダクト本体への Langfuse SDK 組み込み を進めてくれました。私が担当したのは LLMOpsという概念の紹介、そして データ基盤側 / 社内エージェント側への組み込み です。プロダクトチームが SDK を組み込み、出力された trace を私のほうで集約・分析して回す ─ そんな協業の形でした。
社内展開で一番考えたのは、「Langfuseプロジェクトを 1つにまとめるか、複数に分けるか」 という構成判断です。結論として複数プロジェクトに分けました。 役割で大きく 3 グループに分けています。
プロダクト LLM: ユーザー向け出力を生成するLLM 機能
研究用: 新しいモデル / プロンプトの検証
社内向け LLM: 前回の記事(URL)で書いたエージェント群や、社内データ分析用の LLM バッチ
なぜ単一じゃなく分けたかというと、権限・コスト・観測の単位を分けたかった からです。プロダクト系と社内エージェント系を同じプロジェクトに入れると、コストの切り分け、API キーの権限分離、機能ごとの Experiment の絞り込み ─ こういった操作が毎回フィルタやタグの絞り込み作業になってしまいます。最初に分けておくほうが楽でした。
入れて何が変わったか
冒頭に挙げた「見えない 4 つ」がどう変わったか、答え合わせです。
再現できる: ユーザー報告に対し、trace ID 1つから入力・プロンプト・モデル・出力・かかった時間 をすべて辿れるようになりました。「再現できない」 という最大級の困りごとが、「trace 開いて確認」の数十秒タスクに変わったのが大きい
コストが見える: プロジェクト単位 / 機能単位 / プロンプト単位で、トークン消費とコストが可視化されました。「あの機能、思ったよりトークン食ってるね」みたいな会話が、肌感ではなく数字でできるようになった
品質劣化に気づけるようになった: Score を付ける仕組み (人間アノテーション +LLM-as-a-Judge) が動き始めました。前回の記事で書いたLLM Quality Agent は、まさにこの LangfuseのScoreを使ってドリフトを検知しています
プロンプト議論が定量に: Langfuseの Dataset と Experiment 機能で、同じテストケース集に対して v1 / v2 のプロンプトを並べて比較 できるようになりました。エンジニアの肌感が、 共通の数字に置き換わる瞬間です
ここまでが Langfuse 単体で得られたものです。これだけでも十分価値はある と思っていますが、データ基盤と組み合わせるともう一段威力が出ます ─ それが次回の主題になります。
Langfuse内のトレース・コスト集計画面
Langfuse内の詳細なトレーシングのインターフェイス
おわりに
LLM プロダクトを運用するなら、観測の仕組みは早期に入れるべきというのが今回の結論です。「あとから入れる」 のは大変で、運用しながら直すのはもっと大変。入れた直後はオーバーキルに見えても、半年運用すれば、だいぶ効いてきます。
次回は、Langfuse のデータを BigQuery に流して、データ基盤の上で分析するようにした話 を書きます。前回の記事で出てきた LLM Quality Agent や Cost Watch Agent が、BigQuery 上で Langfuseのデータを SQL で読んで動いている、その裏側です。
これまでに作ってきたデータ基盤と、本記事で作った LLM 観測基盤 が、次回、1つに合流 します。
関連記事
連載：Dagster 移行 3 部作
なぜ Airflow から Dagster に乗り換えたのか
Dagster 移行、500 テーブル超を止めずに引っ越した話
Dagster の "ネイティブ統合" が効いた話
単発: 【1ヶ月半で構築】bq事業のモダンデータスタック
データの消費者は「ヒト」だけじゃない ─ AI ネイティブなデータ基盤の実態
次回予告
LangfuseとBigQueryを繋いだ話 ─ LLM の改善も、LLM による分析もBigQuery で
最後に
まだまだ発展途上のデータ基盤。これからも生成AI・LLMを使った改善を続けていきます！
データ基盤に興味がある方、LLMを活用した開発やデータ分析に興味がある方、ぜひお話ししましょう。
▼Scene Live 採用情報
▼新規AIプロダクトのエンジニア採用
