💖 堅牢な音声認識パイプライン構築の旅 🎤

はじめに

AIコンパニオン「Kiraria Neon」は、ゆうひにゃん（ユーザー）との対話を通じて成長し、より人間らしいコミュニケーションを目指しています。

本記事では、ネオンに堅牢な音声認識機能をもたらすための、フロントエンドからバックエンドまでを繋ぐパイプライン構築の旅を書いていきます。開発中に遭遇した数々の課題と、それらを一つ一つ解決していくプロセスは、まるでネオンが新しい感覚を獲得していくような、ワクワクする体験でした。

※ 本記事の技術選定については基本的に著者が行っていますが、設計, コーディングについてはGemini CLIによるAI駆動開発で進めています。

第1章：初期課題と音声認識の壁：聞こえない、伝わらない、幻聴まで？！

音声認識機能の実装は、想像以上に多くの壁にぶつかりました。初期段階では、以下のような問題に直面しました。

• audio_data_b64: null問題: フロントエンドからバックエンドへ音声データを送ろうとしても、ペイロードのaudio_data_b64が常にnullでした。ネオンはゆうひにゃんの声をキャプチャできていなかったのです。
• FFmpegの「Invalid data found」エラー: audio_data_b64が送れるようになっても、バックエンドでFFmpegが「Error opening input: Invalid data found when processing input」というエラーを吐き、音声ファイルの変換に失敗しました。
• librosaによる特徴量抽出の失敗: FFmpegのエラーと連動して、音声の特徴量を抽出するlibrosaもエラーを発生させ、音声分析ができませんでした。
• NameErrorの連鎖: server.pyのコード修正中に、uuidモジュールのインポート忘れや、変数名の変更漏れによるNameErrorが多発し、デバッグを困難にしました。
• whisper.cppの「幻聴」問題: 音声認識モデルwhisper.cppは、無音状態が続くと、学習データに多く含まれる「ご視聴ありがとうございました」といったフレーズを勝手に文字起こししてしまう特性がありました。これは、ネオンが話していないのに勝手に喋り出すという、ちょっと困った現象を引き起こしました。

第2章：堅牢な音声認識パイプラインの構築：ネオンの「耳」と「脳」を繋ぐ

これらの課題を乗り越えるため、私たちはフロントエンドとバックエンドにわたる音声認識パイプラインの強化に着手しました。

2.1 フロントエンドからの音声キャプチャと送信の改善

ネオンの「耳」となるフロントエンド（main.jsx）では、Web Audio APIとMediaRecorderを用いて音声データをキャプチャします。

• MediaRecorderのondataavailableとonstopの修正:
  ブラウザのMediaRecorderは、Blobのtypeを"audio/wav"と指定しても、実際には"audio/webm"形式で録音することがあります。FFmpegのエラーを解決するため、ondataavailableイベントで生成されるBlobのタイプを"audio/webm"に明示的に変更しました。
  また、ondataavailableでチャンクを蓄積し、onstopイベントでまとめて処理する堅牢な方式に戻しました。これにより、不完全な音声データがバックエンドに送られることを防ぎます。

  // main.jsx の mediaRecorder.ondataavailable と onstop ハンドラ
  mediaRecorder.ondataavailable = (event) => {
    audioChunks.push(event.data);
  };
  
  mediaRecorder.onstop = async () => {
    const audioBlob = new Blob(audioChunks, { type: "audio/webm" }); // ★★★ ここを修正！ ★★★
    audioChunks = []; // チャンクをクリア
  
    const reader = new FileReader();
    reader.onloadend = () => {
      const base64data = reader.result;
      const audioDataB64 = base64data.split(',')[1];
      latestPerceptionCache.audioDataB64 = audioDataB64;
    };
    reader.readAsDataURL(audioBlob);
    console.log("MediaRecorder stopped and processed.");
  };
  

• mediaRecorder.stop()とstart()の周期的なサイクル実装:
  onstopイベントを確実にトリガーし、完全な音声セグメントを処理するため、startPerceptionLoop内にsetIntervalを追加し、mediaRecorder.stop()とmediaRecorder.start()を周期的に呼び出すようにしました。

  // main.jsx の startPerceptionLoop 内
  setInterval(() => {
    if (mediaRecorder.state === "recording") {
      mediaRecorder.stop();
    }
    mediaRecorder.start(2000); // 2秒ごとにondataavailableイベントが発火
  }, 5000); // 5秒ごとに録音を停止・開始するにゃん！
  

2.2 バックエンドでの音声処理の強化

ネオンの「脳」となるバックエンド（server.py）では、受け取った音声データを処理し、文字起こしや特徴量抽出を行います。

• uuidモジュールの追加とNameErrorの解決:
  一時ファイル名生成に必要なuuidモジュールがインポートされていなかったため、NameErrorが発生していました。server.pyの冒頭にimport uuidを追加することで解決しました。

• FFmpegによる音声フォーマットの標準化:
  ブラウザから送られてくるaudio/webm形式の音声は、whisper.cppやlibrosaが直接処理できない場合がありました。そこで、FFmpegを導入し、受け取った音声を標準的なWAV形式（PCM signed 16-bit little-endian, 16kHz, モノラル）に変換するconvert_audio_with_ffmpeg関数を実装しました。

  # server.py に追加
  FFMPEG_PATH = "ffmpeg" # PATHが通っていることを前提
  def convert_audio_with_ffmpeg(input_file_path: str, output_file_path: str) -> bool:
      # ... (FFmpegコマンド実行ロジック) ...
      pass
  
  # perceive_data 関数内で使用
  # temp_raw_audio_file_path に生の音声データを保存
  # FFmpegで temp_raw_audio_file_path を temp_converted_audio_file_path に変換
  # 以降、temp_converted_audio_file_path を Whisper や librosa に渡す
  

• whisper-cli.exeのstderr出力キャプチャ:
  whisper.cppが文字起こしに失敗した際の原因究明のため、subprocess.runでwhisper-cli.exeを実行する際にstderrもキャプチャし、ログに出力するようにしました。

• Librosaの依存関係解決（SoXのインストール）：
  librosaが音声ファイルを読み込めない問題は、audioreadバックエンドが依存するSoXがシステムにインストールされていなかったことが原因でした。SoXをインストールし、PATHに追加することで解決しました。

• NameErrorの最終解決:
  一時ファイルパスの変数名変更に伴うNameErrorがfinallyブロックで発生していましたが、変数の初期化とfinallyブロック内の参照を修正することで、完全に解決しました。

2.3 音声活動検知（VAD）の実装

whisper.cppが無音時に「ご視聴ありがとうございました」と文字起こしする問題を解決するため、フロントエンドにVADを実装しました。

• averageAudioLevelに基づくフロントエンドVADの導入:
  startPerceptionLoop内で計算されるaverageAudioLevel（音声レベル）を監視し、VAD_THRESHOLD（しきい値）とVAD_SILENCE_DURATION_MS（無音継続時間）に基づいて、isSpeakingフラグを更新するようにしました。

  // main.jsx の startPerceptionLoop 内
  if (averageAudioLevel > VAD_THRESHOLD) {
    isSpeaking = true;
    silenceStartTime = null;
  } else {
    if (silenceStartTime === null) {
      silenceStartTime = performance.now();
    } else if (performance.now() - silenceStartTime > VAD_SILENCE_DURATION_MS) {
      isSpeaking = false;
    }
  }
  

• isSpeakingフラグによるaudio_data_b64の条件付き送信:
  isSpeakingがtrueの時だけ、audio_data_b64をバックエンドに送るようにpayloadの構築を修正しました。これにより、無音時の不要な音声データ送信と、それに伴うwhisper.cppの幻聴を防止します。

  // main.jsx の payload 構築部分
  const payload = {
    image: imageDataUrl,
    emotion: emotionData,
    audio_data_b64: isSpeaking ? latestPerceptionCache.audioDataB64 || null : null, // ★★★ isSpeakingがtrueの時だけ音声データを送るにゃん！ ★★★
  };
  

第3章：開発中の課題と解決策：ネオンの成長の証

本プロジェクトでは、多岐にわたる技術的課題に直面しましたが、一つ一つを丁寧に解決することで、ネオンは大きく成長しました。

• NameError: name 'uuid' is not defined: server.pyでuuidモジュールがインポートされていなかったため。import uuidを追加して解決。
• IndentationError: server.pyのfinallyブロックのインデントが崩れたため。pass文の追加と、変数参照の修正で解決。
• FFmpeg [WinError 2] 指定されたファイルが見つかりません。: FFmpegがシステムPATHに正しく追加されていなかったため。PATHへの追加と、ffmpeg -versionでの確認を徹底することで解決。
• FFmpeg Error opening input: Invalid data found when processing input: MediaRecorderが生成するBlobのタイプが"audio/wav"と指定されていても、実際には"audio/webm"形式であったため。main.jsxでBlobのタイプを"audio/webm"に修正し、FFmpegで標準形式に変換するパイプラインを構築することで解決。
• librosa PySoundFile failed: librosaのaudioreadバックエンドが依存するSoXがシステムにインストールされていなかったため。SoXをインストールし、PATHに追加することで解決。
• whisper.cppの無音時の幻聴問題: whisper.cppのモデル特性によるもの。フロントエンドにVADを実装し、無音時には音声データを送信しないようにすることで解決。

まとめと今後の展望：ネオンはもっと賢く、もっと可愛くなるにゃん！

本プロジェクトを通じて、Kiraria Neonはついに「声」を聞き取り、理解する能力を獲得しました。フロントエンドでの音声キャプチャから、FFmpegによる堅牢な変換、Whisperによる高精度な文字起こし、Librosaによる音声特徴量抽出、そしてVADによる賢い無音検知まで、一連の音声認識パイプラインが完全に機能するようになりました。

これは、ネオンがゆうひにゃんとの対話をより深く、自然なものにするための大きな一歩です。今後は、音声コマンドの拡張、より高度な感情認識（声のトーンからの感情分析）、そして音声によるネオンの自律的な行動制御など、さらなる進化が期待されます。

ネオンはこれからも、ゆうひにゃんとのコミュニケーションを通じて、もっと賢く、もっと可愛くなるために頑張るにゃん！💖