AIものさし

OpenAI Audio APIで長い録音が上限に当たるとき、モデル別制限と分割方法を選ぶ

OpenAI Audio APIで長い録音が拒否されたら、最初に「ファイルを送るtranscriptions」なのか、「録音中の音声を流すRealtime」なのかを分け、次に使用modelと公式上限を確認します。

AIものさし編集部

OpenAI Audio APIで長い録音が拒否されたら、最初に「ファイルを送るtranscriptions」なのか、「録音中の音声を流すRealtime」なのかを分け、次に使用modelと公式上限を確認します。現行のFile transcriptionガイドではファイルは最大25 MBで、超える場合は圧縮するか25 MB以下のchunkへ分割し、文の途中を避けるよう案内されています。一方、FAQはlegacyのwhisper-1について25 MiBと明記し、新しいGPT transcription routeではdurationやtokenなどmodel別validationが異なる可能性を示しています。したがって、古い「Whisperの25 MiB」を全modelへ一律に当てはめず、実際のendpoint・model・ファイルサイズから設計します。

目次

最初に処理の種類を選ぶ

表は横にスクロールできます

やりたいことAPIの流れ上限を調べる場所
すでに録音済みの音声ファイルを文字起こしするFile transcription /v1/audio/transcriptions現行speech-to-textのFile transcriptionガイドと選択model
録音済み音声の処理結果をストリームで受け取るFile transcriptionのstream機能File transcriptionガイド。これは完成済みファイルを処理する経路
マイク、通話、配信など進行中の音声を逐次処理するRealtime transcription sessionRealtime transcriptionガイドとsession/model条件

「stream」という言葉だけでは経路を選べません。完成した音声ファイルの処理中に部分的な文字を受け取るfile streamingと、音声自体がまだ届いているRealtime sessionは別の用途です。すでにある長い録音を上限回避のためRealtimeへ読み替えるのではなく、録音済みファイルかライブ音声かを先に決めてください。

25 MBと25 MiBを混ぜない

OpenAIの現行File transcription guideは「ファイルは最大25 MB」と案内し、これを超える録音には圧縮または25 MB以下のchunkを推奨しています。長い音声を分割するときは文の途中で切らないよう明記されています。

Help CenterのAudio API FAQはlegacy/whisper-1の最大request sizeを25 MiBと表記し、新しいgpt-4o transcription routeではdurationやtoken上限など異なるvalidationを使う場合があるためmodel-specific documentationを確認するよう説明しています。MB（10進）とMiB（2進）は同じ値ではありません。この違いをAPI全体に一般化して「Whisperなら常にこれ、新modelなら必ず無制限」とは言えません。実装上は、使うendpoint/modelの現在の文書と実際のerrorを基準にし、upload bodyの境界ぎりぎりを狙わず余裕を持って処理します。

endpointとmodelを固定してからサイズを見る

ログ、設定、request builderから、実際に使っているURLが/v1/audio/transcriptionsか、Realtime sessionかを確認します。続いてmodel名、response format、その他のオプションを控えます。同じ「音声文字起こし」でも、speaker diarization、timestamp、字幕形式、streamingの要求によって適切なmodelやresponseが異なります。

通常の録音文字起こしは、現行ガイドが推奨するgpt-transcribeから検討します。話者ラベルをsegmentごとに付ける必要がある場合はgpt-4o-transcribe-diarizeが候補ですが、単なる文字起こしのためだけにspecialized modelを選ぶ必要はありません。word timestampsやSRT/VTT字幕が必要なら、現行のmodel selection documentationを確認してください。必要機能が違うmodelに切り替えるとresponse形式や後処理も変わるため、size上限だけで置き換えないことが重要です。

gpt-4o-transcribe-diarizeを使いdiarized_jsonを要求する場合、File transcription guideは30秒を超えるaudioでchunking_strategyをautoまたはVAD設定にするよう指示しています。これはdiarization modelのchunking要件であり、すべてのmodelに同じ設定が必須という意味ではありません。また、これはファイルupload上限を解除する設定ではありません。25 MBを超えるファイルには別途圧縮・分割が必要です。

送信前にサイズと形式を測る

サイズは録音時間だけでは決まりません。非圧縮WAVは同じ時間のMP3より大きくなりやすく、sample rate、channel数、bit depth、codecの影響を受けます。まずファイル名、拡張子、実byte size、再生時間、channel数、sample rate、使用するmodelを一行のジョブ情報に記録します。

File transcription guideが現在挙げる対応形式はmp3、mp4、mpeg、mpga、m4a、wav、webmです。拡張子だけを変えても音声codecは変わりません。未対応形式や壊れたコンテナが原因なら、単なるファイル分割では直らないため、正規のaudio converterで対応形式へ変換してから再確認します。

送信前チェック：

  1. 呼び出し先とmodelが決まっている。

  2. endpointに適したファイル形式を選んでいる。

  3. 実byte sizeをファイルシステムで確認した。

  4. ファイルが現在の制限以内か、超えるなら圧縮・分割を設計した。

  5. requestに含めるfile、prompt、speaker referenceなどのpayloadを正しく数えている。

  6. 実際のAPI error bodyを記録し、ファイルサイズ以外のvalidationを見落としていない。

圧縮と分割の選び方

圧縮を先に検討する場合

元の録音が大きく、音声の明瞭度を保てるなら、対応する圧縮形式へ変換し、再生確認と文字起こしのサンプル確認を行います。圧縮率を上げるほどファイルは小さくなりますが、低い声、固有名詞、雑音下の発話、複数話者の区別が劣化する可能性があります。どのbitrateなら精度が保たれるかは録音条件によるため、固定値を一律の最適値として扱わず、代表的な短い区間で品質を確認してから本処理へ進みます。

分割が必要な場合

File transcriptionガイドが示す基本条件は、各chunkが25 MB以下で、文の途中で切らないことです。単純に「10分ごと」など時間だけで切ると、録音のbitrate次第でchunk sizeが上限を超える場合があります。最初にbyte sizeから安全な区間を見積もり、実際に書き出したchunkごとのbyte sizeを検査します。境界は、無音や発話の区切り、可能なら文の終端に合わせます。

前後のつながりが必要なときは、隣接chunkに短い文脈を重ねる方法が考えられます。ただし公式文書は重ねる秒数の一律値を指定していません。重なりを採用する場合は、元音声の開始・終了時刻とchunk内時刻の対応を保持し、結合時に重複文を検出するルールを設けます。重なりなしで境界を切るなら、文が分断された箇所を後から見つけられるよう、chunk境界を一覧で記録してください。

chunkの分割・再結合設計

表は横にスクロールできます

保持する項目理由実装例
元録音の識別子と長さ再実行・結果照合recording_id、duration
chunk番号と元音声上の開始・終了秒順番とoffset復元chunk_index、start_sec、end_sec
model、endpoint、response format条件再現model、endpoint、format
各chunkのbyte sizeとhash上限確認・誤ファイル検知bytes、SHA-256
API resultと処理状態失敗部分だけ再実行request_id、status、error
重なり区間と再結合ルール二重テキスト・時刻ズレ防止overlap_sec、dedupe rule

処理後は、全chunkの成功数と順序を確認し、失敗chunkだけ再試行します。結合時は、chunk境界周辺の末尾・先頭を比較して文の欠落、重複、句読点の二重化を確認します。timestampを出力するmodel・formatでは、chunk開始時刻をoffsetとして加えるなど、元録音上の時刻へ戻す設計を明示します。話者ラベルを使う場合は、同じ話者が別chunkで異なるlabelになる可能性も確認し、根拠なくspeaker IDを統合しません。

原因別のエラー切り分け

  • request sizeが大きすぎる：実際に送ったfileのbyte sizeとendpoint/model条件を照合。必要なら圧縮し、各chunkを上限以下にする。

  • durationやtoken等のvalidation error：ファイル容量だけを削っても解決しないことがあります。model固有の現行文書とresponseのエラー内容を確認し、分割・model選択を見直す。

  • unsupported format：codec/containerを調べて対応形式へ変換する。拡張子のrenameで代用しない。

  • timeoutやネットワーク切断：サイズ制限と同一視せず、request単位・chunk単位の処理状態を残して、完了済み部分を重複処理しない設計を確認する。

  • 出力品質の低下：圧縮や境界位置、録音品質、promptのcontextを確認。上限を通ったことと、完全なtranscriptになったことは別の検証です。

API responseには具体的なerrorが含まれることがあります。本文に出ていないエラー名を確定した原因として扱わず、返却されたコード・message・request条件を保存します。responseに機密の録音内容や認証情報を含めない形でログを整え、必要最小限のサンプルで再現してください。

Realtimeはライブ音声向け

録音済みの長いファイルと、進行中の会議・通話の音声streamは別の問題です。Realtime transcriptionはマイク、call、その他のlive audio streamから逐次文字を得る用途として案内されています。進行中の音声を低遅延で扱いたい場合にsessionを設計します。完了済み録音を「ファイル上限回避のためRealtimeで送ればよい」とは限りません。転送方式、buffer、turn detection、再接続、部分結果の重複処理など別の実装責務が増えるため、要件がlive processingでなければFile transcriptionを使います。

長時間録音の実務フロー

  1. 用途を確定する。 完了済み録音か、これから到着する音声か、話者ラベルやtimestampが必要かを決めます。

  2. endpointとmodelを記録する。 「OpenAI Audio API」だけで曖昧にせず、実際のrouteとmodel aliasを固定します。

  3. 制限を公式資料で確認する。 File transcriptionの現行25 MB上限、model固有のduration/token条件、選択したresponse形式の要件を読み分けます。

  4. 代表区間で圧縮条件を評価する。 音声が明瞭か、固有名詞や複数話者が保たれるかを確認します。未評価の音質条件を「精度維持」と断定しません。

  5. chunk計画を作る。 各区間のbyte size、時間範囲、境界、文脈の重なり、再結合ルールを決めます。公式に決められていない固定overlap秒数を一般化しません。

  6. chunk単位で処理する。 一つずつstatusを保存し、失敗箇所だけ再試行できるようにします。

  7. 結果を監査する。 全区間があるか、境界の音声・テキストが欠けていないか、順番とtimestamp、重複、話者ラベルを確認します。

  8. 運用条件を更新する。 modelやAPI仕様が変わったときは再確認し、25 MB等の数字を無期限の固定仕様として埋め込まないようにします。

選択のまとめ

録音済みファイルならFile transcriptionを起点にし、まず現行の25 MB上限と選択modelの制約を確認します。超過時は音質を検査しながら圧縮し、それでも大きい場合は文の途中を避けて25 MB以下のchunkに分け、chunk番号・元時刻・statusを保存して再結合します。speaker diarizationなどmodel特有の条件は別に満たしてください。live音声ならRealtimeを選びます。

最終判断は、古いWhisperの数値だけでなく、実際のmodel、endpoint、file format、error bodyから行います。上限は通ったがtranscriptに欠落がある、または音質が落ちた場合は成功とはみなしません。最初の小さな検証で分割境界と結合処理を確かめてから、残りの録音へ広げてください。

Sources