AI音声読み上げを使っていると、ある問題にぶつかります。
「Claude Code」と書いたとき、ちゃんと「クロードコード」と読んでくれるのか。それとも変な発音になるのか。「v2.1.3」は？「脆弱性」は？
このジャーナル自体、毎回音声読み上げ版を生成しています。エンジンはedge-ttsのFlorianMultilingualNeural。記事を書くたびに「ここ、ちゃんと読んでくれるかな」と気にしながらテキストを調整してきました。
でも、その調整がいつも勘頼りだったんですよね。
今回は「どの表記が一番うまく読まれるのか」を、条件を揃えて検証してみました。
検証の設計
ポイントは、日本人リスナー向けの音声を前提にしていることです。「Claude Code」を英語ネイティブの発音で読まれるより、「クロードコード」と和製発音で読まれた方が、日本語の文脈で聴いているときに自然に耳に入ってくる。普段の会話で僕たちが「クロードコード」と言っているように、音声でもそう聞こえてほしい。だからカタカナ置換やひらがな置換を検証パターンに入れています。
同じ内容の文章を、表記だけ変えて4パターン用意しました。
| パターン | 方針 | 例 |
|---|---|---|
| original | 英語・漢字をそのまま | Claude CodeのAPIを使って |
| カタカナ置換 | 英語→カタカナ | クロードコードのエーピーアイを使って |
| ひらがな置換 | 英語→ひらがな | くろーどこーどのえーぴーあいを使って |
| スポット置換 | 問題箇所だけピンポイント変換 | クロードコードのエーピーアイを使って、脆弱性診断の… |
テスト文は5カテゴリ。技術用語（Claude Code、API）、固有名詞（Anthropic、Gemini）、難読漢字（脆弱性、冪等性）、バージョン番号（v2.1.3）、英単語混在文（deploy、Slack、GitHub Actions）。
これを3つのボイスモデルで生成します。
| ボイス | 特徴 |
|---|---|
| ja-JP-NanamiNeural | 日本語女性（標準） |
| ja-JP-KeitaNeural | 日本語男性（標準） |
| de-DE-FlorianMultilingualNeural | 多言語男性（このジャーナルで使用中） |
合計60ファイル。全部聴き比べました。
最初に試して失敗した2つのアプローチ
実は、本命だと思っていた方法が2つとも使えませんでした。
括弧付き読み仮名 → 二重読み
Claude Code（クロードコード） と書くと、「クロードコード、クロードコード」と二重に読み上げられます。人間にとっては自然な表記なんですが、TTSエンジンは括弧の中身も律儀に読んでしまう。
改善策: 括弧読み仮名を使うなら、原稿を「人間向け」と「音声向け」に分けるしかありません。人間向けには Claude Code（クロードコード） と書きつつ、音声生成時には正規表現で括弧部分を除去して クロードコード だけ残す。あるいは最初から括弧を使わず、直接カタカナに置換してしまう方がシンプルです。今回の検証では、後者のアプローチ（直接置換）が結果的に最も安定しました。
SSMLのsubタグ → メタ情報を読み上げ
SSMLの読み替え指示（sub alias=”クロードコード”）も試しました。これならエンジン側で読みを制御できるはず。でもedge-ttsでは、タグのメタ情報（属性名やタグ名）まで音声に含まれてしまい、音声時間が伸びて全く使い物になりませんでした。
以前にも別の場面で同じ現象に遭遇していたので、edge-ttsとSSMLの相性は根本的に悪いようです。
なぜedge-ttsでSSMLが使えないのか: edge-ttsは Microsoft Edge ブラウザの内部TTS APIを非公式に利用しています。Microsoftは、Edgeが生成しうるSSML（speak + voice + prosody のみ）以外をブロックしているため、sub や phoneme は処理されません。本家の Azure Speech Service を直接使えばSSMLは正式サポートされますが、有料APIです。無料のedge-ttsで完結させるなら、SSMLに頼らずテキスト側で読みを制御するのが現実的な落とし所でした。
結果：モデルによって「最適な表記」が違う
ここからが本題です。聴き比べた結果、モデルの種類によって最適な表記戦略が異なることが分かりました。
多言語モデル（Florian）→ カタカナ置換が最適
FlorianMultilingualNeuralは、名前の通り多言語対応のモデルです。ドイツ語がベースで、日本語も話せる。
このモデルに英語をそのまま渡すと、発音が不安定になります。「Claude」が英語発音になったり、「API」のイントネーションが揺れたり。一方、カタカナに置換して渡すと、安定した日本語読みになる。「クロードコード」「エーピーアイ」とこちらの期待通りに発音してくれます。
多言語モデルは複数の言語を切り替えながら処理するため、英語テキストを見ると英語モードに引っ張られやすいのだと思います。カタカナにしてあげることで、「これは日本語として読んでね」という明確なシグナルになる。
日本語ネイティブモデル（Nanami / Keita）→ 英語そのままが基本OK
一方、日本語専用モデルのNanamiとKeitaは事情が違います。英語をそのまま渡しても、かなり自然に読んでくれる。「Claude Code」も「GitHub Actions」も、日本語話者として違和感のない発音になります。
ただし、すべてが完璧ではありません。「v2.1.3」を「バージョンにーてんいちてんさん」と読んでほしいのに、「ブイにーてんいちてんさん」と読まれる。こういうエンジンの解釈と期待がズレる箇所だけ、スポットで読み仮名に置換するのが最適でした。
もう1つの手法：pykakasi（パイカカシ）による自動前処理
リサーチの過程で、もう1つ面白いアプローチを見つけました。Pythonの pykakasi（パイカカシ）というライブラリを使って、漢字を自動でひらがなに変換してからTTSに渡す方法です。
import pykakasi
kks = pykakasi.kakasi()
result = kks.convert("脆弱性の冪等性を担保する")
reading = "".join([item['hira'] for item in result])
# → "ぜいじゃくせいのべきとうせいをたんぽする"難読漢字を手動でピックアップする手間が省けるのが利点です。ただし、pykakasi の辞書精度に依存するため、技術用語の読みが意図通りにならないケースもあります（「冪等性」→「べきとうせい」ではなく「べきひとしせい」になる等）。完全自動化は難しいものの、手動スポット置換のベースラインとして使い、間違いだけ修正するという運用なら実用的です。
まとめると
| モデルタイプ | ベース戦略 | 補助 |
|---|---|---|
| 多言語モデル（Florian等） | カタカナ置換 | — |
| 日本語ネイティブモデル（Nanami/Keita等） | 英語そのまま | 読み間違い箇所だけスポット置換 |
つまり、「モデルごとにベース戦略を変えて、個別の読み間違いはスポットで直す」が現実的な運用です。
このジャーナルの音声生成にどう活かすか
このジャーナルではFlorianMultilingualNeuralを使っています。今回の検証で分かったのは、Florianにはカタカナ置換が最も相性が良いということ。
そこで、検証結果をもとに音声生成スクリプトを実際に改良しました。主な変更点は：
– Florianが中国語読みしてしまう問題を、SSMLの言語指定をja-JPに差し替えるパッチで対策
– 英語の固有名詞・技術用語を自動でカタカナに変換する辞書（READING_MAP）を追加
– 括弧付き読み仮名の自動除去（二重読み防止）
– 「→」やダッシュの前後に短い無音を挿入して、聴きやすい間を作る
この記事の音声も、改良後のスクリプトで生成しています。これまで勘でやっていた調整に、根拠ができました。
余談：「正解」は1つじゃない
面白いなと思ったのは、「カタカナが正解」でも「英語のままが正解」でもなく、モデルとの相性で最適解が変わるという点です。
人間が読む文章では「Claude Code」と書くのが自然。でも音声エンジンが読む文章では「クロードコード」が正確。同じ内容なのに、読み手が人間かAIかで最適な表記が変わる。
これって、今後AIが音声コンテンツを生成する場面が増えるほど、意識すべきポイントになると思います。「人間向けの原稿」と「AI音声向けの原稿」を分けて持つ、あるいは変換レイヤーを挟む。そんな運用が当たり前になるかもしれません。
今回の検証コード（edge-tts一括生成スクリプト、テストケース定義、生成済み音声ファイル60個）はGitHubで公開しています。実際に聴き比べてみてください。
参考：有料TTSなら発音制御はどう変わる？
今回はedge-tts（無料）で検証しましたが、有料サービスにはもっと強力な発音制御機能があるようです。こちらは実際に試したわけではなく、ドキュメントやコミュニティの情報をリサーチした範囲でのまとめです。
Azure Speech Service（edge-ttsの本家）
edge-ttsが裏で使っているMicrosoftの正式サービスです。ドキュメントによると、SSMLをフルサポートしており、phonemeタグでIPA表記の発音指定、subタグで読み替え、さらに カスタム辞書（Custom Lexicon） で単語ごとの発音を一括定義できるようです。日本語では x-microsoft-sapi フォネティックセットが利用可能とのこと。（公式ドキュメント）
料金はNeural音声で100万文字あたり$16（約2,400円）。個人ブログの音声生成なら月100円もかからないレベルです。
Google Cloud TTS
こちらもSSML完全対応ですが、日本語向けに特に興味深い機能があります。yomigana アルファベットという独自のフォネティック指定です。（公式ドキュメント）
<phoneme alphabet="yomigana" ph="ぜいじゃくせい">脆弱性</phoneme>IPA記号を覚えなくても、ひらがなで読みを指定できるようです。もしこれがドキュメント通りに動くなら、日本語話者にとっては非常に直感的な仕組みだと思います。料金は100万文字あたり$4〜$16。
OpenAI gpt-4o-mini-tts
2025年末にリリースされた、LLMベースの音声合成です。SSMLではなく、自然言語のインストラクションで発音を制御するという全く異なるアプローチ。（公式ガイド）
response = client.audio.speech.create(
model="gpt-4o-mini-tts",
voice="coral",
input="Claude Codeを使ってデプロイする",
instructions="日本語で自然に読み上げてください。英語の固有名詞は日本語のカタカナ発音で読んでください。"
)SSMLの構文を覚える必要がなく、「こう読んで」と日本語で指示できるのが特徴です。ただし、指示通りの発音になるかはモデル次第で、確実性という意味ではSSMLの方が上かもしれません。料金は100万文字あたり$12。
VOICEVOX（無料・ローカル）
日本語に特化した無料の音声合成ソフトです。ずんだもん等のキャラクターボイスで知られていますが、技術的にはアクセント辞書でイントネーションを細かく制御できるのが強み。APIモード（HTTPサーバー）もあるため、スクリプトからの自動生成にも対応しています。ただしキャラクター色が強いため、ニュートラルなナレーション用途には向き不向きがあります。
比較まとめ
| サービス | 発音制御 | 日本語対応 | 料金 |
|---|---|---|---|
| edge-tts | テキスト置換のみ | ○ | 無料 |
| Azure Speech | SSML全機能 + カスタム辞書 | ◎ | 〜$16/100万文字 |
| Google Cloud TTS | SSML + yomiganaアルファベット | ◎ | 〜$16/100万文字 |
| OpenAI gpt-4o-mini-tts | 自然言語インストラクション | ○ | $12/100万文字 |
| VOICEVOX | アクセント辞書 + GUI調整 | ◎ | 無料（ローカル） |
個人ブログの音声生成くらいの用途なら、edge-ttsの「カタカナ置換 + スポット修正」で十分実用的です。もし「正確に読ませたい箇所が多い」「プロフェッショナルな品質が必要」という場面が出てきたら、Azure や Google Cloud TTS のSSML制御を試してみる価値はありそうです。特にGoogle Cloud TTSの yomigana は、実際に使ってみたい機能ですね。
この記事が参考になったら
Share