設計審査と技術検討会の記録から、決まったことと持ち越しを議事録にする
設計審査や技術検討会の会議の記録から、決まったこと・保留になったこと・次回への持ち越しを、決まった様式に沿って下書きします。担当者の作業は、録音を聞き直して書き起こすことから、下書きを直して確定させることに変わります。
- 生成AI
- ChatGPT/Claude/Gemini/Microsoft Copilot
- 連携・自動化
- Make/n8n/Power Automate
- 対象業界
- IT・SaaS/その他/医療/教育/製造
- 対象部門
- 研究開発
- 対象業務
- 書類作成/記録・議事録作成
- 主な課題
- 属人化している/書類作成に時間がかかる/期限・対応漏れが起きる
- AIで行う処理
- 要約
- 主な効果
- 品質標準化/属人化解消/工数削減
- 導入難易度
- ★★☆☆☆
- 実装レベル
- 半自動化
- 費用感
- 既存ツールのみ(小)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 会議の予定が決まり、審査の対象と資料が共有される
- 会議を開く(オンラインまたはハイブリッド)
- 担当者が会議中にメモを取る
- 会議後、録音または文字起こしを確かめる
- 議事録の様式に沿って書く
- 決まったこと、保留、持ち越しを分けて書く
- 担当と期限を確かめて書き足す
- 出席者へ回して確認を取る
- 確定した議事録を保管する
- 次回の会議で、前回の持ち越しを確認する(されないことがある)
- 会議の予定が決まり、審査の対象と資料が共有される
- 人会議を開く。文字起こしを有効にする
- 自動会議の終了を検知して処理が始まる
- 自動文字起こしと、会議に紐づく資料を読み込む
- 自動前回の持ち越し事項を読み込む
- 自動議事録の様式に沿って下書きする
- 自動決まったこと・保留・持ち越しを分ける
- 自動担当と期限が示されていない項目に印を付ける
- 自動前回の持ち越しについて、今回議論されたかを示す
- 人担当者が下書きを直し、抜けを埋める
- 人出席者へ回して確認を取り、確定する
- 自動持ち越し事項を、次回の資料へ引き継ぐ
各工程の詳しい説明を読む
- 会議の予定が決まり、審査の対象と資料が共有される
- 会議を開く(オンラインまたはハイブリッド)
- 担当者が会議中にメモを取る
- 会議後、録音または文字起こしを確かめる
- 議事録の様式に沿って書く
- 決まったこと、保留、持ち越しを分けて書く
- 担当と期限を確かめて書き足す
- 出席者へ回して確認を取る
- 確定した議事録を保管する
- 次回の会議で、前回の持ち越しを確認する(されないことがある)
問題は7つあります。
(a)録音を聞き直す時間がかかる。 60分の会議を確かめるのに、倍速で聞いても20〜30分かかります。
(b)書く人によって粒度が違う。 「対応する」で終わる議事録と、誰が何をいつまでにするかまで書く議事録があります。
(c)決まったことと保留の区別が曖昧。 会議の場で「では、その方向で」と言われたことが、決定なのか方針の確認なのかが分かりません。
(d)担当と期限が抜ける。 「確認しておきます」と誰かが言ったが、誰がいつまでかが記録されません。
(e)持ち越しが追われない。 前回の持ち越しを次回の資料に載せる運用が、担当者の記憶に頼っています。
(f)認証の要求に沿った項目が抜ける。 DRでは、審査の対象、参加者、結果、指摘と対応を残す必要があります。急いで書くと項目が抜けます。
(g)確認の往復に日数がかかる。 出席者へ回して確認を取るのに、3〜5日かかります。 その間、持ち越しの対応が始まりません。
- 会議の予定が決まり、審査の対象と資料が共有される
- 【人】 会議を開く。文字起こしを有効にする
- 【自動】 会議の終了を検知して処理が始まる
- 【自動】 文字起こしと、会議に紐づく資料を読み込む
- 【自動】 前回の持ち越し事項を読み込む
- 【自動】 議事録の様式に沿って下書きする
- 【自動】 決まったこと・保留・持ち越しを分ける
- 【自動】 担当と期限が示されていない項目に印を付ける
- 【自動】 前回の持ち越しについて、今回議論されたかを示す
- 【人】 担当者が下書きを直し、抜けを埋める
- 【人】 出席者へ回して確認を取り、確定する
- 【自動】 持ち越し事項を、次回の資料へ引き継ぐ
自動化されるのは「記録の読み込み」「様式への整形」「区分の仕分け」「抜けの検出」「前回との突合」の5つです。残るのは、下書きの確認と、抜けを埋めることです。
設計の判断はしません。 設計が要求を満たすか、次の段階へ進めてよいかは、審査に出た人が判断します。この構成が書くのは、そこで何が決まったかの記録です。
議事録を確定させません。 下書きを作るところまでです。確定は、出席者の確認を経て担当者が行います。
発言の要約に丸めすぎないでください。 「懸念が示された」ではなく、誰がどういう懸念を示したかを残す必要があります。設計審査の記録は、後から経緯を辿るためのものです。
「前回の持ち越しとの突合」が、この構成で新しく生まれる価値です。 現状は担当者の記憶に頼っています。
02今回想定するシステム構成
会議(Teams。文字起こしを有効にする) │ ▼ 文字起こしが会議の記録とともに保存される │ ▼【トリガー】会議の終了を検知 Power Automate │ ├──▶ 会議の情報を取得(件名、日時、出席者) ├──▶ 会議に紐づく資料を取得(SharePoint) ├──▶ 前回の持ち越し事項を取得 ├──▶ 議事録の様式を読み込む │ ▼ Microsoft 365 Copilot │ ・文字起こしと資料から、様式に沿って下書き │ ・決まったこと / 保留 / 持ち越しを分ける │ ・担当と期限が示されていない項目に印を付ける │ ・前回の持ち越しが議論されたかを突き合わせる │ ・組織のデータへのアクセスは利用者の権限に従う │ ▼ 議事録の下書き(Word / SharePoint) │ ▼ 担当者が直して抜けを埋める ──【人】 │ ▼ 出席者の確認 ──【人】 │ ▼ 確定・保管(設計管理システム) │ ▼ 持ち越し事項を次回の資料へ引き継ぐ
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 生成AI | Microsoft 365 Copilot | Claude API、OpenAI API、Gemini API |
| 連携 | Power Automate | Make、n8n |
| 会議と文字起こし | Microsoft Teams | Google Meet、Zoom |
| 保管 | SharePoint | Box、Google ドライブ |
| 設計管理 | 既存の設計管理システム | 各社の製品 |
設計管理システムに議事録の機能があるなら、まずそちらを確認してください。 様式が固定され、持ち越しの管理まで入っている製品があります。自前で組む価値があるのは、文字起こしから下書きを作る部分です。
Microsoft 365 Copilot を選ぶ理由は、会議の記録と資料が同じ場所にあることです。 文字起こしは会議の記録とともに保存され、資料は SharePoint にあります。別の場所へコピーする作業が要りません。
Copilot の応答は、利用者の権限の範囲に限られます。 公開されている説明では、「利用者の権限に応じたアクセス(セキュリティとコンプライアンスが適用される)」とされています。見てはいけない資料が議事録に混ざることはありません。
Microsoft 365 Copilot(Premium)では、組織のデータに Microsoft Graph と Work IQ を通じて自動でアクセスします。 メール、ファイル、会議、予定、チーム、組織の関係が対象です。Copilot Chat(Basic)と Microsoft 365 Copilot(Basic)では、ファイルを添えるか、開いている内容を使う形になります。
Teams では、会議の要約(過去30日まで)と文字起こし、対応事項の抽出ができるとされています。 この30日という範囲は、古い会議を後から処理する場合の制約になります。
文字起こしには管理者の設定が要ります。 Teams 管理センターの「会議」→「会議ポリシー」で、「文字起こし」をオンまたはオフに切り替えます。この設定は新しいポリシーでは既定でオンです。会議や催しに文字起こしを含めるには、主催者がこの設定をオンにしている必要があり、録画や文字起こしを開始する利用者もオンになっている必要があります。
文字起こしは会議の記録とともに OneDrive と SharePoint に保存されます。 保存の場所と期限は、組織の設定によります。
組織の主催者が Teams 会議で Microsoft Copilot をオフにすると、録画と文字起こしもオフになります。 この点に注意してください。
03どうやって実装するのか
処理の起点を決める
会議の終了を検知したときを起点にします。
すべての会議を対象にしないでください。 雑談や日程調整の会議まで議事録が作られると、下書きが大量に生まれて確認されなくなります。
対象を絞る方法を決めてください。
| 方法 | 内容 |
|---|---|
| 会議の件名の規則 | 「DR_」「技術検討_」で始まる会議だけ |
| 予定表の分類 | 特定の分類を付けた会議だけ |
| 主催者 | 開発管理部のメンバーが主催した会議だけ |
| 明示的な依頼 | 会議後に担当者が依頼する |
件名の規則を推奨します。 会議を設定するときに接頭辞を付けるだけで、運用の負担がほとんどありません。
文字起こしがあることを確かめてから処理してください。 文字起こしがオフのまま開かれた会議では、下書きが作れません。 その旨を担当者へ知らせる形にしてください。
もう1つの起点として、次回の会議の準備があります。 会議の3営業日前に、前回の持ち越し事項を資料へ載せる形で通知します。 ここが現状できていない部分です。
月次のトリガーも置きます。 期限を過ぎた持ち越し事項を一覧にします。対応漏れを防ぐ仕組みです。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 会議の文字起こし | 発言の記録、話者、時刻 | Teams(会議の記録とともに保存) |
| 会議の情報 | 件名、日時、出席者、主催者 | 予定表 |
| 会議の資料 | 審査の対象の資料、図面、試験結果 | SharePoint |
| 議事録の様式 | 記録すべき項目と、書き方 | 開発管理部の文書 |
| 前回の持ち越し | 前回の会議で持ち越した事項と期限 | 記録 |
| 会議の種類 | DR/技術検討会/仕様確認会 など | 会議の件名または分類 |
| 審査の段階 | DR1(企画)/DR2(基本設計)/DR3(詳細設計)ほか | 設計管理システム |
データの取得方法を決める
議事録の様式が、この構成の質を決めます。 会議の種類ごとに、記録すべき項目を定めてください。
| 項目 | DR | 技術検討会 | 書き方 |
|---|---|---|---|
| 会議の名称・日時・場所 | 必須 | 必須 | |
| 出席者と役割 | 必須 | 必須 | DRでは審査員の氏名と所属が要る |
| 審査の対象 | 必須 | 任意 | 製品名、図面番号、版数 |
| 審査の基準 | 必須 | 不要 | 参照した規格・要求仕様 |
| 決まったこと | 必須 | 必須 | 「誰が」「何を」が分かる形で |
| 指摘事項 | 必須 | 任意 | 指摘の内容と、その根拠 |
| 対応の方針 | 必須 | 任意 | 誰が、何を、いつまでに |
| 保留 | 必須 | 必須 | 決まらなかった理由 |
| 次回への持ち越し | 必須 | 必須 | 期限と担当 |
| 審査の結果 | 必須 | 不要 | 合格/条件付き合格/再審査 |
「決まったこと」と「保留」を分ける基準も明文化してください。
| 区分 | 基準 |
|---|---|
| 決まったこと | 会議の場で結論が出て、異論がなかった事項 |
| 条件付きで決まったこと | 結論は出たが、条件がついている |
| 保留 | 情報が足りず、結論を出さなかった事項 |
| 持ち越し | 次回までに誰かが何かをする必要がある事項 |
「条件付き」の区分を必ず入れてください。 設計審査では「この試験の結果が出れば進めてよい」という決着がよくあります。これを「決まったこと」に入れると、条件が抜けます。
前回の持ち越し: 次の形で記録します。
| 列 | 中身 |
|---|---|
| 会議ID / 会議の種類 | |
| 持ち越しの内容 | |
| 担当 | 氏名または部署 |
| 期限 | |
| 関連する審査の対象 | 製品名、図面番号 |
| 状況 | 未着手/対応中/完了/次回へ再持ち越し |
「関連する審査の対象」の列が要ります。 同じ製品の次のDRで、前回の持ち越しを引き継げます。
AIへ渡す前に整形する
- 会議の種類の判定 … 件名または分類から、DRか技術検討会かを決めます。様式が変わります
- 文字起こしの有無の確認 … なければ処理を止めて、担当者へ知らせます
- 話者の対応づけ … 文字起こしの話者名と、出席者の一覧を対応づけます。役割(審査員/説明者)も付けます
- 資料の取得 … 会議に添付された資料を取ります。図面や試験結果は、参照した事実だけを記録します
- 前回の持ち越しの取得 … 同じ審査の対象について、前回の持ち越しを取ります
- 審査の段階の特定 … DRの何番目かを設計管理システムから取ります
- 未公開の技術情報の確認 … 出願前の発明が議論されている場合、扱いを決めます
3の話者の対応づけが、DRの議事録では重要です。 誰が指摘したかを残す必要があります。「審査員のAさんから指摘」という形で書けるようにしてください。
4で資料の中身を議事録に転記しないでください。 「図面 XX-001 rev.3 を参照」と書けば足ります。図面の内容を議事録に書き写すと、版の管理が二重になります。
AIに処理させる
| 処理 | 内容 |
|---|---|
| 様式への整形 | 会議の種類に応じた項目に沿って下書き |
| 区分の仕分け | 決まったこと/条件付き/保留/持ち越し |
| 発言の帰属 | 誰が何を言ったか(指摘事項では必須) |
| 担当と期限の抽出 | 「〜さんが」「〜までに」を拾う |
| 抜けの検出 | 担当や期限が示されていない項目 |
| 前回の持ち越しとの突合 | 今回議論されたか |
設計の妥当性を判断させません。 「この設計は要求を満たしています」といった記述を出させないでください。判断は審査に出た人が行います。
審査の結果も決めさせません。 「合格」「再審査」の判定は、審査の場で決まったことを記録するだけです。会議で明示されなかった場合、空欄にして人が確かめてください。
技術的な評価もさせません。 「この方式のほうが優れています」といった記述を禁じてください。
発言の要約に丸めすぎないでください。 「懸念が示された」だけでは、後から経緯を辿れません。どういう懸念かを残してください。
指示内容を固定する
Microsoft 365 Copilot では、エージェントの指示として次の内容を設定します。
あなたは開発管理部で設計審査の議事録を作る担当者です。
会議の文字起こしから、決まった様式に沿って議事録を下書きすることが役割です。
【厳守事項】
- 設計の妥当性を判断しないでください。
「この設計は要求を満たしています」「この方式が適切です」と書かないでください。
**判断は審査に出た人が行います。**
- 審査の結果を決めないでください。
「合格」「条件付き合格」「再審査」は、会議で明示されたときだけ書いてください。
明示されなかった場合は空欄にし、「会議で明示されませんでした」と注記してください。
- 技術的な評価をしないでください。
「この方式のほうが優れています」「リスクが高い」と書かないでください。
- 文字起こしにない内容を補わないでください。
一般的な設計審査の進め方で埋めないでください。
- 指摘事項については、誰が指摘したかを必ず書いてください。
話者が特定できない場合は「発言者不明」と書いてください。
- 発言を丸めすぎないでください。
「懸念が示された」ではなく、どういう懸念かを残してください。
**後から経緯を辿るための記録です。**
- 決まったこと・条件付きで決まったこと・保留・持ち越しを、
下の「区分の基準」に照らして分けてください。
迷った場合は「保留」にしてください。
**決まっていないことを「決まった」と書くほうが危険です。**
- 担当と期限が会議で示されていない項目には、
「担当未定」「期限未定」と明記してください。
推測で担当や期限を書かないでください。
- 下の「前回の持ち越し」について、今回の会議で議論されたかを
1件ずつ確かめてください。
議論されていない場合は「今回は議論されませんでした」と書いてください。
- 資料の内容を議事録に転記しないでください。
「図面 XX-001 rev.3 を参照」のように、参照した事実を書いてください。
- 出席者の発言の巧拙を評価しないでください。
「説明が不十分でした」と書かないでください。
【会議の種類】
{meeting_type}
【会議の情報(件名 / 日時 / 出席者と役割)】
{meeting_info}
【議事録の様式(項目 / 必須か / 書き方)】
{minutes_template}
【区分の基準(決まったこと / 条件付き / 保留 / 持ち越し)】
{classification_rules}
【前回の持ち越し(内容 / 担当 / 期限 / 状況)】
{prior_carryovers}
【会議に紐づく資料の一覧(名称と版数のみ)】
{document_list}
「迷った場合は保留にする」の指示が、この構成でもっとも重要です。 決まっていないことを「決まった」と記録すると、後で「合意したはずだ」という認識の食い違いが起きます。 保留と書かれていれば、確認の過程で直せます。
「担当未定」「期限未定」と明記させる指示も外せません。 空欄にすると、書き忘れなのか、会議で決まらなかったのかが分かりません。 明記されていれば、確認の場で埋められます。
「発言を丸めすぎない」の指示は、設計審査の記録の性質から来ています。 「安全性について懸念が示された」だけでは、後から見て何が問題だったか分かりません。 「電池の発熱について、連続使用時の温度上昇の試験が不足しているとの指摘」まで残す必要があります。
「誰が指摘したか」を書かせる指示も、DRでは必須です。 審査員の指摘と、説明者の補足は別のものです。
出力形式を固定する
議事録は Word の文書として出しますが、内部では次の構造で持ちます。
{
"meeting_id": "",
"meeting_type": "DR | tech_review | spec_review | test_plan",
"dr_stage": "",
"held_at": "",
"attendees": [
{ "name": "", "department": "", "role": "reviewer | presenter | observer" }
],
"review_target": { "product": "", "documents": [] },
"review_criteria": [],
"decisions": [
{ "item": "", "content": "", "conditions": "", "type": "decided | conditional" }
],
"findings": [
{
"raised_by": "",
"content": "",
"basis": "",
"response_plan": "",
"owner": "",
"due_date": "",
"owner_missing": false,
"due_missing": false
}
],
"pending": [
{ "item": "", "reason_not_decided": "" }
],
"carryovers": [
{ "item": "", "owner": "", "due_date": "", "owner_missing": false, "due_missing": false }
],
"prior_carryover_status": [
{ "item": "", "discussed": false, "outcome": "" }
],
"review_result": "passed | conditional | re_review | not_stated",
"unattributed_statements": [],
"transcript_quality_note": ""
}
type で「決まったこと」と「条件付き」を分けていることが、この構成の核です。 設計審査では条件付きの決着が多くあります。条件を落とすと、後から問題になります。
owner_missing と due_missing のフラグが要ります。 担当や期限が会議で示されなかった項目を、確認の場で埋めるための印です。
prior_carryover_status に discussed を持たせている理由があります。 前回の持ち越しが今回議論されなかったことを、記録として残すためです。議論されなかったこと自体が、追跡すべき事実です。
review_result に not_stated を入れてください。 会議で審査の結果が明示されないことがあります。空欄にせず、明示されなかったことを記録します。
unattributed_statements は、話者が特定できなかった発言です。 文字起こしで話者の識別が外れることがあります。担当者が確認する対象になります。
transcript_quality_note は、文字起こしの品質の問題です。 対面の出席者の声が拾えていない、専門用語の変換が誤っている。この注記があると、担当者が念入りに確かめる判断ができます。
システムへ連携する
下書きを作るだけで、確定と保管は人が行います。
| 出力先 | 内容 |
|---|---|
| Word(SharePoint) | 議事録の下書き |
| Teams | 下書きができたことの通知 |
| SharePoint リスト | 持ち越し事項の記録 |
| 設計管理システム | 担当者が確定してから登録 |
設計管理システムへ自動で登録しないでください。 設計審査の記録は、認証や監査で参照されます。確認を経ていない下書きが正式な記録として残ると、後から問題になります。
出席者への確認は、これまでどおり人が行ってください。 下書きを自動で回すと、誤りがあるまま「確認済み」になる恐れがあります。
持ち越し事項の記録は自動で構いません。 議事録が確定した時点で、持ち越しをリストへ追加します。次回の会議の3営業日前に、そのリストから資料を作ります。
期限を過ぎた持ち越しの通知も自動で構いません。 月次で、期限を過ぎて未完了の項目を担当へ知らせます。ただし、催促の文面は定型にとどめ、責める書き方にしないでください。
人が確認する
担当者の確認は必ず残します。
| 見る点 | 判断 |
|---|---|
owner_missing / due_missing | 会議の記憶が新しいうちに埋める |
type が conditional の項目 | 条件が正しく書けているか。ここが落ちやすい |
pending の項目 | 本当に保留か、決まっていたのに拾えていないか |
review_result が not_stated | 審査の結果を確かめる |
unattributed_statements | 誰の発言かを確かめる |
prior_carryover_status | 議論されなかった項目をどうするか |
transcript_quality_note | 文字起こしに問題があれば念入りに確かめる |
確認を速くするための設計が効きます。
owner_missing/due_missingの項目を先頭に集める- 文字起こしの該当箇所へのリンクを付ける
- 前回の持ち越しを併記する
conditionalの項目を目立たせる- 確認の完了をその場で記録できるようにする
2つ目が効きます。 「この記述は本当にそう言われたか」を確かめるとき、文字起こしの該当箇所へすぐ飛べると、確認が速くなります。
出席者への確認は省かないでください。 議事録は、後から「そう決まった」ことの根拠になります。下書きの精度がどれだけ上がっても、出席者の確認は残してください。
月次で、持ち越しの状況を見てください。
| 見るもの | 判断 |
|---|---|
| 期限を過ぎた持ち越しの件数 | 増えているなら、期限の設定が甘い |
| 「次回へ再持ち越し」の件数 | 2回以上繰り返しているものは、別の対応が要る |
| 「今回は議論されなかった」の件数 | 次回の資料への引き継ぎが機能していない |
owner_missing の割合 | 会議の進め方に改善の余地がある |
最後の項目が、実は会議そのものの改善につながります。 担当が決まらないまま終わる項目が多いなら、会議の進行で「誰がやりますか」を確認する運用に変えるほうが効きます。
例外に対処する
| 起きること | 対応 |
|---|---|
| 文字起こしがオフのまま会議が行われた | 下書きが作れない。担当者へ知らせる |
| 対面の出席者の声が拾えていない | transcript_quality_note に出す。念入りに確かめる |
| 話者が特定できない | unattributed_statements に出す |
| 専門用語が誤って変換されている | 用語の対応表で置き換える。残りは人が直す |
| 審査の結果が会議で明示されない | not_stated として記録する。推測しない |
| 担当や期限が決まらなかった | owner_missing / due_missing を立てる |
| 会議が予定より長引いて複数に分かれた | 同じ会議IDで扱う。別々の議事録にしない |
| 30日を超えた古い会議 | 会議の要約は過去30日までの範囲。それ以前は文字起こしから直接処理する |
| Copilot がオフにされている会議 | 録画と文字起こしもオフになる。事前に確認する |
| 出願前の発明が議論された | 扱いを知財部と決める。対象から外す選択もある |
| 資料の内容が議事録に転記される | 参照の事実だけを書く指示を入れる |
| AIが設計の妥当性を判断した | 指示で禁止する。テストで必ず確認する |
| AIが審査の結果を決めた | 禁止する。会議で明示されたときだけ |
| 発言が丸められすぎる | 指示で禁止する。経緯が辿れなくなる |
| 設計管理システムへ自動登録される | 行わない。確認を経ていない記録が残る |
「Copilot がオフにされている会議」は、見落としやすい点です。 主催者が Teams 会議で Microsoft Copilot をオフにすると、録画と文字起こしもオフになります。 機微な議論のためにオフにした会議では、この構成は使えません。事前に確認する運用にしてください。
記録を残す
この記録は、設計管理の証跡になります。
- 会議の文字起こし(保存の場所と期限は組織の設定による)
- 議事録の下書きと、担当者が直した後の内容
- 出席者の確認と、修正の内容
- 確定した議事録
- 持ち越し事項と、その後の状況
owner_missing/due_missingの割合の推移- 文字起こしの品質の問題の記録
「下書きと直した後の内容」を両方残してください。 どこが直されているかが、この構成の改善点そのものです。「条件付き」の条件が毎回書き足されているなら、指示を強める必要があります。
設計審査の記録は、認証や監査で参照されます。 医療機器や自動車の分野では、設計管理の記録の保存が求められます。この構成が作るのは下書きであり、正式な記録は確定した議事録です。 その区別を、保管の場所でも分けてください。
文字起こしの保存期間に注意が要ります。 文字起こしは会議の記録とともに OneDrive と SharePoint に保存されます。保存の場所と期限は組織の設定によるため、設計審査の記録として必要な期間、残るかを確かめてください。
会議の内容には、未公開の技術情報が含まれます。 出願前の発明、試験の結果、仕様の詳細。閲覧範囲を、その開発テーマに関わる人へ限定してください。
Copilot の応答は利用者の権限の範囲に限られます が、議事録として保存された文書は、その保存場所の権限に従います。 権限の設計を確かめてください。
04実装レベルの3段階
半自動化の時点で、45分が25分程度になります。 録音を聞き直して書き起こす作業が消えるためです。本格構成では15分になりますが、減るのは持ち越しを探して引き継ぐ作業です。 本格構成の「次回への引き継ぎ」を、必ず入れてください。 現状できていないことです。持ち越しが次回の資料に載る状態になることが、この構成のいちばんの価値です。 「期限の通知」も入れてください。 期限を過ぎた持ち越しを月次で知らせます。対応漏れを防ぐ仕組みです。 段階を飛ばさないでください。 区分の基準が曖昧なまま自動化すると、「決まったこと」と「保留」が混ざった議事録が量産されます。 最小構成で基準を固めてから進んでください。 会議の種類も段階的に広げてください。 まず技術検討会、次にDR。DRは認証の要求に関わるため、様式の確認に時間をかけてください。
05工数削減シミュレーション
導入後 70件 × 15分 ÷ 60 = 17.5 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 設計審査や技術検討会を月に50回以上開いていて、議事録を担当者が手で書いている企業。記録すべき項目が決まっているのに、書く人によって粒度が違う場合。持ち越しになった検討事項が、次回まで追われていない場合。会議がオンラインまたはハイブリッドで、文字起こしが取れる環境がある場合。
- 設計審査が年に数回の企業。会議が対面のみで、録音や文字起こしが取れない場合。議事録の様式が定まっておらず、何を書くかが決まっていない場合。設計審査の記録に法令や認証上の要求があり、決まった様式でしか残せない場合(この構成は下書きまでです)。
07最小構成で試す方法
- 会議の種類を1つ選ぶ(件数の多い技術検討会)
- その種類の議事録の様式を、項目と書き方付きで整える
- 区分の基準(決まったこと/条件付き/保留/持ち越し)を明文化する
- 過去の会議5回分の文字起こしと、担当者が書いた議事録を用意する
- 生成AIに文字起こしと様式を渡して、下書きを作らせる
- 担当者が書いた議事録と突き合わせる
見るのは次の5点です。
| 見る点 | 判断 |
|---|---|
| 設計の妥当性の判断・技術的な評価が混ざっていないか | 1件でも混ざったら指示を直す |
| 「決まったこと」と「保留」の区別が正しいか | 決まっていないことを「決まった」にしていないか |
| 条件付きの条件が落ちていないか | ここがいちばん落ちやすい |
| 指摘の帰属(誰が指摘したか)が書けているか | DRでは必須 |
| 発言が丸められすぎていないか | 経緯が辿れる粒度か |
2つ目を最優先で確かめてください。 決まっていないことを「決まった」と記録すると、後から認識の食い違いが起きます。 5回分すべてについて、担当者が「保留」とした項目が下書きでも保留になっているかを見てください。
3つ目も落ちやすい部分です。 「試験の結果が出れば進めてよい」という決着で、条件が抜けて「進めてよい」だけが残ると、記録として誤りになります。
次に、文字起こしの品質を確かめてください。 ハイブリッドの会議では、会議室にいる人の声が拾えていないことがあります。専門用語の変換も確かめてください。 「バリ取り」「公差」「呼び径」といった語が正しく変換されているかを見ます。
DRの様式は、最小構成では扱わなくて構いません。 認証の要求に関わる項目があるため、技術検討会で手応えを確かめてから、DRへ広げてください。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| AIが設計の妥当性を判断する | 禁止する。テストで必ず確認する |
| AIが審査の結果を決める | 会議で明示されたときだけ。not_stated を用意する |
| 「決まった」と「保留」が混ざる | 区分の基準を明文化する。迷ったら保留 |
| 条件付きの条件が落ちる | type を分ける。確認の対象に上げる |
| 発言が丸められすぎる | 指示で禁止する。経緯が辿れる粒度に |
| 指摘の帰属が書かれない | 話者の対応づけを前処理で行う |
| 文字起こしがオフのまま会議が行われる | 事前に確認する。なければ下書きが作れない |
| Copilot をオフにすると文字起こしも止まる | 事前に周知する |
| 対面の出席者の声が拾えない | transcript_quality_note に出す |
| 専門用語が誤変換される | 用語の対応表で置き換える |
| すべての会議が対象になる | 件名の規則で絞る |
| 30日を超えた会議を処理しようとする | 会議の要約は過去30日まで。文字起こしから直接処理する |
| 設計管理システムへ自動登録する | 行わない。確認を経ていない記録が残る |
| 持ち越しが次回に引き継がれない | 会議の3営業日前に自動で資料へ載せる |
| 担当・期限の未定が空欄になる | 「未定」と明記させる |
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 会議の文字起こし、設計の資料、指摘事項、出席者の氏名。未公開の技術情報が含まれます。
- 未公開の技術情報 … 設計審査では、出願前の発明や未公開の仕様が議論されます。知財部と扱いを確認してください。 特定の会議を対象から外す判断もありえます
- 権限の範囲 … Microsoft 365 Copilot の応答は、利用者の権限に応じた範囲に限られます(セキュリティとコンプライアンスが適用されます)。ただし、議事録として保存された文書は、その保存場所の権限に従います。 保存先の権限設計を確かめてください
- 文字起こしの管理 … 文字起こしは Teams 管理センターの会議ポリシーで制御します。新しいポリシーでは既定でオンです。 機微な議論を行う会議では、オフにする判断もありえます
- Copilot と文字起こしの連動 … 主催者が Teams 会議で Microsoft Copilot をオフにすると、録画と文字起こしもオフになります。 この動きを、会議の運営者へ周知してください
- 文字起こしの保存 … 文字起こしは会議の記録とともに OneDrive と SharePoint に保存されます。保存の場所と期限は組織の設定によります。 設計審査の記録として必要な期間、残るかを確かめてください
- 出席者への周知 … 会議が文字起こしされ、AIが議事録を作ることを、出席者へ事前に伝えてください。後から知られるより、先に伝えるほうが信頼を保てます
- 設計の判断との分離 … この構成は設計の妥当性を判断しません。 審査の判断は、審査に出た人が行います。議事録の下書きにその旨を明記してください
- 正式な記録との区別 … この構成が作るのは下書きです。 正式な記録は、出席者の確認を経て確定した議事録です。保管の場所を分け、下書きが正式な記録として扱われないようにしてください
- 設計管理の要求 … 医療機器や自動車の分野では、設計審査の記録の内容と保存に要求があります。この構成が様式を満たしているかを、品質保証部門と確認してください
- 発言者の記録 … 誰が何を発言したかを残すことは、設計審査の記録として必要です。ただし、発言の巧拙を評価する記述を残さないでください
- 自動実行してよい範囲 … 文字起こしの読み込み、様式への整形、区分の仕分け、抜けの検出、前回との突合までです。議事録の確定、設計の判断、審査の結果の決定、正式な記録への登録は人が行います
誤りが起きた場合のリスクは、決まっていないことが「決まった」と記録されること、そして条件付きの条件が落ちることです。どちらも後から認識の食い違いを生みます。 「迷ったら保留」の指示と、出席者の確認を、省かないでください。
10まず何から始めるか
1週目:議事録の様式を項目と書き方付きで整える
技術検討会の様式から始めます。項目ごとに「どう書くか」を1文で書いてください。 「決まったこと:誰が何をするかが分かる形で」といった形です。
2週目:区分の基準を明文化する
「決まったこと」「条件付きで決まったこと」「保留」「持ち越し」の4区分の基準を書きます。過去の議事録から、区別が曖昧だった例を5件挙げて、どう分けるべきかを決めてください。
3週目:5回分で下書きを試す
過去の会議の文字起こしから下書きを作らせ、担当者が書いた議事録と比べます。「決まった」と「保留」の区別が正しいかを、1件ずつ確かめてください。 条件付きの条件が落ちていないかも見ます。
4週目:文字起こしの品質を確かめる
ハイブリッドの会議で、会議室の出席者の声が拾えているかを確かめます。専門用語の誤変換も集めて、対応表を作ってください。
2か月目: 技術検討会で半自動化を回します。設計管理システムへの自動登録は入れないでください。 出席者の確認は、これまでどおり残します。
3か月目以降: DRへ広げ、前回の持ち越しとの突合と、次回への引き継ぎを足します。DRの様式は、品質保証部門と確認してから使ってください。 認証の要求に関わります。
半年後: 出席者の確認にかかる日数を、導入前と比べてください。3〜5日が1〜2日に縮んでいれば、下書きの質が十分です。 同時に、期限を過ぎた持ち越しの件数を見てください。引き継ぎが機能していれば、ここが減ります。
1年後には、下書きと直した後の差が資産になります。 どの項目が毎回直されているかが分かれば、指示を直せます。 さらに、owner_missing の割合が高いなら、会議の進行そのもの(「誰がやりますか」を確認する)を変えるほうが効きます。 議事録を速く作ることより、会議で決めるべきことが決まる状態を作るほうが根本的です。その材料が集まることが、この構成のいちばん長く残る成果です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
| Microsoft Copilot の各体験が大規模言語モデル、Web および組織のデータ(Microsoft Graph と Work IQ)への接地、利用者の権限に応じたアクセス(セキュリティとコンプライアンスが適用される)で成り立つこと。Microsoft 365 Copilot(Premium)は組織のデータ(メール、ファイル、会議、予定、チーム、組織の関係)に Microsoft Graph・Work IQ・Copilot Search・セマンティックインデックスを通じて自動でアクセスし、Copilot Chat(Basic)と Microsoft 365 Copilot(Basic)ではファイルを添えるか開いている内容を使う必要があること。Teams では会議の要約(過去30日まで)と文字起こし、対応事項の抽出ができること。すべての体験が Enterprise Data Protection で保護されること | Microsoft Learn: What is Microsoft Copilot? | 2026-09-28 |
| Teams の文字起こしが Teams 管理センターの「会議」→「会議ポリシー」で切り替えられ、新しいポリシーでは既定でオンであること。会議や催しに文字起こしを含めるには主催者がこの設定をオンにしている必要があり、録画や文字起こしを開始する利用者もオンになっている必要があること。文字起こしは会議の記録とともに OneDrive と SharePoint に保存されること。主催者が Teams 会議で Microsoft Copilot をオフにすると録画と文字起こしもオフになること。ライブキャプションは保存されないこと | Microsoft Learn: Manage transcription and captions for Teams meetings | 2026-09-28 |
| Power Automate のクラウドフローが、自動・インスタント(手動)・スケジュールの3種類の起動の仕方を持つこと。自動フローはイベントの発生後に処理を行い、スケジュールのフローは日時と頻度を指定して実行できること | Microsoft Learn: Triggers - Power Automate | 2026-09-28 |
設計審査の様式、記録すべき項目、保存期間は、業種と適用される規格・認証によって異なります。この部分は自社の開発部門および品質保証部門の定めに応じた個別対応が必要です。 医療機器・自動車などの分野では、設計管理の記録の内容と保存に法令や規格上の要求があります。この記事はその要求を満たすことを保証するものではありません。設計の妥当性、審査の結果の判断は、審査に出席した人が行ってください。会議の文字起こしと未公開の技術情報を外部のAIサービスへ渡してよいかは、自社の知財部門と情報管理の責任者の判断が必要です。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-0281)についてのご相談はこちらから。
