16 ポイント 投稿者 GN⁺ 2025-06-26 | 2件のコメント | WhatsAppで共有
  • OpenAIの音声文字起こし料金は、入力音声の長さに応じて算定される
  • ffmpegのようなツールで音声を2〜3倍速に変換してからアップロードすると、文字起こし品質を落とさずに処理速度とコストを削減できる
  • 実際に40分の音声を2倍、3倍に速度変換すると、コストが23〜33%削減される
  • gpt-4o-transcribeモデルは25分未満の音声のみ対応しているため、速度を上げる方法は有用な回避策になる
  • 2〜3倍速までは結果の品質が維持されるが、4倍速では文字起こし精度が急落する現象が起きる

要約紹介

  • OpenAIの文字起こしおよび音声料金ポリシーを、より効率的に活用できるシンプルな方法
  • 音声の変換速度を上げて、より短い時間で同じ内容を処理することで、料金と時間の両方を節約する戦略
  • ffmpegのようなオープンソースツールで音声ファイルを2〜3倍速に変換した後、OpenAI APIにアップロードすれば、品質劣化なしに価格と所要時間を下げられる
  • この方法は特に入力長(gpt-4o-transcribeモデルの25分制限)を超えやすい長尺音声でより効果的

文字起こしの速度・コスト節約の核心的な方法

  • OpenAIの音声文字起こしサービスは、受け付ける音声の長さを基準に料金を設定している
  • したがって、音声ファイルをffmpegなどで事前に2〜3倍速化してアップロードすれば、入力トークン数を大きく減らせて、文字起こし処理時間も短くできる
  • この方法を実際に適用すると、40分音声を基準に入力トークンのコストを33%以上削減できる(3x適用時 $0.07、2x適用時 $0.09)
  • 出力トークンのコストは音声速度とほぼ無関係で、ほぼ同じになる(入力要約の長さ基準で自動割り当てされた結果)
  • 2倍速、3倍速では文字起こし精度は安定しているが、4倍速ではモデルが内容を正確に認識できない限界が生じる

使用スクリプト例

次のオープンソースツールの利用が必要:

  • yt-dlp : YouTubeなどから音声を抽出
  • ffmpeg : 音声変換および速度調整
  • llm : テキスト要約の自動化

参考用の全体ワークフロー:

  • yt-dlpで音声を抽出した後、
  • ffmpegで音声を2〜3倍速に変換してmp3として保存
  • OpenAI API(gpt-4o-transcribe)にmp3をアップロードして文字起こしテキストを取得
  • その結果テキストをllmに入力して、望む要約文を自動生成

実体験と試行錯誤

  • 当初はYouTubeの自動文字起こしを取得しようとしたが、yt-dlpの旧バージョン(2025.04.03)だったためダウンロードエラーが発生
  • プログラム更新後は正常動作したが、その間に手動抽出とffmpeg高速化→OpenAI API処理という方式に挑戦することになった
  • M3 MacBook AirでローカルWhisperを実行すると、バッテリー負荷や実行速度の問題があり、クラウド(OpenAI API)にオフロードする方がより速く効率的だった

文字起こし品質とアルゴリズムの特性

  • 音声速度を2倍〜3倍に上げても、人が元の音声を早回しで聞くのと同じように、AIモデルも本質的な情報をほぼ認識できる
  • 画像ファイル容量の最適化(可逆・非可逆フォーマット)に似ていて、聴取情報の一部損失(高速時の断続的な単語欠落など)があっても、要約や理解には大きな支障がない
  • 脳がスペルミスや一部単語が省略された文章でも補完して認識するように、文字起こしアルゴリズムも高速化された音声から大半の主要情報をうまく抽出する

実際の料金比較と削減幅

  • OpenAIのgpt-4o-transcribe基準では、音声速度ごとのコストは次のように計算される
    • 2倍速(1,186秒): $0.09
    • 3倍速(791秒): $0.07
    • 入力音声が長い場合(例: 元の2,372秒)は、モデル要件上処理不可
    • Whisper-1モデル基準では $0.006/分 で、結果としてこの方法を使えば最大67%程度のコスト削減が可能
  • 出力トークンのコストは入力速度に関係なくほぼ同じ(モデルのコンテキストウィンドウおよび要約方式の影響)
  • 4倍速を適用すると、出力結果は反復文などで深刻に劣化する

推奨事項と結論

  • OpenAIの音声文字起こしを速く安く使うには、2〜3倍速での音声高速化が最も効率的
  • 速すぎる速度(4x)では精度低下の問題がある
  • シンプルで実行しやすい方法であり、品質維持とコスト削減の両方に有利
  • 一般的なビジネス向け音声要約や議事録など、長時間の音声データ処理が必要なスタートアップやIT実務者にとって、直接的なコスト・時間削減手段として活用できる

要約(TL;DR)

  • OpenAIは音声長または入力/出力トークン基準で料金を請求する
  • ffmpegで音声を2〜3倍速に変換して入力すれば、時間とコストの両方を節約できる
  • 入力トークン(または時間)が減ることで料金が下がる
  • 2倍速、3倍速までは最適で、4倍速以上からは文字起こし品質の低下が見られる

2件のコメント

 
mbsahg 2025-06-27

gpt-4o-transcribe は使えますか?
昨日 OpenAI に問い合わせたところ、API キーで呼び出せるのは Whisper モデルだけだと言われました。
品質を維持できるか確認するために、速度を上げた設定で Whisper を試してみようと思っています。

 
GN⁺ 2025-06-26
Hacker Newsの反応
  • Andrejの講演は、もともと一般的な人より少なくとも1.5倍は速い自然な話し方なので、ついていくにはYouTubeの再生速度を必ず1xに落とさないといけないと感じた。OpenAIのminute課金をもっと効率化したいなら、無音区間を丸ごと削って処理する方法を提案したい。
    ffmpegコマンドの例として、-50dB以下で20ms以上のすべての無音を20msの停止に置き換えることで、39分31秒の動画を31分34秒まで短縮できる可能性を体験した。本文の趣旨どおり長さだけを測って効果を確認し、短縮版の品質は別途確認していない

    • 私はいつもすべての動画を2xで見ていて、Andrejの講演も2xが自然に感じる。ただ、自分が作った動画は周囲の人から速すぎるので0.75xで見る必要があるとよく言われる。自分の感覚では2xでないと遅すぎる。ちなみにJohn Carmackの話す速さは2xでも完全に自然だと感じる。最近の自分の動画が気になるならここで確認でき、たいていはその場でテーマだけ決めて録音する形で250〜300本以上やっている。自分の動画があまりに速すぎると感じるのか、それとも十分普通の速度なのか気になる

    • 品質を確認していないなら、2つのバージョンの出力をdiffcheckerのようなもので比較すれば簡単だったのでは、と思う

    • 一般人向けに2.25xのYouTube速度があればいいのにと思う。私はいつもショートカットを使って、2xで90%くらいは聞いているが、Andrejの講演だけは1.25xより速く回すのが難しい

    • Andrejが一般の人より1.5倍以上速く話すという点で、YouTube速度を元に戻すべきだという話には共感する。人の話す速度を自動で検出する方法があるのか気になる。速度は主観的で人それぞれだが、OPが試した方法が失敗したときにそれを検知できるなら面白そうだ。(たとえばx4速度で品質が壊れてしまったような場合)

    • ffmpegの魔法をもっと活用できそうでわくわくする。後でぜひ試してみたいので、アイデアに感謝

  • ざっと目を通すことと、時間を取ってきちんと見ることについての考え。
    Andrejの講演は、transcriptと要約だけ読んだときは普通に感じてそのまま流したが、YouTubeで全体の動画を見ると、非常に多様なアイデア、思考、判断へとつながる体験になった。こういうことは他のテーマでもよくある。実際にカンファレンスに参加して聞くと、オンライン講演よりはるかに有益だ。オンラインで見るだけでも、要約だけ読むよりずっと有益だ。10分だけざっと考えて終わるより、散歩しながら深く考えるほうがずっとよいことさえある。考えるためには、たいていゆっくり進めるほうがよいという実感がある

    • これが本当に不思議に感じる。学校で画一的に知識を投げ込まれるのを嫌っていた開発者として、今ではそういう形の体験に喜んでお金まで払っている現実が奇妙だ。読むこと自体が楽しいし、講演を見ながら考えが噛み合っていく感覚も素晴らしい。世界の意味を自分たちで考えることこそ人間らしさだと思っている。なのに、こうした傾向がみんなを愚かにする道だという見方にはまったく共感できない

    • 上の意見に強く同意する。講演の価値は、公開されている事実やアイデアそのものよりも、それをきっかけに生まれるさまざまな付随的なひらめきのほうが大きいと思う。世の中には本当に無数の情報があり、文脈がすべてだ。もしもう少し具体的な文脈が添えられていたら時間を取って見たと思うが、文脈のないリンクだけ渡されると、どうしても「要点」だけを素早く把握して対処しようとしてしまう。結局、今回はそのおかげで興味が湧いたので、もう一度見直すかもしれない。「ゆっくり考えるほうがたいてい良い」に改めて同意する

    • ゆっくり考えることが重要なのは確かだが、講演内容を少し聞いておいて、後でまた見返しながらより深く考えるやり方もかなり有用かもしれないと思う

    • 果たして重要だったのは動画の速度なのか、それとも動画や音声がもたらす付加情報なのか、という問い。話し上手な話者は、同じメッセージでもオーディオ/ビデオのほうがはるかによく伝えられると感じる。音声は特定の部分に強調を与えられるし、動画はジェスチャーや表情でもメッセージを補えるからだ

    • 私はむしろ、ポッドキャストやオーディオブックを2〜3xで聞く人を見ると、自分の場合は0.8xに落としたほうが集中できるし、考える時間も増えると感じる。自分が例外的なケースなのか気になる

  • OpenAIのtranscription APIで40分の講演を要約しようとしたが、長すぎたためffmpegで3倍速に圧縮して25分制限内で動かした。実際に効果があり、コストも時間も節約できたので記事として共有した。スクリプト全文とコスト内訳も含まれている

    • こういう裏技をこっそり使って、OpenAIより安いtranscription事業まで始められたのでは、という冗談
  • 「精度は?」「わからない、もともとそこが要点ではない」という元記事の書き手の雰囲気そのままで、かっこいい仕事だと思う一方で、この未来にどこか不安も覚える

    • もともと人間が作る音声記録にも正確さの保証はなかった。こうした変換プロセスには常に誤りがあり、それは今後も期待値の一部だ。むしろもっと心配なのは、生成AIが事実であるかのように解釈したり、「AIのほうが信頼できる」という社会的な観念そのものだ。人間、専門家、記者よりもAIのほうが信頼性や公正さを備えているという大衆的な考えも危険だ
  • Gemini 2.0以前のバージョンでは、画像1枚あたり258トークンの固定料金を取る方式があり、画像にもっと大量のテキストを詰め込めばそのぶん安く処理できるというトリックもあった

  • Chrome拡張機能を作ったのだが、huggingface/transformers.jsでOpenAI WhisperモデルをWebGPU上で動かし、ブラウザ内で直接オーディオをテキスト化できる。サンプル一覧を参照。たとえば、大統領のSNS動画は聞いたり見たりしたくないが、経済に大きな影響を与える失言が出たときは素早く検知する必要があるので、1分ごとに新規投稿をクロールし、OCRと音声transcriptionをローカルで自動処理して、さらにテキスト分析まで行い、経済的に重要なときだけ通知する。プロジェクトリンク

    • 驚くべき実装だという評価
  • OpenAI Whisper APIの代わりに、Groq(安価にdistil-large-v3が1時間あたり$0.02、whisper-large-v3-turboが$0.04、OpenAIは$0.36/hr)もおすすめ。社内では、市議会の会議がYouTubeに上がると自動的にGroq、Replicate、Deepgramなどを使ってtranscriptionを処理している

    • Hugging FaceのInference APIを使えば、複数のAPIプロバイダを簡単に切り替えられて便利だというヒント。例はここで直接確認できる

    • 1時間あたり$0.02〜$0.04の単価なら、特に最適化は不要にも思えるが、オーディオをさらに高速化してコストをもっと下げられるのではないかという疑問もある。YouTubeがすでにたいてい1日以内に自動字幕を提供していることへの疑問も伴う

    • 最新のMacBookユーザーなら、Whisperモデルを完全無料でローカル実行できることを強調したい。自分の手元のハードウェア計算資源がすでに非常に安いという点を、多くの人はよくわかっていない気がする

    • Cloudflare Workers AIでもwhisper-large-v3-turboモデルを1時間あたり約$0.03で使えるオプションがあることを案内(リンク

  • Google AI Studioでは、YouTubeリンクを投げるだけでspeaker label付きのtranscriptionや視覚的な手がかりまで自動抽出してくれる機能が強調されていた。動画へのマルチモーダル対応にも言及

  • 私はOpenAIでAPI関連の仕事をしているが、2〜3xの高速化でも結果がかなり良好で驚いた。実際、電話チャネル向けには8khz音声を24khzにアップサンプリングして問題なく使っている。ただし、1xから離れるほど精度低下が明確に存在する点と、長期的にはもっと長いファイルのアップロード対応が必要だ

    • 社内でこうした速度最適化を研究して、精度損失が最小になる倍率のポイントを見つけるとよいというフィードバック。簡単な前処理だけでAPI価格を下げられる可能性も示唆している
  • いきなり本題に入る文章スタイルが気に入ったという意見。多くの文章は無駄に冗長になりがちだが、こういうアプローチは新鮮だ。著者の半分は、実は肝心のメッセージそのものがないと気づくことになりそうだ