会議録音から根拠付きのアクション案を作る：Scribeで文字起こしを確認する

会議の記録を実務に活用するには、録音、発言内容を残した文字起こし、そして該当する発言と時刻に結び付いたアクション案の3つを分けて扱う必要があります。流暢な要約は、文字起こしの代わりにはなりません。生成されたJSONファイルに項目があっても、それがプロジェクト管理システムで承認済みのタスクになるわけではありません。

このチュートリアルでは、Ofoxを使って43.92秒の合成音声をelevenlabs/scribe_v2で文字起こしし、時刻付きの応答をopenai/gpt-6-lunaに渡します。録音には、担当者が割り当てられたタスク、担当者のいないタスク、未決定のリリース日、未承認の予算が意図的に含まれています。テキストモデルは、提案項目と未解決の質問を返しましたが、メッセージの送信や外部タスクの作成は行っていません。ソースファイルと生の応答はダウンロードできます。

会議はこのチュートリアル用に作成した架空の内容で、音声は合成です。登場する名前は台本の一部であり、実在の参加者や、検証済みの話者の識別情報を示すものではありません。この例で示すのは監査可能な処理の流れであり、雑音のある実際の会議での性能や、自動話者分離の信頼性を実証するものではありません。

確認できる成果物を決める

音声をアップロードする前に、確認者に何を渡すかを決めましょう。このワークフローで最低限そろえるのは、元の録音、ASRの生の応答、修正済みの文字起こし（ある場合）、引用と時間範囲を付けたアクション案、未解決の質問、そして確認結果です。後から修正してもモデルが実際に返した内容が消えないよう、成果物は分けて保管します。

アクション記録に必要なのは、見栄えのよい文章だけではありません。タスク、担当者、期限、承認状況を区別できるようにします。録音に根拠がないフィールドには、nullまたは「確認が必要」と分かる状態を設定してください。推測で表のすべての欄を埋めても、記録が完成するどころか、かえって役に立たなくなります。

作業キットには、meeting-script.txt、会議音声、meeting-transcript.json、extract_actions.py、抽出リクエスト、生の応答が含まれています。これらのファイルを使えば、ほかの人の非公開会議をアップロードせずに処理の流れを検証できます。

架空の会議の合成音声

1. 許可された入力を用意し、時間軸を保つ

選択したクラウドサービスで処理する許可を得ている録音を使います。職場の会議を扱う場合は、組織の録音、保存、アクセスに関する規則に従ってください。タスクの理解に役立つかもしれないという理由だけで、パスワード、非公開のアクセストークン、無関係な個人情報を含めないでください。

元のファイルを保管し、必要に応じて対応形式の音声コピーを作成します。ここでテストしたOfoxのルートはWAVまたはMP3を受け付けます。動画から音声トラックを抽出する場合は、選択したトラックと、先頭の時間をトリミングしたかどうかを記録してください。後から付ける引用はすべて、正しい時間軸を参照する必要があります。

この例では、元の台本から43.92秒のMP3を1つ作成しました。意図的に、次のような異なる発言を含めています。

• Leoが2026年10月15日までにAPIの例を確認する。
• 日本語ナレーションの収録担当者は割り当てられていない。
• 話者は本番リリースを承認できない。
• リリース日は未決定のため、まだ招待を送ってはいけない。
• 30ドルのテスト予算について話し合ったが、承認されていない。

こうした違いを含めることが、このテストの狙いです。「送らないで」という否定を落として「招待を送る」と抽出するシステムは、もっともらしく見えても有害な作業リストを作りかねません。予算の話し合いを支出の承認とみなすシステムは、要約の範囲を超えて事実を作り出しています。

2. Scribeで文字起こしし、元の応答を保存する

OFOX_API_KEYを設定し、requests、FFmpeg、ffprobeをインストールしてから、作業キットのディレクトリで付属クライアントを実行します。

python3 audio_api.py transcribe \
  --input meeting.mp3 \
  --output my-meeting-transcript.json

クライアントはelevenlabs/scribe_v2とverbose_jsonを使い、マルチパートフォームデータを/v1/audio/transcriptionsにアップロードします。現在公開されているルートについては、OfoxのScribeモデルページを確認してください。この例では、プロバイダーのネイティブAPIで使えるすべてのパラメーターがゲートウェイでも受け付けられるとは想定していません。

編集する前に応答を保存します。サンプルのJSONには、全文に加えて単語ごとの開始時刻と終了時刻が含まれています。また、話された日付が「October 15th, 2026」と書き起こされています。このように表記を正規化すると便利ですが、それはモデルが現在の日付を認識している証拠でも、相対的な期限を常に安全に解釈できる証拠でもありません。

録音は43.92秒で終わり、応答に含まれる最後の単語の終了時刻は43.74秒です。録音時間と使用量のフィールドは区別して扱ってください。最後の発話の時刻は、ファイルの長さの代わりにはならず、文字起こしリクエストの課金額を確定するものでもありません。

APIが失敗した場合は、エラー本文とリクエストIDを保存し、そのエラーメッセージを文字起こしとして抽出モデルに渡さないでください。時刻情報なしでテキストだけが返された場合でも要約案は作れますが、アラインメント情報が得られるまでは、時刻に結び付いた根拠を検証したとは言えません。

3. 判断に影響する誤りを中心に文字起こしを確認する

まず、名前、日付、数字、否定、許可に関する発言を確認します。この合成例では、比較用の元の台本を参照できます。実際の会議では録音が第一の根拠です。スライド、議題、以前のメモで用語を確認することはできますが、参加者の発言を黙って上書きしてはいけません。

修正内容は編集ログに残します。各行に、元のASRの表現、修正後の表現、時間範囲、理由、確認者を記録できます。音声から判断できない場合は、不確かであることを示してください。近くにいた人が話していた、あるいは普段その業務を担当しているという理由だけで、担当者の名前を作り出してはいけません。

この応答には、検証済みの話者ラベルはありません。意図的に作成した台本では「Leo speaking（Leoが話しています）」という発言がありますが、これは音声ファイルに含まれるテキストであり、特定の従業員が話したという音響上の証拠ではありません。抽出用のプロンプトでは、次のモデルがその慣例から話者の本人確認を推測しないよう明示しています。

複数の人が割り込んだり意見を異にしたりする場合、正確なアクションリストを作るには追加の確認が必要になることがあります。短い一人語りのチュートリアル用録音では、発話の重なり、背景雑音、かぶり、アクセントをテストしていません。チームの録音に自動ワークフローを使う前に、これらは別の評価条件として扱ってください。

4. 根拠に結び付いた提案をテキストモデルに求める

抽出段階では、文字起こしテキストと実際の単語配列の両方を入力します。モデルには、その情報だけを使うこと、不明なフィールドを明示すること、否定を保つこと、確約と提案を区別することを指示します。メッセージを送ったり、プロジェクト管理システムを変更したりしてはいけないことも指定します。

リクエスト全体はactions-request.jsonにあります。中心となる指示は次のとおりです。

Use only the supplied ASR words and text.
Return actions, decisions, and open_questions.
Each action needs task, owner, due_date, status=proposed,
an exact supporting quote, and start/end seconds copied
from the word timestamps. Use null for unknown fields.
Separate commitments, proposals, and negations.
Do not infer acoustic speaker identity from a spoken name.
Do not invent approvals, send messages, or create tasks.

extract_actions.pyを実行すると、付属の抽出例を再現できます。このスクリプトは/v1/chat/completions経由でopenai/gpt-6-lunaを使い、時刻付きの文字起こしを読み込んで生の結果を保存します。付属スクリプトは既存のactions-response.jsonを上書きしません。意図的に有料リクエストをもう一度実行する場合は、別の作業用コピーを使うか、バージョン付きの出力先を指定してください。

この例では、指示でJSON形式を求めたうえで、応答をそのまま保存します。APIレベルで構造化出力スキーマが強制されたとは主張していません。本番システムでは、モデルのメッセージが有効なJSONに見える場合でも、パースしたオブジェクトを独自のスキーマに照らして検証してください。

新しい会議を扱う場合は、入力ファイルを意図的に変更し、プロンプトのバージョンも保存します。チュートリアルの文字起こしを参照したままのスクリプトを安易に使い回さないでください。形式が完璧でも、別の録音から作られた結果は誤った結果です。

5. 実際の出力を、誤りも含めて確認する

サンプルのモデルは、確約、提案、否定を含むネストされたactionsオブジェクトと、decisionsおよびopen_questionsを返しました。すべてのアクションのステータスはproposedです。この生の応答は1回の出力を示すものであり、今後の呼び出しでも安定したAPIスキーマが保たれることを示すものではありません。

生の応答には、「I can review the example（例を確認できます）」という別の提案も含まれています。この提案はAPI確認の割り当てと重複している可能性があります。タスクとして書き出す前に、確認者が同じ作業を指しているか判断してください。引用がそれぞれ実際の発言に基づいていても、自動作成すると割り当てが重複することがあります。

モデルはdecisionsを空のままにし、未承認の予算を未解決の質問として保持しました。承認を作り出すよりは望ましい結果ですが、この慎重さが確認できるのは、あくまで丁寧に設計された今回の例に限られます。実際の会話全般でこの振る舞いを信頼する前に、より幅広いテストが必要です。

確認後の記録では、明示されたAPI確認を残し、デモを担当者未定の提案として維持し、3つの未解決の質問も保持したうえで、招待に関する制限を実行するタスクではなく制約として記録するのが考えられます。この編集上の判断はactions-response.jsonと分けて保存し、元の出力を後から確認できるようにしてください。

6. 引用、時刻、不明なフィールドを検証する

まず、機械的に検証できる項目から始めます。JSONをパースし、必須キーがあることを確認して、不正な時刻は拒否します。引用された時間範囲は録音の長さに収まり、引用した単語の開始と終了に対応している必要があります。数値がファイルの長さの範囲内にあることは必要条件ですが、正しい文を指していることの十分な証拠ではありません。

引用が文字起こしと完全に一致するかを確認します。照合のために空白や句読点を正規化する場合は、そのルールを記録してください。「承認した」と「承認していない」を同じものとして扱いかねない、許容範囲の広いあいまい一致は使わないでください。この例の予算に関する引用には、承認されていないという否定が含まれています。その部分を落とすと意味が変わります。

次に、意味を確認します。引用が正確でも、誤った結論を支えることはあります。「I cannot approve the production release（本番リリースは承認できません）」が示すのは制約であって、デプロイの許可ではありません。「The release date is still undecided（リリース日はまだ未定です）」から、別の文にあるAPI確認の期限を流用して期限を設定することもできません。

不明な値は、インターフェース上でも不明なままにしておきます。担当者が空欄だからといって、アップロードした人、会議の主催者、最初に名前が出た人を黙って設定してはいけません。期限がない場合に、今日の日付を既定値として設定してはいけません。後続ツールがそれらのフィールドを必須とするなら、入力を捏造してフォームを埋めるのではなく、確認待ちのキューに残してください。

7. 抽出とタスク作成を分ける

このチュートリアルで作るのは提案記録までです。チケットの作成、メールの送信、カレンダーの予定登録は行いません。両方のAPI呼び出しがHTTP 200を返しても、文字起こしや解釈が誤っている可能性があるため、この境界は重要です。

プロジェクト管理ツールに接続する前に、誰がアクションを承認できるのか、承認者にどの根拠を見せるのかを決めてください。提案された担当者と期限の横に、引用と音声の時間範囲を表示します。承認、修正、却下を記録し、書き出したタスクを確認済みのバージョンに結び付ける監査証跡を保ちます。

最終的にタスクを作成する場合は、確認済みの会議バージョンとアクション識別子に基づく冪等性キー、または重複排除キーを使います。要約を再実行しても、チケットが重複作成されないようにしてください。修正されたアクションは、変更内容を確認した後でのみ、対象の記録を更新します。以前承認された確約を黙って上書きしてはいけません。

録音後に、会議参加者が意見を変えることもあります。後から人が決めた内容は、会議中に発言されたかのように文字起こしへ遡及して追加するのではなく、独自の情報源とともにタスク履歴に記録してください。

8. 各段階を分けてトラブルシューティングする

文字起こしリクエストが失敗した場合は、対応している入力形式、認証情報、正確なエラー内容を確認します。このプロジェクトで以前にScribeを呼び出した際、上流のクォータに関する問題が発生しましたが、新しいリクエストの成功によって復旧を確認できました。ウォレットの状態だけでは、ルートの問題を診断できませんでした。

文字起こしが不完全なら、入力音声、選択したトラック、アップロードが完了したかを確認します。テキストモデルが不正なJSONを返した場合は、生の応答を保存し、抽出または検証の手順を修正してください。下流のJSON整形だけが失敗したのに、同じ音声を何度もアップロードしてはいけません。

出力に担当者や日付が作り出されている場合は、根拠に関する要件を強化し、実際の例を確認します。プロンプトを長くしても、指示に従う保証にはなりません。担当者未定の作業、仮の日付、否定された許可、矛盾する発言を含むテストケースを用意し、バリデーターと確認者がそれらを検出できるようにしてください。

非常に長い会議では、チャンクごとのオフセットを維持し、セクションをまたいだ重複や、後から変更された決定を整理します。このキットの小さなスクリプトは、短い録音を透明性のある形で処理する例であり、長時間の会議を完全に統括するシステムではありません。テストしていない長時間処理の上限や、会議をまたいだ自動記憶機能をうたわないでください。

9. 要約の長さではなく、成果を評価する

提案項目のうち、そのまま承認されたもの、修正されたもの、却下されたもの、重複として統合されたものの数を記録します。確認にかかった時間や、確認者が見つけた取りこぼしの数も記録してください。こうした指標は、生成された箇条書きの数より有益です。

コストを確認するときは、文字起こしとテキストモデルの使用量を分けて扱います。秒数で計測するASR使用量とテキストトークン量は異なる単位です。成果物のメタデータは自分の請求記録とリクエストを照合するのに役立ちますが、このチュートリアルでは、照合されていない推定値を実際の請求額として示していません。

公開やチームへの導入にあたっての合格条件は、未解決のフィールドを保った、確認者が承認済みの情報源付き作業リストです。招待に関する制限を落としたり、予算の承認を捏造したりするなら、どれだけ短く読みやすくても、その要約は条件を満たしません。