文字起こしAPIの比較と選び方｜主要7サービスの料金・日本語対応・使い方【2026年10月】

文字起こしAPIは、OpenAI・Deepgram・AssemblyAI・Google Cloud・AWS・Azure・AmiVoiceの7サービスで、録音済み音声の単価が1分あたり0.0025ドル相当から0.016ドルまで開きます。「Whisper API」として広まったOpenAIのwhisper-1は、2026年8月の告知どおり2027年2月26日に終了するため、これから組むなら後継モデル前提のコードが必要です。この記事では、比較表、公式ドキュメントに沿ったOpenAI・Deepgram・AssemblyAIのAPI実装例、ローカルWhisperを同じ日本語音声で実際に測った処理時間と誤り率、月100時間と1,000時間の試算の順に整理します。料金は2026年10月20日に各社の公式料金ページで確認した値で、契約前には公式で確かめてください。

まとめ｜2027年2月のwhisper-1終了を踏まえた文字起こしAPIの選び方

• 録音済みの日本語議事録なら、OpenAIの後継モデルgpt-transcribe（0.0045ドル/分）が第一候補。話者分離までAPIに任せるならAssemblyAI（話者分離込みで0.17ドル/時間）が手数を減らせます。
• 新規実装でwhisper-1・gpt-4o-transcribe系を選ばない。4モデルと英訳の /v1/audio/translations は2027年2月26日に停止します。
• 即時性が要らない大量処理なら、Azureのバッチ（0.18ドル/時間）とGoogleのDynamic Batch（0.003ドル/分）が最安帯です。
• 同時字幕や音声エージェントなら、ストリーミング単価の低いDeepgram Nova-3（日本語の単言語で0.0048ドル/分のキャンペーン価格）が扱いやすい選択肢です。
• 音声を社外に出せないならローカルWhisper。CPUだけでもsmallモデルは音声の長さより短い時間で処理でき、用語ヒントを渡すと文字誤り率は2.8%でした（後述の実測）。月1,000時間でもAPIの定価は数百ドルなので、コスト目的だけでローカルを選ぶ理由は薄いと考えます。

文字起こしAPIとクラウド・ローカルWhisperの違い

文字起こしAPI（音声認識API、Speech-to-Text API）は、音声データを送るとテキストを返すクラウドサービスです。対して「ローカル型」は、Whisperのようなオープンソースモデルを自社のマシンやサーバーで動かす方式を指します。音声認識の仕組みや精度の考え方から整理したい場合は、音声認識とは？AIの仕組み・精度の考え方・業務導入の判断基準を先に読むと比較表の読み方がつかめます。

付加機能と運用負荷で分かれるAPIとローカルWhisperの判断軸

APIの利点は、推論サーバーの構築・保守をサービス側に任せられる点です。話者分離・タイムスタンプ・要約の提供有無や追加料金は、サービスとモデルによって異なります。弱点は音声を外部に送ることと、量に比例して従量課金が増えることです。ローカル型は音声を外に出さない代わりに、GPUの準備・モデル更新・スケーリングを自前で抱えます。判断軸は「音声を外部送信できるか」と「月間の処理時間」の2つで、実務では前者が先に決まります。

OpenAIの旧文字起こしモデル4種と英訳エンドポイントの2027年2月停止

OpenAIは2026年8月26日、公式の非推奨モデル一覧（Deprecations）でwhisper-1・gpt-4o-transcribe・gpt-4o-mini-transcribe・gpt-4o-transcribe-diarizeの4モデルを2027年2月26日に停止すると告知しました。同じ日に、音声を英語へ訳す /v1/audio/translations も停止し、移行先は v1/realtime/translations です。文字起こしの移行先は、録音済みファイル向けのgpt-transcribeとライブ用途のgpt-live-transcribe（どちらも2026年7月28日公開）です。

影響が大きいのは「Whisper API」として普及したwhisper-1でしょう。公式の文字起こしガイドは、単語・区間のタイムスタンプ（timestamp_granularities[]）にwhisper-1を使うよう案内しており、後継のgpt-transcribeはタイムスタンプを返しません。SRT字幕を作る処理は、停止日までにローカルWhisperか他社APIへ寄せる設計変更が要ります。

主要7サービスの文字起こしAPI料金・日本語対応・リアルタイム比較表

単価は録音済みファイル（バッチ・非同期）処理の定価です。ストリーミングは別単価になるサービスが多い点に注意してください。

出典はOpenAIの料金ページ、Deepgramの料金ページ、AssemblyAIの料金ページ、Google Cloud Speech-to-Textの料金ページ、Amazon Transcribeの料金ページ、Azure Speechの価格ページ、AmiVoice APIの料金ページです。AWSは東京リージョンの価格表（AWS Price List API、2026年9月11日版）で1秒0.0001ドル、Azureは東日本リージョンのバッチ（0.18ドル）とFast Transcription（0.36ドル）をAzure Retail Prices APIで確認しました。AmiVoiceは税込の汎用エンジンで、非同期HTTPのログ保存あり（79.2円）から同期・WebSocketのログ保存なし（148.5円）までの幅です。

1分あたり単価と無料枠で並べた7サービスの安い順と注意点

1分あたりに揃えると、AssemblyAIのUniversal-2（0.0025ドル相当）、GoogleのDynamic Batch（0.003ドル）、Azureのバッチ（0.003ドル相当）が最安帯です。続いてDeepgram Nova-3（0.0043ドル）、gpt-transcribe（0.0045ドル）、Amazon TranscribeとAzure Fast Transcription（ともに0.006ドル相当）が並びます。

読み違えやすい箇所は4つあります。GoogleのDynamic Batchは結果が最長24時間後になる低優先度処理で、Azureのバッチもジョブを投げて完了を待つ非同期方式です。Googleの「月60分無料」はV1 APIの料金表の枠で、V2の標準認識は0分目から課金されます。AssemblyAIは2026年10月6日のロードマップで、Universal-2を指定した日本語のリクエストをUniversal-3.5 Proで処理し、料金はUniversal-2のままにすると告知しました。AWSはAmazon Transcribeの料金・使い方の解説でも触れたとおり、新規アカウントの無料利用枠がクレジット制の無料プランへ変わっており、料金ページに残る「月60分・12か月」がそのまま当たるかは契約形態で確かめる必要があります。

日本語の精度を左右するカスタム語彙・キーワード指定の対応状況

日本語は同音異義語と社内固有の製品名で誤りが出やすく、精度の差は「語彙を事前に渡せるか」で決まる場面が多くあります。gpt-transcribeはkeywordsとprompt、AWSはカスタム語彙、GoogleとAzureはフレーズヒントやカスタムモデル、AssemblyAIはUniversal-3.5 ProのKeyterms Prompting（最大1,000語・1時間0.05ドル）を持つ構成です。AmiVoiceは単語登録に加えて医療・金融・保険などの分野別エンジンを用意しています。

Deepgramは公式の対応言語一覧でNova-3の単言語モデルに日本語（ja）を載せています。サービス別の仕様はAmiVoice APIの料金・精度・対応言語の解説やGoogle Cloud Speech-to-Textの料金・日本語対応・APIの使い方にまとめました。

ストリーミングの課金の数え方が違う3つのパターン

同時字幕や音声エージェントには、音声を流しながら逐次テキストを返すストリーミングが必須です。見落としやすいのは課金の数え方の違いです。

• 送った音声の長さ：Deepgram Nova-3（単言語0.0048ドル/分のキャンペーン価格、通常0.0077ドル）、Amazon Transcribe（東京で0.01ドル/分）、OpenAIのgpt-live-transcribeとgpt-realtime-whisper（0.017ドル/分）
• 接続している時間：AssemblyAIはセッションの継続時間で課金し、無音でも料金が発生します。日本語に対応するUniversal-3.6 Pro Realtimeは0.45ドル/時間で、0.15ドルのUniversal-Streamingは英語と欧州5言語だけです
• 発話区間だけ：AmiVoiceは無音区間を課金対象に含めず、1秒単位で集計します

会話の密度が低い受付窓口や会議室の字幕ほど、接続時間課金は不利になります。

OpenAIの文字起こしAPIをPythonで動かす手順とモデル移行

ここでの「Whisper API」はOpenAIがクラウドで提供する音声認識APIで、後述するローカル実行のオープンソースWhisperとは別物です。

gpt-transcribe・gpt-live-transcribe・旧whisper-1の役割と単価

gpt-transcribeは旧gpt-4o-transcribeより25%安く、移行で費用は増えません。名前にWhisperが残るgpt-realtime-whisperは2026年5月7日公開のライブ専用モデルで、モデルページの対応表では v1/realtime/transcription_sessions だけに対応し、ファイルを送る /v1/audio/transcriptions では使えません。ライブ用の実装はGPT-Live-Transcribeの低遅延ストリーミング実装とGPT-Transcribeとの使い分けで詳しく扱っています。

Python SDKで音声ファイルを起こし日本語の用語ヒントを渡す実装

公式SDKでは、音声ファイルを開いて client.audio.transcriptions.create に渡します。languagesとkeywordsはリストで、Pythonでは extra_body に入れるのが公式ガイドの書き方です。2026年10月20日時点のopenaiパッケージ3.35.1はPython 3.10以上が必要です。実行環境に python -m pip install openai==3.35.1 で導入し、環境変数OPENAI_API_KEYを設定してから実行します。

from openai import OpenAI

client = OpenAI()  # 環境変数 OPENAI_API_KEY を読む

with open("meeting.mp3", "rb") as f:
    result = client.audio.transcriptions.create(
        model="gpt-transcribe",
        file=f,
        extra_body={
            "languages": ["ja"],                       # 日本語を明示して言語判定の揺れを防ぐ
            "keywords": ["一創", "受託開発", "要件定義"],  # 社内用語のヒント
        },
    )
print(result.text)

公式ガイドはキーワードを「出力を強制しないヒント」と位置づけ、関係する用語だけに絞るよう求めています。キーワードに改行や山括弧を含めるとリクエスト全体が拒否され、単数形のlanguageはlanguagesと併用できません。会議ごとに参加者名やプロジェクト名を差し替えると、固有名詞の誤変換を減らせます。

25MB上限を超える長時間音声をffmpegで分割して送る手順

1ファイルの上限は25MBで、対応形式はmp3・mp4・mpeg・mpga・m4a・wav・webmです。16kHz・16bit・モノラルの非圧縮PCMでは、音声部分は計算上1秒32,000バイトです。25MBを25,000,000バイトとして扱うと、ヘッダーを除いて約13分1秒に相当します。64kbpsのモノラルMP3なら43.9秒で352,268バイトだったので、10分でも約4.8MBに収まります。

# 10分（600秒）ごとに分割。64kbpsのモノラルなら1本あたり約4.8MB
ffmpeg -i long_meeting.mp3 -f segment -segment_time 600 -ac 1 -ar 16000 -c:a libmp3lame -b:a 64k part_%03d.mp3

import glob
from openai import OpenAI

client = OpenAI()
texts = []
for path in sorted(glob.glob("part_*.mp3")):
    with open(path, "rb") as f:
        r = client.audio.transcriptions.create(
            model="gpt-transcribe",
            file=f,
            extra_body={"languages": ["ja"]},
        )
    texts.append(r.text)
print("\n".join(texts))

固定秒数の分割は境界で単語が切れることがあり、公式ガイドも文の途中で切らないよう注意しています。精度を詰める段階では、ffmpegのsilencedetectで無音位置を拾って切る方式に置き換えてください。

stream=Trueで部分結果を受け取る実装とライブ字幕の構成

録音済み音声でも、stream=True を付けると部分結果が transcript.text.delta イベントで届き、最後に transcript.text.done で全文が返ります。Realtimeのセッションは要りません。

with open("chunk.wav", "rb") as f:
    stream = client.audio.transcriptions.create(
        model="gpt-transcribe",
        file=f,
        stream=True,
        extra_body={"languages": ["ja"]},
    )
    for event in stream:
        if event.type == "transcript.text.delta":
            print(event.delta, end="", flush=True)

マイクからの同時字幕は、Realtime文字起こしのガイドのとおり、type: “transcription” のセッションへ24kHzのPCM音声を送り続ける構成で、モデルはgpt-live-transcribeを使います。遅延と精度は audio.input.transcription.delay を minimal から xhigh まで段階で選んで調整し、server_vad は使えません。gpt-live-transcribeは単語タイムスタンプも話者ラベルも返さないため、字幕ファイルが要るなら録音後に別経路で作ります。

ローカルWhisperで音声ファイルとマイク入力を文字起こしする手順

API課金を避けたい、または音声を外部に出せない場合は、オープンソースのWhisperをローカルで動かします。PyTorch上の実装やTransformers経由の使い方はWhisperをPyTorchで動かす手順で掘り下げています。

faster-whisperのtiny・base・small・turboを同じ日本語音声で比べた処理時間と誤り率

モデルの大きさで精度と速度がどれだけ変わるかを、同じ音声で測りました。音声はmacOSの音声合成（Kyoko）で読み上げた43.9秒の会議冒頭の原稿で、受託開発・要件定義・キューバネティスなどの用語と、日付・数量を含みます。環境はIntel Core i9-9880HのCPUのみ、faster-whisper 1.2.1、compute_type="int8"、beam_size=5、language="ja" です。文字誤り率（CER）は句読点と空白を除き、原稿の数字を算用数字に揃えてから計算しました。

処理時間はヒントなしの値です。tinyとbaseは「受託開発」を「住宅開発」、「進捗」を「新直」などと起こし、議事録にそのまま使える水準ではありませんでした。initial_prompt に用語を並べると全モデルで誤り率が下がり、base以上では「住宅開発」が「受託開発」に直っています。turboはヒントありで0.5%と最も正確でしたが、ヒントなしでは原稿にない「ご視聴ありがとうございました。」を末尾に足しました。無音や話し終わりで定型句を生成するのはWhisper系で知られた誤りで、議事録では削除処理か無音区間の切り落としが要ります。また、どのモデルも「基本設計」を「基本設定」と起こしたため、ヒントで直らない誤りは人手の校正か辞書置換で潰す前提で組みます。

CPUだけで音声長より短く処理できたのはsmallまでで、turboは音声の2.3倍の時間がかかりました。今回のCPU測定ではsmall＋用語ヒントが速度とCERを両立しました。GPU環境でのturboの速度は測っていないため、導入候補のGPUと実際の録音で比較して選びます。合成音声は発音が明瞭で雑音もないため、実際の会議録音では誤り率はこれより上がると見てください。

openai-whisperのインストールとturboモデルで日本語を起こす手順

openai/whisperの公式リポジトリのパッケージ（PyPIの最新は20250625）を入れ、モデルをロードして音声を渡します。デコードにffmpegを使うため、OSにffmpegを先に入れておきます。

pip install -U openai-whisper

import whisper

model = whisper.load_model("turbo")   # tiny/base/small/medium/large/turbo から選択
result = model.transcribe("audio.mp3", language="ja")
print(result["text"])

READMEではturboはlarge-v3を高速化した版（約809Mパラメータ、VRAM約6GB）とされています。日本語中心なら、日本語で追加学習された派生モデル（kotoba-whisperなど）も候補です。

faster-whisperとwhisper.cppでGPUなし環境も速くする設定

CTranslate2で再実装したfaster-whisperは、同じモデルでメモリ使用量と処理時間を減らせます。上の実測ではdevice=”cpu”、compute_type=”int8″、beam_size=5を指定し、initial_promptには「キューバネティス、要件定義、受託開発、情報システム部」を渡しました。

from faster_whisper import WhisperModel

model = WhisperModel("small", device="cuda", compute_type="float16")  # GPUなしは device="cpu", compute_type="int8"
segments, info = model.transcribe(
    "audio.mp3",
    language="ja",
    initial_prompt="受託開発、要件定義、キューバネティス",  # 用語ヒント
)
for seg in segments:
    print(f"[{seg.start:.1f}s - {seg.end:.1f}s] {seg.text}")

segmentsは区間ごとの開始・終了秒を持つため、whisper-1の停止後もここからSRT字幕を組み立てられます。C++実装のwhisper.cpp（最新はv1.9.5）はCPUのみの環境やエッジデバイスでも量子化モデルで動き、入力は16bitのWAVに変換して渡します。

git clone https://github.com/ggml-org/whisper.cpp
cd whisper.cpp
sh ./models/download-ggml-model.sh base
cmake -B build
cmake --build build -j --config Release
ffmpeg -i meeting.mp3 -ar 16000 -ac 1 -c:a pcm_s16le meeting.wav
./build/bin/whisper-cli -m models/ggml-base.bin -l ja -osrt -f meeting.wav

-osrt でSRT字幕を書き出せるので、whisper-1で字幕を作っていた処理の代替経路になります。

マイク入力を5秒チャンクで区切る準リアルタイム文字起こしの実装

Whisperはまとまった音声を処理する設計で、マイクの生バイト列をそのまま渡しても動きません。音声を数秒ごとのチャンクに区切って順次認識します。

import whisper
import sounddevice as sd
import numpy as np

model = whisper.load_model("base")
sr = 16000          # サンプリングレート
chunk_sec = 5       # 5秒ごとに認識

while True:
    audio = sd.rec(int(chunk_sec * sr), samplerate=sr, channels=1, dtype="float32")
    sd.wait()
    result = model.transcribe(np.squeeze(audio), language="ja")
    print(result["text"])

この方式は準リアルタイムで、チャンク境界で単語が切れます。このコードは録音完了後に認識し、その間の音声は録音しません。連続字幕には、InputStreamなどによる録音と、キューを介した認識処理を並行させる実装が必要です。smallを連続処理に使う場合も、採用する実装とチャンク長で処理時間を測り、録音キューが増え続けないことを確認します。低遅延が必要ならwhisper_streamingやストリーミングAPIのほうが実用的で、軽量なローカルモデルならWhisperと比較したMoonshine Voiceの導入手順も選択肢になります。

DeepgramとAssemblyAIのAPIで話者分離付きの日本語文字起こしを試すコード

どちらも登録時の無料クレジットがあり、クレジットカードなしで検証を始められます。

DeepgramのNova-3に日本語音声を送り話者分離付きで受け取るcurl

録音済み音声を1回のHTTPリクエストで送り、JSONで結果を受け取ります。Deepgramの話者分離ドキュメントでは、以前の diarize=true は非推奨となり、diarize_model=latest だけで話者分離が有効になります。smart_format=true は数字や句読点を整形します。

curl -X POST \
  "https://api.deepgram.com/v1/listen?model=nova-3&language=ja&diarize_model=latest&smart_format=true" \
  -H "Authorization: Token $DEEPGRAM_API_KEY" \
  -H "Content-Type: audio/wav" \
  --data-binary @meeting.wav

録音済み単価は単言語0.0043ドル/分で、日本語は単言語モデルの language=ja で指定します。200ドルのクレジットは0.0043ドルで割ると約775時間分です。SDKの版差や同時接続数の上限はDeepgramの料金・日本語対応・APIの使い方にまとめました。

AssemblyAIでアップロードから話者ラベル付き結果の取得までのPython

非同期方式で、音声をアップロードしてジョブを作り、完了まで状態を問い合わせます。流れは公式クイックスタートのHTTP版と同じです。

import os
import time
import requests

BASE = "https://api.assemblyai.com"
headers = {"authorization": os.environ["ASSEMBLYAI_API_KEY"]}

with open("meeting.mp3", "rb") as f:
    upload = requests.post(BASE + "/v2/upload", headers=headers, data=f)
audio_url = upload.json()["upload_url"]

job = requests.post(BASE + "/v2/transcript", headers=headers, json={
    "audio_url": audio_url,
    "language_code": "ja",
    "speech_models": ["universal-2"],
    "speaker_labels": True,
}).json()

while True:
    t = requests.get(BASE + "/v2/transcript/" + job["id"], headers=headers).json()
    if t["status"] == "error":
        raise RuntimeError(t.get("error", "Transcription failed"))
    if t["status"] == "completed":
        break
    time.sleep(3)

for u in t.get("utterances") or []:
    print(u["speaker"], u["text"])

speech_models を省略すると既定の [“universal-3-5-pro”, “universal-2”] が使われ、日本語はUniversal-3.5 Pro（0.21ドル/時間）で処理されます。上のコードはUniversal-2を明示しており、2026年10月6日以降はUniversal-2を指定した日本語もUniversal-3.5 Proが処理し、料金はUniversal-2のままです。録音済みの話者分離は1時間0.02ドルの追加で、Universal-2と合わせて0.17ドル/時間です。全体像はAssemblyAIの日本語対応・料金・APIの使い方にまとめています。

用途別の文字起こしAPIの選び方｜議事録・音声エージェント・機密音声

単価の安さだけで選ぶと、必要な機能が足りずに作り込みが増えます。代表的な3つの用途で判断基準を示します。

録音済み議事録のバッチ処理で精度と単価が釣り合うAPI

録音済みファイルの一括処理ではgpt-transcribeが手堅く、話者分離が要るならAssemblyAIが手数を減らせます。gpt-4o-transcribe-diarizeを使っている場合、OpenAIの後継2モデルは話者ラベルを返さないので、移行先は他社になります。Google系ならGemini 3.5 Transcribe（約0.005ドル/分）が話者分離に対応しますが、モデルページでは話者分離を有効にすると1リクエスト30分までで、3人以上の割り当ては実験的機能とされています。GoogleのGeminiで会議メモまで済ませる運用はGeminiで議事録を作る方法、完成品の議事録ツールを買うかAPIで組むかはAI議事録・自動文字起こしの仕組みと法人での選び方が判断材料になります。

音声エージェント・同時字幕で遅延と常時接続コストを抑えるAPI

日本語の同時字幕では、7サービスで最もストリーミング単価が低いDeepgram Nova-3を第一候補にします。日本語音声での応答速度は本記事では比較していないため、採用前に測定します。OpenAIで揃えるならgpt-live-transcribeで、delayの段階を変えて自社の音声で遅延と誤り率を測ってから決めます。GoogleのDynamic BatchやAzureのバッチのような非同期の経路は、結果を待つ時間が読めないため、この用途では選びません。

日本語の専門用語・機密音声・オンプレ要件がある現場のAPIと相談先

専門用語と国内サポートを重視するならAmiVoiceが適します。音声を外部に出せない要件では、ローカルWhisperか、コンテナ提供の形態を持つAzure Speechを検討する流れです。Azureの課金体系はAzure AI Speechの料金解説（無料枠・従量課金S0）で整理しました。設計・開発を外部に任せたい場合は、一創のAI音声認識システム開発でAPI選定から議事録・コールセンター向けの組み込みまで相談できます。

月間処理時間で試算する文字起こしAPIの総額とローカル運用への分岐点

定価が一律のサービスが多いため、月100時間と1,000時間で並べると差の大きさがそのまま見えます。

月100時間と1,000時間で比べた定価ベースの月額試算表

録音済み音声を定価で処理した場合の月額です（無料枠・割引は含めない）。

即時性を求めない処理なら、月1,000時間でも多くのサービスが月200〜400ドルの帯に入ります。AmiVoiceは発話区間だけの課金のため、無音の多い会議録音では表より下がります。

ローカルWhisperがAPIより安くなる条件と安くならない条件

ローカル運用ではCPUまたはGPU機器の費用・電力・保守工数を見積もります。API側にも連携処理・保存・障害対応の費用があるため、次の270ドルは総運用費ではなく文字起こしAPIの利用料として比較します。gpt-transcribeで月1,000時間を処理しても定価は270ドルで、GPUインスタンスの常時稼働費と担当者の工数を足すと、多くの企業ではこの額を下回りません。上の実測のとおりCPUだけでもsmallは回せますが、1,000時間の音声を音声長の0.7倍で処理すると700時間かかり、1台では1か月の稼働時間（約720時間）をほぼ使い切ります。

結論として、コスト削減だけを理由にローカルへ切り替える判断は、月1,000時間規模でも成り立ちにくいと考えます。ローカルが正解になるのは、音声を社外に出せない規程がある場合、社内のGPU資産の余剰時間で回せる場合、ネットワークのない現場で動かす場合です。

文字起こしAPIを採用しない場面と導入で詰まりやすい失敗パターン

25MB制限・接続時間課金・データ保存設定で起きる失敗パターン

多いのは、検証では短い音声しか使わず、本番の1時間録音で初めて25MB上限のエラーに当たるケースです。16kHzモノラルのWAVなら計算上13分ほどで上限に届くので、分割処理は最初から組み込みます。AssemblyAIのストリーミングを常時接続にして、無音時間まで課金される設計も起きがちな失敗です。

データの扱いも見落とされやすい論点です。GoogleのV1 APIはデータロギングを有効にすると単価が下がる代わりに、音声がモデル改善に使われます。AmiVoiceも「ログ保存あり」のほうが安い体系です。社内規程で音声の第三者利用を禁じているのに安い側で見積もると、後から前提が崩れます。

クラウドAPIを見送りローカルや人手の文字起こしに回すべき条件

• 契約や社内規程で、音声データを社外のサービスへ送れない（ローカルWhisperかオンプレ提供へ）
• 処理が月数時間の取材音声で、修正に必ず人手を掛ける（文字起こしアプリか外注で足りる）
• 逐語の証拠資料など誤変換が1か所も許されない（APIは下書きにとどめ人手で校正）

月数十時間以上を定型的に処理し、結果を検索や要約に回す用途ならAPIの費用対効果は高くなります。アプリで足りるか迷う段階なら、文字起こしアプリの無料・有料の選び方と用途別の使い分けから比べてください。

よくある質問｜文字起こしAPIの無料枠・Whisper・日本語精度・話者分離

文字起こしAPIの比較で多い質問に答えます。

無料で使える文字起こしAPIと各社の無料枠はどのくらいありますか？

2026年10月時点で、Deepgramは200ドル、AssemblyAIは50ドルのクレジットが登録時に付きます。AmiVoiceはエンジンごとに毎月60分、Azureはリアルタイムの文字起こしが月5時間、Google CloudはV1 APIで月60分が無料です。AWSは新規アカウントの無料利用枠がクレジット制へ変わったため、契約時の条件を確かめてください。OpenAIに文字起こし専用の無料枠はありません。恒常的に無料で使うなら、API課金の発生しないローカルWhisperが選択肢です。

Whisper APIとローカルWhisperはどちらが安く運用できますか？

多くの企業ではAPIのほうが安く収まります。後継のgpt-transcribeは0.0045ドル/分で、月1,000時間でも定価270ドルです。ローカルはAPI課金がゼロでも、GPUサーバーと運用の人件費がかかります。ローカルを選ぶ理由はコストより、音声を社外に出せない要件にあると考えてください。なお「Whisper API」のwhisper-1は2027年2月26日に停止します。

日本語の精度が高い文字起こしAPIはどれを選べばよいですか？

専門用語辞書や分野別エンジンを持つ日本語特化型ならAmiVoice、汎用APIならkeywordsで用語ヒントを渡せるgpt-transcribeが扱いやすい選択肢です。精度は音声品質・話者数・専門用語の多さで変わります。自社の会議録音を10分程度用意し、2〜3社で同じ音声を起こして誤り箇所を比べるのが確実です。

Whisperでリアルタイムに文字起こしするにはどうすればよいですか？

ローカルのWhisperは、マイク音声を5秒前後のチャンクに区切って順に認識する準リアルタイム方式になります。ただし本文のコードは認識中に録音が止まるため、途切れない字幕には録音と認識を並行させる実装が要ります。クラウドで低遅延にするなら、OpenAIのgpt-live-transcribeかgpt-realtime-whisper（どちらも0.017ドル/分）、またはDeepgram Nova-3のストリーミング（0.0048ドル/分のキャンペーン価格）を使います。

話者を分けて文字起こしできるAPIとローカルでの方法はありますか？

できます。AssemblyAIは speaker_labels、Deepgramは diarize_model=latest で話者分離が付きます。OpenAIのgpt-4o-transcribe-diarizeは2027年2月26日に停止し、後継のgpt-transcribeには話者ラベルがないため、新規採用は避けてください。ローカルではWhisperXなどで、Whisperの認識結果に話者分離と時刻合わせを組み合わせる方法があります。

関連記事

• GPT-Live-Transcribeとは？OpenAIの低遅延ストリーミング文字起こしの実装手順とGPT-Transcribeとの使い分けを解説【2026年7月版】
• Deepgramとは？料金・日本語対応・APIの使い方【2026年10月版】
• AssemblyAIとは？日本語対応・料金・APIの使い方【2026年10月版】
• AmiVoice APIとは？料金・精度・感情分析・対応言語を解説【2026年最新】
• WhisperをPyTorchで動かす手順｜openai-whisper・faster-whisper・Transformersと日本語・GPU設定