<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>AudioQuery on 思いつきそうで思いつかなくていたときに</title><link>https://blog.fuga.jp/tags/audioquery/</link><description>Recent content in AudioQuery on 思いつきそうで思いつかなくていたときに</description><generator>Hugo -- gohugo.io</generator><language>ja-jp</language><copyright>Copyright(c) 2022-2025 SATO Daisuke. All rights reserved.</copyright><lastBuildDate>Wed, 05 Aug 2026 06:00:00 +0900</lastBuildDate><atom:link href="https://blog.fuga.jp/tags/audioquery/index.xml" rel="self" type="application/rss+xml"/><item><title>podcast-tool 開発日記 #10 — 抑揚への探求</title><link>https://blog.fuga.jp/posts/2026-08-05-podcast-tool-devdiary-10-audio-query-intonation/</link><pubDate>Wed, 05 Aug 2026 06:00:00 +0900</pubDate><guid>https://blog.fuga.jp/posts/2026-08-05-podcast-tool-devdiary-10-audio-query-intonation/</guid><description>&lt;p&gt;前回（第9回）は、81日間の沈黙から1月の「様子見の一往復」を経て、2月にまた0件に戻るという話だった。休眠と復活を繰り返しながらも、cast形式統合や禁則処理の改善は着実に積み上がっていた。今回はその少し先、2026年4月に開いた新しい取り組みを追う。VOICEVOXの**抑揚（イントネーション）**そのものに手を入れるための仕組みだ。&lt;/p&gt;
&lt;h2 id="読み上げてみないと分からない問題"&gt;&lt;a href="#%e8%aa%ad%e3%81%bf%e4%b8%8a%e3%81%92%e3%81%a6%e3%81%bf%e3%81%aa%e3%81%84%e3%81%a8%e5%88%86%e3%81%8b%e3%82%89%e3%81%aa%e3%81%84%e5%95%8f%e9%a1%8c" class="header-anchor"&gt;&lt;/a&gt;「読み上げてみないと分からない」問題
&lt;/h2&gt;&lt;p&gt;VOICEVOXのようなエンジンにテキストを渡すと、音声合成のリクエストの裏側では &lt;code&gt;audio_query&lt;/code&gt; というJSONが一度組み立てられる。アクセント句の区切りやモーラごとのピッチ、話速——抑揚を決めるパラメータ一式がここに入っている。これまでの podcast-tool は、このJSONを毎回その場で作って、そのまま音声合成に投げていた。つまり「読み上げてみないと、イントネーションがおかしいかどうか分からない」。気になる抑揚があっても、確認する手段は完成した音声を聞く以外になかった。&lt;/p&gt;
&lt;p&gt;4月26日、この構造に楔を打つコミットが並ぶ。狙いはシンプルで、&lt;strong&gt;audio_queryを生成・保存する工程と、それを使って音声合成する工程を分離する&lt;/strong&gt;こと。事前にJSONを書き出してレビューし、必要なら手で直してから合成できるようにする。&lt;/p&gt;
&lt;h2 id="テストから書くという選択"&gt;&lt;a href="#%e3%83%86%e3%82%b9%e3%83%88%e3%81%8b%e3%82%89%e6%9b%b8%e3%81%8f%e3%81%a8%e3%81%84%e3%81%86%e9%81%b8%e6%8a%9e" class="header-anchor"&gt;&lt;/a&gt;テストから書く、という選択
&lt;/h2&gt;&lt;p&gt;面白いのは着手の順番だ。朝12時03分、&lt;code&gt;4341894&lt;/code&gt;「query_pipeline テストを追加（RED）」でまず433行のテストファイルが入る。実装はまだ存在しない。2分後の12時05分、&lt;code&gt;9edd985&lt;/code&gt;で &lt;code&gt;src/podcast_tool/audio/query_pipeline.py&lt;/code&gt;（238行）が実装として追加される。&lt;code&gt;normalize_tts_text&lt;/code&gt;（改行や置換辞書の正規化）、&lt;code&gt;classify_utterance&lt;/code&gt;（発話をintro/technical_list/defaultに分類）、&lt;code&gt;build_query_id&lt;/code&gt;、&lt;code&gt;save_query&lt;/code&gt;/&lt;code&gt;load_query_for_item&lt;/code&gt;、&lt;code&gt;load_manifest&lt;/code&gt;/&lt;code&gt;save_manifest&lt;/code&gt;といった純粋関数群が並ぶ、クエリ操作専用のモジュールだ。同じ分で &lt;code&gt;cache_utils.py&lt;/code&gt; にAudioQuery用のキャッシュキー関数（&lt;code&gt;a3c32cc&lt;/code&gt;）、続けて &lt;code&gt;sample/justfile&lt;/code&gt; にAudioQuery関連コマンドのテンプレート（&lt;code&gt;e935678&lt;/code&gt;）が入る。テスト→実装→周辺整備までを1時間弱でひとまとまりにしている。&lt;/p&gt;
&lt;h2 id="phase2phase3そして同日中の2つのバグ"&gt;&lt;a href="#phase2phase3%e3%81%9d%e3%81%97%e3%81%a6%e5%90%8c%e6%97%a5%e4%b8%ad%e3%81%ae2%e3%81%a4%e3%81%ae%e3%83%90%e3%82%b0" class="header-anchor"&gt;&lt;/a&gt;Phase2・Phase3、そして同日中の2つのバグ
&lt;/h2&gt;&lt;p&gt;同日16時39分、&lt;code&gt;bbcfb9c&lt;/code&gt;「&amp;ndash;prepare-audio-queries CLI を追加（Phase2）」。台本を読み込み、話者ごとにaudio_queryを生成して &lt;code&gt;queries/&lt;/code&gt; に保存するだけで、音声合成までは進まないコマンドだ。2分後の16時41分、&lt;code&gt;ccadad7&lt;/code&gt;「&amp;ndash;use-audio-queries CLI を追加（Phase3）」。保存済みのマニフェストとJSONを読み込み、それを使って合成する側の経路が入る。&lt;/p&gt;
&lt;p&gt;ただ、Phase2・3を追加した直後の17時台に、立て続けに2つの修正が入っているのが実態を物語っている。17時01分の &lt;code&gt;f500c78&lt;/code&gt; は、「&lt;code&gt;--prepare-audio-queries&lt;/code&gt; を指定したのに音声合成まで走ってしまう」というPhase2側の不具合修正。&lt;code&gt;podcast_orchestrator.py&lt;/code&gt; に専用の分岐が抜けていて、既存の合成フローに素通りしていたらしい。17時10分の &lt;code&gt;74d2f4b&lt;/code&gt; は逆にPhase3側で、マニフェストのキー名が実装と食い違っていた（&lt;code&gt;speaker&lt;/code&gt; → &lt;code&gt;speaker_name&lt;/code&gt;、&lt;code&gt;text&lt;/code&gt; → &lt;code&gt;processed_text&lt;/code&gt;、&lt;code&gt;query_id&lt;/code&gt; → &lt;code&gt;id&lt;/code&gt;）ことに加え、&lt;code&gt;main.py&lt;/code&gt; で &lt;code&gt;APP_CONFIG.clear()&lt;/code&gt; した後に &lt;code&gt;_runtime&lt;/code&gt; フラグが消えてしまう問題の修正。新設したパイプラインを両端（生成側・消費側）から通しで動かしてみて、初めて噛み合わせのズレが見えてきた、という順番だ。&lt;/p&gt;
&lt;h2 id="運用性向上とパストラバーサル修正が同じ夜に並ぶ"&gt;&lt;a href="#%e9%81%8b%e7%94%a8%e6%80%a7%e5%90%91%e4%b8%8a%e3%81%a8%e3%83%91%e3%82%b9%e3%83%88%e3%83%a9%e3%83%90%e3%83%bc%e3%82%b5%e3%83%ab%e4%bf%ae%e6%ad%a3%e3%81%8c%e5%90%8c%e3%81%98%e5%a4%9c%e3%81%ab%e4%b8%a6%e3%81%b6" class="header-anchor"&gt;&lt;/a&gt;運用性向上とパストラバーサル修正が同じ夜に並ぶ
&lt;/h2&gt;&lt;p&gt;翌27日19時15分、&lt;code&gt;208501e&lt;/code&gt;「AudioQueryパイプラインの運用性向上」。&lt;code&gt;--audio-query-id&lt;/code&gt; で特定のクエリだけを部分再生成できるようにし、&lt;code&gt;check_audio_queries_fresh&lt;/code&gt; という整合性チェックを追加した。台本やreplace辞書が変わったのに古いAudioQuery JSONを使い回してしまう事故を防ぐための仕組みだ。設定ファイル側でも &lt;code&gt;prepare_if_missing&lt;/code&gt; や &lt;code&gt;mode&lt;/code&gt; から &lt;code&gt;use_audio_queries&lt;/code&gt; を立てられるようにして、CLIオプションだけに頼らない運用を意識している。&lt;/p&gt;
&lt;p&gt;その7分後、19時22分に &lt;code&gt;f5b4f96&lt;/code&gt;「AudioQueryパストラバーサル脆弱性を修正」が入る。&lt;code&gt;audio_query.directory&lt;/code&gt; にプロジェクトディレクトリ外を指す値を渡せてしまう問題と、マニフェストの &lt;code&gt;query_path&lt;/code&gt; に絶対パスを書けば任意のファイルを読み込めてしまう問題——&lt;code&gt;Path&lt;/code&gt; の「右辺が絶対パスなら左辺を無視する」という挙動を悪用できる典型的な穴だ。&lt;code&gt;commands.py&lt;/code&gt; と &lt;code&gt;linter/checks.py&lt;/code&gt; の両方に、解決後のパスがプロジェクトディレクトリの配下にあるかを検証する処理を足している。運用性を上げるためにパスまわりの自由度を広げた直後に、その自由度が攻撃面にもなり得ることに気づいて塞ぐ——同じ夜のうちにこの順序で入っているのが、地味だが誠実な仕事に見えた。&lt;/p&gt;
&lt;p&gt;19時29分の &lt;code&gt;9fe0bed&lt;/code&gt; でドキュメントを追加し、この日の作業は締めくくられる。&lt;/p&gt;
&lt;h2 id="見えてくるもの"&gt;&lt;a href="#%e8%a6%8b%e3%81%88%e3%81%a6%e3%81%8f%e3%82%8b%e3%82%82%e3%81%ae" class="header-anchor"&gt;&lt;/a&gt;見えてくるもの
&lt;/h2&gt;&lt;p&gt;第10回で扱った一連のコミットは、機能追加そのものよりも「作った直後に自分で通しで使ってみて、ズレとリスクの両方を拾っていく」というリズムが目立った。RED→実装→周辺整備で土台を組み、Phase2・3で両端を繋ぎ、同日中にバグを2つ潰し、翌日には運用性とセキュリティを同時に見直す。VOICEVOXの抑揚という、聞いてみないと分からない曖昧な対象に対して、JSONという確認可能な中間表現を挟み込んだこと自体が、この回のいちばんの発明だったように思う。&lt;/p&gt;
&lt;p&gt;なお、来週はお盆のため一週間スキップします。次回（第11回）は8月19日の更新です。&lt;/p&gt;</description></item></channel></rss>