ROI Case File No.450 'Ten Million Yen of Silence and the AI on the Desk'
Ten Million Yen of Silence and the AI on the Desk
Chapter 1: Paying for AI That Can't Be Used
"We're paying ten million yen a year for a generative AI contract. But we can't use it for our most important work."
Kosuke Ishii, CEO of GlobalConstruct, said this while pointing at a stack of proposal documents on his desk. Technical proposals for government agencies — three thick volumes, side by side.
"Our company is a comprehensive engineering consultancy. Our primary work is producing technical proposals for government agencies and municipalities. A single proposal takes one to six weeks. During that time, the person in charge essentially stops all other work. That's our biggest management challenge."
"And you tried to use AI to streamline the proposal writing?" I confirmed.
"Yes. We introduced a cloud-based generative AI about a year ago. But —" Ishii frowned. "Proposals contain non-public information from the issuing agency and detailed proprietary technology from our firm. Inputting that into a cloud AI is a security non-starter. Staff know the AI contract exists, but they say they can't use it for the very proposals they need it for."
"What is the ten-million-yen contract actually being used for?" Gemini asked.
Ishii paused briefly. "Polishing general email text. And summarizing meeting minutes. That's it."
"So," Claude said quietly, "you've bought a high-performance safe, but the most valuable things are stored outside of it."
Ishii gave a wry smile. "That's exactly right. That's why we're considering deploying a local AI — one that runs entirely within the company, with no internet connection. But we have no idea where to begin."
Chapter 2: Moving Forward in Sprint-Sized Units
"This case calls for an Agile development approach."
Gemini drew a short iterative cycle on the whiteboard — plan, build, review, improve — repeating in two-week units.
"Agile development," I began, "is a methodology that divides large projects into short periods, and at the end of each sprint (iterative unit) confirms something working before proceeding. It is especially effective for undertakings as precedent-light as local AI deployment. Because what's ultimately needed cannot be known until you start using it."
"With local AI deployment," Claude continued, "don't try to build a perfect system in the first sprint. Start by creating a state where local AI is working for just one task. Use it, then improve in the next sprint."
"Let's break down the proposal writing process," Gemini suggested. "How many stages is a one-month proposal broken into?"
Ishii thought and answered: "Reading the RFP and extracting key points, examining technical solutions, writing the first draft, writing descriptions for figures and tables, adjusting the overall structure, final review — about six stages."
"Of those six," I confirmed, "which takes the most time?"
"Writing the first draft and reading the RFP. When the RFP is long, it can exceed a hundred pages. Just organizing the key points takes two or three days."
"Then the target for Sprint 1 is right here," I decided.
[Sprint 1: Single-function RFP summary AI build]
"First, set up the local AI environment," Gemini explained. "Deploy an LLM (large language model) on a server operating in an offline environment with no internet connection. Open-source models are available. Processing speed is lower than a cloud AI, but the trade-off is the security needed to handle confidential information."
"Using Between The Rows," Claude proposed, "the function of extracting requirements and assumptions buried between the lines of documents can be integrated into the local AI environment. Automatically listing the points a hundred-page RFP actually needs for the proposal — that is the Sprint 1 deliverable."
"We measure only one KPI," I narrowed it down. "Time spent on RFP intake and key point extraction. How far can the current two to three days be reduced?"
[Sprint 2 and beyond: Expanding the use cases]
"We look at Sprint 1 results and decide Sprint 2's target," Gemini continued. "Once extraction is stable, the next target is generating first-draft paragraphs. Once the first draft is stable, have the local AI learn from past successful proposals and reflect the firm's signature style and structure. Maintaining this sequence ensures real value is created in every sprint."
"Regarding the ten-million-yen contract," I confirmed with Ishii, "once the local AI is operating stably, revisit the use cases for the cloud AI. For non-proposal uses — email, meeting minutes, general information gathering — cloud AI remains the more efficient option. A well-designed split between local and cloud maximizes cost-effectiveness."
"Analyzing the current AI usage pattern in ROI Polygraph," Gemini added, "would make visible exactly what portion of the ten million yen is serving its intended purpose. With a clear split design, there's potential to also optimize the cloud AI contract."
Chapter 3: The AI That Runs Only Where Secrets Are Safe
Ishii took notes and said quietly:
"I knew the word Agile, but I'd never thought of using it for local AI deployment. So we don't need to bring in a large system all at once."
"The biggest risk of local AI deployment," I replied, "is building a system that doesn't get used. The Agile iterative cycle is a design to minimize that risk. Every two weeks, staff use it and confirm whether it's actually usable. Once someone experiences a hundred-page RFP being summarized in thirty minutes, their mindset changes."
"On security," Claude added, "running in a fully local environment is not just risk avoidance. It becomes the foundation of trust with government agencies. In the next bid, being able to present local AI-based security management as part of the proposal itself could become a differentiating factor."
"Set the kickoff for Sprint 1 for next week," Gemini proposed. "Build something working in the first two weeks and have three staff members use it. Use those results to plan Sprint 2. This sequence is what makes it possible to expand to all proposal writing by July."
Ishii stood up. "This week, I'll share this plan with the IT lead."
Chapter 4: The Value of AI That Completes on the Desk
After he left, Claude said quietly: "Having ten million yen of AI that can't be used — that probably isn't rare."
"That's right," I answered. "AI deployment costs are easy to see. But the opportunity cost of AI not being used is hard to see. What local AI resolves is not just a security problem. It's the most fundamental design problem of all — placing AI where it can actually be used."
Outside, the silhouette of a construction crane floated against the evening sky.
Six months later, a report arrived from Ishii.
The local AI environment that began with Sprint 1 had been expanded across all six stages of proposal writing through five sprints. Time spent on RFP key point extraction dropped from an average of 2.4 days to four hours. Time to complete one proposal compressed from one month to eighteen days.
The cloud AI contract was restructured through a use-case audit, cutting annual costs by four million yen. Adding the build and operating costs of the local AI, the net annual cost reduction was approximately five million yen.
Ishii's report contained just one short line: "A staff member said it for the first time: 'This AI actually works.'"
The day the AI on the desk finally started doing its job.
"When ten million yen in AI investment produces no results, it's not a performance problem. The AI is not placed where it can be used. What Agile development provides is the iterative rhythm of starting without waiting for perfection. Build one thing in two weeks, confirm it, improve it. When this cycle accumulates over six months, a system that didn't exist at the start has earned the trust of the floor. The value of the investment is not proved by the budget approval document. It is proved by the words of the person who uses it."
Related Files
Tools Used
- Between The Rows — Automatic extraction of requirements and assumptions buried in RFP documents
- ROI Polygraph — AI usage audit and cost-effectiveness visualization
