FFTrans Neuは、もともと「高速で軽快なオフライン文字起こし・話者分離アプリ」として開発を続けてきました。
しかし、先日リリースしたメジャーアップデートである Version 3.x では、単なる基本性能の向上にとどまらず、アプリのあり方を少し変える新しい機能を搭載しました。
それが、「音響特徴量付きJSON」およびMarkdownの出力対応です。
これは単に、従来のSRT（字幕ファイル）やMarkdownと同じテキスト内容をJSONというフォーマットに変換しただけのものではありません。
各発話セグメントに対して、
- 話者（Speaker）
- タイムスタンプ / 発話時間（duration）
- 発話前の無音時間（pause_before）
- ピッチの平均（pitch_mean）
- ピッチの標準偏差 / 揺らぎ（pitch_std）
- 平均音量（energy_mean）
といった音響の統計データ（メタデータ）をテキストと完全に紐付けて保持する設計にしています。
最初は「将来的にLLM（大規模言語モデル）へ渡しやすいデータ構造にしておこう」という程度の発想だったのですが、実際に自分でデータをパースしてAIに分析させてみると、従来の文字起こしデータとは次元の違う、非常に興味深い結果が得られました。
今回は、なぜわざわざこのような重いデータ設計に踏み切ったのか、その意図と実際の活用事例を共有します。
テキストメディアが切り捨てる「非言語情報」の限界
従来の文字起こし（SRTやMarkdown）は、「誰が、何を、いつ話したか」を追うには十分な情報を持っています。
議事録や台本として議論の流れを確認するだけであれば、これで事足ります。
しかし、人間が実際の会話から受け取っている情報はテキストだけではありません。
私たちは、
- どこで言葉に熱が入ったか（強調・感情のピーク）
- どこで少し呆れ、トーンを落としたか（皮肉・落差）
- どこで確信を持って、あるいはドスを利かせて話したか（緊迫感）
- どこで一拍の間を置いたか（タメ・躊躇）
といった「どう話したか」という非言語情報（エモーションや空気感）を同時に受け取っています。
音声がテキスト化された瞬間、これらの情報はほぼ100%削ぎ落とされ、すべての言葉がフラットに平坦化されてしまいます。
一方で、「生の音声ファイル」にはこれらの情報がすべて含まれていますが、それは構造化されていない音声ですから、検索も比較も、外部ツールでの自動化も事実上難しいということになります。
「カオスな生の音声」か、「平坦化されて文字情報だけのテキスト」か。
これまではこの二者択一だったのです。
FFTrans Neu 3.xが目指したのは、そのトレードオフの解消です。
音声が持つ非言語情報の中から、データ分析や自動化に本当に価値のある要素だけを抽出し、「JSONというコンテナに構造化して閉じ込める」というアプローチを取りました。
実際のJSONデータで見る「テキスト」と「特徴量」の差
どれほどの差が出るのか、実際にFFTrans Neu 3.xで出力した生のJSONデータを元に説明します。
今回は事例として、ドイツの経済諮問委員であるヴェロニカ・グリム（Veronika Grimm）教授への約6分間のインタビュー音声を使ってみました。
全58セグメントのうち、グリム教授（S2）の発言が約74%を占めており、専門家が主導している構図はテキストだけでも分かります。
しかし、「どこが議論の核心で、どこで感情が動いたか」は、特徴量の数値を見て初めて可視化されます。
実例1：テキストの文字面に隠された「感情の爆発」
以下は、グリム教授が政府の年金改革の方針を批判している場面のJSON（一部抜粋）です。
{
"id" : 44,
"text" : "Ja, aktuell spricht man von einer großen Rentenreform und plant eigentlich nur Maßnahmen, die die Ausgaben noch zusätzlich ansteigen lassen.",
"speaker" : "S2",
"start" : 272.8,
"end" : 281.44,
"metadata" : {
"energy_mean" : 0.08797,
"duration" : 8.64,
"pause_before" : 1.68,
"pitch_mean" : 236.10,
"pitch_std" : 65.20
}
}
テキストの文字面だけを追うと、「現在の年金改革案は支出を増やす措置しか計画していない」という、専門家らしい論理的な政策批判に見えます。
しかし、音響特徴量の数値を注視してみると違った景色が見えてきます。
グリム教授の通常の平均ピッチは190Hz〜210Hz前後であるのに対し、このセグメントでは'pitch_mean'が 236.10Hz まで跳ね上がり、声の起伏を示す 'pitch_std'が 65.20 という突出した異常値を叩き出しています。
映像や音声を直接確認しなくても、データを見ただけで「ここで教授の声が上ずり、強い憤りと危機感をまくし立てている感情の最大ピーク（見どころ）である」ことがピンポイントで判別できます。
テキストだけでは、この「思いが高まった瞬間」を捉えることは不可能です。
実例2：パワーワードに騙されない「呆れのトーン」
もう一つ面白い例があります。
政府の財政運営の抜け穴について語った場面です。
{
"id" : 24,
"text" : "Überraschend ist das alles nicht",
"speaker" : "S2",
"start" : 142.65,
"end" : 143.83,
"metadata" : {
"energy_mean" : 0.05934,
"duration" : 1.17,
"pause_before" : 0,
"pitch_mean" : 189.65,
"pitch_std" : 73.93
}
}
「こんなことは全く驚きではない（Überraschend ist das alles nicht）」という短い一文です。
ここでの平均音量（'energy_mean'）は 0.059 と、全体平均よりかなり低めの数値になっています。
しかし、ピッチの変動幅（'pitch_std'）は全データ中トップの 73.93 を記録しています。
これは「大声で怒鳴っている」のではなく、「声を落とし、吐き捨てるような、あるいは強い皮肉を込めてトーンを激変させた『呆れ果てた感情の落差』」が数値として現れていることを意味します。
もしテキストだけでAIや人間に「盛り上がっている場所」を推測させると、"Wählertäuschung（有権者への欺瞞）" のような強い単語（パワーワード）がある場所を誤ってピークだと判断しがちです。
しかし、人間は普通の言葉を喋っている時にこそ、声のトーンを変えて感情を表現します。
特徴量付きJSONは、そうした文字面だけの推測を排除します。
音響特徴量を活用した要約
さらに、FFTrans Neu 3.2では、各発話に acoustic_trend を追加しました。
例えばニュース番組の冒頭では次のようなデータが出力されます。
{
"text": "人口減少が進む一方で人口が増えた自治体もありました。",
"metadata": {
"pitch_mean": 161.3,
"energy_mean": 0.141,
"acoustic_trend": {
"pitch": 1.29,
"energy": 0.91
}
}
}
この acoustic_trend は、発話前半に対する後半の比率です。
この例では
-
pitch = 1.29
→ 後半になるほど声が高くなっている -
energy = 0.91
→ 声量はほぼ維持したまま説明している
ことを表しています。
文字だけを見ると
人口減少が進む一方で人口が増えた自治体もありました。
という一文ですが、音声を見ると「人口が増えた自治体」という後半部分でピッチが大きく上昇しています。
つまりキャスターは、この話題へ視聴者の注意を向けようとしていることが分かります。
従来の要約では
人口減少と人口増加の自治体について説明した。
程度になります。
一方、音響特徴量をLLMへ渡すと、
日本全体では人口減少が続く一方で、人口が増加した自治体も存在する点を特に強調して紹介した。
といった、「何を伝えたかったか」を反映した要約を生成しやすくなります。
もちろん acoustic_trend だけで結論を出すわけではありません。
発話内容や前後の文脈と組み合わせることで、
- 強調して話した部分
- 徐々に熱が入った部分
- 淡々と説明している部分
といった話し方の違いをLLMが考慮できるようになります。
ラジオ番組では「空気感」の要約も可能
音響特徴量はニュースだけでなく、ラジオ番組やポッドキャストでも活用できます。
例えば、出演者同士の軽快な掛け合いが続く場面では、次のようなJSONが得られます。
{
"speaker": "S1",
"text": "いや、それ本当に面白かったんですよ！",
"metadata": {
"pitch_mean": 214.6,
"energy_mean": 0.186,
"acoustic_trend": {
"pitch": 1.36,
"energy": 1.42
}
}
}
続いて別の出演者がすぐに応答します。
{
"speaker": "S2",
"text": "そうそう！会場もかなり盛り上がってましたね。",
"metadata": {
"pitch_mean": 201.8,
"energy_mean": 0.179,
"acoustic_trend": {
"pitch": 1.18,
"energy": 1.31
}
}
}
文字起こしだけを見ると、
イベントについて出演者同士が感想を話した。
という要約になります。
しかし音響特徴量を見ると、
- 両者とも後半ほどピッチが上昇している
- エネルギーも後半に向かって増加している
- 発話のテンポよく会話が続いている
ことが分かります。
これらをLLMへ渡すことで、
出演者同士がテンション高く軽快な掛け合いを展開。イベントの思い出を笑いを交えながら振り返り、番組全体が盛り上がった雰囲気で進行した。
といった、芸能ニュースの記事やラジオ番組紹介のような要約を生成できます。
重要なのは、LLMが単に「何を話したか」だけでなく、
- 声の盛り上がり
- 話し方の変化
- 会話のテンポ
- 話者同士の掛け合い
といった音声ならではの情報も判断材料として利用できる点です。
このような情報は文字起こしだけでは失われてしまいますが、音響特徴量をJSONとして保持することで、LLMが番組全体の雰囲気まで考慮した要約を生成できるようになります。
LLM（AI）にとっての「カンニングペーパー」
このように、実際にこのデータをLLM（大規模言語モデル）に読み込ませてみて確信したのは、「JSON形式の特徴量は、LLMにとって圧倒的に処理が軽い」ということです。
テキストだけのMarkdownを渡された場合、LLMは文章全体の文脈や形容詞を読み解き、「たぶんこの単語を使っているから怒っているのだろう」と、高度で不確実な「文脈の推論（国語の長文読解）」をぐるぐる回す必要があります。
結果としてハルシネーション（誤認）が起きるリスクも伴います。
一方、特徴量付きJSONを渡した場合、LLMにとっては「答え合わせ済みのイージーモード」になります。
実際、LLM自身に尋ねても、そう答えてくれました。
文脈を深読みしなくても、'pitch_std' や 'energy_mean'の数値のスパイクを見るだけで、一発で感情の起伏や重要シーンを特定できるからです。
グラフの数値を読み取る算数の問題に変形されるため、分析の精度だけでなく、出力の安定性も劇的に向上します。
テキストという1次元の情報に、音響という多次元の補助線が最初から綺麗にバインドされているというのは、LLMに音声のニュアンスを「カンニング」させるための、極めて相性の良いインターフェースなのです。
会話の熱量をハックする活用アイデア
この構造化データを外に吐き出せるようになると、文字起こしの「その先」の自動化や知的生産の幅が一気に広がります。
1. 動画編集（Premiere Pro等）での演出自動化
例えば、ExtendScript等のスクリプトとこのJSONを組み合わせることで、「'pitch_std'（起伏）が50以上のセグメントは、感情が高ぶっていると判断してテロップのフォントサイズを自動で2倍にし、カラーを赤に変更してタイムラインにジャストで配置する」といった感情同期型のテロップ下書き自動化が現実になります。
2. 知的生産ツール（Obsidian / Logseq等）との連携
Markdown出力機能を使ってノートアプリに取り込み、プロパティ（メタデータ）としてJSONの数値を扱えば、Dataviewなどのプラグインを用いて「過去の会議録の中から、参加者の熱量（'pitch_std'）や議論の緊迫感（'energy_mean'）が一定以上だった重要シーンだけをクエリで抽出する」といった運用が可能です。
単なるテキスト検索ではなく、「会話の熱量で検索できる真の知的資産庫」を作ることができます。
競合ツールにないメリットと、FFTrans Neuが目指すもの
世の中には優れた文字起こしツールや話者分離ツールがたくさんあります。
しかし、それらの多くは「綺麗で正確なテキスト（あるいは字幕）を出力すること」をゴールにしています。
FFTrans Neu 3.xは、そこからもう一歩踏み込み、「会話そのものをAIやスクリプトで活用可能な構造化データとして配給するハブ」になることを目指しました。
機能をアプリの中に閉じ込めるのではなく、クリーンで情報密度の高い一次データをJSONやMarkdownとして差し出す。
あとはクリエイターやエンジニアの好きなエコシステムで、自由に活用してほしいというスタンスです。
動画のダイナミクスを自動で抽出したいディレクターの方、会議のドキュメンテーションを自動化したいギークの方、ぜひ新しくなった Version 3.x をあなたのワークフローで自由にパースして使ってみて頂ければ幸いです。