LangSmith のトレース機能を用いたコーディングエージェントのデバッグ方法
LangChain は、コーディングエージェントの複雑なデバッグを可能にする LangSmith のトレース機能活用ガイドを公開し、開発者の生産性向上に寄与する具体的な手法を示した。
キーポイント
トレーサビリティによる可視化
LangSmith を用いてコーディングエージェントの思考プロセスや実行ステップを詳細にトレースし、エラー発生箇所を特定可能にする手法を解説している。
具体的なデバッグワークフロー
単なるログ出力ではなく、インタラクティブなトレース分析を通じてエージェントのロジック欠陥やプロンプト設計の問題を体系的に解決する手順を示している。
実用性の高い実践ガイド
理論的な枠組みだけでなく、実際の開発現場で即座に適用可能なツール設定と分析テクニックを提供しており、エンジニアの負担軽減が期待できる。
影響分析・編集コメントを表示
影響分析
本記事は、AI エージェントの開発現場において、ブラックボックス化しがちな意思決定プロセスを可視化する標準的なアプローチを提供した点で重要です。これにより、開発者はエージェントの挙動を深く理解し、より堅牢なシステム構築が可能となり、産業全体での AI エージェントの実用化スピードが加速すると予想されます。
編集コメント
AI エージェントの普及に伴い、その挙動を解析・改善する手法は開発者にとって不可欠なスキルとなっています。本記事は、単なるツールの紹介に留まらず、実際のデバッグワークフローを体系化した貴重な実践ガイドです。
コーディングエージェントはブラックボックスだ。その正体を暴く方法

先週、レポート用エンドポイントの CSV エクスポート機能を実装しようとした際、コーディングエージェントがサブエージェントを分岐させてページネーション処理を担当させました。しかし、作成されたのは意図しないものばかりでした。データはカーソルベースで管理されているのに、エージェントはオフセット方式でのページングを実装し続けていたのです。
指摘して指示を書き換え、再実行しても、結果は微妙に異なるだけで一向に改善しません。ターミナルには自信満々ながら間違った回答が溢れ、時間とトークン消費するだけでした。
結局、私は諦めてゼロから作り直しました。
しかし、実はこうすればよかったのです。トレース(Trace)を見ていれば、問題は即座に見つかったはずです。親エージェントがサブエージェントに渡した際、コードベースの別の場所にある古いヘルパー関数を指し示していたのです。その関数はオフセット方式でページングを行うものでしたが、現在は非推奨となっています。要件を改めて説明するのではなく、単に「その非推奨ヘルパーは使わない」と強調すればよかったのです。
コーディングエージェントを使ったことがある方なら、似たようなもどかしさを経験したことがあるはずです。そこで登場するのが LangSmith です。エージェントの意思決定プロセスや中間ステップ、そして出力結果を容易に可視化し、観察できるようにするためのツールです。
見えないものをデバッグすることはできない
コーディングエージェントは、現在ほとんどの開発者のエンジニアリングスタックに組み込まれています。コードの作成、ツールの呼び出し、長時間のセッション実行など、その役割は多岐にわたります。開発者はそれぞれのタスクに合わせて最適なエージェントを選択し続けるでしょう。例えば、シェル操作には Claude、インライン編集には Cursor、PR レビューには Copilot、ワークフロー作成には Codex といった具合です。しかし、各エージェントが記録する「何が起こったか」の形式はバラバラです。
一部のツールはフックを公開しており、OpenTelemetry を出力するものもあれば、プラグインに依存しているものもあります。この断片化により、ツールを切り替えるたびにデバッグワークフローが変わってしまいます。Codex と Cursor で行われる「ツールの呼び出し」が同じ種類の作業であっても、各エージェントが記録する構造やメタデータ、用語は異なります。「今週どのセッションが失敗し、その理由は何か」といった単純な質問に答える際にも、複数の場所を確認し、異なるイベント形式に対応した複数の思考モデルを頭の中で切り替える必要が生じます。
LangSmith は、主要なコーディングエージェントすべてに対して単一の観測性レイヤーを提供します。Claude Code、Codex、Cursor、GitHub Copilot Chat、Pi、OpenCode、そして DeepAgents Code(dcode)のトレースをサポートしています。これらのツールからのセッションデータは、LangSmith 上で標準化された構造を持つ「トレース」として蓄積されます。この構造を用いて、データの閲覧、クエリ、共有が可能になります。エージェントワークフローを追跡し、サブエージェントの分岐(ファンアウト)を確認し、モデル呼び出しを精査することもできます。また、機密情報を隠蔽した状態で結果をチームと共有することも可能です。
トレースされたセッションの実際の様子
設定が完了すると、LangSmith 上でのセッション表示は、本番環境で実行されたエージェントのランと同じようになります。トレースには以下のような情報が含まれます。
- ユーザーとアシスタントのやり取り
- モデル呼び出し(入力・出力・キャッシュ・トークン数・コスト)
- ツール呼び出し
- シェルコマンドの実行
- MCP の活動状況
- サブエージェントの起動
- エラー発生とリトライ履歴
- 実行時間やメタデータ


内部の仕組みを覗いてみる
デバッグの観点から、この可視性は極めて重要です。最終的な差分(diff)だけをレビューするのではなく、セッション全体を再構築して失敗箇所を特定し、その情報を今後の実行に活かすことができます。
実際には以下のような形で確認できます。
- 再構築:
thread_idでフィルタリングすれば、一連の実行順序をすべて見ることができます。ユーザーからのリクエストからアシスタントの応答、モデルやツールの呼び出し、サブエージェントの起動、リトライ、実行時間、トークン数、コストまで把握可能です。

- デバッグ: 気になる箇所にズームインして詳細を確認します。ここではテスト実行の失敗事例が該当します。確認できるのは、「テスト失敗 → エージェントがアサーションを読み込む → ファイルを編集(再実行ではない) → テスト成功」という一連の流れです。
差分情報だけでは最終的に緑色のチェックマークが表示されるだけですが、トレースを使えばそこに至るまでの近道や経路をすべて見ることができます。
- テストに失敗した

- 機能の再評価を行うべきところを、テストコードを編集してしまっていた

改善策:この失敗を、エージェントが今後守るべきルールとして定義する。

こうすることで、各セッションから得た教訓をすべてのケースに適用できます。例えば「スキル」は複数のエージェント間で共有可能です。失敗したセッションを保存して評価(evals)に活用すれば、修正が本当に機能していることを証明できるだけでなく、将来同じミスを繰り返さないように検知することも可能になります。単に悪い実行結果を理解するだけでなく、重要なのは「次回の実行で同様の失敗が起きないようにする」ことです。
セッションの再生以外にも、チームはトレースを用いて異なるエージェント間の動作比較(例:同じワークフローにおける Claude Code と OpenAI Codex の比較)、見落としがちなサブエージェントの展開状況の特定、そしてレビューが必要なセッションの抽出を行います。また、レイテンシやコスト、トークン使用量でフィルタリングすることは、コストガバナンス を始めるための第一歩でもあります。
コーディングエージェントのデバッグワークフローを統一する
単一のコーディングエージェントのログを確認すれば、その 1 回の実行に関するデバッグは可能です。しかし、複数のコーディングエージェントを導入すると、デバッグの手順が最初からやり直しになります。なぜなら、各プロバイダーが提供するフックや出力されるペイロードの形式が異なるからです。
LangSmith は、こうしたすべてのセッションを単一の共通トレーススキーマにマッピングします。Claude Code のセッションも、Cursor のセッションも、OpenCode のセッションも、コアとなるフィールドはすべて同じです。これにより、検索、フィルタリング、比較、詳細な確認を、どのエージェントでも一貫した方法で行うことができます。
この仕組みによって、個別のプロンプト修正にとどまらない段階へと進めます。すべてのエージェントの実行結果が同じ場所に集約されることで、運用 fleet の改善を効率的に行えるようになります。「どのワークフローをエージェントが得意としているか」「失敗が繰り返されている箇所は哪里か」「どのスキルや指示の更新が必要か」、そして「変更が実際にパフォーマンス向上につながっているかどうか」を明確に把握できます。
エージェントが実際に何をしているか可視化する
エージェントエンジニアリングプラットフォームである LangSmith は、開発者がエージェントのすべての意思決定をデバッグし、評価結果の変更を確認し、ワンクリックでデプロイできるように支援します。
原文を表示
Your coding agents are a black box. Here's how to crack them open.

Last week, I set out to build a CSV export for a reporting endpoint, and my coding agent split off a subagent to handle pagination. But it kept building the wrong thing. It’d page by offset when our data is cursor-based. I’d point it out, edit my instructions, re-run, and it’d come back in a slightly different way. I burnt time, tokens, and learned nothing from the confident but wrong answers swimming in my terminal.
Eventually I gave up and started fresh.
But here’s the thing: if I’d looked at the trace, I would’ve seen the problem right away. During the handoff, the parent pointed the subagent at an old helper from another part of the codebase - one that paged by offset. Rather than re-explaining requirements, I just needed to emphasize the deprecated helper.
If you’ve worked with coding agents, you’ve experienced similar frustration too. This is why we make your agent’s decisions, intermediary steps, and outputs, easy to observe with LangSmith.
You can't debug what you can’t see
Coding agents are now part of the engineering stack for most developers. They write code, call tools, and work longer sessions. And developers will keep choosing different agents in order to fit the task in front in front of them. You might have Claude running a shell, Cursor handling inline edits, Copilot reviewing a PR, and Codex drafting workflows. And each agent has its own way of recording what happened. Some expose hooks. Some emit OpenTelemetry. Some rely on plugins.
This fragmentation means your debugging workflow changes every time you switch tools. A tool call in Codex and a tool call in Cursor may represent the same kind of work, but each agent records it with different structure, metadata, and terminology. If you want to answer a simple question across all of them — like which sessions failed this week and why — you end up checking multiple places, with multiple mental models for the multiple event formats.
LangSmith gives teams one observability layer across all leading coding agents. We support tracing across Claude Code, Codex, Cursor, GitHub Copilot Chat, Pi, OpenCode, and DeepAgents Code (dcode). Sessions from these tools land in LangSmith as traces, using a standardized structure you can inspect, query, and share. You can trace agentic workflows, follow subagent fanouts, inspect model calls, and share the results with secrets redacted.
What a traced session looks like
Once configured, your session appears in LangSmith the same way any production agent run would. A trace can include:
- User and assistant turns
- Model calls with inputs, outputs, caches, tokens, and costs
- Tool calls
- Shell commands
- MCP activity
- Subagent invocations
- Errors and retries
- Timing and metadata


Looking under the hood
From a debugging standpoint, this visibility is crucial. Instead of reviewing only the final diff, you can reconstruct the session, find the failures, and leverage that information for future runs.
Here's what that actually looks like:
- Reconstruct: Filter by thread_id to see the whole run in order.User request, assistant turns, model / tool calls, subagents, retries, timing, tokens, and cost.

Debug: Zoom into areas of interest. Here, it's a failed test run. We see the sequence:**test fail → agent reads assertion → agent edits file (not a re-run) → test passes.
Diffs only shows the green check at the end - traces show you the shortcuts that got there.
- test failed

- test edited instead of re-assessing functionality

Improve:** Turn the mistake into a rule for the agent to follow.

This way, lessons you learn from each session apply everywhere. For example, Skills work across agents. You can save the failing sessions, use them for evals [learn more], prove that your fixes actually hold - and catch them if they ever regress. More than just understanding a bad run, the goal is always to make sure the next runs cannot fail the same way again.
Beyond session replay, teams use traces to compare behavior across agents (claude-code vs. openai-codex on the same workflow), spot invisible subagent fanouts, and identify sessions that need review. Filtering by latency, cost, or token usage is also the starting point for cost governance.
One debugging workflow across every coding agent
A single coding agent’s logs can help debug one run. But as soon as you adopt more than one coding agent, every debugging workflow starts over because every provider exposes different hooks, and emits differently shaped payloads.
LangSmith maps all those sessions into a singular shared trace schema. A Claude Code session, a Cursor session, and an OpenCode session all carry the same core fields, so you can search, filter, compare, and inspect them the same way. Read more about the trace metadata contract.
That moves us beyond individual prompt fixes. Once every agent’s run lands in the same place, we can efficiently improve our fleet: which workflows agents handle well, where failures repeat, which skills or instructions need updates, and whether changes actually improve performance.
See what your agent is really doing
LangSmith, our agent engineering platform, helps developers debug every agent decision, eval changes, and deploy in one click.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み