--- title: "OpenLITとは？OpenTelemetryネイティブのLLM可観測性を自前で動かす手順【2026年9月版】" url: "https://www.issoh.co.jp/tech/details/5661/" published: 2025-03-05 updated: 2026-09-27 categories: ["監視・オブザーバビリティ"] publisher: "株式会社一創" --- # OpenLITとは？OpenTelemetryネイティブのLLM可観測性を自前で動かす手順【2026年9月版】 OpenLITは、LLMの呼び出しからAIエージェントのツール実行、さらにClaude Code・Cursor・Codexといったコーディングエージェントのセッションまでを、OpenTelemetryの形式のまま記録するオープンソースの可観測性プラットフォームです。本記事は2026年9月23日時点のリポジトリ（openlit/openlit）のタグ付きソースとGitHub API、PyPIを一次情報として、起動手順・SDKの引数・実際に取れるデータ・日本語環境でつまずく箇所を整理します。 ## まとめ：OpenLITの要点 - ライセンスはApache-2.0。ホスティング前提ではなく、自分のインフラで動かす構成が既定です。 - プラットフォーム本体の最新版は openlit-2.1.0（2026年9月10日公開）。Python SDKは1.45.0、TypeScript SDKは1.15.0です。 - 起動は `docker compose up -d` の1コマンド。ClickHouseとOpenLIT本体の2コンテナが立ち、UIが3000番、OTLP受信が4317（gRPC）と4318（HTTP）です。 - アプリ側の計装は `import openlit` と `openlit.init()` の2行。ただし既定で会話本文を記録するため、本番投入前に `capture_message_content` の扱いを決める必要があります。 - 2.1.0ではループに陥ったエージェントの検出と、NIST AI RMF・EU AI Act・OWASP ASIのポリシーパックによるトレースガバナンスが入りました。 - PII検出ガードの正規表現は24本ですが、日本の電話番号やマイナンバー向けのパターンは含まれません。 ## OpenLITの現在地：LLM監視からエージェント計装へ かつてのOpenLITは、LLM APIの呼び出しコストとレイテンシを可視化するツールとして知られていました。2026年9月時点のリポジトリ説明文は `Open-source observability & evaluation platform for AI agents and coding agents` で、対象はエージェントのツール呼び出し、サブエージェント、検索、メモリ、コーディングエージェントのセッションへ広がっています。「LLMのコスト集計ツール」として評価すると、ツール呼び出しやサブエージェント、コーディングセッションの追跡機能を見落とします。 ### バージョンとライセンスの確認 GitHub APIで取得した2026年9月23日時点の実測値は次のとおりです。ライセンスはApache-2.0、スター数は2,786、リポジトリはアーカイブされていません。リリースタグは[リリース一覧](https://github.com/openlit/openlit/releases)のとおり用途ごとに分かれており、プラットフォーム本体が `openlit-2.1.0`（2026年9月10日）、その前が `openlit-2.0.0`（2026年8月28日）、Python SDKが `py-1.45.0`、TypeScript SDKが `ts-1.15.0`（いずれも2026年8月3日）、GPUコレクタが `otel-gpu-collector-0.0.8`（2026年8月26日）です。PyPI上の openlit も1.45.0で一致します。 タグが用途ごとに分かれている以上、ダッシュボードが2.1.0でSDKが1.45.0という組み合わせは正常です。両者の番号を揃えようとする必要はありません。 ### OpenTelemetryによる既存監視基盤との接続 OpenLITは独自フォーマットを定義せず、OpenTelemetryのトレースとメトリクスをそのまま出力します。アプリのテレメトリをOpenTelemetry Collectorへ送り、そこからOpenLITと既存のバックエンド（DatadogやGrafanaなど）へ同時に流せるため、基盤を入れ替えずに評価できます。属性にはOpenTelemetryのGenAIセマンティック規約に基づくものに加え、プロバイダ固有属性やOpenLIT独自拡張も含まれるため、スパンの中身を設計する段階では[OpenTelemetryのGenAIセマンティック規約｜gen\_ai属性とメトリクスの体系・移行の判断](/tech/details/17007/)と合わせて読むと、どの属性がどこから来ているのかを追えます。 ## セルフホストの構成と起動手順 OpenLITはリポジトリに同梱された docker compose で起動します。手順はリポジトリを取得して立ち上げるだけです。なお次の例は既定ブランチと `latest` イメージを使うため、版を固定した再現手順ではありません。2.1.0で揃えるならGitタグとイメージのタグを両方指定してください。 ``` git clone https://github.com/openlit/openlit.git cd openlit docker compose up -d ``` 起動後、ブラウザで `http://127.0.0.1:3000` を開くとダッシュボードに入れます。 ### 立ち上がるコンテナとポート 公式ドキュメントは構成要素としてOpenLIT本体・ClickHouse・OpenTelemetry Collectorの3つを挙げますが、タグ openlit-2.1.0 の docker-compose.yml が定義するサービスは2つだけです。Collectorは独立したコンテナではなく、本体イメージに同梱されています。 - `clickhouse`：イメージは `clickhouse/clickhouse-server:24.4.1`。トレースの保存先で、8123番（HTTP）と9000番（ネイティブ）を公開します。接続情報は `OPENLIT_DB_NAME`・`OPENLIT_DB_USER`・`OPENLIT_DB_PASSWORD` で上書きします。既定のパスワードは `OPENLIT` という文字列なので、社内ネットワークに出す前に必ず変更してください。 - `openlit`：イメージは `ghcr.io/openlit/openlit:latest`。UIの3000番に加えてOTLPの4317番（gRPC）と4318番（HTTP）を受け持ち、Collectorの設定ファイルを `/etc/otel/otel-collector-config.yaml` にマウントします。 永続化は `clickhouse-data` と `openlit-data` の2ボリュームで、後者にはSQLiteのアプリケーションDB（`/app/client/data/data.db`）が入ります。バックアップ対象を決めるときはこの2つを見てください。 ### 既存Collectorからの転送とKubernetesへの導入 既存のCollectorを経由させる場合は、そのexporterからOpenLITの4318番へ転送します。OpenLIT側で受け口を増やす設定は要りません。Kubernetesへ載せる場合はHelmチャートが公開されています。エアギャップ環境では、2.1.0でPrismaのエンジンをクライアントイメージへ事前に焼き込む修正が入り、起動時のダウンロード失敗で立ち上がらない問題が解消しています。 ``` helm repo add openlit https://openlit.github.io/helm/ helm repo update helm install openlit openlit/openlit ``` ## SDKの組み込みと、本番前に決める引数 Pythonでの導入は、パッケージの追加と2行の初期化だけです。 ``` pip install openlit==1.45.0 ``` ``` import openlit openlit.init(otlp_endpoint="http://127.0.0.1:4318") ``` アプリのコードを触らずに切り替えたい場合は、環境変数でも指定できます。 ``` export OTEL_EXPORTER_OTLP_ENDPOINT="http://127.0.0.1:4318" ``` この初期化だけで、対応するLLMプロバイダ・フレームワーク・ベクトルデータベースが自動計装されます。TypeScriptは `npm install openlit`、ほかにGo向けSDKもリポジトリに含まれます。 ### openlit.init()で最初に見直す引数 py-1.45.0 の `init()` は20個以上の引数を取ります。本番投入で判断が要るものは次の範囲です。 | 引数 | 既定値 | 用途 | | ------------------------- | --------- | -------------- | | capture\_message\_content | True | プロンプトと応答の本文を記録 | | max\_content\_length | None（無制限） | 記録する本文の最大文字数 | | capture\_db\_parameters | False | DBクエリのパラメータを記録 | | disabled\_instrumentors | None | 個別の自動計装を止める | | pricing\_json | None | 独自価格表のパスまたはURL | | collect\_gpu\_stats | False | GPUメトリクスの収集 | | guards | None | 適用するガードのリスト | | disable\_batch | False | バッチ送信を無効化 | `disabled_instrumentors` には別名解決があり、`aiohttp` と書くと `aiohttp-client` に解釈されます。ただし `requests` を止めても内部で使われる `urllib3` は止まらないため、HTTPクライアント由来のスパンを消したいときは両方を指定する必要があります。ソースのdocstringに明記された挙動です。 ``` openlit.init( application_name="support-bot", environment="production", capture_message_content=False, max_content_length=2000, disabled_instrumentors=["requests", "urllib3"], ) ``` ### 会話本文の記録範囲と保存方針 送信先をOpenLITへ設定し、本文記録の既定値を変更せずに対応するLLM呼び出しを実行すると、プロンプトと応答の本文が切り詰めなしでスパン属性としてClickHouseへ入ります。社内の問い合わせ内容や顧客データをLLMへ渡すアプリでは、トレースストアが機微情報の複製になるということです。障害調査で本文が必要なら記録した上で保存期間とアクセス権で守る、必要でないなら `capture_message_content=False` にして会話本文の記録を止め、トークン数・コスト・モデル名・処理時間などのメタデータを残す。既定値のまま曖昧に運用する選択肢は取るべきではありません。記録範囲の考え方そのものは[エージェントトレーシングとは？スパン木の設計・gen\_ai属性・記録範囲を実装目線で解説【2026年版】](/tech/details/16332/)で整理しています。 ## Claude Code・Cursor・Codexのセッション計装 2026年のOpenLITで最も特徴的なのがコーディングエージェントの計装です。アプリ用SDKとは別に、CLIを入れてエージェント側へフックを仕込みます。 ``` curl -fsSL https://raw.githubusercontent.com/openlit/openlit/main/cli/scripts/install.sh | sh openlit configure --endpoint http://127.0.0.1:4318 openlit coding install --vendor=all openlit doctor ``` Windowsでは `install.ps1` をPowerShellで実行します。`--vendor` は `all` のほか `cursor`・`claude-code`・`codex` を個別に指定でき、`openlit doctor` で導入状態を点検できます。 ### エージェント別のプラグイン登録とフック設定 3種類は同じコマンドで入りますが、内部の仕組みは別物です。Claude Codeでは `claude` CLI経由でプラグインを登録し、登録に失敗した場合はフック自体は書き込まれた上で、Claude Code内で `/plugin marketplace add` と `/plugin install openlit-cc@openlit` を実行するよう案内が出ます。Codexは `codex plugin marketplace add` と `codex plugin add openlit@openlit` を実行し、さらにCodex内の `/hooks` で各フックを明示的に信頼する操作が要ります。Cursorだけはプラグインツリーを置く方式が使えず、フックをマージする独自処理になっています。 この差は失敗時の切り分けに直結します。`openlit coding install` が成功してもトレースが出ないときは、Codexならフックの信頼操作、Claude Codeならプラグイン登録を先に疑うのが最短です。 ### セッションから取れる情報 記録対象は、ユーザーのプロンプト、LLM呼び出し、ツール呼び出し（ファイル読み取り・ファイル編集・シェルコマンド・検索）、サブエージェントの活動、トークン使用量、コスト、コードへの影響範囲です。ダッシュボードのCoding Agentsでセッション単位に追えます。 2.1.0ではこの上にループ検出が乗りました。同じツール呼び出しを繰り返して止まらなくなったエージェントをLoopフィルタで抽出し、その間に消費したトークンとコストを無駄分として表示します。エージェントの費用が想定より膨らんだときに、モデル単価より先に見るべき画面です。 ## コスト追跡・Evaluations・Prompt Hubの処理先と設定 コストはモデル・プロバイダ・ユーザー・セッション・エージェント・環境の各軸で集計されます。通常のテキスト生成コストは、入力・出力トークン数を単価の基準トークン数で割り、それぞれの単価を掛けて合算します。キャッシュ単価がある場合は別計算です。なお単位が2か所で異なります。Python SDKの価格表は1,000トークン単位、ダッシュボードのManage Modelsは100万トークン当たりの単価として扱うため、独自単価を入れるときは取り違えに注意してください。ファインチューニング済みモデルや独自契約の単価を使う場合は、価格表を差し替えます。 ``` openlit.init( otlp_endpoint="http://127.0.0.1:4318", pricing_json="./pricing.json", ) ``` `pricing_json` はファイルパスとURLのどちらでも受け付けます。2.1.0ではMiniMaxのM3とM2.7が組み込みプロバイダとして追加され、コンテキスト情報・価格・キャッシュ率・ストリーミング対応の情報が同梱されました。 ### Evaluationsのサーバー実行と認証設定 組み込みの評価種別は11種類です。ハルシネーション・バイアス・毒性・安全性・指示追従・網羅性・簡潔さ・機微性・関連性・一貫性・忠実性が用意され、いずれもLLM-as-a-Judge方式で実行されます。誤解しやすいのは、評価がSDK内で完結しない点です。py-1.45.0 の評価APIは `OPENLIT_API_KEY` と `OPENLIT_URL` を解決できないと `ValueError` を送出します。OpenLITサーバーの評価エンジンを呼ぶ構造であり、ダッシュボードで設定したルールとコンテキストがそのまま使われます。 ``` import openlit result = openlit.eval( prompt="請求書の締め日を教えてください", response="毎月末日です", eval_types=["hallucination"], ) ``` 複数件をまとめて処理する `openlit.eval_batch()`、利用可能な評価種別を取得する `openlit.get_eval_types()` も同じ経路です。評価指標そのものの選び方は[LLM評価とは？指標・データセット設計・評価ツールの選び方を実装視点で解説【2026年版】](/tech/details/16319/)を参照してください。 ### Prompt Hubの公開APIとREADMEの差異 プロンプトのバージョン管理にはPrompt Hubを使いますが、ここに注意点があります。リポジトリのREADMEには `openlit.prompts.get("customer-support")` という例が載っていますが、py-1.45.0 にも main ブランチのSDKにも `prompts` というオブジェクトは存在しません。実際の公開APIは、[py-1.45.0 の \_\_init\_\_.py](https://github.com/openlit/openlit/blob/py-1.45.0/sdk/python/src/openlit/%5F%5Finit%5F%5F.py) が定義する `get_prompt()` です。 ``` prompt = openlit.get_prompt(name="customer-support") ``` この関数も `OPENLIT_URL` と `OPENLIT_API_KEY` を必要とし、サーバーの `/api/prompt/get-compiled` を呼びます。READMEを写経してAttributeErrorで止まった場合は、READMEの例とpy-1.45.0の公開APIが一致していないためです。 ## PIIガードの既定パターンと日本固有の個人情報への対応範囲 OpenLITにはガードレール機能があり、初期化時にガードのリストを渡す形で有効化します。 ``` import openlit openlit.init( otlp_endpoint="http://127.0.0.1:4318", guards=[openlit.PII(action="redact")], ) ``` py-1.45.0 が公開するガードクラスは `PII`・`PromptInjection`・`SensitiveTopic`・`TopicRestriction`・`Moderation`・`Schema`・`Custom` の7種類です。動作は `redact`（`[REDACTED:ラベル]` へ置換）・`deny`（拒否）・`warn`（イベント送出のみ）から選べます。ただし自動ガードが差し込まれるのは実装に列挙されたテキスト入出力のメソッドだけで、埋め込みや画像・音声のAPIは対象外です。応答側の検査はストリーミング応答では省略され、リクエスト側の検査だけが常に走ります。`guard_fail_open` の既定はTrueで、ガード自体が失敗したときはリクエストを通します。止める方を優先するなら明示的にFalseへ倒してください。 ここでもドキュメントと実装にずれがあります。公式のガードレール解説は `All` を含む5種類を挙げ、`openlit.guard.PromptInjection(...).detect(text=...)` という個別呼び出しの例を示していますが、py-1.45.0 のソースに `All` クラスは無く、判定メソッドも `detect()` ではなく `evaluate()` です。個別にガードを呼ぶコードを書くときは、ドキュメントの例を写す前に導入済みバージョンの公開APIを確認してください。 PIIガードは外部APIを呼ばず、[pii.py](https://github.com/openlit/openlit/blob/py-1.45.0/sdk/python/src/openlit/guard/pii.py) に定義されたローカルの正規表現24本で判定します。内訳はOpenAI・Anthropic・AWS・GCP・GitHub・Stripe・Slack・SendGridなどのAPIキー類と、メールアドレス・IPv4・クレジットカード番号・秘密鍵・接続文字列です。応答速度は実装のdocstringで1ミリ秒未満とされています。 日本語環境で効いてくるのは、残る個人情報系のパターンです。電話番号は `phone-us`、個人識別番号は `ssn`（米国の社会保障番号）で、日本の番号書式に対応した正規表現はありません。この24本を日本語のサンプルへ当てると、結果は次のように割れます。 | 入力 | 判定 | 一致したラベル | | ------------------ | ---- | --------------------- | | 0312345678 | 検出 | phone-us（10桁の並びに偶然一致） | | 03-1234-5678 | 未検出 | なし | | 090-1234-5678 | 未検出 | なし | | 4111111111111111 | 検出 | credit-card | | 378282246310005 | 未検出 | なし（15桁は対象外） | | test@example.co.jp | 部分検出 | email（.jp が範囲外） | | 氏名・住所・12桁の番号 | 未検出 | なし | 既存パターンへ偶然一致するものはあっても、携帯番号・氏名・住所・マイナンバーは検出されません。メールアドレスは多段ドメインの末尾が欠けた部分一致になるため、伏せ字にしても `.jp` が残ります。 したがって日本語環境での現実的な使い方は、PIIガードをAPIキー流出の防止線として位置づけ、個人情報の側は `capture_message_content=False` による記録の停止か、アプリ側でのマスキングで担保する構成です。ガード1行で個人情報保護の要件を満たしたとみなすのは誤りです。PIIクラスのcustom\_patternsで追加の正規表現を渡す方法もありますが、表記揺れや誤検出・未検出をテストする必要があります。なお2.1.0では、トレースガバナンスのポリシーパックとしてNIST AI RMF・EU AI Act・OWASP ASIが追加され、ガバナンス上の所見をトレース単位で確認できるようになっています。規程への適合を説明する材料は、ガードよりこちらが担います。 ## Langfuse・LangSmithとの使い分け 同種のツールと比べるときの判断材料は3点です。 第一に、OpenTelemetry対応の有無は判断材料になりません。LangfuseのSDKも現行版はOpenTelemetryの上に構築されており、[Langfuse OpenTelemetry連携の実装｜OTLP送信の設定と既存パイプラインの分岐](/tech/details/17009/)で扱ったとおりOTLPで受けられます。違いが出るのは製品の範囲です。Traceloop OpenLLMetryは計装ライブラリ群とSDKが中心でダッシュボードもストレージも持たず、OpenLITはUIとClickHouseまで含めたプラットフォームとして配布されます。同じ「OpenTelemetryベース」でも、自分で用意する部分の量が違います。 第二に、運用形態です。OpenLITはApache-2.0でセルフホストが既定、ClickHouseを自前で持つ前提です。裏返すとClickHouseの運用が発生します。マネージドで始めたい、運用要員を割けないという条件なら[LangSmithとは？トレース送信の設定・評価の実行・料金とリージョンの選び方【2026年版】](/tech/details/17585/)で扱ったSaaS側が向きます。 ライセンスも一様ではありません。OpenLITとTraceloop OpenLLMetryはApache-2.0、Langfuseは ee ディレクトリ配下を別ライセンスに切り出して残りをMITとする構成、Arize PhoenixはElastic License 2.0です。社内システムへ組み込んで再配布するなら、機能比較より先に見る箇所です。 第三に、対象範囲です。OpenLITはコーディングエージェント用のCLIとセッション画面を提供します。ただしLangfuseにもコーディングエージェント連携があるため、可視化の可否だけでは差分になりません。Claude CodeやCursorの利用実態とコストを部門単位で把握したい場合は、各製品の対応エージェント、利用者の識別方法、集計方法、権限管理を比較してください。 逆にOpenLITを選ぶべきでない条件もはっきりしています。ClickHouseを含むコンテナ基盤を運用する体制が無い、評価やPrompt Hubを使うためのAPIキー管理を増やしたくない、可観測性の統合先がすでにSaaSで完結している。この3つが揃う環境では、導入の手間に見合いません。 ## よくある質問 ### OpenLITは無料で使えますか？ リポジトリのライセンスはApache-2.0で、自分のインフラで動かす限り利用料は発生しません。費用が出るのはClickHouseとアプリケーションを動かすサーバーの実費、および評価機能で呼び出すLLMのAPI利用料です。 ### すでにDatadogやGrafanaを使っています。乗り換えが必要ですか？ 必要ありません。OpenTelemetry Collectorから既存バックエンドとOpenLITの両方へ同時に送れるため、段階的に評価してから判断できます。 ### Claude CodeやCursorの利用状況も記録できますか？ 記録できます。CLIを導入して `openlit coding install --vendor=all` を実行すると、Claude Code・Cursor・Codexのセッションについてプロンプト、ツール呼び出し、トークン使用量、コストが記録されます。導入状態は `openlit doctor` で確認します。 ### プロンプトの本文はどこまで記録されますか？ 既定では全文です。記録を止めるなら `capture_message_content` をFalseに、長さを制限するなら `max_content_length` に文字数を指定します。 ### 日本語の個人情報も検出できますか？ 日本固有の個人情報を網羅的には検出できません。メールアドレスなどは日本語文中でも検出対象で、日本の番号が既存パターンに偶然一致する場合もあります。py-1.45.0 のPIIガードが持つ24本の正規表現は、電話番号が米国形式、個人識別番号が米国の社会保障番号で、日本の電話番号やマイナンバーのパターンは含まれていません。日本語環境では記録自体を止めるか、アプリ側でマスキングしてから渡す設計が必要です。 ## 関連記事 - [OpenTelemetryのGenAIセマンティック規約｜gen\_ai属性とメトリクスの体系・移行の判断](/tech/details/17007/) - [Langfuse OpenTelemetry連携の実装｜OTLP送信の設定と既存パイプラインの分岐](/tech/details/17009/) - [LangSmithとは？トレース送信の設定・評価の実行・料金とリージョンの選び方【2026年版】](/tech/details/17585/) - [エージェントトレーシングとは？スパン木の設計・gen\_ai属性・記録範囲を実装目線で解説【2026年版】](/tech/details/16332/) - [LLMOpsとは？MLOpsとの違いとトレース・評価・コスト管理の実装を解説【2026年版】](/tech/details/16069/) --- 出典: [OpenLITとは？OpenTelemetryネイティブのLLM可観測性を自前で動かす手順【2026年9月版】]()（株式会社一創）