大規模プロジェクト向けバッチ文字起こし:2026年版プレイブック

1,000ファイルのアーカイブはUIの問題ではありません。プロジェクトがおおよそ50時間の音声を超えた瞬間から、問いは「どのツールを使うか」から「何が失敗したかを見失わずに、このパイプラインをどう回すか」へと変わります。

この記事では、そのパイプラインの構築について解説します。ファイル整理、API送信パターン、並列処理、レート制限、失敗時の対応、QCサンプリング、命名規則、そして主要API全体のコスト計算を取り上げます。ポッドキャストのバックカタログ移行でも、リサーチインタビューの処理でも、証言(デポジション)のアーカイブでも、同じパターンが使えます。

APIコールを1つ書く前に:マニフェスト

大規模バッチにおける最大の隠れたコストは再構築作業です。ジョブが数時間〜数日にわたって散らばった後、どのファイルが実行され、どれが失敗し、どの出力がどのソースに属するのかを突き止める作業です。

送信前に書いておいたCSVマニフェストが、そのコストをなくします。重要な列は以下の通りです:

バッチの実行中はマニフェストをその場で更新します。マニフェストを読み込み、completedの行をスキップし、pendingの行を送信し、submittedの行をポーリングするPythonスクリプトは、構造上べき等になります。いつでも安全に再起動できます。

スケールするディレクトリ構成

/batch-project/
    manifest.csv
    source/
        2024-Q1/
            interview-001-smith-2024-03-12.mp3
            interview-002-jones-2024-03-14.mp3
        2024-Q2/
            ...
    transcripts/
        2024-Q1/
            interview-001-smith-2024-03-12.txt
            interview-001-smith-2024-03-12.srt
            interview-001-smith-2024-03-12.json
        ...

{id}-{speaker}-{date}.{ext}という命名パターンにしておくと、問題が起きたときにファイルシステムからマニフェストを復元できます。ファイル名にスペースは避けてください。多くのストレージシステムで署名なしURLが壊れます。

適切なAPIの選び方

バッチプロジェクトでは、どのAPIを選ぶかは3つの要素で決まります:分単位のコスト、同時リクエスト上限、そして話者ダイアライゼーションやドメイン語彙が必要かどうかです。以下は2026年7月上旬時点でベンダーのページと照合した現在の料金です。

素の文字起こしボリュームでは、AssemblyAIがコスト面で最有力です。Deepgram Nova-3は割高ですが、ノイズの多い多話者音声で高い性能を示し、ドメイン語彙のためのキータームプロンプティングにも対応しています。AWS Transcribeは1秒単位で課金されますが、リクエストごとに15秒の最低料金があり、アーカイブに短いクリップが多い場合、この最低料金が実効コストを押し上げます。

ダイアライゼーション付きのAssemblyAI Universal-2で1,000時間のアーカイブを処理する場合、約170ドルを見込んでください。同じジョブをダイアライゼーション付きのDeepgram Nova-3で行うと約580ドルです。どちらも、クリアな音声であれば人手の文字起こしより桁違いに安くなります。

さらに詳しい内訳については、2026年の文字起こし料金比較と1時間あたりの文字起こしコストをご覧ください。

送信パターン:URL vs アップロード

**クラウドストレージに既にあるファイルはURL送信を使います。**APIが署名付きURLからダウンロードするため、ギガバイト級の音声を自分の回線で再アップロードする必要はありません。ほとんどのストレージシステム(S3、R2、GCS)は、シンプルなSDK呼び出しで署名付きURLを生成できます。

直接のマルチパートアップロードは、ローカルにしか存在せず他の場所に保存しないファイルだけに使います。大規模になると、ローカルからAPIへのアップロードにかかる帯域と時間のコストは急速に膨らみます。

送信ループ

再起動可能に設計した、基本的なPythonパターンです:

import csv
import time
import requests

API_KEY = "your_api_key"
BASE_URL = "https://api.assemblyai.com/v2"

def submit_job(url, language="en"):
    resp = requests.post(
        f"{BASE_URL}/transcript",
        headers={"authorization": API_KEY},
        json={
            "audio_url": url,
            "language_code": language,
            "speaker_labels": True,
        },
    )
    resp.raise_for_status()
    return resp.json()["id"]

def poll_job(job_id, timeout=600):
    deadline = time.time() + timeout
    while time.time() < deadline:
        resp = requests.get(
            f"{BASE_URL}/transcript/{job_id}",
            headers={"authorization": API_KEY},
        )
        data = resp.json()
        if data["status"] == "completed":
            return data
        if data["status"] == "error":
            raise RuntimeError(data.get("error", "unknown"))
        time.sleep(15)
    raise TimeoutError(f"Job {job_id} did not complete in {timeout}s")

1,000ファイルのバッチでは、単一スレッドで同期ポーリングしないでください。まずジョブをひとまとまり送信してIDを集め、その後並列にポーリングするか、エンドポイントが安定したらWebhookに切り替えます。

並列処理とレート制限

送信ループのスロットリング

同時実行上限が高くても、1,000リクエストを30秒で全部送ると、ほとんどのプロバイダーでレート制限に引っかかります。セマフォを使えば範囲内に収まります:

import asyncio
import aiohttp

CONCURRENCY = 50  # Stay under provider ceiling

async def submit_all(manifest_rows):
    sem = asyncio.Semaphore(CONCURRENCY)
    async with aiohttp.ClientSession() as session:
        tasks = [submit_with_sem(sem, session, row) for row in manifest_rows]
        return await asyncio.gather(*tasks, return_exceptions=True)

初期のバースト中に429レスポンスが出る場合は、送信の間に短いスリープ(10〜50ミリ秒)を挟みます。

本番システム向けのWebhook vs ポーリングのトレードオフの整理が必要なら、その記事で意思決定ツリーを解説しています。

失敗時の対応

言語混在バッチでの言語処理

カスタム語彙:最初に設定する価値あり

品質管理:完成と呼ぶ前にサンプル確認を

**1,000ファイルのバッチでは、すべての文字起こしをそのまま完成と認めてしまいたくなります。**サンプル抽出とレビューのステップはプロジェクト時間の5〜10%しかかかりませんが、そうしなければ文字起こしのあらゆる下流利用に波及するような体系的な問題を捉えられます。

何をサンプリングするか

完了した文字起こしからランダムに5%を抽出します。バッチ内の主要なソースタイプごとに少なくとも1ファイルを含めてください(異なる録音環境、異なる話者、異なる機材)。

各サンプルファイルから2分程度の区間を、文字起こしを読みながら聞きます。次のような点にフラグを立てます:

• 繰り返し現れる用語が一貫して誤認識されている(語彙リストに追加し、該当ファイルを再実行する)
• 多話者ファイルでの話者の誤り付け(ダイアライゼーションが有効だったか確認。音声品質も確認)
• 信頼度が下がった区間(背景ノイズや発話の重なりと相関することが多い)

重要度の高いファイルのスポットチェック

ファイルの中には、他より重要なものがあります。リサーチプロジェクトの基軸となるインタビュー。法務アーカイブの鍵となる証言。ポッドキャストの記念すべき第1回。サンプルの結果がどうであれ、こうしたファイルは重点的にレビューするために取り出してください。AIの信頼度スコアは「このファイルは重要だった」という事実と完全には一致しません。

信頼度しきい値はゲートではなくシグナルとして使う

一部のプロバイダーはJSONレスポンスで単語レベルの信頼度スコアを返します。平均信頼度がおよそ0.80を下回る文字起こしを人手レビュー候補としてフラグを立てますが、自動で捨ててはいけません。クリアな音声での低信頼度は、たいていドメイン語彙がモデルにとって馴染みがないことを意味します。ノイズの多い音声での低信頼度は、たいてい音声の再録音が必要か、そのファイルは諦めるしかないことを意味します。

よくあるプロジェクト規模別のコスト計算

月額$9.99のCATT Proプランは、月100時間前後までの継続的な利用量に適しています。一度きりの大規模移行には、従量課金のAPI料金の方が柔軟です。月額契約なしで、実行した分だけ支払えます。

損益分岐点の分析については、無制限 vs 従量課金の文字起こし料金をご覧ください。ユーザーに代わってこれらのAPIを呼び出す製品を作っているなら、文字起こしAPI呼び出しのコスト最適化と文字起こし結果のキャッシュが、影響の大きい2つのレバーを解説しています。

パイプラインを組まずにただファイルを文字起こししたい、単発のバッチ処理や1つのプロジェクトの短納期対応が必要という場合は、ConvertAudioToTextの/tools/audio-to-textで、セットアップなしに音声・動画・URLソースを処理できます。

プロジェクトタイプ別の文字起こし後処理

文字起こしが揃ったら、下流の作業はプロジェクトごとに変わります:

**リサーチプロジェクト:**参加者発話単位でのトピックモデリング、MAXQDAやNVivoでのテーマコーディング、引用データベース向けの引用文抽出。ほとんどのAPIのJSON出力には単語レベルのタイムスタンプが含まれるため、タイムスタンプ付きの引用を簡単に復元できます。

**メディアアーカイブ:**検索インデックスの構築(ElasticsearchやMeilisearchがうまく機能します)、メタデータの拡充、各文字起こしをLLMに通したエピソード単位の要約。

**法務アーカイブ:**キーワードインデックス、特権情報レビューのワークフロー、判例引用の抽出。ここではカスタム語彙が何倍にもなって報われます。事件名や法令の参照は正確である必要があるためです。

**コンテンツ制作:**文字起こしを記事、ニュースレター、SNS投稿に転用します。編集ワークフローについてはインタビュー録音の文字起こし方法をご覧ください。

正しい構築順序

新しいバッチプロジェクトでは、この順序が最も時間を節約します:

1. 命名規則とディレクトリ構成を決める。
2. マニフェストCSVを作成または記入する。
3. マニフェストの読み書きを含む送信スクリプトを書く。
4. 10ファイルのパイロットを実行し、出力をレビューする。
5. パイロットで見つかった問題を修正する(語彙、言語設定、フォーマットの問題)。
6. 本番のフルバッチを実行する。
7. 5%をサンプリングしてレビューする。
8. 失敗キューをリトライする。
9. 下流の処理に引き渡す。

私の考えでは、このリストで最も重要なのはパイロットのステップです。ワークフローの問題を10ファイルの時点で見つけるのは安上がりですが、実際にお金と時間を使い終わった後の800ファイル目で見つけるのは高くつきます。10ファイルは、フルジョブにコミットする前にステークホルダーに見せられる、実際の精度サンプルにもなります。

FAQ

文字起こしAPIには何ファイルまで並行して送信できますか?

AssemblyAIはデフォルトで最大200件のジョブを同時に処理します。Deepgramの録音済みエンドポイントは、Pay As You GoプランとGrowthプランで最大50件の同時リクエストが可能です。いずれも上限はプロジェクト単位です。継続的な大量処理のために上限引き上げを希望する場合は、営業に問い合わせてください。

初回バッチでの通常の失敗率はどのくらいですか?

初回のパスではファイルの3〜5%が失敗すると想定してください。指数バックオフ付きのリトライパスで、そのうちの60〜80%は通常解決できます。残りの失敗にはたいてい根本原因があります:ソース音声の破損、未対応のコーデック、あるいは完全に無音のファイルです。マニフェストがあれば、成功したファイルを再実行することなくこれらを仕分けできます。

バッチジョブのステータス追跡にはWebhookとポーリングのどちらを使うべきですか?

数百ファイル未満のバッチなら、15〜30秒間隔のポーリングがシンプルかつ効果的です。数千ファイル規模のバッチでは、Webhookによって繰り返しのHTTPオーバーヘッドがなくなり、完了したジョブを見逃す可能性も減ります。トレードオフとして、Webhookには安定した公開エンドポイントが必要で、インフラが増えます。意思決定ツリーについては、文字起こしのWebhook vs ポーリングの記事をご覧ください。

言語が混在するアーカイブはどう扱えばよいですか?

送信前にファイルごとに言語を事前分類する(軽量な言語識別パスで十分です)か、すべての言語を単一のモデル階層で処理できる多言語モデルを使うかのどちらかです。AssemblyAI Universal-2は99言語、Deepgram Nova-3 Multilingualは30以上の言語に対応しています。大規模処理では、自動検出に頼るより送信時に言語を明示的に指定する方が常に速く、正確です。

カスタム語彙の設定はどんな場合に価値がありますか?

医療用語、法律用語、技術用語、固有ブランド名など、ドメイン固有の用語を含むアーカイブであれば、語彙リストが役立ちます。Deepgram(1リクエストあたり最大100キーターム)もAssemblyAI(Universal-3 Proで最大1,000語)も、別途トレーニングなしでインラインの語彙ヒントに対応しています。リストは一度作れば、バッチ内の全ファイルで使い回せます。既知の用語における精度向上は大きいものです。

出典

• Deepgram 料金ページ、2026年7月閲覧：https://deepgram.com/pricing
• Deepgram APIレート制限、2026年7月閲覧：https://developers.deepgram.com/reference/api-rate-limits
• Deepgram キータームプロンプティング ドキュメント、2026年7月閲覧：https://developers.deepgram.com/docs/keyterm
• AssemblyAI 料金ページ、2026年7月閲覧：https://www.assemblyai.com/pricing
• AssemblyAI 大規模バッチ文字起こしガイド、2026年7月閲覧：https://www.assemblyai.com/blog/large-scale-audio-transcription
• Amazon Transcribe 料金ページ、2026年7月閲覧：https://aws.amazon.com/transcribe/pricing/
• OpenAI 文字起こし料金、2026年7月閲覧：https://developers.openai.com/api/docs/pricing