LangWatch を採用すべきか: ローカル起動の実態とオープンコアの境界線
The platform for LLM evaluations and AI agent testing
ひと目でわかる
- これは何？
- LLM エージェントの評価、シミュレーション、本番トレースを 1 つのループにまとめる TypeScript 製プラットフォーム。npx 一発で始められる一方、有効化する評価器によっては追加で数百 MB のモデルを落とすことになる。
- 誰に向いている？
- LangWatch が向くのは、エージェントの回帰テストと本番トレースを別々のツールで繋ぎ込むのに疲れたチームと、データを自社インフラに置いたまま評価ループを回したいチームである。逆に、評価パイプラインを既に自前で持っていて OpenTelemetry の受け皿だけが欲しい場合や、マネージド SaaS 以外を運用したくない小規模チームには、ローカル起動が落とす PostgreSQL、Redis、ClickHouse の保守コストのほうが重い。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
LangWatch が埋めようとしている溝はどこにあるか
エージェント開発で厄介なのは、失敗の原因が 1 か所に収まらない点にある。ツール呼び出しが誤ったのか、状態遷移が壊れたのか、ユーザー役の入力が非現実的だったのか、判定器の基準がずれていたのか。LangWatch はここを「エンドツーエンドのエージェントシミュレーション」として扱い、ツール、状態、ユーザーシミュレータ、ジャッジをまとめて 1 本のシナリオに載せ、どの意思決定で壊れたかを追う、と README は説明している。対象読者は評価と本番監視を別々の製品で組んでいるチームだ。README の表現を借りれば「回帰テスト、シミュレーション、本番オブザーバビリティを、独自ツールを作らずに必要とするチーム」向けとされている。ここで重要なのは、LangWatch が単体の評価ライブラリではなく、トレース、データセット、評価、プロンプト最適化を 1 つのループとして提示していることだ。ループの各段は独立した機能だが、データが画面をまたいで移動する前提で設計されている。
トレースからデータセット、評価、最適化へ戻るループの実体
README が示す流れは明快である。Trace、dataset、evaluate、optimize prompts/models、そして再テスト。この順序自体は珍しくない。差が出るのは、この往復に「接着コード不要」と銘打っている点で、トレースの取り込みが OpenTelemetry/OTLP ネイティブであることが前提になっている。フレームワークと LLM プロバイダに依存しない設計だと README は述べており、特定の SDK をアプリに埋め込むのではなく、OTLP の送信先を LangWatch に向ける形で計装する。データセットはトレースから切り出し、評価はオフライン評価として実行し、その結果をもとにプロンプトやモデルを見直す。プロンプト側は GitHub 連携で Git 管理し、プロンプトのバージョンをトレースに紐づけられる。つまり評価結果とプロンプトの版が同じ画面上で対応づく。ここは設計上の主張であって、実際の往復がどれだけ摩擦なく回るかは手元で確かめるしかない。少なくともアーキテクチャとしては、トレースが起点でプロンプトが終点、その間をデータセットと評価が繋ぐ一本道になっている。
npx @langwatch/server が実際に何をインストールするか
ローカル起動の最短経路は Node.js だけを前提にした次のコマンドである。npx @langwatch/server。この CLI は uv、postgres、redis、clickhouse、AI Gateway のバイナリ、Langy アシスタントのランタイムを ~/.langwatch/ 配下に導入し、ローカル生成のシークレットを含む .env を用意して、各サービスを並列に起動し http://localhost:5560 を開く。状態はすべて ~/.langwatch/ に閉じるので、rm -rf ~/.langwatch がそのまま初期化になる。ここで見落としやすいのが、既定で有効な評価器と無効な評価器の差である。~/.langwatch/.env の LANGWATCH_ENABLE_LANGY は既定 true で、アシスタントのランタイムに約 45MB を追加し、ワーカーはサンドボックスなしで自分の権限のまま動く。LANGWATCH_ENABLE_PRESIDIO は既定 false で、有効にすると約 670MB の言語モデルを追加で落とす。評価器環境の他の全部を合わせたより大きい、と README は明記している。LANGWATCH_ENABLE_LINGUA も既定 false で約 95MB。これら以外の評価器はどちらの設定でも入る。変更後はサーバを再起動する。Docker を使う場合は git clone ののち platform/app に移動し、.env.example を .env にコピーして docker compose up -d --wait --build を実行する。
AI Gateway が別バイナリとして切り出されている理由
LangWatch の構成で目を引くのは、AI Gateway が本体に混ざらず独立した Go バイナリとして services/aigateway/ に置かれ、Helm では charts/gateway/ というサブチャートになっている点だ。機能は OpenAI/Anthropic 互換のプロキシで、仮想キー、階層的な予算、インラインのガードレール、プロバイダ間の自動フォールバック、Anthropic の cache_control パススルーを備える。README はホットパスのオーバーヘッドを約 700 ナノ秒と記載している。この数値は README の主張であり、こちらで再現したものではない。設計意図は推測できる。ガバナンスとコスト制御は LLM 呼び出しの経路上に置く必要があり、評価やトレースの処理とは寿命もスケール特性も違う。だから別プロセス、別チャートにして、評価基盤を止めずにゲートウェイだけ更新する、あるいはその逆を選べるようにしている。ただしこれは運用単位が 2 つになるということで、Helm で入れるならリリース管理も 2 つ分になる。
セルフホストの選択肢と、それが意味する運用の重さ
デプロイ経路は Docker Compose、Kubernetes の Helm、AWS・Google Cloud・Azure 向けの OnPrem 構成が用意されている。データレジデンシーの要件が厳しいが完全なオンプレまでは要らない、という中間のケース向けにハイブリッド構成も文書化されている。ローカル開発者向けには、データベースだけを docker compose up redis postgres opensearch で先に起動し、別ターミナルで make install、make start を実行する手順が示されている。ここで注意したいのは、npx 経路が ClickHouse を導入するのに対し、開発者向け手順では opensearch を起動している点だ。どちらも README に書かれている以上、両方を同じ構成とみなすのは危うい。セルフホストを選ぶという判断は、PostgreSQL、Redis、ClickHouse という 3 つのステートフルなサービスを自分で面倒みるという判断でもある。評価とトレースの基盤を自前で持つ価値と、この運用負荷を天秤にかけることになる。
LangWatch が向かない場面と、代わりに何を選ぶか
LangWatch は評価と監視をひとつの製品に統合している。逆に言えば、すでに評価パイプラインを自前で持っているチームにとっては、統合の利点が働かない。たとえばプロンプトの回帰テストを pytest や CI ジョブで完結させ、判定ロジックも自作している場合、LangWatch を入れると評価の実行主体が二重になる。この場合は OpenTelemetry のコレクタとしてだけ使う構成のほうが素直で、OTLP ネイティブという性質はそのまま活きる。もうひとつの代替は、可観測性に特化した汎用の OTLP バックエンドにトレースを送り、評価は別のライブラリで回す組み合わせだ。違いは明確で、汎用バックエンドはトレースの保存と検索に責務を絞り、データセット化やプロンプト最適化の導線を持たない。LangWatch はその導線を製品の中心に据えている。どちらが優れているかではなく、評価ループを製品に任せるか、自分で組むかの選択である。評価の基準を外部に預けたくない、あるいは判定器を完全に制御したいチームには、LangWatch の統合は制約になる。
Apache-2.0 と Enterprise の境界、そして更新コスト
ライセンスはリポジトリ上 Apache-2.0 と表示されているが、README のバッジは「Apache 2.0 + Enterprise」、すなわちオープンコア構成であることを示している。つまり Apache-2.0 でカバーされる範囲と、Enterprise 拡張にしか含まれない機能が存在する。どの機能がどちら側かは、この材料からは判断できない。導入検討時に最初に確認すべきはここで、特にアノテーションやキュー、GitHub 連携、リンク機能といったコラボレーション系がどちらに属するかで、チームの使い方は変わる。ライセンスの解釈については法的助言はできないので、必要なら法務に確認してほしい。更新面では、リリースが sdks/go/v1.0.0、typescript-sdk@v1.13.0、skills@v1.4.0 のようにコンポーネント単位でタグ付けされている。SDK と本体が別々に動く以上、サーバ側の更新とクライアント SDK の更新を揃える運用が要る。npx 経路で入れた場合、~/.langwatch/ 配下の一式を更新することになる。
導入を決める前に手元で確かめるべきこと
最初に試すべきは npx @langwatch/server での起動そのものだ。所要時間、ディスク消費、そして ~/.langwatch/.env の 3 つのフラグを切り替えたときの挙動を自分の環境で見る。特に LANGWATCH_ENABLE_PRESIDIO を true にしたときの約 670MB の追加ダウンロードは、CI や開発者ノート PC では無視できない。次に、トレースの取り込みを OTLP で通し、そこからデータセットを作り、オフライン評価を 1 回回して、結果がプロンプトのバージョンに紐づくところまでを一巡させる。この往復が自チームのフレームワークで成立するかが、採用の分かれ目になる。最後に、AI Gateway を別デプロイとして運用に載せるかを決める。charts/gateway/ を別リリースとして管理する前提で Helm の構成を組めるか、あるいは当面はゲートウェイを使わず評価とトレースだけを評価する、という切り分けでも構わない。評価ループを製品に任せる範囲を先に決めてから、セルフホストかハイブリッドかを選ぶ順序が現実的である。
編集部の結論
LangWatch が向くのは、エージェントの回帰テストと本番トレースを別々のツールで繋ぎ込むのに疲れたチームと、データを自社インフラに置いたまま評価ループを回したいチームである。逆に、評価パイプラインを既に自前で持っていて OpenTelemetry の受け皿だけが欲しい場合や、マネージド SaaS 以外を運用したくない小規模チームには、ローカル起動が落とす PostgreSQL、Redis、ClickHouse の保守コストのほうが重い。採用前に確認すべきは 3 点で、第一に Apache-2.0 でカバーされる範囲と Enterprise 拡張の境界、第二に LANGWATCH_ENABLE_PRESIDIO を有効化したときの約 670MB の追加ダウンロードを許容できるか、第三に AI Gateway が services/aigateway/ の Go バイナリと charts/gateway/ の Helm サブチャートという別デプロイ単位になっている点を運用に組み込めるか、である。この 3 つが自チームの制約に収まるなら、トレースからデータセット、評価、プロンプト最適化までを 1 つの画面で往復できる構成は、繋ぎ込みコードを書かずに済む分だけ見合う。
コミュニティノート