LLMでLLMを調教する：Claude Code × Langfuse で同族デバッグ環境を作った話

Langfuseを眺める日々

LLMを使ったプロダクトを運用していると、Langfuseのダッシュボードを眺める時間が増えていきます。

私たちNeuradexでは、AIエージェント向けのメモリプラットフォームを開発しています。LLMを多用しているので、Langfuseでのトレース監視は日常業務の一部です。

「このトレース、なんかレスポンス遅いな」「このセッション、途中で会話が破綻してる」「コスト跳ね上がってるけど、どのプロンプトが原因？」

問題のあるトレースを探して、入力と出力を見比べて、プロンプトを確認して、何が悪かったのか推測する。

この作業、LLMが得意なやつでは？

そう思って、Claude CodeにLangfuseを読ませてみました。結果、LLMが同族のダメ出しを始めました。

Claude Code × Langfuse Skills の仕組み

Claude Codeには「Skills」という機能があります。特定のタスクを実行するためのカスタムコマンドを定義できる機能です。

これを使って、Langfuse APIを叩くスキルを一通り作りました。

/langfuse-trace-list    # トレース一覧
/langfuse-trace-view    # トレース詳細
/langfuse-session-list  # セッション一覧
/langfuse-session-view  # セッション詳細
/langfuse-prompt-list   # プロンプト一覧
/langfuse-prompt-view   # プロンプト詳細
/langfuse-prompt-upsert # プロンプト更新
/langfuse-model-list    # モデル・コスト一覧

これで、Claude Codeに「Langfuseのデータを見て」と頼めるようになります。

LLMがLLMの「診察記録」を読めるようになった、というわけです。

実践：こうやって同族を調教する

基本的なフローはこうです。

Langfuse Consoleを眺める
怪しいtrace IDやsession IDを見つける
Claude Codeにそのまま投げる
分析させて、必要なら修正まで

例1: 怪しいトレースを診断させる

Langfuseで見つけた遅いトレース。IDをコピーして、Claude Codeに投げます。

このtrace ID見て: abc123-xxxx-yyyy
なんか遅いんだけど、原因わかる？

Claude Codeは /langfuse-trace-view でトレースの詳細を取得し、こんな感じで返してきます。

このトレース、input tokensが12,000超えてますね。system promptに含まれてる例示が多すぎます。few-shot examplesを3つから1つに減らすか、別の方法を検討した方がいいかもしれません。

JSONを眺めて「うーん、トークン数多いな」と思うより、具体的な改善案まで出してくれます。

例2: 破綻したセッションの原因分析

Langfuseでセッション一覧を眺めていたら、途中から会話が破綻しているセッションを発見。該当のセッションIDを投げます。

このsession見て: session-xyz-789
途中から会話がおかしくなってるんだけど

Claude Codeは /langfuse-session-view でセッション内の全トレースを取得。時系列で会話の流れを追って分析します。

5番目のターンで、ユーザーが日本語と英語を混ぜた入力をしています。ここでLLMが言語を誤認識して、以降の返答が英語ベースになってしまってますね。system promptに言語処理のルールを追加するか、言語検出のステップを入れた方がいいかも。

人間が同じ分析をしようとしたら、各ターンのinput/outputを全部読む必要があります。LLMなら一発で文脈を把握できます。

例3: ツールコールの挙動を分析させる

ツールコールのデバッグは特に厄介です。エラーで失敗するならまだ気づけますが、「エラーは出てないのに期待した動作と違う」パターンが一番追いにくい。

このsession見て: session-tool-unexpected-123
エラーは出てないんだけど、検索結果がおかしい

Claude Codeはセッション内の複数トレースをまたいでツールコールの流れを追い、こんな風に返してきます。

3番目のトレースで search_documents を呼んでますが、引数の query が空文字列になってますね。2番目のトレースの extract_keywords の出力を見ると、キーワードは抽出できてるんですが、それを query に渡す部分でフォーマットがずれてます。プロンプトで出力形式を明示するか、パース処理を見直した方がいいです。

エラーが出ないケースは、複数トレースのJSONを展開して「どこで意図と違う値になったか」を追う必要があります。LLMならセッション全体を見て「ここで値がおかしくなってる」と流れを追って指摘してくれます。

例4: プロンプト改善まで任せる

問題の原因がプロンプトにあるとわかったら、そのまま修正を依頼できます。

このプロンプト改善して: my-chat-prompt
さっきの言語混在問題が起きないように

Claude Codeは /langfuse-prompt-view で現在のプロンプトを取得し、改善案を提示。OKなら /langfuse-prompt-upsert でLangfuseに直接反映できます。

開発環境のプロンプトを更新して、問題が起きないか検証。問題なければ、Langfuse Consoleから「Promote to Production」で本番反映。このループが会話だけで完結します。

なぜ「LLMにLLMを診断させる」が有効なのか

1. JSON地獄から解放される

Langfuseのトレースデータはネストが深いです。metadata、input、output、spans...。これを人間が読み解くのは結構しんどい。

LLMに渡せば、構造を理解した上で「要するにこういうこと」とサマリーしてくれます。

2. 「なんかおかしい」をそのまま伝えられる

「レスポンスが変」「なんか遅い」「コストが高い気がする」

こういう曖昧な訴えを、LLMはちゃんと解釈してくれます。具体的なメトリクスに落とし込んで、問題を特定してくれます。

3. 会話しながら深掘りできる

「それ、もう少し詳しく」「他のトレースと比較して」「じゃあどう直せばいい？」

対話的に掘り下げていけます。ダッシュボードをポチポチするより、思考の流れに沿ってデバッグできます。

Skillsは意外と簡単に作れる

今回使ったスキルは、基本的にはLangfuse APIをラップしているだけです。

# /langfuse-trace-view

trace IDを受け取って、Langfuse APIから詳細を取得。
結果をMarkdownで整形して返す。

Claude CodeのSkillsは、自然言語でタスクを定義できます。API呼び出しの詳細は、Claude Codeが解釈してくれます。

1つのスキルを作るのに、30分もあれば十分。一度作っておけば、チーム全員が /langfuse-trace-view abc123 で同じことができるようになります。

まとめ

LangfuseのデータをClaude Codeで読めるようにした
怪しいtrace/session IDを投げるだけで、LLMが診断してくれる
プロンプトの修正までそのまま依頼できる
LLMの調教は、LLMに任せる時代

同族に同族を診させる。ちょっとメタですが、LLMの出力を理解するのにLLMを使うのは理にかなっています。彼らは同じ言語を話すのですから。

Neuradexでは、こうしたLLMの運用ノウハウを活かしながら、AIエージェントがより賢く動けるメモリ基盤を作っています。LLMを「使う」だけでなく「育てる」時代。その環境づくりを進めていきます。