自作読み上げアプリ（iOS v0.9.0／Windows v1.0）の「声の世代交代」設計資料。iOSは既存Azure資産を活かしたDragon HD、WindowsはAivisSpeech（ローカル・0円）、実験枠にOpenAI gpt-4o-mini-ttsの3案を、なぜ×3の深掘り・費用・工数・落とし穴まで一枚に集約した。
ja-JP-Nanami / Masaru HD（GA）。LLMベースで文脈から抑揚を自動生成
SAPI Haruka(2013世代)から2世代ジャンプ。CPUのみ・外部送信ゼロ
「声の人格を文章で指示」できる唯一級のAPI。Provider化の実証台
先に結論: ElevenLabsは品質最高峰だが1冊≈¥4,500で長文用途とコスト構造が合わず見送り。GPT-Live（ChatGPTの新音声）はAPI未提供のため現時点で組み込み不可。ChatGPT提案書は要件定義として優秀だが、28項目中14項目が実装済み機能の再発明だった（§7参照）。
ChatGPTの音声会話を刷新した新モデル（2026-07-08発表）。聴きながら話すフルデュプレックス型
2025-03公開のTTSモデルのデモサイト。openai.fmで無料試聴できる
教訓: 「ChatGPTで聞こえた声」と「APIで買える声」は別製品。GPT-Liveの声を今日のアプリに入れる手段は存在しない。買えるのは gpt-4o-mini-tts（openai.fm）の系統で、これは十分良いが同じ声ではない。
<lang>対応 → 日英混在の読みが改善見込みリスク: ①Japan East非対応→southeastasiaに新S0リソース ②<prosody>非対応→現行4倍速の作り直し ③F0無料枠対象外→予算アラート必須（§6参照）
リスク: ①このPCでの合成速度は未実測（導入前1hの実測をStep 0に組込） ②SAPIのSpeakProgress相当がなく単語ハイライト→文単位に粗くなる ③常駐メモリ1.5GB+
instructionsに「30代後半の落ち着いた日本人ナレーター…」等の声プロンプトを直接渡せる（ChatGPT提案書§3の理想声文がそのまま使える）リスク: APIキー管理が2系統に増える → Keychain移行（§7採用項目）とセットで実施。usage hard limit $5設定。
バーは金額（線形スケール）。ElevenLabsだけ桁が違うことが、この図の主旨。
| 作業 | 根拠 | 見積 |
|---|---|---|
| southeastasiaにS0リソース作成＋予算アラート設定 | HD音声はjapaneast非対応・F0対象外（公式リージョン表で確認） | 1h |
| リージョン・声名の切替 | 両方とも設定画面の入力値（AzureConfig実装確認済）→ コード変更ほぼゼロ | 0.5h |
SSML分岐: HD時は<prosody>除去＋temperature付与 | 現行ssml()はprosody rate固定挿入（AzureSpeechEngine.swift:209）。HD判定1分岐＋キャッシュキーは既に声名込みで安全 | 1–2h |
| 速度UI調整（HD時は2倍上限表示） | iOS標準声で同じ「上限案内」パターンを実装済み → 流用 | 0.5h |
| 実機試聴・Nanami HD vs 標準の比較 | CIビルド→AltStore反映の確立済み手順 | 1–2h |
| （任意）4倍速の復活: AVAudioPlayer→AVAudioUnitTimePitch | 再生系の載せ替えで再生バー・バックグラウンド再生の回帰テストが必要 | +4–6h |
| 作業 | 根拠 | 見積 |
|---|---|---|
| 導入＋このPCでのCPU合成速度実測 | GPUなし環境の実速度は未検証 → 最初に測って中止判断を可能に | 1h |
| Engine起動管理（プロセス検出・ポート疎通・未起動案内） | 常駐前提のローカルサーバー。ReadAloud.ps1起動時のヘルスチェック追加 | 2–3h |
| 合成API呼出＋WAV再生キュー＋チャンク先読み1本 | audio_query→synthesisの2段呼び出し。System.Speechの同期発話をプレイヤー方式に転換する部分が本体 | 4–6h |
| ハイライトを単語→文単位に再設計 | SpeakProgress相当イベントなし。既存Build-Spokenの位置写像は文粒度で流用可 | 2–4h |
| 速度（speedScale）＋読み方辞書の接続 | 辞書置換は既存Load-ReadingRulesを合成前テキストに適用するだけ | 1–2h |
| Engine不達時のSAPIフォールバック | iOS版と同じ「代替案内つきフォールバック」パターンを踏襲 | 1h |
| 作業 | 根拠 | 見積 |
|---|---|---|
| TTSProviderプロトコル化（ChatGPT提案書§6） | PlaybackControllerの合成呼び出しは3箇所（通常/ローカルfallback/先読み）と特定済み → 抽象化の切断面が明確 | 4–6h |
| OpenAIProvider実装（REST＋instructions＋mp3受信） | Azure実装と同型のURLSession POST。既存キャッシュ・再生経路に乗せる | 3–4h |
| APIキーのKeychain移行＋設定画面（2社対応） | 現状UserDefaults保管を実装確認 → ChatGPT提案書§13は正当、まとめて対処 | 2–3h |
| 音声比較画面（§17簡易版: 同一文を各Providerで生成・採点保存） | 新規View＋評価のJSON保存。LibraryStoreの1件=1JSONパターンを流用 | 4–6h |
<prosody> 非対応 → 現行4倍速が壊れる
現行実装は prosody rate（-40%〜+100%）×プレイヤーレートの掛け算で4xを実現。HDではprosody自体が無視/エラーになる。
&のエスケープは確認済み。Web/PDF/OCR由来の本文が<等でSSMLを壊さないか（注入面はここだけ）の全記号確認は未実施。
監査の結論: この提案書は「音声要件の言語化（§3）」と「比較の方法論（§17–18）」が最大の収穫。一方で実装計画部分は既存アプリを知らない前提で書かれており、そのまま実行指示に使うと大規模な手戻りになる。要件は使う、工程表は捨てる。
①Azure音声ギャラリーで Nanami HD vs 標準Nanami vs Mayu を聞き比べ ②openai.fmで声プロンプトを試す ③AivisSpeechをPCに入れて長め段落3本の合成時間を計測。
southeastasiaにS0作成→予算アラート→SSML分岐→実機試聴。ダメなら設定値を戻すだけで完全ロールバック可。
Engine起動管理→合成キュー→文単位ハイライト→SAPIフォールバック。Step 0の実測値で先読み本数を決める。
プロトコル抽象化→OpenAIProvider→Keychain移行→§17比較画面。以後の新エンジン（GPT-Live API等）はProvider追加だけになる。
| 項目 | 点検結果 |
|---|---|
| ログ | 合成失敗はUI表示＋フォールバック案内（実装済み）。月次文字数はAzureメトリクスで確認。ログ・キャッシュにAPIキーと本文全文を書き出さない（現状も準拠）。 |
| 費用上限 | HD導入と同時にAzure Cost Managementで月¥1,000予算アラート設定（手順に組込済み）。最悪放置額: 月30万字全てHDでも約¥990。OpenAIはusage hard limit $5。AivisSpeechは¥0。暴走対策はキャッシュ＋チャンク上限（既存）。 |
| 権限 | 要改善→Plan Cで対処: APIキーが現状UserDefaults保管（コード実測）→ Keychainへ移行。キーはSpeechリソース限定スコープ。コード直書きなし（設定画面入力式）・リポジトリprivateは現状OK。 |
| 監査 | 本図解＋Vaultノートで選定根拠を資産化。初回請求サイクル（S0化30日後）に実測費用を点検。比較画面の採点をアプリ内保存し声の変更履歴を追跡可能に。 |
| prompt injection | 読み上げは外向き操作なしで低リスク。唯一の注入面=外部本文→SSML: &エスケープ確認済み・全記号網羅はPlan A時に点検。LLM前処理は不採用のため注入経路を増やさない。 |