LLMOpsの実践 セルフホスト Langfuseを 安全に本番運用するために 必要だった設計とそこから生まれた成果 Sansan株式会社 研究開発部 アーキテクトグループ CTO室 Rapid Delivery グループ 小松 展久 

小松 展久 Sansan株式会社 技術本部 研究開発部 Architect グループ 技術本部 CTO室 Rapid Deliveryグループ 金融系SIer、通信会社、SaaSベンチャーを経て 2021年にSansan入社。 Contract Oneの立ち上げ・開発に携わり、 その後は研究開発部で関連システムの開発・運用を担当。 

なぜセルフホスト Langfuse か - LLM 機能の評価が属人的だった（2025/09ごろ） > Contract One (取引管理サービス) では LLM を使った AI 機能を提供しているが、性能評価のサイクルが属 人的であった - データセットの未整備 / 実験の追跡不在 / 評価が属人的・手動 - 欲しかったもの - データセット管理 / 実行トレースの可視化 / 評価 - トレースには機密性の高い入出力データが含まれ得る - 社内規定やプロダクト規約により海外リージョンでのデータ保持が困難 - 2025/09時点ではLangfuse Cloudは海外リージョンしか存在せず 国内でのデータ保持や社内セキュリティ事項を考慮すると セルフホスト Langfuseが選択肢となった 

構成全体像 コンポーネント デプロイ先 理由 Web/Worker EKS (研究開発部の app 基盤 Circuit) 既存のアプリケーション基 盤に合わせる ClickHouse EC2 + EBS Kubernetes クラスタ の BG デプロイと分離 Redis ElastiCache Valkey 安価で Langfuse の思想に合致 PostgreSQL RDS マネージドで 運用負荷を最小化 S3 S3 Blob Store（SSoT） 

スモールスタートの割り切りと、その回収 - まずは最小コストでPOCを最 で開始することが目標 - 「課題が顕在化してから直す」が実際に機能した > 当初: ClickHouse を ECS Fargate + EFS でホスト > マネージド優先・運用負荷最小化 > 利用が広がるにつれ、EFS の I/O 課金が支配的に > 対処: EC2 + EBS(gp3)へ移行 > ClickHouse 関連の月額コスト約 66% 削減 > シングルノード方針は維持 > Langfuse使用におけるプロダクトとの合意として、 Langfuseへの同期的なリクエストは非推奨 

構築できた！いざ利用！とはならない - プロダクトから Langfuseに連携されるデータ > プロンプト、入出力データ、メタデータ等 > 入出力データに関しては、機密性の高いデータが含まれる場合もある - その前提で、セキュリティ要件に沿った運用設計を実施 > Webアクセス（人のアクセス） - SSOに統一＋本番は承認ベースの時限権限（Just-In-Timeアクセス） > APIアクセス（システムアクセス） - 最小権限（キー単位の許可範囲）＋呼び出し元制限（IP/CIDR等） > データ管理 - プロダクト側の削除要件（例：解約）に連動してデータ削除を実施 この統制により、最も厳格な情報資産区分のデータも扱える基盤になった 

Langfuse（Web）へのアクセス - セルフホスト LangfuseはSSOに対応 > 全社利用しているIdPと連携し、SSOログインに統一 > AUTH_DISABLE_USERNAME_PASSWORD を有効にすると ログイン手段としてSSOを強制可能 - 本番環境は Just-In-Timeアクセス（必要時のみ一時的に権限付与）を採用 > 社内の権限申請・承認フローと連携し、承認された期間/対象に限定して権限を付与*1 > 付与・剥奪の履歴が残る形で監査性を確保 限られたメンバー（開発者・研究員）のみが 承認付き JITアクセスを利用可能となった *1 AWS / Google Cloud / SaaS の横断的な権限管理基盤を作り直している話 

Langfuse（API）へのアクセス - Public APIはプロジェクト内のトレース /評価/プロンプト /設定のCRUD操作が可能 > Project内でAPIキーの発行が可能だが、認可機能はない - Public API を “直接叩けない ” 構成にし、 Proxy で統制 - 経路制御（Istio） > /api/public/* を Proxy にルーティング - 認証（キーの二重化） > 利用者には 内部発行キー を配布 > Proxy 内で 内部発行キー ↔ Langfuse API Key をマッピング > Langfuse で発行した生 API Key の直接利用を遮 断 - 認可（最小権限） > キー単位で許可エンドポイント／操作を制限 > キー単位で呼び出し元制限（ネットワーク） 

データ管理 - 解約に連動したデータ削除（顧客 IDベース） > 顧客IDメタデータで対象トレースを特定し、削除リクエストを発行 > 削除処理は非同期のため、削除完了を定期検証するバッチで削除漏れを検知 - 任意の期間でのデータリテンション > 解約処理に連動せず定期的にデータ削除を行いたいユースケースに対応 > configmap 経由で任意の日数を指定可能 - 評価用データ（ Dataset Item）も削除対象 > Dataset Itemはトレースから生成可能なため、対象トレースに連動して削除 - 残してはいけないデータを自動的に削除する仕組み > 必須メタデータ（例：顧客 ID）が欠落したトレースは定期削除 > トレースに紐づかない Dataset Itemは定期削除 > 個別リクエスト時の都度チェックを避けつつ、データ残存リスクを低減 

利用の広がり - 計6チーム・6サービスでの利用 (stg/prod合わせて) - LLMを利用したアプリ - MCP server - AI Agent - 日次での流入トレース量の増加 - 事例紹介 > Sansan Labs > 社内情報取得エージェント (Betelgeuse) 

Sansan Labsとは Sansan Labsは、未来の働き方を体験できる実験的な機能を提供するサービスです。 最新テクノロジーを駆使した機能を誰でも手軽に活用でき、新たなビジネスの気付きにつなげられます。 Sansanで蓄積したデータ 企業の開示情報やウェブ上の情報 名刺情報 有価証券報告書 過去の登壇情報 企業情報 導入サービス 商材情報 営業履歴 … 

Sansan LabsでのLangfuse活用実績 - 不具合の検知・原因特定・品質担保のサイクルが回り出した - モデル変更を安全に > カナリア + LLM-as-a-Judge 7 軸のオンライン評価で品質劣化がないことを確認してモデル 切替 - 本番インシデントの早期検知 > レイテンシ急増を検知し、LLM関連の原因の早期特定、即日対処を実行 - 「精度が低い」報告の即日原因特定 > 定性的なクレームを、オンライン評価スコアという定量データで裏付け、対処の優先度判断 

なぜSansan Labsでの活用が進んだのか - Sansan Labs 側の要因 - LLM を使った機能を多数抱えていた = トレース・評価のニーズが最初からあった - ファーストペンギンとなる推進者の存在 : 計装・ダッシュボード作成・評価の利活用を自ら進 め、チーム内に利用を広めてくれた - ホスト側の要因 - 利用者が「プロダクトの機能に関わること」だけに集中できるように整えた > 利用者がやること: 計装・監視・評価(プロダクトの価値に直結する部分) > 利用者がほぼ意識しなくていいこと: データ削除・セキュリティ(要件準拠を基盤側で担保済み) 

社内情報取得エージェント (Betelgeuse) *2 営業担当者の問いが、 3つの入口とアプリケーション層を経て、共通データ取得ロジック・データソースまで届く流れ ユーザー 別々の入口 Claude / ChatGPT / Cursor (MCP) 営業・CS担当者 アプリケーション層 社内情報取得 MCPサーバー 共通 データ取得 ロジック Slackエージェント (@メンション ) Slack絵文字 (リアクション ) 共通データ取得ロジック 社内情報取得 エージェント データソース 名刺 コンタクト 顧客活用 企業データ 契約書 請求書 CRM 商談書き起 こし 提案資料 社内ナレッ ジ(Notion) ニュース ・Web 導入事例 *2 どの入口からでも、同じ社内情報へ 

社内情報取得エージェント (Betelgeuse)での活用実績 - コストの異常も「内訳」まで即特定/社内用途はさらに踏み込める - 想定を超える LLM API 呼び出しが発生した際、コスト内訳が即座に特定でき、機能の停止 /再開 の判断と改善方針がすぐ出せた - 社内用途ならではの踏み込み > 顧客データを扱うプロダクトと異なり、トレース自体を LLM で分析して改善に回せる > 同じ基盤でも、データの機密区分に応じて活用の深さを使い分けられる = 統制設計が先にある からできること - 自らがCTO室兼務であることからホスト側から利用者側へ - 利用者の目線で今後のLangfuseで必要となりそうな機能の解像度を上げる 

今後 - 利用チーム・トレース量ともにこれからも増えていく見込みのため、インフラの堅 牢化を検討 - - 単一EC2によるClickHouseの見直し セルフホストLangfuseだからこその機能追加の検討 - コストアラート - コスト情報のデータレイク連携 - クラウドのマネージドLLMとの連携 - 独自モデルLLMを用いた透過的評価 

まとめ - セルフホスト Langfuse を本番運用し、価値創出へ繋げるための3つの要点 - ガバナンスの先行設計 - - 開発者の「価値創 - - SSO/JITアクセス制御とAPI Proxyにより、厳格な機密データも扱える基盤を構築 解約連動や不整合データの自動削除設計により残存リスクを徹底低減 」集中 インフラ・セキュリティ要件を基盤側で担保し、チームは計装・監視・評価に専念 6チーム6サービスへ拡大し、インシデント特定やモデル切り替えの高 化を達成 自社最適化と発展性 - ClickHouseの構成見直しでコストを66%削減し、スモールスタートを回収 社内用途の深掘り分析や独自評価基盤など、柔軟な機能拡張を継続 

Sansan 技術本部 募集ポジション紹介 https://media.sansan-engineering.com/ 

No content