LangfuseによるLLMOps基盤の構築と活用事例

2026/07/29 開催「LLMアプリケーション開発のリアル — オブザーバビリティと品質評価の実践」の登壇資料です。

https://sre-next.dev/2026/schedule/#slot098

株式会社ZOZO
データ・AIシステム本部
データサイエンス部 コーディネートサイエンスブロック
清水 悠揮

#o11y_findy

Transcript

1. LLM本番運用と Observability の始め方 Langfuseによる LLMOps基盤の構築と活用事例 2026/07/29 LLMアプリケーションの観測と評価 — 本番運用フェーズで何を見て、何を直すか 株式会社ZOZO データ・AIシステム本部 データサイエンス部 コーディネートサイエンスブロック データサイエンティスト 清水悠揮 Copyright © ZOZO, Inc. 1
2. 自己紹介 所属・役割 データサイエンス部 コーディネートサイエンスブロック やっていること WEARにおけるVLM/LLMを使った特徴抽出システムの開発・運用 最近の関心 ファッションベンチマークの作成、プロンプトの効率的な開発 清水悠揮 ひとこと 本日の内容はテックブログにて公開しています。是非いいねお願いしま す！ © ZOZO, Inc. 2
3. 本日お話しすること 発表 15分 ＋ 質疑応答 5分 LLMを本番で動かし始めて「Observability、そろそろ何とかしたい」となった場合に いつ・何を基準に導入を判断 するか ツールをどう比較・選定した か 導入して何が変わったか 課題が顕在化した「本番移行」のタイ ミングと、私たちの判断基準 LangSmith・Difyなど候補との比 較3軸と、Langfuseに決めた理由 トレースによるエラー調査の実例2 ケースと改善効果 © ZOZO, Inc. 3
4. 背景：VLMによる特徴抽出の本番運用 WEARのコーディネート画像 × Vision Language Model コーデ画像 （WEAR投稿） → VLM推論 （Gemini / Vertex AI） → 小規模な実験・検証 ログを見れば なんとかなる規模 © ZOZO, Inc. 特徴の 構造化出力（JSON） 日次バッチで 大規模推論を運用 本番運用フェーズ → 運用課題が一気に顕在化 4
5. 本番運用で直面した4つの課題 ① モニタリングの不足 エラー監視が実行時ロギング頼み。推論データ数の増加 で、ログの手動突き合わせが限界に ③ コスト管理の不透明さ 請求画面の合算値しか見えず、コスト急増時に原因リクエ ストを特定できない © ZOZO, Inc. ② プロンプト管理の難しさ 実験中は文言が頻繁に変わり、都度コミットするGit差分 管理は非現実的。configとの紐付けも全てコードベース に ④ モデルライフサイクル追従 Geminiは半年〜1年で提供終了も。更新前後の精度・レイ テンシー比較が都度必要 5
6. いつ導入するか — 判断が必要になった瞬間 PoC段階では正直、困っていませんでした。判断を迫られたのは本番移行のタイミング 判断材料になったシグナル（本番移行前後で出現） PoC・実験 本番移行 実行時ログで困っていな かった＝判断の必要がない 初めて「導入するか」の 判断が必要になった転換点 エラー調査＝ログの手動突き合わせが常態化している プロンプト更新と設定更新により、Gitのコミット・差分管理が 煩雑になる 日次推論などでAPIコストが継続的・不透明に発生 本番運用 © ZOZO, Inc. 移行後、4つの課題が 一気に顕在化 → 導入へ モデル更新（提供終了）への追従が定期イベント化 6
7. 候補ツールの比較 — 3つの評価軸 LangSmith・Dify等を候補に比較評価。GCPネイティブ機能も参考として併記 評価軸（自社要件） セルフホスティング （GCP上で自前ホスト） 既存スタックとの統合 （Vertex AI / LangChain / Python） 必要機能の充足度 （トレース・プロンプト等） Langfuse LangSmith Dify GCPネイティブ※ ◎ OSS。GCP向け 公式手順あり △ Enterpriseプラン のアドオン ◦ Community版 （OSS）で可 — ホスト不要 （GCP内で完結） ◎ @observeで最小 変更。OTel対応 ◦ LangChain利用時 は設定のみで有効化（移 行が必要） △ アプリ構築基盤 が主眼 △ OTel準拠の 自前計装が必要 ◎ ワンストップ＋ マルチモーダル ◦ トレース・プロン プト・評価を提供 △ アプリ内機能 に限定 △ 複数サービスに分散 Trace単位コストなし ※ Model observability dashboard／Cloud Trace（生成AIタブ）／Vertex AI Studioプロンプト管理などの総称。2026年7月時点の公開情報に基づく © ZOZO, Inc. 7
8. Langfuse選定の決め手 OSSで自前ホスト可 社内インフラ要件（GCP上でのセルフホスティング）に最も合致 既存コードに自然に統合 Python SDK提供。Vertex AI・LangChainなど主要フレームワークと互換 必要機能がワンストップ トレーシング／プロンプト管理／コスト監視を統合提供。画像入力トレース（マルチモーダル）対応が 決め手 © ZOZO, Inc. 8
9. 機能① Tracing — モニタリング不足を解決 1リクエスト全体をTraceに、各処理ステップをObservationとして階層記録 Trace: gemini_request_with_retry ├ fetch_langfuse_prompt ├ append_feedback Span 導入は @observe を付けるだけ 既存コードへの変更は最小限 Span 入出力・メタデータを1画面で把握 ├ request_to_gemini Generation ログの手動突き合わせが不要に ├ validate_gemini_response ├ parse_gemini_result Span Span Generation には 8.36s／4,986→302トークン／$0.000929 のよ うにLLM固有情報が自動記録 © ZOZO, Inc. エラー箇所がTrace一覧で一目瞭然 「モニタリング不足」を直接解決 9
10. 機能② Prompt Management — 運用課題を解決 「実験中の頻繁な文言変更」と「コードベースのconfig紐付け」から解放 バージョン管理＋ラベル Config Traceとのリンク UI上の更新のたびに自動でバージョン 作成。コミット不要で実験中の頻繁な 文言変更に追従でき、Diff表示で差分 確認も可能。production / staging ラベルをSDKから指定取得 モデル名・temperature・top_p を プロンプト側に持たせ、紐付けをコード から分離。コード変更・再デプロイなし にUIでまとめて更新（最も効いた機 能） どのバージョンがどの出力を生成した かを追跡。バージョン別のレイテンシー ・コスト比較で改善効果を定量測定 「どのバージョンが本番稼働中か・何を変えたか・効果はどうか」を1つのツールで把握できるように © ZOZO, Inc. 10
11. 機能③ Cost Tracking ／ ④ Tags・Session コスト管理の不透明さを解決 • • • © ZOZO, Inc. ダッシュボードでモデル別コスト・トークン数を 時系列で可視化 請求画面の「合算値」から、Trace単位 ・Generation単位に分解 異常なトークン消費の検知が容易に モデルライフサイクル追従を支援 • Tags：実験ID・アプリバージョン等の軸で Traceをフィルタ・グルーピング • Session：session_id指定で関連Traceを 集約 • モデル更新のたびにバージョン間の精度・レイ テンシー・コストを比較し、品質を検証してから 移行 11
12. 実例：トレースで原因特定→改善した2ケース 「日によって推論の所要時間が大きく違う」→ ダッシュボードのTrace推移から調査開始 ケース1 ケース2 503エラー（API接続失敗） 無限文字列の繰り返し出力 初回のAPIコールが503で失敗し、複数回のリトライ後にようや く成功するパターンが多発。Traceにリトライごとの記録が残り、 実態を定量的に把握できた 出力で特定の文字列が延々と繰り返され、JSONパース失敗→リ トライが頻発。入力9,616に対し出力64,999トークンの異常消 費。Trace Detail画面に出力がそのまま残っており、繰り返し パターンを直接確認できた 対策 Vertex AI SDK標準の指数バックオフを活かしつつ、リト ライ上限（例：3回）とタイムアウトをクライアント側でチューニン グ。一時的なエラーを許容しながらレイテンシー増を制御 対策 temperature=0では同じ異常出力が再現されるだけ。 エラーごとにtemperatureを+0.1して出力にランダム性を加 え、無限繰り返しから脱出。max_tokens明示で再発時の被害も 限定 → 対策後、Trace推移のグラフは安定し、推論スループットが一定に © ZOZO, Inc. 12
13. 導入して何が変わったか 以前はVertex AIのログを手動調査 — 全体像の把握に多大な時間 エラー調査時間の短縮 Trace単位で調査が完結。一覧からエラー箇所が一目瞭 然に リトライ戦略の最適化 各リトライの記録が残り、定量データに基づく改善が可能 に © ZOZO, Inc. 入出力の精緻な監視 プロンプトごとの入出力・トークン・コストを追え、異常検知 が容易に チーム内の議論が具体的に TraceのURL共有だけで、データに基づくエラー議論が できる 13
14. 本日のまとめ 課題 本番移行で「モニタリング／プロンプト管理／コスト／モデル追従」の4課題が顕在化 選定 セルフホスト・既存スタック統合・機能充足の3軸で比較し、Langfuseを採用 活用 Tracing／Prompt管理／Cost・Tagsで解決。エラー調査→改善のサイクルを短縮 今後 カスタムダッシュボード活用、評価データセット構築、自動評価パイプライン連携へ Q&A — ご質問をどうぞ 元記事：ZOZO TECH BLOG techblog.zozo.com/entry/llmops-observability-with-langfuse © ZOZO, Inc. 14