数百のAI関連機能を提供するLayerXは、なぜLLMOpsにLangfuseを選んだか
AIエージェントの開発や運用に欠かせないのが、LLMOps（Large Language Model Operations）だ。これはDevOpsのように、LLMアプリケーションの開発から運用までを包括するプロセスだが、特にAIエージェントの運用では、LLM特有の不安定な出力をビジネス品質に高めるための制御が重要だ。そこで注目されているのが、プロンプトの管理や、出力の計測や評価を行う「LLMオブザーバビリティ」である。同社のバクラク事業部で機械学習チーム AI・MLOpsテックリードを務める中村弘武氏は、その重要性を「評価なくしてAIエージェントの開発なし」と表現する。
LayerX バクラク事業部 機械学習チーム AI・MLOpsテックリード 中村 弘武氏
評価すべき切り口や、取り扱うデータはドメインによってまちまちだ。特に同社のサービスは、経費精算から契約管理まで、広範なバックオフィス業務をカバーしなければならない。例えば契約管理では、PDFファイルの入力に加えて顧客のプレイブックや社内ルールといったナレッジを扱い、並列で5タスクほどLLMを実行した結果を合体させて最終的なアウトプットを出力する。こうした複雑な構成では、エンジニアが考えた評価手法をどれだけ簡単にセットアップし、素早くプロンプトを改善していけるかがLLMOps成功の鍵を握る。
また、LLMオブザーバビリティでは、AIへの入出力や思考過程を記録するトレースが欠かせない。しかしAIエージェントのマルチモーダル化が進み、音声や画像なども取り扱えるようになった結果、膨大なデータを保存し、高速に読み書きできるデータ基盤の実現も、円滑なLLMOpsを実現するうえで重要なポイントとなった。
こうした背景の下、LLMOpsの基盤として同社が採用したのが、ClickHouseが提供する「Langfuse」だ。採用のきっかけは、AI申請レビュー機能の開発中に、プロンプトの入れ替えを動的に行いたいという要件が生じたことだった。
プロンプトがアプリケーションに直接書き込まれていると、変更のたびに再デプロイが必要になってしまう。そこで外部にプロンプトを置き、毎回そこから取得すれば、デプロイなしにプロンプトだけを入れ替えられる。同社のバクラク事業部 申請・経費精算自動承認開発チームに所属する大森貴通氏は「プロンプトを変えたいときにすぐ変え、戻したいときにすぐ戻せるという機動力が欲しかった」と、当時を振り返る。
LayerX バクラク事業部 申請・経費精算自動承認開発チーム 大森 貴通氏
Langfuseの導入により、顧客の実際の出力結果を見ながら、プロンプトをリアルタイムに調整することが可能となった。Langfuse導入の効果はそれだけではない。トレースとプロンプトが自動的に紐付けられて記録されるので、プロンプトの変更による良し悪しを評価しやすくなった。
また、評価用のデータが大幅に増えたことで、性能評価の改善に大きく貢献した。具体的には、顧客や社内メンバーによる開発中機能のテスト時に、データセットにない未知の書式などのパターンを、LLM as a judge（評価者としてのLLM）によるオンライン評価で事前に検知し、リリース前に修正できるようになった。実運用では、未知のパターンの報告から約2日で修正版を提供できたケースもあるという。さらに、トレースを評価用データセットに加える機能により、従来は評価者からSlackやファイルの受け渡しが必要だった失敗例の収集がエンジニア自身の操作で完結するようになり、コミュニケーションコストも下がった。
「Langfuseにより、AIエンジニア以外の人間もAIの評価がしやすい基盤が整った。弊社はサービスのリリース前に『社内のみんなに触ってもらう』という文化が強いので、その結果のトレースが適切に取れることは、今後の性能評価の改善に役立つ貴重なデータとなる」（中村氏）
ClickHouseの魅力は「列指向DBとしての圧倒的な速さ」と「進化のスピード」
Langfuseを選んだもう1つの理由として大森氏が挙げるのは、セルフホスティングが可能だった点だ。LayerXは経費精算の申請や契約書といった顧客のデータを預かり、LLMへの入力として扱う。そのため、トレースデータの置き場所を自社で管理できることは必須要件だった。しかし当時、他のLLMOpsサービスはクラウド版しか存在せず、かつ日本リージョンもないという問題があった。その点、LangfuseはOSS版のセルフホスティングが可能であり、自社が契約するAWS上に基盤を構築してデータの所在を完全に管理下に置けた。
また、LangfuseはSSO機能を標準で提供している。自社IdPと連携して社員のみにアクセスを限定するなど理想とするアクセス制御を実装しやすかったことも、この構成を選択した理由だと、大森氏は話す。
Langfuseのバックエンドとなるデータ基盤には、OLAP（オンライン分析処理）向けの高性能な列指向SQLデータベース「ClickHouse」を選択した。Langfuseの公式ドキュメントでも、バックエンドとしてClickHouseの利用が推奨されている。さらに、Web上に公開された構築事例も多く、Langfuseとの組み合わせで最もサポートが充実していると判断したのも大きな理由だった。
加えて中村氏は、ClickHouseそのものの魅力として次の2点を挙げる。第一に、列指向データベースとしての圧倒的な速さ。そして第二に、進化のスピードだ。ClickHouseは列指向データベースとしての基本機能に加え、検索インデックスやベクトル検索の高速処理など、様々な機能を迅速に開発・提供し続けている。
「ClickHouseの技術情報をずっと追いかけているが、高速化に圧倒的なこだわりを感じて、個人的にも大好きな製品だ。また弊社LayerXの事業成長速度に負けないくらいClickHouseの進化が速いので、将来性にも大いに期待している」（中村氏）
システム構成としては、AWSのECS上にセルフホストする形を採用している。前段にはLangfuseのアプリケーションサーバーとワーカーが配置され、その後方でClickHouseが、Langfuse1台につき2台の冗長構成でトレースデータを支えているという、比較的一般的な構成だ。当然ながらこれらのクラスタは、動作状況に応じてオートスケールするように構築されている。
実運用では想定外の難しさにも直面した。ClickHouseはデータ永続化のために外部ストレージを必要とし、同社の環境ではAmazon EFSを利用している。一方AIエージェントは、動作次第で保存すべきトレース量が大きく変動する。大森氏によれば、事前にデータ量や読み書き速度を見積もるキャパシティプランニングが難しく、構築初期の検証時には、データが失われるトラブルにも遭遇した。構築自体は1週間ほどで完了したものの、こうした問題を2カ月かけて修正し、安定稼働に至った。
新規エージェントが生成するトレース量は事前に予測しにくいため、SREと連携しながらインフラリソースの見積もりを慎重に吟味する必要がある。LayerXのようなAI機能を組み込んだプロダクトを次々とリリースする企業であれば、その負担は尚更だ。さらに、Langfuseは頻繁にバージョンアップが行われるため、その管理コストも今後負担となる恐れがある。
ところが2026年4月、状況に変化が生じた。ClickHouseが、Langfuseのクラウドサービス版であるLangfuse Cloudの日本リージョンの提供を開始したからだ。そこでLayerXは、現在OSS版のセルフホスティングからクラウドサービス版への移行を検討しているという。
「現状ではキャパシティの調整のため、リリースのスケジュールが後ろ倒しになってしまうこともある。しかしクラウド版であれば、ワークロードに合わせて柔軟なスケーリングが可能となり、バージョンアップも自動で適用される。開発のスピードを緩めることなく、事業の成長に集中できるメリットは非常に大きい」（大森氏）
LLMOpsの構築によって、定量的に評価し、正しい判断を下す
Langfuse運用の課題は、インフラ面だけではない。ドメインやアプリケーション固有の評価にも難しさがあると、二人は言う。Langfuseの標準UIはドメイン特化ではないため、例えば契約書の原本と抽出データを並べて比較したい、ファイルの特定箇所同士が合っているかを表示したいといった、各サービス固有の見方を表現できない。そのため各チームがドメインごとに評価閲覧用のビューを別途開発しているのが実情だ。評価点とその見せ方は、ドメインごとに人間が設計・実装せざるを得ないが、今後共通化できるものはしていきたいと、大森氏は言う。
ここで2人に、Langfuseのお気に入りの機能を紹介して頂いた。中村氏が挙げるのはCode Evaluatorsと全文検索の2つだ。Code Evaluatorsは、これまでLLM as a judgeが前提だった評価の仕組みに、スクリプトを直接組み込める機能だ。エージェント出力の決定論的な評価が可能になるだけでなく、各チームが作った評価コードをそのままLangfuseに組み込むことで、ドメインごとに異なる評価要件への対応が格段に容易になったという。
また全文検索は、トレースの入出力テキストに対してキーワード検索をかけられる機能だ。LLM as a judgeが発火しなかった大量のトレースの中から、例えば「秘密保持契約で失敗したトレース」といった特定の失敗パターンを探し出すのに役立っている。現在Langfuseが提供するのはキーワード検索のみだが、中村氏はClickHouseのベクトル検索技術を応用した類似検索の開発にも期待を寄せる。
大森氏が挙げるのはLangfuse MCPとCLIだ。従来ブラウザから人間が操作するしかなかったトレースの確認やプロンプト管理が、これらのリリースを経てターミナルから実行可能になった。その真価は、手元のコーディングエージェントがCLIを叩いて、トレース確認からプロンプト改善、再実行、結果検証までを自律的に回せる点にある。人手で改善サイクルを回していた時間が浮き、プロンプト最適化の自動化に直結する機能として高く評価している。
今後の展望として、同社が目指すのはモデル評価の自動化だ。新しいモデルは次々登場するが、同社サービスの数百にも上るAI機能について、モデルを入れ替えるために人手で評価を実施するのは現実的ではない。そこで、新しいモデルのリリースを自動検知し、自律的に評価を実行、コストや精度などの基準をクリアしたら、そのまま本番環境にデプロイするような仕組みが必要となる。
さらに将来的には、評価結果に基づき、プロンプトだけでなくツールやハーネスまでAIが自動で変更し、プルリクエストまで作成する、ループエンジニアリングの領域までを見据えているという。こうした運用のデータ基盤として、Langfuse環境を育てていきたいと、中村氏は語る。
最後にLLMアプリケーションの運用に悩む読者にメッセージを頂いた。大森氏が勧めるのは、段階的なプロセスの構築だ。まずはアプリケーションの入出力をトレースすることから始め、典型的な入力パターンが蓄積された段階でデータセット機能を用いた評価体制へと移行する。そして必要に応じて、プロンプト管理機能を活用しトレースデータと連携させながら動的にプロンプトをブラッシュアップしていくという、一連の改善サイクルを定着させることが重要だと説く。
一方、中村氏が強調するのは、計測の重要性だ。モデルの進化は速く、ハーネスの付け外しも頻繁に起こる。エンジニアが時間を費やして慎重に評価している最中に新たなモデルが登場すると、既存の構成への執着が生まれ、結果としてそれを手放すタイミングを逸してしまう。モデルやハーネスを迅速に更新するためにも、「捨てる判断」を迅速に下せるLLMオブザーバビリティ基盤をきちんと作るべきだというのだ。
「計測できていないとモデルを捨てるという判断はできない。AIエージェントの開発と運用は、評価に始まって評価に終わる」（中村氏）。LayerXのLLMOpsの進化はこれからも続いていく。
【8/20オンライン開催】Langfuse 初心者向け入門Webinar（30分・無料）
30分でクイックに解説！AIエージェント開発の新定番「Langfuse」とは？
本Webinarでは、AIエージェントの開発・運用を劇的にラクにする今大注目のLLMオブザーバビリティツール 「Langfuse」 について、初心者向けに分かりやすく解説します。「Langfuseを使うと何が解決するのか」「どうやって開発が効率化するのか」を、実際の画面デモを交えてわずか30分でサクッと学べる入門講座です。＜詳細・ご登録はこちら＞
【9/9東京開催】Langfuse ハンズオントレーニング（3時間・無料）
「Langfuseで始めるLLMOps実践ハンズオントレーニング」初開催決定！
エージェント全ステップのトレースから、プロンプトのLangfuse管理、LLM-as-a-judgeによる本番モニタリング、検証用データセットの構築、データセット全体に対する実験実行、そして変更前後のRun比較による評価まで。評価はルールベースとLLM-as-a-judgeを併用し、「変更 → 再実行 → 比較 → 出荷判断」のAIエンジニアリングループを実際に一周させ、自社プロダクトに組み込むスキルを実践的なハンズオンで習得します。＜詳細・ご登録はこちら＞
