音声・対話

日本語の音声・音響データアノテーション

日本語音声に対する書き起こし、タイムスタンプ付与、話者ダイアライゼーション、意図・スロット付与、感情や方言のタグ付け。暗黙の慣習ではなく、明文化したルールに沿って作成します。

同じ日本語音声を、ルールなしで二人に書き起こさせると、3行に1行くらいは食い違います。何を話したかではなく、どう書くかで、です。

書き起こしは録音ではなく、判断の集合です

日本語には分かち書きがなく、4つの文字体系があり、音と慣用的な表記のあいだに大きな隔たりがあります。ですから音声がテキストになった瞬間に、誰かが何十もの選択をしています。有難うございます を漢字で書くかかなで書くか、3人 と書くか三人と書くか、文頭の えーっと を残すか落とすか、語の途中の言い直しをそのまま書くか整えるか。

どの選択も、単独では間違いではありません。間違いなのは、コーパス全体で不揃いに選ぶことです。一貫しない正解を学習したASRモデルは、同じ音が複数の文字列に対応すると学び、その差はそのまま誤り率に吸収されます。日本語の音声データで最も効く品質の梃子は、明文化され、実際に守られている正規化ルールです。

ですから音声のプロジェクトは、必ずその文書の合意から始めます。すでにお持ちの場合は、当社のものを押しつけず、お客様のルールを採用します。

要点

タスク種別
素起こしと整文の書き起こし、タイムスタンプ付与、話者分離、意図・スロット付与、感情と韻律、方言のタグ付け。
対応する音声
コールセンターの録音、会議、インタビュー、放送、車載・デバイス音声、自然発話の会話。
表記ルール
表記の選択、フィラー、数字、笑い、聞き取れない区間を、書き起こし開始前にすべて定義します。
標準出力
単語またはセグメント単位のタイムスタンプ付きJSON。SRT、VTT、CTM、TextGridにも対応します。
レビュー
全ファイルに対する二度目の聴取に加え、サンプルへのブラインド再書き起こし。

タスク種別

アノテーションの対象

通常は書き起こしが基盤の層になり、それ以外は同じタイムライン上に重ねていきます。

書き起こし

素起こしまたは整文。フィラー、言い直し、繰り返し、言い間違い、聞き取れない区間の扱いを明文化したルールに沿って行います。

  • 非流暢性を含む素起こし
  • 読みやすさを優先した整文
  • 聞き取り不能・発話重複の明示
  • 非音声イベントのタグ

タイミングとアライメント

セグメント、発話、単語単位のタイムスタンプ。既存の書き起こしがある場合は、それに対する強制アライメント。

  • 発話の境界
  • 単語単位のタイミング
  • 強制アライメントのQA
  • 無音区間と重複区間

話者ラベル

発話が重なる箇所やチャネルの切り替わりを含めて、誰が話しているか。実際の通話録音で最も壊れやすい部分です。

  • ダイアライゼーションと話者ID
  • 役割ラベル(オペレーター/顧客)
  • 発話重複の扱い
  • 話者属性のタグ付け

意図・スロット付与

その発話が何をしようとしていて、どんな値を含んでいるか。音声アシスタントや通話分析のために、書き起こしの上に重ねます。

  • 意図の分類
  • スロット・エンティティの範囲
  • 対話行為のラベル
  • 通話の結果と後処理区分

パラ言語のラベル付け

感情、センチメント、韻律的な強調、話し方、地域差。印象ではなく、定義したカテゴリに照らして採点します。

  • 感情とセンチメント
  • 話し方と丁寧さの水準
  • 地域差とアクセント
  • 音質と収録環境のタグ

日本語固有の論点

日本語のルールが決めなければならないこと

力量のある書き起こし担当者どうしの食い違いは、この4つでおおむね説明がつきます。

同じ語の表記の選択

ありがとう、有難う、アリガトウ は同じ語です。各担当者の判断に委ねれば、コーパスには3つとも入り、モデルはそれらを別の正解として扱います。

当社の対応 ルールに頻出語の表記を列挙し、それ以外の既定ルールを定め、納品前に自動チェックが表記の揺れを検出します。

数字と助数詞

日本語の助数詞は数えるものによって読みが変わり(一本、一杯、一人)、数字は 3 とも 三 とも 参 とも書けます。表記が揃わないと、できあがったモデルの数値の正確さは測定不能になります。

当社の対応 数字のルールで、文脈ごとにアラビア数字か漢数字かを決め、助数詞と単位の書き方を定めます。日付、金額、時刻、電話番号の実例も添えます。

言いよどみと非流暢性

あの、えーっと、まあ、そのー は自然発話の日本語に頻出します。残せば書き起こしはノイズが増え、落とせば非流暢性を扱うモデルにとって素起こしデータの意味がなくなります。

当社の対応 素起こしと整文をそれぞれ別に定義し、フィラーの一覧と表記を固定します。判断がファイルごとにぶれず、プロジェクトの設定になります。

尊敬語と謙譲語

コールセンターの日本語は尊敬語・謙譲語が濃く、速度を求められる作業では取り違えやすい表現がいくつもあります。いたします と いただきます、よろしいでしょうか と よろしかったでしょうか など。

当社の対応 対象音声に特有の敬語のパターンをレビュアーに事前共有し、敬語の誤りはレビュー工程で一つの名前のついたカテゴリとして扱います。一般的な正確さに埋もれさせません。

プロセス

音声プロジェクトの進め方

誰かが1ファイルを通して書き起こす前に、ルールの文書を作成します。改訂はバージョン管理された変更としてのみ行います。

  1. 01

    サンプル聴取と範囲の確定

    代表的なサンプルを聴きます。きれいな音声だけでなく、最も条件の悪い音声も含めて聴き、実際に何が難しいのかを特定します。

  2. 02

    ルールを書く

    表記、数字、フィラー、非音声イベント、発話重複、聞き取り不能区間、話者の役割、タイミングの粒度を、お客様の承認する文書で固定します。

  3. 03

    パイロットでキャリブレーション

    複数の担当者が同じファイルを独立に作業します。分かれた箇所はルールが曖昧だった箇所なので、そこを鋭くします。

  4. 04

    書き起こしとレビュー

    全ファイルを別の担当者が二度目に聴取します。サンプルはブラインドで再書き起こしし、実測の正確さの値を出します。

  5. 05

    納品と報告

    書き起こし、タイミング、ラベルに、ルールのバージョン、QAレポート、推測で埋めずに使用不能として扱ったファイルの一覧を添えて納品します。

納品

入出力の形式

お客様の音声を、そのまま扱います。コーデックやサンプリングレートが達成できる水準を制約する場合は、事後ではなくプロジェクト開始前にお伝えします。

日本語の音声業務でよく使う入出力形式。
レイヤー標準出力その他の対応形式
書き起こしセグメント単位のタイムスタンプ付きJSONプレーンテキスト、SRT、VTT
単語単位のタイミングJSONCTM、TextGrid
話者ラベルRTTMまたは話者ターンのJSONチャネル別の書き起こし
意図とスロットJSONL、1行1発話CSV、CoNLL形式のスパン
パラ言語ラベル時間区間付きJSONLCSV、ELANのアノテーションファイル

品質

この業務に固有の品質管理

日本語音声に対する正確さは、主張するものではなく計測するものです。しかも、易しいファイルではなく難しいファイルで計測します。

  • 別の担当者によるサンプルのブラインド再書き起こし。バッチごとに実測の誤り率を出す。
  • 納品前に、表記の揺れ、数字の書式、フィラーの表記をルールに照らして自動チェックする。
  • タイミングは隣接セグメントとの整合だけでなく、音声そのものに対して検証する。
  • 本当に書き起こせないファイルは、その旨をフラグ付けして返す。もっともらしい推測で埋めることはしない。
  • 話者ラベルはファイル全体を通して確認し、途中での取り違えを検出する。
  • QAサンプルに難しい音声を意図的に含める。報告する値が、コーパスの良い部分ではなくコーパス全体を反映するようにする。

よくあるご質問

音声・音響について

初めて日本語音声のバッチをお送りいただく前に、よくいただくご質問。

はい。音質が良い場合は、たいていそのほうが費用対効果に優れます。ただし注意点があります。機械の書き起こしを修正する作業は、画面にすでにある内容を受け入れる方向に人を引っ張ります。そのため学習データについては、ゼロから書き起こすか、サンプルにブラインドの検査を行い、修正工程が実際にどれだけ拾えているかを計測します。

方言を話されたとおりに書き起こすのか、標準的な日本語に正規化するのかを事前に合意します。この判断でデータセットの性格が丸ごと変わるからです。方言が対象に含まれる場合は変種をタグ付けし、どの変種なら確実に体制を組めて、どれが難しいかは率直にお伝えします。

電話帯域の通話音声、背景ノイズ、発話の重なりを含む、実際の録音を扱います。形式より大事なのは、代表的なサンプルを最初にお送りいただくことです。きれいな音声で範囲を決めて、ノイズの多い音声で納品する。これが音声プロジェクトの失敗の典型です。

はい。NDAとデータ処理契約のもと、ロールベースのアクセス制御を敷いた隔離環境で作業し、保持と削除の条件は契約で合意します。録音に個人情報が含まれる場合は、マスキング対象としてマークすることも、お客様側でマスキング済みの音声を扱うこともできます。全体像はセキュリティのページをご覧ください。

はい。発話の重なりは自動ダイアライゼーションが最も失敗しやすい箇所であり、人が入る主な理由の一つです。当社のルールでは、重なった発話をどう区切り、誰に帰属させるかを定義しているため、ファイルごとに判断がぶれることはありません。

音声・音響

最もきれいな音声ではなく、最も難しい音声をお送りください。

仕様書よりも、代表的なサンプルのほうが多くを語ります。ルールの草案、書き起こしたサンプル、そして見込まれる誤り率についての率直な見解をお返しします。

データをご共有いただく前にNDAを締結します。パイロットの要件定義は無料です。