音声入力の後に、二つのことを確かめる
名前を直す、長い文章を段落に分ける、列挙を箇条書きにする、メールの挨拶と本文を分ける。単語が合っていても、使える文章になるまでに仕事が残ることがあります。単語誤り率(WER)だけでは、この負担は表せません。
- 貼り付け後、どれだけ編集が必要か。単語の訂正、書式の修正、使える状態までの時間を測る。
- 最初の出力は、どれだけ理解しやすいか。文章を整理し直さずに、依頼・締め切り・要点がわかるかを確かめる。
この記事は評価方法の提案です。例や計算は説明用であり、VoiceOSや他製品の測定結果ではありません。編集の負担と読みやすさを分け、意味が正しいことも確認します。
実際の入力先に入った文章から始める
短い返信、複数段落のメール、作業のリスト、会議メモ、名前と数字、途中で言い直す文など、普段の仕事に近い課題を選びます。音声、人が確認した書き起こし、完成文で伝えるべき内容を保存してください。
編集する前の最初の出力を、そのまま残します。単語比較用のプレーンテキストに加え、段落・箇条書き・余白がわかる画像やリッチテキストも保存します。プレビューがきれいでも、GmailやSlackへ入れたときに一つの塊になるなら、その違いが重要です。
比較するツールでは入力先、音声、関連設定をそろえます。「改行して」と明示した場合と、話題の変化から自動で段落を作った場合は、別の能力なので分けて試します。
試す前に「使える状態」の条件を決めます。事実と意図が正しく、内容が欠けず、入力先に合った構成になっていることです。修正は必要最小限にし、好みで行う書き換えは別に記録します。
貼り付け後に残る編集作業を測る
最初の出力が目的の入力欄に入り終わった時点で計時を始め、書き手が確認を終えて送信・保存できると判断した時点で止めます。認識や入力そのものの待ち時間は別に残してください。
横にスクロールすると表全体を読めます →
| 指標 | 記録方法 |
|---|---|
| 修正なしで使えた割合 | 内容と書式を変えずに確認基準を満たした試行数を、対象となる全試行数で割る。入力失敗は成功に数えない。 |
| 完成文100語あたりの修正数 | 最初の出力と必要最小限の修正後の文を比較。最小の挿入・削除・置換数を完成文の語数で割り、100を掛ける。 |
| 書式の修正 | 段落の分割・結合、箇条書き化、字下げ、メール配置の修正を別に数える。「改行一つ」「リストへの変換一回」など単位を決める。 |
| 使える状態までの時間 | 確認時間、実際の修正時間、貼り付け後の合計経過時間を分ける。修正ゼロでも確認時間を残す。 |
たとえば完成文100語に8語の修正なら、100語あたり8修正です。段落を二つ追加し、文章を一度リストに変えたなら書式修正は3回。確認20秒、修正40秒、待機なしなら合計60秒です。いずれも説明用の計算であり、製品の成績ではありません。
単語の分割と正規化のルールも記録します。英語なら空白で分割し、大文字・小文字や単語に付く句読点を残し、レイアウト用の記号を除く方法などがあります。日本語には別の分割規則が必要です。改行などは元の見た目として別に保存します。
編集距離をそのまま時間に換算してはいけません。一語の置換でも、単純な誤字と、数字の根拠を調べ直す作業では負担が違います。詳しく調べる場合は同意を得て修正操作を記録し、認識、意味、書式、好みに分けます。
NISTの使いやすさに関する資料は、作業時間、誤り、完了、利用者の意見を組み合わせて評価しています。ここではその考え方を音声入力に応用していますが、この評価表自体は標準規格ではありません。[2]
出典・参考資料: Usability Testing
段落、箇条書き、メールの形を確認する
未編集の最初の出力を評価します。どこで話題が変わるか、どの項目が一組か、何に返答すべきかが見えることが大切です。言葉が正しくても、毎回構成を直す必要があるなら、その作業も評価に含めます。
同じ言葉でも、読みやすさは変わる
ひと続きの文章
Alexさん、 金曜日に必要なものです。 修正版の資料を送ってください。 公開日を確認してください。 予算の見積もりを共有してください。 すべて15時までにお願いします。 よろしくお願いします。Sam
段落と箇条書き
Alexさん、
金曜日に必要なものです。
- 修正版の資料を送ってください。
- 公開日を確認してください。
- 予算の見積もりを共有してください。
すべて15時までにお願いします。
よろしくお願いします。Sam
空白や箇条書き記号を無視する採点なら、同じ語列の二つの版は同じWERになり得ます。しかし、三つの依頼や締め切りを見つけやすいかまではわかりません。読み取りやすさは別に試します。
下のGmailの修正後の下書きでは、段落、候補日時のリスト、署名が分かれています。評価では、この形になるまでに必要だった編集と時間を記録し、最初の出力と完成文を別々に採点します。

横にスクロールすると表全体を読めます →
| 確認項目 | 使いやすい出力 | 修正が必要な出力 |
|---|---|---|
| 段落 | 関連する文がまとまり、話題の変化で段落が分かれる | 一つの大きな塊、または意味に関係なく毎文で改行 |
| 箇条書き | 項目を区別でき、順序が重要なら番号がある | 項目が混ざる、階層や順序が誤解を招く |
| メールの配置 | 挨拶、本文、依頼、結びが適切に分かれる | 署名が本文に混ざる、話していない件名や約束が足される |
| 句読点と見出し | 文の区切りが明確で、必要な箇所にだけ見出しがある | 句読点の欠落や不要な見出しで読みにくい |
| 入力先での表示 | アプリに入れた後も構成が維持される | 箇条書きや空行が消える、Markdown記号がそのまま出る |
出力を見る前に、今回使う項目を決めます。各項目を「2:そのまま使える」「1:理解できるが小さな修正が必要」「0:構成が欠ける、または誤解を招く」と評価し、関係のないものは対象外にします。項目ごとに報告し、見出しや箇条書きが多いほどよいとは考えません。
W3Cのページ構造のガイドは、意味のある見出しや内容の整理が理解・移動を助けることを説明しています。この考え方を参照していますが、上の0〜2の評価はW3Cの採点や認証ではありません。[3]
出典・参考資料: Page Structure Tutorial
読み手が情報を見つけるまでを測る
構成のチェックだけでなく、実際の読み取り課題も用意します。未編集の出力を入力先のまま見せ、「Alexが送るものは三つとも何か」「いつまでか」など、正解を先に決めた質問を出します。
文章と質問の提示から回答までの時間を記録し、正確さと漏れの有無を採点します。正答時の時間に加え、誤答率と時間切れも報告してください。早く間違えた回答は、読みやすさの改善ではありません。感想の評価も補助にはなりますが、課題の結果に代わるものではありません。
書式だけを比べるなら文言をそろえ、配置だけ変えます。製品全体を比べるなら実際の出力を使い、文言や意味の違いも残します。製品名を隠して順序を無作為化し、繰り返しでは同程度の別の文章を使って、答えの暗記を避けます。
書き手の修正負担と読み手の理解は分けます。書き手は言いたかったことを知っているため、受信者が困る点を見逃す場合があります。想定読者に近い人と、普段の画面・支援機能の設定で試しましょう。
事実と意味を、合格の条件にする
名前、日付、金額、否定、約束の変化は別に記録します。「ない」が一語抜けただけで指示が逆になることがあります。個人メモでは問題にならない表記でも、顧客への文面では許されない場合があります。製品の結果を見る前に、重要な誤りの区分を決めてください。
正しい意味は、美しい書式で埋め合わせられるものではありません。期限が違うメールは、見た目が整っていても送れる状態ではありません。名前、数字、否定、約束、作り足された内容を課題の条件と照合します。
空の出力、違う欄への入力、再試行、時間切れも記録します。入力欄に届かなかった試行には「貼り付け後の完了時間」がありません。ゼロ秒にしたり集計から黙って除外したりせず、失敗として残します。使えない録音を除く場合も、全製品に同じ規則を適用します。
単語誤り率は、補助的な指標として使う
WERは、置換・削除・挿入の合計を、正解文の語数で割ったものです。句読点、大文字・小文字、数字、短縮形、単語分割などの規則で値が変わるので、採点前に決め、全製品でそろえます。
英語の正解文が「send the revised brief tomorrow」(5語)で、出力が「send the brief tomorrow」なら、revisedが1語抜けています。WERは1÷5=20%です。これは算数の例であり、特定製品の評価ではありません。
全体の値を出す場合は、誤りの数と正解語数をそれぞれ合計してから割ります。文ごとの比率の単純平均では、2語の指示と長文が同じ重みになります。集計法を示し、個別の結果も残してください。
日本語と英語が混ざる場合は、分割規則も必要
例文として「明日のdesign reviewは午後3時です。FigmaのリンクをSlackで送ってください。」を使えます。日本語の構文、英語の製品名、時刻、勝手な翻訳や表記変更を確認するための説明用文面です。実測した書き起こしではありません。
名前の正しい綴りと許容する表記揺れを記録します。日本語は英語のように単語間を空白で分けないので、WERは分割器に強く依存します。分割器と正規化を明示し、必要なら規則を定めた文字誤り率も加えます。どちらの場合も、固有名詞と意味の確認を残してください。
複数の話者と自然な言語の切り替えを含めて試します。一つの例文だけで「日本語で最も正確」とは言えません。単語リストを使えるなら他製品にも同等の情報を与えるか、設定の違いとして報告します。
他の人が再現できる記録を残す
- 課題・音声のID、製品とアプリのバージョン、日付、OS、マイク、入力先、録音への同意。
- モード、言語、単語設定、書式への指示、書き起こし、伝えるべき内容。
- 最初の文字列と見た目、修正後の文字列と見た目、正規化と差分の計算規則。
- 必要な単語修正、書式修正、好みの書き換え、確認・修正・合計時間。
- 修正なしでの合格、意味と事実の確認、再試行、入力失敗、時間切れ。
- 構成の項目別評価と対象外の項目、読み取り問題、正答、回答時間、提示順。
書き手、読み手、音声、試行の数を報告し、短い返信、メール、リスト、長いメモなどで分けます。修正なしで使えた割合、完成文100語あたりの修正数、書式修正、修正時間と合計時間の中央値、ばらつきを示します。90パーセンタイルは、意味のある推定ができる標本数がある場合に限ります。
完了した試行だけの時間集計なら、その条件を明示して失敗数と並べます。読み取りやすさは、構成の項目別評価、正答率、正答時の時間として別に示します。重みの根拠を示さずに、すべてを一つの「精度」にまとめないようにしましょう。
許可を得た音声や出力を可能な範囲で公開し、選び方と自社製品への関係も説明します。大切なのは、どれだけ作業が残り、最初の出力がどれだけ読めるかを、再現できる形で伝えることです。
出典と調査方法
更新日:.
WERの定義、NISTの使いやすさの指標、W3Cの構造に関する資料を参照し、修正負担と読み取りやすさを分ける評価方法を提案しています。例文と採点表は説明用です。 留意点:この手順による製品間比較は実施していません。編集距離は実際の負担の代わりにならず、構成の評価だけで読み手の理解を証明することもできません。
- Word Error Rate metric — Hugging Face Evaluate
- Usability Testing — NIST
- Page Structure Tutorial — W3C Web Accessibility Initiative
よくある質問
WER以外に何を測ればよいですか?
最初の出力を直す負担と、未編集の出力の読み取りやすさを分けます。単語・書式の修正、使えるまでの時間、修正なしの合格率に加え、読み取り課題を使います。意味と事実の正しさは合格の条件です。
編集量はどう計算しますか?
最初の文と必要最小限の修正後の文で、単語の挿入・削除・置換を数え、完成文の語数で割って100を掛けます。書式修正と実際の時間は別に記録します。
WERが完璧でも読みにくいことはありますか?
あります。空白やリスト記号を無視する採点では、同じ語列の一段落と、段落・箇条書きに整理した文が同じWERになります。入力先の見た目は別の確認が必要です。
主観だけに頼らず読みやすさを測るには?
未編集の文を見せ、依頼や期限について正解を決めた質問を出します。正答率と時間、誤答、時間切れを記録します。書式だけの比較では文言をそろえ、提示順や文章を変えて学習の影響を減らします。
これはVoiceOSや他製品の実測結果ですか?
いいえ。説明用の例を含む評価手順です。順位を付けるには、同じ条件で実際に試し、設定・出力・結果を記録する必要があります。
英語のWERで日本語も公平に比べられますか?
日本語の分割と正規化の規則が必要です。文字単位や固有名詞の確認も加え、言語が混ざったときの意味、修正負担、読み取りやすさを確かめてください。
