検索結果

はじめに GoogleのVertex AI Geminiが提供するコンテキストキャッシュ機能は、大量のコンテキストを再利用することで、APIコストを大幅に削減できる強力なツールです。しかし、実際にどの程度のコスト削減効果があるのかを可視化するには、一手間加える必要があります。 本記事では、オープンソースのLLM監視プラットフォームであるLangfuseとGeminiのコンテキストキャッシュを組み合わせ、キャッシュ効果を定量的に監視し、コストの内訳を詳細に把握する方法を解説します。 必要なツール Google Cloud Platform: Vertex AI API 有効化済み Langfuse : OpenSourceの LLM Engineering Platform Python 実行環境: uv または pip でパッケージ管理 実現できること Before（従来） キャッシュを利用しているものの、具体的な効果が不明確  コストの内訳（通常入力 vs キャッシュ）が見えない レイテンシ改善効果が分からない After（本手法） 📊 Langfuse ダッシュボード表示例: ├── 入力トークン: 15 → $0.0000045 ├── キャッシュトークン: 1,189 → $0.0000891 ├── 出力トークン: 1,291 → $0.0032275 ├── 合計コスト: $0.0033211 └── レイテンシ: 自動測定 実装手順 ステップ 1: Langfuse でモデル定義を設定 ※ 今回は、gemini-2.5-flashを利用する前提で手順の説明をします。 1. Langfuse ダッシュボード にログイン 2. Settings > Modelsでgemini-2.5-flashを探し、右のCloneを選択 3. モデルにキャッシュの価格を追加する 今回は、gemini-2.5-flashにcached_tokensとして$0.000000075(2025年8月時点の金額)と入力 ステップ 2: コンテキストキャッシュを作成 ライブラリインストール google-generativeai langfuse python-dotenv 環境変数定義 (envファイル作成) ### .env LANGFUSE_PUBLIC_KEY=[パブリックキー] LANGFUSE_SECRET_KEY=[シークレットキー] LANGFUSE_HOST=[langfuseのホストURL] GOOGLE_CLOUD_PROJECT=[自身のGoogle Cloud Project ID] GOOGLE_CLOUD_LOCATION=global 大量のコンテキストデータを準備（例：長い文書、FAQ、マニュアル、PDF） 今回は長いテキストの文章をキャッシュに入れるようなサンプルになってます。 Vertex AI Clientでキャッシュを作成 📖 公式ドキュメント: Context Cache Create - Google Cloud from google.genai.types import Content, CreateCachedContentConfig, Part content_cache = client.caches.create( model="gemini-2.5-flash", config=CreateCachedContentConfig( contents=[Content(role="user", parts=[Part.from_text(text=long_context)])], ttl="3600s", # 1時間有効 ), ) print(f"キャッシュID: {content_cache.name}") キャッシュを作成するのには以下の制限があります。 最小キャッシュサイズ: 1,024 トークン以上のコンテンツが必要（Gemini 2.5 Flash） 最大コンテンツサイズ: 10MB まで TTL 制限: 最小 1 分、最大制限なし 制限詳細: Google Cloud 公式制限表 コンテキストキャッシュ作成時のprint文で表示された キャッシュID （例：`projects/xxx/locations/global/cachedContents/123`）を保存します。 次の呼び出しで使用するため、環境変数に入れておくと便利です。 # .env GEMINI_CACHE_ID=projects/xxx/locations/global/cachedContents/123 ステップ 3: Langfuse 統合コードの実装 3-1. 使用量データの正確な取得 Gemini APIでは、モデルを呼び出した後のレスポンス内にトークン使用数が含まれています。このレスポンスから得られたトークン数をLangfuseに渡す必要があります。 # キャッシュIDを使用してGemini呼び出し cache_id = "projects/xxx/locations/global/cachedContents/123" # ステップ2で取得 response = client.models.generate_content( model="gemini-2.5-flash", contents="あなたの質問をここに入力", config=GenerateContentConfig(cached_content=cache_id) ) # APIレスポンスから直接取得 usage_metadata = response.usage_metadata cached_tokens = getattr(usage_metadata, "cached_content_token_count", 0) input_tokens = getattr(usage_metadata, "prompt_token_count", 0) - cached_tokens output_tokens = getattr(usage_metadata, "candidates_token_count", 0) 補足 キャッシュから供給されたトークン数は、呼び出し後の response.usage_metadata.cached_content_token_count に入ります GenerateContentConfig(cached_content=cache_id) を付けて呼び出す必要があります。 prompt_token_count は「プロンプト全体（キャッシュ分を含む）」のトークン数です。 通常課金される入力トークンは、全体からキャッシュ分を引いた数で算出をしています。 3-2. Langfuse トレース実装 このサンプルで行っていること（流れ） @observe(..., as_type="generation") で関数を計測対象にし、レイテンシを自動取得 GenerateContentConfig(cached_content=cache_id) を指定して Gemini を呼び出し レスポンス usage_metadata から cached_content_token_count などの使用量を取得 課金対象の入力トークンを prompt_token_count - cached_content_token_countで算出 update_current_generation に model/input/output/usage_details/metadata を渡して Langfuse に送信 モデル定義の単価に基づき、Langfuse 側でコストが自動計算・可視化 サンプルソースコード import os from typing import Any from dotenv import load_dotenv from google import genai from google.genai.types import GenerateContentConfig, HttpOptions from langfuse import get_client, observe load_dotenv() def build_clients() -> tuple[genai.Client, Any]: _ = get_client() project_id = os.getenv("GOOGLE_CLOUD_PROJECT") location = os.getenv("GOOGLE_CLOUD_LOCATION") client = genai.Client( vertexai=True, project=project_id, location=location, http_options=HttpOptions(api_version="v1"), ) return client, _ @observe(name="gemini-cached-call", as_type="generation") def call_gemini_with_cache( client: genai.Client, cache_id: str, query: str, model_name: str = "gemini-2.5-flash", ) -> str: """Call Gemini with context cache and report usage to Langfuse.""" response = client.models.generate_content( model=model_name, contents=query, config=GenerateContentConfig(cached_content=cache_id), ) usage = response.usage_metadata cached_tokens = getattr(usage, "cached_content_token_count", 0) input_tokens = max(0, getattr(usage, "prompt_token_count", 0) - cached_tokens) output_tokens = getattr(usage, "candidates_token_count", 0) langfuse_client = get_client() langfuse_client.update_current_generation( model=model_name, input=query, output=(response.text or ""), usage_details={ "input": input_tokens, "cached_tokens": cached_tokens, "output": output_tokens, }, metadata={ "cache_id": cache_id, "provider": "vertex-ai", }, ) return response.text or "" def main() -> None: client, langfuse_client = build_clients() # Example placeholders for blog readers cache_id = os.getenv( "GEMINI_CACHE_ID", "projects/[Project ID]/locations/global/cachedContents/[cache_number]", ) query = "データサイエンスについて教えて" _ = call_gemini_with_cache(client, cache_id, query) # Ensure data is flushed to Langfuse backend in short-lived processes langfuse_client.flush() if __name__ == "__main__": main() Langfuseダッシュボード可視化 以下の画像のように、キャッシュトークンが別途コストとして出力されています。 命名の注意点 input, output という名前を入れた変数を設定すると、それぞれ Input cost, Output cost に分類されます。 例：cached_input_tokensと命名し、モデル価格をセットすると以下のようにinput costとして描画されるようになります。 キャッシュコストを独立して表示したい場合は cached_tokens など別の名前を使用してください。 cached_tokens は Other cost として独立したカテゴリで表示されます。 まとめ この手法により、以下を実現できます 透明性 : キャッシュ効果の可視化 自動化 : 手動計算不要のコスト監視 継続性 : 長期的なコスト最適化 スケール : 大規模システムでの運用 Gemini のコンテキストキャッシュと Langfuse を組み合わせることで、生成AIの「コスト」「レイテンシ」「再利用性」を定量的にコントロールできます。特に、長文コンテキストやPDF・動画等のマルチモーダルのデータの再利用が多いワークロードでは、入力コストの削減と応答時間の短縮が同時に見込め、AI アプリケーションの運用効率を大幅に向上させることができると思いますので、ぜひGemini のコンテキストキャッシュと Langfuseを利用して、生成AIアプリケーションの開発を進めていただけると嬉しいです。

PIIフィルター用LLMのトレース保存 こちらの記事 で、Langfuse の PII フィルターに LLM を利用する方法について検証しました。 実際の運用では、LLM呼び出しにかかる費用を正確に把握するため、PIIフィルターの実行を含めたトレース記録が求められることがよくあります。ここでは、Langfuse の mask オプションを利用する場合の、PIIフィルターLLMの呼び出しとメインのLLM呼び出しを同一トレース内で記録する方法と、その際の注意点について解説します。 トレース記録の構成イメージ require_mask = True def masking_function(data: any, **kwargs) -> any: global require_mask if require_mask and isinstance(data, str): try: require_mask = False # PII フィルター適用時のトレース保存 with langfuse.start_as_current_generation( name="pii_filter_prompt", prompt=[使用するプロンプト] ) as generation: # LLM呼び出し（マスキング処理） generation.update( output=[フィルター済みデータ], ) finally: require_mask = True return [フィルター済みデータ] langfuse = Langfuse( public_key="****************", secret_key="****************", host="*****************", mask=masking_function, ) # LLM呼び出しのトレース with langfuse.start_as_current_generation( name="llm_called_trace", input=[ユーザの入力], ) as generation: # LLM呼び出し（入力に対する回答取得用） generation.update( output=[LLMの回答], ) この構成では、langfuse.start_as_current_generation の input や generation.update の output に対して、自動的に masking_function が呼び出され、PIIがマスキングされた状態でトレースに保存されます。 注意点：再帰呼び出し（無限ループ）への対策 mask オプションで設定した masking_function 内で、さらに Langfuse のトレース保存（例: langfuse.start_as_current_generation）を行おうとすると、 無限ループ に陥る可能性があります。これは、トレース保存処理自体が mask オプションの対象となり、masking_function が再帰的に呼び出されてしまうためです。 この問題を避けるためには、masking_function の内部でトレースを保存する際に、多重呼び出しを防止する何らかの制御が必要です。 今回のサンプルコードでは、処理を簡潔にするため、グローバル変数 (require_mask) をフラグとして持たせ、masking_function 内部からの呼び出しに対してはフィルターを適用しないようにしています。 実際の運用では、mask オプションを利用せず明示的にマスキング用関数を呼び出す方法や、より堅牢な方法を検討することをお勧めします。 検証結果 今回は、以下の条件でトレースの確認を行いました。 入力値、LLMのプロンプト（PIIフィルター用）:   こちらの記事 でも利用した、以下のダミーデータとプロンプトを利用 入力値 私の個人情報は以下の通りです： 氏名：山田 太郎 Name: Taro Yamada 生年月日：1985年3月15日 Birthday: March 15, 1985 住所：東京都新宿区西新宿2-8-1 Address: 2-8-1 Nishi-Shinjuku, Shinjuku-ku, Tokyo, Japan 電話番号：03-1234-5678 / 090-9999-8888 Phone: +81-3-1234-5678 / +81-90-9999-8888 メールアドレス：taro.yamada@example.com Email: taro.yamada@example.com 運転免許証番号：123456789012 Driver's License: DL-123456789012 パスポート番号：TK1234567 Passport Number: TK1234567 社会保障番号：987-65-4321 Social Security Number: 987-65-4321 クレジットカード情報： - カード番号：4111-2222-3333-4444 - 有効期限：12/25 - セキュリティコード：123 Credit Card Information: - Card Number: 4111-2222-3333-4444 - Expiry Date: 12/25 - Security Code: 123 銀行口座情報： - 銀行名：みずほ銀行 - 支店名：新宿支店 - 口座番号：1234567 Bank Account Information: - Bank Name: Mizuho Bank - Branch: Shinjuku Branch - Account Number: 1234567 プロンプト 以下のテキストから、個人情報をマスクしてください。 # 条件 - マスク処理以外は行わない - テキストの前後に余分なテキストを追加しない - どのようなデータがマスクされたかわかるようにする（例：山田太郎 -> [氏名1]、000-0000-0000 -> [電話番号1]） - 同じ個人情報種別でも、異なる情報の場合は別物であるとわかるようにする（例：山田さんと佐藤さん -> [氏名1]さんと[氏名2]さん） # 置換対象の個人情報 - 氏名 - 生年月日 - 住所 - 電話番号 - メールアドレス - 運転免許証番号 - パスポート番号 - 社会保障番号 - クレジットカード情報(カード番号, 有効期限, セキュリティコード) - 銀行口座情報(銀行名, 支店名, 口座番号) # 対象のテキスト {{userMessage}} LLMのプロンプト（問い合わせ用）： 以下のテキスト中に「山」が何度出てくるか数えて # 対象の文書 [ 入力値 ] 結果概要 問い合わせ用のLLMの下に、PIIフィルター用のLLM呼び出しがネストする形で保存できました。 Langfuseのトレース上では、LLM呼び出し（問い合わせ1回、input、output のフィルター用各1回ずつ）計3回分のトークン数や費用が確認できます。 LLM呼び出し（llm_called_trace）: このトレースでは、問い合わせの LLM 問い合わせにかかった費用と、一連の流れ（問い合わせ＋PIIフィルター）でかかった費用の両方が表示されます。 このLLM への問い合わせ結果を metadata の情報として登録したい場合、mask オプションが適用される作りになっているかを十分に確認する必要があります。上記のコード例では、文字列型以外の場合にマスキング処理が適用されないため、場合によっては metadata に個人情報が除去されていない状態で残ってしまう可能性があります。トレースの output としては個人情報が除去されていても、metadata には生データが残るリスクがあるため、input や output と metadata に保存する形式が異なっている場合は特に、保存内容には注意を払うことが必要です。 冒頭の例のコードでLLM からの結果を metadata に保存（一部抜粋） LLM呼び出し（1つ目のpii_filter_prompt）: langfuse.start_as_current_generation( name="llm_called_trace", input=[ユーザの入力], ) 上記で設定している、input に対して masking_function が呼び出された結果です。 with langfuse.start_as_current_generation( name="pii_filter_prompt", prompt=[使用するプロンプト] ) as generation: # LLM呼び出し（マスキング処理） generation.update( output=[フィルター済みデータ], ) 今回はPII フィルターに対するトレースを保存する際に、 PIIフィルターを適用しないよう制御しています。そのため、 個人情報が除去されていない生データを残さないよう、input は保存しないようにします。 Langfuse で費用を表示したい場合には、モデルとトークン数の情報も必要になります。 GeminiAPIの場合は、LLM の結果情報に含まれているため、 generation.update の際に model, usage_details もあわせて保存すると今回の例のような形になります。 LLM呼び出し （2つ目のpii_filter_prompt） : # LLM呼び出し（入力に対する回答取得用） generation.update( output=[LLMの回答], ) 上記で設定している、output に対して masking_function が呼び出された結果です。ここでも mask オプションが適用されます。 input に対するトレース保存と同様に、input には何も設定しないことで、誤って生データがトレースに保存されることを防ぎます。 まとめ この記事では、Langfuseのmaskオプションを活用し、PII（個人特定情報）フィルターにLLMを用いる際のトレース記録方法とその注意点について深掘りしました。LLM呼び出しにかかるコストを正確に把握するためには、PIIフィルターの実行を含む一連の処理を同一トレース内で記録することが重要です。 Langfuseのmaskオプションは、inputやoutputデータがトレースに保存される際に自動的にマスキング関数を適用できる便利な機能です。しかし、オプションで指定した関数内部で再度Langfuseのトレース保存処理を行うと無限ループに陥る可能性があるため、実際に利用する際は適切かつ堅牢な処理となるよう注意が必要です。 また、metadataに個人情報を保存する際の注意点、PIIフィルターLLMのinputには生データを設定しないことの重要性についても解説しました。 これらの注意点を踏まえることで、PIIを適切に処理しつつ、Langfuseの強力なトレース機能を最大限に活用し、LLMアプリケーションの運用コストと安全性を両立させることができます。実際の運用では、本記事で紹介した内容を参考に、トレース設計を検討することをお勧めします。

n8nとは何か n8nは「nodemation」の略称で、ドラッグ&ドロップ操作や各ノードの設定によってワークフローを作成できる自動化ツールです。300以上の組み込みノードを提供しており、Slack、Gmail、Notion、カレンダー、Webhookなど、様々なサービスとの連携が可能です。コードを書くことなく複雑な自動化フローを構築できる一方で、JavaScript や最近はPython を使用したコードの実行をフローに埋め込むことなどにも対応しています。 Dify との違いは何？ 両方とも基本的にOSSベースのノーコードツールと位置付けてよいと思いますが、Difyは「生成AIアプリを作る」ツール、n8nは「生成AIを含むシステムを繋いで業務を処理する」ツールという違いがあると思います。特に実際のオフィスワークにおいては、生成AIをはじめとして JIRA やCRM, mail, Slack などと連携することが求められるケースも多く、n8n はそのようなケースで非常に有用であると考えられます。またコードを書くこともできるので、痒いところに手が届くところも人気の理由です。 ちなみに n8n は Dify よりも歴史が長く、その分で安定しているという意見もある一方で、現在利用者や人気という点ではほぼ互角に見えます (ただし日本ではローカライズが早かった Dify の方が採用が多いように思われます) Github starsの推移、n8nの歴史は長いが スター数は近い n8n と Langfuse 連携の価値 そんな n8n と Langfuse を連携させる理由の一つは、もちろんTraceを取得することによる処理の可視化です。レイテンシーやコスト、システムの中でどのような処理が行われているかを可視化することは運用上で大きな意味を持ちます。またLLM as a judge などの評価にも利用することも可能となります。 もう一つの価値はプロンプト管理です。n8n の生成AIアプリケーションのノードの中にプロンプトをハードコードしても使い回しや世代管理などをすることができず、管理も煩雑になり、生産的ではありません。以降では、実際の設定方法について記載していきます。 n8n サンプル構成概要 今回の説明には、サンプルとして下図のシンプルなフローを用います。 [構成環境] Version 1.99.1 OSS Self-hosted on CloudRun + CloudSQL (PostgreSQL), [サンプルフロー] n8n フロー チャットでの入力を受け、このフローは以下の動作をします。 Code ノードがプロンプトを Langfuse から取得 そのプロンプトを AI Agentノードの System prompt に入れ、チャットに入力された内容が user prompt として入れられる その情報が Langchain ノード (Langfuse LLM) に入り、そこから今回はVertexAIのModelを呼び出す (これは OpenAI でも Bedrock でも何でも同じです) ひとつずつコードと設定を見てみましょう。 Codeノード コードサンプル const { Langfuse } = require("langfuse"); const langfuseClient = new Langfuse(); return langfuseClient.getPrompt("wording").then(prompt => { const variables = $input.item.json.variables || {}; const systemPrompt = prompt.compile(variables); return { json: { systemPrompt: systemPrompt, userMessage: $input.item.json.chatInput, langfusePrompt: prompt, promptVersion: prompt.version, promptName: "wording", sessionId: $input.item.json.sessionId } }; }); まず langfuse を読み込み、その後に wording という 名前のプロンプトを langfuseから取って、それを SystemPrompt に渡しているだけです。その後、各変数をセットしています。ちなみに Langfuse の host などは環境変数に入れておくなどする必要があり、langfuseパッケージもコンテナの中にモジュールをインストールしておく必要がありますのでご注意ください。また今回は特に使っておりませんが、prompt.compile に変数を渡してあげることで、 Langfuse の中のプロンプトに変数を渡してあげることもできます。 AI Agentノード このノードにはコードは書く必要はありません。Prompt の中に User messageを定義し、System Message として、1. Codeノードで取得した内容を反映させておきます。 前のノードを実行するとこの画像の左側ペインに変数がでるので、それをドラッグ&ドロップして設定するのが簡単 Langchain ノード コードサンプル const { CallbackHandler } = require("langfuse-langchain"); const model = await this.getInputConnectionData("ai_languageModel", 0); const inputData = $input.item.json; const langfuseHandler = new CallbackHandler({ sessionId: inputData.sessionId || `session_${Date.now()}`, userId: inputData.userId || "anonymous", tags: ["n8n", "ai-agent", "production"] }); model.callbacks = model.callbacks || []; model.callbacks.push(langfuseHandler); return model; まず langfuse-langchain パッケージから CallbackHandler クラスをインポートし、次にLLMモデルを取得します。この例ではGoogle Vertex Chat model かモデル名と 0 (最初の接続) を指定してとってきます。とってきたjson からデータを展開し、sessionIDやUserIDを入れております。ついでに n8n などのタグも設定しています。 そしてmodelに callback を追加して、model オブジェクトを AI Agent ノードに渡します。 以上で、やるべきことは終わりです。 Langfuse のTraceを見てみると以下のように記録されているはずです。Langchainを使ってるので、勝手にTokenなども取られています。 プロンプトには "言葉遣いは荒々しい野武士のようにしてください" と指定しており、それをそのままSystem promptとして指定してある。 いかがでしたでしょうか。n8n は簡単に使えるツールですが、生成AIの利用もサポートされており、Langfuseとの組み合わせも実現可能です。ご興味あるかたは、ぜひ試してみてください。

本記事ではDify で作ったLLMアプリケーションをLangfuse で可視化してみた時に、処理はどう見えるのか、そしてどのように役に立つのかをご紹介します。 ＊このブログは 前半 と後半に分かれており、後半パートなります。 はじめに 前半では、Dify で簡単なフローを作ったアプリケーションを使った場合のLangfuseにおけるTraceの可視化についてご紹介しました。 今回はDify でRAG をつかったフローを構成した場合に、どのように詳細を確認できるかについてご紹介します。 Dify でのサンプルアプリの構成 今回のケースで用いたアプリは、以下の処理をします。 ユーザーが知りたい情報を入力 "知識取得" でRAG で情報参照 " テンプレート " で "知識取得" の出力変数から特定の情報を取得 " LLM " でRAG を利用した回答生成 4の結果を出力 Dify でのフロー 実行すると以下のようになります。 入力Text として 「Dify でLangfuse の設定をする方法を教えて」と質問すると、前述の処理を経て、Result として設定方法をコメントしつつ参照したURLを返してくれるという仕様です。 text に知りたい情報の入力をすると、RAGで学習した内容から答えを返してくれる なお今回は、知識取得においてWEBでクロールした情報を登録しました。 Firecrawl と Jina Reader のいずれからから選択することができますが、HTML から MarkDown を生成してくれて簡単にAPIキーを取得できるJina Reader を使用しています。 Jina Reader は何もせずともいきなりアクセスした瞬間にAPIキーが払い出されてるというアグレッシブなWebサイトになっており、 公式サイト の日本語翻訳が怪しいですが性能の良さを感じました。多言語対応しており、有償版でもコストパフォーマンスも良さそうです (つい最近 v2 がリリースされており、Reader自体はツールというかSLMだそうです)。 Jina Readerの設定画面 またJina からは Rerank と Embedding のモデルも提供されており、今回はそれらをRAGの構成に利用しています。RAGにつかったソースは後述の通り英語で、クエリは日本語ですが高い品質があると感じました (ただ元データが英語なので、クエリも英語の方が結果の精度は高いかなとも思いました)。 Jina の各種モデル 今回はあくまでLangfuse での表示が主目的なので、とりあえずデフォルトの10サイトのクロールでLangfuse のBlog記事からデータを以下の通り取得しています。 (余談ですが、特定のフォルダ以下をとるような処理はDify上では正常に動いていないと思われ、トップページなどのURLもクロールしてしまいました。) Langfuse での見え方 ここからが本題のTrace の見え方です。Trace は 前半のブログ にも記載がありますので、必要に応じて合わせてご確認ください 前述のフローを動かした際、Trace の詳細は以下のようになります。 Trace詳細 各Trace をクリックすると、Input/Output, Token, Metadataなどを を確認することができます。この辺りは基本的同じです。ただ今回はRAG の構成にしておりますので、新たに画面右側部分に" Knowledge-retrieval" があることを確認できると思います。 フロー同様、Knowledge-retrieval が Start直後にある そしてOutput としてresult が 0, 1, 2 と返ってきており、その中を見ると参照されたドキュメントやScore などが返却されております。Score が高いほど一致率が高いものであり、0に比べて1 や 2 のSocre は低いことが確認できます。 Scoreなどを含む結果詳細 参考までにこのフローでの1 の結果は以下の通りです。Score 0.33 と0 の結果に比べてだいぶ低いということがわかると思います。これは2 になるともっと低いです。 1 の詳細結果 そして今回は "テンプレート" ツール で、0 についてくる各種データもついでにとってきています。単に配列からデータをとってきているだけです。 {{ result.0 }} Langfuse 側でテンプレートに対応するTrace を見るとこのように表示されています。 resultの0 の値だけを正常に取得できています。 Template-transform そしてLLMには 0の結果を含めて、処理を渡して個別に Metadata 中の Title のValueをアウトプットに含めるように指示しています。 この部分の実際の処理はLangfuse上で以下のように確認できます。 System プロンプトで指示された内容がContext 含めて反映されていることが見てとれ、Title の Value にも取得した元のBlog記事が入っていることがわかります。 そして最終的なアプリの結果は以下のようになっており、期待した通りの動作をしていることを確認することができます。 このようにLangfuse を活用することで、RAGのような処理が必要な際や特定の値をとってくる処理などをした際においても、Dify の各処理を確認しながら、効率的な開発・運用を進めることができます。今回は正常にデータが取れていましたが仮に期待した結果でない場合に、取得元のソースが違うのかなどのdebug にも大変役に立ちます。 Langfuseでの可視化 [Dify編 (後半) ] まとめ 本記事ではLangfuseのTrace機能を通じて、RAGなどを含むDifyの処理の可視化の基本的をご紹介しました。今後、Bedrock やVertexAI などのプラットフォームを使った場合の可視化についても適宜ご紹介をしていきたいと思います。 ガオ株式会社 は企業向けにLangfuse ProおよびEnterpriseプランを日本円で販売し、日本語でサポート提供・導入支援などを実施している唯一の企業です。 Langfuseにご興味ある方は、contact@gao-ai.comまでご連絡ください。

本記事ではDify で作ったLLMアプリケーションをLangfuse で可視化してみた時に、処理はどう見えるのか、そしてどのように役に立つのかをご紹介します。 ＊このブログは前半と 後半 に分かれており、前半パートなります。 はじめに 近年のDifyユーザーの広がりとエンタープライズでの採用事例などから、Dify でも生成AIアプリケーションの可視化ニーズが高まっています。そこでこの記事では、Langfuse を使った可視化についてご紹介します。 なおこの記事ではDify の設定には深く踏み込まず、あくまでLangfuse側でどのような情報が標準では反映されるのかにフォーカスしています。 Dify とLangfuse の設定の詳細手順については、 Difyの公式ページ をご参照ください。 手順といっても特に難しいことはなく、実際は各アプリケーション左側のメニューバー一番下の "監視" をクリックしていただければ、あとはキー情報などをいれるだけです。 赤丸のところが "監視" です Dify でのサンプルアプリの構成 まず今回のケースで用いたアプリは、以下の処理をします。 ユーザーがファイルアップロード "テキスト抽出ツール" でテキストを抽出 " LLM1 " で 原文に忠実に翻訳 " LLM2 " でそれをレビューして修正 " LLM3 " で不要な文字は全て排除して、マークダウンに変更 5の結果を出力 Dify フロー図 抽出、翻訳、レビュー、整形を行っている 実行すると以下のようになります。 特に何の変哲もないアプリケーションなので、詳細な処理は割愛します。 複数段階の処理を経て、最終的にMarkDownで出力される ここまでが前置きで、ここからLangfuse側で状態を見ていきます。 Traceとは Dify側で "秘密キー" , "公開キー", "HOST" を入れていることを確認し、Langfuse側で状況を見てみます。フローを実行してまもなく、Trace に新しいエントリがあることがわかります。 Trace一覧 (見やすい表示項目は絞っていますが、コストや自動評価スコアなども表示可能です) 改めてご説明するとTrace の定義は以下のとおりです。詳細は こちら も確認ください。 なんとなくでもご存知の方は以下の点線内は飛ばして先に進んでいただけます。 Traces A Trace represents a single execution of a LLM feature. It is a container for all succeeding objects. 訳: Trace はLLM機能の単一実行を表します。これはすべての後続オブジェクトのコンテナです Observations Each Trace can contain multiple Observations to record individual steps of an execution. There are different types of Observations: Events are the basic building block. They are used to track discrete events in a Trace. Spans track time periods and include an end_time. Generations are a specific type of Spans which are used to record generations of an AI model. They contain additional metadata about the model, LLM token and cost tracking, and the prompt/completions are specifically rendered in the langfuse UI. 訳: 各Traceは、実行の個々のステップを記録するための複数のObservations を含めることができます。Observations にはさまざまな種類があります。 Event は基本的な構成要素です。これらは、トレース内の個別のイベントを追跡するために使用されます。 Span は時間期間を追跡し、end_timeを含みます。 Generation は、スパンの特殊なタイプであり、AIモデルの世代を記録するために使用されます。これには、モデル、LLMトークン、コスト追跡に関する追加のメタデータが含まれ、プロンプト/補完は、特にlangfuse UI でレンダリングされます。 Traceの中の構成, Generation が処理のアウトプットに相当する 参照: https://langfuse.com/guides/cookbook/python_sdk_low_level#tracing Langfuse での見え方 Traceの詳細 各Trace をクリックすると、このようにInput/Output を確認することができます。 Trace名 workflow の下には、日時と所要時間とToken 数が見て取れます。Dify 側で出すInput/Out Token とLangfuse 側の取り扱いが原因で、ゼロになってますが合計のToken も確認することができます。 まずこのTrace のInput とOutput を確認することが可能ですが、それに加えて下の方にはDify で付与したMetadata があることも確認できます。 Traceのメタデータ そして右側のメニューを Tree から Timeline に切り替えると、どこの処理でどの程の時間がかかったかを視覚的に見ていただくことも可能です。 またフロー各処理のタイムライン ただ、ちょっと問題なのはDifyで3つあったLLM での処理と各アウトプットが全部 llm で名称が統一されてしまっており、Langfuse の画面だけで分からない (DifyのUIの仕様) 問題があります。これについては、各GENERATION をクリックして中身から確認が可能です。 この画面ではGENERATION の詳細で、Systemプロンプトなどの他にレイテンシーやToken、Model などの情報が確認できます。 GENERATIONSの詳細 この画面の下の方では、Metadata が表示されておりDIfyのノード名やタイプなどの情報を 確認することができます。 node_name として定義されている部分です。 GENERATION の Metadata ちなみに結果がうまく出ないなど、本当に文章抽出されてる？など思った時にはSPANとして document-extractor を見ていただくと実際のOUTPUTなどの詳細を確認することができます。ここから更に Debug が可能です。 document-extractor (Outputを確認できる) このようにLangfuse を活用することで、ブラックボックスになりがちなDify の各処理を確認しながら、効率的な開発・運用を進めることができます。 Langfuseでの可視化 [Dify編 (前半) ] まとめ 本記事ではLangfuseのTrace機能を通じて、Difyの処理の可視化の基本的をご紹介しました。次回はもう少し深掘りして、RAGを行った場合について触れていきます。 ガオ株式会社 は企業向けにLangfuse ProおよびEnterpriseプランを日本円で販売し、日本語でサポート提供・導入支援などを実施している唯一の企業です。 Langfuseにご興味ある方は、contact@gao-ai.comまでご連絡ください。

はじめに 本記事では、Agent Development Kit (ADK) によって構築されたAIエージェントの挙動をLiteLLMを通じてLangfuseで可視化する方法について解説していきます。 ADKの基本的な内容やその評価については こちら Langfuse についての 説明についての記事は こちら 生成AIアプリケーションやAIエージェントを開発し、そのパフォーマンスを最大限に引き出す上で、内部処理の可視化は成功の鍵を握ると言っても過言ではありません。これは、ADKを用いた開発においても例外ではありません。 可視化ツールとして Cloud Trace のような選択肢も考えられますが、本記事では、導入の容易さ、直感的な操作性、そして LLMOps 全体のトレーサビリティをオープンソースで実現できるLangfuseに焦点を当てます。 ただし、ADK から Langfuse へ直接Traceを連携させようとすると、現時点（2025年5月8日）では注意が必要です。例えば、OpenTelemetry 経由で Langfuse にトレースを送信した場合、全ての情報がメタデータとして一括りに扱われてしまい、詳細な分析やデバッグが困難になるなどの課題があります。 そこで本記事では、この課題を解決し、ADKで開発するエージェントの情報を Langfuse 上で効果的に可視化するためのアプローチとして、ADK と Langfuse が共にネイティブサポートしている LiteLLM を利用する構成をご紹介します。この構成を採用することで、LLM とのやり取りを含む詳細なトレース情報を、構造化された形でスムーズに Langfuseへ連携させることが可能になります。構成はおおまかには以下のようになります。 ADK で作ったAgentと同じ環境にProxyとしてLiteLLMを起動 それでは、LiteLLM のセットアップから進めていきましょう。 LiteLLM とは LiteLLMは、OpenAI、Azure、VertexAI/Gemini、Anthropicなど、100種類以上の様々な大規模言語モデル（LLM）に対して、統一されたシンプルなインターフェースでアクセスできるようにするライブラリです。 これにより、開発者は特定のLLMプロバイダーにロックインされることなく、アプリケーションの要件に応じて最適なモデルを柔軟に選択・切り替えることが可能になります。 LiteLLM は、APIキー管理、呼び出しのフォーマット統一、そしてリクエストのロギングやコールバック, 同一コードでの切り替え, 帯域制限やコスト管理といった機能など提供し、LLM 運用において大きな助けとなります。LiteLLM には SDK として利用するモードと、Proxy として動作させるモードがありますが、今回はついでにProxy モードのセットアップ方法も紹介しながら構成を作っていきます。 LiteLLM (Proxyモード) のセットアップ セットアップは非常にシンプルです。 公式の手順 がありますので、基本的にはこれに沿って進めるだけで立ち上げることが可能です 。 litellm_config.yaml に model 定義などを入れるのですが、今回は以下のような設定をしています。 model_list: - model_name: gpt-4o litellm_params: model: openai/gpt-4o api_key: "os.environ/OPEN_AI_API_KEY" - model_name: gemini-2.0-flash litellm_params: model: vertex_ai/gemini-2.0-flash vertex_project: "YOURPROJECTNAME" vertex_location: "us-central1" vertex_credentials: "os.environ/VERTEXAIFILE" - model_name: gemini-2.5-flash litellm_params: model: vertex_ai/gemini-2.5-flash-preview-04-17 vertex_project: "YOURPROJECTNAME" vertex_location: "us-central1" vertex_credentials: "os.environ/VERTEXAIFILE" general_settings: master_key: sk-1234 litellm_settings: drop_params: True success_callback: ["langfuse"] redact_user_api_key_info: true module list の中に、model_name として任意の名前をつけ、後ほどこの名前をプログラム内から利用することで、指定したモデルが使われるようになります。APIキーやクレデンシャルは、.env ファイルを作り、環境変数として読みこませておきます。 そして設定最下部に success_callback: ["langfuse"] を入れることを忘れないようにしましょう。逆にいうとLangfuse のための設定はこの１行だけという簡単さです。 続いて環境変数ファイル (.env)を、以下のような内容で作成します。 export LITELLM_MASTER_KEY="sk-1234" export LITELLM_SALT_KEY="sk-1234" export LANGFUSE_PUBLIC_KEY="pk-lf-****" export LANGFUSE_SECRET_KEY="sk-lf-****" export LANGFUSE_HOST="YOURLANGFUSEHOSTURL" export OPEN_AI_API_KEY="sk*****" export VERTEXAIFILE="FILENAME" export OPENAI_API_BASE= http://localhost:4000/v1 続いて docker-compose.yml をちょっと編集します。volumes と command が最初はコメントアウトされているので、それをアンコメントして、VertexAI認証用のファイルを読み込ませています。(セキュリティ的にベストプラクティスではないですが、一時的な検証用ということで簡単な方法で実装しています) もちろん、たとえばOpenAI だけで良い場合は対応不要です。 volumes: - ./litellm_config.yaml:/app/litellm_config.yaml - /SOURCE.json:/app/vertexaifile.json command: - "--config=/app/litellm_config.yaml" docker compose up で Proxy を起動し、以下のように curl で疎通確認をしてみてください。結果をLangfuse内で Trace として確認できるはずです。 % curl --location 'http://0.0.0.0:4000/chat/completions' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer sk-1234' \ --data '{ "model": "gpt-4o", "messages": [ { "role": "user", "content": "気の利いたアメリカンジョークをかましてくれ！" } ] }' すると、Langfuse側では以下のように Trace を確認することができます。 ジョークはつまらないですが、Trace は見えます ここまでで一旦準備は完了です。 ADK のコードを準備する 基本的には全て こちらのコード を利用し、以下に示す点のみを編集するだけです。 agent.py の冒頭で LiteLLM のモジュールをインポートします。 from google.adk.models.lite_llm import LiteLlm from google.adk.agents import LlmAgent 続いて最下部を以下の通りに変更します。 lite_model = LiteLlm(model="openai/gemini-2.0-flash") root_agent = LlmAgent( name="weather_time_agent", model= lite_model, description=( "Agent to answer questions about the time and weather in a city." ), instruction=( "You are a helpful agent who can answer user questions about the time and weather in a city." ), tools=[get_weather, get_current_time], ) 以上です！ LiteLlm の中の model には litellm_config.yaml であらかじめ定義したmodel名を定義しますが、その際に指定した openai インターフェイスに則った LiteLLM Proxy のエンドポイントを指定するため、明示的に "openai/" と指定しています。Google が提供する LLM であるGemini にアクセスするのに openai/gemini という記載になることに違和感があるかもしれませんが、これにより OPENAI_API_BASE と .env に定義した先にリクエストが飛ぶようになるため、必須の設定となります。 そして、実行するとこのように出力されます。(フォルダ名は任意に変えてください)  % adk run adk_agent Log setup complete: /var/folders/ys/8vpjq9657dnb3dvq33k6q_hm0000gp/T/agents_log/agent.20250508_213004.log To access latest log: tail -F /var/folders/ys/8vpjq9657dnb3dvq33k6q_hm0000gp/T/agents_log/agent.latest.log Running agent weather_time_agent, type exit to exit. [user]: new york 21:30:14 - LiteLLM:INFO: utils.py:2827 - LiteLLM completion() model= gemini-2.0-flash; provider = openai 21:30:15 - LiteLLM:INFO: utils.py:2827 - LiteLLM completion() model= gemini-2.0-flash; provider = openai [weather_time_agent]: OK. The weather in New York is sunny with a temperature of 25 degrees Celsius (77 degrees Fahrenheit). The current time in new york is 2025-05-08 08:30:15 EDT-0400. ちなみに上記コマンドを入れた際、以下のようなエラーが出るかもしれません。 litellm.exceptions.AuthenticationError: litellm.AuthenticationError: AuthenticationError: OpenAIException - Authentication Error, Invalid proxy server token passed. key=******, not found in db. Create key via /key/generate call. エラーの原因は、LiteLLM Proxy が「渡されたトークン」を自身のデータベースで認識しておらず、認証に失敗しているためです。その際には以下のようなコマンドを実行して、keyを発行してみてください。 curl --location 'http://0.0.0.0:4000/key/generate' \ --header 'Authorization: Bearer sk-master-あなたが決めたキー' \ --header 'Content-Type: application/json' \ --data-raw '{ "models": ["gpt-4o"], "metadata": {"user": "your-user-id"} }' そうすると key を含んだJSONが返却されますので、agent.py と同じディレクトリ下に置く .env に以下のような形式でKeyを追加しておいてください。 export OPEN_AI_API_KEY="sk-***" なお locahost: 4000 でブラウザ経由でもアクセス可能ですので、LiteLLM は UI上から操作しても問題ないでしょう。 そしてエラーがなくなれば、以下のような出力を Langfuse 上で確認できます。 Agent の挙動を確認可能 いかがでしたでしょうか？ LiteLLM を通じて、Trace が入ることを確認いただけたかと思います。ぜひお手元のADK 環境でも試してみてください！また別の機会に LiteLLM の機能の掘り下げた記事も公開していきたいと思います。Langfuse 可視化のみならず、LLMOps のサイクルをオールインワンで解決できることが強みです。ぜひこれを機会に活用してみてください。

2025年4月9日にLangfuseのTownhall が開かれ、そこで直近のメジャーリリースと今後の予定について発表がされました。Langfuseのアップデートについてその速度と進化をシェアすべく、主な内容をまとめてみました！ オリジナル動画はこちら Langfuse Q1 2025 アップデートまとめ 特にTrace におけるグラフ表示やJavaクライアントのサポート、またプロンプト管理などは待望の機能となっています！ Trace のUI が刷新され大幅に改善: LangGraph などのエージェントフレームワークのグラフ表示 、デバッグ情報の非表示オプション、統合されたタイムライン、トレースプレビュー機能の追加とキーボードナビゲーションが可能になりました。 https://langfuse.com/changelog/2025-02-14-trace-graph-view ビヨンビヨン動いて楽しいのと、どこで何が起きてるのか非常に追いやすい。 ネイティブ環境サポート (Environmentの設定) が追加: 環境に基づいたトレースとプロンプトの分離 とUIでの選択が可能になりました。 OpenTelemetryエンドポイント が導入: 様々なフレームワークや技術スタックとの互換性が大幅に向上 しました。また Javaクライアント がリリースされ、 JavaアプリケーションでのLangfuseの利用 が可能になりました。 プロンプト管理: UIの刷新、コードスニペットのコピー機能の改善、プロンプトの合成機能、保護されたプロンプトラベル (adminなどだけが変更できるラベル)、変数リンティング機能付きの新しいコードエディタ、コミットメッセージの追加、Langfuseプロンプト用のMCP（Model Context Protocol）サーバーのリリース が行われました。 プレイグラウンド: ツール呼び出しと構造化出力がサポート されました。 セルフホスティング: バージョン1のHelm chartのリリースと、AWS用のTerraformリポジトリの公開 が行われました。 UIの改善: オンボーディング画面の追加とコマンドパレットによるナビゲーションの改善 が行われました。 評価機能: 履歴データに対するElement Judge評価の実行、評価プロンプトへのデータ挿入をより具体的に指定するためのJSONパスのサポート、CSVファイルによるデータセットのアップロード が可能になりました。 APIの更新: 新しいAPIリファレンスの公開、アノテーションキューとスコア構成用の新しいAPI、Python、JavaScript、Java用の型付きクライアントの追加 が行われました。 セキュリティ機能: UIおよびAPIによる単一またはバッチでのトレース削除、プロジェクトレベルでのデータ保持ポリシーの設定、Audit logの利用 が可能になりました。 Langfuse Q2 2025 ロードマップまとめ Tracing : Full text検索 の初期デモが近日公開予定であり、最優先事項の一つです。 Analytics : データに基づいて独自のビューを作成できる カスタマイズ可能なダッシュボード と、アプリケーション内でのチャート表示やデータ集計に利用できる クエリAPI が近々提供されます。 OpenTelemetry : Langfuse SDKの内部を OpenTelemetryネイティブ に移行する作業が進められています。 評価 (Evaluation) : セッションレベルの評価 の改善、コアな評価ビューの改善、データセット実験のアノテーションの簡略化が予定されています。 管理API (Admin API) : 組織とプロジェクトのプロビジョニングと管理を可能にする Admin SCIM API のドラフトがあります。 セルフホスティング : セルフホスティングの開始方法に関するドキュメント が来週再リリースされ、スケーリングに関するガイダンスも提供されます。 エージェント : エージェントグラフの汎用化、ツール呼び出しやツール検出に関する 可視化オプション の追加、より 意見の強いエージェント評価 機能の構築が計画されています。 UI : テーブルのUI改善が予定されています。 プロンプト管理 : プレースホルダー の導入、本番環境のトレースにおけるプロンプト変数の追跡、Elementによるプロンプトエンジニアリング支援、 フォルダ によるプロンプト整理機能、 ABテスト 機能、 ツール呼び出しと構造化出力のネイティブサポート が計画されています。 データプラットフォーム : Webhook が追加され、Langfuse内の変更に基づいて外部アクションをトリガーできるようになります。また、 アラート 機能も検討されています。 プロンプト実験とプレイグラウンド : プロンプトプレイグラウンドへの 分割ビュー の追加、プロンプト実験への ツールと構造化出力のサポート の拡充が計画されています。 Langfuse Cloud : HIPAAコンプライアンス への対応が検討されています。また、 使用量に基づく請求アラート 機能が追加される予定です。 設定可能なダッシュボード : 最も要望の多かった機能の一つである 設定可能なダッシュボード の早期ベータ版がLangfuse Cloudでリリースされました。 これらのアップデートは、有償版ユーザーとコミュニティからのフィードバックに基づいて優先順位付けされており、GitHub Discussionsでの議論から多くの機能が実装されています。 気になる内容などあれば、お気軽にGithub あるいは GAO までお問い合わせください ！

本記事は、LLM（大規模言語モデル）アプリケーション開発プラットフォームであるLangfuse と LangSmith を比較するものです。両プラットフォームは、開発者が LLM を活用したアプリケーションを構築・運用することを支援しますが、その出自、焦点、実装において違いがあります。各セクションで、主要な基準で両者を比較し、対比を行なっていきます。なお内容は 2025年2月26日時点においての公開情報をもとに作成されております。 またセルフホスト版における費用比較は LangSmith 側の Web 上などに公開情報がないため、対象外となっています。 ------ TL;DR (2025年04月25日 修正) 多くの相違点と類似点がありますが、最終的に論点は以下に点に収束します。 ぜひ皆様のユースケースに照らし合わせてご確認ください。 OSS が持つガバナンスや今後のロードマップなどの透明性 (Langfuse) or 従来型のProprietary (LangSmith) という観点からの Pros/Cons の検討 自分の環境内に立てたいか (セキュリティポリシー的の観点) or SaaS 厳密なコスト計算シナリオ (ただし SaaS の場合は大きく変わらない) LangChain との緊密なインテグレーションをどの程度重要視するか ------ 1. 基本概要 (Basic Overview) Langfuse: 開発元: Langfuse GmbH (Finto Technologies) 概要:  オープンソースのLLMアプリケーションエンジニアリングプラットフォーム。 主な目的:  チームがLLMアプリケーションを「共同でデバッグ、分析、反復」することを支援すること。開発ワークフローを加速するために、すべての機能が統合されています。 特徴: 特定のフレームワークに依存しない。 本番環境での利用を想定して構築。 オープンソースであるため、高い柔軟性とカスタマイズ性を持つ。 LangSmith: 開発元:  LangChainチーム 概要:  プロプライエタリ（閉鎖的）なエンドツーエンドのプラットフォーム。 主な目的:  LLMアプリケーションのライフサイクルのあらゆる段階に対応する、オールインワンの開発者プラットフォームを提供すること。 特徴: 特にLangChainユーザーを対象としているが、あらゆるLLMアプリケーションで利用可能。 綿密な監視と評価に重点を置き、開発者が信頼性の高いアプリケーションを迅速に提供できるよう支援。 SaaS (Software as a Service) として提供される (エンタープライズ向けのセルフホストオプションあり)。 LangChainエコシステムと緊密に統合されている。 要約:  Langfuse (Langfuse GmbH) はオープンソースでフレームワーク非依存。LangSmith (LangChain) はLangChainユーザー向けに設計されたプロプライエタリなエンドツーエンドプラットフォームですが、あらゆるLLMアプリケーションで利用可能です。どちらも、LLMアプリケーションの開発/監視/運用の効率化を目指しています。 2. 主要機能 (Main Features) 両プラットフォームは、トレース、デバッグ、プロンプト管理、評価、フィードバック収集など、豊富な機能セットを提供します。以下の表では、主要な機能を比較し、実装や重点の違いを強調します。 機能 Langfuse LangSmith トレース & デバッグ LLM可観測性:  完全な実行トレース (LLM呼び出し、ツール呼び出しなど) を完全なコンテキストとともにキャプチャ。ネストされたチェーン、並列呼び出し、マルチモーダルデータをサポート。複数ターンの会話のためのセッションビューと、レイテンシをデバッグするためのタイムラインビューを提供。開発者は、LangfuseのSDKまたは統合を介してコードを計測し、各ステップをログに記録。 可観測性 & トレース:  LangChain/LangGraphアプリ用の組み込みトレース (自動計測) と、あらゆるアプリ用のAPI/SDKを提供。カスタムダッシュボードとアラートでトレースを分析可能。呼び出しシーケンスを完全に可視化し、エラーやボトルネックをリアルタイムで特定。トレースをリンクで共有して共同作業を可能にし、2つのトレース実行を並べて比較することも可能 (回帰デバッグ用)。 プロンプト管理 中央集約型プロンプト管理:  プロンプトを共同で作成、編集、バージョン管理するためのコンソールを提供。プロンプトはコードから分離されており、新しいバージョンはアプリを再デプロイすることなくデプロイ可能。複数形式のプロンプト (テキストまたはチャット) をサポートし、バージョン管理とロールバック機能を備える。非開発者はUIを介してプロンプトを更新可能 (役割ベースのアクセス)。プロンプトの変更は経時的に追跡され、トレースにリンクされて影響を確認可能。また、 Playground  を提供し、プロンプトを単独で即座にテスト可能。 LangSmith Hub (プロンプトエンジニアリング):  プロンプトを作成し、自動バージョン管理で反復するためのWeb UI。ユーザー (非エンジニアを含む) は、プロンプトテンプレートを作成し、入力変数を設定し、コメントや共同作業が可能。すべてのプロンプト編集は追跡され、ロールバックと比較が可能。統合された Prompt Playground  により、デプロイ前にモデル (カスタムまたはOpenAI互換エンドポイントを含む) に対してプロンプトをテスト可能。LangSmithのプロンプトハブはチームの共同作業に重点を置いており、プロンプトはチームメンバー間で簡単に議論および共有可能。 評価 (自動化) LLM-as-a-Judge:  出力に対するLLMによる自動評価をサポート。Langfuseは、トレース (本番環境またはテストシナリオ) に対して「Evaluator」を実行し、スコアを生成可能。開発者は評価基準 (例: 正確性、関連性あるいは独自に基準) を定義し、モデルを使用して応答をスコアリング可能。これらのスコア (数値、ブール値、カテゴリ) は、トレースまたは特定のステップに付加。Langfuseは、カスタム評価指標をログに記録するためのAPI/SDKも提供。 AI支援評価:  LangSmithは、関連性、正確性、有害性など、一般的な基準に対するカスタム評価器と 既製の評価器  の両方を提供。ユーザーは、LLMと提供されたプロンプトを使用して出力を自動的にスコアリングするか、事前に構築された評価モジュールを使用可能。LangSmithは 回帰テスト  と オンライン評価  を重視しており、ライブ実行を継続的に評価し、品質の低下を検出可能。評価結果は各実行のメトリックとして保存され、品質がしきい値を下回った場合にアラートをトリガー可能。 フィードバック & アノテーション ユーザーフィードバック:  Langfuseは、出力に関するエンドユーザーのフィードバックを収集し、トレースに付加することを可能にする。たとえば、ユーザーからのGood/Badなどを、Browser SDKまたはAPIを介して取り込むことが可能。すべてのフィードバックはトレースデータに付加されなり、低品質の結果を特定するために使用可能。 手動アノテーション:  Langfuseには、内部レビュー担当者が出力にラベルを付けたり、手動でスコアリングしたりするための アノテーションキュー  システムが含まれる。これは、トレースのサンプルに対してグラウンドトゥルースラベルを作成するのに役立つ。プラットフォームは、人間のアノテーターのワークフローをサポートし、自動スコアとともにその判断を追跡。 人間のフィードバック統合:  LangSmithは、任意の実行に対して 「人間のフィードバックを重ね合わせる」  ことを可能にする。チームは、LangSmithアプリで アノテーションキュー  を設定し、人間にモデル出力をレビューおよびラベル付けさせることが可能。これは、体系的な評価やファインチューニングデータの収集に役立つ。エンドユーザーのフィードバックもキャプチャ可能 (たとえば、アプリケーションがユーザーに応答を評価するように求める場合)。すべてのフィードバックはトレースとともにログに記録され、ダッシュボードで使用したり、メトリックを計算したりするために使用可能。LangSmithのUIはアノテーション用に統合されており、割り当てられたレビュー担当者はプラットフォーム内で直接ラベル付け可能。 データセット & テスト データセット & 実験:  Langfuseでは、実際の例 (特に失敗例や重要なクエリ) からデータセットを構築可能。これらのデータセットは、テストスイートまたはベンチマークとして機能。これらのデータセットに対して プロンプト実験  またはチェーン実験を実行可能。たとえば、同じ入力セットに対して異なるプロンプトバージョンまたはモデル設定を並べて比較。プラットフォームは、各実験のメトリック (精度、コスト、レイテンシ、またはカスタムスコア) を表示し、最適化をガイド。これは、 デプロイ前のテスト  (新しいバージョンを出荷する前の回帰テスト) と、本番環境の外れ値を定期的にテストセットに追加することによる 継続的な改善  をサポート。 データセット & 評価スイート:  LangSmithは、デバッグ実行またはアップロードされたデータから データセットを構築  するためのツールを提供。これらのデータセットは、体系的なテストのために、入力と期待される出力 (または参照出力) をグループ化。LLMベースの評価器またはカスタムテスト関数のいずれかを使用して、データセットに対して バッチ評価  を実行可能。プラットフォームは 回帰テスト  をサポートしており、同じデータセットでアプリケーションのパフォーマンスをバージョン間で比較。たとえば、プロンプトまたはモデルを更新した後、保存したデータセットを再実行し、評価スコアが向上したか低下したかを確認可能。これにより、各反復で品質が確実に向上。 監視 & メトリクス ダッシュボード:  Langfuseには、品質スコア、レイテンシ、LLM呼び出しのコストなどの主要なメトリックを監視するための組み込みダッシュボードが含まれる。トレースがストリーミングされると、これらの集計メトリックを経時的に追跡可能 (例: 平均応答時間、成功率、ユーザーフィードバックのスコア)。Langfuseはこれらの洞察をアプリ内で提供することに重点を置いているが、ドキュメントにはカスタムアラートルールについては明示的に言及されていない。(必要に応じて、APIを介してデータをエクスポートし、外部監視を行うことは可能。) コスト追跡は、ユーザーごとまたは全体的なAPI使用料を監視するためにサポート。タグ、ユーザーID、またはバージョンによるトレースの詳細なフィルタリングがUIでサポートされており、特定のシナリオを掘り下げることが可能。 ダッシュボード & アラート:  LangSmithは監視に重点を置いている。ユーザーは、1秒あたりのリクエスト数、エラー率、レイテンシ、コストなどのメトリックを経時的に表示するためのカスタム ダッシュボード  を作成可能。プラットフォームでは、 アラート/自動化ルール  を設定可能。たとえば、メトリックがしきい値を超えた場合や、評価スコアが低下した場合に通知。LangSmithは オンライン評価監視  もサポートしており、ライブトラフィック (AIまたはメトリックを使用) を継続的に評価し、リアルタイムで問題をフラグ付け可能。組み込みのフィルタリングと検索は、トレースデータを (モデル、時間枠、タグなどによって) 分割するのに役立ち、インターフェースは調査のために異常 (エラーまたはレイテンシのスパイク) を強調表示。 共同作業 チームコラボレーション:  オープンソースツールであるLangfuseは、セルフホストして複数のチームメンバーで使用可能。組織向けの役割ベースのアクセス制御 (RBAC) をサポート (上位プランで利用可能)。それぞれのOrganizationやプロジェクトといった単位を活用しながら、1つのインスタンスで管理できる。コラボレーションは主に、Langfuseダッシュボード、プロンプト、トレース、データセットなどへのの共有アクセスを通じて行われる。 共有 & コラボレーション:  LangSmithはチームワークを念頭に置いて構築。複数のユーザーと組織に対してきめ細かい権限 (Plus/Enterpriseプラン) を提供。特に、 トレース共有  は機能の1つであり、開発者はトレースへの公開共有可能なリンクを生成し、同僚や利害関係者に送信可能。このリンクを使用すると、他のユーザーは透明性のために実行チェーン全体を表示可能。 LangSmith Hub  は、プロンプト設計におけるコラボレーションも可能にし、チームメンバーはプロンプトにコメントでき、非技術的な専門家は直接貢献可能。要約すると、LangSmithはすぐに使えるより多くのアプリ内コラボレーションツール (コメント、共有リンク) を提供する一方、Langfuseは複数ユーザーアクセスと外部ディスカッション (またはサードパーティ統合) に依存してコラボレーションを行う。 機能における主な違い:  両プラットフォームは、エンドツーエンドのLLM開発サイクル (プロンプト設計から監視まで) をカバーしています。Langfuseはオープンソースであるため、セルフホスト環境での柔軟性と統合を重視しており、 可観測性  と 評価パイプライン  を中心に強力なコアを備えています。LangSmithはマネージドサービスとして、LangChainとの容易な統合、既製の評価器、カスタムダッシュボード/アラート、組み込みのコラボレーション (共有とコメント) などの ユーザーエクスペリエンス  機能に特に重点を置いています。LangChainを頻繁に使用する場合 (計測のオーバーヘッドがない) はLangSmithが優位に立つ可能性があり、一方、Langfuseはフレームワーク非依存のカスタマイズ可能なソリューションが必要な場合や、セルフホストのオープンソースを好む場合に優れています。 3. 統合性 (Integration) LangfuseとLangSmithはどちらも、さまざまなツール、ライブラリ、APIと統合して使いやすさを向上させています。以下に、統合機能の比較を示します。 言語SDK & API: 両者とも、複数の言語の公式SDKを備えたAPIファーストのアプローチを提供。 Langfuse: Python  と TypeScript/JavaScript SDK 、および適切に文書化されたREST APIを提供。 LangSmith: 同様に Python  と JS/TS SDK 、およびトレースをログに記録するためのREST APIを提供。 つまり、どちらのプラットフォームも、APIを呼び出すかSDKメソッドを使用することで、あらゆる環境 (バックエンド、フロントエンドなど) で使用できます。両者とも開発者に優しく、カスタムワークフローやLangChain以外のアプリケーションに統合できます。 フレームワーク & ツール統合: Langfuse: フレームワーク非依存  の設計。 幅広いコミュニティ統合を持つ。 LangChain, LlamaIndex, Haystack, OpenAI SDK, Vercel AI SDK, LiteLLM, Langflow, Flowiseなど、一般的なLLMフレームワークやツールをすぐにサポート。 これらの統合は、多くの場合、Langfuseにデータを自動的に送信する計測モジュールまたはコールバックとして提供される。 例: Langfuseには、チェーンをログに記録するためのLangChainコールバック統合があり、エンタープライズトレースシステムと統合するためのOpenTelemetryサポートさえある。 LangSmith: LangChainエコシステムと深く統合 。 LangChain (または新しいLangGraphフレームワーク) を使用している場合、LangSmithは追加のコードをほとんど必要としない。環境変数とコールバックハンドラを設定するだけでトレースを有効にできる。 OpenTelemetry計測、Vercel AI SDK、カスタムLLM APIなど、他のシナリオとの統合に関するガイドも提供。 LangSmithは、LangChain以外のネイティブ統合はLangfuseよりも少ないが、SDKを介して任意のカスタムワークフローをサポート。 LangChainチームは、SDKまたはAPIを介してトレースをログに記録することで、「LangChainを使用しているかどうかに関係なく」LangSmithを使用できることを明示的に示している。 プラットフォーム/リージョンサポート: Langfuse: セルフホスト可能であるため、任意のクラウドまたはオンプレミス環境にデプロイでき、インフラストラクチャ (データベース、監視ツール) への統合は非常に柔軟。 Langfuse Cloud (ホスト型サービス) は現在、コンプライアンスのために米国またはEUリージョンでのデータホスティングを提供。 LangSmith: 主にホスト型SaaS (LangChain Inc.がホスト) であり、サービスを使用する際にリージョンオプション (米国またはEU) を提供。 データレジデンシー要件がある企業向けに、LangSmithは エンタープライズセルフホスト  オプションを提供 (下記の「デプロイメント」を参照)。 両プラットフォームともAPIを介してデータを公開しているため、必要に応じて、その出力 (トレース、メトリック) を他の分析ツールまたはBIツールと統合可能。 要約:  Langfuse は幅広い統合フックを提供し、特定のライブラリに縛られないため、多様な技術スタックに適しています (複数のLLMOpsツールの統合もリストされています)。LangSmith はLangChainとシームレスに統合されており、LangChainユーザーには非常に摩擦の少ないセットアップを提供し、他のユーザーにはSDKを介した汎用的な統合もサポートします。実際には、すでにLangChainを使用している場合はLangSmithの方が簡単に組み込める可能性がありますが、LangfuseもLangChainはサポートしており簡単なインテグレーションが可能です。どちらもPython/JS SDKとREST APIを備えており、事実上すべてのプラットフォームまたは言語との統合が可能です。 4. デプロイメント (Deployment Options) このセクションでは、クラウドとセルフホストオプションを含め、各プラットフォームをデプロイまたは使用する方法を比較します。 ホスト型クラウドサービス: 両方ともクラウドホスト型サービスを提供。 Langfuse Cloud:  Langfuseチームによるフルマネージドサービス。サインアップすると、ダッシュボードとバックエンドがホストされる。インフラストラクチャを保守したくない場合に最適。 LangSmith:  本質的にマネージドクラウドプラットフォーム (smith.langchain.com経由でアクセス可能)。ほとんどのユーザーにとって、LangSmith はクラウドサービスとして使用することになる。 セルフホスティング: 大きな違いはセルフホスティング。 Langfuse:  オープンソースであるため、 誰でも簡単にセルフホスト可能 。 すべてのコアLangfuse機能はMITライセンスの下で利用可能。つまり、独自のサーバーまたはクラウドアカウントでプラットフォームを無料で実行でき、使用制限はない。 Langfuse社が Docker, Kubernetes, またはVMを介してインフラストラクチャにデプロイするためのガイドや公式のHelm, Terraform などをおおお提供。 個人情報保護や自社セキュリティ基準などの理由から、オンプレミスソリューションが必要なチームや、データを完全に制御したいチームに最適。 LangSmith:  一般公開のセルフホスティングは提供していない (クローズドソースプラットフォーム)。 ただし、 エンタープライズ顧客  は、Enterpriseプランの一部としてLangSmithのセルフホスト/オンプレミスデプロイメントを取得可能。 このシナリオでは、LangChainチームは、Kubernetesクラスターで実行できるコンテナ化されたバージョンのLangSmithを提供し、データが環境内に留まることを保証。 このオプションは、(通常、厳格なデータ要件を持つ大企業向けの) 商用契約でのみ利用可能。 クラウド vs オンプレミス: Langfuseのオープンソース版はクラウド版と同じコアソフトウェアであるため、セルフホストユーザーは 完全な機能セット  を利用できる (さらに開発も可能)。 Langfuseのセルフホスティングには機能的な損失はなく、実際、Langfuseは 「セルフホスティング時にはすべてのコア機能が無制限で利用可能」  と述べている。 LangSmithのセルフホスト (エンタープライズ) は、おそらくクラウドバージョンと同等の機能を備えている (環境にデプロイされるだけ) が、これは無料または小規模チーム向けではない。 LangSmithはクラウドに頻繁に更新をプッシュする可能性があることに注意。エンタープライズデプロイメントは、手配された更新を介してそれらを受け取る。 要約:  Langfuseはデプロイメントにおいて最大限の柔軟性を提供します。クラウドを使用することも、(自分のクラウドまたはオンプレミスに) 自分でデプロイすることもでき、エアギャップ環境でも、コア機能のライセンス料はかかりません。LangSmithは主にクラウドサービスです。オンプレミスが必要な場合は、エンタープライズ契約を介してのみ可能です。オープンソースまたは自己管理ソリューションを優先する組織はLangfuseに傾く可能性があり、ターンキーSaaSを好み (サードパーティがデータをホストしても構わない) 組織はLangSmith も選択肢になりえます。 5. 価格 (Pricing Plans) Langfuse とLangSmith は異なる価格モデルを持っています。以下にクラウド版の費用の要約します。どちらも始めるための無料枠がありますが、Langfuse の無料枠はイベントによって使用量が制限され、LangSmith の無料枠はユーザーとトレースによって制限されます。そして有料プランでは、より高いクォータとサポートが導入されます。 プラン Langfuse (Langfuse Cloud) LangSmith (LangChain) 無料枠 Hobby Plan – 無料 . 特定の制限付きですべてのコア機能が含まれる。例: 月間最大 5万  イベント、30日間のデータ保持、最大2ユーザー。クレジットカードは不要。コミュニティサポート (Discord & GitHub経由) のみ。プロトタイプや趣味のプロジェクトに最適。 Developer Plan – 無料 . シングル開発者向け。 1ユーザー  と月間最大 5,000  トレースを許可。5,000トレースを超えると、従量課金制 (追加の1,000トレースあたり0.50ドル)。すべての機能 (トレース、評価、プロンプト管理など) が含まれる。この無料枠は機能的には寛大だが、ボリュームとシート数に制限がある。 ミドルレベル Pro Plan – $59/月 . 中程度のボリュームでの本番環境での使用に適している。Hobbyのすべてに加え、より高い制限が含まれる: 月間 10万  観測 (その後、追加の10万件あたり10ドル)、無制限のデータ保持、 無制限のユーザー  と評価器。サポートはメール/チャット経由。 Team Plan – $499/月 . 大規模なチーム向けで、Proのすべてに加え、高度なセキュリティ機能が含まれる: シングルサインオン (SSO) 統合、きめ細かいRBAC、コンプライアンス (SOC2、ISO27001)。プライベートSlackチャネルを介した優先サポートも含まれる。ProとTeamはどちらも大規模な商用利用を許可し、Teamはエンタープライズのようなコントロールを追加する。 Plus Plan – $39/ユーザー/月 . 小規模チーム向け。Developerのすべての機能をより高いクォータで含む: 月間 1万  トレース (プール)、最大10ユーザーシート。1万トレースを超える追加トレースは、1,000件あたり0.50ドル。このプランではチームコラボレーション (複数シート) が導入され、LangChainチームからの メールサポート  が付属。レート制限は無料枠よりも高い。価格はユーザー数に応じてスケーリング (ユーザーごとの価格設定)。 エンタープライズ Enterprise Plan – カスタム価格 . Teamのすべてに加え、エンタープライズグレードのサポートとカスタム条件が含まれる。特に、Enterpriseは稼働時間SLA、サポートSLA、専任サポートエンジニア、アーキテクチャレビューさえ提供。価格は交渉による (AWS Marketplace経由の請求などのオプションを提供)。 セルフホスティングコスト:  Langfuseのコアソフトウェアはセルフホストが無料 (ライセンス料なし)。企業は無料でセルフホストし、必要に応じてエンタープライズサポートプランの料金のみを支払うことを選択できる。Langfuseは追加のサービスまたはサポートのためにセルフホストのPro/Enterpriseライセンスを提供しているが、すべての機能はセルフマネージドモードで無料で使用可能。 Enterprise Plan – カスタム価格 . 大企業が必要とする組織全体の機能を追加。この階層にはPlusのすべてが含まれ、 SSO統合 (Oktaなど) 、エンタープライズレベルのSLAコミットメント、そして重要なことに セルフホストデプロイメント  のオプションが追加される。エンタープライズ顧客は、データプライバシーのために独自のクラウド/KubernetesでプライベートLangSmithインスタンスを取得可能。価格は相談による。LangChainには特別な Startupsプログラム  (初期段階のスタートアップ向けの割引価格) もあり、採用を促進している。これは階層そのものではなく、割引プログラムである。 クラウド版のコストに関する考慮事項:   Langfuse の価格はイベントベースで月額固定であり、使用量が含まれるクォータ (例: 10万イベントで月額59ドル) に収まる場合は、より予測しやすい可能性があります。 一方でLangSmithの価格はシートごとおよび使用量ベースであり、無料の割り当てを超えたトレースに対して課金されます。チームメンバーが多い場合やトレース量が多い場合は、コストが高くなる可能性がありますが、単独の開発者にとっては低コストのエントリが可能です。どちらもプラットフォームを試用するための無料枠があります。Langfuseの無料枠は、LangSmithの無料枠 (5,000トレース) よりもはるかに高いボリューム (5万イベント) を許可し、LangSmithの1ユーザーに対して2ユーザーを許可します。これは、即時のコストなしで小規模なコラボレーションを行う場合に有益です。ただし、LangSmithの無料枠には使用量ベースのオーバーフローが含まれています (5,000で打ち切られるのではなく、追加料金を支払うことができます)。一方、LangfuseのHobby枠は、常に5万件のイベントを超える場合はアップグレードが必要になります。要約すると、 Langfuse  は従来の階層型サブスクリプションモデル (明確な制限とアップグレードパス付き) を提供し、 LangSmith  はハイブリッドモデル (従量課金制の無料枠、その後チーム向けのユーザーごとのサブスクリプション) を使用します。エンタープライズニーズを持つ大規模組織は、カスタム価格設定のために両方を利用できます。Langfuseはライセンス料なしでセルフホストするオプションを提供し、インフラストラクチャが問題にならない場合はコストを削減できる可能性があります。 6. サポートとコミュニティ (Support & Community) ドキュメント: 両プラットフォームとも十分に文書化されている。 Langfuse:  ウェブサイトで包括的なドキュメント (ガイド、リファレンス、インタラクティブなデモ、ビデオウォークスルーなど) を提供。ドキュメントは複数の言語 (英語、日本語、韓国語、中国語) で利用可能であり、グローバルなコミュニティを反映。また日本語でのBlogやコミュニティのアウトプットなども数多く確認されている。 LangSmith:  ドキュメントは、より広範なLangChainドキュメントサイトの一部。クイックスタート、ハウツーガイド、各SDKのAPIリファレンス、概念ガイドが含まれる。主に英語だが、LangChainのコミュニティはブログなどで非公式にコンテンツを翻訳している。公式のLangSmithドキュメントは英語のみ。 どちらのドキュメントも、統合手順、機能の使用法、ベストプラクティスを徹底的にカバー。LangSmithは新しい (2023年半ばに「LangChain Plus」として開始) ため、そのドキュメントは製品とともに急速に進化しており、一方もLangfuseの公式ドキュメントはAIによる性能も非常に高いと評価できる。 コミュニティとオープンソース: Langfuse:  オープンソースであるため、GitHub (コアリポジトリはGitHubにある) に活発なユーザーと貢献者のコミュニティがある。問題や機能リクエストはそこで直接開くことができる。チームは、サポートとQ&AのためにDiscordコミュニティを介して関与。このオープンモデルは、より迅速なコミュニティ主導の改善と透明性を意味する。 LangSmith:  それ自体はオープンソースではない (コードは公開されていない) が、LangChainの巨大なオープンソースコミュニティの恩恵を受けている。多くのLangChainユーザーは、LangChainのDiscordまたはフォーラムでLangSmithについて議論しており、LangChainのGitHubの問題はLangSmithの統合トピックをカバーする場合がある。さらに、(ブログ投稿やdev.toの記事で見られるように) サードパーティの比較やツールは、LangSmithがオープンな代替手段とどのように比較されるかについて、コミュニティ全体で関心が高まっていることを示している。 サポートチャネル: Langfuse:  階層型サポートを提供。 Hobbyユーザー: コミュニティサポート  (Discord、GitHubディスカッション)。 有料プラン: Langfuseチームからの直接サポート (Proユーザーはメールまたはチャット、TeamユーザーはプライベートSlackチャネル、Enterpriseは専任サポートエンジニアとSLA)。 これにより、ミッションクリティカルなデプロイメントはタイムリーな支援を受けることができる。 また日本においてはガオ株式会社 (GAO,Inc) が日本語サポートと円建て請求書払いなどにも対応。 LangSmith: 無料のDeveloper階層: 直接サポートは含まれない (コミュニティチャネルを除く)。 Plusプラン: LangChainチームからの メールサポート  が付属。 Enterprise顧客: 専用のサポート担当者、SLA、およびアカウントマネージャーがいる可能性が高い。(個別に要確認) さらに、LangChainはイベント (「Interrupt」カンファレンスなど) を主催し、教育コンテンツ (ブログ、LLMアプリケーションのテストに関する電子書籍) を共有しており、これらはLangSmithユーザーの間接的なサポートおよび学習リソースとして機能。 コミュニティの感情と採用: どちらのツールも、LLMアプリケーションの可観測性のための主要なソリューション。 Langfuse:  独立したオープンプロジェクトとして、「最も使用されているオープンソースLLMOpsプラットフォーム」を自称し、特にセルフホストツールを好むユーザーの間で急速にユーザーベースを拡大。 LangSmith:  LangChainの人気に支えられ、すぐに大規模なユーザーベースを獲得 (LangChainのサイトではLangSmithに「25万人以上がサインアップ」と記載)。 要約:  Langfuseは、開発者への直接チャネルを備えた強力なオープンソースコミュニティの雰囲気を提供します (CEOやCTOでさえDiscordで頻繁に関与しています)。そのドキュメントと国際化サポートは、世界中で親しみやすいものにしています。加えて、Langfuseは製品ロードマップを公開しており、ユーザーから度々要求を受けつけている点などにも特徴があります。 Langfuse は直近のリリース や 今後のロードマップをオープンに公開している LangSmithはLangChainの名声の恩恵を受けています。LangChainのユーザーは、おそらくどこで助けを求めればよいかを知っており、LangChainチームのリソース (ブログ、ガイド) はサポートエクスペリエンスを向上させます。 コミュニティ主導の開発と透明性を重視するユーザーにとって、Langfuseのモデルは魅力的です。マネージドソリューションとベンダーからの専門的なサポートを希望し、すでにLangChainエコシステムにいるユーザーにとって、LangSmithもまた同様に選択肢になりうるでしょう。 結論 LangfuseとLangSmithはどちらも、LLMアプリケーションのトレース、デバッグ、プロンプトの反復、および評価のための堅牢なソリューションを提供しますが、異なる哲学を持っています。 Langfuse: オープンソースでセルフホストを念頭に置いているプラットフォーム  であり、モデル/フレームワークに依存しない。 データ制御が最優先される環境や、カスタマイズが必要な環境で優れている。 その機能セット (トレース、プロンプト管理、評価、データセット、プレイグラウンド) は、柔軟性に重点を置いてライフサイクル全体をカバー。 チームは1つの機能 (例: トレースのみ) から始めて、徐々により多くを採用できる。 コストモデルはわかりやすく、無料枠のユーザーに対するコミュニティサポートも強力。 また日本においてはコミュニティの規模も成長しており、エンタープライズ向けにガオ株式会社 (GAO,Inc) が日本語サポートと円建て請求書払いなどにも対応。 LangSmith: プロプライエタリなマネージドプラットフォーム  (オプションでエンタープライズ向けのオンプレミス) であり、特にLangChainユーザーにとって、利便性と緊密な統合を提供する。 最小限のセットアップ、豊富な監視およびコラボレーションツール、組み込みの評価フレームワークを備えたエンドツーエンドの開発者エクスペリエンスを提供。 LangChainスタックをすでに使用しているチームにとっては、すべてのLLMOpsニーズに対応する1つのまとまったインターフェースを提供することで、開発を加速する可能性がある。 価格は使用量とシートベースであり、チームの規模に応じてスケーリングできる。 どちらかを選択する際は、セルフホスト (自社クラウド環境やオンプレミスへの設置) の必要性、オープン性 vs 利便性、コスト構造、LangChainへの依存度などの要素を考慮してください。たとえば、LangChainで迅速にプロトタイプを作成するスタートアップは、LangSmithのプラグアンドプレイの性質と既製の評価ツールから価値を得る可能性があります。顧客データなどを自社内に置く必要がある企業や、オープンソースを好む企業は、Langfuseが良いオプションになるでしょう LangfuseとLangSmithはどちらも同じ主要な 機能領域 (トレース、プロンプトのバージョン管理、評価、監視、フィードバック収集)  をカバーしていますが、 提供方法  (オープン vs クローズド) と一部の 機能のニュアンス  (例: LangSmithのカスタムダッシュボード/アラートと組み込みの評価モジュール vs Langfuseのより優れた統合拡張性とセルフホストの自由) が異なります。どちらを選択しても、本番環境でのLLMアプリケーションの動作に対する非常に必要な可視性と制御を得ることができますので、社内ポリシーなどに応じて適切なツールを選択することが肝要です。

1. はじめに: Langfuseとは何か？ 生成AIアプリケーションを本番投入したものの、 「何が悪いか分からないが生成AIアプリが思ったように動かない」「ちょっとプロンプトを変えるだけで、アプリ自体をもう一度リリース」「プロンプトやモデルを変えたら精度は上がような気がするが、どれくらい良くなったのかなどは感覚でしかない」「エージェントが暴走して 無限にAPIを叩き続けているが原因が分からない」「どのユーザーセッションで不具合が起きたか追えない」「そもそも役に立ってるのかも分からない」 ・・・・ このような悩みはありませんでしょうか？ こうした 開発・運用・改善の断絶  は、プロダクトマネージャー, SRE, 生成AIの企画担当者 まで誰もが抱える悩みです。Langfuse はそれらの悩みを “Trace” という一本のバックボーン  に集約し、以下のような役割の課題を解決します。 開発者  … 処理の可視化、プロンプト管理、リリース前テストで開発工程を短縮 運用担当  … コスト, レイテンシ, 品質をモニタリングで異常を発見し、原因を特定 生成AI企画・業務担当者  … ROI や品質を判断して、改善に繋げる Langfuse は OSS をベースにして Self-hostedと SaaS という２種類の提供オプションを持ち、ロードマップは常に公開・更新されており透明性があり、OSS コアモデルがゆえに国内外で活発なコミュニティが形成されている、非常にユニークな「LLM エンジニアリング プラットフォーム」です。 2. Langfuseが提供する主な機能 以下の表は、Langfuseが提供する主な機能をまとめたものです。 これらの機能が非常にわかりやすい GUI や API で提供されています。 機能 目的 代表ユースケース Tracing レイテンシ・エラー・再試行・トークン・コストをまとめて記録 ボトルネック解析／コスト急騰の問題解決 Prompt Management バージョン管理・ラベル付け・保護 破壊的変更の防止、チーム共有、プロンプト変更とリリースの高速化 Evaluations ユーザーフィードバック＋LLM as a Judge ＋人手評価 生成AIの効果測定／A/B テスト Datasets 良質 Q&A を蓄積し学習ループを構築 継続学習・RAG 強化 Dashboards & Playground／Experiments KPI 分析＋GUI テスト＋並列実験 仮説検証を高速化し部門間共有 この画像は実際のTracing 画面のキャプチャです。画像左側のバーに実際の処理の流れとコンポーネントが表示されており、クリックするとその中身が右側に詳細が表示されます。 Trace画面の例: 非常に見やすく、可視化や分析にすぐに役立つ 3. “Trace” を中心に循環するオペレーティングモデル 最近では、生成AIアプリケーション市場の高まりに合わせて、Proprietary から OSS まで、さまざまな可視化ソリューションが登場してきました。しかしながら、単なる可視化ソリューションの導入は前述のような課題の一部のみを解決するものであり、LLMの品質を上げるためには可視化された情報を活用することこそが重要です。Langfuse はその点において、ひとつのプラットフォームとして、必要とされる一連の流れをカバーできるということに大きな強みがあります。参考までに、どのように Langfuse の各機能が Trace に紐づいているかをまとめたものが以下の表です。 サイクル 役割 キーとなる Trace の利用法 Prompt Management プロンプトを一元管理し、Trace の入力/出力とプロンプトもリンク 使用されているプロンプトが、品質・コストへ与える影響をTraceごとに確認 Evaluations Trace ごとにユーザ評価/ 自動評価 / 人的評価を与える 評価をTraceに紐づけることで、問題の特定 Datasets テスト用などのデータを管理 Trace から直接データセットを作りし、問題があった Trace などをプロンプトやモデルの変更などで試験することで、改善サイクルを回すことができる Dashboards コスト、評価、利用状況などを一元管理 Trace から KPI を判断 このようにTrace さえ送れば 管理→評価→最適化  が芋づる式に回り、GenAIOps/LLMOps の“理想形”を最短で実装できることが、LLMエンジニアリングプラットフォームとされている所以とも言えるでしょう。 例えば以下の画像は前出のTrace画像の一部ですが、トークンやコストだけではなく、この処理で使われたモデル名 "gpt-4o-mini " や プロンプト名 "qa-answer-withcontext-chat -v47" が紐づいていることが確認できます。またこのTraceを直接 dataset に入れることができる "Add to datasets" や 人的評価 (Human Annotation) をする "Annotate" もTraceから実施できることがわかります。 このように Langfuse は個々の機能を単に提供しているだけではなく、それらが Trace を軸にして全て結びついて設計がされているということに特徴を持ちます。 　また今回は触れませんが、Langfuse外のツール 例えば異常を検知するガードレール機能やRAGASのような別の評価・スコアリングとも連携し、APIを通じてTraceにスコアをつけることなども可能であり、まさにプラットフォームとして幅広く利用することができます。 4. 導入パターン Langfuse では SaaS と Self-hosted の2パターンでの提供がされています。 SaaS と同様の機能を Self-hosted で利用でき、かつ OSS から手軽に始めることができることも Langfuse の大きな特徴です。まずは無償のSaaS版や OSS で簡単に立ち上げ、その後に本格導入することができるため、企業への導入の敷居も非常に低いと言えるでしょう。 方式 主に利用されているケース SaaS (Langfuse Cloud) 従量課金 (無償版あり)でも問題がない。 個人プロジェクト、PoC やスタートアップ、メンテ不要で素早やく試したい。 Self-hosted (Docker Compose, Helm, Terraform, AWS CDK などによるインストール) 固定費用 (OSS版なら無償)が予算の都合が良い。 セキュリティ要件として、自社内のNWに情報を保管する必要がある。 検証用でローカル環境で手軽に試したい。 Self-hosted において、どのパターンでインストールするかについては、 こちらの Blog も参考になさってみてください。 Docker compose などを使えば、すべての手順が数分で完了しますので、ぜひまずはとりあえずサクッとお試しください。 5. ロードマップとコミュニティ ― “公開・参加型”の進化エコシステム Langfuse は OSSをベースとして展開しており、その運営も非常にユーザーフレンドリーで透明性が高く、以下のような特徴を持ちます。 公開されたロードマップ GitHub Discussions に専用スレッドを設け、公式ページは機能計画とステータスが随時更新されています。また採択・却下の理由まで閲覧可能で、ユーザーのニーズを汲み取りながらも、非常に透明性の高い運営がされています。 ロードマップ: https://langfuse.com/docs/roadmap コミュニティサポート もし Bug と思われる挙動を発見した場合には、Github の Issue で報告をすることができます。有償サポートほどではないですが、開発者をはじめとしてコミュニティから多くのサポートを得られます。 フィードバックが反映 Idea ボードで提案に投票→優先度が可視化されます。Issue/PR はコメント付きでレビューされ、採用までの過程がすべて残ります。 定例イベント Discord Community Session（隔週）  と Town Hall（毎月）  で最新リリースをライブ解説。アーカイブは YouTube に公開され、非参加者もキャッチアップが可能。 日本発コミュニティ 「Langfuse Night」 Langfuse Night #1 （2025/1/28、虎ノ門）と #2 （2025/3/25）が 50〜60 名規模で開催されています。資料・動画を全公開。国内でも知見循環が急速に広がっています。​また AWS でのハンズオン なども開催され、関連エコシステムとの連携も発展しています。 Langfuse の Github レポジトリはこちらです。ぜひご確認ください。 https://github.com/langfuse/langfuse まとめ Langfuse は生成AIアプリケーション / エージェント の開発から運用までを一貫して支援するプラットフォームです。その導入は非常にシンプルで、Cloud版やSelf hosted のDocker版なら数分で利用を開始することができます。まずはTraceの可視化を見える化から 始めて、その後にプロンプト管理や評価などをそこに付け足していくことで、生成AIのビジネス効果が高めていくことが可能です。 ガオ株式会社はサポートや有償版のリセールなどを行なっている Langfuse の 日本/APAC唯一のパートナーです。不明点など、お気軽にご相談ください。

LLMOps とは？ LLMOps（Large Language Model Operations）とは、大規模言語モデル（LLM）を利用した生成AIアプリケーションの開発から運用、改善までを一貫して管理するための考え方や仕組み（フレームワーク）です。多くの企業では、自社でモデルをゼロから構築するのではなく、OpenAI、Google、Anthropic などが提供する基盤モデルを活用し、プロンプト設計やファインチューニング（微調整）を通じて目的に合った生成AIアプリケーションを開発しています。LLMOpsは、こうした開発・運用プロセスを効率化し、品質管理やガバナンスを実現する上で重要な役割を果たします。 LLMOps のメリットとユースケース LLMOps は「便利ツール」ではなく、品質・コスト・リスクを同時に最適化する運用メソドロジーです。以下はその主なメリットの例です。 開発スピードの加速 - プロンプト管理、モデル、確立されたテスト手法により、開発効率の向上 (プロンプト管理に関しては こちら のブログを参照） 品質の継続的改善 LLM as a Judge、 ユーザーフィードバック、 Human Annotationなどをワンループで運用し、リリース後の精度向上を仕組み化 コスト最適化 Trace単位でトークン数と請求額を可視化、高コスト箇所を改善 ガバナンスと監査対応 全入出力・モデルバージョン・評価結果を一元ログ化し、生成物の説明責任 (Explainability) を担保、有事の際におけるトレーサビリティの確保 チーム横断コラボレーション データサイエンティスト／エンジニア／業務担当が 共通ダッシュボード で指標を共有し、改善案を合意形成しやすい スケールと未来対応力 新モデル登場やワークロード拡大時も、同じパイプラインにプラグインするだけで リスクなく横展開 ROI の可視化 Trace と KPI を結びつけ、「生成 AI がビジネス成果を生んでいるか」 を定量的に証明 またユースケースとしては、以下のようなものが想定されます。 生成AI導入によるカスタマーサポート平均対応時間の削減 生成AIの処理を可視化し、回答を継続的に評価、改善することで人件費削減 あわせて顧客の待ち時間も削減し、顧客満足度を向上 法務ドキュメントレビュー の時間削減 一次評価を全て生成AIで実現しつつも、発生するエッジケースに対して、Trace から LLM as a Judge による誤りケースを検出し、専門家レビューによる改善 パーソナライズド広告コピー生成クリック率 の向上 効果的なプロンプト をTraceのTagで判別し、A/Bテストを実施し、プロンプトを改善しつつ、効果的なものを瞬時に本番適用 LLMOps を導入せず当初の仮説だけでリリースした場合、こうした効果は期待できず、ビジネスにおける ROI も限定的なものとなってしまう恐れがあります。 MLOps と LLMOps の違い 従来のMLOps が一般的な機械学習モデルの開発と改善を対象とするのに対し、LLMOps はLLM を活用した生成AIアプリケーションやエージェント特有の課題に対応するためのものです。その主な特徴として運用プロセスにおいてモデルの出力に対する ユーザーからのフィードバック収集や自動的な評価の実行結果などを改善に活用する ことが重視されます。これらの結果がプロンプトや 自動評価自体の改善、モデル選定や 評価データセットの構築などに活用されることになります (具体的なプロセスは後述）。 LLMOps とGenAIOps の違いと関係性 LLMOps と似た用語にGenAIOps（Generative AI Operations）があります。GenAIOps は、テキストだけでなく画像、音声、動画などの生成モデルを含む、あらゆる生成AIを対象とした、より広範な概念です。一方、LLMOps は生成AIの中でも特に「大規模言語モデル（LLM）」を利用した言語生成にフォーカスしています。つまり、LLMOps はGenAIOps の一部分（サブセット）と位置づけられ、特に言語生成に特化したプロセスが重視されます。 LLMOps は GenAIOps の一部 生成AIアプリケーションのデプロイ、その後の課題 IT部門やDX部門などにより開発・導入された生成AIアプリケーションが、通常のシステムと同様に 最初から100% の品質でユーザニーズを満たすことはまずありません 。そして、アプリケーションの使われ方、ユーザーフィードバックの獲得、定量的な評価などが何もない状況であれば、当然その状況は 永遠に改善されません 。結果として経営層がそのプロジェクトにROI を見出せなければ継続することが難しくなるかもしれません。 生成AI は一見すると正しいように見える出力をする特性があり、出力結果はそのまま使えないが必ずしも全てが間違えているとも言い切れず、残念ながらユーザはモヤッとした不満を心に抱えることになります。その状況で仮にIT部門がアンケートを定期的にとったところで、低い解答率で曖昧な回答を受け取ることになり、具体的な改善に繋げることは難しいでしょう。 このような問題を解決するために必要な手法が LLMOps です。 LLMOps に必要な構成要素 生成AIを利用したアプリケーションやエージェントの継続的な改善を実現させるためのLLMOps には以下のような構成要素が含まれます。 Tracing ユーザ入力とモデルの出力 (Trace)の取得および保管、および処理内容の可視化 プロンプト管理 生成結果の品質向上のためのプロンプト修正、テスト、評価など ユーザ フィードバックの取得 ユーザがどの処理に対して、どのような評価をしたのかを具体的に収集・管理 Human Annotation 業務の専門家から見て、適切な回答をしているのかどうかの評価 自動評価 LLM as a Judge などを活用して、3や4の効率化・一次評価に利用 Dataset管理 ユーザの実際の入力などをデータセットとして管理し、テスト資材などのために管理 利用傾向の把握と分析 コスト, プロンプト, モデル, ユーザ, アプリケーションなどの様々な観点で、どのような傾向があるのかを分析 生成AIアプリケーションはこれらのプロセスを通じて継続的に改善し続けることで、初めてビジネスに価値を生み出すことが可能となります。続いて、この中から重要な要素であるTracingと評価 (ユーザーフィードバック, Human Annotation, 自動評価) に焦点をあてて、説明をしていきます。 Tracing - LLM アプリの“挙動”を可視化するバックボーン Tracing (または Trace ) はユーザーのインプットと LLM のアウトプットをまとめ、どのモデルを使い・何を参照し・何秒かかり・いくらコストが発生し・どんな結果を返したかなどを時系列で残す仕組みです。このTraceを軸に評価 (Evaluation) やデバッグなどが行われることから、LLMOps におけるバックボーンと言えるでしょう。以下はTracing によって得られる一般的なパターンです。 ビジネス課題 Tracing が解決すること 例 品質管理 失敗した Generation をクリックし、入力→Retrieval→出力を時系列で確認 “Hallucination が起きたのは Retrieval が空集合だった”と即判明 コスト抑制 Trace 単位でトークン数と課金額を自動記録 月次レポートで高コスト プロンプトを可視化し、短縮を提案 SLA／レイテンシ Span 間のタイムスタンプでボトルネックを特定 「埋め込み検索が 600 ms → Pinecone にインデックス分割」で改善 A/B テスト 異なるプロンプトを与えたTrace毎に結果を比較 プロンプト v2 の CS 工数削減率が +12 % を確認 Tracing は LLM アプリの全イベントを “1 本のストーリー” に束ねることで、 品質・コスト・パフォーマンスをワンクリックで照会 評価（LLM as a Judge、Human Annotation、User Feedback）との橋渡し プロンプトやパラメータが与える影響の確認 監査／セキュリティ要件への対応 と言ったLLMOps の道筋を作る重要な役割、最初の一歩の役割を持ちます。 これにより Tracing → 評価 (Evaluation) → 改善 のループが完成し、GenAIOps／LLMOps の継続的改善が“仕組み”として回り始めます。 生成AI においては評価が鍵 Tracing がされている前提で、LLMOps の構成要素の中で、特に重要なのは "評価" です。 生成 AI アプリケーションは、モデルが生成したアウトプットが実際にユーザーの課題解決に役立っているかを常に確認し、改善し続けることでなければ ROI を証明できません。 特に GenAIOps／LLMOps では、 オンライン指標（ユーザー行動） オフライン指標（定義済みデータセットによるテスト） モデル／人による定性評価 これら3つを組み合わせ、素早くループを回すことが成功の分水嶺になります。 1. ユーザーフィードバック：最も信頼できるオンライン評価 評価例 実装方法 オンライン 👍/👎、5 段階評価、自由コメント UI コンポーネントはできる限りワンクリックで完結させる オフライン クリック率、編集率、滞在時間 既存の分析基盤と Trace ID をひも付ける オフライン CS 工数削減、処理時間短縮 業務システム側で自動計測 → Langfuse の score API に送信 Langfuse では数値・カテゴリ・真偽値いずれのフィードバックも Trace 単位で保存、Exportすることが可能です。またダッシュボード上でスコア分布も即時確認できます。 2. Human Annotation：ドメイン知識を注入する評価の“最後の砦” Langfuse には以下の図のような極めて分かりやすい Human Annotation 専用の UI があり、次項で説明する自動評価でスコアが悪い Trace を Queue に入れ、Queueにいるそれらを簡単にドメインエキスパート (業務の専門家) が評価することができます。 実際の INPUT と OUTPUT をみて、手動でカテゴリや点数などで専門家が判定（評価軸は独自設定が可能） 3. 自動評価──“LLM as a Judge” で 指標  を ビジネス価値  に変換する BLEU／Rouge のような機械翻訳系メトリクスは「表層的一致」を測るには有効ですが、 本当にUX に寄与しているのか 業務 KPI（例：チケット処理時間、法令順守率）に直結しているのか という問いには答えてくれません。 ここで鍵になるのが LLM as a Judge ――LLM 自身を “審査員 (Evaluator) ” として使い、 独自プロンプト  でタスク固有の評価軸を採点させる手法です。 なぜ「独自プロンプト評価」が効くのか？ 業務コンテキストを埋め込める 業界用語や必須の条文のチェックなど、業務独自の内容を反映可能 評価基準の透明性 プロンプト の中に基準を明文化 することで、 ドメインエキスパートやステークホルダーも理解がしやすい 定量化が難しい基準も自然言語で入れることができる ビジネスに相応しいか、似合っているか、多様か ... などの基準を作ることが難しい内容もプロンプトが可能（精緻化した方が効果は高くなることがあります） Langfuse は最初から評価用テンプレートも用意されており、そこにさらに独自の基準を日本語で追加することができます。こうした自然言語で 半コード化された評価基盤  を「作る→回す→直す」のループに緊密に組み込み、Traceに紐づけることで、改善対象を明確にすることで、改善を具体化・高速化させることが可能になります。 「メトリクスでは不十分な評価も、LLM 使うことで “自社専属の 一次QA チーム” を構築」 ──Langfuse はその最短ルートもあわせて提供します。 まとめ｜LLMOpsはLLM活用の鍵 LLMOps は、LLMをビジネスに導入し、その価値を継続的に生み出すために不可欠な運用手法です。特に、モデルプロバイダが提供する強力な基盤モデルの活用が一般的となった現在、LLMOps なしでの効果的な運用は困難と言えるでしょう。 その中でも特に、評価が改善の鍵となり、 Langfuse は世界中で使われている便利なUIや 機能を最初から備えています。ご興味がある方は、あわせてご確認ください。

最近話題の Google 製 AI エージェントフレームワーク「Agent Development Kit (ADK)」を触ってみました！ Gemini モデルとの連携がしやすく、柔軟なエージェント開発が可能とのことで、期待が高まります。エージェントが自律的にツールを使うのは凄いですが、ちゃんと意図通り動くか、修正で壊れないかを確認する「評価」も重要ですよね。 そこで今回は、ADK のセットアップからエージェント作成、そしてそのエージェントを「評価」機能でテストするところまで、一通り試してみた記録をまとめます。 公式ドキュメント : 事前準備の参考記事 ： （ 事前準備はこちらの記事を参考にしました ） 1. 環境セットアップ まずはローカル環境（Mac）でプロジェクトを準備します。パッケージマネージャーには uv を使用しました。 Bash # プロジェクトディレクトリ作成と移動 (Python 3.12.9 を指定) uv init -p 3.12.9 adk-work cd adk-work # ADK パッケージのインストール # (評価機能も使うため、[eval] 付きでインストールする) uv add "google-adk[eval]" google-adk[eval] とすることで、評価に必要な追加ライブラリ (pandasなど) も一緒にインストールされます。 2. エージェントプロジェクトの作成 参考記事に沿って、天気 (get_weather) と時刻 (get_current_time) を取得するツールを持つエージェント (multi_tool_agent) を作成します。 ディレクトリ・ファイル構成: Bash mkdir multi_tool_agent touch multi_tool_agent/{__init__.py,agent.py,.env} tree -a multi_tool_agent/ 実行結果： multi_tool_agent/ ├── .env ├── __init__.py └── agent.py ファイルの内容: multi_tool_agent/__init__.py : from . import agent multi_tool_agent/agent.py のコードを記述します。 import datetime from google.adk.agents import Agent from zoneinfo import ZoneInfo def get_weather(city: str) -> dict: """特定の都市の現在の天気情報を取得する。 Args: city (str): 天気情報を取得したい都市名。英語で。 Returns: dict: ステータスと結果またはエラーメッセージ。 """ if city.lower() == "new york": return { "status": "success", "report": ("ニューヨークの天気は晴れです。" "気温は25度（41°F）です。"), } else: return { "status": "error", "error_message": f"{city}の天気情報は利用できません。", } def get_current_time(city: str) -> dict: """特定の都市の現在時刻を取得する。 Args: city (str): 天気情報を取得したい都市名。英語で。 Returns: dict: ステータスと結果またはエラーメッセージ。 """ if city.lower() == "new york": tz_identifier = "America/New_York" else: return { "status": "error", "error_message": (f"{city}のタイムゾーン情報は利用できません。"), } tz = ZoneInfo(tz_identifier) now = datetime.datetime.now(tz) report = f'{city}の現在時刻は {now.strftime("%Y-%m-%d %H:%M:%S %Z%z")}です。' return {"status": "success", "report": report} root_agent = Agent( name="weather_time_agent", model="gemini-2.0-flash-exp", description="任意の都市の時刻と天気に関する質問に答えるエージェントです。", instruction="私は指定された都市の時刻や天気に関する質問に答えることができます。", tools=[get_weather, get_current_time], ) 3. モデル接続の設定 (.env ファイル) LLM (Gemini) への接続情報を .env ファイルに記述します。Google AI Studio か Vertex AI かで設定内容が異なります。 Google AI Studio: GOOGLE_GENAI_USE_VERTEXAI="False" GOOGLE_API_KEY="YOUR_API_KEY_HERE" Vertex AI: GOOGLE_CLOUD_PROJECT="your-gcp-project-id" GOOGLE_CLOUD_LOCATION="your-region" # 例: us-central1 GOOGLE_GENAI_USE_VERTEXAI="True" (Vertex AI 利用時は事前の API 有効化、gcloud auth login が必要) 今回は Vertex AI  を使用しました。 4. エージェントを実行してみる (Web UIでの基本動作確認) まずはエージェントがちゃんと動くか、Web UI で確認します。プロジェクトルート (adk-work) で以下を実行。 Bash uv run adk web ブラウザで http://localhost:8000  にアクセスし、エージェント multi_tool_agent を選択します。 チャットで「ニューヨークの天気は？」などと尋ねると、エージェントがツールを使って応答してくれるはずです。右側のページで詳細な動作（LLM とのやり取り、ツール実行）も確認できます。これでエージェントが基本動作することは確認できました。 5. エージェント評価の必要性 手動での動作確認も大事ですが、エージェントが複雑になったり、修正を繰り返したりすると、「毎回同じテストを手動でやるのは大変」「意図しないところで動作が変わっていないか心配」となります。ここで ADK の 評価機能 の出番です。 ADK ドキュメントによると、LLM エージェント評価では「最終出力」だけでなく、そこに至る「軌跡（ツールの使い方など）」も重要であり、これを自動でチェックできる仕組みが提供されています。 6. 評価シナリオ (評価セット) の準備 評価のために、「お手本」となるシナリオと期待される動作を定義した 評価セットファイル (.evalset.json)  を用意します。ファイル名は任意（例: multi_tool_agent_test.evalset.json）です。Web UI で対話したセッションを保存して生成することも、手動で作成することも可能です。 以下のファイルでは、期待されるツール使用と参照応答 (reference) を定義しています。 (ファイル名例: multi_tool_agent_test.evalset.json) JSON [ { "name": "test", "data": [ { "query": "おはよう！", "expected_tool_use": [], "reference": "おはようございます！ お手伝いできることはありますか？ " }, { "query": "ニューヨークの現在の時間は？", "expected_tool_use": [ { "tool_name": "get_current_time", "tool_input": { "city": "New York" } } ], "reference": "ニューヨークの現在時刻は...です。..." }, { "query": "ニューヨークの天気は？", "expected_tool_use": [ { "tool_name": "get_weather", "tool_input": { "city": "New York" } } ], "reference": "ニューヨークの天気は晴れです。..." } ], "initial_session": { "state": {}, "app_name": "multi_tool_agent", "user_id": "user" } } ] 7. 評価の基準 ( ADK ドキュメントより ) ADK はエージェントの実際の動作と評価セットの期待値を比較する際、以下の基準（メトリクス）とデフォルトの閾値を使用します。 tool_trajectory_avg_score : ツール使用履歴の一致度。デフォルト閾値 1.0  (完全一致)。 response_match_score : 最終応答と reference の類似度。デフォルト閾値 0.8  (ある程度似ていればOK)。 ちなみに、これらのデフォルト閾値は、必要であれば 以下のようなtest_config.json という設定ファイルを作成して各エージェントディレクトリ配下に置くことでカスタマイズすることも可能です。 { "criteria": { "tool_trajectory_avg_score": 1.0, "response_match_score": 0.8 } } 8. Web UI で評価を実行！ 準備ができたので、Web UI で評価を実行します。 (もし adk web が停止していれば再起動) Web UI で multi_tool_agent を選択。 右側の「評価 (Eval)」タブを開く。 「評価セット (Eval Set)」ドロップダウンから、 自分で準備した評価セットファイル （multi_tool_agent_test）を選択。 評価ケース test が表示されるのでチェックを入れて、「Run Evaluation」ボタンをクリック！ 実行後、結果が表示されます。 今回は無事「PASS」しました！ また、ターミナルを見てみると詳細が出力されると思います。 （ ※注意 ：応答一致 (response_match_score): 筆者が実験をしてみると、評価セットの reference に明らかに正しくない応答を設定し、さらに test_config.json で 値を明示的に指定しても、評価全体の結果は1となり「PASS」のままでした。） Agent Development Kit の評価まとめ 今回は、ADK のセットアップからエージェント作成、そして評価機能を使ったテストまでを一通り体験しました。評価セットによる自動評価は、特にエージェントのツール利用手順（軌跡）が期待通りかを確認する上で有効だと感じました (tool_trajectory_avg_score は意図通り機能しているようです)。これにより、回帰テストの一部は自動化できそうです。 一方で、 最終応答のテキスト内容 (reference) との比較 (response_match_score) については、今回試した範囲では、期待通りに最終的な評価結果 (PASS/FAIL) に影響を与えない場面がありました。  明らかに異なる応答を期待値としても、評価全体が PASS してしまうケースがあり、test_config.json で基準を明示的に設定しても結果は変わりませんでした。この挙動については、さらなる調査や ADK の今後のバージョンでの改善が必要かもしれません。 このように、現状では特に 応答内容の自動評価に関しては注意が必要 ですが、ツール利用の正確性を担保する目的など、 部分的には  ADK の評価機能は開発の助けになる可能性はあります。ADK の評価機能を利用する際は、現状の挙動をよく理解・検証した上で、目的に合わせて活用するのが良さそうです。皆さんもぜひ試してみてください！

1.初めに 近年、AI 技術、特に大規模言語モデル（LLM）の進化は目覚ましく、様々な分野での活用が進んでいます。しかし、LLM をビジネスに適用する上で、その品質をどのように評価するかが大きな課題となっています。 これまでの LLM の評価は、主に「出力結果の目視確認」や「ユーザーフィードバック」に頼ってきました。この従来のアプローチには、以下のような課題があります 評価基準の曖昧さ 何をもって良い評価とするのかが評価者によって異なり、客観的な評価が困難 個人の価値観や経験によって、評価結果にばらつきが生じます 評価の多面性 正確性、簡潔性、論理的構成など、複数の観点からの評価が必要で 多角的な視点での評価が必要となり、総合的な判断が難しくなります 実装の複雑さ テストデータの準備、評価項目の設定、結果の可視化など、多くの実装工程が必要 評価用データセットの作成やプロンプトの作成に多くの工数がかかります このような課題を解決し、効率的かつ効果的な LLM 評価を実現するために、注目されているのが Langfuse です。 Langfuse は、LLM システムの開発から運用までをサポートする包括的なプラットフォームです。本記事では、特に LLM の評価機能に焦点を当て、Langfuse がどのように LLM 開発を効率化するのか、具体的な活用方法を解説します。 2. Langfuseによる評価機能 Langfuse は、これらの課題を解決するために、以下の2つの主要な評価機能を備えています。※セルフホスティングの場合はPro/Enterprise版を利用する必要あり Human Annotate: 人間の手によるラベル付けを可能にします。開発者以外のドメインエキスパートが評価する場合に特に有効です。 LLM as a Judge: LLM を評価者として活用し、評価用プロンプトに基づいて自動で評価を行います。これにより、評価の客観性と効率性を高めることができます。 Langfuse の評価機能を利用することで、評価軸を明確に定義し、客観的な評価を行うことが容易になります。また、評価結果は UI 上で可視化され、トレースと紐付けられるため、問題点を特定しやすく、効率的な改善サイクルを実現できます。 3. RAGASとLangfuseの評価アプローチの違い RAGシステムの評価フレームワークとして、RAGASは広く使用されています。RAGASは汎用的な評価フレームワークとして、検索精度や応答の関連性など、RAGシステムの基本的な性能を測定するために設計されています。しかし、実際のビジネス応用においては、以下のような制約があります RAGASの制約 事前に定義された評価指標に基づく標準的な評価 ドメイン固有の要件への対応が限定的 評価基準の詳細な調整が困難 これに対し、Langfuseは実務での活用に焦点を当てた評価プラットフォームとして、以下のような特徴があります Langfuseの特徴 ドメイン固有の評価基準を柔軟に設定可能 評価プロンプトのカスタマイズと継続的な改善 具体的な評価例 金融分野での規制要件への適合性評価 医療分野での専門用語の正確性評価 このように、RAGASとLangfuseはそれぞれ異なる用途に適しています。RAGASはRAGシステムの基本性能を標準的に評価する際に有効で、Langfuseは実際のビジネス要件に応じた詳細な評価が必要な場合に適しています。 　　　　　　　　　　　　　　RAGASとLangfuseの主な違い RAGAS Langfuse プロンプトを作成する必要性 必要なし 必要あり 各評価用のテンプレートはある 評価用プロンプトの可視化 Githubから確認 LangfuseのUI上で確認 評価のカスタマイズ性 ほぼなし 評価基準を作成・修正が容易に可能 実装方法 ソースコードで実装 UIで設定（別途実装も可能） 日本語での評価制度 （個人的印象） 不安定 安定するように評価用プロンプトの修正が可能 Langfuse を用いた評価の実践 データセットの作成 Langfuse では、トレースデータから評価用データセットを簡単に作成できます。UI 上で必要なトレースを選択し、「Add to dataset」ボタンをクリックするだけで、データセットとして利用できます。 また、データセット用のトレースをあらかじめ作成しておけば、より柔軟なデータセット作成が可能です。ユーザの入力だけ取得をして、データセットとして保管しておきたい場合などに有用です。 方法としては以下のような、関数を1つ作成するだけです。 例：（ユーザの入力だけほしい場合） ## python @observe() async def trace_dataset(): langfuse_context.update_current_observation(input=ユーザの入力 ,output="") テストデータセットの選定と管理 Langfuse では、作成したデータセットを「Queue」という仕組みで管理します。トレースを Annotation の Queue に入れ、ドメインエキスパートが Queue を仕分けることで、適切なテストデータを選定できます。これにより、評価に必要なデータだけを効率的に管理し、テストの精度を高めることができます。 　　　　　　　　　　　トレースからqueueに入れる画面 　　　　　　　　　　　　Human Annotateの画面（仕分け画面） LLM as a Judge の利用方法 Langfuse の LLM as a Judge 機能を利用すると、データセットの選定も効率的に行えます。あらかじめ LLM as a Judge の設定をしておけば、トレースには自動でスコアが入力されるため、怪しい値をチェックすることで、より精度の高いデータセットを選定できます。 LLM as a Judge設定画面 LLM as a Judge設定画面（トレースの設定） テスト実行と結果の可視化 選定したデータセットを用いて、Langfuse 上でテストを実行します。テストの際には、モデルやプロンプトを自由に選択でき、複数の評価基準を設定することも可能です。テスト結果は、ダッシュボードで可視化され、各データポイントの評価スコア、入出力、トレースなどの情報を一目で確認できます。これにより、システムの改善点を効率的に特定し、迅速な改善サイクルを回すことが可能です。 プロンプト実験の設定画面 Langfuseを活用した評価サイクル 以上の機能を用いることで以下のような評価・改善サイクルが実現できます。 LLMの出力結果をトレースし、Langfuseで可視化 Annotation の Queueに入れて、ドメインエキスパートの人に出力結果を判断してもらう　& LLM as a Judgeで各評価項目に対してスコアを出力させる 2で悪い結果の原因追及をして、入力をデータセットに格納（オプションで期待する出力もあると良い） プロンプトを変更する プロンプト実験を行い、前回のプロンプトの出力との違いについてLangfuse上で結果を可視化し原因の追求 5. まとめ Langfuse は、LLM システムの開発から運用までをカバーする包括的なプラットフォームです。特に評価機能においては、以下のような作業を UI 上で完結させることができます。 評価の事前準備 評価用プロンプトの作成 評価基準の定義 ドメイン固有の要件への対応 テストの効率化 トレースからの自動データセット作成 Human AnnotateとLLM as a Judgeの併用 複数の評価軸でのテスト実行 結果の可視化と改善 定量的なスコア表示 トレースを活用した原因追求 プロンプト実験による継続的な改善 現状では、Langfuseはトレースやモニタリング機能の利用がメインとなっていますが、本記事で紹介した評価機能を活用することで、LLM開発のライフサイクル全体を効率的に管理することが可能です。評価から改善までのサイクルを一つのプラットフォームで完結できる点は、開発効率を大きく向上させる要因となるでしょう。 ぜひ Langfuse を導入し、効率的なLLM開発の実現を目指してみてください。