ケーススタディ2:会議アジェンダ→議事録→意思決定ログ
このケースでは、部門横断の週次会議を「共有の場」で終わらせず、意思決定と次アクションが残る会議運用へ変換します。AIは、アジェンダ案、議事録テンプレート、意思決定ログのたたき台作成に使います。ただし、発言の意図、決定の妥当性、参加者の合意、機密情報の扱いは人間が確認します。
標準手順は AI活用の標準業務フロー(1枚) を参照してください。
1. ケースの前提
1.1 目的 / 読み手 / 意思決定点 / 機密区分
| 項目 | 内容 |
|---|---|
| 目的 | 部門横断の週次会議で、来週の優先度、担当、期限、未決事項を確定し、会議後に再利用できる意思決定ログを残す |
| 読み手 | 会議参加者、欠席した関係者、施策オーナー、次回会議の進行役 |
| 意思決定点 | 来週の優先度上位3件、各タスクの担当と期限、未決事項の確認責任者を決める |
| 機密区分 | 社内限定。個人評価、顧客名、契約条件、障害の詳細ログ、未公開の商談情報はAIへ入力しない |
| 成果物 | 会議アジェンダ、議事録、意思決定ログ、action / follow-up tracker |
| 最終判断者 | 会議体オーナー。AI出力は整理素材であり、決定確定と参加者合意は人間が行う |
このケースで使う名前、日付、タスク、影響度は演習用の架空サンプルです。実務では、実名、顧客名、障害ID、契約条件、個人評価を入力する前に、社内ルールと情報分類を確認してください。
1.2 標準業務フローへの対応
| 工程 | このケースで行うこと |
|---|---|
| 1. タスク定義 | 会議目的を「情報共有」ではなく「優先度、担当、期限の決定」に置く |
| 2. 情報分類 | 顧客名、個人評価、障害詳細、契約条件を除外し、抽象化した論点だけを使う |
| 3. 文脈設計 | 参加者、会議時間、意思決定点、事前資料、未決条件をAIへ渡す |
| 4. 出力仕様 | アジェンダ、議事録、意思決定ログ、action / follow-up tracker の見出しを指定する |
| 5. 手段選択 | AIは構造化と抜け漏れ確認に使い、合意形成と発言意図の確認は人間が行う |
| 6. 生成 | 初回アジェンダと議事録テンプレートを作らせる |
| 7. 評価 | CARE(4観点)と会議運用固有基準で点検する |
| 8. ファクトチェック | 決定事項、担当、期限、保留理由、前提条件を参加者へ確認する |
| 9. 編集・承認 | 会議体オーナーが配布版を確定し、関係者レビューを通す |
| 10. ログ化・再利用 | 決定 ID、判断理由、前提、次回確認事項を意思決定ログに残す |
2. 初期入力
2.1 人間が整理した meeting task brief
【meeting task brief】
会議名: 部門横断 週次優先度会議
目的: 来週の優先度上位3件、担当、期限、未決事項の確認責任者を決める
読み手: 会議参加者、欠席した関係者、施策オーナー
会議時間: 60分
参加部門: 開発、運用、営業、CS
意思決定点:
1. 来週の優先度上位3件を決める
2. 各タスクの担当と期限を決める
3. 未決事項の確認責任者と次回確認日を決める
入力禁止情報:
- 個人評価
- 顧客名
- 契約条件
- 障害詳細ログ
- 未公開の商談情報
承認者: 会議体オーナー、施策オーナー
2.2 入力データ(演習用サンプル)
【事前論点】
候補タスク:
A. 障害再発防止策の恒久対応
- 状況: 暫定回避は完了
- 影響: 複数チームの運用負荷が高い
- 要確認: 恒久対応の設計レビュー日
B. 重要顧客向けの期限対応
- 状況: 期限が固定
- 影響: 営業とCSの調整が必要
- 要確認: 顧客名と契約条件はAIへ入力しない
C. 運用手順の見直し
- 状況: 手順が分散し、引き継ぎに時間がかかっている
- 影響: 新任者の作業遅延
- 要確認: 標準化対象の範囲
D. 新機能の小規模検証
- 状況: 仮説検証の準備中
- 影響: 中長期の改善候補
- 要確認: 今週中に決める必要性
制約:
- 会議では上位3件だけを決める
- 期限や担当が未確定の場合は「暫定」または「要確認」と書く
- 個人の責任追及に見える表現は避け、作業と判断に焦点を当てる
2.3 初期プロンプト
最初にありがちな依頼は、次のように抽象的です。
次回の定例会議のアジェンダを作ってください。会議後は議事録も作りたいです。
この指示では、会議目的、意思決定点、入力禁止情報、議事録の型、意思決定ログへの接続が不足しています。そのため、AIは「進捗共有」「課題共有」のような一般的な会議案を出しやすくなります。
3. 初回出力
# 週次定例会議アジェンダ
1. 進捗共有
2. 課題共有
3. 来週の予定確認
4. 次のアクション
# 議事録テンプレート
- 日時:
- 参加者:
- 議題:
- 議論内容:
- 決定事項:
- ToDo:
4. 問題点
初回出力は見慣れた会議フォーマットですが、意思決定の再現性が不足しています。
| 観点 | 問題 | リスク |
|---|---|---|
| 目的 | 「何を決める会議か」が見えない | 共有だけで終わり、優先度が決まらない |
| 論点 | 候補タスク、判断基準、事前資料が反映されていない | 重要論点が抜ける |
| 出力仕様 | 決定事項、ToDo、未決、判断理由、前提が分かれていない | 後から決定の根拠を説明できない |
| 機密管理 | 入力禁止情報や抽象化ルールがない | 顧客情報、個人評価、障害詳細が混入する |
| 合意確認 | 参加者レビューと確定条件がない | 議事録に対する認識差が残る |
| 再利用性 | 意思決定ログや action / follow-up tracker に接続していない | 次回会議で同じ確認を繰り返す |
5. 評価(CAREと章固有基準)
5.1 CARE(4観点)評価
| CARE | 判定 | 根拠 | 改善方針 |
|---|---|---|---|
| Correctness / 正確性 | 不十分 | 入力した候補タスクや制約が反映されていない | 事前論点と入力禁止情報を明示して再生成する |
| Appropriateness / 適切性 | 不十分 | 参加部門と意思決定点に合う構成ではない | 会議目的を優先度、担当、期限の決定へ絞る |
| Relevance / 関連性 | 不十分 | 決定、未決、判断理由、前提が弱い | 議事録と意思決定ログの出力仕様を固定する |
| Effectiveness / 効果性 | 不十分 | 会議後の行動、レビュー、次回確認へつながらない | action / follow-up tracker と次回確認事項を入れる |
5.2 会議運用固有基準
| 基準 | 確認ポイント | 初回出力の状態 |
|---|---|---|
| 意思決定可能性 | 会議内で何を決めるか明確か | 不十分 |
| 時間設計 | 判断に必要な議題へ時間配分できているか | 不十分 |
| 事前準備 | 参加者が何を読んで来るべきか分かるか | 不十分 |
| 記録の分離 | 決定、ToDo、未決、判断理由、前提が分かれているか | 不十分 |
| 合意確認 | 参加者レビューと確定条件があるか | 不十分 |
| 機密管理 | 入力禁止情報と抽象化方針が示されているか | 不十分 |
| 再利用性 | 次回会議や監査に使えるログになっているか | 不十分 |
6. 改善指示
6.1 改善プロンプト
あなたは部門横断会議の進行設計と議事録作成を支援します。
以下の条件を守り、会議前のアジェンダ、会議後の議事録テンプレート、意思決定ログ、action / follow-up tracker を作ってください。
【目的】
部門横断の週次会議で、来週の優先度上位3件、担当、期限、未決事項の確認責任者を決める。
【読み手】
会議参加者、欠席した関係者、施策オーナー、次回会議の進行役。
【会議時間】
60分。
【参加部門】
開発、運用、営業、CS。
【意思決定点】
1. 来週の優先度上位3件を決める
2. 各タスクの担当と期限を決める
3. 未決事項の確認責任者と次回確認日を決める
【候補タスク】
A. 障害再発防止策の恒久対応
B. 重要顧客向けの期限対応
C. 運用手順の見直し
D. 新機能の小規模検証
【制約】
- 上位3件だけを決める
- 期限や担当が未確定の場合は「暫定」または「要確認」と書く
- 個人評価、顧客名、契約条件、障害詳細ログ、未公開の商談情報は扱わない
- 決定事項、ToDo、未決事項、判断理由、前提、次回確認事項を分ける
- 発言者の意図や合意は推測せず、要確認にする
【出力仕様】
A. 会議アジェンダ
B. 議事録テンプレート
C. 意思決定ログ
D. action / follow-up tracker
E. 人間が確認すべき点
6.2 改善後出力(AIのたたき台)
# A. 会議アジェンダ(60分)
1. 目的と意思決定点の確認(5分)
- 来週の優先度上位3件、担当、期限、未決確認責任者を決める
2. 候補タスクの確認(10分)
- A. 障害再発防止策の恒久対応
- B. 重要顧客向けの期限対応
- C. 運用手順の見直し
- D. 新機能の小規模検証
3. 優先度判断(20分)
- 判断基準: 影響度、緊急度、依存関係、今週決める必要性
4. 担当と期限の確認(15分)
- 担当が未確定の場合は暫定担当または確認責任者を置く
5. 未決事項と次回確認(10分)
- 保留理由、確認責任者、確認日を残す
# B. 議事録テンプレート
- 会議名:
- 日時:
- 参加部門:
- 目的:
- 決定事項:
- ToDo(担当 / 期限 / 状態):
- 未決事項(保留理由 / 確認責任者 / 確認日):
- 判断理由:
- 前提 / 要確認:
- 次回議題:
# C. 意思決定ログ
- 決定 ID:
- 決定内容:
- 判断理由:
- 代替案:
- 前提:
- リスク:
- 承認者:
- 次回見直し条件:
# D. action / follow-up tracker
| Action | 担当 | 期限 | 状態 | 次回確認 |
| --- | --- | --- | --- | --- |
# E. 人間が確認すべき点
- 決定事項、担当、期限が会議内の合意と一致しているか確認する
- 顧客名、契約条件、障害詳細ログ、個人評価が混入していないか確認する
- 発言者の意図や参加者の合意は推測せず、必要な箇所を要確認として残す
改善後出力は構造化されていますが、提出物としてはまだサンプル値が薄く、会議後に参加者へ配布できる最終版としては不足しています。次に、人間が会議結果を反映して確定版へ編集します。
7. 最終成果物
以下は、演習用サンプルをもとに人間が編集した最終成果物です。実務では、会議体オーナーが参加者レビューを通して確定してください。
7.1 会議アジェンダ(配布版)
# 部門横断 週次優先度会議 アジェンダ
## 会議目的
来週の優先度上位3件、担当、期限、未決事項の確認責任者を決める。
## 事前確認事項
- 候補タスクA〜Dの状況を確認して参加する
- 顧客名、契約条件、障害詳細ログ、個人評価は会議資料とAI入力から除外する
- 判断基準は、影響度、緊急度、依存関係、今週決める必要性とする
## 時間配分(60分)
1. 目的と意思決定点の確認(5分)
2. 候補タスクA〜Dの事実確認(10分)
3. 優先度上位3件の決定(20分)
4. 担当、期限、確認責任者の決定(15分)
5. 未決事項、次回確認、配布前レビュー方法の確認(10分)
## 本日決めること
- 来週の優先度上位3件
- 各タスクの担当と期限
- 未決事項の確認責任者と確認日
7.2 議事録(会議後配布版)
# 部門横断 週次優先度会議 議事録
- 日時: 2026年5月25日 10:00-11:00(演習用サンプル)
- 参加部門: 開発、運用、営業、CS
- 欠席 / 共有先: 欠席した関係者、施策オーナー、次回会議の進行役
- 確定条件: 会議体オーナー確認後、参加者の1営業日レビューを経て確定
## 会議目的
来週の優先度上位3件、担当、期限、未決事項の確認責任者を決める。
## 決定事項
1. 優先度1: 障害再発防止策の恒久対応
- 理由: 複数チームの運用負荷が高く、再発防止の優先度が高い
- 担当: 開発リード(暫定)
- 期限: 今週金曜までに恒久対応案を提示
2. 優先度2: 重要顧客向けの期限対応
- 理由: 期限が固定で、営業とCSの調整が必要
- 担当: 営業リード、CSリード
- 期限: 今週水曜までに調整案を提示
3. 優先度3: 運用手順の見直し
- 理由: 手順が分散し、新任者の作業遅延が発生している
- 担当: 運用リード
- 期限: 来週火曜までに標準化対象を整理
## 今回は見送る事項
- 新機能の小規模検証
- 理由: 今週中に決定する必要性が他候補より低い
- 次回確認: 次回定例で検証準備状況を確認
## 未決事項
- 障害再発防止策の設計レビュー日
- 保留理由: レビュー担当者の予定確認が未完了
- 確認責任者: 開発リード
- 確認日: 今週木曜
- 重要顧客向け期限対応の制約
- 保留理由: 契約条件をAI入力から除外しているため、法務 / 営業で別途確認が必要
- 確認責任者: 営業リード
- 確認日: 今週水曜
## 配布前レビュー
- 会議体オーナーが、決定事項、担当、期限、未決事項を確認する
- 参加者は配布後1営業日以内に誤記または認識差を指摘する
7.3 意思決定ログ
# 意思決定ログ: 週次優先度会議
## Decision-001
決定内容:
来週の優先度1を「障害再発防止策の恒久対応」とする。
判断理由:
- 複数チームの運用負荷が高い
- 暫定回避は完了しているが、再発防止策が未確定
- 期限を置かないと暫定対応が長期化する
代替案:
- 重要顧客向け期限対応を優先度1にする
- ただし、期限対応は営業とCSで並行可能と判断した
前提:
- 障害詳細ログはこのログには記載しない
- 恒久対応案の技術妥当性は設計レビューで確認する
リスク:
- 設計レビュー日が決まらない場合、期限が遅れる
承認者:
- 会議体オーナー
次回見直し条件:
- 設計レビュー日が未確定のまま次回会議を迎える場合
## Decision-002
決定内容:
重要顧客向け期限対応を優先度2とし、営業リードとCSリードで調整案を作成する。
判断理由:
- 期限が固定で、関係部門間の調整が必要
- 顧客名と契約条件は会議ログとAI入力から除外する必要がある
代替案:
- 運用手順の見直しを優先度2にする
- ただし、期限が固定された調整事項を先に処理する必要があると判断した
前提:
- 契約条件の詳細は別途、営業と法務で確認する
- 顧客名と契約条件はこのログには記載しない
リスク:
- 契約条件上の制約が後から判明した場合、調整案の再作成が必要になる
承認者:
- 会議体オーナー
次回見直し条件:
- 期限変更の余地または契約条件上の制約が判明した場合
7.4 action / follow-up tracker
| ID | Action | 担当 | 期限 | 状態 | 次回確認 |
|---|---|---|---|---|---|
| A-001 | 恒久対応案を作成する | 開発リード | 今週金曜 | 未着手 | 次回定例 |
| A-002 | 重要顧客向け調整案を作成する | 営業リード / CSリード | 今週水曜 | 未着手 | 今週木曜の事前確認 |
| A-003 | 運用手順の標準化対象を整理する | 運用リード | 来週火曜 | 未着手 | 次回定例 |
| A-004 | 設計レビュー日を確認する | 開発リード | 今週木曜 | 要確認 | 次回定例 |
| A-005 | 契約条件の制約を確認する | 営業リード | 今週水曜 | 要確認 | 今週木曜の事前確認 |
8. 人間が確認すべき点
| 確認項目 | 確認者 | 確認内容 |
|---|---|---|
| 決定事項 | 会議体オーナー | 優先度、担当、期限が会議内の合意と一致しているか |
| 発言意図 | 参加者 | 発言の要約が意図と異なっていないか |
| 機密情報 | 会議体オーナー / 情報管理担当 | 顧客名、契約条件、障害詳細、個人評価が混入していないか |
| 未決事項 | 各確認責任者 | 保留理由、次の確認事項、確認日が具体的か |
| 期限 | 各担当 | 実行可能な期限か、暫定期限として扱うべきか |
| 配布範囲 | 会議体オーナー | 欠席者、関係者、外部共有可否を確認しているか |
| ログ化 | 進行役 | decision ID、判断理由、前提、見直し条件が残っているか |
AIが作った議事録は、会議の事実を確定するものではありません。決定事項、担当、期限、発言意図、配布範囲は、人間が確認してから確定します。
9. 再利用のためのテンプレ化ポイント
9.1 meeting operating template として残す要素
【meeting operating template】
会議名:
会議目的:
読み手:
意思決定点:
参加者 / 参加部門:
入力禁止情報:
事前資料:
判断基準:
アジェンダ:
議事録の出力仕様:
意思決定ログの出力仕様:
action / follow-up tracker の出力仕様:
配布前レビュー方法:
次回確認事項:
9.2 評価ログ
| ログ項目 | 残す内容 |
|---|---|
| 入力データ | 事前論点、候補タスク、除外した機密情報の種類 |
| プロンプト | 初期プロンプト、改善プロンプト、禁止条件 |
| 初回出力 | 共有中心で終わった問題例を含めて保存する |
| 評価 | CARE、会議運用固有基準、修正理由 |
| 最終成果物 | 配布版のアジェンダ、議事録、意思決定ログ、action / follow-up tracker |
| 承認履歴 | 会議体オーナー確認、参加者レビュー、確定日 |
| 再利用条件 | 使える会議体、使ってはいけない情報、抽象化ルール |
9.3 次回の改善観点
- 会議依頼時点で、必ず意思決定点を1〜3個に絞る。
- 「共有」「相談」だけでなく、会議後に残す決定 ID と action ID を決める。
- 議事録では、決定、ToDo、未決、判断理由、前提を分ける。
- 発言者の意図や合意をAIに推測させない。
- 顧客名、契約条件、障害詳細、個人評価は必要に応じて別管理し、AI入力から除外する。
- 次回会議では、action / follow-up tracker の未完了項目から開始する。