システム開発の委託先との定例会議の記録から、課題管理表の状態と期限を更新する

処理の起点を決める

起点は、会議の冒頭で文字起こしを開始することです。 更新案を作るのは会議の後ですが、文字起こしが無ければ会議後の Copilot は会議の中身に答えられません。会議が終わった後に何が言われたかを質問するには、会議のトランスクリプトが利用可能である必要があります。

会議ポリシーで Copilot の既定値を決めておきます。 既定値は「オンで、トランスクリプトの保存が必須」（EnabledWithTranscript）で、この場合、開催者が作る会議の Copilot は「会議中および会議後」に固定され、開催者は変更できません。定例会議の運用には、この既定値がそのまま合います。 担当者が会議ごとに設定を選び間違える余地がなくなるからです。

更新案を作るのは、会議が終わった当日中にします。翌週まで持ち越すと次の会議と重なり、第3章の（d）と同じ遅れになります。

入力データを集める

質を決めるのは、下の2つです。 未完了の課題の一覧が無ければ、Copilot は発言をどの課題番号に結びつけてよいかが分かりません。参加者の所属が無ければ、話者の名前は分かってもそれが先方か当方かを判定できません。

「よく使われる呼び名」の列は、課題管理表に足します。 「Q-042 生産実績の月次集計帳票の改修」は、会議では「月次の帳票」「集計の件」と呼ばれます。会議での呼び名を2つか3つ書いておくと、課題番号が口頭で言われない発言を当てやすくなります。

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

文字起こしは、会議を開くだけで取れます。 管理者は Teams 管理センターの［会議］＞［会議ポリシー］で文字起こしをオンにし、PowerShell では Set-CsTeamsMeetingPolicy の -AllowTranscription パラメーターで管理します。

文字起こしは開催者ごとと、ユーザーごとのポリシー設定です。会議に文字起こしを含めるには開催者がこの設定をオンにしている必要があり、文字起こしを開始するユーザーも同じ設定がオンである必要があります。 担当者2名の両方にポリシーを割り当てておけば、どちらが主催しても始められます。

要件を満たしているかは、診断ツールで確かめられます。 Microsoft 365 管理センターで Teams トランスクリプト診断ツールを実行すると、ユーザーのアカウントが Teams 会議のトランスクリプトを作る要件を満たしているかを確認できます。

AIへ渡す前に整形する

1. 主催者の確認 … 定例会議の予定が自社側の主催になっているかを確かめます。委託先の招待で開かれていれば、Copilot は機能しません
2. 会議オプションの確認 … Copilot が「会議中および会議後」になっているかを確かめます
3. 暗号化の確認 … Copilot は、エンドツーエンドの暗号化された会議では使用できません。 定例会議にこの設定を使っていないかを確かめます
4. 未完了の課題の一覧を作る … 課題管理表をその会議体で絞り込み、状態が「完了」以外の行だけを抜き出します
5. 一覧をチャットに貼る … 会議の前日に、課題番号・件名・呼び名・担当・状態・期限の6列を貼ります
6. 参加者の所属を書く … 一覧の下に、参加者の氏名と所属（自社／A社／B社）を1行ずつ書きます

4番目で「完了」を外すのは、一覧を短くするためです。 80件前後の未完了のうち、1つの会議体で扱うのは20件から30件です。全件を貼ると、似た件名の課題に誤って当てる余地が増えます。 会議体ごとに絞るのが最も効きます。

AIに処理させる

させるのは、発言を5つの箱に分け、既存の課題番号と根拠の発言を添えることだけです。

右端の列が、この構成でいちばん大事な区別です。 当てられなかったものを無理に既存課題に寄せると、違う行の状態が変わり、それに気づくのは次の会議で話が食い違ったときです。 当てられないものは当てられないと出させます。

3行目がいちばん起きやすい失敗です。 「来週中にはお出しします」を渡すと、指示しなければ来週の金曜日の日付を期限の列に入れます。その瞬間、口約束が合意した期限に変わります。

指示内容を固定する

会議後に、会議チャットまたは【要約】タブの Copilot に送ります。

あなたは情報システム部門で、委託先との定例会議の課題管理表を更新する担当の補助です。
この会議の文字起こしと、会議チャットに貼った「未完了の課題の一覧」と「参加者の所属」だけを根拠にしてください。
推測で補わないでください。

【抜き出すもの】
A. 既存課題の状態変化（一覧の課題番号に結びつくもの）
B. 期限の変更
C. 新しい課題の候補（一覧のどの課題にも当たらないもの）
D. 宿題（先方＝委託先、当方＝自社 に分ける）
E. 課題番号を当てられなかった、課題に関わる発言

【課題番号の当て方】
- 一覧の課題番号・件名・呼び名と照らして当ててください。
- 当てはまる候補が2つ以上あるときは、1つに決めず「要確認」とし、候補の番号を並べてください。
- 課題番号を言っていない発言に、似た件名から番号を当てはめないでください。根拠が弱ければ E に入れてください。

【期限の扱い】
- 両者が具体的な日付に合意した発言だけを「確定」にしてください。
- 「来週中」「月末を目指す」「なるべく早く」は「目安」とし、日付に直さないでください。
- 期限を延ばすかどうかは判断しないでください。延長の提案があったという事実だけを書いてください。

【状態の扱い】
- 状態を「完了」とするのは、完了したと明言され、相手が了承した発言がある場合だけです。
- 「ほぼ終わりました」「あとは確認だけです」は「完了」にしないでください。

【宿題の担当】
- 参加者の所属から、先方か当方かを決めてください。
- 話者が分からない、または所属が一覧に無いときは「担当不明」としてください。

【各行に必ず付けるもの】
- 根拠にした発言の要旨と、そのタイムスタンプ
- 発言者の氏名

【出力】
次の表の形で返してください。表の外に説明を書かないでください。
区分｜課題番号｜件名｜変更する列｜変更前｜変更後｜期限の確度｜担当｜根拠の発言（要旨）｜タイムスタンプ｜発言者｜判定

「似た件名から番号を当てはめない」を明記しないと、当ててしまいます。 一覧に「月次集計帳票」と「月次締め処理」があれば、「月次の件」という発言をどちらかに寄せて自信ありげに返します。禁じるのは、根拠の弱い結びつけそのものです。

「完了」の条件を書いているのも同じ理由です。 委託先は定例会議で進みを前向きに話すので、「ほぼ終わりました」を完了として拾うと、表の上では閉じた課題が翌週また開きます。

出力形式を固定する

Copilot には、次の12列の表で返させます。 課題管理表の列にそのまま写せる形にするためです。

本格構成で Power Automate に渡すときは、承認済みの行を次の形のJSONにします。

{
  "meeting": { "series": "移行作業の定例", "date": "2026-09-28" },
  "updates": [
    {
      "category": "status_change | due_change | new_candidate | action | unmatched",
      "issue_no": "Q-042",
      "field": "status | due | owner | history",
      "before": "",
      "after": "",
      "due_certainty": "confirmed | tentative | null",
      "owner_side": "vendor | own | unknown",
      "evidence": "",
      "timestamp": "",
      "speaker": "",
      "judgement": "apply | needs_review",
      "approved_by": ""
    }
  ]
}

1つ目の理由は、「変更前」を必ず書かせることです。 変更前の値が一覧と違っていれば、Copilot が違う課題を見ているか、一覧が古いかのどちらかです。 反映する前に気づけます。

2つ目は、期限の確度 を独立した列にしていることです。 目安 の行は期限の列を直さず、経緯のメモに「9月末を目指すとの発言（目安）」と書きます。確定と目安を同じ列に入れないことが、表を合意の記録として保つ条件です。

システムへ連携する

半自動化の段階では、課題管理表への書き込みはすべて人が行います。 Copilot が返した表を見ながら、承認した行を表に写します。書き込みを自動にすると、要確認 の行の見落としがそのまま表に入ります。

議事録と表のリンクを関係者に送る作業は残します。送る前に、更新した行だけを一覧にして添えると、委託先が自分の宿題を見落としにくくなります。

人が確認する

人が見るのは、更新案の全行です。ただし、文字起こしまで戻るのは一部の行だけです。

1. 要確認 の行を先に見る … 課題番号の候補が複数あるもの。タイムスタンプの位置の発言を読み、どの課題かを決めます
2. 状態変化 で「完了」になった行を必ず確かめる … 完了を相手が了承した発言があるかを、文字起こしで見ます
3. 期限変更 の 確定 を確かめる … 日付に双方が合意したかを見ます。合意が曖昧なら 目安 に落とします
4. 担当不明 を埋める … 話者の所属を確かめて、先方か当方かを決めます
5. 当てられない発言 を仕分ける … 新しい課題として起票するか、既存課題の経緯に足すか、捨てるかを決めます

2番目を省かないでください。 完了にした課題は、次の会議の一覧から消えます。誤って閉じた課題は、誰の目にも触れないまま期限を迎えます。

目標は、1回あたり30分です。 更新案が20行前後、そのうち文字起こしに戻るのが5行前後という想定です。戻る行が毎回10行を超えるなら、一覧の呼び名の列が足りていないか、会議で課題番号を言う習慣が無いかのどちらかです。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの問題ではなく、会議の開き方の問題です。 主催者、文字起こしの開始、参加のしかたを整えるほうが、プロンプトを直すより効きます。

記録を残す

• 会議ごとの文字起こし（レコーディングとともに OneDrive／SharePoint に保存される）
• 会議チャットに貼った未完了の課題の一覧（その時点の表の内容）
• Copilot が返した更新案の表
• 人が承認・修正・却下した記録 … どの行を、どう変えたか
• 課題管理表の変更履歴（変更前と変更後、変更した人、根拠の会議とタイムスタンプ）
• 当てられない発言 の件数の推移

2つ目で「その時点の一覧」を残すのは、表が毎週変わるためです。 後から更新案を見直すとき、当時の一覧が無いと、Copilot が正しく当てたのか、一覧が古かったのかが分かりません。

経緯の列には、根拠の会議の日付とタイムスタンプを書きます。 半年後に「なぜこの期限なのか」を聞かれたとき、表から文字起こしの位置へ直接戻れることが、引き継ぎの材料になります。