https://techblog.raksul.com/entry/2025/12/21/232315

この記事はノバセルテクノ場出張版2025 Advent Calendar 2025の22日目の記事です。

はじめに

Novasellで主にAIプロダクトの設計・開発を行っている浅田です。

今回は、NotionによるPromptOps運用で直面した課題と、その解決策として検討しているLangfuseについてお話しします。

私たちのチームでは、プロンプトのテンプレートをNotionのデータベースで管理し、タグやバージョン情報を付与して運用してきました。しかし、本番運用が進むにつれ、この体制に限界を感じるようになりました。

以下は実際の管理イメージです。

プロンプトごとにバージョン（version）、ステータス（Status）、変更意図、評価結果サマリーなどを記録しています。また、対象のApp・Module・使用モデル・カテゴリといったタグを付与し、検索性を確保しています。

参考にした記事

Notion運用で直面した課題

まず前提として、弊社ではプロンプトを改善するのはドメイン知識を持つビジネスサイドのメンバーが中心です。そのため、LLMアプリケーションの構築にはDifyを採用し、ビジネスサイドが自分たちでプロンプトを変更・公開できるようにしています。

課題：DifyとNotionのプロンプト二重管理

その上で直面している課題が、Dify上のプロンプトとNotion上のプロンプトの二重管理です。

理想は「Difyでプロンプトを修正 → Notionでバージョン管理」という流れですが、実際は以下のようになりがちです。

Difyでプロンプトを修正し、そのままデプロイ
Notionの更新を忘れる（または後回しにする）
時間が経つと、どちらが正なのかわからなくなる
Notion DBが過去の遺物と化す

この問題は、チームや運用の規模が大きくなるほど顕著になり、PromptOpsの仕組み自体が回らなくなります。

理想の状態

私たちが求めているのは、プロンプトを一元管理しつつ、ビジネスサイドも自由に編集できる環境です。

Gitのようなバージョン管理とロールバック機能
非エンジニアでも使えるGUI
アプリケーションからの動的なプロンプト取得（二重管理の解消）

これらの要件を満たすツールとして、Langfuseの導入を検討しました。

LangfuseはオープンソースのLLMオブザーバビリティプラットフォームです。トレーシング、プロンプト管理、評価機能を備えており、LLMアプリケーションの開発・運用を包括的にサポートしてくれます。

なお、類似ツールとしてLangSmithなども存在しますが、今回はDifyとの連携プラグインが充実している点を重視し、Langfuseを選定しました。

1. Langfuse上でのプロンプト管理の仕組み

バージョン管理の仕組み

Langfuseでは、プロンプトを保存するたびにバージョン番号が自動的にインクリメントされます（1, 2, 3...）。各バージョンは完全に保持され、いつでも過去のバージョンを参照・復元できます。

ラベルによる環境管理

Langfuseの特徴的な機能がラベル（Labels）です。ラベルはバージョンへの「ポインタ」として機能し、デプロイ管理を柔軟に行えます。

ラベル	用途
`production`	本番環境で使用するバージョン
`staging`	ステージング環境でテスト中
`latest`	最新バージョン（自動付与）
カスタム	テナント別、実験用など自由に定義可能

ロールバックはラベルを付け替えるだけで実行できます。コード変更やデプロイは不要です（アプリケーション上で、常にproductionラベルが付与されたプロンプトを取得するよう事前に設定しておくイメージ。これによりアプリケーション側のコードを変更することなく、内部で使用するプロンプトを更新できます）。

Before: version 3 → production
After:  version 2 → production  // UIでポチッと変更するだけ

Config設定

プロンプトと一緒に、モデル名やパラメータも管理できます。

{
  "model": "gpt-4o",
  "temperature": 0.7,
  "max_tokens": 1000
}

これにより、「このプロンプトはどのモデルのどの設定で動かすべきか」という情報もセットで管理でき、二重管理の問題がさらに軽減されます。

2. Langfuse上でのプロンプト評価の仕組み

Scoreによる評価管理

Langfuseでは、LLMの出力に対してScoreを付けることで品質を追跡できます。

データ型	説明	例
NUMERIC	数値スコア	0.0〜1.0
CATEGORICAL	カテゴリ	"良い"、"普通"、"悪い"
BOOLEAN	真偽値	合格/不合格

Human Annotation（人間による評価）

Annotation Queues機能を使うと、大規模なアノテーション作業を効率化できます。

1. 評価基準（Score Config）を事前定義

まず、評価基準を事前に定義しておきます。以下に例として、クレーム対応メール生成Botで使用するプロンプトを評価するための基準を載せておきます。

2. 評価対象のトレースをキューに追加

続いて、Langfuseでトレースしているアプリケーションのログをキューに追加します。

3. アノテーターがGUI上で順次評価

評価者は、Human Annotationからステータスが「Pending」になっているものを選択し、

以下のように、事前に定義した評価基準に基づいて評価を行います。

4. 評価結果がScoreとして記録される

評価が完了すると、結果がScoreとしてLangfuseに記録されます。

LLM-as-a-Judge（自動評価）

人間の評価と併用して、LLMによる自動評価も可能です。

組み込みの評価テンプレート：

Hallucination（ハルシネーション検出）
Helpfulness（有用性）
Relevance（関連性）
Toxicity（有害性）
Correctness（正確性）

大量のトレースを評価する際に、まずLLM-as-a-Judgeでスクリーニングし、閾値以下のものを人間がレビューするといった運用が可能です。

3. アプリケーションからのプロンプト利用方法

Langfuseの最大の利点は、プロンプト名とラベル（タグ）を指定するだけで動的にプロンプトを取得できる点です。これにより、アプリ側のコード変更なしでプロンプトを更新できます。

Python SDKでの取得

from langfuse import Langfuse

langfuse = Langfuse()

# productionラベルのプロンプトを取得（デフォルト）
prompt = langfuse.get_prompt("claim_response_generation")

# ラベル指定で取得
prompt = langfuse.get_prompt("claim_response_generation", label="production")

# 特定バージョンを取得
prompt = langfuse.get_prompt("claim_response_generation", version=2)

変数の展開

# プロンプトを取得
prompt = langfuse.get_prompt("claim_response_generation")

# 変数を展開
compiled = prompt.compile(
   customer_inquiry="ログインできません"
)

# LLMに渡す
response = openai.chat.completions.create(
    model=prompt.config["model"],
    messages=compiled,
)

ポイントは、アプリケーションコードは一切変更せずに、Langfuse上でプロンプトを更新するだけで本番に反映されるという点です。これでNotionとの二重管理問題が解消されます。

補足：Difyとの連携

Dify 0.6.12以降、Langfuseとのトレーシング統合がビルトインで提供されています。

設定方法：

Difyの「Orchestration Studio → Monitoring」タブを開く
LangfuseのAPIキーを設定

これにより、Difyで実行されたワークフローのトレースがLangfuseに送信され、可観測性が向上します。

プロンプト管理の直接連携については、コミュニティの dify-plugin-langfuse を使うことで、Difyワークフロー/チャットフロー内からLangfuseのプロンプトを取得・利用することも可能です。

キャッシュによる可用性確保

SDKはクライアントサイドキャッシュを実装しており、Langfuse APIに障害が発生してもアプリケーションは動作を継続できます。

# キャッシュTTLを設定（デフォルト60秒）
prompt = langfuse.get_prompt("movie-critic", cache_ttl_seconds=300)

残る課題：評価基準の設計は人間の仕事

Langfuseを導入すれば、プロンプトの管理・配信・トレーシングは大幅に改善されます。しかし、評価基準そのものはドメインエキスパートが設計するしかないという点は変わりません。

何をもって「良いプロンプト」とするのか
どの出力が「正解」なのか
品質の閾値はどこに設定するのか

これらの判断は、ドメイン知識を持つ人間にしかできません。LLM-as-a-Judgeも結局は「人間が定義した評価基準」に基づいて動作するので、基準設計は依然として人間の仕事です。

良し悪しの判断——これこそが、人間が介在することで生まれる数少ない価値の一つです。ツールで効率化できる部分はツールに任せ、人間は本質的な価値判断に集中する。Langfuse導入後は、この役割分担を意識した運用を進めていきたいと考えています。

まとめ

課題	Langfuseによる解決
二重管理問題	アプリから動的取得、Single Source of Truth化
非エンジニアの編集	GUIでの直接編集
品質評価	Score機能 + Annotation Queues

Langfuseは、Notion運用で抱えていた課題の多くを解決できる可能性を持っています。引き続き検証を進め、本番導入に向けた知見を蓄積していく予定です。

参考リンク - Langfuse Documentation - Prompt Management - Evaluation / Scores - Dify x Langfuse Integration

LangfuseによるPromptOpsの実践[入門編]

目次