LangSmith AI Search、従来のトレースフィルターが見逃すエージェント障害を発見
LangSmithは、通常のフィルターでは見逃されるエージェント障害を見つける新たな手段として、AI Searchのパブリックベータを公開した。この機能は振る舞いを自然言語で記述した内容を受け取り、記録済みのエージェント対話から一致するトレースを検索する。
開発者は、ユーザーが不満を募らせたケース、エージェントがタスクを完了していないのに成功したと主張したケース、個人情報が応答内に現れたケースなどを尋ねられる。こうした問いは、既知のタグや完全一致のフレーズではなく、意味と時系列に依存する。
この違いこそ、LangSmith AI Searchをめぐる本質的な緊張を生む。エージェントの可観測性は、チームがどの障害を重視すべきか把握する前に設定された構造化フィルター、全文検索、評価器に大きく依存してきた。LangSmithは、問いが生じた時点でモデルが未知の振る舞いを調査できると見込んでいる。
一方で、このアプローチは居心地の悪い問いも突きつける。別のモデルが、本番環境の会話のうちどれが主観的な記述に合致するかを判断するなら、チームはそのモデルが何を読み、何を除外し、何を誤分類するのかを理解しなければならない。
LangSmith AI Search、トレース探索に振る舞いベースのクエリを追加
このリリースは、トレース調査をデータベースクエリの問題から解釈の問題へと変える。
LangChainは2026年10月13日、パブリックベータを発表した。Google Cloudの米国、欧州、アジア太平洋地域にあるLangSmith Cloudで利用できる。他のメンバーが利用する前に、組織管理者が有効化する必要がある。
LangSmithではすでに、ステータス、レイテンシー、タグ、メタデータ、コスト、フィードバックといったフィールドでトレースをフィルタリングできる。全文検索では、トレースの入力、出力、メタデータ、エラー内に含まれる語句も照合できる。
これらのツールは、調査担当者が対象を特定するフィールドやフレーズを把握している場合に有効だ。ステータスフィルターはエラーを見つけられ、テキストクエリは「refund」を含む会話を特定できる。しかし、役に立たない回答を受けた後にユーザーが黙って離脱したかどうかを、どちらも確実には判断できない。
LangSmith AI Searchは、代わりに振る舞いの記述を受け付ける。同社のbehavioral trace searchの例には、不満を示すユーザー、内部実装の詳細を露出するエージェント、割り当てられた作業を完了できないエージェントが含まれる。
この機能は、スレッド、トレース、個別の実行をまたいで機能する。トレースは1件のリクエストとそのネストされた操作を記録し、スレッドは同じ会話からの複数のトレースを結び付ける。
チームは自然言語クエリと既存の構造化フィルターを組み合わせられる。まずエラーのある本番トレースに結果を絞り込み、その後、オンボーディング中にユーザーが混乱した会話を尋ねることができる。
この組み合わせは重要だ。モデルが残った会話を調べる前に、従来のフィルターで検索範囲を縮小できる。また、解釈を必要とすべきでない属性については、決定論的な制御を維持できる。
結果には信頼度スコアが付く。一致結果を開くと、LangSmithのトラジェクトリービューに移動し、一致に影響した利用可能なメッセージが強調表示される。
トラジェクトリーは、人間のメッセージ、エージェントの応答、ツール呼び出し、ツール結果を正規化したシーケンスだ。連続するモデル呼び出しに含まれる会話履歴を繰り返すのではなく、セッションを一度だけ表示する。
これは既存フィルターを使いやすい構文で覆っただけのものではない。LangSmithによると、判断モデルは各候補トラジェクトリーを読み、要求された振る舞いが発生したかを評価する。
違いは、「エージェントはタスクを完了したと言ったが、実際には完了していなかった」といった要求で明確になる。成功したトレースと失敗したトレースには、ほぼ同一のトピック、ツール、語彙が含まれる場合がある。
テキストを数値ベクトルとして表す埋め込みは、同じタスクを扱っているため、こうした会話を近くに配置する可能性がある。これに対し、振る舞いの分類では、主張とトレース全体に記録された行動を比較しなければならない。
そのため同社は、LLM-as-a-judgeのパターンをインタラクティブなトレース発見に直接導入した。エンジニアは、調査を始める前にすべての評価器を定義する必要がなくなる。
この変化により、探索的分析は速くなる。ただし、すべての結果が権威あるものになるわけではない。
エージェントのトレース検索がデータ問題になった理由
長時間にわたるエージェントセッションには貴重な証拠が含まれるが、その規模と反復により手動レビューはますます現実的でなくなっている。
従来のアプリケーション監視は、予測可能なシグナルに焦点を当てる。エンジニアは、エラーコード、遅いリクエスト、失敗したデータベース呼び出し、異常なリソース消費を検索する。これらのシグナルは通常、構造化フィールドに収まる。
AIエージェントは異なる障害面を生み出す。エージェントは、要求を誤解したり、不適切なツールを呼び出したり、達成した内容を誇張したりしながらも、技術的には成功した応答を返すことがある。
生成されるテレメトリーも異例なほど高密度だ。1つのエージェントタスクには、ユーザーメッセージ、モデル出力、取得した文書、シェルコマンド、ツール応答、再試行、他のエージェントへの引き継ぎが含まれる場合がある。
LangChainは、オープンソースのコーディングエージェントであるOpen SWEからランダムに選んだ150件の会話を調査した。同社によると、そのうち複数は100万トークンを超えていた。
会話の中央値は約72,000トークンだった。ユーザーメッセージと最終的なエージェント返信は約2,000トークンにすぎず、約85パーセントはツール出力で構成されていた。
これらの数値はLangChainのサンプルに基づくものであり、独立した業界ベンチマークではない。それでも、すべての生イベントを検索するとコンテキストと推論の両方のコストが生じる理由を示している。
エージェントは、新しいモデル呼び出しのたびに会話履歴全体を送ることが多い。そのため、単純なトレース表現では同じ過去のメッセージが繰り返し保存される。
LangSmithはトラジェクトリーによってこの反復に対処する。同社のtrace data layerは、サポート対象のトレース形式を、データ到着時に共通の表現へ変換する。
対象形式には、LangChain、LangGraph、OpenAIおよびAnthropic SDK、Vercel AI SDK、OpenTelemetryを通じて生成されたトレースが含まれる。正規化により、検索システムは一貫したシーケンスを調査できる。
これは競争上の重要性も高める。可観測性ベンダーは、単なる保存とフィルタリングではなく、トレースレベルの評価をますます提供するようになっている。
例えばDatadogは、トレース内のすべてのスパンをLLM判定プロンプトに入れるtrace-level evaluationsを文書化している。こうした評価では、目標達成、ツールの順序、会話品質を分類できる。
Arize Phoenixも、トレーシング、アノテーション、評価、データセット、実験をopen-source tracing workflowで組み合わせている。その評価器は本番トレースを採点し、選択した実行を後のテスト用データセットに変換できる。
主な違いはタイミングとワークフローにある。評価器は通常、チームが定義し、テストし、繰り返し適用する基準を表す。LangSmith AI Searchは、調査中に浮かび上がる問いを対象にする。
キャンセル要求が急増したサポートエージェントを考えてみよう。構造化ダッシュボードでは、レイテンシーは安定し、明示的なエラーも少なく見えるかもしれない。全文検索では「cancel」という語を特定できても、その背景にある理由は分からない。
代わりにプロダクトマネージャーは、矛盾する回答を受け取った後にキャンセルを試みたユーザーを検索できる。この記述は、意図、時系列、知覚された品質を組み合わせている。
一致結果が有用であれば、チームはそれをレビューし、例をデータセットに追加し、永続的な評価器を構築できる。検索は、より正式な品質プロセスのための探索的フロントエンドとなる。
このワークフローは、可観測性プラットフォームに対し、発見と評価を結び付けるよう求める。顧客が内部に隠れた振る舞いを取り出せないなら、詳細なトレースを保存するだけでは不十分だ。
また、トレースデータを利用できるチームも変わる。プロダクトマネージャー、安全性レビュー担当者、サポート責任者は、プラットフォーム固有のクエリ言語を先に学ばなくても問題を記述できる。
技術的なクエリ層は依然として必要だ。自然言語は、最初の調査ステップをビジネス上の問題を認識する人々に近づけるだけである。
LangSmith AI Searchはいかにしてすべてを読まずにトレースを読むのか
LangSmithは会話上の証拠を優先して検索コストを抑えるが、その圧縮によって可視のまま残る障害が決まる。
ユーザーがAI Searchの記述を送信すると、まず既存のフィルターが候補セットを絞り込む。その後、SmithDBがトラジェクトリーを準備し、判断モデルが並行して確認する。
システムが一致を特定するにつれ、結果はインターフェースにストリーミング表示される。ユーザーは候補セット全体の処理完了を待つ必要がない。
中心となる仕組みは、各トラジェクトリーに対する8,000トークンのコンテキスト予算だ。LangSmithは、記録済みのすべてのトークンを送るのではなく、固定された優先順位でこの予算を埋める。
ユーザーメッセージとエージェントの直接返信が最優先される。中間のモデルメッセージ、ツール呼び出し、ツール結果、システムメッセージが残りの領域を埋める。
次のメッセージが収まらない場合、LangSmithはそれを切り詰める。予算が満たされると、それ以降のコンテンツはモデルの視野から外れる。
この選択により、多くの会話検索が実用的になる。不満、拒否、混乱、キャンセルの意図、裏付けのない約束は、しばしば表示対象の対話に現れる。
同時に、予測可能な死角も生まれる。一部の障害は、ツール出力や中間実行ステップの内部にしか存在しない。
エージェントは認可エラーに遭遇してもそれを無視し、ユーザーにはタスクが成功したと伝えるかもしれない。表示される返信には虚偽の主張が含まれるが、決定的な証拠はツール結果の内部にある。
先行する優先度の高いコンテンツがトークン予算を使い切ると、検索モデルはその証拠を見逃す可能性がある。LangChainはこの制限を認め、クエリ依存のコンテキスト選択を検討しているとしている。
このような選択では、問いに応じて証拠の順序が変わる。無視されたツールエラーに関するクエリではツール応答を優先し、ユーザー感情に関するクエリでは会話を重視すべきだろう。
現行リリースでは、代わりに1つの一般的な順序を使用している。ベータ版としては理解できるが、チームは得られるカバレッジをクエリ依存のものとして扱うべきだ。
この仕組みは、LangSmithがベクトル検索だけに依存しなかった理由も説明する。ベクトル検索は、あるトピックに関する資料を見つけることが目的の場合に有効に機能する。
請求に関する会話は、埋め込み空間では他の請求に関する会話の近くに位置する可能性が高い。しかし、成功した請求対応と失敗した請求対応は、意味的に類似したままであり得る。
振る舞いベースのクエリには、何が起きたのかについての判断が必要になる。判断モデルは、エージェントが要求されたタスクを完了したかどうかといった限定的な命題に照らしてトラジェクトリーを評価する。
このモデルベースのアプローチは表現力を高めるが、1つの検索上の不確実性を別の不確実性へ置き換える。システムは今や、曖昧な言語に対するモデルの解釈に依存する。
「ユーザーの不満」には、直接的な苦情、繰り返される質問、皮肉、唐突な離脱、丁寧な拒絶が含まれ得る。境界的なケースについては、レビュー担当者ごとに判断が分かれる可能性がある。
信頼度スコアは結果の順位付けに役立つが、事実の確定にはならない。高いモデルスコアであっても、振る舞いの定義、利用可能なコンテキスト、判定モデルを反映したものにすぎない。
したがって、最も堅牢な運用パターンには人によるレビューが含まれる。チームはハイライトされた証拠を確認し、弱い一致を修正し、結果セットを代表的なものとして扱う前に記述を洗練できる。
繰り返し発生するリスクについては、レビュー済みの事例を評価データセットに変換できる。その後、LangSmithの既存のオンライン評価器で、定義済みの基準を将来のトレースに適用できる。
これにより、探索とモニタリングが分離される。AI Searchはチームによるパターンの発見を支援し、評価器は定義が安定した後、そのパターンを一貫して測定する。
この分離は、特にセキュリティとコンプライアンスで重要だ。個人情報を対象とした自然言語検索は疑わしいトレースを見つけ出せるが、決定論的スキャナーや正式な統制の代替にはならない。
モデルの判断は調査の対象を広げられる。ただし、重大な影響を伴う判断における唯一の執行レイヤーにしてはならない。
主な競合は事前定義された評価
LangSmithは、本番トラフィックが問題を露呈する前に、チームが重要な失敗をすべて把握していなければならないという前提に挑戦している。
行動検索以前、チームが問題のあるトレースを見つける方法は概して3つあった。テキスト検索、既知の属性によるフィルタリング、または選択したトラフィックに対する評価器の実行である。
全文検索は、速度と再現性をもたらす。関連する証拠に特徴的なフレーズ、識別子、エラーメッセージ、製品名が含まれる場合に有用だ。
構造化フィルタリングは、さらに精密である。チームは、失敗したステータスコード、長いレイテンシー、高コストのモデル呼び出し、特定のツール、低いフィードバックスコアを持つトレースを切り分けられる。
事前定義された評価器は意味を扱う。LLM judgeは、回答が有用か、根拠に基づいているか、安全か、完全かを判断し、その結果を各トレースに付与できる。
評価器の手法は、チームがすでに失敗カテゴリを理解している場合に有効だ。予期しないインシデントの際には、利便性が低下する。
誰かがルーブリックを定義し、必要なトレースフィールドを選び、サンプリングルールを決め、評価器をテストし、過去または将来のトラフィックに適用しなければならない。その準備は持続的な測定を生むが、オープンエンドな調査を遅らせる。
LangSmith AI Searchは、その作業をクエリ時に入力する記述へと圧縮する。疑念から候補となる証拠へ、より速く到達できるようにする。
この機能は評価器を不要にするものではない。その前段に発見のステージを設けるものだ。
チームは、理由を把握しないままサポートのエスカレーション増加に気付くかもしれない。アナリストは、エージェントが解決済みだと主張した後に、要求を繰り返したユーザーを検索できる。
レビュー担当者は、エージェントがアカウント閉鎖をサブスクリプション解約として繰り返し解釈していたことを発見するかもしれない。そのパターンは、テスト済みのルーブリックを持つ名前付き評価器へと変換できる。
この一連の流れは、今回のローンチで最も重要な部分だ。定性的な探索、データセット構築、評価、本番モニタリングをつなぐ。
また、LangSmithの直接的な競合の外にも圧力を生む。製品に関する問いが可観測性ダッシュボードの範囲を超えるため、社内分析チームはしばしばトレースをデータウェアハウス、ノートブック、またはカスタム検索システムへエクスポートする。
行動ベースのトレース検索は、そうした分析の多くを可観測性プラットフォーム内にとどめられる可能性がある。製品チームとエンジニアリングチームは、同一の基盤となる実行記録から作業できるようになる。
このアプローチは、エンタープライズのナレッジシステムにおけるキーワード検索からモデル支援検索への広範な移行に似ている。いずれも、ユーザーがメタデータとして記録していない意味を見つけようとするものだ。
違いは、エージェントのトレースにはドキュメントだけでなくアクションが含まれる点にある。有用な結果を得るには、メッセージとツールをまたいで何が起きたかを再構成する必要がある。
エンジニアリングチームにとっては、トレースの整理が製品品質のインフラの一部になる。同じ原則は、断片化した技術記録から検索可能なナレッジベースを構築する際にも当てはまる。
優位に立つのは、調査の摩擦を減らしながら証拠を保持するシステムだ。自然言語によるアクセスは役立つが、レビュー可能性も同じくらい重要である。
LangSmithは、trajectory view内で一致したメッセージをハイライトする。この設計により、レビュー担当者はモデルの分類から記録された会話までたどることができる。
ただし、ドキュメントでは、すべての一致をハイライトできるわけではないとされている。繰り返し出現するテキストやtrajectory viewに存在しないメッセージは、証拠の特定を妨げる可能性がある。
したがって、結果には、その理由をすべて表示せずに信頼度スコアが付く場合がある。チームは、モデルの信頼度と監査可能な証拠を区別すべきだ。
競合各社は、自社の評価器インターフェースをより対話的にすることで対応できる。アドホックなjudge、保存可能な行動クエリ、自動データセット生成を提供することも可能だ。
製品競争は、単に誰が最初に自然言語検索を提供するかではない。不確実な発見を、最小限の欠落で反復可能なテストへ変えられるのは誰かという競争である。
コンテキスト、プライバシー、再現性がベータ版の限界を定める
この機能の有用性は、チームが除外されるデータと新たに生じるガバナンス上の義務を理解しているかどうかにかかっている。
LangSmithのフィルタに関するドキュメントは、いくつかの製品上の制約を示している。現時点では、AI Searchの記述をビューとして保存したり、コピーしたページリンクに保持したりすることはできない。
検索は最近使用したフィルタの履歴にも表示されない。AI Searchクエリが有効な間は、統計パネルが利用できなくなる。
これらの制約は再現性に影響する。インシデントを調査するエンジニアは、保存済みの行動クエリを別のレビュー担当者に送るだけで、同一のワークフローを期待することはできない。
チームは文言を別の場所に記録できるが、それには手作業のプロセスが加わる。わずかな表現の変更がモデルの分類に影響し得るため、これは重要でもある。
システムはワークスペースレベルでレート制限を適用する。LangChainは参照されたドキュメント内で閾値を公開していないため、チームは頻繁な自動調査への適性をまだ判断できない。
より重要な制約はtrajectoryそのものに由来する。AI Searchはメインエージェントの会話を読み取るが、サブエージェント、ミドルウェア、コンパクションメッセージの内容は読み取らない。
そのため、マルチエージェントのワークフローでは、決定的な挙動が検索可能な表現の外に隠れる可能性がある。親エージェントは成功を報告する一方、サブエージェントが実際の失敗を記録しているかもしれない。
また、システムは自然言語による記述から実行ステータス、タグ、メタデータ、トレース構造を推論できない。これらの属性には、従来のフィルタを適用する必要がある。
この分担はチームのプレイブックに明記すべきだ。行動検索はtrajectory内の意味を扱い、構造化フィルタは既知の運用属性を扱う。
プライバシーは別の制約をもたらす。AI Searchを有効化すると、トレースデータはLangChainが管理する推論システムおよびサブプロセッサーを介して、米国へ転送・処理されることが許可される。
組織の管理者が、すべてのメンバーに対してこの機能を有効化する。個別のモデルプロバイダーキーは不要だ。
LangChainは、顧客が保護対象保健情報にAI Searchを使用すべきではないと明示している。この機能は、組織がLangChainと締結したBusiness Associate Agreementの対象ではない。
この警告は、今回のローンチが漏えいした個人識別情報の検索を強調しているため、注意を要する。機密データを検索するには、関連するトレース内容を分類システムに送信する必要がある。
組織は、一般的なPIIレビューと規制対象の医療データ処理を区別しなければならない。また、この機能を有効にする前に、保持、アクセス、データ所在地、サブプロセッサーの要件を確認する必要がある。
ベンダーを問わず、より広範な可観測性リスクは残る。詳細なトレースには、プロンプト、モデル応答、顧客記録、取得されたドキュメント、ツールの結果が記録され得る。
より完全なテレメトリーはデバッグを改善する一方、過剰な収集による影響も拡大する。チームは、機密フィールドが可観測性プラットフォームに到達する前に最小化すべきだ。
また、レビュー済みのサンプルに対して偽陽性と偽陰性をテストすべきである。有用なベータベンチマークには、既知の行動インシデント、難しいネガティブケース、異なるエージェントフレームワークにまたがる例が含まれるだろう。
公開資料は、精度、再現率、レイテンシー分布、埋め込みや事前定義された評価器との独立した比較を報告していない。説明されているのは、アーキテクチャと内部のトレース長サンプルである。
そのため、購入を検討する側には検索品質の共通指標がない。もっともらしい一致を返す機能であっても、最も重要な稀な失敗を見落とす可能性がある。
したがって、適切な解釈は限定的なものだ。LangSmithは有望な調査インターフェースを導入したのであって、評価、セキュリティスキャン、人によるレビューの代替として実証されたわけではない。
その価値は、ユーザーがどれだけ速く結果を検証し、クエリを再現し、その発見を持続的な品質管理へ転換できるかに左右される。
LangSmith AI Searchベータ版の後に注目すべき点
行動ベースのトレース検索が中核インフラになるのか、それとも有用な調査上の近道にとどまるのかは、3つのシグナルが示す。
1つ目のシグナルは、適応的なコンテキスト選択だ。LangChainは、クエリに応じて証拠を選択し、モデルが2回目のパスを必要とするタイミングを示す手法を検討しているとしている。
この取り組みは、8,000トークンの制限に直接対応するものだ。ツールに焦点を当てた検索がツール結果を優先し始めれば、会話上の証拠に隠れた実行失敗をより多く検出できるはずだ。
適応的な選択がなければ、ユーザーはトレースの種類ごとに異なるアプローチを必要とする。会話ベースの検索はうまく機能しても、運用上の検索ではカバレッジが一貫しない可能性がある。
2つ目のシグナルは再現性だ。保存済み検索、共有可能なクエリ、安定した結果セット、文書化されたレート制限があれば、AI Searchをインシデント対応へ組み込みやすくなる。
類似する一致をグループ化することも、チームが個別トレースの先へ進む助けになる。LangChainは、単にフラットなリストを返すのではなく、共通パターンを要約したいとしている。
その機能は、アドホックな検索をプロダクトインサイトのワークフローへ変え得る。チームは繰り返し発生する失敗クラスターを特定し、代表的なトレースを確認し、対象を絞った評価器を作成できる。
3つ目のシグナルは競合の対応だ。Datadog、Arize、その他の可観測性プロバイダーは、すでにトレーシングとモデルベースの評価を組み合わせている。
これらが対話的な行動探索を追加すれば、自然言語によるトレース検索は標準的なインターフェースになるだろう。その場合、競争は証拠の品質、ガバナンス、データセットとの統合へ移る。
競合が評価済みの精度と反復可能なモニタリングを重視するなら、LangSmithは探索がデプロイ後に測定可能な改善を生むことを示す必要がある。
ユーザーは、公開される検索品質ベンチマークにも注目すべきだ。フラストレーション、不完全なタスク、安全でない情報開示、無視されたツールエラーにわたる精度と再現率が、比較のより明確な基盤を提供するだろう。
現時点でLangSmith AI Searchを評価するチームは、既知のトレースをレビューしたセットから始めるべきだ。複数の記述をテストし、返された一致を比較し、モデルが見落とす証拠を文書化できる。
その後、この機能は発見のために使い、最終判断には使わない。影響の大きい発見は手作業で確認し、安定した行動定義は評価器または決定論的統制へ昇格させるべきだ。
今回のローンチが重要なのは、チームがエージェントの挙動についていつ問いを立てられるかを変えるからだ。本番トレースを収集する前に、あらゆる失敗を予測する必要はなくなる。
これはエージェント可観測性にとって意味のある一歩である。より困難な試験は、LangSmith AI Searchが、実際の本番ワークロード全体でこれらの発見を再現可能、監査可能、安全なものにできるかどうかだ。
