
音声をリアルタイムでテキスト化できる文字起こしアプリは、会議の議事録作成、オンライン授業の字幕生成、インタビュー記録、動画制作、カスタマーサポートなど、さまざまな場面で活用できます。これまでは録音した音声ファイルを後からアップロードして文字起こしする方法が一般的でしたが、近年は「話している最中に文字が表示される」リアルタイム文字起こしの需要が高まっています。
OpenAIが提供するRealtime APIでは、音声をストリーミングで送信しながら文字起こしを行うことができます。さらに、2026年5月に発表されたGPT‑Realtime‑Whisperは、話者が話している最中に音声をテキスト化するストリーミング音声認識モデルとして紹介されています。OpenAIの発表では、会議字幕、授業、放送、イベント、業務ワークフローなどでの活用が想定されています。
本記事では、GPT‑Realtime‑Whisperを使ってリアルタイム文字起こしアプリを作る場合の基本構成、実装の流れ、必要なAPI設定、サンプルコードの考え方、運用時の注意点をわかりやすく解説します。
GPT‑Realtime‑Whisperとは

GPT‑Realtime‑Whisperは、OpenAIがRealtime API向けに発表したストリーミング音声認識モデルです。従来のように音声ファイルをすべて録音してから処理するのではなく、話している途中の音声を順次テキスト化できる点が特徴です。
たとえば、会議中に発言内容をほぼリアルタイムで画面に表示したり、発話ごとのテキストを保存して後から議事録に整形したりできます。イメージとしては、録音機というより「会話に追従する字幕エンジン」に近い仕組みです。
OpenAIのRealtime transcriptionドキュメントでは、Realtime APIを使うことで、マイク入力や音声ファイルからリアルタイムに字幕やトランスクリプトを生成できると説明されています。文字起こし専用モードでは、モデルは応答文を生成せず、入力音声の文字起こしに集中します。
通常の音声文字起こしAPIとの違い
文字起こしには、大きく分けて「バッチ処理」と「リアルタイム処理」があります。
バッチ処理は、録音済みの音声ファイルをアップロードして、処理完了後に全文テキストを受け取る方式です。一方、リアルタイム処理は、音声を小さな単位で送りながら、途中経過のテキストを順次受け取る方式です。
| 比較項目 | 通常の文字起こし | Realtime APIによる文字起こし |
|---|---|---|
| 入力方法 | 録音済み音声ファイル | マイク音声・ストリーミング音声 |
| 結果の返り方 | 処理後にまとめて返る | 発話中に順次返る |
| 向いている用途 | 録音データの後処理 | 字幕、会議ログ、ライブ配信 |
| 体感速度 | 音声時間+処理時間が必要 | 発話に追従して表示可能 |
| 実装難易度 | 比較的簡単 | WebSocket / WebRTCの理解が必要 |
つまり、会議後に録音ファイルを文字起こしするだけなら通常のSpeech to Text APIでも十分です。しかし、会議中に字幕を表示したい、発言内容をリアルタイムに保存したい、音声入力を使った業務アプリを作りたい場合は、Realtime APIの方が適しています。
作るアプリの完成イメージ
今回想定するアプリは、ブラウザ上でマイク音声を取得し、その音声をRealtime APIへ送信して、文字起こし結果を画面に表示するシンプルなWebアプリです。
ユーザーがブラウザで録音開始
↓
マイク音声を取得
↓
音声データをRealtime APIへ送信
↓
GPT‑Realtime‑Whisperが文字起こし
↓
途中経過を画面に表示
↓
確定した発話をログとして保存
最初は「リアルタイム字幕表示アプリ」として作り、後から以下のような機能を追加できます。
| 追加機能 | 内容 |
|---|---|
| トランスクリプト保存 | 文字起こし結果をtxtやMarkdownで保存 |
| 議事録生成 | GPTモデルで要約・決定事項・ToDoに整理 |
| 用語補正 | 社内用語、製品名、人名、CVE番号などをプロンプトで補助 |
| タイムスタンプ | 発話開始時刻や終了時刻を記録 |
| 話者分離 | 複数人の会議で話者を区別する機能を追加 |
| 編集画面 | 文字起こし結果を手動修正できるUIを追加 |
文字起こしアプリは、単に音声をテキストに変えるだけではなく、その後の「整理」「検索」「共有」「要約」まで含めると、実用性が大きく高まります。
基本アーキテクチャ
リアルタイム文字起こしアプリの構成は、以下のようになります。
[ブラウザ]
├─ マイク入力を取得
├─ 一時的な認証キーを取得
├─ WebRTCまたはWebSocketで接続
└─ 文字起こし結果を表示
[バックエンド]
├─ OpenAI APIキーを安全に保持
├─ Realtime transcription sessionを作成
└─ ブラウザ用の一時的なclient_secretを発行
[OpenAI Realtime API]
├─ 音声ストリームを受信
├─ GPT‑Realtime‑Whisperで文字起こし
└─ delta / completedイベントを返却
重要なのは、OpenAI APIキーをブラウザに直接埋め込まないことです。ブラウザはユーザー側で動作するため、APIキーを書いてしまうと誰でも確認できてしまいます。
OpenAIのAPIリファレンスでは、クライアント側アプリケーションでRealtime APIを利用する場合、サーバー側で一時的なAPIトークン、つまりclient secretを発行して使用する構成が説明されています。この一時キーはブラウザからRealtime APIへ接続するために使われます。
Realtime APIの文字起こしセッション
Realtime APIで文字起こしを行う場合は、通常の会話セッションではなく、transcription sessionを作成します。
公式ドキュメントでは、Realtime APIの文字起こしではWebSocketまたはWebRTCでtranscription sessionへ接続すると説明されています。transcription sessionは、会話応答を生成するためのものではなく、基本的には入力音声の文字起こし結果を返すためのセッションです。
セッション設定のイメージは以下のようになります。
{
"type": "transcription",
"audio": {
"input": {
"format": {
"type": "audio/pcm",
"rate": 24000
},
"noise_reduction": {
"type": "near_field"
},
"transcription": {
"model": "gpt-realtime-whisper",
"language": "ja",
"prompt": "日本語の会議音声です。サイバーセキュリティ、CVE、EDR、AWS、バックアップなどの専門用語が含まれます。"
},
"turn_detection": {
"type": "server_vad",
"threshold": 0.5,
"prefix_padding_ms": 300,
"silence_duration_ms": 500
}
}
}
}
なお、OpenAIのRealtime transcriptionドキュメントでは、入力音声形式として24kHzのmono PCM、G.711 μ-law、G.711 A-lawなどが説明されています。また、ノイズ低減、言語指定、プロンプト指定、VADによる発話区切りの設定も用意されています。
deltaイベントとcompletedイベント
Realtime APIの文字起こしでは、主に2種類のイベントを受け取ります。
deltaイベント
deltaイベントは、文字起こしの途中経過です。話者が発言している最中に、少しずつテキストが返ってきます。
{
"type": "conversation.item.input_audio_transcription.delta",
"item_id": "item_001",
"delta": "本日は、"
}
画面上でリアルタイム字幕のように表示したい場合は、このdeltaイベントを使います。ただし、途中経過なので、後から修正される可能性があります。
completedイベント
completedイベントは、発話単位で確定した文字起こし結果です。
{
"type": "conversation.item.input_audio_transcription.completed",
"item_id": "item_001",
"transcript": "本日は、バックアップ運用の見直しについて説明します。"
}
保存用の正式なトランスクリプトには、completedイベントを使うのが基本です。
OpenAIのドキュメントでは、conversation.item.input_audio_transcription.delta が逐次的な文字起こし結果、conversation.item.input_audio_transcription.completed が発話単位の完了結果として説明されています。また、複数の発話完了イベントは順序が前後する場合があるため、item_id などを使って管理することが推奨されています。
実装ステップ
ここからは、アプリ開発の流れを整理します。
ステップ1:バックエンドで一時キーを発行する
まず、Node.jsなどで簡単なバックエンドを用意します。バックエンドの役割は、OpenAI APIキーを安全に保持し、ブラウザへ一時的なclient secretを渡すことです。
ブラウザ → 自分のサーバー → OpenAI API
ブラウザから直接OpenAI APIキーを使わず、必ず自分のサーバーを経由します。
Node.js / Expressで書く場合のイメージは以下です。
import express from "express";
const app = express();
app.use(express.json());
app.get("/session", async (req, res) => {
const response = await fetch("https://api.openai.com/v1/realtime/transcription_sessions", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.OPENAI_API_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
input_audio_format: "pcm16",
input_audio_transcription: {
model: "gpt-realtime-whisper",
language: "ja",
prompt: "日本語の会議音声です。専門用語をできるだけ正確に文字起こししてください。"
},
input_audio_noise_reduction: {
type: "near_field"
},
turn_detection: {
type: "server_vad",
threshold: 0.5,
prefix_padding_ms: 300,
silence_duration_ms: 500
}
})
});
const data = await response.json();
res.json(data);
});
app.listen(3000, () => {
console.log("Server running on http://localhost:3000");
});
このコードは考え方を示すサンプルです。実際に使う場合は、最新のAPIリファレンスに合わせてパラメータ名を確認してください。
ステップ2:ブラウザでマイク入力を取得する
次に、ブラウザ側でマイク音声を取得します。
const stream = await navigator.mediaDevices.getUserMedia({
audio: true
});
この処理を実行すると、ブラウザがマイク利用許可を求めます。ユーザーが許可すると、音声ストリームを取得できます。
ステップ3:Realtime APIへ接続する
ブラウザからRealtime APIへ接続する方法には、WebRTCとWebSocketがあります。
| 接続方式 | 特徴 |
|---|---|
| WebRTC | マイク音声を扱いやすく、低遅延な音声アプリ向き |
| WebSocket | サーバー側処理や音声ファイルのストリーミングに向いている |
ブラウザでマイク入力を使うアプリなら、WebRTCが自然です。一方、録音済みファイルを読み込んで送るCLIツールやサーバー処理なら、WebSocketの方が実装しやすい場合があります。
最初の学習用・検証用であれば、WebSocketを使ってwavファイルを送るPoCから始めると理解しやすいです。Webアプリとして完成させる段階でWebRTCへ広げると、段階的に開発できます。
ステップ4:文字起こし結果を画面に表示する
Realtime APIから返ってきたイベントを受け取り、イベント種別によって処理を分けます。
function handleRealtimeEvent(event) {
if (event.type === "conversation.item.input_audio_transcription.delta") {
showPartialText(event.delta);
}
if (event.type === "conversation.item.input_audio_transcription.completed") {
appendFinalTranscript(event.transcript);
}
}
画面上では、途中経過と確定結果を分けて表示すると使いやすくなります。
現在の発話:
本日は、バックアップ運用の...
確定済みログ:
1. 本日は、バックアップ運用の見直しについて説明します。
2. 次に、復旧手順の確認ポイントを整理します。
deltaは字幕表示、completedは保存対象と考えると整理しやすいです。
ステップ5:文字起こし結果を保存する
確定した文字起こし結果は、配列に保持しておき、最後にテキストファイルやMarkdownとして保存できます。
const transcripts = [];
function appendFinalTranscript(text) {
transcripts.push({
time: new Date().toISOString(),
text
});
}
保存形式は、最初はシンプルなMarkdownで十分です。
# 会議文字起こし
## 2026-05-12 10:00
- 本日は、バックアップ運用の見直しについて説明します。
- 次に、復旧手順の確認ポイントを整理します。
後から議事録化する場合も、Markdown形式にしておくと扱いやすくなります。
文字起こし後に議事録化する
文字起こしアプリを実用的にするなら、文字起こし結果をそのまま保存するだけでなく、後処理として要約や議事録化を行うと便利です。
たとえば、以下のような形式に変換できます。
# 議事録
## 概要
本会議では、バックアップ運用の見直しとランサムウェア対策強化について議論した。
## 決定事項
- 重要システムのバックアップ分離状況を再確認する
- 復旧手順書の更新状況を棚卸しする
- 次回会議までに対象システム一覧を整理する
## アクションリスト
| 担当 | 内容 | 期限 |
|---|---|---|
| 情シス担当 | バックアップ方式の確認 | 5月末 |
| セキュリティ担当 | 復旧手順の確認観点を整理 | 5月末 |
この処理は、GPT‑Realtime‑Whisperではなく、別のテキスト生成モデルに文字起こし結果を渡して行います。つまり、アプリ全体としては以下のような流れになります。
音声
↓
GPT‑Realtime‑Whisperで文字起こし
↓
テキスト保存
↓
GPTモデルで要約・議事録化
↓
Markdown / Word / Google Docsへ出力
文字起こしと議事録化を分けて考えると、アプリの設計がシンプルになります。
専門用語を正確に文字起こしするコツ
会議では、一般的な単語だけでなく、社内用語、製品名、人名、略語、技術用語が多く登場します。これらは音声認識で誤変換されやすい部分です。
たとえば、セキュリティ系の会議では以下のような用語が出てきます。
CVE
EDR
SIEM
ゼロトラスト
ランサムウェア
イミュータブルバックアップ
AWS Backup
Object Lock
Vault Lock
こうした用語は、transcription設定のpromptに含めておくと、モデルが文脈を把握しやすくなります。OpenAIのドキュメントでも、文字起こし設定には言語やプロンプトを指定できると説明されています。
プロンプト例は以下です。
これは日本語のIT会議の文字起こしです。
以下の専門用語が出る可能性があります。
CVE、EDR、SIEM、AWS Backup、Object Lock、Vault Lock、ゼロトラスト、ランサムウェア、イミュータブルバックアップ。
専門用語は可能な限り英字表記を維持してください。
用語リストは、アプリの設定画面から登録できるようにしておくと便利です。
VAD設定の考え方
Realtime APIでは、VAD、つまりVoice Activity Detectionによって、発話の区切りを自動判定できます。簡単に言えば、「どこからどこまでを1つの発話として扱うか」を決める仕組みです。
VAD設定が短すぎると、少し間を置いただけで発話が細切れになります。逆に長すぎると、発話の確定が遅くなり、字幕やログの反映がもたつく場合があります。
| 設定項目 | 役割 |
|---|---|
| threshold | 音声と無音を判定するしきい値 |
| prefix_padding_ms | 発話開始前の音声を少し含める設定 |
| silence_duration_ms | どれくらい無音が続いたら発話終了とみなすか |
会議用途では、最初は以下のような設定から試すと扱いやすいです。
{
"type": "server_vad",
"threshold": 0.5,
"prefix_padding_ms": 300,
"silence_duration_ms": 500
}
発話が細切れになりすぎる場合は、silence_duration_ms を少し長くします。反応が遅い場合は、短くします。実際の会議環境やマイク品質によって最適値は変わるため、テストしながら調整するのが現実的です。
料金の目安
OpenAIの価格ページでは、GPT‑Realtime‑Whisperは1分あたり0.017ドルとされています。秒単位では0.00028ドルです。
単純計算すると、以下のようになります。
| 利用時間 | 概算料金 |
|---|---|
| 10分 | 0.17ドル |
| 30分 | 0.51ドル |
| 60分 | 1.02ドル |
| 100時間 | 102ドル |
日本円換算は為替によって変わりますが、1ドル150円で考えると、1時間あたり約153円です。
ただし、実際の料金はAPIの最新価格、利用モデル、音声処理方式、追加で使う要約モデルなどによって変わります。議事録生成まで含める場合は、文字起こし料金に加えて、要約用モデルのトークン料金も考慮する必要があります。
セキュリティとプライバシーの注意点
文字起こしアプリを社内利用する場合、技術的な実装だけでなく、データの取り扱いにも注意が必要です。
会議音声には、個人情報、社内機密、顧客情報、未公開情報などが含まれる可能性があります。そのため、以下の点を事前に整理しておくと安心です。
| 確認項目 | 内容 |
|---|---|
| 録音・文字起こしの同意 | 会議参加者に録音・文字起こしを明示する |
| 保存期間 | 音声データや文字起こし結果をいつまで保存するか |
| 保存場所 | ローカル、クラウド、社内ストレージのどこに保存するか |
| アクセス権限 | 誰がトランスクリプトを閲覧できるか |
| API利用ルール | 社内情報を外部APIに送信できるか確認する |
| 削除機能 | 不要になったデータを削除できるようにする |
OpenAIの発表では、Realtime APIに安全対策が組み込まれていること、また開発者はエンドユーザーがAIとやり取りしていることを明確にする必要があると説明されています。
特に企業利用では、便利さだけで導入を進めず、情報管理ルールや利用規程と合わせて設計することが重要です。
アプリの画面設計例
最初のバージョンでは、画面はシンプルで構いません。
┌──────────────────────────────┐
│ リアルタイム文字起こしアプリ │
├──────────────────────────────┤
│ [録音開始] [停止] [保存] │
├──────────────────────────────┤
│ 現在の発話 │
│ 本日は、バックアップ運用の... │
├──────────────────────────────┤
│ 確定済みトランスクリプト │
│ 10:00 本日は、バックアップ... │
│ 10:02 次に、復旧手順について... │
├──────────────────────────────┤
│ [議事録を生成] [Markdown出力] │
└──────────────────────────────┘
最初から高機能にしすぎると開発が複雑になります。まずは、録音開始、停止、文字起こし表示、テキスト保存の4機能に絞ると作りやすいです。
最小構成の開発ロードマップ
個人開発や学習目的で作るなら、以下の順番がおすすめです。
フェーズ1:録音済み音声で検証
最初はブラウザではなく、wavファイルを使って文字起こしを試します。
sample.wav
↓
WebSocketでRealtime APIへ送信
↓
文字起こし結果をコンソール表示
ここでAPI接続、イベント受信、文字起こし結果の保存方法を確認します。
フェーズ2:ブラウザでマイク入力に対応
次に、ブラウザでマイクを取得し、リアルタイムに文字起こしします。
ブラウザのマイク
↓
Realtime API
↓
画面に字幕表示
この段階で、録音開始・停止ボタン、現在の発話表示、確定ログ表示を作ります。
フェーズ3:保存機能を追加
文字起こし結果をMarkdownやtxtでダウンロードできるようにします。
completedイベント
↓
配列に保存
↓
Markdown形式に変換
↓
ダウンロード
フェーズ4:議事録化機能を追加
最後に、文字起こし結果を要約モデルに渡し、議事録として整形します。
トランスクリプト
↓
要約モデル
↓
概要・決定事項・ToDoに整理
この順番で進めると、途中でつまずいても原因を切り分けやすくなります。
実装時につまずきやすいポイント
Realtime APIを使った文字起こしアプリでは、以下の点でつまずきやすいです。
| つまずきポイント | 対策 |
|---|---|
| APIキーをブラウザに書いてしまう | サーバー側で一時キーを発行する |
| 音声形式が合わない | 24kHz mono PCMなど、指定形式に変換する |
| 文字起こしが細切れになる | VADの無音時間を調整する |
| 専門用語が誤変換される | promptに用語リストを入れる |
| 結果の順番がずれる | item_idで発話単位を管理する |
| 保存内容が途中経過だらけになる | 保存はcompletedイベントを使う |
| 料金が読みにくい | 利用時間と要約処理を分けて試算する |
特に重要なのは、deltaは表示用、completedは保存用と役割を分けることです。これを混同すると、途中経過の文字が重複して保存されたり、修正前の不完全な文章が残ったりします。
どんな用途に向いているか
GPT‑Realtime‑Whisperを使った文字起こしアプリは、以下のような用途に向いています。
| 用途 | 活用イメージ |
|---|---|
| 会議 | 会議中に文字起こしし、終了後に議事録化 |
| セミナー | 登壇内容をリアルタイム字幕として表示 |
| 授業 | 講義内容をテキスト化して復習資料にする |
| インタビュー | 会話内容を保存し、記事作成の素材にする |
| カスタマーサポート | 通話内容を記録し、対応履歴として整理 |
| 動画制作 | 字幕原稿を自動生成する |
| 社内研修 | 研修動画の文字起こしと要約を作る |
特に、会議や研修のように「聞きながら記録したい」場面では、リアルタイム文字起こしの価値が大きくなります。
まとめ
GPT‑Realtime‑Whisperを使えば、話している最中の音声をリアルタイムにテキスト化する文字起こしアプリを作ることができます。従来のように録音ファイルを後から処理するだけでなく、会議中の字幕表示、発話ログの保存、議事録生成など、リアルタイム性を活かしたアプリ開発が可能です。
実装の基本は、バックエンドで一時的なclient secretを発行し、ブラウザ側でマイク音声を取得して、Realtime APIのtranscription sessionへ送信する流れです。返ってくるdeltaイベントは途中表示に使い、completedイベントは保存用の正式なトランスクリプトとして扱うと整理しやすくなります。
最初は、録音済みwavファイルを使ったPoCから始めるのがおすすめです。その後、ブラウザでのマイク入力、トランスクリプト保存、議事録生成、用語補正、話者分離などを段階的に追加していくと、実用的な文字起こしアプリに発展させられます。
音声をテキスト化する技術は、単なる記録ツールではなく、会議・教育・サポート・コンテンツ制作の効率を高める基盤になりつつあります。GPT‑Realtime‑Whisperは、そのようなリアルタイム音声活用を始めるための有力な選択肢の一つといえるでしょう。
参考URL
- OpenAI「Advancing voice intelligence with new models in the API」
https://openai.com/index/advancing-voice-intelligence-with-new-models-in-the-api/ - OpenAI Realtime transcription guide
https://platform.openai.com/docs/guides/realtime-transcription - OpenAI Realtime API reference
https://platform.openai.com/docs/api-reference/realtime - OpenAI API pricing
https://openai.com/api/pricing/



コメント