Langfuse

Langfuse v4は、Fast (Preview)の案内どおり「速くなる」更新に見えがちですが、本質は観測（observation）中心のデータモデルへの移行です。traceだけを入口にせず、処理単位から一覧や分析を辿れるobservations-first、保存と照会の組み替えに伴う画面・公開APIの応答改善、observation単位の評価などが一体になっています。公開APIはv2がデフォルトでv1相当はlegacy側です。SDKはPython v4とJS・TS v5で、相関属性のpropagate、trace属性まわりの役割分離、Pythonではstart_as_current_span/start_as_current_generationがstart_as_current_observationに置き換わる点、OpenTelemetryの既定spanフィルタの変更などがポイントです。全体像の詳細は公式のマイグレーションガイドや「Explore Observations in v4」、ブログ「Simplifying Langfuse

この記事のポイント 前編では、Langfuse v3.158.0の "fulltext search" が実装上は部分一致検索であること、そして3層の検索アーキテクチャの全体像を解説しました。 後編では、PR #12578のソースコードを詳しく読み、以下の2点を明らかにします。 プロンプト編集画面のTextモードとChatモードで 検索の挙動が異なる こと、特にChatモードではカウンターとハイライトが食い違うケースがあること サーバーサイド検索（ClickHouse / PostgreSQL）を含めた、日本語利用時の 具体的な制約（Limitation） → 前編はこちら：「Langfuse v3.158.0の"fulltext search"を読み解く — その実態は部分一致検索だった」 （ リンク ） PR #12578のコードリーディング 検索のエントリポイント：MessageSearchProvider 検索機能のアーキテクチャは、React Contextベースの MessageSearchProvider を中心に構成されています。

はじめに Langfuse v3.158.0（2026年3月13日リリース）で、PlaygroundおよびPrompt Managementのチャットメッセージ編集画面にテキスト検索機能が追加されました。ChangelogやPRタイトルでは "fulltext search"（全文検索）と表現されています。 日本語環境でLangfuseを使っている身としては、「全文検索」と聞くと気になるのが日本語の対応状況です。そこで今回、ソースコードを読んで実装の中身を調べてみました。 この前編では、まず新機能の概要とLangfuseの検索アーキテクチャの全体像を整理し、今回Langfuseに実装された検索機能が、技術的にはどういう仕組みなのかを明らかにします。後編では、ソースコードをさらに深く読み、日本語で使った場合の具体的な挙動や制約について掘り下げます。 今回の新機能：Playground / Promptsのメッセージウィンドウ内検索 今回追加されたのは、 Cmd+F （Mac）/ Ctrl+F （Windows）でPlaygroundやプロンプト編集

本記事でわかること Langfuseにおける「管理者によるトレース閲覧の検知」というニッチだが重要な課題に対して、実機検証ベースで現状の選択肢を整理します。 Langfuse環境で「管理者の会話ログ閲覧」をどう検知するか `LANGFUSE_ADMIN_ACCESS_WEBHOOK` の動作仕様（実機確認済み） この機能の限界と「本番で使えるか」の判断基準 対象読者 Self-hosted Langfuseを複数チーム・複数顧客で共用している方 LLMアプリの運用でコンプライアンス・セキュリティを気にしている方 Langfuseの特権アクセス管理に興味がある方 課題：LLMアプリの会話ログは機密データである LLMアプリを組織で運用していると、避けて通れない問題があります。 ユーザーの会話ログは、多くの場合、機密性の高いデータです。 カスタマーサポートの問い合わせ内容、社内文書への質問、医療・法律領域のやりとり——これらはすべてLangfuseのTrace（トレース）として記録されます。プロンプトの改善やデバッグのために記録することは正しい運用で

LibreChat v0.8.1から追加された、LiteLLMなしで直接Langfuseへトレースを送信できる新機能を試しました 。Docker Composeを用いたシンプルな環境構築手順から、MCP Server利用時のトレース確認まで、実践的なオブザーバビリティの実現方法を解説します 。

過去、Langfuseでのマスキングについて触れてきましたが、これまではクライアントサイドで対応するしかありませんでした。しかし、ついに先日のリリース（ v3.152.0 ）で、サーバーサイドでのマスキングが設定可能になりました。 ※ 注意 ：現時点ではEE（Enterprise Edition）ライセンス専用機能となっています。 今回は公式ドキュメントを参考に、実際に設定してみました。 基本設定 事前準備 マスク処理を行う、Langfuseからのコールバック先が必要になります。 今回は設定の挙動を確認したいため、公式の 実装例 をそのまま利用し、Cloud Runにデプロイしました。 設定 設定自体は、Langfuse Workerのコンテナに環境変数 LANGFUSE_INGESTION_MASKING_CALLBACK_URL  を設定すれば利用できるようになります。 ※ 注意 ：Langfuse Worker コンテナにEEライセンスが適用されていない場合、コールバックURLを設定しても、そのURLへリクエストが送られることはありません。

先週と同じ条件で実験したいのに、データセットを更新したから再現できない」「精度が下がったけど、データのせいかモデルのせいか分からない」——LLMアプリの評価データ管理でこんな課題を感じたことはないでしょうか。 Langfuse v3.151.0で強化されたデータセットバージョニング機能を使えば、評価データの変更とモデルの変更を分離して管理し、実験の再現性を確保できます。UIからはバージョンを選択するだけ、SDKからは特定時点のデータセットを指定して取得可能。チーム全体で安心してデータセットを改善し続けられます。

こんにちは。ガオ株式会社の黒澤です。 Langfuse v3.153.0 で [PR #11861]( https://github.com/langfuse/langfuse/pull/11861 ) がマージされ、LLM-as-a-Judge を Observation 単位で実行できるようになりました。本記事ではその背景と使い方をまとめます。 課題：Trace 全体への評価では「どこが悪いか」がわからない LLM アプリの評価で、こんな状況に陥ったことはありませんか。 RAG アプリの LLM as a Judge スコアが下がった。でも、ドキュメント検索が悪いのか、回答生成が悪いのか、判断できない。 これは、従来の Langfuse の評価機能が Trace（エンドツーエンドのリクエスト全体） を評価単位としていたためです。 Before：Evaluator は Trace 全体にしか設定できなかった Langfuse で LLM as a Judge Evaluator を作成すると、評価対象は Trace 全体の最終出力のみでした。

Google ADK（Agent Development Kit）のトレースに Langfuse のプロンプト情報を紐付ける方法を解説します。これにより、プロンプトごとのコスト・レイテンシ分析や A/B テストが可能になります。 なぜ紐付けが必要なのか 紐付けができないと何が困るか ・プロンプトごとのコスト・レイテンシを分析できない ・A/B テストでプロンプトバージョンを比較できない ・どのプロンプトが本番で使われているか追跡できない GoogleADKInstrumentor だけでは不十分 GoogleADKInstrumentor を使えば、Google ADK のトレースを Langfuse に送信できます。 from openinference.instrumentation.google_adk import GoogleADKInstrumentorGoogleADKInstrumentor().instrument() しかし、これだけではプロンプト紐付けがされません。 Langfuse ダッシュボード └──

LLMの多機能化により1つのトレースに詰め込む情報が増え、可視化目的のトレースでも見にくくなる問題が発生しています。LangfuseのTrace詳細画面では、適切なJSON構造を使うことで特殊なレンダリングが可能です。 主要なパターンは4つ。ChatML形式では会話履歴をroleに応じた背景色で表示。ツール定義と実行結果では、Function Callingの流れを視覚的に表示。マルチモーダルコンテンツでは、画像や音声を埋め込み表示でき、特にtype: "image_url"やtype: "input_audio"などの構造が重要です。推論過程では、LLMの思考プロセスを折りたたみ可能なブロックで表示します。 ただし公式ドキュメントと実際の挙動にギャップがあり、特にマルチモーダルファイルは指定のJSON形式でないとレンダリングされません。正確な構造を理解することで、デバッグ効率やチーム共有がスムーズになります。

Geminiの性能向上によりOCRは実用的になりましたが、高精度を目指すならプロンプト調整は必須です。しかし、調整のたびに画像と結果を目視で見比べるのは、手間がかかりミスも誘発します。 そこで本記事では、Langfuseを使ってこの作業を自動化します。「評価」と聞くと難しそうですが、今回は複雑な指標や設定を使わず、かつ、チーム運用は一旦忘れ、まずは 「自分のPC上で、正解データと一致するか」 だけをチェックする気軽な構成を目指します。 なお、プロンプト改善のサイクルを回すことが目的なので、今回は繰り返しテストに適した Dataset Run 機能を利用します。 Datasetの準備 Dataset Runを実行するには、データセットの作成が必要です。 ※ 基本的な作成方法については、以前の記事（ Langfuseデータセット構築ガイド：UI・CSV・SDKの徹底比較 ）にて紹介しています。 しかし、ここで一つ問題が発生します。 期待する結果の値（Expected Output）はテキストなので問題なく登録できますが、 こちらの記事 でも言及し

本ブログでは、Langfuseを複数人で運用する環境下において、「プロンプトを誰でも変更されるのが不安」「うっかり本番用のラベルを動かしてしまった」というヒヤリハットや、「誰でも本番環境を変更できてしまう」というガバナンス上の課題を感じていたチームにとって、必須の機能をご説明します！

プロンプトを修正した後、「なんとなく良くなった」という感覚だけでリリースしていませんか？Langfuseの最新機能「Experiments Baseline」を使えば、変更前後の挙動を定量的に比較し、予期せぬ品質低下（デグレ）を即座に可視化できます。本記事では、Python SDK V3を用いた具体的な実装手順と、リグレッションテストの自動化フローを徹底解説します。

LLM オブザーバビリティプラットフォーム「Langfuse」に機能を追加して、PR がマージされるまでの過程を紹介します。環境構築でハマったポイントや解決方法もまとめているので、日本語でのコントリビュートガイドとしてもお使いください。 この記事で得られること Langfuse 開発環境のセットアップ手順 実際に遭遇したエラーと解決法 セルフホスト/クラウドモードの違いと切り替え方 PR 作成時のベストプラクティス コントリビュートの背景 セルフホスト環境で Langfuse を使っていて、Vertex AI の認証に Application Default Credentials（ADC）  を使いたかったのですが、その機能がありませんでした。AWS Bedrock には既に ADC 対応があったので、Vertex AI にも同様の機能を実装することにしました。 成果 : PR #11039  がv3.140.0でマージされました 🎉 （私の PR #10915  が取り込まれたもの） まずは公式ドキュメントを読もう Langfuse には充

This article presents a focused comparison between the newly released Langfuse MCP Server and the existing Dify Langfuse Plugin, specifically for prompt management within Dify workflows. The core purpose is to help Dify users choose the optimal tool. The MCP Server is positioned as the official gateway to Langfuse's full feature set, including specialized tools for Chat prompt creation (createChatPrompt) and label management (updatePromptLabels).

Langfuse MCPサーバーは、プロンプト管理をDifyから統一されたHTTP API経由で操作するための公式エンドポイントとしてリリースされました。これにより、Chatプロンプトの作成やラベルの厳密な管理（updatePromptLabels）など、Langfuseのフル機能にアクセスできる点が特長です。しかし、Difyの仕様上、同じサーバーURLで複数のLangfuseプロジェクトを同時に扱えず、またプロンプト取得時の変数置換機能も内蔵されていません。 一方、弊社が開発したDify Langfuseプラグインは、Difyユーザー特有のニーズに対応しています。特に、Get Promptツールに変数置換機能が組み込まれているため、プロンプトテンプレートの動的な利用がDifyのコード実行ブロックなしで実現でき、ワークフローを簡略化できます。また、認証設定をブロックごとに行えるため、複数のLangfuse組織・プロジェクトを同時に運用する柔軟性があります。

Google Cloud IAP保護下のLangfuseで課題となる、トークンの有効期限切れ（1時間）への対策を解説。Python SDKを利用し、httpxとOpenTelemetry ExporterでIAPトークンを動的に更新・維持する実装方法を紹介します。

はじめに Langfuseは、LLMアプリケーションの観測性、プロンプト管理、評価を一元管理できるオープンソースプラットフォームです。セルフホストでの運用が可能で、多くの企業が自社環境での導入を進めています。 セルフホストには2つの選択肢があります OSS版（無料・MIT License） : すべてのコア機能が無制限で利用可能 Enterprise版（ライセンスキー必要） : OSS版の機能に加え、Enterpriseグレードのセキュリティ・管理機能を提供 本記事ではEnterprise版で追加される主要な機能と、その具体的なユースケースを詳しく解説します。「OSS版で十分なのか？」「Enterprise版が必要になるのはどんな時か？」という疑問に答えます。 OSS版 vs Enterprise版 重要なポイント：コア機能は完全に同じ まず理解すべき重要なポイントは、 OSS版でもEnterprise版でも、Langfuseのコア機能に一切の制限がない ということです。 両バージョンとも以下が利用可能： トレーシング（エージェント対応） プロ

はじめに LLMアプリケーション開発において、テキストだけでなく画像や音声などのマルチモーダルなデータを扱うケースが増えています。Langfuseは2024年8月に初めてマルチモーダルトレースのサポートを発表し、同年11月には画像、音声、PDFなどの添付ファイルにも対応する完全なマルチモーダルサポートを実現しました。 当該機能は長らくpreviewとされていましたが、先日GAとなったようです（※中の人がSlackでそう言ってました）。 そこで本記事では、Langfuseのマルチモーダル機能の概要、具体的な使い方、そして利用時の注意点について解説します。 Langfuseマルチモーダル機能の概要 たとえば画像ファイルを含んだトレースを送信した場合、LangfuseのWebUI上では以下のように表示されます。 このように、LLMを呼び出す際に画像データが含まれていた場合、テキストデータだけでなく画像データも同時に確認でき、改善活動の効率が大いに向上します。 （※余談ですが、gpt-4oは寿司ネタにそこまで詳しくないのかもしれません。上記画像にタコにみ

LiveKit Agentsは、WebRTCベースの音声AIアプリケーション開発フレームワークです。STT+LLM+TTSパイプラインでも約2.33秒という高速な応答を実現でき、プリエンプティブ生成やストリーミングTTSなどの最適化技術により自然な会話が可能です。 しかし、Langfuseを使った観測可能性の実装時に、各アクティビティ（agent_session、user_turn、agent_turnなど）が独立したトレースとして記録される問題が発生しました。これは非同期処理でOpenTelemetryのコンテキストが適切に伝播されないことが原因です。 解決策として、プログラム起動時にカスタムトレースIDを生成し、NonRecordingSpanを使ってグローバルコンテキストとして明示的に設定しました。これにより、すべてのスパンが同一トレースIDを継承し、階層化されたトレース構造を実現できました。非同期処理を多用するアプリケーションでは、コンテキストの明示的な管理が重要です。