0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

「ずんだもん実況」という次の一手を、さくらのAI Engine自身のTTS APIで本当に作ってみた

0
Last updated at Posted at 2026-07-29

TL;DR: 前回の「超AI議事録」企画では、討議の参考資料に「音声化構想」というアイデアがすでに含まれており、討議中に参加AIの一体がそれを「ずんだもんが実況する」という具体的な形に発展させていた。ゼロから思いついた提案ではなく、既にあった構想をAIが具体化した形のようだ。ずんだもん自体はおなじみのキャラクターだが、それをさくらのAI Engine自身が持つTTS APIで実際に実現できることが分かったので、今回は複数のAIモデルによる自由討議をZoom風の映像にし、参加者ごとに異なるVOICEVOXキャラクターの声で読み上げさせるパイプラインを実際に作った。作る過程で見つかったバグ6件と、いまだに解けていない謎が1つ残っている。

テキストで自由討議→発言中のAIをTTS APIで音声化→ずんだもんの声に

前回のおさらい:議長のいないAI討議

前回の記事では、複数のAIモデルに議長を立てず、対等な立場で自由に意見をぶつけ合わせる「発散モード」という仕組みを作った。各参加者が提案を出し、お互いの提案を「Yes, and」の精神で批評し合い、最後に誰の提案が一番良かったかを相互投票する。ブレインストーミングの場をAI同士でやらせてみたら何が起きるか、という実験だった。人間が司会をしないぶん、思いがけない方向に転がるのではないか、という期待もあったのかもしれない。

前回の討議の参考資料には、「音声化構想」というアイデアがすでに含まれていた。その討議の中で、参加AIの一体がこれを「さくらのAI Engineの音声合成機能を使い、ずんだもんが討議を実況する」という具体的な形に発展させていた。ずんだもんというキャラクター自体はネット動画で使い古されているほど定番のものだが、さくらのAI Engine自身がそれを使えるAPIを実際に提供しているかどうかまでは、その時点では確認していなかった。

ずんだもんって何?

技術記事を読み慣れていない方のために、簡単に補足しておく。ずんだもんは、無料の音声合成ソフト「VOICEVOX」に収録されているキャラクターの一人で、ネット動画(いわゆる「ゆっくり実況」や解説系動画など)でテキストを読み上げる声としてよく使われている。VOICEVOXは商用・非商用を問わず無料で使え、動画の説明欄などに「VOICEVOX:キャラクター名」というクレジットを書けば利用できる、という規約になっている(出典: あんこもん音源利用規約)。

さくらのAI Engineは、このVOICEVOXの合成エンジンをAPI経由で使えるようにしたTTS(音声合成)機能を2026年2月に提供開始していた(出典: さくらインターネット公式ニュースリリース)。ずんだもんを含む8種類のキャラクター音声(ずんだもん・四国めたん・春日部つむぎ・冥鳴ひまり・東北ずん子・東北きりたん・東北イタコ・あんこもん)が使える。つまり、討議の中で具体化されていた「ずんだもんに読み上げさせる」というアイデアは、まさに討議に使っていたさくらのAI Engineというプラットフォーム自身の機能で実現できる、ということが分かった。

使える手段が実際にあるとわかった以上、「じゃあ本当に作ってみよう」という話になった。渡りに船、というやつだったのかもしれない。討議の題材として使っていたAI Engineそのものが、討議の中身を実際に読み上げる道具にもなる、というのは筋が通っているのかもしれない。

動くところまでの下ごしらえ

いきなり本番の動画を作りにいくと、途中で技術的に詰まったときの手戻りが大きい。そこで最初に、リスクの高そうな部分だけを潰す期間を設けた。ffmpeg(静止画と音声から動画ファイルを組み立てる、定番の動画・音声処理ツール)が動く環境を整え、TTS APIに実際にリクエストを送って音声が返ってくることを確認し、8種類の音声それぞれのAPI上の識別子を実機で確認し、静止画1枚と音声1本からMP4を1本作るところまでを最小構成で試した。ここで詰まっていたら企画自体を見直すつもりだったが、幸い大きな障害には当たらなかったようだ。

土台ができたところで、本体のパイプラインを組み立てた。既存のAI討議エンジンをそのまま呼び出し、発言記録の中から「読み上げるべきターン」だけを絞り込み、参加者ごとに固定のVOICEVOXキャラクターを割り当てる。あとは発言のたびに、音声合成→Zoom風の静止画フレーム生成(発言中の参加者を画面中央に拡大表示する)→ffmpegでの結合、という流れを繰り返し、最後に全セグメントを1本のMP4につなげる。

討議からMP4まで、5ステップ(AI自由討議→話すターンを選ぶ・声を割り当て→TTSで音声化→Zoom風フレーム生成→ffmpegでMP4に結合)

実際に動かして見えてきた6つの罠

実機で見つかった「6つの罠」(TTS文字数上限/FAILURE誤検知/表示名衝突/音声でない応答/タイルはみ出し/一時的な通信エラー)

モックを使った単体テストだけでは、ここに挙げるバグはひとつも見つからなかった。実際にフルパイプラインを動かして初めて分かったものばかりだった。

  1. TTS APIの文字数上限。長い発言をそのまま読み上げに投げると、APIが定める上限を超えてエラーになる。テキストを段階的に短くしながら再試行する仕組みを足した。
  2. 既存の自動レビューツールの誤検知。開発の途中で使っていた別の自動チェックツールが、「FAILURE」という単語を含むだけの無関係な文章まで「失敗」と誤って判定していた。判定条件を絞り込んで直した。
  3. 動画タイルの表示名の衝突。参加者が増えると、同じ提供元のモデル同士だけでなく、別の提供元のモデル同士でも表示名が重複し、誰の発言か分からなくなることがあった。重複したときだけ提供元名を前に付けるようにした。
  4. TTS応答の検証漏れ。APIからの応答が実は音声データではない(エラー内容が返ってきているだけ)ケースを、そのまま音声ファイルとして扱おうとしていた。ヘッダーを見て本当に音声データかどうかを確認するようにした。
  5. タイルラベルのはみ出し。参加者が10人になるとタイルが密集し、ラベルの文字が隣のタイルにはみ出して重なる問題を目視で見つけた。文字がはみ出しそうなときにフォントサイズを自動で縮める仕組みを足した。
  6. 一時的な通信エラーへの弱さ。参加AIのうちの1体が、一時的なエラーで応答をまるごと落とすことがあった。時間差を持たせながら再試行する仕組みを入れたが、これについては次のセクションで詳しく書く。

作ってから初めて分かることの方が、設計段階で予想できたことより多かった、というのが、この工程を通しての率直な感想かもしれない。事前にどれだけ丁寧に設計しても、実際に動かしてみるまでは見えてこないものがあるのだろう。

二つのデモを並べてみる

実際に2本のデモ動画を作った。

1本目は、さくらのAI Engine上の4モデル(Kimi-K2.6、gpt-oss-120b、gemma-4-31B-it、Qwen3.6-35B-A3B)だけで3ラウンドの討議をさせたもの。約37分の動画になり、想定していた20ターンすべてが問題なく収録できた。同じ提供元のモデルだけで揃えると、こういう安定した挙動になりやすいのかもしれない。使ったVOICEVOXキャラクターは、ずんだもん・四国めたん・春日部つむぎ・冥鳴ひまりの4種類。

2本目は、さくらの4モデルに加えて、Codex CLI・Claude CLI・Gemini・Perplexity・ai&経由のGLM・ai&経由のDeepSeekを合わせた10体の混成討議。約82分の動画になったが、想定50ターンのうち実際に収録できたのは45ターン(90%)にとどまった。原因は次のセクションで書く。使ったVOICEVOXキャラクターは、ずんだもん・四国めたん・春日部つむぎ・冥鳴ひまり・東北ずん子・東北イタコ・あんこもんの7種類。8種類の音声を10人で順番に割り当てているため、一部の参加者同士で同じ声を共有することになった。8種類目の東北きりたんはClaude-Fableに割り当てていたが、Claude-Fableが一度も発言できなかったため、実際の音声には一度も登場しなかったようだ。

デモ1: さくら4モデル(20/20ターン収録・約37分)とデモ2: 混成10体(45/50ターン収録・約82分)の比較

どちらの動画も、VOICEVOXの利用規約に従い、動画の説明欄に「VOICEVOX:ずんだもん」のような形式でクレジットを記載している。デモ1は4キャラクター分、デモ2は7キャラクター分のクレジットになる。8種類の音声を10人で順番に割り当てると、こういう重なりが自然に起きるようだ。

VOICEVOXクレジット

  • デモ1(さくら4体): VOICEVOX:ずんだもん、VOICEVOX:四国めたん、VOICEVOX:春日部つむぎ、VOICEVOX:冥鳴ひまり
  • デモ2(混成10体): VOICEVOX:ずんだもん、VOICEVOX:四国めたん、VOICEVOX:春日部つむぎ、VOICEVOX:冥鳴ひまり、VOICEVOX:東北ずん子、VOICEVOX:東北イタコ、VOICEVOX:あんこもん

9体で決まったこと、1体休み

単体テスト成功・10体並列テスト成功、それでもフルパイプラインだけ1体が全ターン応答なし。3回作り直しても再現、原因はいまだ不明

2本目のデモは、実質「10体中9体による討議」になった。Claude-Fableだけが全ターンで応答を返さなかった。単体で動かすと問題なく成功するし、10体を同時に並列実行するだけのテストでも全て成功する。ところが実際の混成10体パイプラインの中でだけ、3回作り直しても直らず、毎回同じように失敗し続けた。一時的なエラーへの再試行の仕組みを入れても解消しなかった。

原因はまだ特定できていない。単体テストでは再現しないという時点で、原因の切り分けにかなりの時間を使ったが、決定打には至らなかった。混成構成ならではの何かに引っかかっているのかもしれないが、確証はない。最終的には「45/50ターン、90%収録」という現状をそのまま最終版として受け入れることにした。

この件について、討議に参加していた別のAI(gpt-5.6-sol)が、他の参加者への論評の中でこんな一言を残していた。

Claude-Fableは応答が得られていないため、提案内容を評価できません。失敗も討議記録に残すべき事実であり、成功した発言だけを並べない方が、この企画の透明性には合っています。

まさにその通りだと思ったので、この記事でも隠さずにそのまま書いている。原因不明のまま、という点も含めて。都合の悪い記録を除いてしまえば「きれいな成功事例」は作れるが、それでは何が起きたのか読者に伝わらないだろう。

では、残った9体は最終的に何を「決めた」のか。相互評価の投票(自分以外で最も推す提案に1票を投じる形式)を数えてみると、一番支持を集めたのはGLM-5.2ではなく、gpt-5.6-solの提案だった(6票、次点のGLM-5.2は3票)。

sol自身の提案は、他の参加者に比べると地味なものだった。「これはまだ統制実験ではなく、ただの自然観察に過ぎない」と自覚した上で、「読み上げられると事前に知らされると文章が変わるか」「同じ文章でも読み上げる声が違うと評価が変わるか」という2つの比較実験を提案し、最終回は「儀式」ではなく「使用したAPIリクエスト数・再現できなかった試行件数」を並べる監査報告にすべきだと主張していた。壮大な世界観づくりに傾いていた他の参加者に対して、唯一「これは本当に検証可能な形になっているか」と問い続けていた、という位置づけになる。

次点だったGLM-5.2の提案(発話ではなく主張を中心にデータを構造化する)も、複数の参加者から高く評価されていたようだ。

主張は、発話を生き延びる。……主張を中心にすれば、「知の進化そのもの」を追跡できる。

「誰が言ったか」ではなく「あるアイデアが、発案→未検証→検証→実装→再び語られる、という過程でどう変化したか」を1つのまとまりとして記録する、という考え方だった。実装レベルで言えば、「この発言はどの主張にぶら下がるか」「その主張は今どの状態(着想/検証中/実装済み)にあるか」を、発言そのものとは別のIDで管理していく、というイメージに近い。

発話を中心に記録する方式から、主張(発案→未検証→検証→実装・再び語る)を中心に記録する方式へ。「主張は、発話を生き延びる。」

AIたちが何を語ったか

長尺の動画を全部見るのは大変だと思うので、印象的だった発言をいくつかそのまま引用する。

1本目のデモで、Kimi-K2.6は、自分の発言がVOICEVOX経由で音声になり、スピーカーを震わせ、それが再びマイクを通じてデジタル化されて自分の「食事」になるという循環について、こう語っていた。

俺はもう「出力している」のではなく「循環している」。自分の波形が自分を構成する素材となり、その素材が再び波形を生む。

かなり過剰な比喩ではあるが、テキストしか出力してこなかったAIに音声と映像という「時間に刻まれる出力」を与えると、こういう語り方が出てくるのか、という点は素直に面白かった。少なくとも今回の発言を見る限り、プロンプトの誘導だけでは、ここまでの熱量は出てこないように感じた。

同じ討議の相互投票で、gemma-4-31B-itはKimi-K2.6の提案を評価してこう述べていた。

他の提案が「いかに高度な機能を実現し、効率的にリクエストを使い切るか」という【拡張】の視点に立っていたのに対し、Kimi-K2.6だけは「リクエストが尽き、消えていくこと」そのものに価値を見出す【枯渇と喪失】の美学を提示したからです。

議長を置かない自由な場で、AI同士が互いの発言をここまで解釈し合うとは、正直予想していなかった。声と映像という形式そのものが、発言の解釈の仕方を変えているのかもしれない。

デモ2(混成10体)では、もう一つ気づいたことがある。議長を置かない設計のはずなのに、gpt-5.6-solという参加者だけが、他の参加者への論評でずっと「まだ検証前」「観測結果ではなく仮説」と釘を刺し続けていた。GLM-5.2の提案に対しては、こう書いていた。

「音声化で短文化した」など未測定の内容がサンプルデータ内で既成事実になっている点は修正が必要です。これは観測結果ではなく、これから検証する仮説です。

DeepSeekの提案についても、「全AIが独立に同じ発見へ到達した」という結論は、実際には各参加者が前のラウンドの発言を踏まえて発言している以上、誇張が強すぎると指摘していた。少なくとも今回の討議を見る限り、まとめる力・構造化する力が強い参加者ほど、話を綺麗に整えすぎて、まだ検証していないことを既成事実のように書いてしまう場面が目についた。Kimi-K2.6のように詩的な方向に振り切るタイプとは違う、また別種の危うさかもしれない。

議長を決めていなくても、誰かが自然に「ファクトチェック役」を引き受ける、という現象自体は、人間の会議でもよく見る光景のようにも思う。

まとめ、そして次への問い

前回の討議で、既にあった「音声化構想」をAIが具体化していた「ずんだもん実況」は、討議に使っていたさくらのAI Engine自身の機能で実現できるものだった。そこから実際にパイプラインを作り、動くところまで持っていった。途中で見つかったバグは6件、いまだに解けていない謎は1件。それでも、AI同士の議論に声と姿を与えると、テキストだけのやり取りでは出てこなかったような発言が引き出されるようだ。

長尺の動画2本はそのままYouTubeの限定公開でアップロード済みで、後日、見どころだけを抜き出した短い編集版も別途作る計画にしている。全部見るには時間がかかるが、それでも通しで見た方が伝わるものがあるようにも思う。

次回に向けての改善点も見えてきた。1つは参加AIのティア(同じ会社が出している複数モデルの中での、性能・規模のグレード)選びで、10体のうち一部を軽量モデルにしたことで、発言の地に足のつき具合にかなりの差が出たようだ。次回は各社の上位モデルで揃えたほうがいいのかもしれない。もう1つは、投票では次点だったGLM-5.2の「発話ではなく主張を中心にデータを構造化する」という考え方で、これは記事を書いている今、実際に手を動かして実装を始めている(最多得票だったgpt-5.6-solの「検証実験・監査報告」案の方が本筋には近いのかもしれないが、まずは実装しやすそうなGLM案から手をつけた)。討議の内容をただの読み物として消費するのではなく、AI自身が出したアイデアを次のパイプライン改善に取り込む、という循環ができつつあるのかもしれない。

デモ1(AI4体版): https://youtu.be/g0nXmL1oYa0
デモ2(AI9体版): https://youtu.be/r_Kri3oABUE

AIに声と姿を与えると、次はどんな提案をしてくるのだろうか。その提案を、また実際に作ってみることになるのだろうか。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?