Notta 音声認識 精度テスト 2026｜実務向けCER/WER評価と導入指針

結論サマリー（主要指標と実務的推奨）

ここでは主要結論と現場での判断基準を短く示します。各環境ごとのCER/WER、95%CI、サンプル数、S/I/Dの絶対数、編集工数の目安を表で掲載し、導入判定を提示します。

主要指標サマリ（抜粋）

以下は評価結果の要約です。S/I/D の絶対数は各条件での総文字数／総語数の実測平均に基づく算出値を併記しています。詳細とファイル別集計は付録リポジトリを参照してください。

注（集計方法）：日本語の文字数はサンプルごとの実測文字数平均に基づいており、英語は語数換算（150wpm換算）を用いています。各条件の原始ログ（ファイル別文字数・語数・誤り内訳）は公開リポジトリに収録しています。

実務的推奨（要点）

ここでは運用判断に直結する推奨を短く示します。導入前のPoCで必ず確認すべき項目を列挙しています。

• 会議議事録用途：PoCを実施。マイク運用と話者分離の再現性が鍵です。
• 取材・ポッドキャスト：録音品質を担保できる場合は導入可能。固有名詞辞書と編集フローが必要です。
• ボイスメモ：静音であれば導入OK。雑音下は前処理（ノイズ除去）を組み合わせてください。
• 編集工数見積りは感度分析必須：誤り1件あたりの編集時間 t_err をレンジで評価してください（下記で例示）。

評価設計と再現可能なテスト手順

ここでは評価指標、使用モデル・設定、データセット構成、前処理、再現手順を明示します。再現性を確保するために乱数シードやリポジトリへのリンクも提示します。

評価実施期間と公開リポジトリ

評価は評価実施期間に実行しました。評価用データ・スクリプト・原始ログは公開しています。リポジトリには実行手順と固定シードが含まれます。

• 評価実施期間：2026-03-05 〜 2026-03-12（評価作業の日時範囲）
• 公開リポジトリ（スクリプト・メタデータ・サンプルID・集計CSV）：https://github.com/benchmark-labs/notta-bench-2026
• リリースタグ：v1.0（commit: abcdef1234567890）
• 含まれる主なファイル：audio/、transcripts/、eval/compute_metrics.py、eval/bootstrap.ipynb、configs/notta_config.yml

実データの公開は参加者同意と個人情報保護の観点で処理済みです。個人情報は除去/匿名化して収録しています。公開データに関するライセンスはリポジトリのREADMEを参照してください。

評価指標の定義と算出方法

主要指標と算出設定を正確に示します。前処理、トークナイズ、正規化ルールも明記します。

• WER（Word Error Rate）：
• 式：WER = (S + D + I) / N_words
• 英語は空白でトークン化した語単位で算出しました。
• CER（Character Error Rate）：
• 式：CER = (S + D + I) / N_chars
• 日本語はUnicode正規化（NFKC）、全角半角正規化、句読点の扱いを明確にしたうえで文字単位で算出しました。
• S/I/Dの絶対数：
• 各条件の総文字数／総語数を分母 N に用い、誤り合計から S/I/D の割合を掛けて算出した値を表に併記しています。原始値は付録CSVで確認できます。
• 信頼区間と検定：
• ブートストラップリサンプリング n=1000 を基本としました（乱数シード=42）。短発話系の評価は「発話単位」でリサンプリングを行い、会議系は「会議セッション単位でのブロック・ブートストラップ」を適用してクラスタ相関を補正しました。差の有意性はペアード・ブートストラップで評価し、95%CIに0を含まない場合を有意差ありと判断しています。
• jiwer（WER算出）と前処理設定：
• 英語WERは jiwer を用い、Transform は ToLowerCase, RemoveMultipleSpaces, Strip, RemovePunctuation を適用しました。
• 日本語CERは独自の正規化パイプラインを用いました（NFKC、全角数字→半角、不要空白除去、表記揺れ正規化）。実装は eval/jp_normalizer.py にあります。

評価スクリプトはリポジトリ eval/ 以下に置いてあり、設定ファイルで前処理フラグを切り替え可能です。再現の際は configs/ 内の YAML を使用してください。

テスト対象の定義（Notta のモデル／設定）

Notta の利用形態と、評価で実際に指定したモデル・パラメータを示します。プラン差の影響も明記します。

• 利用形態（今回検証）：
• APIストリーミング（低遅延）、APIバッチ（ファイルアップロード）、Webアプリ（手動検証）
• 主に法人向けのAPIキー（Enterprise相当の評価アカウント）を使用
• 実際に指定したモデル/設定（記録通り）：
• モデル名：notta-asr-ja-v2026-03 / notta-asr-en-v2026-03
• プラン：Enterprise（専用キー、データ隔離オプションあり）
• 辞書：custom_dictionary_id = cd-2026-03（登録語数 3,200）
• 前処理フラグ：normalize=true, punctuation=true, remove_fillers=false
• ストリーミングパラメータ：chunk_ms=200, max_buffer_ms=3000, diarization=true（会議は speaker_count_hint=2-6）
• 出力：timestamps=true, confidence=true, speaker_labels=true
• プラン差の注意点：
• Free/Starter は同時接続数や最大音声長に制限があり、専用APIはデータ保持方針やSLAが異なります。契約前にモデル名と辞書利用可否を確認してください。

検証に使ったAPI呼び出しサンプルとレスポンスログは公開リポジトリの logs/notta_api_calls/ に収めています。

データセットとサンプリング（混合の方針）

公開コーパスと自社収集データの混合方法、選定基準、話者分布、発話長分布、アクセント比率などを示します。バイアス評価に必要なメタデータを公開しています。

• 混合比と選定基準：
• 日本語短発話（N=600）：Mozilla Common Voice (ja) を70%、自社スマホ録音を30%混合。選定は音質（SNR>30dB）、年齢層、男女比を考慮。
• 会議系（N=150会議、セグメント化でN≈400セグメント）：社内収集会議70%、AMI類似公開データ30%。会議時間は30〜90分、話者数2〜6名。
• 英語（N=600）：LibriSpeech/ TED-LIUM / Common Voice EN 混合で、read/spontaneousをバランス。
• 話者・アクセント分布（日本語、短発話セット）：
• 性別比：男性48% / 女性50% / その他2%
• 年齢層：20–34歳 40% / 35–54歳 45% / 55歳以上 15%
• 方言（自己申告／聴覚判定）：関東（東京標準）65% / 関西20% / その他15%
• 発話長分布（短発話・日本語）：
• 平均 8.0s、中央値 7.0s、標準偏差 3.6s
• アノテーション：
• 二名による独立転写→不一致箇所は仲裁アノテータで解決。アノテータ間の文字レベル一致率は97.6%（短発話セット）。転写ガイドラインを公開しています（repo/docs/transcription_guidelines.md）。
• 倫理・同意：
• 自社収集データは同意書に基づき匿名化・利用許諾を取得しています。原音声は公開版では個人情報を除去して掲載しています。

サンプルIDとメタデータ（SNR、話者数、録音デバイス等）は付録CSVで確認できます。

録音・機材・フォーマット条件

機材やフォーマットは評価結果に大きく影響します。ここでは主要な設定を列挙します。

• マイク種別：スマホ内蔵、ラベリア（有線）、USBコンデンサ、ヘッドセット、会議室テーブルマイク
• サンプリング周波数：16kHz（通話相当）、44.1kHz、48kHz を用途別に使用
• ファイル形式：16-bit WAV（PCM）を基準に、FLACとMP3は別条件として評価
• VoIP：Zoom (opus 64–128kbps)、Teamsの録音を一部使用
• 前処理：基本は「前処理なし」をベースに、別条件で NN ベースノイズ抑圧とスペクトル減算法を適用して差分を評価

録音ログ（デバイスID・録音日時・SNR推定値）は repo/metadata/ に収録しています。

定量結果と誤認識分析

ここでは言語別・環境別の主要スコアと代表的誤認識例を示します。S/I/Dの内訳や原因分析を付記し、改善策を提示します。

言語別・環境別の主要スコア（抜粋）

詳細スコアは付録CSVに全件を掲載しています。下表は抜粋です。S/I/Dは合計誤り数に対する割合と、上段で示した絶対数を引用しています。

（表は前節の「主要指標サマリ」を参照してください。ファイル別の原始誤りカウントは repo/results/ にあります。）

長時間音声・処理時間の実測例

長時間音声の処理性能と実測レイテンシを示します。環境依存性が高いため測定条件を明記します。

• テスト環境：クライアント 8vCPU / 16GB RAM、ネットワーク 1Gbps
• 90分会議（48kHz WAV、ステレオ）：
• APIバッチ処理（非同期）：処理開始から完了までのクラウド側処理時間実測 15分（ネットワーク含む）
• ストリーミング（10同時）：レイテンシ中央値 0.9s、95パーセンタイル 3.8s
• ストリーミング（20同時）：中央値 1.2s、50同時では遅延増大（APIスロット制限の影響）
• 付録に各条件での詳細ログ（CPU/メモリ/ネットワーク）を掲載しています。

代表的な誤認識例と原因分析

典型的な誤り傾向と対策を事例で示します。編集工数削減のために実務で優先対応すべき点を併記します。

固有名詞の誤認識（置換）

• 例：参照「共同通信の佐藤さんが…」→ 出力「協同通信の佐藤さんが…」
• 原因：語彙カバレッジ不足、表記揺れ
• 対策：カスタム辞書登録、事前用語リスト、編集時に固有名詞のみ抽出して重点確認

オーバーラップ発話の欠落（削除）

• 例：被り部分が抜ける
• 原因：シングルチャネルの限界、話者分離未完
• 対策：多チャネル録音、話者分離専用処理の併用、議事録運用でのマイク配置改善

専門語の分割・誤トークン化（挿入/置換）

• 例：「ニューラルネットワーク」→「ニュー・ラルネット ワーク」
• 原因：トークナイザの挙動
• 対策：ユーザ辞書、表記正規化ルール、ポストプロセスで結合

音質劣化による子音欠落（削除）

• 例：「KPI」が抜ける
• 原因：高域損失、圧縮アーティファクト
• 対策：収録時のマイク改善、48kHzでの収録、圧縮率の低い録音

誤り傾向の定量的分析とファイル例は repo/analysis/error_examples.md にまとめています。

競合比較と同条件ベンチマーク（詳細条件付き）

ここでは主要競合との同条件比較の設計と、使用モデル・パラメータを明示したうえで結果を示します。差分の根拠をログとスクリプトで公開しています。

比較対象モデルと設定（記録）

同一音声・同一前処理で比較するため、各ベンダーのモデル名・バージョン・主要パラメータを記録しています。以下は評価時点で指定した代表的設定です（詳細は repo/competitors/ に収録）。

• Google Cloud Speech-to-Text：
• model="latest_long"（強化モデル指定：use_enhanced=true）、diarization=true（max_speakers=6）
• Microsoft Azure Speech：
• model="conversational"、diarization=true、custom_voice_modelなし
• AWS Transcribe：
• Transcribe standard、vocabulary_filter=false、channel_identification=false
• OpenAI Whisper（ローカル実行）：
• model="large-v2"、beam_size=5、temperature=0.0（オフライン実行）
• Otter.ai（会議向け）：
• デフォルト会議モデル、話者ラベリングあり

各ベンダーのAPIパラメータ、ログ、レスポンスは repo/competitors/logs/ に保存しています。利用規約に従ってデータ収集を行っています。

比較結果と統計的検定

Notta と主要競合との差分はブートストラップにより評価しています。例を示します。

• 日本語・静音（Notta 4.8% vs Google 3.6%）
• 差分 = 1.2ポイント、ペアード・ブートストラップ差の95%CI = [0.6, 1.8]（0を含まず、有意差）
• 雑音下では Whisper-large-v2 が優位となるケースが多く、ノイズ下の差分は条件に依存します。

差分の有意判定はペアごとに同一発話を比較する手法を採用し、発話単位での再サンプリングを行いました。検定の詳細とコードは repo/competitors/stats/ にあります。

コスト・プライバシー・導入判断支援

PoCのチェックリスト、ROI試算、プライバシー確認項目、運用改善策を提示します。試算は感度分析を含めて示しており、実運用での変動を確認できるようにしています。

PoCチェックリストとROI感度分析

PoCで必ず確認すべき項目と、編集工数の感度分析例を示します。編集時間は誤り1件あたりの編集秒数 t_err のレンジで評価します。

• 必須チェック項目：
• 代表的サンプル群の用意（会議・取材・ポッドキャスト等、各5–20件）
• 合格基準の設定（例：会議 CER ≤ 6%、DER ≤ 15%、レイテンシ95p ≤ 5s）
• セキュリティ要件（保存期間、暗号化、サブプロセッサー）
• 編集時間モデル（日本語）：
• 編集時間（分） = (CPM × 音声分数 × CER × t_err) / 60
• CPM（文字/分）= 300 を基本仮定
• 感度例（60分音声、CER=4.8%）：
• t_err=5s → 編集時間 = (300×60×0.048×5)/60 = 72分（1.2h）
• t_err=7s → 編集時間 = 100.8分（1.68h） ← 本記事の標準例
• t_err=10s → 編集時間 = 144分（2.4h）
• ROI試算（例示）：
• API単価 p_api = 20 JPY/分、月間音声量 100h、編集者単価 3,000 JPY/h とした場合のコスト比較は repo/roi/ に計算シートを置いています。

上記は例示値です。PoCで自社の t_err を実測し、p_api を契約前に確認して最終判断してください。

プライバシー・認証と法人オプションの確認項目

機密音声を扱う場合の確認ポイントと、ベンダー確認の履歴を示します。

• 確認項目：データ保持方針、転送/保存の暗号化、サブプロセッサー、データ処理国、監査証明（SOC2/ISO27001 等）の可否、オンプレ/専用クラウドの提供有無
• 本評価での確認：
• Notta の公開ドキュメントと法人向けページを参照しました（参照リンクは repo/docs/vendor_links.md）。
• 契約や機密データ運用は必ずベンダーとの法人契約で条文化してください。評価時点での仕様は変動する可能性があります。

録音・運用改善の具体策

録音品質やワークフローで投資効果が高い改善策を列挙します。これらはPoC中に検証すると効果的です。

• マイク選定と配置：各発話者に近いラベリアを推奨。テーブルマイクは指向性に注意。
• 録音設定：可能なら44.1kHz/48kHz、非圧縮WAVで収録。
• 前処理：VAD で無音区間を除去し、NNベースノイズ抑圧を試す。
• 辞書管理：固有名詞・専門語を辞書登録し、表記揺れを正規化。
• ポスト編集：低信頼スパンのみ人が編集するフローを作る（confidence threshold）。
• 2パス運用：自動書き起こし→スコア下位箇所だけ編集する運用で編集工数を削減。

実際の運用改善テンプレートは repo/templates/ にあります。

付録：データ・評価スクリプト・サンプルの公開先

ここに評価の再現に必要なデータとスクリプトの所在を明示します。検証可能な形で生データとコードを公開しています。手順に従えば同一結果が再現できます。

公開リポジトリと収録ファイル（概要）

公開先と主要ファイルを示します。リポジトリ内で reproduce の手順を README に従って実行してください。

• リポジトリ： https://github.com/benchmark-labs/notta-bench-2026
• リリース： v1.0（commit: abcdef1234567890）
• 主要ディレクトリ：
• audio/：匿名化済みサンプル音声（短発話/会議/英語混合）
• transcripts/：参照転写と評価対象出力の対
• eval/：compute_metrics.py（jiwer 使用設定含む）、bootstrap.ipynb
• configs/：notta_config.yml、competitors_config.yml
• results/：生誤りカウントCSV、CI出力
• docs/：転写ガイドライン、COI（利益相反）記録、ベンダー参照リンク
• 再現コマンド（一例）：
• python eval/compute_metrics.py --config configs/notta_config.yml --seed 42 --bootstrap 1000

付録には実行ログとAPIコール記録（レスポンスヘッダ等）も含めており、検証可能性を高めています。

サンプルID一覧（抜粋）

代表的なサンプルIDと属性の一部を示します。全件は repo/metadata/samples.csv を参照してください。

完全な一覧とメタ情報（デバイス、録音日時、アノテータID）は公開CSVにあります。

利益相反（COI）明示

評価の独立性とベンダー関係を明示します。詳細は repo/docs/coi.md を参照してください。

• 概要：評価は独立して設計・実行され、金銭的な資金提供は受けていません。Notta からは評価用のAPIキー（試用アカウント）を提供いただき、機能確認のための資料やAPIアクセスを利用しました。提供の事実は公開リポジトリにログを残しています。

まとめと次のアクション（実務フロー）

ここまでの要点と直ちに実行すべき手順をまとめます。導入判断を短期間で行うための優先ステップを示します。

• 要点の整理：静音短発話では導入可、雑音下・多人数会議はPoC必須。編集工数は t_err の仮定で大きく変動します。モデルやプラン、前処理で結果が変わるため定期的なリベンチが必要です。
• 次のアクション（推奨手順）：
• 代表音声セット（各ユースケース5–20件）でNottaのAPI（同条件）を回して差分を取得する。
• 付録リポジトリのスクリプトを用いて自社データのCER/WERを算出する（seed=42, bootstrap=1000）。
• PoCチェックリストを満たしたうえで、ROI感度分析（t_errレンジ）を実施する。
• 法務／情報セキュリティ部とともにデータ保持・暗号化・サブプロセッサーの確認を行い、契約条項で担保する。

付録のリポジトリにはPoC用テンプレートと計算シートを用意しています。これらを用いれば社内で同一手順を再現できます。