LangSmith

このスキルを使用する場合

• ユーザーはすでに LangSmith を選択しており、トレーシング、評価、レビュー、プロンプト所有権、またはトレース伝播のための最小限の有用なパケットが必要である。
• リクエストが LangChain トレーシング、@traceable / traceable、wrap_openai / wrapOpenAI、アノテーション キュー、実行ツリー、トレース ID、データセット、または実験比較について言及している。
• チームが、変更がデバッグ トレース、オフライン評価ゲート、オンライン レビュー キュー、Prompt Hub / プロンプト レジストリ作業、またはマルチサービス リネージを必要とするかどうかを決定する必要がある。
• ユーザーはすでに LangSmith がある程度セットアップされているが、信頼度がまだ低く、監査/ギャップ レビューが必要である。

このスキルをメイン ワークフローとして使用しない場合:

• 実際のジョブが汎用ダッシュボード / アラート / SLO / テレメトリ所有権 → monitoring-observability
• 実際のジョブが既存ログの根本原因トリアージ → log-analysis
• 実際のジョブがコードレベルの再現/バグ分離 → debugging
• 実際のジョブがデプロイメント / ロールアウト オーケストレーション → deployment-automation
• 実際のジョブが汎用エクスポート メトリクス解釈または KPI 統合 → data-analysis
• 実際のジョブがランタイム ガードレール / 承認 / ポリシー ミドルウェア → 関連するセキュリティまたはポリシー スキル

コアアイデア

langsmith は ワークフロー パケット ルーターとして動作すべきで、巨大な SDK エンサイクロペディアではありません。

1. API に名前を付ける前にリクエストにラベルを付けます。
2. 1 つのプライマリ パケットを選択します。
3. 質問に答える最小限のインストルメンテーション / 評価 / レビュー表面を選択します。
4. コンパクトなオペレーター ブリーフを返します。
5. 隣接する可観測性、デバッグ、デプロイメント、およびポリシー作業を素早く外部にルーティングします。

パケットを選択する前に、これらのサポート ドキュメントを読んでください:

• references/intake-packets-and-route-outs.md
• references/modes-and-routing.md
• references/python-sdk.md
• references/typescript-sdk.md
• references/cli.md

手順

ステップ 1: リクエストを正規化する

プロンプトをまずこのインテーク パケットに変換します:

langsmith_packet:
  primary_packet: trace-debug | eval | review | prompt-registry | propagation | audit
  app_shape: chat | rag | tool-calling | agent | batch-job | multi-service | mixed | unknown
  runtime: python | typescript | mixed | cli-only | unknown
  request_type: setup | debug | pre-ship gate | production review | prompt decision | cross-service tracing | audit
  current_evidence: traces | datasets | evaluators | feedback queues | prompt versions | exported runs | none
  confidence_problem: missing traces | noisy traces | no regression gate | weak review rubric | prompt drift | broken lineage | mixed | unknown
  route_after: stay-here | monitoring-observability | log-analysis | debugging | deployment-automation | data-analysis

実行のための1 つのプライマリ パケットを選択します。2 つが妥当に見える場合は、不確実性を最も速く低減するものを選択します。

ステップ 2: パケットを選択する

パケット	使用時期	メイン出力	典型的なシグナル
trace-debug	実際の質問が「何が起こったのか?」である	trace-debug パケット	見える化の欠如、ラッパー/デコレーター、トレース カバレッジ、メタデータ規律
eval	変更がプレシップまたは回帰信頼が必要である	eval パケット	データセット作成、評価器、実験、ベースライン/候補比較
review	トレースは存在するが本番での信頼が弱い	review パケット	アノテーション キュー、フィードバック基準、ヒューマン スコアリング、インライン レビュー
prompt-registry	プロンプト/バージョン所有権がボトルネック	prompt パケット	Prompt Hub、プロンプト バージョン、Git 同期、プロンプト バリアント比較
propagation	1 つのリクエストがサービス、ジョブ、ツール、またはエージェントにまたがる	propagation パケット	親/子トレース ID、クロスサービス ヘッダー、マルチホップ リネージ
audit	LangSmith は存在するがまだ有用ではない	audit パケット	ノイジー トレース、欠落 ID、評価の欠如、プロンプト所有権の不明確さ

パケット ルール:

• チームが実行ツリーを説明できない場合は trace-debug を優先します。
• 次のリスクが回帰ゲートなしで出荷されることである場合は eval を優先します。
• 実際のユーザー出力がヒューマン またはストラクチャード品質フィードバックを必要とする場合は review を優先します。
• プロンプト/バージョン選択が実際のボトルネックである場合のみ prompt-registry を優先します。
• 1 つのリクエストが単一のサービス境界を超えて広がる場合は propagation を優先します。
• システムが既に「LangSmith を持っている」が信頼度がまだ低い場合は audit を優先します。

ステップ 3: 最小限の有用な表面を選択する

表面	使用時期	強み	リスク
プロバイダー ラッパー (wrap_openai、wrap_anthropic、wrapOpenAI)	モデル呼び出しカバレッジが必要である	見える化トレースへの最速パス	単独で使用する場合、より高度なワークフロー コンテキストを見落とす
デコレーター / traceable()	アプリ関数の周りに名前付きスパンが必要である	明確なスパン境界、再利用可能	それでも意図的な配置が必要
手動トレース ブロック / トレーシング コンテキスト	スコープまたは一時的な見える化が必要である	監査と疑わしいブロックに適している	計器装置が不足しやすい
アノテーション キュー + フィードバック基準	ストラクチャード ヒューマン レビューが必要である	ルーブリックとレビュアー フローを保持	レビュー所有権は引き続き設計が必要
データセット + 実験ワークフロー	ベンチマークまたは回帰チェックが必要である	プレシップ比較を提供	制限されていない場合、汎用評価理論に漂流可能
CLI エクスポート/リスト/取得フロー	インストルメンテーション設計よりも監査/エクスポート操作が必要である	スクリプトと検査に適している	インストルメンテーション設計の代替ではない
クロスサービス伝播ヘッダー / メタデータ	エンドツーエンド リネージが必要である	親/子コンテキストを保持	サービス境界で忘れやすい

ルール:

• 現在の質問に答える最小限の表面を優先します。
• 常にプロジェクト/ワークスペース/環境グループ化に名前を付けます。
• ヒューマンまたはダウンストリーム ツールが後で実行をレビューする場合は、run_id、trace_id、メタデータを保持します。
• CLI、ワーカー、短寿命ジョブのシャットダウン フラッシュ / 待機動作を含めます。

ステップ 4: 必要な場合のみ評価またはレビュー レイヤーを選択する

レイヤー	使用時期	注記
決定論的 / コード評価器	出力を機械的にチェックできる	構造/ファクチュアル ルールの最初の選択肢
LLM-as-judge (openevals)	品質が主観的または参照が少ない	有用だが、グラウンド トゥルースではない
ヒューマン レビュー	スタークが高いまたはニュアンスが支配的である	ルーブリック、レビュアー、およびケイデンスが必要
ペアワイズ比較	2 つのプロンプト/モデル/アプリ バージョンが比較されている	ベースライン vs 候補の決定に適している
オンライン評価器	本番トラフィックが継続的なスコアリングを必要とする	明示的なアラート/レビュー セマンティクスとペアリング

1 つのレイヤーが他を置き換えると無視しないでください。

ステップ 5: 1 つのコンパクト LangSmith ブリーフを返す

デフォルト レスポンス形式:

## LangSmith ブリーフ
- パケット: trace-debug | eval | review | prompt-registry | propagation | audit
- アプリ形状: ...
- ランタイム: ...
- 現在の証拠: ...

## 選択した表面
- ラッパー / デコレーター / 手動トレース / データセット+実験 / レビュー キュー / プロンプト レジストリ / 伝播ヘッダー

## 必須設定
- `LANGSMITH_API_KEY`
- プロジェクト/ワークスペース/環境
- セルフホスト の場合のエンドポイント/ワークスペース オーバーライド

## 必須 ID / メタデータ
- `run_id`、`trace_id`、タグ、メタデータ フィールド、必要に応じてユーザー/セッション識別子

## 検証ステップ
- 1 つのトレース クエリ、1 つの実験比較、1 つのキュー レビュー チェック、または 1 つのプロンプト バージョン サニティ チェック

## ルートアウト
- ボトルネックが移動した場合の次の隣接スキル

コンパクトに保ちます。ポイントは、ユーザーに 1 つの最小限の次のアーティファクトを残すことであり、SDK ノートの壁ではありません。

ステップ 6: パケット固有のヒューリスティック

trace-debug の場合

• 欠落した見える化表面から開始: アプリ スパン、ツール呼び出し、取得、プロバイダー呼び出し、またはワーカー境界。
• すべてを盲目的にトレースするのではなく、ラッパーといくつかの高価値デコレーターを優先します。
• インストルメンテーションがランディングした後、チームが実行すべき最初のトレース クエリ/フィルターを返します。

eval の場合

• リスキーな変更を反映する最小限のデータセットを定義します。
• 決定論的チェックを LLM-as-judge またはヒューマン レビューから分離します。
• ベースライン/候補比較、実験命名、並行処理/コスト制限、および出荷/非出荷決定ポイントに名前を付けます。

review の場合

• フィードバック キー、スケール セマンティクス、レビュアー所有権、およびキュー ケイデンスを定義します。
• run_id / trace_id を保持して、フィードバックが後で正しいアーティファクトにアタッチされるようにします。
• 問題がより大きい場合は、より広いサポート オペレーション ワークフローを外部にルーティングします。

prompt-registry の場合

• Prompt Hub / LangSmith がプロンプトを所有するか、Git/アプリ設定が標準的なままであるかを明示的に決定します。
• プロンプト バージョンを評価または実験に接続します。レジストリを別の島として扱わないでください。
• パブリック ハブの閲覧がチームの真実のソースではなく、リファレンスのみである場合は明示的にします。

propagation の場合

• 親/子ヘッダー、メタデータ ハンドオフ ルール、およびトレース コンテキストを保持する必要があるサービスに名前を付けます。
• 分散システムの信頼性とアラートの懸念を汎用の可観測性にルーティングしたままにします。

audit の場合

• ギャップを重大度で順位付けします: カバレッジの欠如、悪いメタデータ、評価の欠如、弱いレビュー フロー、プロンプト/バージョンの曖昧さ、破損したフラッシュまたはリネージ。
• 巨大な再インストール計画ではなく、最初のラチェットを推奨します。

ステップ 7: 積極的にルートアウトする

LangSmith がメイン ボトルネックでなくなったらすぐに切り替えます:

• 汎用テレメトリ / ダッシュボード / アラート / SLO → monitoring-observability
• 既存ログの根本原因トリアージ → log-analysis
• 再現とバグ分離 → debugging
• ロールアウト / デプロイ / 環境昇格 → deployment-automation
• エクスポート メトリクス、実験、または KPI 解釈 → data-analysis
• ポリシー / 承認 / ランタイム ガードレール → 関連するセキュリティまたはポリシー スキル

例

例 1: Trace-debug パケット

プロンプト:

FastAPI RAG サービスに LangSmith を追加して、取得器の変更後に回答品質が低下した理由をデバッグできるようにします。

適切なレスポンス形状:

• trace-debug を選択
• 取得/ツールが見える化する必要がある場合は、ラッパーとターゲットされた高度なスパンを推奨
• 短寿命の実行用のプロジェクト/タグ/メタデータとフラッシュ ステップを定義
• 汎用サービス ヘルス可観測性を外部にルーティング

例 2: Eval パケット

プロンプト:

このプロンプト リライトを出荷する前に、ベースライン、候補、および 1 つのジャッジを使用して LangSmith 評価ワークフローを構築します。

適切なレスポンス形状:

• eval を選択
• データセット、評価器ミックス、実験命名、および検証ステップを定義
• 決定論的チェックを LLM-as-judge とヒューマン レビューから分離
• ロールアウト オーケストレーションをスコープ外に保つ

例 3: Review パケット

プロンプト:

既に LangSmith トレースがありますが、サポート リードは依然として AI アシスタントを信頼していません。ヒューマン スコアリング付きのレビュー ワークフローをセットアップします。

適切なレスポンス形状:

• review を選択
• フィードバック キー、ルーブリック、キュー所有権、および実行 ID 保持を定義
• 汎用プロンプト管理ではなく、レビュー ワークフロー グラウンドに回答を保つ

例 4: Prompt-registry パケット

プロンプト:

これらのプロンプトは LangSmith Prompt Hub に存在する必要がありますか、それとも Git に留まるべきですか?

適切なレスポンス形状:

• prompt-registry を選択
• プラットフォーム所有とリファレンス所有のプロンプト真実源を比較
• 選択を実験とリリース信頼度に接続
• Prompt Hub がオプションである場合は正直に留まる

例 5: Propagation パケット

プロンプト:

1 つのチャット リクエストはワーカーとツールに広がります。LangSmith 経由で 1 つのトレースを保つにはどうすればよいですか?

適切なレスポンス形状:

• propagation を選択
• 親/子 ID、メタデータ伝播、およびサービス境界を定義
• 必要に応じて汎用分散システム可観測性を外部にルーティング

ベストプラクティス

1. SDK 呼び出しではなく、パケットから開始します。
2. LangSmith をトレース/評価/レビュー基盤として扱い、本番全体制御プレーンではありません。
3. run_id、trace_id、タグ、メタデータを意図的に保持します。
4. 現在の質問に答える最小限の有用な表面を優先します。
5. 決定論的チェック、LLM ジャッジ、ヒューマン レビューを区別して保つ。
6. Prompt Hub がオプションまたはリファレンスのみである場合は明示的にします。
7. スクリプト、ワーカー、およびクロンスタイル ジョブのフラッシュ/待機動作を含めます。
8. 1 つの検証ステップと 1 つのルートアウトで終了します。

リファレンス

• references/intake-packets-and-route-outs.md
• references/modes-and-routing.md
• references/python-sdk.md
• references/typescript-sdk.md
• references/cli.md
• 公式ドキュメント: https://docs.langchain.com/langsmith
• SDK リポジトリ: https://github.com/langchain-ai/langsmith-sdk
• OpenEvals: https://github.com/langchain-ai/openevals