DifyとLangfuseを使ったプロンプト改善の仕組みの検討

こんにちは、株式会社メンバーズデブオプスリードカンパニーの兼子です。

インフラエンジニアとして10年、私はシステムの「測定」と「改善」を繰り返してきました。CPU使用率、レスポンスタイム、エラーレート。これらの数値を見ながら、ボトルネックを特定し、改善し、また測定する。この当たり前のサイクルが、LLMアプリ開発では意外と回っていないことに気づきました。

「このプロンプト、なんとなく良さそう」「前より悪くなった気がする」

そんな曖昧な判断で、本当に良いのだろうか。DevOpsで培ってきた「測定可能性」の考え方を、LLMアプリ開発にも適用できないだろうか。

そう考えて導入したのが、DifyとLangfuseの組み合わせでした。

本記事の核：1分でわかる連携の価値

この記事で得られる3つのこと

1. Difyで高速開発 → ノーコードで数時間でLLMアプリを構築

2. Langfuseで測定可能な改善 → プロンプトの効果を数値で評価し、PDCAを高速に回す

3. DevOpsの知見をLLMアプリへ → 「Observability」「測定→改善」のサイクルをプロンプト開発に適用した実感

一言で言えば： Difyで作り、Langfuseで測定し、改善サイクルを回す。DevOpsでやってきたことを、LLMアプリ開発でも実現する仕組みです。[1][2]

Dify × Langfuse：役割分担で回す改善ループ

この2つのツールは、開発と改善で明確に役割が分かれています。

この表が示す核心： 開発はDifyで完結させ、改善ループはLangfuseで高速に回す。インフラの世界で当たり前だった「測定→改善」のサイクルが、LLMアプリ開発でも回せるようになりました。

3ステップの改善サイクル

DevOpsで慣れ親しんだサイクルを、プロンプト改善にも適用できました。

1. つくる（Dify）

何をするか： 数時間でプロトタイプを構築

• ドラッグ&ドロップでワークフローを組み立て

• RAG機能で社内ドキュメントを取り込み

• 複数のLLM（GPT-4、Claude、Geminiなど）を使い分け

成果物： 動くAIアプリケーション

2. みる（Langfuse）

何をするか： 実行ログを可視化し、ボトルネックを特定

• API Keyを設定するだけで、Difyの全実行がLangfuseに自動記録

• トレース画面で「どのステップに時間がかかっているか」「コストはいくらか」を確認

• エラー発生箇所を即座に特定

成果物： 改善すべきポイントのリスト（レイテンシ、コスト、品質）

3. 直す（Dify × Langfuse）

何をするか： 測定結果をもとに、改善のプロセスを回す

• Dify上でプロンプトを修正（プロンプトはDify内に置いたままでOK）

• Langfuseで実行ログを確認し、改善の効果を数値で測定

• 複数バージョンをA/Bテストで比較し、最適なものを選択

• うまくいかなければ、ログを見て原因を特定し、再度修正

成果物： 継続的に品質が向上するAIアプリケーション

重要なのは、この3ステップを回し続けられる「視点」を持てたことです。インフラの世界では当たり前だった「メトリクスを見て、仮説を立て、改善し、また測定する」というサイクル。それがLLMアプリ開発でも実現できると分かったのが、最大の収穫でした。[3]

実際に運用してみて、やってよかったこと

ここからが、この記事で最もお伝えしたい部分です。DevOpsエンジニアとして、Langfuseを導入して実感した3つの「よかったこと」をご紹介します。

1. 個人の感覚ではなく、「測定可能な指標」で改善できるようになった

従来、プロンプトの良し悪しは個人の感覚や経験に依存していました。

「このプロンプト、なんとなく良さそう」
「前より悪くなった気がする」

インフラエンジニアとして、こういう曖昧な判断には常に違和感がありました。CPUが「なんとなく重い気がする」では改善できない。数値で測定し、ボトルネックを特定し、改善する。それがDevOpsの基本です。

Langfuseを導入したことで、レスポンス時間、トークン数、コストといった具体的な数値が可視化されるようになりました。

何が変わったか：

• 「速くなった気がする」→「P95レイテンシが200ms改善」

• 「コストが心配」→「1実行あたり0.03ドルから0.02ドルに削減」

• 「品質が上がった」→「評価スコアが平均3.2から4.1に向上」

数値で語れるようになったことで、改善の効果を定量的に示せるようになりました。これはまさに、DevOpsにおける「測定可能性（Measurability）」の考え方そのものです。

プロンプト改善の優先度判断も、感覚ではなくデータで行えるようになりました。

2. チーム全員が「同じ視座」でプロンプトを見られるようになった

以前は、プロンプトの改善がエンジニア個人のスキルに依存していました。

「Aさんはプロンプトが上手い」
「Bさんはまだ慣れていない」

この「属人化」も、インフラの世界では避けるべき状態です。誰か一人しか触れない環境、誰か一人しか理解していない設定。そういう状態は、チームの脆弱性になります。

Langfuseで実行ログとメトリクスを可視化したことで、誰でも同じ情報を見て、同じ基準で判断できるようになりました。

何が変わったか：

• プロンプトの変更履歴が全て記録され、「誰が、いつ、なぜ変更したか」が明確

• 過去のバージョンと現在のバージョンを並べて比較可能

• エンジニア以外のメンバー（企画、ビジネス側）も実行ログを見て議論できる

これにより、複数人で同じ目線でプロンプトを改善できるようになりました。DevOpsの「透明性（Transparency）」と「共通言語」が、LLMアプリ開発にも適用できた実感があります。

個人のスキルに頼るのではなく、チーム全体で改善サイクルを回せる。これは、持続可能な開発体制を作る上で非常に重要だと感じています。

3. DevOpsのように「測定→改善」のPDCAサイクルを回せるようになった

インフラエンジニアとして、これが最も感動したポイントです。

DevOpsでは「メトリクスを測定し、ボトルネックを特定し、改善する」というサイクルを回します。Prometheus、Grafana、Datadog。ツールは違えど、本質は同じです。

「測れないものは、改善できない」

この原則が、LLMアプリ開発でも実現できました。

具体的なサイクル：

• Plan（計画） → Langfuseで現状のメトリクスを確認し、改善ポイントを特定

• Do（実行） → Difyでプロンプトを修正

• Check（評価） → Langfuseで効果を測定。評価スコアとメトリクスで比較

• Act（改善） → 効果の高いバージョンを本番適用。効果が薄ければ再度改善

このサイクルを数時間〜数日単位で高速に回せるようになったことで、プロンプトの品質が継続的に向上していく実感があります。

改善のプロセスを回せる「視点」を持てたこと

これが最大の収穫でした。ツールの使い方を覚えたのではなく、「LLMアプリ開発でも、測定→改善のサイクルを回せる」という視点を得られたのです。

インフラの世界で「Observability（可観測性）」「Infrastructure as Code」が当たり前になったように、LLMアプリ開発でも「測定可能な改善サイクル」が重要になると感じています。

Dify × Langfuseは、DevOpsエンジニアが持つ知見を、LLMアプリ開発に活かせることを教えてくれたツールセットでした。

まとめ

Dify × Langfuseの組み合わせは、LLMアプリ開発に「測定→改善」のサイクルをもたらします。

この記事の核心：

• Dify → 高速な開発基盤（数時間でプロトタイプ）

• Langfuse → 測定可能性の提供（メトリクスと実行ログの可視化）

• 改善サイクル → DevOpsで培った知見を、LLMアプリ開発に適用

DevOpsエンジニアとしての実感：

インフラの世界で当たり前だった「測定→改善」のサイクルが、LLMアプリ開発でも回せることが分かりました。ツールは違えど、本質は同じ。「測れないものは、改善できない」という原則は、どの領域でも変わりません。

Dify × Langfuseは、DevOpsエンジニアが持つ知見を、新しい領域に活かせることを教えてくれました。