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版のセルフホスティングからクラウドサービス版への移行を検討しているという。
「現状ではキャパシティの調整のため、リリースのスケジュールが後ろ倒しになってしまうこともある。しかしクラウド版であれば、ワークロードに合わせて柔軟なスケーリングが可能となり、バージョンアップも自動で適用される。開発のスピードを緩めることなく、事業の成長に集中できるメリットは非常に大きい」（大森氏）
