この記事では、音声認識API「AmiVoice API」と生成AIを組み合わせて、会議や商談の録音を「あとから聞き返せる議事録」に変える設計を整理します。
単に音声をテキスト化するだけなら、いまは珍しくありません。問題はその先です。
- どの発言が、どの決定につながったのか
- ToDo は誰に割り当てられたのか
- 要約が本当に元発言に基づいているのか
- 後から質問したとき、根拠の時刻まで戻れるのか
ここまで扱って、ようやく「音声体験」と呼べます。
先に結論を書くと、AmiVoice API は入口で、生成AIは出口です。体験の品質を決めるのは、その間にある「認識結果の正規化」「根拠付き要約」「確認UI」「再処理できるジョブ設計」です。
想定するユースケース
例えば、営業会議や社内定例の録音をアップロードすると、次のような画面が返ってくるアプリを考えます。
- 会議全体の要約
- 決定事項
- ToDo と担当者
- 未決事項
- 重要発言へのタイムスタンプリンク
- 「予算の話はどこ？」のような自然文検索
ここで大事なのは、生成AIの回���をそのまま信じさせないことです。議事録は業務の根拠になります。回答には、元の発言へ戻れるリンクが必要です。
全体アーキテクチャ
最小構成は次のように分けます。
| 層 | 役割 | 注意点 |
|---|---|---|
| フロントエンド | 音声アップロード、進捗表示、要約確認、質問UI | 長時間処理を同期画面で待たせない |
| API 層 | 認証、ファイル受付、ジョブ作成 | API Gateway + Lambda などで入口を薄く保つ |
| ストレージ | 音声ファイル、認識結果、生成結果の保存 | S3 などに原本と派生物を分けて保存する |
| 音声認識 | AmiVoice API による文字起こし | API仕様や話者分離の扱いは公式仕様を確認する |
| 正規化 | 発話単位、時刻、話者、句読点の整形 | LLMに投げる前の品質が回答品質を決める |
| 生成AI | 要約、ToDo抽出、質問応答 | 根拠のない断定を避ける |
| 検索 | チャンク検索、全文検索、ベクトル検索 | タイムスタンプを失わない |
構成を図にすると、かなり地味です。
Browser / Mobile
-> API Gateway
-> Lambda: create transcription job
-> S3: raw audio
-> Worker: call AmiVoice API
-> DB: transcript segments
-> LLM worker: summary / action items / QA index
-> Search index: timestamped chunks
-> UI: summary + source links
地味ですが、この分割にしておくと失敗時の再実行が楽です。音声認識だけ再実行したいのか、要約だけ作り直したいのか、検索インデックスだけ更新したいのかを分けられます。
認識結果をそのままLLMに渡さない
音声認識APIの結果を、そのまま長い文字列として生成AIに渡すのはおすすめしません。
理由は単純で、後から根拠に戻れなくなるからです。
最低でも、次のような単位に整形してから扱います。
{
"meeting_id": "mtg_20260522_001",
"segment_id": "seg_00042",
"speaker": "speaker_2",
"start_ms": 184230,
"end_ms": 191840,
"text": "次回までに料金プランの比較表を作ります。",
"confidence": 0.91
}
この形式にしておくと、生成AIが「料金プランの比較表を作る」というToDoを抽出したときに、元発言の segment_id と時刻を一緒に返せます。
生成AIに任せる処理を分ける
ひとつの巨大プロンプトで、要約、ToDo、リスク、質問応答を全部やらせると、保守しづらくなります。
私は次のよう���分けるのが扱いやすいと考えています。
- 会議全体の短い要約
- 決定事項の抽出
- ToDo の抽出
- 未決事項・確認事項の抽出
- ユーザー質問への回答
それぞれ出力形式を固定します。
あなたは会議ログを整理するアシスタントです。
以下の transcript segments だけを根拠に、ToDoを抽出してください。
制約:
- 推測で担当者を補わない
- 不明な場合は assignee: null とする
- 必ず根拠 segment_id を含める
- 出力は JSON 配列のみ
ここで重要なのは、「不明なら不明」と出させることです。議事録で一番困るのは、もっともらしい嘘です。
RAGにするなら、チャンクに時刻を持たせる
会議ログに対して「来月の予算の話はどうなった？」と聞けるようにするなら、RAG構成にしたくなります。
ただし、チャンクから時刻情報を落とすと一気に使いづらくなります。
検索対象のチャンクには、本文だけでなく次の情報を持たせます。
- meeting_id
- segment_id の範囲
- start_ms / end_ms
- speaker
- original_text
- normalized_text
- embedding text
回答時には、生成AIに「引用IDなしの回答は禁止」と指示します。
{
"answer": "予算は次回会議までに再見���もりする方針です。",
"citations": [
{ "segment_id": "seg_00042", "start_ms": 184230 },
{ "segment_id": "seg_00051", "start_ms": 231900 }
]
}
UI側では citation をクリックすると、その時刻から音声を再生できるようにします。これで「AIがそう言っている」ではなく「元発言に戻れる」体験になります。
長時間音声はジョブとして扱う
音声ファイルは、テキスト入力より失敗パターンが多いです。
- ファイルが大きい
- 無音区間が長い
- 複数人が被って話す
- ノイズが多い
- 処理時間が長い
- ユーザーが画面を閉じる
そのため、同期APIで全部返す設計にしない方が安全です。
POST /meetings
-> meeting_id を返す
POST /meetings/{id}/audio
-> upload_url を返す
POST /meetings/{id}/transcription-jobs
-> job_id を返す
GET /meetings/{id}/jobs/{job_id}
-> queued / running / failed / completed
失敗時には、どの段階で落ちたかを残します。
- upload_failed
- transcription_failed
- normalization_failed
- llm_summary_failed
- indexing_failed
これを残さないと、運用時に「なんか議事録ができません」しか分かりません。地獄です。
セ���ュリティとプライバシーを後回しにしない
音声には、メールより生々しい情報が入ります。
顧客名、価格、障害、評価、採用、個人情報。会議音声はだいたい危険物です。
最低限、次は設計に入れます。
- アップロード時の同意表示
- 保存期間の明示
- 原音声と生成結果の削除機能
- プロジェクト単位のアクセス制御
- 監査ログ
- LLMに渡す前のマスキング
- 外部APIに送るデータ範囲の説明
特に、生成AIの要約だけ消しても原音声が残っていたら意味がありません。削除要求は、原本、認識結果、要約、検索インデックスまで一貫して処理する必要があります。
体験として一番効くのは「確認できる」こと
音声認識と生成AIを組み合わせると、つい自動化を前面に出したくなります。
でも、業務で本当に使われるには、自動化より確認性が大事です。
良いUIは、たとえば次のようになります。
- 要約文の横に根拠発言を表示する
- ToDo に「担当者不明」の状態を許す
- ユーザーが要約を修正できる
- 修正前のAI出力と修正後の確定版を分ける
- 重要な決定事項には「確認済み」フラ���を付ける
AIが書いた議事録を、そのまま正式記録にする必要はありません。AIは下書きを作り、人間が確定する。この分担の方が現実的です。
まとめ
AmiVoice APIのような音声認識APIと生成AIを組み合わせると、文字起こしを超えた音声体験を作れます。
ただし、品質を決めるのはモデルの派手さではありません。
- 認識結果を発話単位で保存する
- タイムスタンプを最後まで失わない
- LLM処理を用途別に分ける
- 回答には根拠を必ず付ける
- 長時間音声をジョブとして扱う
- 削除、権限、監査を最初から設計する
ここまで作って初めて、「文字起こしツール」ではなく「聞き返せる議事録体験」になります。
音声認識APIは入口です。生成AIは出口です。その間の設計を雑にすると、便利そうに見えるだけの危ない議事録ができます。そこを丁寧に作るのが、音声体験の本体です。