デバシシュ・ゴーサル(Debashish Ghosal)はAugust 7, 2026、AIエージェント向けのオープンソース観測レイヤー`agent-exec-trace`の構築が、検出器設計の課題からデータ形状の問題へ移ったと述べた。転機になったのは、Hugging Faceから取得した実際のエージェントトレース100,000件でのテストだった。このツールはOpenTelemetry風のトレース（標準化された遠隔測定記録）でエージェント実行を計測し、ループ、リトライの嵐、コスト急増、幻覚パターン、そのほかの実行時障害を分析して、開発者がエージェント実行の失敗箇所を把握できるようにする。

ゴーサルは当初、難所は異常の定義、しきい値の選定、トレースの接続、分析の実行、リポジトリの公開だと考えていた。Hugging Faceのコーパスに対する最初の大規模処理では、`empty_response`検出器がトレースの100%で発火し、35個のルールベース検出器のうち28個は一度も発火しなかった。原因は検出器そのものではなく、トレースごとに応答キー、ツール名の慣例、操作名、タイムスタンプ形式、親子関係が異なる点にあると結論づけた。4回の正規化を経て、当初の互換性推定値は42.4%まで下がった。

`agent-exec-trace`は、計画、ツール呼び出し、検索、メモリ、承認、コストについてスパンを出力し、問題のある実行を使いやすいUIに表示する設計だ。プロジェクトは3つのPyPIパッケージとして公開され、794件のPythonテストと34件のPlaywrightエンドツーエンドテストを備える。小さなSDKは、実在のエージェントを再設計せずにラップする用途を想定している。ゴーサルは、ruff clean、mypy strict clean、成功するテスト、90%超のカバレッジを含む規律あるプロジェクト設定があっても、モックエージェント前提が非現実的なデータで検証されることは防げなかったと述べた。

実トレースのコーパスがシステムの限界を示した後、ゴーサルは100万件のトレース、10個の架空エージェント、14個のツールを使う合成トレース生成器を作った。そこにはループ、リトライ、タイムアウト、非アクティブな空白、介入待ち、トークン爆発、メモリ急増といった意図的な挙動モードが含まれた。構造的互換性は99.2%に上がり、35個のルールベース検出器のうち20個が発火した。それでも合成データは検証を歪めた。合成出力とツール証拠の関係が人工的に分かりやすかったため、幻覚検出器は合成トレースの98%で発火した一方、生成されたコストの大半がセント単位だったため、`cost_spike`検出器はほとんど発火しなかった。

ゴーサルは、検証には層が必要だと述べた。ユニットテストはロジックが動くことを示し、合成トレースは検出器が必要なフィールドを見られることを示し、実トレースはその結果が開発者のサンドボックスの外で意味を持つかを示す。OTLPエクスポートの成功マイルストーンも誤解を招くものだった。2つのバグが相殺されていたためだ。OTelコレクターのgRPCポートはDocker Composeで公開されておらず、SDKの経路はOTLPエクスポートではなくローカルトレーシングに設定されていた。実際のゲートは、実在のエージェントがデータを出し、Jaegerがそれを受け取り、分析が取り込み、APIが結果を返すことを証明しなければならないと述べた。

プロジェクトはプライバシー上のトレードオフも迫った。メタデータのみの取得は、生のツール引数、完全なツール応答、メモリ値をデフォルトで避けたが、エージェントの主張と返されたツール証拠を検出器が比較できないため、幻覚検出器を弱くした。切り詰めた内容を許可すると、幻覚の偽陽性率は急落した。ゴーサルは、実コーパスで意味のある形で発火していない28個の検出器、本番ワークロード上のLLM検出器、API内のスパンツリー実体化、ワークロード横断のしきい値セット、エンドツーエンドの証明を欠く成功ゲートを、まだ完全には信頼していないと述べた。

デバシシュ・ゴーサル(Debashish Ghosal)はAugust 7, 2026、AIエージェント向けのオープンソース観測レイヤー`agent-exec-trace`の構築が、検出器設計の課題からデータ形状の問題へ移ったと述べた。転機になったのは、Hugging Faceから取得した実際のエージェントトレース100,000件でのテストだった。このツールはOpenTelemetry風のトレース（標準化された遠隔測定記録）でエージェント実行を計測し、ループ、リトライの嵐、コスト急増、幻覚パターン、そのほかの実行時障害を分析して、開発者がエージェント実行の失敗箇所を把握できるようにする。

ゴーサルは当初、難所は異常の定義、しきい値の選定、トレースの接続、分析の実行、リポジトリの公開だと考えていた。Hugging Faceのコーパスに対する最初の大規模処理では、`empty_response`検出器がトレースの100%で発火し、35個のルールベース検出器のうち28個は一度も発火しなかった。原因は検出器そのものではなく、トレースごとに応答キー、ツール名の慣例、操作名、タイムスタンプ形式、親子関係が異なる点にあると結論づけた。4回の正規化を経て、当初の互換性推定値は42.4%まで下がった。

`agent-exec-trace`は、計画、ツール呼び出し、検索、メモリ、承認、コストについてスパンを出力し、問題のある実行を使いやすいUIに表示する設計だ。プロジェクトは3つのPyPIパッケージとして公開され、794件のPythonテストと34件のPlaywrightエンドツーエンドテストを備える。小さなSDKは、実在のエージェントを再設計せずにラップする用途を想定している。ゴーサルは、ruff clean、mypy strict clean、成功するテスト、90%超のカバレッジを含む規律あるプロジェクト設定があっても、モックエージェント前提が非現実的なデータで検証されることは防げなかったと述べた。

実トレースのコーパスがシステムの限界を示した後、ゴーサルは100万件のトレース、10個の架空エージェント、14個のツールを使う合成トレース生成器を作った。そこにはループ、リトライ、タイムアウト、非アクティブな空白、介入待ち、トークン爆発、メモリ急増といった意図的な挙動モードが含まれた。構造的互換性は99.2%に上がり、35個のルールベース検出器のうち20個が発火した。それでも合成データは検証を歪めた。合成出力とツール証拠の関係が人工的に分かりやすかったため、幻覚検出器は合成トレースの98%で発火した一方、生成されたコストの大半がセント単位だったため、`cost_spike`検出器はほとんど発火しなかった。

ゴーサルは、検証には層が必要だと述べた。ユニットテストはロジックが動くことを示し、合成トレースは検出器が必要なフィールドを見られることを示し、実トレースはその結果が開発者のサンドボックスの外で意味を持つかを示す。OTLPエクスポートの成功マイルストーンも誤解を招くものだった。2つのバグが相殺されていたためだ。OTelコレクターのgRPCポートはDocker Composeで公開されておらず、SDKの経路はOTLPエクスポートではなくローカルトレーシングに設定されていた。実際のゲートは、実在のエージェントがデータを出し、Jaegerがそれを受け取り、分析が取り込み、APIが結果を返すことを証明しなければならないと述べた。

プロジェクトはプライバシー上のトレードオフも迫った。メタデータのみの取得は、生のツール引数、完全なツール応答、メモリ値をデフォルトで避けたが、エージェントの主張と返されたツール証拠を検出器が比較できないため、幻覚検出器を弱くした。切り詰めた内容を許可すると、幻覚の偽陽性率は急落した。ゴーサルは、実コーパスで意味のある形で発火していない28個の検出器、本番ワークロード上のLLM検出器、API内のスパンツリー実体化、ワークロード横断のしきい値セット、エンドツーエンドの証明を欠く成功ゲートを、まだ完全には信頼していないと述べた。