Simtops Co., Ltd. is involved in manufacturing, construction, maintenance services, and other industries.4,500Electronic document solution used in workplaces of more than 100 companiesi-ReporterWe plan, develop, and provide "[product name]". We address the challenge of how to overcome the limitations of tablet input in work environments where both hands are occupied, such as working at heights or in confined spaces, or when wearing gloves.AmiVoice SDKWhat role does it play in solving this problem? What is the background to its adoption, and what are the effects after its implementation?iOS / AndroidWe spoke with Mr. Atsuhiro Inaba, App Development Manager.

Assignment background

Using a tablet with your hands is difficult in high places, confined spaces, or while wearing gloves.

i-Reporter is an electronic form solution that digitizes paper forms, streamlining the input, reporting, and management of on-site operations. It is used by over 4,500 customers in a wide range of industries, primarily manufacturing, but also construction, building, general contractors, maintenance services, and repair businesses. While it has been deployed to many sites as a field form solution using tablets, there were inevitably situations where it was difficult to use, such as when working at heights or in confined spaces, where both hands are occupied and it is impossible to tap the screen. There are many situations on site where manual input is difficult, such as when hands are dirty, when holding tools or measuring instruments, or when wearing gloves. We had been receiving requests from customers for a long time to "input without stopping work" and "be able to record while working." This was the direct impetus for considering incorporating voice recognition into i-Reporter.

Key Drivers of the Adoption

The combination of high recognition accuracy and offline operation was the deciding factor in its adoption.

We initially considered AmiVoice as a candidate for our speech recognition engine because of its long-standing reputation for high accuracy in Japanese language recognition, based on years of expertise and accumulated data. After conducting various tests, we determined that it was at a level suitable for practical use and decided to adopt it.
What I particularly liked after actually using it was its extremely high recognition accuracy even while operating offline. In many i-Reporter field situations, network environments are not readily available, so offline operation that does not rely on the cloud was an essential requirement. Also, the fact that it could reliably recognize speech even with the device in my breast pocket exceeded my expectations. Situations where voice recognition is used are precisely those where "hands cannot be used," so an engine that only recognizes speech when you hold it close to your mouth and speak clearly would be counterproductive. In this respect, AmiVoice SDK delivers accuracy that is in line with actual usage.

Incidentally, when I checked which engine other companies' products with similar voice control functions were using, they were all AmiVoice. I feel that it is becoming the de facto standard in this field.

 

Introduction Results

Achieving a "two-person task completed by one person." Answer-back and dictionary registration ensure not only accuracy but also "certainty."

I had the opportunity to see its effects firsthand at a customer's site. When recording information engraved on large materials, previously there were two people: one who read it aloud and another who took notes.2A name was required, but voice input was used.1It has become possible to complete the task by name alone. I actually saw this in action on-site, and I felt that it directly leads to labor savings in workplaces where securing manpower is difficult.

While the accuracy of the voice recognition itself was already high thanks to AmiVoice, our main challenge during development was ensuring the reliability of voice-based operation. Unlike manual input, it's difficult to tell if the input was correct. Therefore, we implemented an "answer-back" mechanism that reads back the content from the speaker when the input is successful. We repeatedly considered the timing and wording of the repetition, as well as its customizability, and we believe we have achieved a level of reliability that is not significantly different from manual input.

Another challenge we faced was the diversity of how words are "pronounced." For example, even the number "205" can be read differently depending on whether it's a numerical value ("nizerogo") or a room number ("nimarugo"). Similarly, a hyphen ("-") can be read as a symbol ("hyphen") or as a separator in a postal code ("no"). Because it's difficult to cover all of these possibilities in advance, we created a system that allows users to register words in the dictionary according to their specific needs. This structure, which allows users to develop their own "rules of language" for each specific situation, has been a major support in actual operation. We also made improvements during the development and testing phases. Because it was a burden for developers to speak for long periods of time each time they tested the system, we developed our own web application to handle the speech and streamline testing.
I believe that this accumulation of meticulous testing is what leads to the quality that allows users to use our products with confidence in the field.