Difyのモニタリング連携を実践 ─ LangSmith・LangfuseでAIの動作を「見える化」する

前回の記事では、DifyのAPI・Webhook・MCP連携について解説しました。外部サービスと「つながる」ことで、AIは単なる話し相手から実務パートナーへと進化します。

しかし、AIアプリを本番で運用し始めると、こんな疑問が浮かんできませんか？

「最近、AIの回答がおかしい気がする。でも、何が原因なのか分からない…」

その答えがモニタリング連携です。この記事では、DifyのOpenTelemetry対応機能を使って、AIの動作を「見える化」し、継続的に品質を改善する方法を解説します。

Data Insightでは、AIを人間の創造性を支援するパートナーとして位置づけています。パートナーの調子が悪いときに「どこが悪いか」を把握できなければ、改善のしようがありません。モニタリングは、そのパートナーシップを健全に維持するための基盤です。

§ 1. なぜモニタリングが必要なのか ─ ブラックボックスの問題

§ 「AIが何を考えているか、なぜ失敗したかを、見えるようにできる」

これがモニタリングの本質です。ChatGPTやClaudeを使っていると、「AIが何を考えて、その回答を出したのか」が見えません。うまくいっている間は問題ありませんが、うまくいかなくなったときに困ります。

§ 本番運用で必ず直面する3つの課題

AIアプリを本番で運用していると、以下の課題に直面することが多いです。

§ 「何がおかしいのか」の特定に時間がかかる

モニタリングがない状態でこれらの問題が発生すると、原因特定に膨大な時間がかかります。

• 「プロンプトを変えてみよう」→ 変わらない
• 「モデルを変えてみよう」→ 変わらない
• 「データを見直してみよう」→ 膨大な作業量

このような試行錯誤を繰り返すより、最初から「何が起きているか」を把握できる仕組みを整えておく方が効率的です。

§ 2. Difyのモニタリング連携の全体像

§ OpenTelemetryを標準規格として採用

Difyは、業界標準のオブザーバビリティ規格である**OpenTelemetry（OTel）**に対応しています。OpenTelemetryは、トレース・メトリクス・ログを統一的に扱うための標準規格で、多くのモニタリングサービスが対応しています。

これにより、Dify専用の仕組みを覚える必要なく、既存のオブザーバビリティツールをそのまま使用できます。

§ 対応サービス一覧

Difyは以下のLLMOps・オブザーバビリティサービスとの連携に対応しています。

§ どのサービスを選ぶべきか

初めてモニタリングを導入する場合は、以下を参考にしてください。

• LangChainを使っている → LangSmith（エコシステムの一貫性）
• オープンソース・コスト重視 → Langfuse（セルフホスト可能）
• 既存のMLOps基盤がある → Arize または W&B Weave（既存ツールとの統合）

どれを選んでも、Dify側の設定は同じパターンで行えます。

§ 3. 連携の設定 ─ LangSmith・Langfuseの場合

§ 設定はAPIキーとプロジェクト名の入力で完了

DifyのモニタリングはAPIキーとプロジェクト名を設定するだけで利用できます。複雑なインフラ構築は不要です。

§ Dify側の「監視」設定画面での手順

§ LangSmithの場合

1. LangSmithで新規プロジェクトを作成
2. LangSmithのAPIキーを取得（Settings → API Keys）
3. Difyのアプリ設定 → 監視 → LangSmithを選択
4. APIキーとプロジェクト名を入力
5. 保存して完了

§ Langfuseの場合

1. Langfuseでアカウント作成（またはセルフホスト）
2. プロジェクトを作成し、Public Key / Secret Keyを取得
3. Difyのアプリ設定 → 監視 → Langfuseを選択
4. Host（デフォルトまたはセルフホストURL）とキーを入力
5. 保存して完了

§ 何がエクスポートされるか

連携後、以下のデータがモニタリングサービスに自動送信されます。

§ 4. 把握すべき指標 ─ 何を見るべきか

モニタリングで「すべてを見よう」とすると、情報過多で逆に何も分からなくなります。まずは以下の4つの指標に集中してください。

§ 1. トレース（実行履歴）

何を見るか: どのノードがいつ実行されたか、データがどう流れたか

活用シーン:

• 「回答がおかしい」→ どのノードで想定外の出力が発生したか特定
• 「途中で止まった」→ どのノードでエラーが発生したか特定

確認ポイント:

• 各ノードの入出力が期待通りか
• 条件分岐が意図した方向に進んでいるか
• RAGの検索結果が適切か

§ 2. トークン消費量とコスト

何を見るか: モデル別・ワークフロー別のトークン消費量と推定コスト

活用シーン:

• 「請求が想定を超えた」→ どのワークフローが原因か特定
• 「コストを削減したい」→ 消費量の多いノードを最適化

確認ポイント:

• 入力トークンと出力トークンの比率
• 同じ処理でもトークン数にばらつきがないか
• 不要な情報をプロンプトに含めていないか

§ 3. レイテンシ

何を見るか: 各ノードの実行時間、ボトルネックの特定

活用シーン:

• 「応答が遅くなった」→ どのノードが遅いか特定
• 「ユーザー体験を改善したい」→ 並列化できる処理を発見

確認ポイント:

• LLMノードの応答時間（モデルによって異なる）
• 外部API呼び出しの応答時間
• RAG検索の実行時間

§ 4. エラー率

何を見るか: 失敗したワークフロー・ノードの傾向分析

活用シーン:

• 「たまに失敗する」→ どの条件で失敗するか特定
• 「特定のユーザーだけ失敗する」→ 入力パターンの問題を発見

確認ポイント:

• エラーが発生するノードのパターン
• エラーメッセージの内容
• 時間帯や負荷との相関

§ 5. 事例 ─ モニタリングによるAI精度改善

§ 製造業のマニュアル検索AI

ある製造業の企業で、生産ラインの作業者向けに「マニュアル検索AI」を導入しました。作業中に不明点があれば、AIに質問して即座に回答を得られる仕組みです。

§ 課題：検索時間が長い・偶に不正確な回答が出る

導入後、以下の問題が報告されました。

• 「質問してから回答が返ってくるまで、待ち時間が長い」
• 「たまに、全然関係ない回答が返ってくる」

モニタリングなしでは、「プロンプトが悪いのか」「モデルが悪いのか」「データが悪いのか」の判断がつきませんでした。

§ モニタリング導入：トレースで原因を発見

Langfuseを導入し、トレースを分析した結果、以下のパターンを発見しました。

1. 不正確な回答のパターン: Rerank処理後のスコアが閾値（0.3）以下でも、結果を返していた
2. 遅延のパターン: チャンクサイズが大きすぎて、検索に時間がかかっていた

§ 改善策の実施

トレース分析の結果を踏まえ、以下の改善を実施しました。

1. チャンキング戦略を変更: 固定長分割から親子分割（Parent-Child Chunking）に変更
2. Rerankスコア閾値を調整: 0.3以下の場合は「該当する情報が見つかりませんでした」と返す
3. 検索対象を絞り込み: メタデータフィルタリングで、質問に関連する部門のマニュアルのみを検索対象に

§ 結果：検索時間15分→1分未満、年間約1,200万円の削減

改善後の効果は以下の通りでした。

• 検索時間: 平均15分 → 1分未満
• 不正確回答率: 12% → 2%未満
• ライン停止損失: 年間約1,200万円の削減（検索時間短縮による）

§ この事例が示すもの

モニタリングなしでは、「Rerankスコアが低いまま回答を返している」という根本原因にたどり着けませんでした。「プロンプトを調整する」「モデルを変える」といった対症療法では解決できない問題でした。

モニタリングは「問題の根本原因」にたどり着くための必須ツールです。

§ 6. Dify内部のデバッグ機能との組み合わせ

外部モニタリングツールと、Dify内蔵のデバッグ機能を使い分けることで、効率的な問題解決が可能になります。

§ 変数インスペクター（ノード別の入出力確認）

Difyのワークフロー/Chatflow編集画面では、テスト実行時に各ノードの入出力を確認できます。

使いどころ:

• 開発・テスト段階での動作確認
• 単発の問題調査
• プロンプトの調整

§ 実行履歴の確認と再実行

Difyの「ログ」画面では、過去の実行履歴を確認し、同じ入力で再実行できます。

使いどころ:

• 「この入力で失敗した」の再現
• 修正後の動作確認
• ユーザーからの報告を受けての調査

§ 外部モニタリングと内部デバッグの使い分け

§ よくある質問

§ Q. モニタリング機能を使うと、AIの応答速度に影響しますか？

モニタリングデータの送信は非同期で行われるため、ユーザーへの応答速度にはほとんど影響しません。ただし、大量のデータを送信する場合は、ネットワーク負荷を考慮する必要があります。

§ Q. LangSmithとLangfuseのどちらを選ぶべきですか？

LangChainエコシステムを使っている場合や、評価（Evaluation）機能を重視する場合はLangSmithがおすすめです。コストを抑えたい場合や、データを自社環境に留めたい場合はLangfuseのセルフホスト版が適しています。どちらも無料プランがあるので、両方試してから決めることをおすすめします。

§ Q. モニタリングデータに顧客情報が含まれる場合、プライバシーはどうなりますか？

入出力データには顧客の個人情報が含まれる可能性があります。LangSmithやLangfuse（クラウド版）を使用する場合は、利用規約とプライバシーポリシーを確認してください。Langfuseのセルフホスト版を使えば、データを自社環境内に留めることができます。

§ Q. どのくらいの頻度でモニタリングを確認すべきですか？

本番運用開始直後は毎日確認することをおすすめします。安定稼働後は、週1回の定期確認と、問題発生時の都度確認で十分です。アラート機能を設定しておけば、異常時に通知を受け取ることもできます。

§ Q. モニタリングツールの料金はどのくらいですか？

LangSmithは月間5,000トレースまで無料、それ以上は従量課金です。Langfuseは月間50,000オブザベーションまで無料（クラウド版）、セルフホスト版は無料で無制限に使用できます。小規模な運用であれば、無料プランで十分対応できます。

§ まとめ ─ モニタリングは「品質を維持し続ける」ための基盤

AIアプリは「作って終わり」ではありません。本番で運用し続ける中で、精度が下がったり、コストが上がったり、パフォーマンスが劣化したりすることがあります。

モニタリングは、これらの問題を早期に発見し、根本原因を特定し、継続的に改善するための基盤です。

§ この記事のポイント

1. モニタリングなしでは「何がおかしいのか」が分からない ─ 試行錯誤に時間を浪費する前に、可視化の仕組みを整える
2. OpenTelemetry標準で複数ツールに接続可能 ─ LangSmith・Langfuse等、自社の環境に合ったツールを選べる
3. 4つの指標に集中する ─ トレース・コスト・レイテンシ・エラー率を把握すれば、大半の問題に対処できる

Data Insightでは、AIを人間の創造性を支援するパートナーとして位置づけています。パートナーの調子が悪いときに「どこが悪いか」を把握できなければ、改善のしようがありません。

モニタリングは、そのパートナーシップを健全に維持し、継続的に価値を高めていくための投資です。

§ 次のステップ ─ AIの機能をさらに拡張する

AIアプリの運用基盤が整ったら、次は機能の拡張です。

「AIアプリの運用は分かった。では、機能をさらに拡張したい場合は？」

次の記事では、Difyのプラグインシステム ─ 導入・開発・カスタマイズを解説します。標準機能では足りない処理を追加する方法、既存のプラグインを活用する方法、自社専用のプラグインを開発する方法まで、段階的に説明します。

→ 次へ：上級編 ─ プラグインで機能を拡張する実践ガイド