2026.09.11 AI

LangSmithとは？トレース送信の設定・評価の実行・料金とリージョンの選び方【2026年版】

Q: LangChainを使っていないアプリでもトレースできますか？

できます。方法は2つで、1つは langsmith SDKの @traceable を任意の関数に付ける形、もう1つがOpenTelemetryのOTLPエンドポイント（ https://api.smith.langchain.com/otel ）へ直接送る形です。後者なら既存のOTel計装をそのまま向けられるため、FastAPIやGoのサービスに後付けする場面でもアプリの構造を変えずに済みます。

Q: 日本のデータを国外に出さずに使えますか？

GCP APACリージョン（ apac.smith.langchain.com ）を選べば、その組織のデータはAPAC側で扱われます。注意点は、リージョンをサインアップ時に選ぶ必要があることです。公式のRegions FAQはリージョン間の移行を提供しないと明記しており、後から組織ごと移すことはできません。

LangSmithとは？トレース送信の設定・評価の実行・料金とリージョンの選び方【2026年版】

LangSmithは、LLMアプリの実行を1件ずつ記録し、どのプロンプトでどのモデルが何を返したかを後から追えるようにするLangChain社のプラットフォームです。導入そのものは環境変数3つとSDKの数行で終わります。詰まるのはその先です。どのリージョンで組織を作るか、base traceを何日残すか、既存のOpenTelemetry基盤とどう併存させるかを決めずに走り出すと、運用に入ってから取り返しがつきません。この記事では、run・traceという記録単位、wrap_openaiと@traceableによる最小構成、OTLPエンドポイントの設定、evaluateによる評価、Developer／Plusの課金単位、リージョン移行が非対応という制約までを、2026年9月時点の公式ドキュメントで確認した内容に沿って整理します。

まとめ｜最初に決めるリージョンと課金単位の見積り

結論から示します。LangSmithで先に決めるべきは、組織を作るリージョンと、トレースを何日残すかの2点です。前者は後から変えられません。公式のRegions FAQには「We do not support migration between regions at this time」と明記されており、US・EU・APACをまたぐ組織の移行手段は提供されていません。日本国内のデータで運用するなら、最初のサインアップで apac.smith.langchain.com を選ぶ判断が必要になります。

課金は座席数とトレース量の2軸です。Developerは1シート・月5,000 base tracesまで無料、Plusは1シート月39ドルでシート数無制限・月10,000 base tracesが含まれ、超過分は従量課金になります。base traceの保持は14日、extended traceにすると400日です。

実装はLangChainを使っていないアプリでも通ります。https://api.smith.langchain.com/otel というOTLPの受け口があり、既存のOpenTelemetry計装をそのまま向けられる設計です。見送ってよい条件も明確で、実行が1日数件のPoCと、人手で結果を読まない単発バッチが該当します。

LangSmithの記録単位｜run・trace・thread・projectの関係

設計を誤りやすいのは、記録の粒度です。LangSmithは4つの単位を使い分けており、これを取り違えると後から集計できないデータが溜まります。

runとtraceの親子関係｜1トレース25,000runという上限

公式の概念説明では、runは「a single unit of work executed by an agent」と定義されます。LLMの呼び出し1回、プロンプトの整形1回、ドキュメントの検索1回が、それぞれ独立したrunです。OpenTelemetryのspanに相当する粒度と考えて差し支えありません。

traceはそのrunの集合で、「a collection of runs for a single operation」と説明されています。ユーザーの質問1件を処理する過程で発生した検索・整形・生成が、共通のトレースIDで1本にまとまる構造です。ここに上限があります。1トレースに含められるrunは25,000件まで。通常の問い合わせ処理で当たる数字ではありませんが、ループを回すエージェントを1トレースに閉じ込める設計では届きます。長時間動くバッチを1トレースに収める設計は、この時点で避けるのが無難です。チェーン構造がどう分解されるかはLangChainの仕組みと採用判断の側から見ると把握しやすくなります。

threadとprojectの使い分け｜多ターン会話を束ねる単位

threadは「a sequence of traces representing a single multi-turn session」で、会話の1ターンごとに作られたトレースを thread_id メタデータで束ねます。チャットボットで「3ターン前の指示を無視した」という報告を受けたとき、threadがなければ該当トレースを人手で探すことになります。多ターン前提のアプリなら、実装の初日から thread_id を渡しておきたいところです。

projectは「a container for all the traces related to a single application or service」で、アプリケーション単位の入れ物です。環境ごとに分けるか、アプリごとに分けるかは決めておく必要があります。実務では rag-prod と rag-stg のように環境をprojectで分ける運用が扱いやすく、本番のダッシュボードに検証中のノイズが混ざりません。グラフ構造で状態を持つエージェントの場合はノード単位のrunが増えるため、LangChainとLangGraphの違いと使い分けで整理した実行モデルの差が、そのままトレースの形に現れます。

環境変数とwrap_openaiでトレースを送る最小構成の手順

最小構成は15分で動きます。公式のクイックスタートに沿って、環境変数とSDKの2段階で見ていきます。

pip installと3つの環境変数｜LANGSMITH_TRACINGの設定

必要なパッケージと環境変数は次の通りです。LANGSMITH_TRACING を true にしない限り、SDKを入れてもトレースは送信されません。

pip install -U langsmith openai

export LANGSMITH_TRACING=true
export LANGSMITH_API_KEY="lsv2_pt_xxxxxxxx"
export LANGSMITH_PROJECT="rag-prod"

3つ目の LANGSMITH_PROJECT を省略すると default プロジェクトに集約されます。環境変数名は旧称の LANGCHAIN_TRACING_V2 から移っており、日本語の解説記事には旧名が残るものが多い状況です。両方を設定した環境は挙動が読みにくくなるため、新規に組むなら LANGSMITH_ 接頭辞で揃えておくと後任に説明しやすくなります。SDKはPythonとJavaScript／TypeScriptの2系統がlangsmith-sdkリポジトリで開発され、python/ と js/ が同じリポジトリに同居しています。

@traceableでツール関数とLLM呼び出しを分けるspan設計

OpenAIクライアントを wrap_openai で包むと、LLM呼び出しが自動で入れ子のspanとして記録されます。検索などの自作処理は @traceable を付けて明示的に区切ります。

from openai import OpenAI
from langsmith import traceable
from langsmith.wrappers import wrap_openai

client = wrap_openai(OpenAI())

@traceable(run_type="tool")
def get_context(question: str) -> str:
    return search_documents(question)

@traceable
def assistant(question: str) -> str:
    context = get_context(question)
    res = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": f"context: {context}"},
            {"role": "user", "content": question},
        ],
    )
    return res.choices[0].message.content

run_type="tool" の指定で、その関数はLLM呼び出しとは別種のrunとして扱われます。指定を省くと全てが汎用のchain扱いになり、後からレイテンシの内訳を見たときに「遅いのは検索か生成か」を切り分けられません。計測の目的が原因の切り分けなら、run_typeは省略しない前提で書き始めるのが現実的です。span木をどう切るかという設計そのものは、製品を問わない論点としてエージェントトレーシングのspan木設計で扱っています。

既存OpenTelemetry基盤からOTLPでトレースを送る設定

LangSmithはLangChain専用ではありません。既存アプリがOpenTelemetryで計装済みなら、SDKを入れ替えずにエクスポート先を追加する形で導入できます。

OTLPエンドポイントにパスを足すと404になる設定の落とし穴

受け口は https://api.smith.langchain.com/otel です。公式のOpenTelemetry連携ドキュメントは、この値にパスを含めないよう明示しています。OTLP／HTTPのエクスポーターが /v1/traces を自動で付けるため、環境変数に完全なパスを書くと /otel/v1/traces/v1/traces となり404が返ります。送信できない原因を認証やファイアウォールに求める前に、まずこの二重付与を疑ってください。

セルフホスト構成では https://your-domain.com/api/v1/otel の形式になり、クラウド版とパスの規則が異なります。同じ設定ファイルを両環境で使い回している場合、ここは環境変数で分岐させる必要があります。

x-api-keyヘッダとリージョン別ホストを指定する書き方

認証はヘッダで渡します。プロジェクト名も同じヘッダに載せられます。

export OTEL_EXPORTER_OTLP_ENDPOINT=https://apac.api.smith.langchain.com/otel
export OTEL_EXPORTER_OTLP_HEADERS="x-api-key=lsv2_pt_xxxxxxxx,Langsmith-Project=rag-prod"

ホスト名はリージョンごとに変わり、GCP EUは eu.api.smith.langchain.com、GCP APACは apac.api.smith.langchain.com、AWS USは aws.api.smith.langchain.com です。APIキーは発行したリージョンでしか通らないため、ホスト名とキーの組み合わせを誤ると認証エラーになります。既存のOTelパイプラインを分岐させて複数の可観測性基盤へ同時送信する構成は、LangfuseへのOTLP送信と既存パイプラインの分岐で扱った設計がそのまま応用できる領域です。

データセット作成からevaluateまで評価を実行する具体手順

トレースを見るだけでは、プロンプトを変えたときに良くなったのか悪くなったのかを判定できません。LangSmithの評価機能は、記録から回帰テストを作る役割を担います。

create_datasetとcreate_examplesで正解データを登録

公式の評価クイックスタートでは、評価を「入力データセット・評価対象の関数・evaluator」の3要素で構成すると説明されています。データセットの登録は次の形です。

from langsmith import Client

client = Client()
dataset = client.create_dataset(
    dataset_name="rag-qa",
    description="社内FAQ由来の質問と期待回答 50件",
)
client.create_examples(
    dataset_id=dataset.id,
    examples=[
        {
            "inputs": {"question": "経費精算の締め日はいつですか"},
            "outputs": {"answer": "毎月20日です"},
        },
    ],
)

現場で効くのは、本番トレースから失敗例を拾ってデータセットへ足していく流れです。UIで問題のあるトレースを選んでデータセットに追加できるため、クレーム1件が回帰テスト1件になります。50件程度でも、プロンプト変更時の劣化検知には足ります。

evaluateとLLM-as-judgeで実験を比較する評価の実行

評価の実行は client.evaluate です。第1引数に評価対象の関数、data にデータセット名、evaluators に採点関数を渡します。

results = client.evaluate(
    target,
    data="rag-qa",
    evaluators=[correctness_evaluator],
    experiment_prefix="rag-v2-prompt",
    max_concurrency=2,
)

experiment_prefix を付けておくと、UIで実験同士を横に並べて差分を読めます。採点側は openevals の create_llm_as_judge でLLM-as-judgeを組むほか、文字列一致や数値比較の自作関数も渡せる仕様です。max_concurrency は評価対象のAPIレート制限に合わせて絞る値で、既定のまま大きなデータセットを流すと評価側でレート制限に当たります。判定を全てLLMに任せると採点そのものが揺れるため、決定的に判定できる項目は自作関数で先に弾くほうが扱いやすくなります。

LangSmithの料金｜base traceとLCU・LSUで費用が増える条件

費用の読み方が、この製品でもっとも誤解されている部分です。公式の料金ページで確認できる2026年9月時点の条件を基に、増え方の構造を整理します。

DeveloperとPlusの含有トレース数とシート課金の違い

プランは3種類で、無料のDeveloper、シート課金のPlus、条件個別のEnterpriseに分かれます。含有量と座席の扱いは次の通りです。

項目	Developer	Plus	Enterprise
シート料金	0ドル（1シート固定）	39ドル／シート・月	個別見積
含有base traces	5,000／月	10,000／月	個別
シート追加	不可	無制限に追加可	個別
超過分	従量課金	従量課金	従量課金

従量部分はLCU（LangChain Compute Unit）が1.50ドル、LSU（LangChain Storage Unit）が1.00ドルという単位で示されており、トレース1件あたりの単価ではなく計算量と保存量の2系統で積算されます。見落としやすいのは座席側です。トレース量が小さくても、開発者が5人いてPlusなら月195ドルの固定費が先に立ちます。1リクエストに検索と生成が含まれても1トレースとして数えられるため、日次160リクエスト程度まではDeveloperの無料枠に収まる計算です。

base traceの14日保持と400日保持を選ぶ判断の分かれ目

保持期間は費用と直結します。base traceは14日、extended traceは400日で、後者は課金対象の扱いが変わります。判断基準は「そのトレースを誰がいつ読むか」です。日々のデバッグに使うだけなら14日で足りますが、次の2つの要件があるときは400日側を選ぶ価値が出ます。

モデルやプロンプトを四半期ごとに更新し、更新前後の応答品質を後から突き合わせる運用がある
誤った出力への問い合わせが数か月後に届く業務（保険・医療・公共系の照会窓口など）を扱っている

逆に、14日を超えたトレースを一度も開いていないなら、その保持は費用だけを増やしています。運用開始から2か月ほどで「何日前のトレースを実際に開いたか」を棚卸しし、そこで決め直すのが無駄がありません。コストと品質をどの指標で見続けるかという全体設計はLLMOpsのトレース・評価・コスト管理の側で整理しています。

リージョン選定とセルフホスト｜移行非対応という制約への先回り

ここが本記事でもっとも先に決めてほしい部分です。技術的な難しさはないのに、後から変更できない項目が集まっています。

US・EU・APACの4系統と移行非対応という一方通行の選択

クラウド版の入口は4つあります。GCP USの smith.langchain.com、GCP EUの eu.smith.langchain.com、GCP APACの apac.smith.langchain.com、AWS USの aws.smith.langchain.com です。そしてRegions FAQには、リージョン間の移行を提供しないこと、異なるリージョン間での組織接続と請求の共有に対応しないこと、1つの組織が複数リージョンにワークスペースを持つことにも対応しないことが、いずれも「does not support this at the moment」として並んでいます。

実務上の意味は明快です。何も指定せずサインアップするとGCP USの組織ができ、日本のユーザーの問い合わせ文面が米国側に残ります。個人情報や機微な業務データをプロンプトに含める設計なら、APACを選び直すには組織の作り直しが避けられません。判断は言い切れます。国内の顧客データがプロンプトに乗る可能性が1%でもあるなら、最初からAPACで組織を作ってください。「後で移せる」という前提は、公式ドキュメントに否定されています。データの置き場所と記録範囲を設計段階から決めておく進め方は、生成AI導入支援のように業務の棚卸しからツール選定・セキュリティ要件までを通して伴走する形が相性が良く、運用開始後の作り直しを避けられます。

セルフホストがEnterprise限定｜必要なミドルウェア構成

データを一切外部に出せない要件では、セルフホストが候補になります。ただし公式ドキュメントは「Self-hosted LangSmith is an add-on to the Enterprise plan」と明記しており、Plusからの延長では選べません。トライアル用のライセンスキーの取得にも営業窓口への連絡が必要です。

構成側の要件も軽くはありません。Kubernetesでのセットアップが標準の手順として案内され、本番運用ではClickHouse・PostgreSQL・Redis／Valkey・Blobストレージを外部サービスとして用意することが強く推奨されています。AWSならRDSとS3、GCPならCloud SQLとCloud Storageという組み合わせです。可観測性の基盤のために、データベース3種とオブジェクトストレージを自社で守り続けられるか。担える体制がないなら、セルフホストは選ばず、APACリージョンのクラウド版で要件が通るかを先に確認してください。

LangSmithを採用しない場面と自前計装に寄せる判断条件

入れない判断も設計の一部です。計測基盤は入れた時点で運用対象が1つ増えるため、得られるものが小さい局面では見送ったほうが総量として軽くなります。

採用が過剰になる条件｜PoC段階と単発バッチにおける記録の扱い

見送ってよい条件は2つに絞れます。1つは、実行が1日数件でプロンプトも固定のPoC。トレースを開く習慣ができる前に検証が終わるため、標準出力のログで足ります。もう1つは、人が結果を読まない単発バッチです。夜間に1万件を分類して結果をDBへ書くだけの処理なら、失敗件数とエラー内容をアプリ側のログに残すほうが速く追えます。

判断の分かれ目は、実行の件数ではありません。記録を読む相手がいるかどうかです。自分以外の誰か（QA担当・顧客・数か月後の自分）に応答の根拠を説明する必要が出た時点で、初めてトレース基盤の費用対効果が立ちます。この線を引かずに「まず計測から」と入れると、誰も開かないダッシュボードと月39ドルのシートだけが残ります。

フレームワーク非依存を優先する場合の代替候補と乗り換えの起点

LangSmithを採らない方向の筆頭は、オープンソースで自社運用できる基盤です。セルフホストがEnterprise限定である点が制約になる場合、MITライセンスでDockerによる自前運用が無償のLangfuseが現実的な比較対象になります。両者の性格の違いと料金構造の比較はLangfuseの機能とLangSmithとの違いで表にまとめているため、比較検討の段階ならそちらを先に読んだほうが判断が早まります。

もう1つの方向が、特定製品に寄せず、OpenTelemetryの規約に沿って自社で計装しておく進め方です。gen_ai.* 属性で記録しておけば、送信先を差し替えても計装コードは残ります。LangChainやLangGraphを軸に組んでおり、Prompt Hubやネイティブトレースを組み立てなしで使いたいならLangSmith。送信先を将来入れ替える前提なら、計装をOTel規約側に寄せる。この2択で迷いは減ります。

よくある質問

LangSmithの導入検討でよく挙がる論点を、公式ドキュメントの記載に沿って整理します。

LangSmithは無料で使えますか？

使えます。Developerプランは0ドルで、1シート・月5,000 base tracesまで含まれます。ただしシートは1つ固定で、2人目以降が同じ組織でトレースを見るにはPlus（1シート月39ドル）が必要です。個人の検証やプロトタイプは無料枠で完結する一方、チームで結果を共有する段階に入ると座席側の費用が先に立ちます。

LangChainを使っていないアプリでもトレースできますか？

できます。方法は2つで、1つは langsmith SDKの @traceable を任意の関数に付ける形、もう1つがOpenTelemetryのOTLPエンドポイント（https://api.smith.langchain.com/otel）へ直接送る形です。後者なら既存のOTel計装をそのまま向けられるため、FastAPIやGoのサービスに後付けする場面でもアプリの構造を変えずに済みます。

LangSmithとLangfuseはどちらを選ぶべきですか？

LangChain／LangGraphを軸に組んでおり、運用を自社で持ちたくないならLangSmithです。セルフホストを無償で行いたい、フレームワークに依存しない形で観測データを自社に残したいならLangfuseが候補になります。機能・料金・ライセンスの比較はLangfuseとは？LangSmithとの違いで詳しく整理しています。

日本のデータを国外に出さずに使えますか？

GCP APACリージョン（apac.smith.langchain.com）を選べば、その組織のデータはAPAC側で扱われます。注意点は、リージョンをサインアップ時に選ぶ必要があることです。公式のRegions FAQはリージョン間の移行を提供しないと明記しており、後から組織ごと移すことはできません。

トレースの保持期間を過ぎたデータはどうなりますか？

base traceの保持は14日で、期間を過ぎたトレースは参照できなくなります。長く残すものはextended trace（400日保持）として扱う選択があり、こちらは課金上の扱いが別です。四半期単位でモデルやプロンプトを更新し、前後の品質を突き合わせる運用があるなら400日側、日々のデバッグ用途だけなら14日で足ります。