なぜこれを書くか

現役の AI エンジニアで、現在は教育関係の仕事も並行している遠藤太一です。Part 1 (MCP 入門) に続き、自分が手掛けている 実プロダクト (医療系の Web 教材プラットフォーム) を題材に、新しい技術を消化していく実装ノートです。

Part 2 のテーマは LangSmith — LLM アプリの「観測 (Observability)」プラットフォームです。

なぜ LangSmith なのか

教材プラットフォームには既に pgvector ベースの RAG パイプライン が組み込まれています:

学習者の掲示板投稿を Gemini text-embedding-004 で 768 次元埋め込み
Supabase pgvector に保存
検索クエリも埋め込んで cosine 類似度 top-K で類似投稿を返す
「○○について話してる投稿を探す」検索バーで実利用

ここまでは動いています。ですが、こんな疑問が解けません:

検索クエリの P95 レスポンス時間 はどれくらい？
「ハルシネーション」と打った時、本当に医療系の投稿が上位に来ている？
prompt を 1 文字変えたら、応答品質はどう変わる？
どの段階 (embedding 生成 / SQL クエリ / 後処理) で時間がかかってる？

これらは「ログを眺める」では追えない。専用の観測基盤が要ります。

それが LangSmith です。

LangSmith とは何か

LangChain 社が運営する LLM アプリの観測 + 評価プラットフォーム。3 つの軸:

1. Tracing (トレース)

LLM 呼び出しを 木構造で可視化。1 リクエストに対して:

親 Run: 「掲示板検索」(全体)
子 Run 1: generateEmbedding (Gemini API 呼び出し)
子 Run 2: pgvector <=> 検索 (SQL 実行)
子 Run 3: anonymizePost (後処理)

各 Run について input / output / latency / token 数 / エラー が記録される。

2. Datasets + Evaluators

ゴールデンデータ (期待入出力) を Dataset として保存し、Evaluator で自動採点。プロンプトを変えるたびに「過去のクエリを全部再評価」して回帰を検出。

3. Monitoring

本番トラフィックの P95 latency / エラー率 / トークン使用量 / ユーザーフィードバック をダッシュボード化。

自分のプロダクトに統合する設計

Step 1: 既存の RAG パイプラインを LangChain でラップ

現状は素の @google/generative-ai + Prisma の $queryRawUnsafe で書いていますが、これを @langchain/google-genai + LangChain の Runnable で包みます。

import { ChatGoogleGenerativeAI, GoogleGenerativeAIEmbeddings } from "@langchain/google-genai";
import { Client } from "langsmith";
import { traceable } from "langsmith/traceable";

const embeddings = new GoogleGenerativeAIEmbeddings({ model: "text-embedding-004" });

export const searchBoard = traceable(
    async (query: string, userId: string) => {
        const vector = await embeddings.embedQuery(query);
        const results = await searchByVector(vector, userId);
        return results;
    },
    { name: "searchBoard", project_name: "medical-edu-rag" }
);

traceable で wrap するだけで、searchBoard の呼び出しが全て LangSmith に記録されるようになります。

Step 2: 環境変数 3 つで起動

LANGCHAIN_TRACING_V2=true
LANGCHAIN_API_KEY=ls__...
LANGCHAIN_PROJECT=medical-edu-rag

これだけ。コードに「ログを送る」処理は書きません。LangChain が自動でフックします。

Step 3: ダッシュボードで眺める

LangSmith Web UI で:

1 リクエストあたり embedding 生成に 何 ms かかっているか
同じ意味のクエリでも「ハルシネーション」と「AI幻覚」で類似度がどう違うか
どのレッスン由来の投稿が頻繁に上位に来ているか (= 学習者の関心領域の可視化)

を見られるようになります。

なぜ LangSmith を入れる価値があるか

LLM プロダクトを案件として納品するとき、避けて通れないのが 「スコアリング / 評価指標策定 / 運用改善」 です。LangSmith なしだと、これらは雰囲気でしか語れません。「P95 を改善した」と言うには 計測のスクショ が要る。

LangSmith のダッシュボード画面は、プロダクトオーナーやステークホルダーに見せられる「動く実績」 として強力です。「Hit Rate を 0.62 → 0.81 に改善しました、ここが Before/After のグラフです」と即座にメトリクスを出せる状態にしておくと、改善提案の説得力が桁違いです。

医療領域での副次効果

LangSmith は AI の意思決定を観測可能にする = 「説明可能性 (Explainability)」を担保するという意味で、医療 AI に強く効きます。

電子カルテに AI 提案を組み込む際、規制当局や倫理委員会から:

「その提案が出た根拠は何ですか？後から検証可能ですか？」

を必ず聞かれます。LangSmith のトレースは、「この LLM 出力は、これらの retrieval 結果と、このプロンプトテンプレートと、この context から生成された」 を完全に再現できるので、医療現場での AI 監査要件にも応えやすい。

シャドー AI の対極にある「透明な AI 運用」の基盤として、LangSmith は医療 IT で覚えておく価値があります。

次のステップ

Part 3 では本シリーズの集大成 Evals (評価ハーネス) に進みます:

LangSmith Dataset に ゴールデンデータ を 30 件入れる
LLM-as-Judge で ハルシネーション率 を自動採点
GitHub Actions で PR ごとに回帰検出

医療 AI で一番譲れない「答えてはいけないことを答えない」をどう数値で担保するかの記録になります。

学んだこと (現時点で)

LLM の「動く / 動かない」と「良い / 悪い」は別問題。観測なしでは後者が分からない
観測は最初から入れた方が安い。「動いてから入れる」は罠
LangSmith は OpenTelemetry 互換ではないが、専門特化している分 LLM アプリでは圧倒的に強い
無料枠 (5,000 traces / 月) で個人プロジェクトには十分

実装記録は次回。

タグ: LangSmith LangChain LLM RAG Observability 生成AI 医療AI TypeScript