この記事のポイント 前編では、Langfuse v3.158.0の "fulltext search" が実装上は部分一致検索であること、そして3層の検索アーキテクチャの全体像を解説しました。 後編では、PR #12578のソースコードを詳しく読み、以下の2点を明らかにします。 プロンプト編集画面のTextモードとChatモードで 検索の挙動が異なる こと、特にChatモードではカウンターとハイライトが食い違うケースがあること サーバーサイド検索（ClickHouse / PostgreSQL）を含めた、日本語利用時の 具体的な制約（Limitation） → 前編はこちら：「Langfuse v3.158.0の"fulltext search"を読み解く — その実態は部分一致検索だった」 （ リンク ） PR #12578のコードリーディング 検索のエントリポイント：MessageSearchProvider 検索機能のアーキテクチャは、React Contextベースの MessageSearchProvider を中心に構成されています。

LMアプリケーションの可観測性（オブザーバビリティ）を確保しようとする際、Langfuse SDK や OpenTelemetry SDK をアプリケーション側に組み込んで計装するのが一般的なアプローチですが、これは多少なりとも手間がかかることと、社内のエージェントを勝手に動かす人などが意図的に観測されないように対応しないこともありえるでしょう。 しかしながら、LLM への呼び出しを LLM Gateway に集約することで、アプリケーション側での計装が不要になり、ガバナンスを高めることにも寄与します。 そこでこの記事では、Pythonアプリ（Google ADKエージェント / google-genai SDK）からのLLM呼び出しを API gateway である Kong経由に切り替え、Kongの組み込みOpenTelemetr プラグインから Langfuse の OTLP/HTTP エンドポイントへ直接トレースを送信するまでの手順をまとめます。 本記事の作成にあたりまして、Langfuse Night #3 の川村さんの登壇内容を参考