音声を夜間に一括文字起こし：キューに入れて寝るだけ（2026年版）

就寝前にセットアップする

40本のインタビュー録音や60件の顧客通話を文字起こしするなら、正しいやり方は就寝前にすべてをキューに入れ、朝ノートパソコンを開けば完成した文字起こしが待っている状態にすることです。最新のAIなら1ファイル1〜3分で処理できるため、夜間実行の目的は計算時間を待つことではなく、何十ものアップロードを見張らずに済ませることにあります。

このガイドでは、整理・変換・送信・放置という一括ワークフローを解説します。経路は2つ。1回だけ済ませたい人向けのコード不要ルートと、毎月実行するチーム向けのAPIループです。

夜間一括処理が本当に有効なとき

ここは正直に言いましょう。1時間の録音1本なら、文字起こしはおよそ2分で終わります。一晩待つ必要はありません。

夜間一括処理が適切なのは次のような場合です：

• 20ファイル以上あり、1つずつクリックして回りたくない場合。
• アップロード帯域が本当のボトルネックである場合（非圧縮WAV 40ファイルは数GBになることも。夜間に任せれば、アップロード中じっと座っているプレッシャーから解放されます）。
• 定期的なワークフロー、リサーチアーカイブ、ポッドキャストのバックログ、四半期ごとの通話レビューなど、バッチが作業単位になる運用をしている場合。
• アカウントの同時実行数上限により、ジョブがどうせ順番待ちになる場合。

3ファイル以下なら、今すぐそのままアップロードしてください。「バッチ」という発想が効いてくるのは、手動送信の手間こそが実際の時間コストになるときです。

ステップ1：すべてを1つのフォルダにまとめる

元ファイルをすべて1つのディレクトリに入れます。あとで文字起こし結果を元ファイルと照合できるよう、ファイル名は統一しておきましょう：

interview_2026-06-15_smith.mp3
interview_2026-06-15_lee.mp3
interview_2026-06-16_kim.mp3

ファイル名にスペースを入れないようにしましょう。大半のワークフローでは問題になりませんが、シェルスクリプトやバッチツールでたまにつまずきの原因になります。

ステップ2：先にアップロードサイズを減らす

夜間一括処理の本当のボトルネックは、通常、処理ではなくアップロード帯域です。 48kHzステレオの1時間WAVは約600MB。同じ内容を128kbpsモノラルMP3にすると約60MBです。40ファイルだと24GB対2.4GB。50Mbpsの回線なら、アップロードに1時間超かかるか、10分未満で済むかの違いになります。

キューに入れる前にffmpegで変換します：

for f in *.wav; do
  ffmpeg -i "$f" -ac 1 -ar 16000 -b:a 64k "${f%.wav}.mp3"
done

各フラグの意味：-ac 1でモノラル、-ar 16000で16kHzサンプルレート（音声には十分）、-b:a 64kで小さなファイルに。この設定でも、音声録音の文字起こし精度は実質的に劣化しません。

iPhoneのボイスメモ（M4A）やZoomのMP4録画は、変換をスキップしてもそのまま問題なく使えます。ただし、64kbpsモノラルMP3で足りる場面で、ステレオ4K動画をアップロードしていないかだけ確認しましょう。

ステップ3：バッチをアップロードする

音声をテキストにツールは複数ファイルのアップロードに対応しています。フォルダ全体をアップロード領域にドラッグすれば、各ファイルが個別のジョブとしてキューに入ります。

40〜60ファイルの場合、回線速度とファイルサイズにもよりますが、アップロード完了まで5〜20分を見込んでください。その後は各ファイルが独立して処理されます。

アップロードが完了したらタブを閉じて構いません。 処理はサーバー側で続行されます。ブラウザを開けていなくても、結果はアカウントに保存されます。標準的なインタビュー録音40〜60本のバッチは、アップロード完了から2〜4時間以内にほぼ仕上がります。朝戻ってきてください。

定期的なバッチ向けのAPIルート

毎月または四半期ごとに実行するなら、送信ループをスクリプト化すると実際に時間を節約でき、手動クリックも完全になくなります。APIアクセスはBusinessプランで利用可能です。

最小限の送信ループ

API_KEY="your_api_key"
for f in ./audio/*.mp3; do
  curl -s -X POST https://convertaudiototext.com/api/v1/transcribe \
    -H "Authorization: Bearer $API_KEY" \
    -F "source=upload" \
    -F "language=en" \
    -F "file=@$f" \
    > "./jobs/$(basename "$f" .mp3).json"
  echo "submitted: $f"
  sleep 2
done

リクエスト間のsleep 2でレート制限内に収まります。APIはジョブIDを即座に返し、処理は非同期で走ります。

朝に結果をポーリングする

for job_file in ./jobs/*.json; do
  job_id=$(jq -r .job_id "$job_file")
  curl -s https://convertaudiototext.com/api/v1/result/$job_id \
    -H "Authorization: Bearer $API_KEY" \
    > "./results/${job_id}.json"
done

処理中のジョブはステータスフィールドを返します。完了したジョブは文字起こし結果を返します。朝にこれを1回実行すれば、すべて揃います。

ポーリングの代わりにWebhookで受け取る

より大きなバッチにはWebhookの方がすっきりしています。エンドポイントを一度登録すれば、各ジョブの完了時にAPIが結果をあなたのURLへPOSTします。文字起こし結果をデータベースやNotionワークスペースに直接書き込む自動パイプラインには、このパターンが適しています。

夜間実行を台無しにする落とし穴

送信時にレート制限への配慮をしないこと。 ほとんどのAPIには1分あたりの上限があります。10〜20件ずつ送信し、それぞれの間に短い間隔を空けましょう。総処理時間はまったく変わりませんが、仮に60ファイル中47ファイル目でレート制限エラーが起きても、復旧はずっと楽に済みます。

言語が分かっているコーパスで自動検出に頼ること。 言語の自動検出はファイルごとに数秒余計にかかり、短いクリップやノイズの多いクリップをたまに誤判定します。60ファイルあって言語が分かっているなら、すべてのリクエストで明示的に指定しましょう。時間の節約になり、稀な誤検出も避けられます。

失敗のチェックをしないこと。 一部のファイルは失敗することがあります。破損した音声、非対応のコーデック、アップロード中のネットワーク不調などです。朝になったら必ず結果ディレクトリをスキャンして、ジョブIDが欠けていないか確認し、該当ファイルを再送信しましょう。

出力でファイル名を無視すること。 60個の文字起こし結果が「Transcript_1.txt」から「Transcript_60.txt」まで並んでいたら役に立ちません。最初から出力構造に元のファイル名を残しましょう。

実際に機能するパターン

リサーチアーカイブ。 調査員が1週間のフィールドワークから25本のインタビューを持って帰ってきます。帰宅した夜にすべてをバッチに放り込み、言語を明示指定し、朝にはインデックス付きの文字起こしフォルダが開けます。これがインタビュー録音の文字起こしを規模拡大するワークフローです。

ポッドキャストのバックログ。 未公開エピソードの録音を50本抱えるプロデューサーは、バックログ全体を一夜の実行で処理し、その後は週に1本ずつ、エピソードの再シェアと合わせて文字起こしを公開していきます。エピソードごとの品質の考慮点については、ポッドキャストに最適な文字起こしも参照してください。

四半期ごとの顧客通話レビュー。 セールスオペスチームは毎月、四半期分の営業通話を夜間に一括処理し、出力に対して分析を実行して、検索可能なVOC（顧客の声）アーカイブを作ります。1時間あたりの文字起こしコストの比較記事は、定額無制限プランがなぜ継続的な通話分析において「全部文字起こし」を実現可能にするのかを示しています。

結果の活用方法

夜間バッチは大量のテキストを生み出します。実用的な出力パターンは3つあります：

ソースごとに1ファイル＋マスターインデックス。 各文字起こしをMarkdownまたはTXTファイルにし、ファイル名と文字起こしパス、話者数、長さを対応付けたCSVインデックスを用意します。

分析用の統合CSV。 コーパス全体で感情分析やトピック分析を行うなら、文字起こしを1つのCSVに連結し、ソースファイル列を付けます。ほとんどの質的分析ツールへの直接入力として使えます。

Webhook経由でのDB書き込み。 継続的なパイプラインでは、文字起こし結果がWebhookハンドラからPostgresやNotionへ直接POSTされ、検索やタグ付けの準備が整った状態になります。

コストの実際の計算

私の見方：夜間パターンは「何を文字起こしするか」の経済性を変えます。人手による文字起こしに1分1.50ドル払っているなら、選別して依頼するでしょう。定額無制限プランなら、「全部文字起こしして、あとで検索する」が、通話やインタビュー業務を定期的に行うチームにとって正当な戦略になります。

大規模なAPIボリュームのワークフローでは、主要クラウドAPIはバッチ文字起こしをストリーミング版より大幅に安い価格で提供しています。AssemblyAIは（2026年7月時点の料金ページ確認）Universal-2が0.15ドル/時間、Universal-3.5 Proが0.21ドル/時間です。AWS Transcribeはボリューム割引付きで0.024ドル/分前後から段階設定されています。これらは素のAPIの上に社内ツールを構築するチームに関係する話です。ほとんどのコンテンツチームや研究者にとっては、定額無制限プランの方が考えやすくシンプルです。

APIキーやスクリプトをセットアップせずに、きれいな文字起こしだけが必要なら、ConvertAudioToTextが複数ファイルのキューを直接処理します。Proプランは9.99ドル/月でファイル数の上限なし。Businessプランは自動パイプラインを構築するチーム向けにAPIとWebhookアクセスを追加します。

よくある質問

AIがこれほど速くなった今、夜間の一括文字起こしはまだ必要ですか？

数ファイル程度なら必要ありません。最新のAIは1時間の録音をおよそ1〜3分で処理できます。夜間一括処理が意味を持つのは、20ファイル以上あり、手動送信の手間、アップロード時間、進行バーを見張りたくないという点が実際のコストになるときです。これは大量処理のためのワークフローパターンであり、速度面の回避策ではありません。

一度にまとめて送信できるファイル数の実用上の上限はいくつですか？

プラットフォームの同時実行数の上限によります。たとえばAssemblyAIはデフォルトで200件の同時ジョブまで対応しています（2026年7月時点のドキュメント確認）。多くの個人向けツールはジョブをキューに入れ、順番に処理します。非常に大きなバッチ（200ファイル以上）の場合は、ドラッグ＆ドロップ1回ではなく、レート制限を考慮したペース配分でAPIを使いましょう。

アップロード前にWAVをMP3に変換すべきですか？

アップロード帯域が問題になるバッチでは、はい。1時間のWAVは600MBになることがありますが、同じ内容を64kbpsモノラルMP3にすると35〜60MB程度です。変換はffmpegの1行ループで数分しかかからず、大量バッチでは大幅なアップロード時間の節約になります。64kbpsモノラルでも、音声録音の文字起こし精度に実質的な影響はありません。

バッチ処理の途中で失敗したファイルにはどう対処しますか？

バッチ完了後は必ず結果をスキャンして、出力ファイルが欠けていないか確認しましょう。送信ループでジョブIDをソースファイル名と一緒にログに記録しておき、対応する結果ファイルがないジョブIDを特定します。そのファイルだけ再送信します。クリーンな音声のバッチはほとんど失敗なしで完結しますが、このチェックは30秒で済み、アーカイブに黙って穴が空くのを防げます。

参考情報源

• AssemblyAI 料金ページ： https://www.assemblyai.com/pricing （2026年7月確認）
• AssemblyAI バッチ文字起こしの同時実行数に関するドキュメント： https://support.assemblyai.com/articles/4854424693-how-does-the-concurrency-limit-work-for-transcription-requests （2026年7月確認）
• AWS Transcribe 料金： https://aws.amazon.com/transcribe/pricing/ （2026年7月確認）
• Deepgram 料金： https://deepgram.com/pricing （2026年7月確認）
• ConvertAudioToText 料金： https://convertaudiototext.com/pricing （2026年7月確認）
• AssemblyAI リアルタイムvsバッチ文字起こし： https://www.assemblyai.com/blog/real-time-vs-batch-transcription （2026年7月確認）