なぜこれを書くか
現役の 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