「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
詳細 †
トランスクリプト品質依存 †
音声認識（ASR）の限界 †
- 背景音や咳払いなどの雑音、発言者の滑舌の悪さ、早口、なまりによって認識精度が落ちる。
- 複数人が同時に話す（ダイアログのオーバーラップ）と誰が何を言ったかが曖昧になる。
- 特に指示詞、専門用語や固有名詞、社内用語などは誤認識されやすい。
音声認識以外の品質低下要因 †
- 質疑、答弁のスタイルではなく、話を遮っての発言がある場合など。
- 口語的問題
- アレ、コレ、ソレなどの指示語が多用されている。
- 主語や目的語の省略（「やっといて」「進めて」など）
- 途中で文が途切れる（「それは…まあ、その…」）
- 言い直しや修正の多さ（「つまり…いや違う、えっと…」）
- 前提、根拠や背景、構造などの文脈が欠落
- 会議中の発言は省略や曖昧さが多く、逐語的に記録しても意味が通じ難い。
- 「当事者」の会話の内容を「部外者」が理解できないことがある。
- 「当事者」同士の発言は、背景にある文脈が言語に現れていない事が多い。
上手く行かない理由 †
その他、以下のような理由で苦手。
そもそもの難しさ †
- 単に音声をテキスト化するだけでなく、発言の真意や背景にある文脈を正確に理解し、議論の要点を抽出し、簡潔にまとめる必要がある。
- 会議では、複数の参加者が同時に発言したり、指示詞、専門用語が飛び交ったり、非言語的な情報（ジェスチャー、表情など）も含まれる。
- AIにとって判断が難しい「決定事項、タスク、重要な議論のポイント」などを取捨選択してまとめる必要がある。
発言の文脈・意図の理解が困難 †
- 暗黙の了解や前提知識、非言語的情報（表情、ジェスチャー）に依存する場合もある。
- 当事者同士の発言は、前提、根拠や背景、構造などの文脈が欠落していることが多い。
- AIは「何が重要だったか」「何が決定されたのか」を自動で判断するのが難しい（→LLMの進歩で解決されるるあるように見える）。
要約・構造化の難しさ †
- 会議の目的（情報共有/意思決定/ブレスト）によって要約の形式が異なる（→プロンプトで対応可能）
- 以下は、LLMの進歩で解決されるるあるように見える
- 会話は冗長で、要点が散らばっていたり、途中で話題が飛んだりする。
- 「決定事項」「次のアクション」「担当者」などの抽出には深い文脈理解が必要。
個人・組織ごとの書き方の差異 †
- 議事録には企業・組織ごとにフォーマットや書き方の文化がある（→プロンプトで対応可能）
- 「丁寧に」「簡潔に」「発言者を明示する/しない」など、汎用モデルでは対応が困難（→プロンプトで対応可能）
セキュリティ・プライバシーの懸念 †
- 会議内容には機密情報が含まれることが多くクラウド上のモデル利用が難しい。
- 特に生成AIを用いる場合、データが外部に送信されることへの懸念が強い。
※ 法人版を使用すれば良い。
責任と信頼性の問題 †
- 議事録は法的な意味を持つ場合も多く、内容の正確性が極めて重要。
- 誤りがあった場合の責任の所在が不明確であり、組織として利用することにリスクが伴う。
※ コレが最も問題だが、効率向上の観点で利用すれば良い。
まとめ †
| 項目 | 得意 / 不得意 | 説明 |
| テキスト要約 | △（構造化されていれば） | 会話形式だと精度が落ちる |
| 固定フォーマット出力 | △ | 定型的な会議（定例報告など）には適用可能 |
| 意思決定の抽出 | × | 意図や合意形成を自動で理解するのは困難 |
| 会話の構造理解 | × | 会話の流れや関係性をモデルが理解しきれない |
| 文書生成（清書） | ○ | 下書きがあれば文書化には有効 |
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
