「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
詳細 †
トランスクリプト品質依存説 †
- LLMではなく、トランスクリプト品質が、AI議事録作成施策のボトルネックになっているという話。
- 多くの組織施策は主流ではなく、音声認識性能とLLM性能・機能性（プロンプトフロー、マルチエージェント）に依存している説。
音声認識（ASR）の限界 †
- 背景音や咳払いなどの雑音、発言者の滑舌の悪さ、早口、なまりによって認識精度が落ちる。
- 複数人が同時に話す（ダイアログのオーバーラップ）と誰が何を言ったかが曖昧になる。
- 特に指示詞、専門用語や固有名詞、社内用語などは誤認識されやすい。
音声認識以外の品質低下要因 †
- 質疑、答弁のスタイルではなく、話を遮っての発言がある場合など。
- 口語的問題
- アレ、コレ、ソレなどの指示語が多用されている。
- 主語や目的語の省略（「やっといて」「進めて」など）
- 途中で文が途切れる（「それは…まあ、その…」）
- 言い直しや修正の多さ（「つまり…いや違う、えっと…」）
- 文脈欠落
前提、根拠や背景、構造など
- 会議中の発言は省略や曖昧さが多く、逐語的記録では意味が通じ難い。
- 「当事者」の会話の内容を「部外者」が理解できないことがある。
- 「当事者」同士の発言は、背景にある文脈が言語に現れていない事が多い。
トランスクリプト品質向上策 †
音声認識技術 †
高品質な音声認識AIを使用する
- Teams Premium ＋ M365 Copilot
- Teamsを個人単位に利用すれば、音声分離は不要で、IDベースに個々の発言を記録できる。
- Teams Premium に含まれる「インテリジェント会議録」では、文字起こし＋要約が可能。
- Microsoft Copilot for M365 と組み合わせると、決定事項やタスク抽出まで自動化可能。
- ただし、文字起こし精度は専用ASRに比べるとやや劣ることも。
- 専用ASR、発話者分離オプションあり。
- Whisper（OpenAI）
- Google Cloud Speech-to-Text
- AWS Transcribe
- AmiVoice?
- 専用ASR、発話者分離オプションがあるが、
Speaker番号での区別。名前は手動付与。
運用回避 †
AIモデル性能だけでなく、会議運営で運用回避
- 音声環境の最適化
- マイクの統一：参加者のマイク性能差を減らす（内蔵マイクではなくUSBヘッドセット推奨）。
- エコー/ハウリング防止：スピーカー出力を抑え、イヤホン利用を徹底。
- 雑音対策：会議室では空調やキーボード音を抑制、自宅では静音環境を確保。
- 発話スタイルのルール化
- 指示語の削減：「あれ」「それ」ではなく、必ず対象を明示
- 同時発話の回避：誰かが話している時は発言を重ねない
- 明確な区切り：要点を一文ごとに区切る、話題が変わるときは明示
- 最後に、決定事項とフォローアップタスクを明言して終わる。
- 技術的補助
- リアルタイム字幕利用（TeamsやZoomのAI字幕を補助的に活用し、誤変換を即修正）。
- 辞書登録：プロジェクト名・略語・技術用語をカスタム辞書に登録。
- 録音のバックアップ：AIが誤認識しても後から修正できるように、元音声を保存。
- 参加者教育
- AI議事録用の話し方研修：短く区切る・明瞭に話す・抑揚を意識する。
- 自動化任せにしない姿勢：後工程で人間がレビューする前提を周知。
クレンジング †
LLMを使用して、トランスクリプトをクレンジングする。
ありがちな施策・仕様 †
（モデレート）施策とか（ツール）仕様とか。
モデレーター †
- 発言を整理し、話の流れを統制。
- 報告と質疑の時間を分ける。
- 発言開始時に名前を言う（「田中さん、お願いします。」「田中です。次の件ですが…」）。
プロンプトフローをエクセルで †
- プロンプトフロー（複数回のLLM処理）をLLM Chatとエクセルで実現する。
- LLMツールの敷居が高い場合、プロンプト生成エクセルなどを展開する。
ファイル入出力機能 †
- VTTファイルなど入力ファイルの読み込み機能
- 出力機能（Word、PDF等の任意のフォーマットで出力）
入出力クレンジング機能 †
- 辞書を用いて書き起こし誤りを訂正する。
- Grep＆Replaceで置換する。
- 略語の展開（「RFP → 提案依頼書」）
- プロンプトを作成してLLMに文脈から正しい用語候補を推測させる。
- 文書校正
- ワードの文書校正機能を使用して修正
- 文書校正プロンプトを生成してLLMが修正
- ワードの文書校正結果をCopilotが認識して修正してくれるといいのだけど。
- 表記揺れ・話し言葉の正規化、ノイズ除去
LLMは文脈理解力が高いため、自然に整形できる。
- フィラー削除（「えー」「あのー」「うん」「はい」「えっと」）
- 口語表現を文語表現に変換（「やっぱ → やはり」）
- 「ですます調」から「である調」へ変換
- 文構造の整形
- 長文の分割、短文化
- 主語や述語の補完
- 話題転換点の明示
- 雑談と本題の分離（タグ付け）LLMは分類のが得意。
概要作成機能 †
会議の概要を設定しプロンプトを生成する。
要約作成機能 †
どのような観点で要約するかプロンプトを生成する。
- フォーカス対象
- 決定事項
- アクションアイテム
- 発言要点、課題、反対意見、リスク
- その他
- 要約レベル：全体の俯瞰／議題ごとの詳細／発言者別
- 対象読者の想定：経営層／参加者／外部共有用／技術部門向け
議事メモ取り込み機能 †
- 議事メモを取るように運用。
- 議事メモをプロンプトに含める。
- 決定事項、アクションアイテム、課題、反対意見、リスクなどが対象。
その他、上手く行かない理由 †
そもそもの難しさ †
- 単に音声をテキスト化するだけでなく、発言の真意や背景にある文脈を正確に理解し、議論の要点を抽出し、簡潔にまとめる必要がある。
- 会議では、複数の参加者が同時に発言したり、指示詞、専門用語が飛び交ったり、非言語的な情報（ジェスチャー、表情など）も含まれる。
- AIにとって判断が難しい「決定事項、タスク、重要な議論のポイント」などを取捨選択してまとめる必要がある。
発言の文脈・意図の理解が困難 †
- 情報の欠落
- 暗黙の了解や前提知識、非言語的情報（表情、ジェスチャー）に依存する場合もある。
- 当事者同士の発言は、前提、根拠や背景、構造などの文脈が欠落していることが多い。
- AIでの自動判断では難しい。
- 「何が重要だったか？」
- 「何が決定されたのか？」
- 「持ち帰り事項はなんだったか？」
要約・構造化の難しさ †
- プロンプトで対応可能
会議の目的（情報共有/意思決定/ブレスト）によって要約の形式が異なる
- 以下は、LLMの進歩で解決されつつあるように見える。
- 会話は冗長で、要点が散らばっていたり、途中で話題が飛んだりする。
- 「決定事項」「次のアクション」「担当者」などの抽出には深い文脈理解が必要。
個人・組織ごとの書き方の差異 †
- 議事録には企業・組織ごとにフォーマットや書き方の文化がある。
- 「丁寧に」「簡潔に」「発言者を明示する/しない」など汎用モデルでは対応が困難。
※ コチラは、プロンプトで対応可能
セキュリティ・プライバシーの懸念 †
- 会議内容には機密情報が含まれることが多くクラウド上のモデル利用が難しい。
- 特に生成AIを用いる場合、データが外部に送信されることへの懸念が強い。
※ コチラは、法人版を使用すれば良い。
責任と信頼性の問題 †
- 議事録は法的な意味を持つ場合も多く、内容の正確性が極めて重要。
- 誤りがあった場合の責任の所在が不明確であり、組織として利用することにリスクが伴う。
※ コレが最も問題だが、効率向上の観点で利用すれば良い。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
