Langtraceとは？OpenTelemetry準拠のLLM監視の機能・導入手順と採用判断

Langtraceは、Scale3 Labsが開発するオープンソースのLLMオブザーバビリティツールです。SDKを2行書き足すだけで、OpenAIやAnthropicへのAPI呼び出し、LangChainなどのフレームワーク、ベクトルDBへの問い合わせをトレースとして記録できます。ただし2026年8月現在、公式サイトのlangtrace.aiは404を返し、SDKの最終リリースは2025年7月で止まっています。この記事では公式ドキュメントとGitHub・PyPI・npmの実データだけを根拠に、Langtraceで何ができるのか、いま導入して問題ないのか、そして「Langtraceのサーバーを使わずSDKだけを使う」という現実的な選択肢までを整理します。

まとめ

Langtraceは、LLMアプリの入出力・トークン数・レイテンシ・コストをOpenTelemetry準拠のトレースとして収集するツールです。アプリ本体はAGPL-3.0、SDKはApache-2.0で公開されています。マネージド版のLangtrace Cloudは公式ドキュメントのFAQで「現時点では完全に無料」と記載されており、有料プランは公開されていません。

一方、採用判断に直結する事実が2つあります。ひとつは開発ペースの鈍化です。アプリ本体の最終リリースは2025年4月17日の4.0.11、PythonとTypeScriptの両SDKは2025年7月24日のリリースを最後に更新が止まっています。もうひとつは公式サイトの消失で、langtrace.aiは全パスが404「Site Not Found」を返します。アプリ本体のapp.langtrace.aiとdocs.langtrace.aiは稼働しているため、サービスが停止したわけではありませんが、GitHubのREADMEが案内する登録先リンクは現在つながりません。

結論として、新規プロジェクトでLangtrace Cloudを長期の監視基盤に据えるのは勧めません。代わりに有力なのが、Langtrace CloudにアカウントをつくらずSDKだけをOpenTelemetryの計装ライブラリとして使い、トレースの送り先をDatadogやGrafanaなど既存のAPMにする使い方です。公式ドキュメントはこの構成でLangtrace APIキーが不要だと明記しており、ベンダーロックインを負わずにLLM固有の計装だけを得られます。以下、機能・導入手順・セルフホスト要件・他ツールとの違いを順に見ていきます。

Langtraceの立ち位置と3つの利用形態

収集するデータとOpenTelemetryとの関係

Langtraceが扱うのは、LLMアプリ特有の「1回の推論で何が起きたか」という記録です。プロンプトと応答の本文、入力・出力トークン数、モデル名、レイテンシ、推定コスト、エラーの有無をスパンとして記録し、複数の呼び出しをまたいだ処理を1本のトレースとしてつなぎます。RAGであれば、ベクトルDBへの検索とその後のLLM呼び出しが同じトレースに並ぶため、遅延の原因が検索側か生成側かを切り分けられます。

特徴は、この記録形式が独自仕様ではなくOpenTelemetryのトレースに従っている点です。スパン属性の定義はlangtrace-trace-attributesリポジトリで公開されています。OpenTelemetryはCNCF傘下の計装標準で、対応するバックエンドであれば送り先を差し替えられます。トレースやメトリクスといった監視データの基礎についてはオブザーバビリティ（可観測性）の3本柱と監視との違いを、OpenTelemetry計装そのものの考え方はAPM（アプリケーション性能監視）の仕組みと導入判断で扱っています。

対応言語はPythonとTypeScriptの2つだけです。公式ドキュメントのFAQでも「現在サポートするのはPythonとTypeScript」と記載されており、GoやJavaのアプリからは直接利用できません。

Cloud・セルフホスト・OTelエクスポートの使い分け

Langtraceの使い方は3通りあり、どれを選ぶかで必要な準備がまったく変わります。

3つ目のOTelエクスポートは、Langtraceのサーバーを一切使わずSDKの計装機能だけを借りる構成です。公式ドキュメントは「Datadog、Instana、New Relicなど他のオブザーバビリティツールへ直接トレースを送る場合、Langtrace APIキーは不要」と注記しています。この選択肢が採用判断を大きく左右するため、後の章で詳しく扱います。

SDKの導入手順とAPIキーの発行先

READMEが案内するlangtrace.aiと現行の登録先app.langtrace.aiの差異

Langtrace Cloudを使う場合、まずアカウント登録とプロジェクト作成、APIキーの発行が必要です。ここでつまずきやすいのが登録先URLです。GitHubのREADMEは「langtrace.aiから登録してください」と案内していますが、2026年8月2日時点でlangtrace.aiとwww.langtrace.aiは全パスがHTTP 404を返し、Framerの「Site Not Found」画面が表示されます。

現行の正しい登録先は、公式ドキュメントのQuickstartが指しているapp.langtrace.ai/signupです。こちらはHTTP 200で応答し、登録画面まで到達できます。READMEのリンクだけを頼りにすると「サービスが終わった」と誤解しかねないため、READMEではなくドキュメント側の手順に従ってください。

インストールと初期化コード

SDKのインストールはパッケージマネージャ1行です。PythonはPyPI、TypeScriptはnpmから取得します。

# Python
pip install langtrace-python-sdk

# TypeScript
npm i @langtrase/typescript-sdk

初期化で気をつけたいのがimportの順序です。公式ドキュメントは、LangtraceのimportをLLMモジュールのimportより前に置くよう明記しています。Langtraceは各ライブラリのメソッドを差し替えて計装する仕組みのため、順序を守らないと計装が当たらないケースがあります。公式の記載どおりに並べてください。

# langtrace の import は LLM ライブラリより前に置く
from langtrace_python_sdk import langtrace

langtrace.init(api_key = "<LANGTRACE_API_KEY>")

from openai import OpenAI

client = OpenAI()
response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "Hello!"}],
)

Pythonパッケージのlangtrace-python-sdkは最新版が3.8.21（2025年7月24日公開）で、動作要件はPython 3.9以上です。TypeScript SDKの@langtrase/typescript-sdkは6.3.7（同日公開）、ライセンスはApache-2.0です。パッケージ名がlangtraceではなくlangtraseである点は、npmでの取り違えが起きやすいので注意してください。

ユーザーIDやセッションIDをトレースに付けたい場合は、Python側のinject_additional_attributes、TypeScript側のwithAdditionalAttributesで属性を追加できます。関連する処理をひとまとめにするには、Pythonのwith_langtrace_root_spanデコレータを使います。

SDK別に割れるLLM・フレームワーク・ベクトルDB対応

Langtraceは対象ライブラリを自動で検出して計装します。実務上の分かれ目は、TypeScript SDKとPython SDKで対応ベンダーが揃っていない点です。

表に載せきれない分では、LLMのPerplexity・Mistral AI・KubeAIが両SDK対応、フレームワークのDSPy・Mem0・Ollamaが Python SDKのみの対応です。ベクトルDBはWeaviateとPGVectorも両SDKに対応しており、主要5製品が揃っているためRAG構成の計装では穴が少なくなっています。このほかMilvus、MongoDB Vector Search、Neo4jの個別ガイドも公開されています。

注目したいのは、フレームワーク側の対応がPythonに偏っていることです。LangChainやCrewAIをTypeScriptで使っている場合、自動計装は効きません。Vercel AI SDKは逆にTypeScript専用の対応です。フレームワークを軸に採用を検討しているなら、自分の言語で対応しているかを公式の対応表で先に確認してください。Webフレームワーク側ではDjango、FastAPI、Flask、Next.jsの導入手順が用意されています。

セルフホストの構成要件と推奨スペック

必要な3コンポーネントと導入方式

データを外部に出せない場合はセルフホストを選びます。ただし単一コンテナで完結するツールではありません。公式ドキュメントによれば、Next.jsアプリ本体、ユーザーやプロジェクトのメタデータを持つPostgres、トレース本体を格納するClickHouseの3サービスを動かす必要があります。ClickHouseの運用経験がないチームでは、ここが最初の障壁になります。

導入方式はDockerの単体起動、必要なDBをまとめて立ち上げるDocker Compose、Helmチャート経由のKubernetes、Azure App Service、Railwayのワンクリックデプロイが用意されています。加えて2025年11月にはNorthflankのデプロイボタンがリポジトリへ追加されましたが、ドキュメント側の手順は未整備です。認証は管理者パスワード、Google OAuth、Azure AD OAuthから選べます。

推奨ハードウェア構成とトレース保持期間の設定

公式ドキュメントは自社クラウドで動かす際の推奨構成を数値で示しています。

トレースは放置すると増え続けるため、保持期間の設定が実質的に必須です。この自動削除機能はセルフホスト限定で、Langtrace Cloudでは使えません。設定はプロジェクト設定の「General」タブで保持日数を指定したうえで、ProjectRetentionPolicyテーブルを作るPrismaマイグレーションを適用し、削除用エンドポイントを定期実行する流れになります。

# 保持ポリシー用テーブルのマイグレーション
npx prisma migrate deploy

# cron から定期的に叩く削除エンドポイント
curl -X GET http://localhost:3000/api/cron/cleanup-traces \
  -H "cron-api-key: YOUR_CRON_API_KEY"

エンドポイントは環境変数CRON_API_KEYで保護します。cronを設定しない限り古いトレースは消えないため、ストレージ設計とあわせて最初に組み込んでください。保存量そのものを抑えたい場合は、収集段階で間引く方法もあります。判断材料はヘッドベースとテールベースのトレースサンプリングの使い分けにまとめています。

Langtrace Cloudを使わないSDK単体のOTel計装構成

APIキー不要で既存APMへ送る設定

ここが2026年時点でLangtraceを検討する最大の理由です。Langtrace SDKは、収集したトレースをLangtraceのサーバーではなく任意のOpenTelemetry対応バックエンドへ直接送れます。公式ドキュメントは、この構成ではLangtrace APIキーが不要で、送信先ツールのキーだけあればよいと明記しています。

送信先として個別のガイドが用意されているのはDatadog、Elastic APM、Grafana Cloud、Honeycomb、SigNoz、New Relic、IBM Instana、Dash0です。設定はOpenTelemetryの標準的な環境変数で完結し、アプリのコードはlangtrace.initを呼ぶだけで変わりません。

# 送信先を SigNoz にする例（標準の OTLP 環境変数のみ）
OTEL_EXPORTER_OTLP_ENDPOINT="https://ingest.us.signoz.cloud:443"
OTEL_EXPORTER_OTLP_HEADERS="signoz-access-token=YOUR_TOKEN"
OTEL_EXPORTER_OTLP_PROTOCOL="grpc"
OTEL_RESOURCE_ATTRIBUTES=service.name="rag chatbot"

なお公式ドキュメントの設定表は、送信先を指定するapi_hostの既定値をhttps://langtrace.ai/、つまり現在404を返すドメインと記載したままです。実際のPython SDKのソースを見ると既定値はhttps://app.langtrace.aiで、実測でもapp側のエンドポイントは応答し、langtrace.ai側は404を返します。ドキュメントの表記が古いだけで、Cloudへの送信そのものは動く状態です。

既存APMへ集約すべき条件と向かない条件

この構成の利点は、Langtraceプロジェクトの将来リスクを引き受けずに済むことです。SDKはApache-2.0で、LLM・フレームワーク・ベクトルDB向けの計装コードがすでに書かれています。仮にLangtraceの開発が完全に止まっても、蓄積したトレースは自社のAPMに残り、計装部分だけを別のOpenTelemetryライブラリに差し替えれば移行できます。Langtrace Cloudにデータを預ける構成では、この退避経路がありません。

すでにDatadogやGrafanaを運用しているチームであれば、迷わずこちらを選ぶべきです。LLMのトレースだけを別ダッシュボードに分離しても、ユーザーの体感遅延はAPIゲートウェイやDBを含めた全体像でしか説明できません。既存APMに寄せれば、LLM呼び出しをアプリ全体のトレースと同じ画面で追えます。

逆にこの構成が向かないのは、プロンプトのバージョン管理や評価、アノテーションといったLangtrace固有の機能を使いたい場合です。これらはトレース閲覧ではなくLangtraceのアプリ側が持つ機能なので、CloudかセルフホストのUIが必要になります。LLMアプリの品質評価そのものを設計したい場合は、AIエージェント評価の指標と実装の進め方で扱う考え方のほうが土台になります。

LangfuseやLangSmithとの違いと選び分け

LLMオブザーバビリティの選択肢としてよく比較されるのがLangfuseとLangSmithです。3つの性格は明確に分かれます。

Langtraceの独自性はOpenTelemetry準拠を前面に出している点で、これが前章のエクスポート構成につながっています。一方、開発の継続性という一点でLangtraceは他の2つに劣ります。プロンプト管理や評価まで含めてOSSで長く使いたいならLangfuseが現実的な第一候補です。読み方や機能差、LangSmithとの比較はLangfuseの機能・使い方とLangSmithとの違いで詳しく扱っています。LangChainを開発の中心に据えているならLangSmithが最も摩擦が少なくなります。

実験管理やモデルのデプロイまで含めた運用基盤を検討している段階なら、監視ツール単体ではなくMLOpsツールの主要スタックと選定基準から入るほうが手戻りが少なくなります。

2026年時点の開発状況と採用判断

GitHub・PyPI・npmの更新履歴実測

採用可否を判断するには、公式サイトの説明ではなく更新履歴を見るのが確実です。2026年8月2日時点でGitHub・PyPI・npmから取得した実データは次のとおりです。

アプリ本体のmainブランチは2025年11月17日に更新されていますが、その内容はNorthflank向けデプロイボタンの追加で、機能変更を伴う直前のコミットは2025年5月4日まで遡ります。両SDKも2025年7月24日を最後に新しいリリースがありません。リポジトリはアーカイブされておらず、2026年8月2日時点でスターは1,224件です。つまり公開停止ではないものの、1年以上まとまった更新がない状態です。

これに加えて、マーケティングサイトのlangtrace.aiが404を返しています。app.langtrace.aiとdocs.langtrace.aiは応答するため、アプリとドキュメントは生きています。事業としての告知面だけが畳まれた形で、これを「一時的な不調」と読むのは無理があります。

新規採用の可否と条件

以上を踏まえた判断は次のとおりです。Langtrace Cloudを本番の監視基盤として新規採用することは勧めません。LLMのAPI仕様は頻繁に変わるため、計装ライブラリが1年更新されないと新しいモデルやパラメータのトレースが欠落し始めます。監視ツールが取りこぼしていることに気づかないまま運用するほうが、監視がない状態より危険です。

一方、次の条件に当てはまるなら選ぶ価値があります。既存のOpenTelemetry基盤があり、LLM部分の計装だけを短期間で足したい場合です。この場合はCloudを使わずSDKのみを導入し、送信先を自社のAPMに向けます。Apache-2.0で配布されている計装コードを利用するだけなので、開発が止まっても影響を受けるのは新しいベンダーへの追随だけで、既存の計装は動き続けます。学習や検証で手元に立てて試す用途も問題ありません。

逆に、プロンプト管理や評価機能を含めてLangtraceに依存する設計は避けてください。移行時にトレースの蓄積とワークフローの両方を作り直すことになります。

よくある質問

Langtraceは無料で使えますか？

公式ドキュメントのFAQに「現時点では完全に無料」と記載されており、有料プランは公開されていません。langtrace.ai/pricingは404を返します。ドキュメントには将来変更される可能性がある旨も併記されています。

公式サイトのlangtrace.aiが開けないのですが、サービスは終了したのですか？

2026年8月2日時点でlangtrace.aiは全パスが404「Site Not Found」を返しますが、アプリのapp.langtrace.aiとドキュメントのdocs.langtrace.aiは正常に応答します。終了ではなく、マーケティングサイトのみが停止した状態です。登録はapp.langtrace.ai/signupから行えます。

LangtraceとLangfuseはどちらを選ぶべきですか？

OSSで長期運用するならLangfuseです。Langtraceは2025年7月以降SDKのリリースが止まっており、継続性で差があります。Langtraceを選ぶ合理性があるのは、SDKをOpenTelemetry計装として使い既存APMへ送る構成に限られます。

Python以外の言語でも使えますか？

公式ドキュメントのFAQによると対応言語はPythonとTypeScriptのみです。GoやJava、Rubyのアプリケーションから直接利用することはできません。

セルフホストするには何を用意すればよいですか？

Next.jsアプリ本体、Postgres、ClickHouseの3サービスが必要です。推奨スペックはClickHouseがメモリ8GBでレプリカ2、Postgresがメモリ16GB・4vCPU・ストレージ512GB、クライアントがメモリ3GB・1vCPUです。Docker Compose、Kubernetes、Azure App Service、Railwayの手順が公開されています。

関連記事

• Langfuseとは？読み方・機能・使い方とLangSmithとの違いを解説【2026年最新】
• オブザーバビリティ（可観測性）とは？監視との違い・3本柱・主要ツールを解説
• APM（アプリケーション性能監視）とは｜仕組み・3種の監視データ・OpenTelemetry計装と導入判断を実装目線で解説
• AIエージェント評価とは？軌跡・ツール呼び出し・タスク達成を測る指標と実装の進め方【2026年版】
• LangChainとは？LLMアプリ開発フレームワークの仕組み・できること・採用判断を解説