LangSmith完全ガイド 2026｜AIエージェントのトレース・評価・運用監視を始める5ステップ

最終確認日: 2026年5月22日（日本時間）

AIエージェントを本番で回し始めると、すぐに「どのツール呼び出しで失敗したのか」「プロンプト変更で精度が上がったのか」「本番流量でどこから壊れ始めたのか」が見えなくなります。通常ログだけでは、エージェントの分岐、ツール呼び出し、評価結果まで一気通貫では追えません。

そこで候補に上がりやすいのが LangSmith です。この記事では、LangSmithとは何かを一次情報で整理し、Langfuse・Phoenix との違い、導入5ステップ、向いているケース、注意点をまとめます。

LangSmithとは

LangSmithとは、LLMアプリとAIエージェントの観測、評価、実験、デプロイをまとめて扱う LangChain のプラットフォームです。LangChain 公式ドキュメントでは、Observability、Evaluation、Deployment、Platform setup を一つのワークフローとして提供すると説明されています。特に LangChain / LangGraph ではトレース取得をすぐ始めやすく、評価データセットや実験結果も同じ流れで扱えます。LangSmith Docs

要するに LangSmith は、単なる「見える化ダッシュボード」ではありません。トレースで問題を見つける → データセット化する → 評価を走らせる → 実験比較する → 本番監視へ戻すまでを閉じたループで回しやすい点が中核です。LangSmith Evaluation Docs

LangSmith / Langfuse / Phoenix 比較

Langfuse 公式 docs は、トレース、セッション、エージェントグラフ、評価、Prompt Management を OpenTelemetry ベースで扱える点を強調しています。Phoenix 公式 docs は、Tracing、Evaluation、Datasets & Experiments、Prompt Engineering を OSS 中心で回せる点を前面に出しています。Langfuse Docs / Phoenix Docs

LangSmithの強みを3つで整理すると

1. トレース取得が速い

LangSmith の tracing quickstart では、LangChain / LangGraph 利用時に環境変数でトレースを有効化できる導線があり、OpenAI などの呼び出しを wrapper と decorator で追跡する例が示されています。つまり、最初の「何が起きたか分からない」を短時間で抜けやすいのが利点です。Tracing Quickstart

2. 評価が本番監視とつながる

LangSmith の Evaluation docs では、Offline Evaluation と Online Evaluation を明確に分けています。開発中のデータセット評価だけでなく、本番トレースに対する評価やフィードバックループを作れるため、リリース後の劣化検知まで視野に入れやすい構造です。Evaluation Docs

3. 導入形態を選べる

LangSmith は managed cloud だけでなく、Hybrid と Self-hosted も用意されています。公式 docs では Hybrid を「制御面は LangChain 側クラウド、データ面は自社クラウド」で分ける形として説明しています。エンタープライズでワークロードの置き場所を気にするチームには重要です。Hybrid Docs / Hosting Docs

LangSmithが向いているケース

導入5ステップ

1. まずトレースだけ入れる

最初から評価設計を完璧にしようとすると止まります。まずは公式 quickstart どおりに tracing を有効化し、代表ワークフロー1本の実行履歴が見える状態を作ってください。ここで確認するのは「モデル呼び出し」「ツール呼び出し」「失敗箇所」の3点です。

2. 失敗トレースを分類する

次に、本番または検証で出た失敗を「回答品質」「ツール選択」「フォーマット違反」「タイムアウト」「コスト超過」に分けます。分類しないまま評価を入れると、何を測っているのか分からなくなります。評価観点が曖昧な場合は、先にAIエージェント評価完全ガイドで評価軸を整理すると進めやすいです。

3. データセットと評価器を作る

LangSmith 公式 docs では、データセット作成、評価器定義、実験実行、結果分析という流れが示されています。まずは 20〜50 ケース程度の小さなデータセットから始め、人手レビューかルールベース評価を1つ入れるだけでも十分です。Evaluation workflow

4. オンライン評価を限定的に回す

本番全流量にいきなり LLM-as-a-judge を当てるとコストもノイズも増えます。LangSmith docs が説明するように、オンライン評価は sampling や filters を使って段階導入するのが現実的です。高価な評価を全件に当てるより、重要フローや失敗率が高い経路だけから始める方が安定します。

5. 週次で「トレース→評価→改善」を閉じる

LangSmith を入れても、見るだけで終わると価値が出ません。毎週、失敗トレースをデータセットへ追加し、プロンプト・ツール選択・モデル設定の改善を実験比較で検証する運用にすると、初めて品質改善が積み上がります。

実装時の注意点

1. トレースだけで満足しない: 可視化できても、評価器と改善サイクルがなければ品質は上がりません。
2. 機密情報を流し込みすぎない: トレースには入力や中間データが残るため、PII・機密文書・認証情報の扱いを先に決める必要があります。
3. 評価を全件自動化しすぎない: LLM-as-a-judge は便利ですが、重要領域では人手ラベルやコードルールと併用した方が安定します。
4. 比較対象を明確にする: LangSmith が強いのは LangChain 系の一体運用で、OTel 中立性や OSS 優先なら別解もあります。

LangSmithが「向く・向かない」を判断する適性早見表

前段の「向いているケース」では追い風になる状況を整理しましたが、ツール選定で本当に効くのは「自分たちの環境では逆に重くなる・恩恵が薄い」条件を先に見極めることです。ここでは導入前にチームの状況へ当てはめて採用可否を判断するための早見表として、向く側と向かない側を対にして整理します。判断軸は「LangChain/LangGraphへの依存度」「評価をどこまで運用に組み込むか」「規模とフェーズ」「複数フレームワーク併用の有無」の4点です。

表の「向かない寄り」「要確認」は、LangSmith自体の優劣ではなく前提条件とのミスマッチを示すものです。とくに「PoC止まりで評価を回さない」「フレームワークが多様で特定ベンダーに寄せたくない」「コストを極力かけたくない」のいずれかに強く当てはまる場合は、導入を急がず、まず自前ログ＋スプレッドシート評価で運用イメージを掴んでから本格採用を検討すると判断を誤りにくくなります。料金・制限・対応範囲などの具体値は変動するため、最終判断の前に必ず公式ドキュメントで最新仕様を確認してください。

本番導入前に押さえる実務チェックリスト

導入ステップ（トレース→分類→評価→オンライン評価→週次改善）が「進め方の順番」だとすれば、ここで示すのは本番に載せてよいかを判断するための合否チェックです。運用に乗せてから「個人情報がトレースに残っていた」「コストが想定外に膨らんだ」「評価が形骸化した」と気づくケースは少なくありません。設計・データ・コスト・セキュリティ・展開の5領域で、本番投入前に潰しておきたい項目を整理します。各項目は「やったか/やっていないか」で自己点検できる粒度にしています。

トレース設計

• 何を1トレースの単位にするかを決めたか（リクエスト単位か、エージェントの1タスク単位か）。粒度が曖昧だと後から分析しづらくなる。
• エージェントのステップ・ツール呼び出し・最終出力が親子関係として追える構造になっているか。
• 失敗時に原因を切り分けられるよう、入力・中間出力・エラー内容を欠落なく記録できているか。
• 環境（開発/ステージング/本番）をタグやプロジェクトで分離し、混在させない設計になっているか。

評価データセットの整備

• 実トレースから抽出した代表ケースと失敗ケースを最小セットで揃えたか（最初は少数でよいが、典型的な失敗を必ず含める）。
• 評価器が「正解一致」だけでなく、出力の妥当性・形式・安全性など狙いに合った観点を見ているか。
• データセットを更新・追記する運用ルール（誰が・いつ追加するか）を決めたか。

コスト管理

• 全件記録かサンプリングかの方針を決め、オンライン評価の対象量を絞る設計になっているか。
• トレース量・評価実行量が増えた際の費用感の見込みを立てたか（具体的な料金は変動するため公式の料金ページで要確認）。
• 本番トラフィックに評価を常時フル適用せず、段階的に範囲を広げる前提になっているか。

PII・機密情報のマスキング

• 氏名・連絡先・社内機密などがそのままトレースに保存されないよう、記録前にマスキング/除去する処理を入れたか。
• 誰がトレース・評価結果を閲覧できるか、アクセス範囲を定義したか。
• データの保管場所・保持期間が、自社のセキュリティ/コンプライアンス要件に適合するか確認したか（提供形態ごとの対応は公式ドキュメントで要確認）。

段階導入

• まず非クリティカルな機能や限定ユーザーから有効化し、影響範囲を絞っているか。
• トレース/評価を入れたことで本番のレイテンシや挙動に悪影響が出ないかを事前に確認したか。
• 問題発生時に計装をオフに戻せる手順（ロールバック）を用意したか。
• 「導入して終わり」にせず、誰が定期的にトレースと評価結果を見るかという運用担当を決めたか。

よくある質問

Q1. LangSmithとは何ですか？

AIエージェントやLLMアプリのトレース、評価、実験、デプロイを一連の流れで扱える LangChain 製プラットフォームです。

Q2. LangSmithはLangChain専用ですか？

LangChain / LangGraph との相性が特に強いですが、公式 docs では他のプロバイダや統合先も案内されています。ただし最も自然に価値が出やすいのは LangChain 系です。

Q3. LangfuseやPhoenixとの違いは何ですか？

LangSmithはトレース、評価、実験、デプロイを LangChain 文脈で一体運用しやすい点が特徴です。Langfuse は OpenTelemetry と OSS の柔軟性、Phoenix は OSS 中心の評価実験が強みです。

Q4. LangSmithは本番監視にも使えますか？

はい。LangSmith docs では Online Evaluation により、本番トレースに対する品質監視やフィードバックループを作れると説明されています。

Q5. Self-hostedやHybridはありますか？

あります。公式 docs では Cloud、Hybrid、Self-hosted の選択肢が案内されています。Hybrid は Enterprise plan 向けです。

Q6. 最初は何から始めればよいですか？

最初は tracing だけを有効化し、代表ワークフロー1本の実行履歴を観察するところから始めるのが最短です。その後に評価データセット化へ進むと失敗しにくいです。

LangSmith Pythonクイックスタート：トレースと評価の実装例

GSCで「langsmith official docs observability tracing evaluation」「langsmith evaluation official docs 2026」といったクエリが多く流入しているこの記事ですが、現行の本文では実際のコード例が手薄でした。ここでは公式ドキュメント（docs.smith.langchain.com）に基づいた実装例を整理します。API名・関数名はすべて公式で確認したものに限定しています。

ステップ1：環境変数の設定

LangSmith公式ドキュメントでは、現行バージョンの環境変数として LANGSMITH_TRACING と LANGSMITH_API_KEY を使用する形が案内されています。旧来の LANGCHAIN_TRACING_V2 は過去バージョンの名称であり、現在のドキュメントでは後者が正式表記です。

# LangSmith公式ドキュメントで確認した現行の環境変数
export LANGSMITH_TRACING=true
export LANGSMITH_API_KEY="your-langsmith-api-key"
export LANGSMITH_PROJECT="my-agent-project"   # 省略可・デフォルトは "default"
# 米国リージョン以外を使う場合のみ
# export LANGSMITH_ENDPOINT="https://..."

ステップ2：traceable デコレーターとwrap_openaiによるトレース取得

公式ドキュメント（observability quickstart）で示されているのが、@traceable デコレーターと wrap_openai() ラッパーの組み合わせです。これにより、OpenAIへの呼び出しとエージェントのロジックを親子スパン（span）として一本のトレースにまとめられます。

from openai import OpenAI
from langsmith.wrappers import wrap_openai   # wrap_openai: 公式確認済
from langsmith import traceable              # traceable: 公式確認済

# OpenAIクライアントをラップして全LLM呼び出しを自動記録
client = wrap_openai(OpenAI())

@traceable(run_type="tool")   # ツール呼び出しとして子スパンを作成
def get_context(question: str) -> str:
    # 外部DB・検索APIなどを呼ぶ処理
    return "retrieved context..."

@traceable   # エージェントのメインフローを親スパンとして記録
def run_agent(question: str) -> str:
    context = get_context(question)
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": "You are a helpful assistant."},
            {"role": "user", "content": f"{question}nnContext: {context}"}
        ]
    )
    return response.choices[0].message.content

# 実行するとLangSmithに自動でトレースが送られる
result = run_agent("LangSmithのonline evaluationとはどのような機能ですか？")

ポイントは get_context() が run_agent() の子スパンとして自動的に入れ子になる点です。これにより「どのツール呼び出しが遅かったか」「どこで失敗したか」をトレースUI上で一目で追えます。LangSmith Observability Docs

ステップ3：データセット作成と評価の実行

公式ドキュメント（evaluation）では、Client.create_dataset() → Client.create_examples() → Client.evaluate() という流れが示されています。評価器（evaluator）には、LangChain公式が提供するOSSパッケージ openevals のビルトイン評価関数を使えます。

from langsmith import Client
from openevals.llm import create_llm_as_judge    # openevals: 公式OSS確認済
from openevals.prompts import CORRECTNESS_PROMPT # ビルトインプロンプト定数: 公式確認済

client = Client()

# 1. データセット作成
dataset = client.create_dataset(
    dataset_name="agent-qa-eval-v1",
    description="エージェント応答の正確性評価用データセット"
)

# 2. 評価例（example）の追加
examples = [
    {
        "inputs": {"question": "LangSmithのtraceableデコレーターの用途は？"},
        "outputs": {"answer": "関数をLangSmithにトレーススパンとして記録するためのデコレーターです。"},
    },
]
client.create_examples(dataset_id=dataset.id, examples=examples)

# 3. LLM-as-judgeの評価器を定義（openevals公式ビルトインプロンプトを使用）
correctness_evaluator = create_llm_as_judge(
    prompt=CORRECTNESS_PROMPT,
    model="openai:gpt-4o-mini",
    feedback_key="correctness",
)

# 4. 評価の実行
results = client.evaluate(
    run_agent,                              # 評価対象の関数
    data="agent-qa-eval-v1",              # データセット名
    evaluators=[correctness_evaluator],   # 評価器リスト
    experiment_prefix="baseline-eval",    # 実験名プレフィックス: 公式確認済
    max_concurrency=2,
)
print(results)

client.evaluate() を実行すると、データセット内の各例に対して run_agent が呼び出され、結果が correctness_evaluator で採点されます。実験ごとにUIで比較グラフが自動生成されるため、「プロンプトAとプロンプトB、どちらが正確性が高いか」を数値で確認できます。

openevals で使えるビルトイン評価プロンプト

公式OSS openevals（LangChain公式維持）には、以下のプロンプト定数が実装されています（公式GitHubで確認）。

出所: LangSmith Evaluation Docs / openevals 公式OSS

Online Evaluation：本番トレースへの自動評価

公式ドキュメントで説明されているOnline Evaluationは、本番トレースが届いた時点でリアルタイムに自動評価を走らせる機能です。UI上の設定手順は次の通りです。

1. LangSmith UIのTracing Projectsで対象プロジェクトを開く
2. 「Evaluators」タブを選択し「+ Evaluator」をクリック
3. 「Code Evaluator」（コードルール）または「LLM-as-Judge Evaluator」を選ぶ
4. フィルター条件を設定（例：不満足フィードバックが付いたトレースのみ、特定ツールを含むトレースのみ）
5. サンプリングレート（0〜1.0）を設定してコストをコントロール

Code Evaluatorは入力として Run オブジェクトを受け取り、{"feedback_key": score} を返す関数として定義します。NumPy、pandas、jsonschemaなどの標準ライブラリは利用可能ですが、外部へのネットワーク接続は制限されています。全件ではなくサンプリングを使い、「重要なフローだけ・失敗率が高い経路だけ」から始めるのが現実的な導入方法です。LangSmith Online Evaluation Docs

利用プランの構成（公式確認）

LangSmith公式サイト（2026年6月時点）では以下の3プランが確認できます。詳細・最新の料金は変動するため公式ページで要確認です。

セルフホスト・ハイブリッドはEnterpriseプラン向けの対応です。個人開発や検証用途はDeveloperプランから始め、チーム運用が本格化したらPlusに切り替えるパターンが一般的です。LangSmith Pricing

まとめ

LangSmith は、AIエージェント運用で一番つらい「壊れ方は見えないのに、改善結果も測れない」という状態を抜けるための有力候補です。特に LangChain / LangGraph を使うチームなら、トレース、評価、実験、本番監視を同じ文脈で回しやすいのが大きな利点です。

1. まず tracing を入れる
2. 次に失敗トレースを評価データセット化する
3. 最後に weekly で実験比較まで回して改善を閉じる

あわせて読みたい:

• Langfuse完全ガイド
• Phoenix完全ガイド
• AIエージェント観測ツール比較
• AIエージェント評価完全ガイド

参考・一次情報

• LangSmith Docs: Home
• LangSmith Docs: Tracing quickstart
• LangSmith Docs: Evaluation
• LangSmith Docs: Hybrid
• LangSmith Docs: Hosting
• Langfuse Docs
• Arize Phoenix Docs