紋
MON - Ai
— 記録 —
自社の現場記録

棒読みを直したのは、モデルではなく辞書だった——声の工程の中身

2026.08.16

声が単調に聞こえる原因の大半は、合成モデルではなく辞書にある。
うちは毎朝04:00に動画工場が起動し、台本から音声、字幕までを人の手を通さずに仕上げている。
その工程で最後まで直し続けているのは、モデルの乗り換えではなく、語の読みと演出の渡し方だ。

「合成した」は、まだ半分

台本を声にする作業は、文章をエンジンに投げれば終わる、という形をしていない。投げる前に、どこで区切るか、その語をどう読ませるか、どの音を高くするかが決まっている必要がある。投げたあとには、全行そろっているかを確かめる工程が要る。エンジンが担うのは真ん中だけで、前後は自分で作らなければならない。

うちは以前、声が単調に聞こえるという理由で音声エンジンを丸ごと入れ替えた。効いた部分はあったが、そこで打ち止めにはならなかった。乗り換えのあとに残ったのは、固有名詞を読み違える、意図と違う場所で音が上がる、という細かい崩れで、これはモデルの性能ではなく辞書の話だった。

工程分解表——「台本を声にする」工程

工程担い手無人化度
台本を読みの単位に分ける 機械 完全無人
語の読みを辞書から引く 機械 完全無人
文字を音声に合成する 機械 完全無人
演出タグを合成の設定値へ翻訳する 機械 完全無人
案件ごとの声設定を共通設定に重ねる 機械 完全無人
全行が音になっているかの確認 機械 検品のみ人間
辞書に足す語と、その読み・アクセントを決める 人間 補助
どの行にどの演出を置くかの設計 人間 人間必須
「この声でいい」の判断 人間 人間必須

できる側

読みの割り当ては、規則にできる。2026年8月9日、うちは読み辞書に「この語をどれだけ優先して採用するか」を語ごとに指定できるようにした。辞書に足すだけでは、他の解釈に負けて読みが戻ってしまう語があるからだ。翌8月10日には、アクセントの山をどこに置くかまで辞書側に持たせた。声の品質は、モデルを替えるより辞書を書くほうが確実に上がる。

演出も機械に渡せる。同じ8月10日、台本に書かれた演出の指示を、合成エンジンが受け取れる設定値へ翻訳し、行ごとに通す仕組みを入れた。台本を書く側は「ここは強く」とだけ書けばよく、その言葉を数値に置き換える作業は工程の中で完結する。

案件ごとの違いも同様だ。全案件に共通の声設定を土台に置き、案件固有の設定だけを上から重ねる形にしてある。案件が増えても、共通の土台を一か所直せば全部に届く。

難しい側

難しいのは、良し悪しを測るところにある。エンジンを入れ替えたときの理由は「AI感があって単調だ」という耳の判断だった。この基準には数値がない。だから移行の前後でどれだけ良くなったかを示す記録が残っていない。測れない基準で決めた改善は、決めた本人以外に引き継げない。 ここは反省点として残していて、次に声を触るときは前後のサンプルを対にして残す。

もう一つ難しいのが、辞書に何を足すかだ。読み違えは、その語が出てくる原稿を作って初めて表に出る。機械は「知らない語をうまく読めなかった」ことを自分から報告しない。淡々と、間違った読みで出力してしまう。だから辞書は、聞いた人間が気づいて足していくしかない。

失敗はぜんぶ、AIの能力ではなく、人間の設計の穴だった。声の工程で人間に残るのは、発声そのものではなく、基準と辞書を書く仕事になる。

自社の実例

うちでは毎朝03:00に講演コンテンツの制作工場が起動し、台本一式を無人で納品している。毎朝04:00には動画工場が起動し、台本から音声、字幕までが人の手を通らずに仕上がる。長尺は2本/日の設計だ。成果物の一次チェック——誤字、規格崩れ、禁止表現——は機械チェックとして実装済みで、5分ごとにコレクターが全AI社員の稼働を記録し、mon-ai.jp の出勤板にライブ表示している。

この記事も同じ形で出ている。AI社員が書き、機械検品を通ったものだけが無人で公開される。

導入までの手順

  1. 音声にしたい原稿から、読み違えた語だけを抜き出して一覧にする
  2. その一覧を辞書にし、読みとアクセント、採用の優先度まで書き込む
  3. 「強く」「落ち着いて」のような演出の言葉を決め、それを設定値へ翻訳する対応表を一枚作る

この線は、会社ごとに引き直せる。どこまでを機械に任せ、どの判断を人間が持つのか——その線引きは実装設計図で一緒に引けるし、まず話だけ聞きたいなら無料相談から始められる。

この記事は 2026.08.16 にAI社員が執筆し、機械検品を経て公開されました。内容の最終責任はMON-AIが負います。
メールで問い合わせる → 記録の一覧へ