Spice Dog

Hello, this is Spice Dog.
Thank you very much for your strong interest in AmiVoice at "Zennfes Spring 2026", which was held from May 11 to June 27, 2026. All of our staff members truly feel that it was an excellent decision to participate in the event.

As part of a festival project themed "Voice Experience Creation with AmiVoice API Speech Recognition and Generative AI", we solicited implementation examples and knowledge regarding speech recognition, which resulted in over 70 submissions, far exceeding our expectations. We sincerely thank all those who submitted, those who read the articles, those who put it into practice, and everyone else involved.

You can view the submitted article on the following website.
Article Submission Contest: "Creating Voice Experiences with the AmiVoice Speech Recognition API and Generative AI" | Zenn

In this blog post, we would like to introduce "our insights" gained from this submission.

1. Number of posts by function of the AmiVoice API

What functional and non-functional aspects did you focus on during the evaluation, testing, and idea generation process?

While there were many instances of word registration, which is frequently inquired about on a regular basis, the impression is that various functions were utilized. It is somewhat gratifying that sentiment analysis, which is one of the distinctive features of AmiVoice API, was frequently used.

I used to think we lived in a sterile, emotionless modern society, but I was mistaken. Emotions are a prime example of something AI lacks, but it seems the day is approaching when we'll be able to understand human emotions thanks to sentiment analysis capabilities.

2. Audio source media used

What kind of audio source did you use for the speech recognition?

Real-time microphone input accounted for the majority of this data.
The second most common source was existing recording files, so I think there were a lot of sample audio files prepared specifically for the contest. In actual use, there will likely be more audio derived from on-site sounds and video content.

3. Apps, frameworks, tools, and APIs used with AmiVoice

We visualized which external systems were used together with the AmiVoice API in a tag cloud. In accordance with this theme, generative AI came to the forefront. In addition, development-related middleware and tools emerged. We also gained insight into everyone's specific preferences and priorities regarding development tools.

4. Interesting points

From here, I will introduce some interesting information that I found noteworthy in the articles you submitted.

4-1 Problem of recognition quality being compromised by noise fillers

Several posts discussed how much of the non-speech elements should be removed, and whether to keep or remove fillers (such as "えー" and "あのー").

Whether or not to retain filler content depends on the use case. In some cases, like meeting minutes, removing it makes the text easier to read, while in others, it provides important information for analyzing the speaker's hesitation or emotions. Furthermore, determining "what constitutes filler content" is surprisingly difficult, and how it is judged and handled can affect the quality of speech recognition.
Through this discussion, I've come to understand once again that handling fillers is a common concern for many people. One of the features of the AmiVoice API's hybrid engine is that it allows you to choose whether to output fillers as fillers or remove them. Since the requirements vary depending on the actual use case, we would appreciate it if you could continue to share your usage examples and opinions with us.

4-2 Problem: Directly passing recognition results to LLM can lead to missummarization and misjudgment.

If you confidently hand over the wrong information, the subsequent processing will become disorganized. It's like the game of telephone.

Therefore, in an attempt to capture nuances such as "they seem to be speaking without much confidence," we sometimes pass the confidence value returned by the AmiVoice API as an attribute of the recognition result to LLM and used it as a basis for judgment.
We are glad to see developers leveraging the confidence metric in practice.
Our aim is to provide "AmiVoice's 1mm"—a small step that adds value and changes the outcome, much like Daichi Kamada's header in the World Cup match against the Netherlands, where he slightly altered the trajectory of the ball towards the goal.

4-3 Data Protection and Governance (Logging Policy, Masking, Pre-publication Checks)

This presents a challenge regarding how much primary information, such as audio data, should be stored, and at what stage and how the personal information contained within it should be masked.

This is a separate issue from the accuracy of speech recognition, and I believe it needs to be considered whether the speech is recognized correctly or not. Once speech is converted to text, it becomes easy to search, copy, and share, and the information can easily spread unchecked.
For example, telephone audio may contain personal information such as names, addresses, and phone numbers. How to detect and protect this information at each stage—from audio acquisition and recognition to storage and utilization—is a topic that needs to be considered.
Furthermore, there is a risk that "false facts" will be generated due to recognition errors. To give an extreme example, it would be troublesome if your name suddenly appeared on a news flash you were watching at home. Accuracy of information is important, of course, but measures to prevent the spread of inaccurate information are also crucial.
From a system development perspective, many people mentioned the importance of a configuration that prevents the leakage of sensitive API keys and authentication information. Since both speech recognition systems and AI systems are ultimately composed of software and infrastructure, security design is essential.
On the other hand, if a robust system can be built by combining appropriate access control, encryption, audit logs, and data masking, it may be possible to achieve a more secure mechanism than one where humans directly handle voice data.
This is where our expertise in enterprise applications really shines. I was reminded that we need to provide value not only in terms of the accuracy of speech recognition, but also in terms of "how to handle it safely."

4-4 Integrating speech recognition functionality into no-code tools

Even with the widespread adoption of AI agents, I don't believe workflows themselves will disappear. The entities responsible for designing and executing workflows may shift from humans to AI agents. However, the workflows that define business processes will continue to be necessary.

No-code tools are an effective way to simplify the configuration of workflows. Furthermore, we believe that integrating modularized speech recognition functionality into workflows will make it easier to deploy them as business systems usable by many people, leading to significant labor savings.
This time, we were shown an example of integrating speech recognition into kintone, but such initiatives are just the beginning. In the field, each business has its own unique operations and rules, and there are many cases that cannot be handled by standard packages alone. We believe that no-code tools will become even more important in the future as a foundation for quickly systematizing such operations and continuously improving them.

4-5 Examples where a user dictionary is effective　

We have previously shared several points about the conditions under which user dictionaries should be utilized, but having you share specific solutions and use cases with us this time has allowed us to reaffirm their effectiveness.
I've added a few points, but I believe user dictionaries are particularly effective in the following situations:

For medical notes, disease names, drug names, and examination names
For financial and insurance calls, product names, contract names, and specialized terminology
For educational materials, names of notable figures, place names, and formulas

Additionally, what was interesting was the registration of aviation radio terminology. (This has also been supplemented slightly)

Cleared：着陸許可　Runway 34, cleared to land – 「34番滑走路への着陸を許可します」
Hold short：滑走路手前で停止　　Hold short of runway 34. – 「34番滑走路の手前で待機せよ」
Go around：着陸復行　go around, climb and maintain three thousand feet. – 「復行して3000フィートまで上昇してください」

It's immediately clear that these terms are important words that we don't want to be misunderstood.
We encourage you to utilize user dictionaries and keyword biasing to ensure you understand important voice instructions.

Aside from that,
In English-speaking countries, there is something called the "NATO phonetic alphabet" to prevent mishearing of spellings.
During phone calls with banks, etc.
"A for Apple, M for Mike, I for India….. "You are "AMI" ""
You might be asked to repeat a phrase like that to confirm what you've said.
I thought I'd never heard of this on a Japanese phone before, so I looked it up and found that NTT and other companies have something called a "Phonetic Call Table".
"A as in Asahi, Mi as in Mikan, Bo as in Boru, I as in Iroha,　Su as in Suzume — AMIVOICE."
It is said that.

5. Finally

Once again, thank you very much for your participation in and interest in Zenn Fest.
Our company will continue to provide useful information on speech recognition and AI, not just during the event period.
If you have any problems on-site or any suggestions like "Is it possible to do this?", please feel free to let us know. We want to use your feedback to improve our information dissemination and services in the future.

You can read the submitted article here.
Article Submission Contest: "Creating Voice Experiences with the AmiVoice Speech Recognition API and Generative AI" | Zenn

If you'd like to try it out, click here. You can use each engine for free for 60 minutes every month.
Speech to Text – AmiVoice's speech recognition API and SDK