会議の録音から議事録と決定事項・宿題を作る

処理の起点を決める

文字起こしファイルの生成を起点にします。UC-0001と同じく、会議終了を直接のトリガーにすると、まだ生成されていないデータを取りに行って失敗します。

すべての会議を対象にしないでください。 1対1の面談、採用面接、雑談的な打ち合わせは対象外です。対象を限定する方法は次のいずれかです。

• 会議の件名に特定の文字列（[議事録] など）を含むものだけを処理する
• 議事録を作る会議体を事前に登録し、そのカレンダーの予定だけを処理する

後者を推奨します。 件名のルールは守られないことがあります。

入力データを集める

参加者一覧を渡すことが重要です。 「山田さんお願いします」という発言から担当者を特定するには、参加者の氏名リストが必要です。文字起こしの氏名は誤変換されることがあるため、参加者リストと照合させます。

データの取得方法を決める

文字起こし： Microsoft Graph の GET /users/{userId}/onlineMeetings/{meetingId}/transcripts で一覧を取得し、/content で本文を取得します。カレンダーに予定として存在する会議のみが対象で、テナント管理者がGraph経由のアクセスを止めている場合は403が返ります。

会議体を事前登録する方式なら、必ずカレンダーに予定があるため、この制約は問題になりません。

対面会議： Teamsの会議室デバイスを使っていない場合、文字起こしがありません。対面会議はこの構成の対象外とするか、スマートフォンの録音アプリで録音して文字起こしサービスに通す運用を別に用意します。

AIへ渡す前に整形する

1. 雑談部分の除去 … 冒頭の接続確認、天気の話などを落とします。先頭2分を落とすだけでも効きます
2. 議題ごとの分割 … 60分の会議で議題が5つある場合、議題ごとに分けて処理すると精度が上がります。ただし、文字起こしから議題の切れ目を機械的に判定するのは難しいため、会議中に議題を口頭で宣言する運用（「では2つ目の議題に移ります」）を作ると、分割しやすくなります
3. 氏名の照合 … 文字起こしの発言者名と、参加者リストを突き合わせます
4. 長時間会議の分割 … 90分を超える会議は、時間で区切って処理し、最後に統合します

AIに処理させる

要約ではなく、3種類の情報の分離です。

「議論の経緯」は、決定事項の補足として簡潔に書かせます。 発言録は作りません。

指示内容を固定する

あなたは会議の議事録を作成する事務局です。
以下の文字起こしから、決定事項・保留事項・宿題を抽出してください。

【厳守事項】
- 発言録を作らないでください。誰が何を言ったかの羅列は不要です。
- 明示的に結論が出た内容のみを「決定事項」としてください。
  議論の流れから結論を推測しないでください。
  結論が出ていない場合は「保留事項」に入れてください。
- 宿題には担当者と期限を記載してください。
  発言から特定できない場合は "担当未定" "期限未定" と記載し、
  推測で人名や日付を入れないでください。
- 担当者名は、提示された参加者リストの氏名を使ってください。
  リストにない氏名を書かないでください。
- 数値、金額、日付は発言のとおりに記載してください。
  概算への丸めや単位の変換をしないでください。
- 「前向きに検討」「おおむね合意」のような曖昧な表現が
  結論として述べられた場合は、決定事項ではなく保留事項に入れ、
  その旨を注記してください。
- 参加者の評価、能力、態度に関する記述をしないでください。

【会議体】{meeting_name} / 【日時】{datetime}
【参加者】{participants}

【前回の未完了の宿題】
{previous_action_items}

【文字起こし】
{transcript}

「前向きに検討」を決定事項に入れない、という制約が効きます。 日本語の会議では、明確に否定せず曖昧に終わることが多くあります。それを「決定」として記録すると、後で「決まっていたはずだ」という認識のずれが起きます。曖昧なものは曖昧なまま記録することに意味があります。

「担当者名は参加者リストから」も重要です。文字起こしの誤変換で存在しない人名が生まれ、その人に宿題が割り当てられる事故を防ぎます。

出力形式を固定する

{
  "meeting_name": "",
  "datetime": "",
  "participants": [],
  "decisions": [
    { "topic": "", "decision": "", "context": "", "quote": "" }
  ],
  "pending": [
    { "topic": "", "reason": "", "next_step": "", "note": "" }
  ],
  "action_items": [
    {
      "task": "",
      "owner": "",
      "due": "",
      "owner_confirmed": true,
      "due_confirmed": false
    }
  ],
  "previous_items_status": [
    { "task": "", "status": "完了 | 未完了 | 言及なし", "quote": "" }
  ],
  "unclear_points": []
}

• owner_confirmed / due_confirmed … 発言から明確に特定できたかどうか。false のものは事務局が確認します
• previous_items_status … 前回の宿題が今回の会議で言及されたか。「言及なし」が続く宿題は、忘れられている宿題です
• quote … 判断の根拠になった発言。事務局が確認する際に使います

システムへ連携する

議事録： SharePointのドキュメントライブラリ、またはSharePointページとして保存します。様式は「決定事項」「保留事項」「宿題」「議論の経緯」の順にします。発言録の欄は作りません。 欄を作ると埋めたくなります。

宿題： Microsoft Planner または Teams のタスクへ登録します。owner_confirmed: true かつ due_confirmed: true のものだけを自動登録し、それ以外は事務局が確認してから登録します。

リマインド： 期限の2営業日前に、担当者へTeamsで通知します。

前回分との照合： 次回の処理時に、未完了の宿題リストを入力として渡します。これにより、宿題が完了するまで追跡されます。

この「宿題の登録とリマインド」までを作ることが、この構成の価値です。 議事録を作るだけで止めると、宿題は相変わらず文中に埋もれます。

人が確認する

全件、事務局が確認します。

確認の観点は3つです。

1. 決定事項が実際に決まったことか … quote を見て判断します。ここを誤ると、決まっていないことが決定として記録されます
2. 宿題の担当者と期限が正しいか … owner_confirmed: false のものを確認します
3. 保留事項が漏れていないか … 議論したが結論が出なかったことが記録されているか

確認後、参加者にも共有し、認識違いがあれば指摘してもらう運用を残してください。議事録は複数人の認識を揃える文書なので、事務局1人の確認では足りません。

例外に対処する

記録を残す

• 文字起こし
• AIの抽出結果
• 事務局が確定させた議事録
• 抽出結果と確定版の差分
• 宿題の登録・完了の履歴

文字起こしの保存期間を決めてください。 会議の全発言が残ることは、参加者にとって心理的な負担になります。議事録が確定した後は文字起こしを削除する、または一定期間で自動削除する運用を検討してください。この方針を参加者に事前に説明することも必要です。