TrueFoundry AI GatewayとLangSmithの統合

企業はかつてない速さでAIアプリケーションを本番環境に移行させていますが、その運用上の現実はプロトタイプとは大きく異なります。アプリケーションチームは迅速なリリースと反復が求められ、プラットフォームチームと品質管理チームは、すべてのモデル呼び出しが何を行い、その理由、そして出力が正しかったかどうかを把握する必要があります。 そこで、より困難な課題となるのが次の点です。 すべてのアプリケーション内にカスタムの計測機能を記述することなく、複数のプロバイダーや複数のエージェントフレームワークにわたる何百ものモデル呼び出しを、どのように監視し、評価するのでしょうか？

TrueFoundryでは、実行レイヤーを統一し、チームがすでに使用している可観測性および評価システムをプラグインできるようにすることを目指しています。そのため、私たちは TrueFoundry AI Gateway と LangSmith （LangChain提供）とのネイティブ統合を発表します。ゲートウェイは、すべてのモデル呼び出しとすべてのエージェントステップが通過する単一の実行境界となり、LangSmithは、それらの呼び出しがチームが活用できるトレース、評価、データセット実行に変換される記録システムとなります。

TrueFoundry AI Gatewayのご紹介

The TrueFoundry AI Gateway は、すべてのモデルおよびエージェントリクエストに対する、単一で統制されたエントリーポイントを確立します。アプリケーションやエージェントは、もはやモデルプロバイダーと直接通信することはありません。ゲートウェイプロキシと通信します。このアーキテクチャ上の決定は、ポリシーの適用、ルーティングの決定、テレメトリーの生成に対して一貫したインターフェースを生み出すため重要です。ゲートウェイは、どのモデルが、どのような制約の下で、どの環境で、どのような安全対策とともに使用されるかを決定します。また、本番環境での動作を包括的に監視できる唯一の場所となります。

プラットフォームリーダーにとって、これはAIシステムが単なるPythonスクリプトの集まりではなく、インフラストラクチャのように振る舞い始める転換点となります。

​​LangSmithのご紹介

ゲートウェイがリクエストの実行場所と方法を統制する一方で、 LangSmith は、散在するログではなく、構造化されたトレースデータとして、実際に何が起こったかを再構築する場所です。LangSmithの用語では、 トレース は、単一のリクエスト（入力から最終出力まで）に対するエンドツーエンドのステップシーケンスを捕捉し、そのトレース内の各ステップは ラン、LLM呼び出し、チェーンステップ、プロンプトのフォーマット、その他可視化したいあらゆる操作など、単一の作業単位を指します。トレースは プロジェクト （特定のアプリケーションやサービスに関連するすべてのものを格納するコンテナ）に整理され、複数ターンの会話はスレッドとしてリンクできるため、単一の孤立したリクエストではなく、対話全体にわたる動作を検査できます。さらに詳しく知りたい場合は、こちらをお読みください。 可観測性の概念

LangSmithはフィードバックも第一級の概念として扱います。これにより、実行（ラン）にスコアや基準を付与できます。そのフィードバックが人間、自動評価器、または本番トラフィックで実行されるオンライン評価器のいずれから得られたものであってもです。これが単なる「モニタリング」以上のものにする理由です。つまり、デプロイ前に厳選されたデータセットでオフライン評価を実行し、本番環境での実際のユーザーインタラクションに対してオンライン評価を実行して、回帰を検出し、品質をリアルタイムで追跡する評価ループをサポートします。 

TrueFoundry AI Gatewayからのトレースは、LangSmith UIでこのように表示されます。各モデル呼び出しは、ゲートウェイレベルで取得された操作タイプとレイテンシとともに、独自の実行（ラン）として表示されます。

TrueFoundryとLangSmithの連携方法

ほとんどの企業はすでに、インシデント対応とSREプラクティスの基盤となる一元化された可観測性スタックを運用しています。LLMシステムにおける課題は、モデル呼び出し（プロンプト、完了、トークン使用量、キャッシュヒット、ガードレール決定、エージェントステップグラフ）によって生成されるテレメトリが、これらのツールが元々設計されたメトリクスやトレースにきれいにマッピングされないことです。チームは通常、以下の2つの不十分な選択肢のいずれかを選ぶことになります。

1. すべてのアプリケーションをLLM固有のSDKで計測する
2. 既存のスタックにトレースを送信するが、実行（ラン）、スレッド、評価は失われる。

TrueFoundry側では、AI GatewayのOpenTelemetryトレースエクスポーターを有効にします。ゲートウェイは、TrueFoundry Monitor UI内で表示できるトレースの生成と保存を引き続き担当し、これらのトレースのエクスポートは、TrueFoundry自身のストレージ動作を変更しない追加操作です。OTELエクスポートのドキュメントはこちらでご確認ください。 TrueFoundry

LangSmith側では、認証用のAPIキーと（オプションで）プロジェクト名を提供します。これにより、トレースはデフォルトではなく、予測可能なプロジェクトに格納されます。LangSmithのOpenTelemetryガイドには、認証とプロジェクトルーティングに使用されるOTLPヘッダーが記載されています。ドキュメント： LangChain

マネージドLangSmith（SaaS）との統合

ドキュメントはこちらをご覧ください。 LangSmith

VPCでLangSmithをセルフホストし、AI Gatewayからトレースをエクスポートする

Kubernetesにデプロイする場合、公式の「KubernetesでLangSmithをセルフホストする」ガイドはHelmベースであり、事前に提供する必要があるもの（LangSmithライセンスキー、APIキーソルト、および（基本認証を使用する場合）JWTシークレット）を明示しています。また、トレースの量が急速に増加する可能性があるため、本番環境ではクラスター内のデフォルトではなく、外部のマネージドPostgres/Redis/ClickHouseを使用することを推奨しています。さらに詳しく知りたい場合は、LangSmithのKubernetesでのセルフホストに関するドキュメントをご確認いただくことをお勧めします。 Kubernetesでのセルフホスト.

TrueFoundryでのこのセットアップを簡素化するため、私たちはHelmチャートリポジトリを github.com/truefoundry/tfy-langsmith-charts で管理しており、これはLangSmithと必要なバックエンドサービスをパッケージ化したものです。

まとめ

AIリーダーにとって、TrueFoundryとLangSmithの統合は、システムがスケールするにつれて実行、可観測性、評価が連携した状態を保つ共通の基盤を提供します。これにより、チームはLLMアプリケーションを、エンタープライズ要件を満たす分散サービスと同じ厳格さで管理できるようになり、本番AIには本番レベルのインフラストラクチャが必要であるため、開発速度を落とすこともありません。

このパートナーシップは意図的に構成可能であり、TrueFoundryが実行を統制・ルーティングし、LangSmithが挙動を記録・評価し、OpenTelemetryがそれらを接続します。これらが連携することで、組織を有望なデモ段階から、本番環境で信頼性と説明責任のあるAIへと移行させる実用的なコントロールプレーンとして機能します。