langsmith-fetch
作成者 ComposioHQlangsmith-fetch は、LangChain と LangGraph エージェント向けのデバッグ skill です。CLI のインストール、LangSmith 認証情報の設定、直近の trace 取得をアシスタントに案内し、trace の根拠に基づいてエラー、ツール呼び出し、メモリ動作、レイテンシ、トークン使用量を分析できるようにします。
この skill の評価は 78/100 で、LangChain または LangGraph と併せて LangSmith をすでに利用しているディレクトリ利用者には有力な掲載候補です。明確な起動条件、セットアップ手順、実践的な trace デバッグのワークフローを備えています。一方で、導入は外部 CLI に依存し、リポジトリ上の根拠はドキュメントのみの skill ファイル 1 点に限られます。
- トリガーしやすい設計です。frontmatter と “When to Use” セクションが、エラー、ツール呼び出し、メモリ操作、トークン使用量といった一般的なデバッグ依頼を、LangSmith の trace 取得ユースケースにうまく対応させています。
- 運用で使いやすい内容です。`pip install langsmith-fetch` による前提セットアップ、必要な環境変数、確認コマンド、直近の trace 取得などの具体的な CLI 実行例が含まれています。
- LangChain/LangGraph のデバッグでエージェントに活用しやすい構成です。ワークフローが、何を実行し、何を報告すべきかをエージェントに示すため、汎用的なデバッグプロンプトよりも手探りが少なくなります。
- 外部の `langsmith-fetch` CLI に加え、`LANGSMITH_API_KEY` と `LANGSMITH_PROJECT` が必要です。この skill 自体には、同梱スクリプトやサポートファイルは含まれていません。
- リポジトリ上で確認できるのは単一の `SKILL.md` のみです。そのため、この skill フォルダ内で実装、サンプル、テストを確認するのではなく、記載された CLI コマンドを信頼して利用する必要があります。
langsmith-fetch skill の概要
langsmith-fetch でできること
langsmith-fetch は、LangSmith Studio のトレースをもとに LangChain / LangGraph アプリケーションを詳しく調査するためのデバッグ skill です。エージェントが失敗した理由をアシスタントに推測させるのではなく、langsmith-fetch CLI で直近の LangSmith トレースを取得し、run、エラー、tool call、メモリの動き、実行時間、トークン使用量を確認したうえで、何が起きた可能性が高いかを整理できるようにします。
LangChain と LangGraph のデバッグに向いているケース
langsmith-fetch skill が特に役立つのは、すでに LangSmith tracing を有効にしてエージェントを動かしており、開発中の調査やインシデントレビューをすばやく進めたい場合です。「なぜこのエージェントは失敗したのか」「どのツールが呼ばれたのか」「なぜレイテンシが高いのか」「メモリは正しく更新されたのか」「直近数分で何が起きたのか」といった問いに向いています。
一方で、アプリが LangSmith にトレースを送っていない場合、対象プロジェクトへのアクセス権がない場合、あるいはトレースデータの外側でコードレベルのプロファイリングが必要な場合には、あまり有効ではありません。
主な差別化ポイント: 証拠にもとづくエージェント分析
通常のプロンプトでも原因候補を説明することはできますが、langsmith-fetch はアシスタントの分析を、直近のトレース、run status、実行フロー、tool invocation、エラー、タイミング、トークン使用量といった観測可能な証拠に寄せます。これにより、静的なコードだけではなく実行時の状態に依存するエージェントの失敗を、より実務で使える形で切り分けやすくなります。
langsmith-fetch skill の使い方
langsmith-fetch のインストールとセットアップ
この skill に頼る前に、CLI をインストールしておきます。
pip install langsmith-fetch
CLI が問い合わせる LangSmith の認証情報とプロジェクトを設定します。
export LANGSMITH_API_KEY="your_langsmith_api_key"
export LANGSMITH_PROJECT="your_project_name"
アシスタントやターミナルコマンドを実行するシェルで、両方の値が参照できることを確認します。
echo $LANGSMITH_API_KEY
echo $LANGSMITH_PROJECT
これらの変数が未設定だったり、誤ったプロジェクトを指していたりすると、skill のデバッグ結果が空になったり、誤解を招く内容になったりする可能性があります。
skill に渡すべき入力
最良の結果を得るには、デバッグ対象、時間範囲、症状をアシスタントに伝えます。弱いプロンプトは「debug my agent」です。より良いプロンプトは次のようなものです。
Use langsmith-fetch to inspect the last 15 minutes of traces in my LangSmith project. Focus on failed LangGraph runs, tool call errors, memory writes, latency spikes, and token usage. Summarize the likely root cause and list the trace evidence you used.
含めると役立つ情報は次のとおりです。
- おおよその失敗時刻、または “last N minutes”
- agent、graph、chain、endpoint の名前
- 期待される動作と実際の動作の違い
- エラー、ツール、メモリ、パフォーマンス、コストのどれを優先して見るべきか
- インシデントに関連するユーザー入力や run ID
実践的な langsmith-fetch 利用フロー
最初によく使うコマンドは次のとおりです。
langsmith-fetch traces --last-n-minutes 5 --limit 5 --format pretty
直近の失敗をすばやくトリアージする用途に向いています。アシスタントには次の点を報告させるとよいでしょう。
- 見つかったトレースの件数
- 失敗した、または異常に見えるトレース
- 関連する tool call と、その入力・出力
- エージェントが使っている場合は、メモリや state の操作
- レイテンシとトークン使用量の傾向
- 証拠つきの簡潔な root cause 仮説
さらに深く調べる場合は、時間範囲を広げるか、取得件数の上限を増やします。ノイズの多いプロジェクトでは、プロジェクトの文脈、時間帯、run name、具体的な失敗症状でクエリを絞り込みます。
最初に読むべきリポジトリファイル
上流の skill は主に SKILL.md にまとまっており、リポジトリプレビュー上では主要な補助フォルダである scripts/、resources/、references/ はありません。まず SKILL.md を読み、想定されているトリガーフレーズ、前提条件、ワークフローパターンを把握してください。導入時に重要なのは、リポジトリ構成の複雑さではなく、あなたの LangSmith 環境と CLI アクセスがすでに設定済みかどうかです。
langsmith-fetch skill FAQ
langsmith-fetch は LangGraph 専用ですか？
いいえ。この skill は LangChain と LangGraph の両方のエージェントデバッグを想定しています。特に graph 型の実行では、トレースから node flow、tool call、state transition、期待から外れた箇所を確認できるため有用です。
ログを渡して AI にデバッグを頼むより何が良いですか？
問題が LangSmith のトレース上に表れている場合、langsmith-fetch skill のほうが有効です。貼り付けられたログや推測に頼るのではなく、実行データを取得するための具体的なワークフローをアシスタントに与えられます。もちろん結果は批判的に確認する必要がありますが、分析の出発点が汎用的なデバッグ助言ではなく、実際に観測された run になります。
初心者でも LangSmith の知識なしで使えますか？
誰かがすでに LangSmith tracing を有効化し、正しい LANGSMITH_API_KEY と LANGSMITH_PROJECT を用意しているなら、初心者でもこの skill を使えます。セットアップがない場合、主な障害はプロンプトの書き方ではなく、環境へのアクセスです。trace、run、tool call、project の基本を知っていると、出力を理解しやすくなります。
langsmith-fetch を使わないほうがよい場面は？
LangSmith でトレースされていないアプリケーション、フロントエンドだけの挙動のデバッグ、トレースに現れていないデータベース問題、アシスタント実行環境に LangSmith 認証情報を渡すべきでないプライベートプロジェクトには使わないでください。また、すでに正確な run ID があり、スクリーンショットやチームの注釈を見ながら LangSmith UI で手動確認する必要がある場合も避けたほうがよいでしょう。
langsmith-fetch skill を改善する方法
スコープを絞って langsmith-fetch プロンプトの精度を上げる
品質を大きく上げるには、質問の範囲を狭めるのが最も効果的です。広いレビューを依頼するのではなく、必要な判断を具体的に指定します。
Check recent traces for failed tool calls in the payment support agent. Determine whether failures come from tool input formatting, tool timeout, or model planning. Include trace IDs or run names if available.
こうすると、アシスタントが症状と原因を切り分けやすくなり、すべてのトレースをざっくり要約するだけの出力を避けられます。
症状だけでなく、見るべき証拠を指定する
どの証拠が重要かを skill に伝えます。信頼性のデバッグでは、エラー、リトライ、例外メッセージ、最後に成功したステップを確認するよう依頼します。パフォーマンスのデバッグでは、遅い run、時間のかかった tool call、モデルのレイテンシ、トークン使用量を見ます。メモリのデバッグでは、read/write 操作、欠落したコンテキスト、想定外の state update、後続ステップが保存済み情報を使ったかどうかを確認させます。
よくある失敗パターンに注意する
よくある問題には、誤った LangSmith プロジェクトを問い合わせている、時間範囲が短すぎる、取得トレース数が少なすぎる、1件の失敗 run を代表例として扱ってしまう、といったものがあります。結果が空に見える場合は、環境変数を確認し、時間範囲を広げてください。結果にノイズが多い場合は、agent name、時間、症状でスコープを狭めます。分析が推測っぽく聞こえる場合は、アシスタントに “trace evidence” と “hypothesis” を分けて書くよう依頼します。
最初の出力をもとに反復する
最初に langsmith-fetch を使ったあとは、トレース分析をエンジニアリング上のアクションに変える追加質問をします。
- “Which code path should I inspect first?”
- “What prompt or tool schema change would prevent this?”
- “Compare failed and successful traces in the same window.”
- “List the minimal reproduction from the trace.”
- “What metric should I monitor to catch this earlier?”
これにより、この skill を単なるトレースビューアではなく、LangChain / LangGraph エージェントの実践的なデバッグループとして活用できます。