顧客との品質の打合せの文字起こしから合意事項と宿題を議事録にし、是正措置の管理表の状態と期限の更新案を作る

処理の起点を決める

半自動化では、文字起こしのファイルが所定のライブラリに保存されたことを起点にします。 SharePoint コネクタの「ファイルの作成時 (プロパティのみ)」をトリガーにし、ライブラリには管理番号の列を必須にして、どの不具合の打合せかを保存のときに選んでもらいます。

ファイルは .vtt で保存してもらいます。 プロンプトに渡せるドキュメントの形式は PNG、JPG、JPEG、PDF が基本で、Word のファイルはコード インタープリターを有効にしたときに限られるとされています。.vtt はテキストなので、フローで中身を読んでテキストの入力として渡します。 .docx を選ぶと、この経路に乗りません。

本格構成では、会議の後に文字起こしを自動で取りに行きます。 Microsoft Graph の callTranscript の取得で、/content に text/vtt を指定すると、タイムスタンプ付きの発話と話者のタグが返ります。毎日の夕方に、その日に終わった品質の打合せを予定表から拾い、文字起こしを取得してライブラリへ保存するフローを足します。保存されたあとは、半自動化と同じトリガーから先に流れます。

入力データを集める

質を決めるのは、前回の議事録と参加者の一覧です。 前回の宿題が無ければ、「前回の件は完了しました」が何の完了なのかを決められません。参加者の一覧が無ければ、発言が顧客のものか自社のものかが分からず、「顧客が認めた」かどうかを判定できません。

用語の一覧は、文字起こしの誤りを読み解くために渡します。 品番や設備名は、文字起こしで別の言葉に化けやすい語です。AIに一覧と照らして読ませ、議事録では一覧の表記に直させます。 直したときは、元の文字起こしの語を残させます。

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

文字起こしは、SharePoint コネクタの「ファイル コンテンツの取得」でテキストとして読みます。管理表の行は「アイテムを取得」で、保存のときに選んだ管理番号をフィルター クエリにして引きます。前回の議事録は、同じ管理番号でライブラリを引き、日付の新しいものを1つ取ります。

本格構成の Graph の取得には、条件が多くあります。 公式ドキュメントでは、アクセス許可は OnlineMeetingTranscript.Read.All などで、アプリケーションのアクセス許可を使う場合はテナント管理者がアプリケーション アクセス ポリシーを作成してユーザーに付与する必要があるとされています。さらに、トランスクリプトへの Graph API のアクセスと話者の帰属という2つの独立したテナント管理者の設定があり、前者が無効なら要求は403になり、後者が無効なら text/vtt の要求は403になって話者の無い形式で取り直すことになります。話者の無い文字起こしでは、顧客の発言かどうかを判定できません。 情報システム部門と、この2つの設定を先に確かめます。

AIへ渡す前に整形する

1. 時刻と話者の整形 … .vtt の時刻と話者のタグを「[00:12:34] 話者名：発話」の1行に直します
2. 話者を会社と役割に置き換える … 参加者の一覧と照らし、話者名の後ろに「（顧客・品質）」「（自社・品質）」を付けます
3. 短い相づちの除去 … 「はい」「ええ」だけの発話を落とします。否定の「いえ」は落としません
4. 用語の一覧を絞る … 対象の品番と工程に関係する語だけを渡します
5. 長さの確認 … 1時間を大きく超える打合せは、議題の切れ目で前後に分けて渡し、結果を後で合わせます
6. 前回の宿題の抜き出し … 前回の議事録から、宿題と期限の表だけを取り出して渡します

2番目が、この構成の要です。 AIに「顧客が合意したか」を判定させるには、発言ごとに顧客側か自社側かが分かっている必要があります。 話者のタグが無い文字起こしでは、この前処理ができません。

5番目の分け方は、時刻で機械的に切らないでください。 合意の発言と、それに対する「それで結構です」が切れ目の両側に分かれると、合意が拾えなくなります。 議題の切れ目は、管理表の項目（原因、暫定対策、恒久対策）の言葉が出てくる位置で見ます。プロンプトで選ぶモデルによって、入力と出力のトークン数の上限が異なるとされているので、分ける長さはモデルに合わせて決めます。

AIに処理させる

させるのは、文字起こしから次の5つを拾い、それぞれに根拠の発言と時刻を付けることです。

合意事項の条件を、顧客側の了承の発言に置きます。 自社が「暫定対策は完了しました」と言っただけでは、合意ではありません。顧客の品質担当が「完了で結構です」と言った発言があって初めて合意です。 前処理で付けた会社と役割が、ここで効きます。

期限は、言われたとおりに残します。 「来週中に」は、打合せの日から日付に直した値と、元の言葉の両方を返させます。日付に直したものだけを議事録に書くと、「来週中」が金曜なのか翌週月曜の朝なのかで顧客と食い違います。

管理表の更新案は、AIの出力からフローが作ります。 合意事項のうち管理表の欄に当たるもの（暫定対策の状態、恒久対策の期限など）だけを取り出し、「管理番号Q-2481：恒久対策の期限 10月31日→11月15日」の形の差分にします。

指示内容を固定する

あなたは部品メーカーの品質保証部で、顧客との品質の打合せの議事録を作る立場です。
文字起こしと、与えられた管理表の行・前回の宿題だけを見て拾い出してください。
推測で埋めないでください。

【拾うもの】
1. agreements：顧客と自社の双方が了承したこと
2. our_actions：自社が、何を、いつまでにすると言ったこと
3. customer_requests：顧客が自社に求めたこと、顧客側が持ち帰ったこと
4. pending：「検討します」「確認します」「社内で相談します」など、約束になっていないこと
5. figures：不良の数、ロット、対象期間、選別の数量など、発言された数値
それぞれに、根拠の発言をそのまま写した quote と、その時刻 time を付けてください。

【厳守事項】
- agreements にするのは、顧客側（話者に「顧客」と付いた人）が了承を示した発言があるものだけです。
  自社側が「完了しました」と言っただけのものは agreements にしないでください。
- 約束か持ち帰りか迷ったら、pending にしてください。
- 期限は、発言された言葉を due_said にそのまま入れ、打合せの日 {meeting_date} から
  日付に直せる場合だけ due_date に入れてください。直せなければ due_date は空欄です。
- 期限の発言が無い宿題に、期限を補わないでください。
- 聞き取れない数値、文字起こしで崩れている数値は空欄にし、questions に書いてください。
- 品番・工程名・設備名は【用語の一覧】の表記に直し、元の文字起こしの語を original に残してください。
- 不具合の原因が何かを、自分で判断して書かないでください。発言された内容だけを写してください。
- 前回の宿題のうち、この打合せで完了・延期・取り下げが話されたものは、
  previous_actions に結果と根拠を書いてください。話されなかったものは「言及なし」にしてください。
- 回答に JSON マークダウンを含めないでください。

【文字起こし】{transcript}
【管理表の行】{capa_record}
【前回の宿題】{previous_actions}
【参加者】{participants}
【用語の一覧】{glossary}

「自社側が完了しましたと言っただけのものは合意にしない」を書かないと、自社の報告がすべて合意になります。 打合せの大半は自社の報告で、顧客は黙って聞いていることが多いからです。黙っていたことは了承ではありません。

前回の宿題の「言及なし」を入れるのは、宿題の消え方を止めるためです。 前回の宿題が今回話されなかったとき、何も指示しないとAIはそれを議事録から落とします。落ちた宿題は、次の打合せで顧客から聞かれるまで誰も思い出しません。

出力形式を固定する

プロンプトの出力は、次の形の JSON で固定します。

{
  "capa_no": "",
  "meeting_date": "",
  "agreements": [
    { "item": "", "quote": "", "time": "", "speaker": "" }
  ],
  "our_actions": [
    { "task": "", "owner_said": "", "due_said": "", "due_date": "", "quote": "", "time": "" }
  ],
  "customer_requests": [ { "request": "", "quote": "", "time": "" } ],
  "pending": [ { "item": "", "quote": "", "time": "" } ],
  "figures": [ { "label": "", "value": "", "quote": "", "time": "" } ],
  "previous_actions": [ { "task": "", "result": "done | postponed | dropped | 言及なし", "quote": "" } ],
  "questions": []
}

1つ目の理由は、議事録の形をそろえられることです。 フローはこの JSON から、合意事項・自社の宿題・顧客の要求・持ち帰り・前回の宿題の結果の順に、毎回同じ並びの議事録を作ります。 担当者ごとに議事録の書き方が違う状態が、ここで止まります。

2つ目は、管理表の更新案を規則で作れることです。 フローは agreements のうち、管理表の欄の言葉（暫定対策、恒久対策、効果の確認、期限）を含むものだけを取り出し、差分の行にします。

3つ目は、quote と time で確認が速くなることです。 品質担当は録画を最初から見返す必要がなく、時刻のところだけを聞き直せば済みます。

システムへ連携する

顧客への送信は、この連携に入れていません。 議事録の送付は品質担当が自分のメールで行います。顧客に出す文書を、フローの送信元から出すことはしません。

承認には期限を決めておきます。 Power Automate のフロー1回の実行は30日が上限で、承認のような保留中のステップも含まれ、30日を過ぎるとタイムアウトします。品質の打合せは毎週から隔週で続くので、承認が次の打合せまで残っていたら、その時点で品質担当に知らせます。

人が確認する

品質担当が、議事録の下書きと管理表の更新案を、根拠の発言を見ながら確かめます。

1. 合意事項を先に見る … quote を読み、顧客側の了承の発言が本当にあるかを確かめます。疑わしければ time の箇所を録画で聞き直します
2. 自社の宿題の期限を見る … due_said と due_date が食い違っていないか。「来週中」を何日とするかは、ここで人が決めます
3. 持ち帰りを見る … 約束に上げるべきものが混ざっていないか。ここは上げる方向にだけ直します
4. 数値を見る … 不良の数とロットを、手元の調査記録と照らします
5. 管理表の更新案を承認する … conflict のものは課長に相談してから決めます

1番目を省かないでください。 合意事項を誤って載せた議事録は、顧客の手元では「自社が認めた記録」として残ります。 削減した時間より、取り消しのやり取りのほうがはるかに重くなります。

課長の確認は、conflict があるときと、新しい期限を約束したときに絞ります。 全件を課長に回すと、第3章の（a）の遅れが課長のところで再び起きます。

例外に対処する

Graph の取得が403のとき、話者の無い形式で取り直さない、を明記しておきます。 公式ドキュメントは、話者の帰属が無効なときは話者の無い形式で再試行するよう案内しています。汎用の議事録ならそれで足りますが、この構成では顧客の発言かどうかが要なので、話者の無い文字起こしは使いません。

文字起こしの言語については、サポート ページで、話す言語の設定が必要で、Teams が不一致を検出すると開催者に設定の更新を促すとされています。 海外の顧客と英語で打ち合わせる回は、会議ごとに確かめます。

記録を残す

• 文字起こしの元のファイル（.vtt）と、整形後のテキスト
• プロンプトが返した JSON の全文
• 議事録の下書きと、品質担当が直して送った版
• 管理表の更新案と、承認・修正・却下の結果
• 管理表の行の「最終更新の打合せ日」「最終更新の議事録」
• 関係部署へ知らせた宿題と期限、知らせた日時

下書きと送った版の両方を残すのは、AIの拾い方の癖を見つけるためです。 品質担当が毎回同じ種類の合意事項を消しているなら、プロンプトの合意の条件がまだ緩いということです。

ログは Power Automate の実行履歴に頼りません。 実行の保持期間は実行の開始時刻から30日です。品質の記録は不具合の解決後も何年も参照されるので、SharePoint のライブラリとリストに残します。