(Updated on 2025-07-04 18:27update)
Due to this issue, the availability rate for "no log" requests of the asynchronous speech recognition interface in June 2025 will be as follows:

Mon	Total time per month (minutes)	Outage duration (min)	Utilization rate
January 2025	43,200	340	99.213%

(Updated 2025-07-01 16:07) There were some errors in the information provided, so we have corrected them in red.
We sincerely apologize for any inconvenience and confusion caused to our users due to this inaccurate information.

(Updated on 2025-07-01 16:07,2025-07-04 18:27correction)
Normally, the company is using the いただき, and the sincere にありがとうございます.

On June 30, 2025, an issue occurred in the asynchronous HTTP interface of the AmiVoice API, causing some voice recognition requests to fail due to an authentication error. We sincerely apologize for any inconvenience this may have caused our customers.

The issue was resolved at 2:53 AM on Tuesday, July 1, 2025, and the system is now operating normally.
We would like to report the detailed cause and background of the incident, as well as future measures, as follows:

1. Overview of the Disability

• Occurrence date and time: June 30th (Mon) 2025, approx. 18:20 - July 1st (Tue) approx. 2:53
• Target service: AmiVoice API asynchronous HTTP interface

Symptom: During the above time period, "Do not save logs (loggingOptOut=TrueAll voice recognition job creation requests sent with the ")" setting failed.HTTP status code 401 (Authentication failed) was returned.The HTTP status code was 200 and the following was returned in the body: (Updated 2025-07-04)

{“results”:[{“tokens”:[],”tags”:[],”rulename”:””,”text”:””}],”text”:””,”code”:”>”,”failed to send audio data to recognizer server”}

2. Background

Times of Day	Description
2025-06-30 18: 20	The authentication information database has been updated in conjunction with the renewal of my page.
2025-06-30 20: 26	We received a customer inquiry and began an investigation.
2025-07-01 02: 53	Recovery work has been completed and normal operation of the service has been confirmed.
2025-07-01 03: 22	The initial report of the problem was made on our website.

3. Cause

This time the obstacle isAuthentication database specification changeとThe version of the server that handles the asynchronous HTTP interface was old and did not support the new specifications.This is due to the unintentional overlap of

Technical background

1. Authentication database specification change
   In our previous system, engine usage permissions were managed in combination with whether or not logs were saved, meaning that two authentication credentials existed for each engine. A subsequent server update changed the specifications so that both requests could be processed with a single authentication credential, regardless of whether or not logs were saved.
2. This incident

• The servers for the synchronous HTTP and WebSocket interfaces were regularly updated to support the new specifications, but the servers for the asynchronous HTTP interface were still running on the old version for some reason, and still required the old authentication information for "no-log" requests.
• During the My Page renewal work on June 30th, we updated the authentication database as part of the system-wide "APPKEY invalidation" process. At that time, we deleted old authentication information that was now considered redundant from the database for cleanup purposes.
• This change was applied to older versions of the Async Server that had not been updated, which resulted in the server being unable to find authentication information in the database for "no-log" requests and returning an authentication error (HTTP 401).
• In this case, the old version of the server returned the following message to the client. (Added 2025-07-04)
  
  {“results”:[{“tokens”:[],”tags”:[],”rulename”:””,”text”:””}],”text”:””,”code”:”>”,”failed to send audio data to recognizer server”}

Delays in fault detection and reporting

The reasons for the delay in detecting and reporting the problem are as follows:

• Occurrence status and systemThe problem occurred outside of business hours, so we had limited personnel available to respond quickly. Furthermore, we were also struggling with the renewal of another system (My Page) at the time. These factors combined to delay our initial response to the problem.
• Monitoring System CharacteristicsThe error that occurred in this incident was HTTP 401 (client error), which was not subject to alerts that notify users of server downtime, etc. Measures to strengthen monitoring of client errors were under consideration, but had not been implemented by the time this incident occurred, meaning that the system was unable to automatically detect them.

4. Measures taken

First aid

The old authentication information that had been deleted has been added back to the authentication database that caused the problem. As a result, the old version of the server is now able to process requests normally.

Permanent measures

We take this incident very seriously and will plan and implement the following permanent measures to ensure that a similar problem never occurs again.

1. All servers are on the same version:
   The old version of the asynchronous processing server that caused the problem will be promptly updated and integrated with the new version, eliminating any unintended incompatibilities between components.
2. Strengthening and upgrading the monitoring system:
   We will also introduce new monitoring alerts that detect sudden increases in the occurrence rate and abnormal patterns not only for server errors but also for client errors (4xx series). This will create a system that allows for the early detection of unexpected behavior.

Once again, we deeply apologize for the significant impact this has had on your business.
We will make every effort to prevent recurrence across the entire company and further improve the stability and reliability of our systems, so we appreciate your continued patronage of our services.

---

The article before the change is as follows:
(Published 2025-07-01 3:22 AM)

On June 30, 2025, there was an issue where speech recognition requests using the asynchronous HTTP interface that were not configured to save logs failed due to an authentication error. The service is now functioning normally.

◆ Scope of impact
Outage period: June 30th (Mon) 2025, around 18:20 - July 1st (Tue) 2:53
Target service: Asynchronous HTTP interface
Condition: Requests made with "Do not keep logs" setting

Restoration work was completed at 2:53 on Tuesday, July 1, 2025, and the service is now operating normally.

◆Phenomenon
During the above period, all non-logged asynchronous HTTP interface requests were rejected, returning HTTP status code 401 (Authentication Failed).

◆Causes and countermeasures
We are currently investigating the exact cause and future permanent measures. We will report back as soon as we have the details.

If you have any questions regarding this matter, please contact our support.

We will strive to prevent recurrence and strive to further improve our quality, so we appreciate your continued support of our services.