🚀 AIエージェントに渡すHTMLを97.5%圧縮する「Skill設計パターン」This article explains a Skill design pattern for AI agents that strips raw HTML…

When AI coding agents such as Claude Code, Antigravity CLI, and Cursor are asked to perform web scraping or data collection, they often ingest raw HTML directly. A single page can carry tens of thousands of tokens, and feeding that unfiltered markup into a model quickly inflates API costs while burying the data that actually matters. A recently published Zenn article, authored with AI assistance, outlines a "Skill design pattern" that addresses this problem by returning only structured data to the agent, reportedly cutting token consumption by more than 90 percent.

The core issue is familiar to anyone who has delegated scraping tasks to a large language model. Modern web pages are dense with navigation menus, inline scripts, tracking snippets, advertising code, and deeply nested DOM elements. When an agent loads this content verbatim, most of the tokens it processes are noise rather than signal. Beyond the raw cost, the article notes a second failure mode: agents frequently stumble with errors like "DOM element not found," then loop through repeated trial-and-error attempts. Each retry consumes additional API calls and time, compounding both expense and latency.

The proposed remedy is to insert a dedicated Skill between the agent and the target website, rather than letting the model reason over unprocessed HTML. In this framing, a Skill is a reusable, task-specific capability that handles the messy extraction work deterministically and hands back a clean, structured result. Instead of asking the model to parse a full page, the pipeline strips out extraneous markup first and delivers only the relevant fields, so the agent receives compact, predictable input. Because the payload shrinks dramatically, the token count and associated cost fall in proportion, which is where the reported reduction of over 90 percent comes from.

This approach aligns with a broader industry pattern often described as pre-processing or tool-augmented retrieval. Rather than treating the language model as a universal parser, developers increasingly offload well-defined, mechanical tasks to conventional code and reserve the model's context window for genuine reasoning. Established libraries for HTML cleanup and content extraction, such as readability-style parsers, DOM sanitizers, and markup-to-Markdown converters, embody the same principle, and the Skill design pattern appears to formalize that habit into a repeatable interface an agent can call.

The concept also sits within the growing ecosystem of agentic tooling. Claude Code, Cursor, and similar CLI-based assistants are designed to operate with external tools and defined skills, and many now interoperate with emerging standards for connecting models to data sources and utilities. Presenting a scraper as a first-class Skill fits neatly into that model: the agent decides when to invoke it, but the underlying extraction logic remains fixed and testable. That separation is likely to improve reliability, since deterministic parsing code does not hallucinate selectors or drift between runs the way a model prompted to read raw HTML might.

For readers considering this technique, a few prerequisite ideas help clarify why it works. Token consumption in most commercial LLM APIs is billed per input and output token, so reducing the size of what the model reads directly lowers cost. Structured output, typically JSON or another schema-bound format, is also easier for downstream code to validate and consume, reducing the ambiguity that triggers retry loops. And because a well-scoped Skill returns consistent shapes, it can be cached, unit-tested, and reused across projects, benefits that ad hoc prompting rarely provides.

It is worth treating the headline figure with appropriate caution. The claimed savings will vary with the target site, the volume of boilerplate on each page, and how aggressively the extraction step trims content. Pages that are already lean may see smaller gains, while heavily instrumented commercial sites could see even larger ones. The article is explicitly an AI-assisted blog post rather than a formal benchmark, so the 90 percent figure is best read as an illustrative result from the author's own workflow rather than a guaranteed outcome.

Even so, the underlying guidance is sound and broadly applicable. As agentic workflows move from experiments into production, controlling token spend and improving determinism become practical necessities rather than optimizations. Encapsulating scraping and data collection behind a purpose-built Skill that emits structured data is a concrete way to pursue both, and the pattern generalizes to other tasks where raw, noisy inputs would otherwise flood an agent's context.