「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
LLM利用目的 †
AIメモ的 †
会議内容を俯瞰して、何が議論されたかを確認するもの。
- トランスクリプトをそのままLLMに処理させる。
- 精度には問題があるため、俯瞰は可能だが正誤について課題が残る。
作成支援 †
いつもどおりの手作業議事録作成の延長上でLLMを使用する。
- 様々な追加施策や手作業で精度を上げ、実用可能なものにする。
- トランスクリプト品質向上施策、入力出力のクレンジング・ツール
議事録の種別 †
以下のような種別があるが、実際の技j録やTeamsのAIメモなどで「フレームワーク型＋決定事項型」が主流。
決定事項型 †
（アクションログ型）
- 特徴: 決定事項、フォローアップタスク（、担当者、期限）だけを書く。
- 用途: プロジェクト会議や進捗確認ミーティングなど、アウトプット重視の場合。
要点整理型 †
（サマリー型）
- 特徴: 議論の流れは簡単に、主要な発言や合意内容を短くまとめる。
- 用途: 打ち合わせ・定例会議で「何を話したか」を後で確認したいとき。
発言記録型（逐語型に近い） †
- 特徴: 発言をほぼ時系列で記録。ただし逐語録ほど厳密ではなく要約する。
- 用途: トラブル懸念のある会議、法務・労務関係、利害調整の場。
フレームワーク型 †
- 特徴: 「目的、議題、決定事項、フォローアップタスク、次回予定」など、決まった枠に沿って書く。
- 用途: 定型的な定例会、社内報告用。
詳細 †
トランスクリプト品質依存説 †
LLMではなく、音声認識によるトランスクリプト品質が、AI議事録作成施策のボトルネックになっているという話。
音声認識（ASR）の限界 †
- 背景音や咳払いなどの雑音、発言者の滑舌の悪さ、早口、なまりによって認識精度が落ちる。
- 複数人が同時に話す（ダイアログのオーバーラップ）と誰が何を言ったかが曖昧になる。
- 特に指示詞、専門用語や固有名詞、社内用語などは誤認識されやすい。
音声認識以外の品質低下要因 †
- 質疑、答弁のスタイルではなく、話を遮っての発言がある場合など。
- 口語的問題
- 指示語の多用：アレ、コレ、ソレなどの指示語が多用されている。
- 省略表現：主語や目的語の省略（「やっといて」「進めて」など）
- 中断や不完全な文：途中で文が途切れ（「それは…まあ、その…」）断片的な情報しか残らない。
- 言い直し・修正の頻発：言い直しや修正（「つまり…いや違う、えっと…」）を削るとニュアンスが欠ける。
- 背景知識の不足：前提や目的が明示されていないため、議事録だけ読んでも理解できない。
- 内部関係者依存の会話：当事者間では通じる略語・暗黙の了解が多く、第三者が読むと意味が不明瞭。
- 時間的制約：会議特有の「短い発話の積み重ね」で進行するため、1発言単体では意味が薄い。
- 非言語情報の欠落：表情・ジェスチャー・声のトーン・沈黙など、重要なニュアンスが文字化できない。
スタイルによる差異 †
公共の答弁（国会答弁や市議会答弁など）とスタンドアップミーティング（日常的なチーム短時間打ち合わせ）では、差が出易い。
- 公共の答弁（精度が出やすい）
- 発話がフォーマルで明瞭：政治家や公務員は公式な場なので、比較的はっきり・標準語で話す。
- 話者交替が明確：「○○議員」「○○大臣」など、発言者が順番に指名される。
- 重なり発話が少ない：原則一人ずつ発言する。
- 背景ノイズが少ない：マイクや会場の音響が整っている。
- 定型的な言い回しが多い：決まり文句や慣用句（「ご質問にお答えします」など）が多く、言語モデルが補正しやすい。
- スタンドアップミーティング（精度が出にくい）
- 発話がカジュアルで省略が多い：短い単語、略語、口語表現（「これ、昨日やったやつ」「あれってさ」など）が多い。
- 話者の切り替えが早く、被り易い：複数人が同時に話したり、割り込んだりする。
- マイク環境が悪いことが多い：オフィスでの雑音、PCファン音、距離がある発話など。
- 話速が速く、イントネーションがバラバラ：内輪の会話なので、聞き取りやすさを意識しない。
- 固有名詞・専門用語が多い：チーム内でしか通じない略称やコードネーム（「PRマージした？」「JIRAのチケット番号1234」など）が多い。
トランスクリプト品質向上策 †
トランスクリプト品質が低いのなら、向上策で品質向上させるしか無い。
音声認識技術 †
高品質な音声認識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ツールの敷居が高い場合、プロンプトフロー（複数回のLLM処理）をLLM Chatとエクセルで実現する。
- より高度なエージェント・フロー、マルチ・エージェントと組み合わせる場合は、当該機能のあるLLM Chatと組み合わせるなど。
ファイル入出力機能 †
- VTTファイルなど入力ファイルの読み込み機能
- 出力機能（Word、PDF等の任意のフォーマットで出力）
入出力クレンジング機能 †
- 辞書を用いて書き起こし誤りを訂正する。
- Grep＆Replaceで置換する。
- 略語の展開（「RFP → 提案依頼書」）
- プロンプトを作成してLLMに文脈から正しい用語候補を推測させる。
- 文書校正
- ワードの文書校正機能を使用して修正
- 文書校正プロンプトを生成してLLMが修正
- ワードの文書校正結果をCopilotが認識して修正してくれるといいのだけど。
- 表記揺れ・話し言葉の正規化、ノイズ除去
LLMは文脈理解力が高いため、自然に整形できる。
- フィラー削除（「えー」「あのー」「うん」「はい」「えっと」）
- 口語表現を文語表現に変換（「やっぱ → やはり」）
- 「ですます調」から「である調」へ変換
- 文構造の整形
- 長文の分割、短文化
- 主語や述語の補完
- 話題転換点の明示
- 雑談と本題の分離（タグ付け）LLMは分類のが得意。
概要作成機能 †
会議の概要を設定しプロンプトを生成する。
要約作成機能 †
どのような観点で要約するかプロンプトを生成する。
- フォーカス対象
- 決定事項
- アクションアイテム
- 発言要点、課題、反対意見、リスク
- その他
- 要約レベル：全体の俯瞰／議題ごとの詳細／発言者別
- 対象読者の想定：経営層／参加者／外部共有用／技術部門向け
議事メモ取り込み機能 †
- 議事メモを取るように運用。
- 議事メモをプロンプトに含める。
- 決定事項、アクションアイテム、課題、反対意見、リスクなどが対象。
その他、上手く行かない理由 †
そもそもの難しさ †
- 単に音声をテキスト化するだけでなく、発言の真意や背景にある文脈を正確に理解し、議論の要点を抽出し、簡潔にまとめる必要がある。
- 会議では、複数の参加者が同時に発言したり、指示詞、専門用語が飛び交ったり、非言語的な情報（ジェスチャー、表情など）も含まれる。
- AIにとって判断が難しい「決定事項、タスク、重要な議論のポイント」などを取捨選択してまとめる必要がある。
発言の文脈・意図の理解が困難 †
- 情報の欠落
- 暗黙の了解や前提知識、非言語的情報（表情、ジェスチャー）に依存する場合もある。
- 当事者同士の発言は、前提、根拠や背景、構造などの文脈が欠落していることが多い。
- AIでの自動判断では難しい。
- 「何が重要だったか？」
- 「何が決定されたのか？」
- 「持ち帰り事項はなんだったか？」
要約・構造化の難しさ †
- プロンプトで対応可能
会議の目的（情報共有/意思決定/ブレスト）によって要約の形式が異なる
- 以下は、LLMの進歩で解決されつつあるように見える。
- 会話は冗長で、要点が散らばっていたり、途中で話題が飛んだりする。
- 「決定事項」「次のアクション」「担当者」などの抽出には深い文脈理解が必要。
個人・組織ごとの書き方の差異 †
- 議事録には企業・組織ごとにフォーマットや書き方の文化がある。
- 「丁寧に」「簡潔に」「発言者を明示する/しない」など汎用モデルでは対応が困難。
※ コチラは、プロンプトで対応可能
セキュリティ・プライバシーの懸念 †
- 会議内容には機密情報が含まれることが多くクラウド上のモデル利用が難しい。
- 特に生成AIを用いる場合、データが外部に送信されることへの懸念が強い。
※ コチラは、法人版を使用すれば良い。
責任と信頼性の問題 †
- 議事録は法的な意味を持つ場合も多く、内容の正確性が極めて重要。
- 誤りがあった場合の責任の所在が不明確であり、組織として利用することにリスクが伴う。
※ コレが最も問題だが、効率向上の観点で利用すれば良い。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
