AI Taps Legacy APIs, LLM Reads 20-Year-Old Excel — A Reversal Where ‘Old Systems’ Become the Strongest Weapon
Related Articles
30 Million for Renewal or 500,000 for Connection
To get straight to the point: There’s no need to discard old systems. Just connect them.
While large corporations spend tens of millions to hundreds of millions of yen to renew their core systems, a structure is emerging where small and medium-sized enterprises can achieve equal or greater results simply by “connecting as is.” AI agents are tapping into legacy SOAP APIs, LLMs are being integrated into PostgreSQL, and document analysis models are reducing errors by 20% while cutting costs to one-sixth. These are separate news items, but they point in the same direction.
The connection costs between “old” and “new” have dramatically decreased.
This structural change presents a reversal opportunity for local small and medium-sized enterprises. Let’s examine this step by step.
—
The Day SOAP API Became a “Useful Legacy”
SOAP API. Those in the IT industry might think, “Is it still alive?” This XML-based communication standard was at its peak in the 2000s and is cumbersome compared to today’s REST APIs and GraphQL. However, the reality is that behind the core systems of small and medium-sized enterprises across Japan—sales management, inventory management, accounting—this SOAP API is still operational.
Recently, an OSS project has garnered attention. It automatically converts old SOAP API WSDL definition files into tool definitions (OpenAPI / Function Calling format) that AI agents can invoke.
What does this mean?
Traditionally, connecting legacy systems to AI required a human to write an intermediary “transformation layer.” You would build middleware to convert SOAP to REST, pass through authentication, write error handling, and conduct testing. If you relied on a system integrator, it would cost millions to tens of millions of yen. Even if you did it in-house, engineers would need to be dedicated for months.
Now, as long as you have the WSDL definition, automatic conversion is possible. AI agents can directly tap into SOAP. The transformation cost has dropped from several million yen to several hundred thousand yen.
Consider this: large corporations have the resources to “discard old systems and replace them with new ones.” That’s why they can spend 30 million, 50 million, or even hundreds of millions on system renewals. Small and medium-sized enterprises do not have that capacity. Therefore, “connecting without discarding” becomes the correct answer.
Let’s look at a specific scenario:
- Connect an AI agent to a 20-year-old sales management system’s SOAP API.
- Instruct it in natural language: “Show me the top 10 products sold last month, compared to the same month last year.”
- The AI agent taps the SOAP API, parses the XML response, and returns it in table format.
Data that previously could only be extracted by someone “knowledgeable about the system” can now be accessed by anyone. The barrier of individual dependency is crumbling due to the decrease in connection costs.
System renewal: 30 million yen or more, duration 12 months or more.
API connection + AI agent construction: 500,000 to 2 million yen, duration 1 to 2 months.
It’s clear which option to choose.
—
PostgreSQL × LLM — Databases Start to “Converse”
Next, the movement to integrate LLMs into PostgreSQL is accelerating.
PostgreSQL is one of the most widely used open-source databases behind web services and SaaS for small and medium-sized enterprises. What does it mean to integrate LLMs here?
You will be able to query the database in natural language without writing SQL.
For instance, using extensions like pgai or pg_vectorize, vector searches and LLM calls can be completed within PostgreSQL. There’s no need to send data externally, which is significant from a security perspective.
What happens on the ground in small and medium-sized enterprises?
“Show me the list of outstanding receivables this month, sorted by amount, but only those over 30 days overdue.”
When an accountant inputs this in natural language, the LLM converts it to SQL, executes it on PostgreSQL, and returns the results. Data that previously could only be accessed by someone who “could write SQL” or by requesting it from a systems company can now be at the fingertips of on-site personnel.
However, let me emphasize one point: Do not take the LLM’s output at face value.
There’s always a possibility that the SQL generated by the LLM is incorrect. Especially when the aggregation conditions are complex, missing just one condition in the WHERE clause can significantly alter the numbers. Therefore, operationally, it’s realistic to include a step where “a human verifies the SQL generated by the LLM before execution.”
Even so, the skill level and time required for reviewing generated SQL versus writing SQL from scratch are entirely different. Jobs that required “someone who can write” are transforming into jobs that can be handled by “someone who can read.” This is a subtle yet certain solution to the talent shortage faced by small and medium-sized enterprises.
—
Document Analysis Model “r-1” — Shocking Cost Reduction to One-Sixth and 20% Fewer Errors
The third topic is about the document analysis model “r-1” announced by Reducto.
Traditional document analysis (OCR + structuring) involved multiple steps. First, text is extracted via OCR, then the layout is analyzed, tables are recognized, and finally, it’s converted into structured data. Errors accumulate at each step, leading to a drop in final accuracy. The longer the pipeline, the more points there are where it can break down.
r-1 consolidates this into a single full-page pass. You input the entire page image and output structured data in one go. As a result, the error rate is reduced by 20% compared to traditional methods, and costs are cut to a maximum of one-sixth.
What does this mean for small and medium-sized enterprises? Let’s think concretely.
Many local manufacturing and wholesale companies have “20 years of transaction data stored in Excel and PDF.” Scanned PDFs of paper invoices, manually entered Excel sheets, and images of faxes. These should be “assets,” but because they are unstructured, they cannot be searched or analyzed. They are dead data.
Traditionally, to digitize this, you would send it to an OCR service, have humans visually correct the errors, structure it, and store it. The processing cost per document is high, so digitizing tens of thousands of documents would cost hundreds of thousands of yen. Hence, the decision often becomes “not to do it.”
When a model like r-1 becomes available, this calculation changes.
- Processing cost: One-sixth of the traditional cost
- Labor costs for error correction: Significantly reduced due to a 20% decrease in error rate
- If traditional digitization cost 3 million yen, it can now be done for 500,000 to 800,000 yen.
When 3 million becomes 500,000, the decision shifts from “not doing it” to “doing it.”
Moreover, the digitized 20 years of transaction history will become a target for LLM analysis. “Is there seasonality in this customer’s ordering patterns?” “Which product categories have the most discount negotiations?” — Insights that previously existed only in the minds of veteran salespeople will be visualized as data.
—
The Reversal Structure — Why “Old” Becomes “Strong”
Connecting these three stories reveals a single structure.
“Old systems” and “old data” were left dormant because the connection and transformation costs were high. Now that those costs have dramatically decreased, they transform into “unique assets.”
Every time large corporations renew their systems, they reset past data and structures. Small and medium-sized enterprises, having “not been able to change,” still have 20 years of data. Business flows that have been in place for 30 years are alive on the other side of the SOAP API.
This is not something that can be easily replicated. New entrants cannot create it from scratch. The moment when “not being able to change” flips to “not needing to change” is happening right now.
So, what specifically should be done? Here are three points:
1. Take inventory of your “old connections”
Does your core system have an API? SOAP APIs are fine. Do you still have the WSDL files? First, check that.
2. Understand the quantity and format of dormant data
Excel, PDF, paper — in what formats, how many years’ worth, and how many documents are there? Once you know that, you can estimate the cost of digitization.
3. Connect small and test
Don’t implement it company-wide all at once. Test with one API, one business process, or one dataset. If you can test for 500,000 yen, even if it fails, it won’t be a fatal blow.
—
Is This Enough?
Finally, just one more thing.
“We have an old system,” or “We don’t have data” — these excuses no longer hold water. Old systems can be connected by AI. Data can be read by LLMs. The cost of document analysis has decreased to one-sixth.
The problem is not the technology. It’s whether you decide to “try connecting.”
Before considering a 30 million yen system renewal, I urge you to conduct a 500,000 yen connection experiment. That 20-year-old Excel is not something to discard; it’s something to unearth.
The era where the old becomes a weapon has already begun.
JA
EN