OpenAI Whisper解説2026｜API提供終了予定とローカル利用・議事録移行の確認点

Whisperで議事録や字幕を作る際は、公開モデルを自分の環境で動かす方法と、OpenAI APIの whisper-1 を利用する方法を分けて検討します。特にAPIには提供終了の案内が出ているため、これから導入する場合と、既存の仕組みを移行する場合で確認事項が変わります。本記事は2026年10月24日に確認した公式資料を基に、選定と検証の進め方を整理します。

Whisperとは：公開モデルとAPI、提供終了予定を区別する

OpenAIのモデル紹介では、Whisperは多様な音声データで学習された音声認識モデルとして説明され、多言語の音声認識、翻訳、言語の識別を扱います。音声を文字列へ変換する処理と、その文字列から決定事項や担当者を整理する処理は別です。文字起こしができた時点で、社内の正式な議事録が完成したと扱わず、何を成果物にするかを先に決めます。

また、APIの whisper-1 と、端末や自社サーバーに配置する公開モデルを同一の設定名として扱わないことが大切です。翻訳APIのリファレンスは、whisper-1 が公開されたWhisper V2モデルを基にすることを説明しています。手元で選んだ別の公開モデル名を、そのままAPIへ渡せるという意味ではありません。どのモデル、実行環境、処理方式で得た結果なのかを、評価記録にも残します。

APIは2027年2月26日の提供終了を前提に計画する

2026年8月26日付の公式案内では、APIの whisper-1 は非推奨となり、2027年2月26日に提供終了予定です。音声翻訳の /v1/audio/translations にも同日の終了予定が示されています。ここで確認できるのはAPIの提供に関する案内です。公開モデルのローカル利用を含むすべてのWhisperが同日に使えなくなる、と読み替えないようにします。

終了日だけを台帳へ書いて移行を終えず、現在の用途を「録音済みファイルの文字起こし」「会話中の表示」「字幕の生成」「英語への翻訳」などに分解します。公式の移行先案内には gpt-transcribe や gpt-live-transcribe が示されていますが、用途に応じた確認が必要です。API名が似ているから同じ出力を返す、モデル名の変更だけで既存の画面が動く、と判断しないことが重要です。

特に字幕ファイルや単語ごとの時刻、話者ラベルを使う仕組みでは、文字列が返ることに加えて、後続の処理が要求する形式を検証します。公式の文字起こし概要も、従来の字幕・時刻情報・話者分離などの機能と移行時の違いを案内しています。まず必要な出力項目を一覧にし、代替できない機能があれば、業務手順や別工程も含めて対応を決めます。

本記事では対応言語を一つの固定数で示さず、利用するモデルと必要な言語の組み合わせで確認する方針を取ります。多言語対応という説明だけで、日本語の社名、数字、日英混在の発言まで同じ品質になるとは限りません。モデルを選ぶ前に、誰がどの場面で使い、どの誤りが業務へ影響するかを定めると、比較の軸をそろえられます。

APIとローカル実行は、出力・データ管理・総費用で選ぶ

APIかローカル実行かを、月間の音声時間だけで決めるのは適切ではありません。最初に、必要な出力形式、許容する処理時間、外部送信の条件、運用を担当する人を確認します。APIを使う場合も、アップロード、失敗時の再実行、権限、保存や削除、利用量の管理は自社の仕組みとして検討が必要です。ローカルで動けば運用費がなくなる、という整理にもなりません。

費用の比較範囲をそろえる

確認時点の公式料金表では、Whisperの文字起こしは1分あたり0.006米ドルです。たとえば600分をこの単価で単純計算すると3.60米ドルになります。これは音声処理の単価による計算例で、再実行、要約処理、ファイル保管、通信、税や為替等は含めていません。提供終了後の運用費を、この単価で継続して見積もらないようにします。

ローカル実行では、機器の調達や利用料に加えて、設定、更新、障害対応、処理の待ち時間、担当者の確認工数も比較対象にします。手元の端末で一件動いたという結果と、複数人が同時に使う業務環境で安定して処理できることは別です。対象音声を同じ条件で処理し、音声時間、処理完了までの時間、手直し時間、再実行の回数を記録すると、費用と品質を一緒に判断できます。

学習利用、保持、社内の保存を分けて確認する

OpenAI APIのデータ管理資料では、明示的に同意して共有する場合を除き、APIへ送ったデータをモデルの学習に使用しないと説明しています。一方、学習利用の有無と、ログやファイルの保持は別の項目です。同資料のエンドポイント別表では、音声文字起こし・翻訳の保持と、RealtimeやFiles等の保持を分けています。使う経路に照らして確認します。

議事録の仕組みでは、音声APIへ送る部分だけでなく、録音機器、一時保存先、要約へ渡す先、検索用の保管先、バックアップまでを対象にすると、確認漏れを減らせます。外部送信の可否、閲覧者、保存と処理の場所、削除の手順、契約や設定の条件を担当者と照合します。学習に使われないという一項目だけで、社内の利用条件を満たしたと判断しないことが大切です。

ローカル構成も、端末の利用者、共有フォルダー、外部へ送る別の処理、ログ、バックアップ等を含めて確認します。録音や文字起こしの利用目的と参加者への案内も、組織のルールに沿って整理します。機密だから必ずローカル、一般情報だから必ずAPIと決めず、必要な管理条件を実際の構成で満たせるかを比較する進め方を推奨します。

完成済みのツールを比較したい場合は、AI議事録ツールの選び方も参照できます。独自に音声処理を組み込む必要があるか、既存ツールと運用の見直しで目的を満たせるかを、先に切り分けると検討しやすくなります。

日本語の精度と移行互換性は、同じ音声で検証する

文字起こしの評価では、文章が読みやすいかに加えて、業務上の重要な内容が保たれているかを確認します。たとえば、金額や日付、否定表現、製品名、担当者、決定と検討中の区別です。平均的な誤りの少なさだけで合否を決めず、誤った場合の影響が大きい項目をテストへ含めます。修正を加える担当者も含めて、受け入れられる条件を決めておきます。

公式のWhisper移行ガイドでは、比較用の同じ音声を用意し、基準となる結果と移行後の結果を評価する進め方を説明しています。モデルと入力の条件を一度に変えすぎると、差が出た理由を判断しにくくなります。まずモデルの変更による差を見て、その後に文脈情報や入力の調整を試すと、改善と悪化の原因を追いやすくなります。

容量、分割、用語の指定を別々に確かめる

ファイル文字起こしの公式ガイドでは、アップロードの上限を25MBとしています。送信時には、経由するシステムにも別の容量制限がないかを確認します。長い録音を圧縮または分割する場合は、発話の途中を避け、変換前後で重要な言葉が失われていないかを比べます。容量が小さくなったことと、認識の品質が保たれたことは分けて検証します。

専門用語を補助する設定も、対象モデルの仕様に合わせます。同ガイドでは、従来の whisper-1 の prompt は224トークンまでで、一般的な対話モデルと同じような指示理解をするものではないと説明しています。新しいモデルでは入力項目も変わるため、旧設定の機械的な移植は避けます。日本語の言語指定をすれば全音声の精度が保証される、とも扱わず、混在する言語や短い発話を含めて評価します。

話者、時刻、字幕、リアルタイムを同じ機能と考えない

誰が発言したかを示す話者ラベルと、実在する参加者の氏名を確定することは別です。会話に名前が出たことだけで、その人の発言と自動確定しない設計にします。氏名が必要な会議では参加者情報と原音を確認し、確信が持てない発言は未確定のまま訂正できるようにします。一方、決定事項だけを記録する会議もあるため、全用途に氏名付きの逐語記録を求める必要はありません。

既存の字幕形式や時刻情報、話者情報が必要な場合は、移行先で同じ情報が得られるか、後続処理が扱えるかを確認します。また、従来の whisper-1 は、完成したファイルの文字起こし結果を逐次返すストリーミングに対応していません。録音済みファイルから結果を逐次受け取ることと、会話中に届く音声を処理することも異なります。用途別の公式案内を照合して選びます。

テストには、雑音、複数人の重なり、固有名詞、数字、無音、長い録音、途中の切断や再送など、想定する利用条件を含めます。全文の抜けや重複、時間のずれ、空の結果も確認し、成功した音声だけで評価を終えないようにします。比較するアプリの範囲や無料枠の見方は、無料文字起こしツールの比較記事で補足しています。

議事録は原音確認から承認・タスク管理まで設計する

Whisperを議事録へ使う場合、音声から得た文字列を、そのまま正式記録として配布する必要はありません。会議の目的に応じて、議題、確認できた決定事項、未決事項、担当者、期限を整理します。発言されていない担当者や期限を補完して確定扱いにしないよう、情報が足りない箇所を確認待ちとして残します。必要な項目の基本は、議事録の書き方を参照できます。

要約や用語の補正に別のAIを使う場合も、変更内容を原音や元の文字起こしと照合します。読みやすさを整える処理で、条件付きの発言が断定へ変わる、否定が消える、異なる発言が一つの決定へまとまる、といった問題を見つけられるようにします。後処理を必須の正解とせず、必要な成果物に対して効果と修正の負担を測ります。補正前の情報へ戻れることも検証項目にします。

担当者と確認待ちの状態を残す

renueでは、処理が成功したかだけでなく、誰が内容を確認し、次の業務へ渡すかまで決めることを推奨します。文字起こし完了、要確認、確認済み、共有済みといった状態を、担当と対応づける進め方です。失敗時は対象ファイルと原因をたどれ、再実行で二重に議事録やタスクを作らないようにします。自動化に任せる範囲と、人が判断する範囲を運用へ組み込む考え方です。

検証の成果は、処理時間だけで判断せず、確認と修正にかかった時間、重要な内容の誤り、担当者へ引き渡せた件数などで評価します。導入期間を一律に決めず、少数の会議で受け入れ条件を確かめ、関係者が扱えることを確認して対象を広げます。APIの提供終了までに必要な試験、切替、旧処理の停止も担当と予定へ落とし込み、移行後に過去の記録を参照できるかも確認します。

会議運営の改善と、独自システムの実装で相談先を分ける

議事録の要約・決定事項・アクションの整理から、定例会議やタスク管理へつなげたい場合は、renueのPMOエージェントが検討先です。公開サービスでは議事録AI生成、タスク管理、定例会議管理を案内しています。導入の検討時には、必要な確認・承認の手順と既存の運営方法に合うかを整理します。この案内は、Whisperが必須の構成であることや、既存の音声APIをそのまま移行できることを示すものではありません。

独自の録音経路や社内システム、権限、訂正画面との連携が必要な場合は、FDEの実装・運用支援へつながります。現状の入力、必要な出力、確認する人、利用条件、既存システムの制約を整理し、要件定義から設計・実装・運用までの対象を検討します。どちらの相談でも、利用するモデル名を先に固定するより、会議後の業務をどこまで改善するかを共有すると、試す範囲を具体化できます。

Whisperの導入や移行を進める際は、モデルの認識結果と、組織で使える記録になるまでの工程を一緒に評価します。APIの終了予定、必要な出力の互換性、データの流れ、原音確認、担当者への引き渡しをそろえることが、継続して利用するための土台になります。まず代表的な会議を選び、判断に必要な項目を記録しながら比較を進めます。