こんにちは。ガオ株式会社の黒澤です。LLMアプリケーションを複数開発する環境では、それらを統合する基盤であるAI Gatewayを活用するケースがあります。本記事では、AI Gatewayとして３つの製品を、Langfuseと組み合わせた場合のポイントとともに解説します。
結論から言うと、Langfuse連携の見やすさを重視するならLiteLLMが最も扱いやすいです。すでにKongをAPI Gatewayとして運用している組織ではKong連携が自然な選択肢です。一方、Bifrostは手元で素早く試せる軽量さが魅力ですが、v1.4.24時点ではOTelスパンが多く、Langfuse上の視認性には課題があります。
想定読者・この記事でわかること#
想定読者：
- LangfuseでLLMのトレースを取りたい方
- AI Gatewayの導入を検討中で、製品選定に迷っている方
この記事でわかること：
- Bifrost・LiteLLM・Kongの3製品をLangfuse連携の観点で比較
- 3製品のLangfuseトレースの見え方の違い（スクリーンショット付き）
- BifrostをVertex AI + Langfuse OTelで動かす際のセットアップのポイント
すでにBifrostを動かしている方は「Langfuseのトレース品質比較」セクションへどうぞ。
課題：AI Gatewayを入れてLangfuseでトレースを見たい、でも製品によって差があり#
LLMを本番サービスに組み込む際、複数プロバイダーの切り替えやコスト管理、オブザーバビリティを一元化するためにAI Gatewayを挟む構成が増えています。本記事ではその中でもLangfuse連携によるオブザーバビリティの観点に絞って比較します。
当社ブログではすでに Kong AI Gateway + Langfuse連携 と LiteLLM Proxy on Google Cloud を紹介してきましたが、機能比較表ではどれも「Langfuse対応」と書かれています。しかし実際に使ってみると、トレースの視認性や設定コストに差がありました。
製品によってLangfuseへの連携方法も、実際のトレースの見え方も大きく異なります。今回はその比較を一本の記事にまとめることにしました。
今回の検証で扱う構成の全体像は次のとおりです。
graph LR Client[クライアント SDK] --> GW[AI Gateway
Bifrost / LiteLLM / Kong] GW --> LLM[LLM Provider
Vertex AI 等] GW -->|トレース送信| LF[Langfuse]
この構成のポイントは、アプリ側（クライアント SDK）に Langfuse の設定を一切書かなくてよい点です。トレースの収集は AI Gateway が担うため、既存のアプリコードを変更せずにオブザーバビリティを追加できます。
検証対象と前提#
比較対象はこの3製品です。
| 製品 | 概要 | 検証方法 |
|---|---|---|
| Bifrost | Go製のAI専用OSSゲートウェイ。npxまたはDockerで即起動できる | 自社でVertex AI + Langfuse OTel構成を実際に構築・検証（本記事） |
| LiteLLM | Python製のOSSゲートウェイ。100以上のLLMプロバイダーに対応し、Langfuse連携をネイティブサポート | 既存記事 のトレーススクリーンショットを参照 |
| Kong | 汎用APIゲートウェイとして広く使われており、AI Gateway機能をプラグインで追加できる | 既存記事 を参照 |
検証について： BifrostはVertex AI + Langfuse OTel構成を本記事で実際に構築・検証しています。LiteLLMとKongは当社の既存記事で詳しく解説しているため、本記事ではトレースの見え方の比較にとどめています。
検証環境の前提：
- Langfuseはセルフホスト版を使用しています（Cloud版とはOTelエンドポイントのホスト名が異なりますが、Cloud・self-hosted問わずパス
/api/public/otel/v1/tracesまで含める必要があります。BifrostはこのパスをURL補完しません） - Bifrostはdockerイメージ
maximhq/bifrost:v1.4.24を使用（検証日: 2026年5月1日）。Bifrostは更新が速く、v1.5系（2026年5月6日リリース）ではTelemetryやTransport周りの変更が入っているため、最新バージョンではLangfuse上の見え方が変わる可能性があります - LLMプロバイダー：Vertex AI（gemini-2.5-flash）
Bifrostとは#
Bifrost
はGo製のAI専用OSSゲートウェイです。Goバイナリをnpmパッケージでラップしているため、npx @maximhq/bifrost で即起動できます（Docker起動も可能です）。
- ゼロコンフィグ起動：設定ファイルを置くだけで動きます。データストア不要です
- OpenAI互換API：OpenAI SDK は
base_url、google-genai SDK はhttp_options={"base_url": ...}のように接続先を変えるだけで動作します - 軽量・低コストで試せる：OSSとして無料で利用でき、基本的なAI Gateway機能はすぐに使えます。なお、SSO・詳細なガバナンス・ガードレールなどはEnterprise扱いの機能もあるため、本番利用時は必要機能のライセンス条件を確認してください
Langfuseのトレース品質比較#
前提を確認したところで、本題の比較に入ります。3製品でLangfuseのトレースUIの見え方がどう異なるかを見ていきます。本記事では、以下の観点でトレース品質を比較しています。
| 評価軸 | 見るべきポイント |
|---|---|
| 入出力の見つけやすさ | prompt / completion がどのスパンにあるか |
| コスト・トークン | token usage / cost が自動で記録されるか |
| レイテンシ | リクエスト全体のレイテンシが見えるか |
| フォールバック・リトライ | tool call / fallback / retry が追えるか |
| ノイズ | Gateway内部スパンが多すぎないか |
Bifrost#
prehook・posthook（リクエスト処理の前後に実行されるフック処理）のスパン（処理ステップの記録単位）が多数生成されるため、ツリービューが深い階段状になります。LLMの入出力がどのスパンにあるかを追うのに手間がかかります。
なお、この問題は既知のissue として上がっており、対応PR（#2279）も存在しますが、2026年5月時点では未マージです。将来的に改善されている可能性があるため、最新状況はissueを確認してください。
なお、BifrostはMCPゲートウェイ機能も持っており、MCPツールを使うとツール実行1回ごとにさらにスパンが追加されます。
LiteLLM#
litellm-acompletion という単一スパンにInput・Output・コスト・レイテンシがまとまっており、見通しが良いです。LiteLLM独自のLangfuse連携ライブラリを使ってLangfuseへ直接データを送る「ネイティブサポート」のため、OTel（OpenTelemetry：分散トレーシングの標準規格）を経由せずに設定できます。OTel経由での連携も可能で、LiteLLM公式ドキュメントでは Langfuse v3 向けに OTel 連携が推奨されています。
Kong#
KongはLangfuse docsで紹介されているKong向けトレーシングプラグインを使用するため設定がシンプルで、LiteLLMと同様にフラットで見やすいトレースが生成されます。
Bifrost セットアップのはまりポイント#
ここからはBifrostを実際にVertex AI + Langfuse OTel構成で動かした際のはまりポイントです。LiteLLM・Kongと比較検討してBifrostを選んだ方や、これから試す方の参考になれば幸いです。
モデル名は明示列挙が必要#
config.json の models に "*" を指定すると、ADC（Application Default Credentials：GCPの認証情報）の authorized_user タイプでモデル一覧取得が失敗し、キーが無効化されます。使用するモデル名を明示的に列挙してください。
"models": ["gemini-2.5-flash", "gemini-2.5-flash-001"]OTelコレクターURLはパスまで含める#
OTelのエンドポイントURLをBifrostは自動補完しません。セルフホストLangfuseの場合はパスまで明記が必要です。
https://your-langfuse-host/api/public/otel/v1/tracesVirtual Keyが必須#
/genai エンドポイントはVirtual Key（Bifrostが発行する仮想APIキー）がないとルーティングされません。Virtual Keyは config.json の virtual_keys セクションで定義します。
"virtual_keys": [
{
"name": "my-key",
"value": "sk-bf-vertex",
"allowed_models": ["vertex/gemini-2.5-flash"]
}
]定義したKeyをリクエストヘッダーに x-bf-vk として付けて送信します。
client = genai.Client(
api_key="dummy",
http_options={"base_url": "http://localhost:8080/genai", "headers": {"x-bf-vk": "sk-bf-vertex"}},
)※
/genaiはBifrost専用エンドポイントです。OpenAI互換の/v1エンドポイントとは異なる点に注意してください。
設定変更後はDBを削除して再起動#
BifrostはSQLiteに設定をキャッシュします。config.json を変更しても反映されない場合は config.db と logs.db を削除してから再起動してください。Docker構成の場合はボリュームマウントしているパスに注意してください。
3製品まとめ比較#
ここまでの比較とセットアップの知見をもとに、3製品を整理します。
| 比較軸 | Bifrost | LiteLLM | Kong |
|---|---|---|---|
| 起動の手軽さ | npxまたはdocker runで数秒 | Docker/Cloud Run | データストア込みの構成が必要 |
| Langfuse連携方法 | OTel（要パス指定） | ネイティブ / OTel（v3 では OTel 推奨） | プラグイン |
| トレース品質 | スパンが多くノイジー | フラットで見やすい | フラットで見やすい |
| フォールバック | あり（リクエスト時に fallbacks 配列で指定）→ 次回
でLangfuseトレースを詳しく解説 | あり | あり |
| ガードレール（入出力の自動検査・制御） | Enterprise版のみ | Enterprise版のみ | 正規表現ベースの AI Prompt Guard は OSS 版で利用可。Semantic Prompt Guard（ベクトル検索）は AI License 必要 |
| 有償サポート | 不明 | 要問い合わせ | あり（価格非公開） |
Bifrostのパフォーマンスについて#
BifrostはGo製のため、公式README では5,000+ RPS・11µsオーバーヘッドを報告しています。ただし、LLM推論自体に数秒かかるため、ゲートウェイのオーバーヘッドが体感レベルで差になるケースは少ないです。スループットよりも、運用コストや連携のしやすさで選ぶのが現実的だと思います。
どれを選ぶか#
Langfuse連携のしやすさを重視するなら：
| こんな場合 | おすすめ |
|---|---|
| Langfuse連携を最小設定でやりたい | LiteLLM（ネイティブ連携、トレースが見やすい） |
| 開発からスモールな本番まで一気通貫で使いたい | LiteLLM |
| すでにKongを運用している・エンタープライズ実績を重視 | Kong |
まず手元で動かして感触を掴みたいなら：
Bifrostは現時点でLangfuse連携のトレース品質では他製品に劣りますが、npx一発で起動できる手軽さは際立っています。本番導入前の評価・プロトタイピング用途では有力な選択肢です。
| こんな場合 | おすすめ |
|---|---|
| 素早く試してBifrostを評価したい | Bifrost（npxで即起動、設定最小） |
まとめ#
Langfuse連携のしやすさという観点では、現時点ではLiteLLMが最も使いやすいという結論になりました。ネイティブサポートによる設定のシンプルさと、フラットなトレース表示が決め手です。
一方でBifrostは手軽に試せることが強みです。トレース品質の問題はissue対応中のため今後改善される可能性があり、引き続き注目したいツールです。
各製品の詳細なセットアップ手順は既存の記事をご参照ください：LiteLLM on Google Cloud / Kong AI Gateway + Langfuse