音声認識を実装する開発者にとって、過去には常に断絶感がありました。チャットはOpenRouterを使用し、音声認識には別のWhisperサーバーを構築するか、または専門の音声からテキストへのSDKを追加しなければなりませんでした。7月22日、OpenRouterはこの断絶を解消しました——自社プラットフォームにPOST /api/v1/audio/transcriptionsエンドポイントをリリースし、チャット補完と同様のBearerキーを使って、base64エンコードされた音声を送信すると、転写されたテキストと使用量情報を含むJSONを取得できます。これにより、チャットと音声認識が同じ入口から利用できるようになりました。

この利便性の核心は再利用です。新しいSDKや別サービスを必要とせず、音声認識機能とチャットトラフィックは同じプラットフォーム上で動作し、複数のプロバイダーがモデルをホストし、お互いにロードバランシングを行います。これは、特定のサプライヤーに固定されるのではなく、柔軟な選択を可能にします。すでにOpenRouterを主要なツールとして使っているチームにとっては、この統合は一つの連携ルートとキーの維持を減らすことになります。

image.png

モデルの面では、OpenRouterは二つのアプローチを提示しています。一つはopenai/whisper-1のようなWhisper系モデルで、これは音声の長さに基づいて料金が発生します（秒単位）。もう一つは最新の音声からテキストへの変換（STT）モデルで、トークン単位で料金が発生します。注意すべき点は、STTモデルのIDはデフォルトの/api/v1/modelsディレクトリには表示されず、明示的に選択する必要があります。?output_modalities=transcriptionパラメータを使って、これらのモデルと現在の価格をフィルタリングできます。テストしたい場合は、OpenRouter Playgroundでブラウザ内でファイルをアップロードして直接転記できます。

呼び出し方法は非常にシンプルで、一度のリクエストで完結します。ファイルをbase64エンコードし、モデルと形式とともにPOSTして、レスポンスからtextとusageという2つのフィールドを読み取るだけです。dataフィールドには元のbase64バイトデータが入力され、data: URIではありませんので、data:audio/mp3;base64などの接頭辞を追加しないでください。formatフィールドは必須であり、上流のモデルにどのようにバイトをデコードするかを伝えます。もしあなたがOpenAI向けの/v1/audio/transcriptions用のクライアントを持っていれば、ベースURLをhttps://openrouter.ai/api/v1に変更するだけで、変更なしで使用可能です。エンドポイントはOpenAIスタイルのmultipart/form-dataアップロードも受け付けており、ファイルとモデルを指定し、最大25MBまで可能です。

フィールドの規格において、model、input_audio.data、input_audio.formatは必須項目です。形式はwav、mp3、flac、m4a、ogg、webm、aacの中から選ぶことができます。languageはISO-639-1言語コードで、省略するとモデルが自動的に検出します。temperatureはサンプリングを制御し、0〜1の値を取ります。response_formatはデフォルトでjsonで、verbose_jsonに設定するとタスク、言語、長さ、セグメントのタイムスタンプなども取得できます。timestamp_granularitiesをwordに選ぶことで、単語レベルのタイムスタンプも取得できますが、この2つはOpenAIとその他の互換性のあるプロバイダーであるOpenAI、Groq、Togetherでのみ有効です。他のプロバイダーは400エラーを返します。providerブロックは各プロバイダーの固有パラメータを透過的に伝えるために使われます。例えば、Groqはprovider.options.groq.promptを通じて予期される単語を渡すことで、モデルが専門用語を正しく処理できるようにします。

応答はJSON形式で、text文字列には転写結果が含まれ、usageオブジェクトは費用をリクエストごとに計測することができ、見積もりに頼ることはありません。例として、9.2秒の音声は113トークン、83入力と30出力を生成し、コストは0.000508ドルでした——この数字はドキュメントの例であり、実際の価格とは異なります。実際の料金は選択したモデルと音声の長さによって異なります。応答ヘッダーにはX-Generation-Idも含まれており、特定のリクエストを記録・デバッグするために役立ちます。

ルーティングロジックはチャットと同じです。複数のプロバイダーが音声認識モデルをホストしている場合、OpenRouterは価格に基づいてロードバランシングを行い、リクエストを各プロバイダー間で分配します。これにより、特定のサプライヤーに縛られることを避けることができます。ただし、現在の音声認識エンドポイントではリクエストごとのルーティングコントロールはまだ提供されていません。チャット呼び出しでよく使われるorder、only、allow_fallbacks、data_collection、sortなどのフィールドはここでは機能しません。providerブロックはプロバイダー固有のオプションのみを受け入れます。OpenRouterはプロバイダーの価格を追加することなく、ディレクトリ上の価格が実際の支払額となります。ゼロ補完保証により、失敗した音声認識は料金が発生しません。また、自分のプロバイダー契約を持っている場合は、BYOK機能を利用して自身のキーでルーティングし、プラットフォーム料金のみを支払い、用量モデルのコストを回避できます。用量課金モードでは、月に100万回までのリクエストのプラットフォーム料金が免除されます。

実際に構築する前に、4つの制限条件をアーキテクチャに組み込む必要があります。第一に、60秒の上流タイムアウトがあります。これは処理時間ではなく、音声の長さではなく、大きなサイズや圧縮されていない録音はタイムアウトになりやすいため、長い音声は分割して転写し、テキストを結合する必要があります。第二に、音声URLはサポートされていません。エンドポイントはbase64 JSONまたは25MB以下のOpenAIスタイルのマルチパートファイルのみを受け入れます。第三に、SRT/VTT形式の出力はサポートされていません。srt、vtt、textは拒否され、400エラーが返されます。タイムスタンプはverbose_jsonを通じて取得し、字幕ファイルは自分でタイムスタンプを組み合わせて作成する必要があります。第四に、形式のサポートはプロバイダーによって異なります。wavは最も広く互換性がある安全なデフォルトですが、mp3などの圧縮形式はより小さな負荷と高速な処理を可能にします。数時間にわたるゲーム会話のような録音は、一度の呼び出しではカバーできません。塊ごとに処理する必要があります。

最後に、音声認識の位置を正しく配置する必要があります。あなたが音声をテキストに変換したいだけであれば、/audio/transcriptionsを使用してください。一方、モデルが音声の内容に対して推論を行う必要がある場合、例えばカスタマーケア通話の感情分析、音声に関する質問応答、または音声を他のモダリティと組み合わせてワンピリミットに含める場合は、/chat/completionsのinput_audioコンテンツタイプを使用する必要があります。テキストから音声への変換は、第三个の独立したエンドポイントです。OpenRouterは非常に明確な対比を示しています：転写稿が必要であれば、転写エンドポイントでJSONテキストと使用量を取得してください。音声を理解できるモデルが必要であれば、チャット補完で1回の会話を取得してください。一つのキーでチャットと音声を同時にカバーすることで、アプリケーション内の音声機能の導入のハードルはさらに低下しました。