アシュウィン・ウガレ(Ashwin Ugale)はAugust 17, 2026、AIエージェントの実行traceを検査するopen-source Python linter「tracelint」を公開した。ユーザーに届く前に、無視されたtool errorなどの構造的欠陥を見つけるためのツールだ。記事では、`charge_card` toolが402 errorを返したにもかかわらず、agentが処理を続け、顧客にorderが出荷済みだと伝えた例が示された。ウガレは、これは通常の意味でのhallucinationではなく、trace上で見える構造的欠陥であり、別のLLMをjudgeとして使わずに決定論的に確認できると主張している。

tracelintはagent runの後にexecution traceを読み、agentが実際に何をしたかを特定し、証拠となる正確なtrace lineとCI exit codeを返す。検査対象はapplication codeではなくtraceであり、記事は「No second model ever judges it」と説明する。ウガレは、公開済みのtrace-error benchmarkではlocalization accuracyが低く、LLM judgeは非決定論的で、traceごとに費用がかかり、CI gateとして使いにくいため、このbug classには適さないとしている。

tracelintが狙うのは、構造的に判定できるagent bugである。toolのJSON Schemaに反するtool-call arguments、toolがerrorを返したのにagentが何もなかったかのように続行するケース、同じtoolが同一argumentsと同一resultsで5 times呼ばれるケース、agentのobservationsに現れないargumentsなどが対象になる。60-second setupでは`pip install tracelint`と`tracelint demo --html demo.html`を使う。demoは、各defectを1つずつ仕込んだkeyless validation suiteとclean controlsを実行し、HTML reportを書き出す。real tracesでは、`tracelint check ./trace.json --tools ./tools.json`がcleanなら`0`、構造的に証明できるdefectなら`2`、input errorなら`3`で終了する。heuristic findingsだけではCIをfailさせない。

tracelintは、agent teamがOpenInference、Arize Phoenix、Langfuse、OTel collector経由ですでに収集している可能性があるtelemetryを読む。記事は、`tracelint check spans.json --format openinference`、`tracelint check trace.json --format langfuse`、`tracelint check messages.json --format openai`などのcommandでsupported formatsを示した。ウガレは、Phoenix trace、OTel-SDK span export、Phoenix dataframe shapeを含むreal OpenInference exportsで検証したという。あるPhoenix traceでは、`add_spans_to_dataset`がGraphQL errorを返したstep 9のreal failureをtracelintがlocalizeした。

rulesは、R1 schema violation、R2 tool returned an errorまたはerrored value reused by a later side-effecting call、R3 hallucinated argument、R4 loop、R5 redundant call、R6 malformed arguments、R7 unknown toolである。記事はOpenInferenceのstuck-loop exampleを示し、R4が`search`の3 times連続呼び出しをflagした。argumentsが同一でresult stateに変化がなかったためだ。R5は、間にmutating callがないrepeated identical callをflagした。

ウガレによると、tracelintはhard defectsとcandidatesを分ける。schema violationsとmalformed JSONはCIをfailさせられる一方、loops、redundant calls、suspicious argumentsはhuman review向けに証拠付きで表示される。checkできなかった項目も報告する。traceにtool schemasやtool registryがない場合、R1やR7はclean扱いではなく、理由を示してsuppressedになる。limitationsとして、tracelintはstructural defectsを検査するがfinal-answer correctnessは検査しないこと、candidate findingsには正当なretriesやtransformsが含まれ得ること、error detectionはexplicit error status、HTTP status ≥ 400、`error` fieldなどのstructured signalsに依存することが挙げられた。`{"status":"declined"}`のようにHTTP 200 payload内に隠れたdomain failuresは、toolがfailureの見分け方を宣言しない限り認識されない。projectはMIT-licensedで、dependency-light、`jsonschema`とPython standard libraryを使い、Python 3.10–3.12をsupportし、offline deterministic test suiteを備える。

アシュウィン・ウガレ(Ashwin Ugale)はAugust 17, 2026、AIエージェントの実行traceを検査するopen-source Python linter「tracelint」を公開した。ユーザーに届く前に、無視されたtool errorなどの構造的欠陥を見つけるためのツールだ。記事では、`charge_card` toolが402 errorを返したにもかかわらず、agentが処理を続け、顧客にorderが出荷済みだと伝えた例が示された。ウガレは、これは通常の意味でのhallucinationではなく、trace上で見える構造的欠陥であり、別のLLMをjudgeとして使わずに決定論的に確認できると主張している。

tracelintはagent runの後にexecution traceを読み、agentが実際に何をしたかを特定し、証拠となる正確なtrace lineとCI exit codeを返す。検査対象はapplication codeではなくtraceであり、記事は「No second model ever judges it」と説明する。ウガレは、公開済みのtrace-error benchmarkではlocalization accuracyが低く、LLM judgeは非決定論的で、traceごとに費用がかかり、CI gateとして使いにくいため、このbug classには適さないとしている。

tracelintが狙うのは、構造的に判定できるagent bugである。toolのJSON Schemaに反するtool-call arguments、toolがerrorを返したのにagentが何もなかったかのように続行するケース、同じtoolが同一argumentsと同一resultsで5 times呼ばれるケース、agentのobservationsに現れないargumentsなどが対象になる。60-second setupでは`pip install tracelint`と`tracelint demo --html demo.html`を使う。demoは、各defectを1つずつ仕込んだkeyless validation suiteとclean controlsを実行し、HTML reportを書き出す。real tracesでは、`tracelint check ./trace.json --tools ./tools.json`がcleanなら`0`、構造的に証明できるdefectなら`2`、input errorなら`3`で終了する。heuristic findingsだけではCIをfailさせない。

tracelintは、agent teamがOpenInference、Arize Phoenix、Langfuse、OTel collector経由ですでに収集している可能性があるtelemetryを読む。記事は、`tracelint check spans.json --format openinference`、`tracelint check trace.json --format langfuse`、`tracelint check messages.json --format openai`などのcommandでsupported formatsを示した。ウガレは、Phoenix trace、OTel-SDK span export、Phoenix dataframe shapeを含むreal OpenInference exportsで検証したという。あるPhoenix traceでは、`add_spans_to_dataset`がGraphQL errorを返したstep 9のreal failureをtracelintがlocalizeした。

rulesは、R1 schema violation、R2 tool returned an errorまたはerrored value reused by a later side-effecting call、R3 hallucinated argument、R4 loop、R5 redundant call、R6 malformed arguments、R7 unknown toolである。記事はOpenInferenceのstuck-loop exampleを示し、R4が`search`の3 times連続呼び出しをflagした。argumentsが同一でresult stateに変化がなかったためだ。R5は、間にmutating callがないrepeated identical callをflagした。

ウガレによると、tracelintはhard defectsとcandidatesを分ける。schema violationsとmalformed JSONはCIをfailさせられる一方、loops、redundant calls、suspicious argumentsはhuman review向けに証拠付きで表示される。checkできなかった項目も報告する。traceにtool schemasやtool registryがない場合、R1やR7はclean扱いではなく、理由を示してsuppressedになる。limitationsとして、tracelintはstructural defectsを検査するがfinal-answer correctnessは検査しないこと、candidate findingsには正当なretriesやtransformsが含まれ得ること、error detectionはexplicit error status、HTTP status ≥ 400、`error` fieldなどのstructured signalsに依存することが挙げられた。`{"status":"declined"}`のようにHTTP 200 payload内に隠れたdomain failuresは、toolがfailureの見分け方を宣言しない限り認識されない。projectはMIT-licensedで、dependency-light、`jsonschema`とPython standard libraryを使い、Python 3.10–3.12をsupportし、offline deterministic test suiteを備える。