(2026年8月7日 19時45分 更新)

本障害について原因の調査が完了しましたので、その結果と再発防止策をご報告いたします。なお、本追記より下の記載は2026年6月23日時点の内容であり、当時の記録としてそのまま残しております。

1. 根本原因

音声認識サーバーの当該バージョンに含まれていた、スレッド間の排他制御の不備によるものです。

不具合の内容

クライアントとの通信を行う処理と、音声認識を行う処理とが、同一の内部データを参照していました。このデータは、単語登録の内容を保持するプロファイルです。しかし両者の間で排他制御が行われていなかったため、一方がそのデータを解放した直後に、他方が解放済みであることを確認しないまま参照する場合がありました。この場合に例外が発生し、音声認識を行うスレッドが異常終了します。

なお、単語登録をご利用でない場合も、セッションごとに一時的なプロファイルが生成されます。そのため本事象は、単語登録のご利用の有無にかかわらず発生します。

発生条件

以下の2つが重なった場合にのみ発生します。

• 音声認識の処理中に、クライアントとの通信でエラーが発生すること
• そのとき、通信を行う処理と音声認識を行う処理の実行順序が、特定の並びとなること

後者は実行のたびに変わりうるため、同じ条件でも発生しないことがあります。

認識結果が返却されなくなるまでの経過

1. バージョンアップ作業を実施（6月22日 11:38〜11:51）。作業直後の起動確認および動作確認では異常は認められませんでした
2. 通信エラーの発生を契機に、音声認識を行うスレッドが1つ異常終了（同日 14:56頃）
3. 同様に、残るスレッドも異常終了（同日 15:04頃）
4. 音声認識を行うスレッドがすべて失われた結果、当該サーバーは、接続およびリクエストの受け付けには成功するものの、音声認識の処理を一切行わない状態となりました
5. 対象エンジンを構成する全てのサーバーで同様に進行し、エンジン全体で認識結果が返却されない状態となりました

エラーが返却されず、認識結果のみが返却されないという事象になったのは、リクエストの受け付け自体は最後まで正常に機能していたためです。

作業直後の確認で検知できなかった理由

本不具合は、音声認識の処理中の通信エラーという条件を満たさない限り発生しません。バージョンアップ作業の動作確認は正常な音声認識が行えることの確認を目的としており、この条件が成立しないため、確認は正常に完了していました。実際に、最初の異常終了は作業完了の約3時間後に発生しています。

2. 検知に時間を要した理由

再発防止策の前提として、弊社側で即時に検知できなかった理由は以下のとおりです。

• 例外が音声認識サーバーのログには出力されず、OS側のログにのみ記録されていました。調査の初期段階でサーバーのログを精査しても原因を特定できず、OS側のログを確認して初めて判明しました
• 監視項目に該当するものがありませんでした。応答遅延は監視しておりましたが、本事象はイベントがそもそも発行されないため、遅延としては検知されません。またサーバーの稼働状態やリクエストの受け付け状況は正常なままでした
• エンジンごとに実際にリクエストを送信し、認識結果が返却されることを確認する試験を、定期的な監視項目として実行しておりませんでした

結果として、お客様からのご申告を受けての調査により把握することとなりました。深くお詫び申し上げます。

3. 再発防止策

対策の中心は、今回の異常について唯一の確実な記録であったOS側のログを、作業時の確認に委ねるのではなく、常時自動的に検知する仕組みを設けることと考えております。そのうえで、導入前の検証と導入時の手順もあわせて見直しております。

(1) OS側のログに記録される異常の自動検知

今回、音声認識を行うスレッドの異常終了は、音声認識サーバーのログには記録されず、OS側のログにのみ記録されていました。またこの異常終了は、入れ替え作業の完了から約3時間が経過した後に発生しており、作業時の確認では捉えられないものでした。

そのため、OS側のログに記録される例外を常時自動的に検知し、通知する仕組みを導入します。人が作業時に確認するのではなく、稼働している間は常に監視される状態とすることで、今回のように時間を置いて発生する事象も捉えられるようにします。

(2) 認識結果が返却されることの定期確認

(1) が異常の記録そのものを捉える対策であるのに対し、症状の側からも検知できるようにします。本番環境のエンジンごとに定期的にリクエストを送信し、音声認識結果が返却されることを確認する仕組みを導入します。異常を検知した場合は、Statuspageへの反映と関係者への通知を自動的に行います。

原因が今回と異なる場合であっても、認識結果が返却されないという事象であれば、同様に検知できます。

(3) 導入前の検証 — 異常系の試験を必須項目に追加

弊社では、音声認識サーバーを開発する部門が品質の検証を行ったうえでリリースし、これをサービスの運用部門が受け取って、本番環境への導入前に改めて検証を行う体制をとっております。運用部門による導入前の検証は、リリース内容に沿った機能確認、すなわち各機能が正常に動作することの確認が中心でした。今回の不具合は、正常な音声認識の手順では成立しない条件でのみ発生するため、この検証では検出できませんでした。

そこで、運用部門による導入前の検証においても異常系の確認を行うこととし、音声認識の処理中にクライアントとの通信が切断される状況を意図的に多数回発生させ、その後も認識結果が返却され続けることを確認する試験を新設しました。この試験は、音声認識サーバーを更新する際の必須の確認項目としております。

本試験は既に整備を完了しており、不具合を含むバージョンではこれを検出できること、および修正版では検出されないことを実測により確認しております。

(4) 段階的な入れ替えの手順

音声認識サーバーの入れ替えは、従来より段階的に実施しております。今後は、(1) および (2) の検知の仕組みが有効に機能していることを確認したうえで作業を開始し、各段階で一定の時間を置いて異常の通知がないことを確認してから、次の段階に進む手順といたします。

作業時の確認のみに依拠せず、時間の経過後に生じる異常についても検知の仕組みによって捉えられる状態としたうえで、入れ替えを進めてまいります。

(5) 適用範囲

上記の見直しは、音声入力_汎用エンジンに限らず全てのエンジン、および音声認識サーバーを含むサーバー群全体を対象としております。本不具合は当該バージョン全体に内在するものであり、特定のエンジンに限った問題ではないためです。

(6) 修正版の適用

排他制御を追加した修正版が提供されております。上記の見直し後の手順に基づき、順次適用してまいります。

4. お詫び

このたびは、お客様に多大なるご迷惑をおかけいたしましたことを、深くお詫び申し上げます。今後、同種の事象の再発防止に努めてまいります。

(2026年6月23日 19時13分 更新)

原因は、音声認識サーバーの不具合であることが判明しました。当該エンジン（`-a-general-input`）については、2026年6月23日（火）9:40頃に旧バージョンへのロールバックを実施し、復旧を確認しておりましたが、他のエンジンにも同様の影響が発生する可能性があることを確認したため、すべての音声認識サーバーも旧バージョンへのロールバックを順次実施し、17:13頃に完了いたしました。その後、モニタリングを続けておりましたが、問題の解決を確認しております。

なお、障害発生中に開始されたWebSocketセッションについては、復旧対応後も当該セッションを継続したままでは認識結果が返却されない可能性があります。復旧後も認識結果が取得できない場合は、WebSocketセッションを一度切断し、再接続をお願いいたします。 本障害により、ご利用のお客様にはご迷惑をおかけしましたことを深くお詫び申し上げます。

再発防止策については、引き続き整理のうえ、改めてご報告いたします。

(2026年6月23日 11時05分)

2026-06-22 15時頃から2026-06-23 9時40分頃まで音声入力_汎用エンジン（-a-general-input）が音声認識の途中結果イベントUおよび音声認識結果イベントAを返さない状態となっておりました。

影響範囲

• 障害発生時間: 2026年6月22日（月）15:00頃〜2026年6月23日（火）9:40頃
• 対象サービス: AmiVoice API WebSocketインタフェース、および、同期HTTPインタフェース
• 条件: 音声入力_汎用エンジン（-a-general-input）を利用の全リクエスト
• 影響内容：WebSocketの場合は音声送信後も U イベントおよび A イベントが返されず、音声認識結果が取得できない。HTTPの場合は応答しない。

2026年6月23日（火）9:40頃の復旧対応以降に新しく開始されたセッションでは、WebSocketの場合は通常通りUイベントおよびAイベントが返され、HTTPも音声認識結果を返すことを確認しております。

一方で、障害発生中に開始されたWebSocketセッションについては、復旧対応後も当該セッションを継続したままでは認識結果が返されない状態が継続する可能性があります。そのため、復旧後に認識結果が取得できない場合は、WebSocketセッションを一度切断し、再接続していただく必要があります。

原因

障害発生当日の2026年6月22日（月）11:38頃に、音声入力_汎用エンジン（-a-general-input）を稼働させているサーバーのバージョンアップ作業を実施しておりました。作業時には、定められた手順に従ってサーバーの起動状態および基本的な動作確認を実施し、作業直後の確認では異常を検知しておりませんでした。

しかしながら、15:00頃以降、音声入力_汎用エンジン（-a-general-input）において、リクエスト自体は受け付けるものの、音声認識の途中結果イベントであるUイベント、および音声認識結果イベントであるAイベントを返さない状態となっておりました。

その後、2026年6月23日（火）9:40頃に、当該エンジンを旧構成のサーバーへロールバックしたところ、復旧対応以降に新しく開始されたセッションではUイベントおよびAイベントが正常に返されることを確認しております。

このことから、今回の事象は、同日に実施したサーバーのバージョンアップ作業に伴う構成、起動設定、または実行環境の差分が影響した可能性が高いと考えております。現在、根本原因の特定を進めております。

検知が遅れた理由

弊社では、サーバーの稼働状態、リクエスト受付状況、リクエスト受付遅延、WebSocketの応答遅延、リソース枯渇などを監視対象としておりました。

一方で、エンジン単位で、WebSocketインタフェースおよびHTTPインタフェースに対して実際にリクエストを行い、正常に認識結果が返却されることを確認するEnd to Endテストは、定期的な監視項目として実行しておりませんでした。

また、WebSocketの応答遅延については監視しておりましたが、今回のようにUイベントおよびAイベントがそもそも発行されないケースでは、応答遅延として検知できない状態となっておりました。

そのため、音声入力_汎用エンジン（-a-general-input）に限定して音声認識結果が返却されない状態を、弊社側で即時に検知できず、お客様からのご申告およびその後の調査により把握する形となりました。

この点は、弊社の監視設計およびリリース後確認項目の不足であり、深くお詫び申し上げます。