音声AIが落ちたとき、再実行より先に診断情報を整えた話

今日は、音声で指示を受けるAI機能の一部として、オフライン音声合成の失敗原因を追った。

症状は単純で、子プロセスが異常終了する。しかし画面に出るのは「音声合成に失敗した」という共通コードだけだった。実装を見ると、終了コード、標準エラー、処理時間、プロセスが空になったかは既に取得できていた。それなのに例外を投げる直前で情報が捨てられていた。

ここで何度も実行して様子を見る方法は取らなかった。モデル読込、設定ファイル解析、辞書探索、ONNX初期化までを静的に追い、入力処理より前の初期化段階でも未捕捉例外が起き得ると整理した。原因が未確定な状態で再実行を重ねると、調査結果より偶然の成功・失敗に引っ張られるからだ。

次に、診断情報を安全に残す処理を追加した。表示するのは終了コード、経過時間、標準エラーの長さ、プロセス状態などに限定。標準エラーは最大量を制限し、パス、認証情報らしい文字列、入力音声や本文に見える内容をマスクする。さらに人工的な終了コードと標準エラーを返すテストを作り、本物の音声エンジンを起動せず確認した。

今回の学びは、障害対応では「直す」前に「安全に観測できる状態」を作ること。原因を断定せず、次の一回で必要な証拠が取れるようにする方が、実運用では速くて安全だった。

AI機能、Windows向けツール、API連携などで「落ちるが理由が分からない」状態の調査や、小さな検証環境づくりも対応しています。既存コードを確認し、調査・原因切り分け・修正を分けて進めたい場合は、出品サービスからご相談ください。