第12章：効果的な会議・議論術

この章で作れる成果物

この章を読み終えると、次の成果物を作れる状態を目指します。

meeting task brief: 会議の目的、意思決定点、参加者、情報分類、承認者を定義する設計メモ。
agenda / decision design canvas: 議題、論点、判断基準、時間配分、必要資料、決めないことを整理する会議設計表。
participant context / role map: 参加者の役割、関心、決裁権、準備依頼、発言が必要な論点を整理する表。
meeting evidence pack: 事前資料、PDF、表、グラフ、チャット、スクリーンショット、前回ログの出所と扱いをまとめる根拠セット。
facilitation runbook: 会議中の進行、論点切り替え、発言促進、対立処理、保留判断を定義する運用メモ。
discussion capture log: 議論中の主張、根拠、反論、未確認事項、感情的論点を分けて記録するログ。
decision log: 決定事項、判断理由、根拠、条件、反対意見、承認者、見直し条件を残す意思決定ログ。
consensus / dissent register: 合意、条件付き合意、不同意、懸念、保留、次回確認事項を可視化する台帳。
action / follow-up tracker: 担当、期限、成果物、承認条件、次回レビューを追跡する実行管理表。

第11章では、プレゼンテーションと想定Q&Aを、聞き手が判断できる成果物へ仕上げました。本章では、その後に生じる会議、議論、合意形成を扱います。会議の目的は、話し合うことではありません。必要な情報を確認し、論点を絞り、判断を行い、残った未決事項を次の行動へつなげることです。

AIは、アジェンダ案、事前資料の要約、論点候補、議事録ドラフト、ToDo抽出に役立ちます。ただし、誰が何を合意したか、どの情報を記録してよいか、どの決定に責任を持つかは人間が確認します。

本章とAI活用の標準業務フロー

本章は、AI活用の標準業務フロー（1枚）のうち、主に次の工程に対応します。

1. タスク定義: 会議の目的、意思決定点、扱う論点、決めないこと、期待する成果物を決める。
2. 情報分類: 事前資料、録音、議事メモ、チャット、参加者情報、顧客情報、個人評価を分類する。
3. 文脈設計: 参加者の前提知識、利害、既存決定、未解決論点、会議制約を context pack にする。
4. 出力仕様: agenda、minutes、decision log、action / follow-up tracker、consensus / dissent register の形式を定義する。
5. 手段選択: 対面、オンライン、ハイブリッド、非同期レビュー、投票、共同編集、ホワイトボード、議事録支援ツールを使い分ける。
6. 生成: AIにアジェンダ案、論点整理、質問案、議事録ドラフト、アクション抽出を作らせる。
7. 評価: CARE+、判断基準、会議目的、参加者準備、意思決定ログの再現性で点検する。
8. ファクトチェック: meeting evidence pack と source hierarchy で、発言、数値、資料、前回決定を確認する。
9. 編集・承認: 人間が議事録、決定事項、公開範囲、担当、期限、承認条件を確定する。
10. ログ化・再利用: 採用版の agenda、minutes、decision log、未決事項、テンプレート化ポイントを残す。

会議は、AIに任せれば自動的に良くなるものではありません。AIに渡す前に、何を決める会議なのか、どの情報を使ってよいのか、誰が最終確認するのかを設計します。

12.1 この章で扱う業務課題

会議が機能しない原因は、進行スキルだけではありません。多くは、会議前の設計不足と、会議後のログ不足から生じます。

目的が「共有」「相談」「議論」のままで、意思決定点が曖昧である。
参加者の役割、決裁権、準備物が不明なまま会議が始まる。
資料、表、グラフ、スクリーンショット、前回議事録の出所が確認されていない。
議論中に、事実、仮説、意見、懸念、決定が混ざる。
反対意見が出たが、解消したのか保留したのか記録されない。
議事録に「誰が、何を、いつまでに、どの条件で行うか」が残らない。
AIが作った議事録を確認せずに共有し、合意内容の誤認が残る。
オンライン会議の録音、チャット、画面共有資料の扱いが決まっていない。
会議後にテンプレートや決定ログが再利用されず、同じ議論を繰り返す。

本章では、会議を「時間枠」ではなく「意思決定と合意形成の成果物」として扱います。agenda、minutes、decision log、consensus / dissent register、action / follow-up tracker を一体で設計します。

12.2 meeting task brief

12.2.1 会議前に決めること

meeting task brief は、会議の目的と制約を定義するメモです。会議招集前に作ることで、開催すべきか、非同期で足りるか、誰が参加すべきかを判断できます。

【meeting task brief】
会議名:
利用場面: 経営会議 / 部門会議 / プロジェクト定例 / 顧客会議 / レビュー会 / 障害対応
会議の目的:
意思決定点:
今回決めないこと:
期待する成果物: 議事録、decision log、action / follow-up tracker、合意条件、次回論点
参加者:
必須参加者と理由:
任意参加者と理由:
承認者 / 決裁者:
情報分類: 公開 / 社内限定 / 機密 / 個人情報 / 顧客情報 / 契約情報 / 人事情報
AI利用環境: 外部AI / 社内AI / AI利用不可 / 手作業中心
利用する入力: 事前資料 / 第11章の presentation outcome log / 前回議事録 / PDF / 表 / グラフ / スクリーンショット / チャット
未確認事項:
想定される対立:
会議後に残すログ:
再利用条件:

「念のため集まる」会議は、AIで議事録を整えても成果につながりません。brief で、決めること、決めないこと、記録すべきことを先に分けます。

12.2.2 会議を開かない判断

すべての論点を会議で扱う必要はありません。会議を開く前に、次のように判断します。

状況	推奨する扱い	理由
情報共有だけで質疑が少ない	非同期共有	参加者の時間を拘束しない
資料の事実確認が主目的	コメントレビュー	根拠確認を残しやすい
意思決定者が不在	開催延期または事前承認	決定できない会議を避ける
利害調整が必要	会議を開催	発言、懸念、条件付き合意を確認する
緊急対応が必要	短時間会議 + decision log	判断と責任者を明確にする

AIには「この会議は開催すべきか」を検討させることもできます。ただし、参加者の権限、社内文化、緊急度、関係性を踏まえた最終判断は人間が行います。

12.3 agenda / decision design canvas

12.3.1 アジェンダを意思決定から逆算する

agenda / decision design canvas は、議題を並べる表ではなく、意思決定から逆算して会議を設計する表です。

【agenda / decision design canvas】
会議名:
最終的に決めたいこと:
成功条件:
決めないこと:

| 時間 | 議題 | 目的 | 判断基準 | 必要資料 | 発言が必要な人 | 出力 |
| --- | --- | --- | --- | --- | --- | --- |
| 0-5分 | 目的確認 | 判断範囲を合わせる | 決める/決めないが明確 | meeting task brief | 進行役 / 決裁者 | 本日の到達点 |
| 5-20分 | 現状確認 | 事実を合わせる | 出所が確認済み | evidence pack | 担当者 | 共有済み事実 |
| 20-40分 | 選択肢比較 | 推奨案を検討する | 評価軸に沿う | 比較表 | 関係部門 | 推奨案 / 保留論点 |
| 40-50分 | リスク確認 | 反対意見を扱う | 許容/要対策が明確 | risk memo | 反対意見を持つ人 | 対策 / dissent |
| 50-60分 | 決定と次アクション | 実行条件を確定する | 担当・期限・承認者が明確 | action / follow-up tracker | 決裁者 / 担当者 | decision log |

「議題1、議題2」と並べるだけでは、何を決める時間なのかが分かりません。各議題に、目的、判断基準、必要資料、出力を付けます。

12.3.2 判断基準を先に合意する

議論の途中で評価軸を変えると、結論がぶれます。会議前または冒頭で、判断基準を合意します。

【判断基準の例】
- 顧客影響: 顧客価値、契約、サポート負荷への影響
- 実現可能性: 人員、期間、技術、運用負荷
- リスク: security、privacy、IP、法務、品質、説明責任
- 経済性: 費用、回収見込み、機会損失。ただし未検証数値は仮説として扱う
- 戦略適合: 既存方針、ロードマップ、組織目標との整合
- 可逆性: 失敗時に戻せるか、段階導入できるか

評価軸に数値を使う場合は、サンプル評価であること、出所、前提、重み付け、確認者を明示します。根拠のないスコアを結論の代わりにしません。

12.4 participant context / role map

12.4.1 参加者を人数ではなく役割で設計する

参加者が多いほど、会議の品質が上がるわけではありません。必要なのは、判断、実行、検証、承認に必要な役割がそろっていることです。

【participant context / role map】
| 参加者 | 役割 | 関心事 | 決裁権 / 影響力 | 準備依頼 | 発言が必要な論点 | 会議後の責任 |
| --- | --- | --- | --- | --- | --- | --- |
| 部門長 | 決裁者 | 投資対効果、リスク、実行責任 | 最終承認 | brief確認 | 採否、条件 | 承認 / 差し戻し |
| 現場責任者 | 実行責任者 | 現場負荷、品質、期限 | 実行可否に影響 | 工数見積 | 実行条件 | action / follow-up tracker の更新 |
| 情報システム | リスク確認 | security、ログ、利用環境 | 制約提示 | 利用環境確認 | AI利用範囲 | policy確認 |
| 法務 / 契約担当 | 専門確認 | 契約、IP、privacy | 専門判断 | 契約条件確認 | 要確認事項 | 追加レビュー |
| 進行役 | プロセス管理 | 論点、時間、記録 | 進行権限 | agenda作成 | 合意確認 | minutes確定 |

AIに role map の草案を作らせる場合は、役職名だけでなく、誰が何を判断できるか、誰の懸念を先に扱うべきかを人間が補います。

12.4.2 発言しない参加者を設計で減らす

会議中に「何かありますか」と聞くだけでは、必要な発言は出ません。事前に、誰に何を準備してもらうかを指定します。

決裁者には、承認条件と差し戻し条件を確認してもらう。
実行責任者には、担当、期限、リソース制約を確認してもらう。
専門部門には、会議中に断定できる範囲と、持ち帰る範囲を分けてもらう。
反対意見を持つ人には、懸念、根拠、受け入れ条件を出してもらう。
記録担当には、決定、未決、ToDo、不同意を分けて記録してもらう。

発言の量ではなく、意思決定に必要な情報が出たかを見ます。

12.5 meeting evidence pack

12.5.1 会議で使う根拠を束ねる

meeting evidence pack は、会議で参照する資料とその扱いをまとめた根拠セットです。会議中に資料を探し始めると、議論が根拠確認ではなく印象論に流れます。

【meeting evidence pack】
会議名:
論点:

| 資料 | 種別 | 出所 | 確認日 | 情報分類 | 主張との関係 | 注意点 | 確認者 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 前回議事録 | 社内正本 | 前回minutes | 会議前 | 社内限定 | 前回決定の確認 | 未承認版なら使用しない | 進行役 |
| 提案書 | 社内資料 | 第10章 proposal skeleton | 会議前 | 社内限定 / 機密 | 選択肢比較 | 顧客情報を含む箇所は共有範囲注意 | 担当者 |
| グラフ | 表 / 図 | BI資料 | 会議前 | 社内限定 | 現状把握 | 読み取ってよい範囲を明記 | 分析担当 |
| スクリーンショット | 画像 | 業務システム | 会議前 | 個人情報の有無を確認 | 問題再現 | マスキング要否を確認 | 現場責任者 |
| チャット抜粋 | 会話ログ | 社内チャット | 会議前 | 社内限定 | 経緯確認 | 個人評価に使わない | 進行役 |

PDF、画像、表、グラフ、スクリーンショットは、AIに要約させる前に情報分類と利用範囲を確認します。顧客情報、個人情報、契約条件、未公開情報が含まれる場合は、社内AIまたは手作業中心に切り替えます。

12.5.2 会議中の事実確認

会議中の発言は、すべて根拠として扱えるわけではありません。discussion capture log で、事実、解釈、仮説、懸念を分けます。

【discussion capture log】
| 時刻 | 発言 / 論点 | 種別 | 根拠 | 要確認事項 | 扱い |
| --- | --- | --- | --- | --- | --- |
| 10:15 | 現場負荷が増える可能性 | 懸念 | 現場責任者の経験 | 工数見積 | action / follow-up trackerへ |
| 10:22 | 前回はA案で合意した | 事実候補 | 前回議事録が必要 | 前回minutes確認 | 保留 |
| 10:35 | B案のほうが顧客影響が小さい | 仮説 | 比較表 | 顧客影響の定義 | 評価軸へ |
| 10:48 | 法務確認が必要 | 専門確認 | 契約条件 | 法務担当確認 | decision log条件へ |

AIで議事録を作る場合も、この分類を出力仕様に含めます。AI出力に「決定」と書かれていても、会議中に明示的な合意がなければ未決として扱います。

12.6 facilitation runbook

12.6.1 進行を台本化する

facilitation runbook は、進行役が会議中に使う運用メモです。台本は硬直的に進めるためではなく、目的から外れたときに戻るために作ります。

【facilitation runbook】
会議名:
進行役:
記録担当:
本日の到達点:

開始時:
- 目的、意思決定点、決めないことを確認する
- 情報分類と録音・記録の扱いを確認する
- 発言ルールと時間配分を確認する

論点切り替え:
- この論点の判断基準は何か
- 決めるために不足している情報は何か
- いま決めるか、保留するか

対立発生時:
- 争点を、事実、価値判断、制約、感情に分ける
- 共通目的を確認する
- 受け入れ条件、保留条件、追加確認を分ける

終了時:
- 決定事項、不同意、未決事項、ToDoを読み上げる
- 担当、期限、承認者、次回確認日を確定する
- 議事録の確認者と公開範囲を決める

12.6.2 発言を引き出す質問

発言を促す目的は、場を盛り上げることではありません。意思決定に必要な情報を引き出すことです。

【論点確認】
- 本日決めるべきことは何ですか。
- いま話している論点は、判断に必要ですか。
- この論点は、今日決めるものですか、次回へ送るものですか。

【根拠確認】
- その判断の根拠はどの資料ですか。
- 事実、解釈、仮説のどれですか。
- 確認日、出所、適用範囲は分かりますか。

【反対意見確認】
- この案で困る人は誰ですか。
- 受け入れられない条件は何ですか。
- 条件付きなら合意できる点はありますか。

【合意確認】
- いま決まったことを一文で言うと何ですか。
- 誰が、何を、いつまでに行いますか。
- どの条件を満たしたら見直しますか。

12.6.3 オンライン・ハイブリッド会議

オンラインやハイブリッド会議では、発言機会、資料共有、記録の扱いが不均等になりやすくなります。

冒頭で、録音、文字起こし、チャット保存、画面共有資料の扱いを確認する。
オンライン参加者と会議室参加者の発言順を意図的に切り替える。
重要な発言は、口頭だけでなく共有メモへ書く。
チャットの質問、リアクション、投票結果を minutes に残すかどうかを決める。
ホワイトボードや付箋の画像は、情報分類、出所、確認者を付けて保存する。
接続不良で意思決定者が参加できない場合は、決定を保留する条件を決める。

AIによる文字起こしや要約は便利ですが、話者の取り違え、否定表現の欠落、条件付き合意の省略が起きることがあります。重要な決定は、会議中に読み上げて確認します。

12.7 minutes と decision log

12.7.1 議事録は会話録ではなく実行文書

minutes は、発言をすべて記録する文書ではありません。後から、何を決め、何を決めず、誰が何をするかを確認する実行文書です。

【minutes schema】
会議名:
日時:
参加者:
欠席者 / 事後確認者:
目的:
情報分類:
AI利用有無:

1. 本日の到達点
2. 決定事項
   - 決定内容:
   - 判断理由:
   - 根拠資料:
   - 条件:
   - 承認者:
3. 未決事項
   - 未決理由:
   - 必要な追加情報:
   - 確認担当:
   - 次回判断予定:
4. 反対意見 / 懸念
   - 内容:
   - 根拠:
   - 解消状況:
   - 残す条件:
5. アクション
   - 担当:
   - 期限:
   - 成果物:
   - 完了条件:
6. 公開範囲 / 再利用条件

AIには、この schema で議事録ドラフトを作らせます。人間は、決定事項、発言者、担当、期限、公開範囲を確認してから共有します。

12.7.2 decision log を残す

decision log は、後から「なぜこの判断になったのか」を説明するための記録です。決定内容だけでなく、判断理由、却下した案、反対意見、見直し条件を残します。

【decision log】
決定 ID:
決定日:
決定者 / 承認者:
会議名:
決定内容:
判断理由:
採用した根拠:
却下した選択肢:
却下理由:
反対意見 / 懸念:
条件付き合意:
未確認事項:
リスクと緩和策:
実行担当:
期限:
見直し条件:
関連資料:
公開範囲:
再利用条件:

特に、AI利用、security、privacy、IP、契約、顧客影響、予算、採用・評価に関わる決定では、判断理由と確認者を残します。記録できない機密事項は、存在だけを示し、詳細は許可された場所へ保管します。

12.8 consensus / dissent register

12.8.1 合意を段階で扱う

合意形成は、全員が完全に賛成することだけではありません。実務では、理解、支持、条件付き合意、不同意、保留を分けて扱います。

【consensus / dissent register】
| 論点 | 参加者 / 部門 | 状態 | 懸念 | 受け入れ条件 | 次アクション | 記録方針 |
| --- | --- | --- | --- | --- | --- | --- |
| 限定試験開始 | 営業部門 | 合意 | 現場負荷 | 対象案件を限定 | 案件選定 | decision logへ |
| 限定試験開始 | 情報システム | 条件付き合意 | ログ保管 | 社内AI環境に限定 | 利用環境確認 | 条件として残す |
| 限定試験開始 | 法務 | 保留 | 契約条項 | 契約確認後に判断 | 法務レビュー | 未決事項へ |
| 評価指標 | 現場責任者 | 不同意 | 数値だけでは品質を測れない | 定性レビューを含める | 評価軸修正 | dissentとして残す |

不同意を消すことが目的ではありません。不同意の根拠、受け入れ条件、保留理由を記録することで、後から「合意したはず」という認識違いを防ぎます。

12.8.2 対立を構造化する

対立が起きたら、人格や部門の問題にせず、争点を分けます。

対立の種類	見分け方	扱い方
事実認識の違い	参照している資料や時点が違う	meeting evidence pack で確認する
評価軸の違い	コスト、品質、速度、リスクの重みが違う	判断基準を再合意する
制約の違い	部門ごとのルール、リソース、期限が違う	制約条件を明文化する
利害の違い	誰かに負荷やリスクが偏る	受け入れ条件と代替案を検討する
感情・経緯	過去の不信や疲弊が影響する	事実と感情を分け、必要なら個別に扱う

AIに対立の整理を依頼する場合は、発言者を断定的に評価させないようにします。「誰が悪いか」ではなく、「論点、根拠、懸念、受け入れ条件」を出力させます。

12.9 action / follow-up tracker

12.9.1 会議後の実行を追跡する

会議で決めたことは、実行されて初めて成果になります。action / follow-up tracker では、担当、期限、成果物、完了条件を明確にします。

【action / follow-up tracker】
| ID | アクション | 担当 | 期限 | 成果物 | 完了条件 | 承認者 | 状態 | 関連decision |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| A-01 | 対象案件を3件候補化する | 営業責任者 | 次回会議前 | 候補一覧 | 情報分類済み | 部門長 | 未着手 | D-01 |
| A-02 | 社内AI利用環境を確認する | 情報システム | 次回会議前 | 確認メモ | ログ保管場所が明確 | 情報システム責任者 | 進行中 | D-01 |
| A-03 | 契約条項の確認要否を判断する | 法務担当 | 次回会議前 | 法務確認結果 | 要否と理由が記録済み | 法務責任者 | 未着手 | D-02 |

ToDo は「やること」だけでは不十分です。成果物、完了条件、承認者、関連する decision log を紐づけます。

12.9.2 再利用できる会議資産にする

会議後に残すものは、minutes だけではありません。次回以降の品質を上げるために、再利用可能な資産として保存します。

meeting task brief: 同種会議の招集判断に使う。
agenda / decision design canvas: 定例会やレビュー会の標準アジェンダにする。
meeting evidence pack: 根拠資料の確認観点を再利用する。
facilitation runbook: 進行役交代時の引き継ぎに使う。
minutes schema: 議事録の最低品質をそろえる。
decision log: 判断理由の監査、振り返り、再検討に使う。
consensus / dissent register: 条件付き合意や未解消の懸念を追跡する。
action / follow-up tracker: 次回会議の冒頭確認に使う。

再利用するときは、古い判断をそのまま流用しません。作成日、適用範囲、前提、廃止条件を確認します。

12.10 AIとの協働境界

12.10.1 AIに任せる範囲

AIに任せやすい作業は、構造化、要約、抜け漏れ確認、形式変換です。

meeting task brief から agenda 案を作る。
事前資料を、論点、根拠、未確認事項へ整理する。
第11章の presentation outcome log から次回会議の論点を抽出する。
会議メモから minutes、decision log、action / follow-up tracker のドラフトを作る。
反対意見や質問を consensus / dissent register に分類する。
長い議事録を、決定事項、未決事項、ToDoへ再構成する。
過去の decision log から見直し条件に該当するものを候補として探す。

12.10.2 AIに任せない範囲

次の判断は、人間が行います。

会議を開催するか、非同期で済ませるか。
誰を必須参加者にするか、誰に決裁権があるか。
機密情報、個人情報、顧客情報、契約情報をAIへ渡してよいか。
録音、文字起こし、チャット、スクリーンショットの保存可否。
発言のニュアンス、不同意、条件付き合意をどう記録するか。
決定事項、担当、期限、承認者が正しいか。
法務、security、privacy、IP、人事評価に関わる判断。
公開範囲、再利用範囲、削除または保管期間。
会議の結論に責任を持てるか。

12.10.3 プロンプト例

AIへ依頼するときは、会議の目的、情報分類、出力形式、確認してほしい観点を明示します。

【背景】次回の部門会議で、営業提案書作成への社内AI試験導入を扱います。
【目的】限定試験を開始するか、開始条件を決めたいです。
【入力】meeting task brief、前回の presentation outcome log、提案書レビュー課題メモがあります。
【制約】顧客名、価格、契約条件は含めません。未確認事項は断定しないでください。
【依頼】agenda / decision design canvas の草案を作ってください。
【出力形式】時間、議題、目的、判断基準、必要資料、発言が必要な人、出力の表にしてください。
【確認観点】意思決定点が明確か、未確認事項が分離されているか、会議で決めないことが明示されているかを最後に点検してください。

AI出力を採用する前に、会議目的、情報分類、参加者、判断基準、未確認事項を人間が確認します。

12.11 よくある失敗

12.11.1 アジェンダが議題一覧で終わる

議題だけでは、何を判断する時間か分かりません。agenda / decision design canvas で、目的、判断基準、出力を付けます。

12.11.2 決定者がいない会議を開く

決定者が不在なら、会議は情報共有や論点整理にとどまります。決定が必要な場合は、決裁者の参加、事前承認、または事後確認条件を設計します。

12.11.3 AI議事録をそのまま共有する

AIは発言者、否定、条件付き合意、保留を誤ることがあります。決定事項、担当、期限、公開範囲は人間が確認します。

12.11.4 反対意見を議事録から消す

反対意見を消すと、後から合意の認識がずれます。不同意、懸念、受け入れ条件は consensus / dissent register に残します。

12.11.5 ToDoに完了条件がない

担当と期限だけでは、完了したか判断できません。成果物、完了条件、承認者を action / follow-up tracker に入れます。

12.11.6 録音・チャット・画面共有の扱いが曖昧

会議ログには機密情報や個人情報が含まれることがあります。保存可否、公開範囲、AI利用可否を会議前に決めます。

12.12 人間が最終判断すべき点

AIと協働しても、次の判断は人間が行います。

会議の目的、意思決定点、決めないこと。
開催要否、参加者、決裁者、記録担当。
事前資料、録音、チャット、スクリーンショットの情報分類。
AIに渡してよい情報、社内AIに限定する情報、AIに渡さない情報。
判断基準、評価軸、重み付け、受け入れ条件。
反対意見をどう扱うか、保留するか、追加確認するか。
決定事項、未決事項、ToDo、担当、期限、承認者。
議事録と decision log の公開範囲、保存場所、再利用条件。
法務、security、privacy、IP、人事評価、契約に関わる確認要否。
会議結果に責任を持てる状態か。

章末演習

演習12-1：meeting task brief を作る

自分が近く開催または参加する会議を1つ選び、meeting task brief を作ってください。目的、意思決定点、決めないこと、情報分類、承認者、AI利用環境を明示してください。

演習12-2：agenda / decision design canvas を作る

演習12-1の会議について、agenda / decision design canvas を作ってください。各議題に、目的、判断基準、必要資料、発言が必要な人、出力を記入してください。

演習12-3：meeting evidence pack を作る

会議で使う資料、PDF、表、グラフ、スクリーンショット、前回議事録を洗い出し、出所、確認日、情報分類、注意点、確認者を整理してください。

演習12-4：decision log と consensus / dissent register を作る

会議で想定される決定事項を1つ選び、decision log の草案を作ってください。あわせて、合意、条件付き合意、不同意、保留を consensus / dissent register に整理してください。

演習12-5：AI議事録ドラフトを点検する

実際または仮想の会議メモを使い、AIに minutes schema で議事録ドラフトを作らせてください。決定事項、担当、期限、未決事項、公開範囲を人間が確認し、修正してください。

理解度チェック

□ meeting task brief を使い、会議目的、意思決定点、情報分類、承認者を定義できる □ agenda / decision design canvas で、議題を意思決定から逆算して設計できる □ participant context / role map で、参加者の役割、決裁権、準備依頼を整理できる □ meeting evidence pack で、事前資料、図表、スクリーンショット、前回ログの出所と扱いを確認できる □ facilitation runbook で、論点切り替え、対立処理、保留判断を運用できる □ minutes schema と decision log で、決定、未決、反対意見、ToDoを分けて記録できる □ consensus / dissent register で、合意、条件付き合意、不同意、保留を可視化できる □ AIに任せる範囲と、人間が最終判断する範囲を分けられる

章末の要点

会議は、話し合いの場ではなく、意思決定、合意形成、実行条件を残すための業務成果物です。
meeting task brief は、会議の目的、意思決定点、決めないこと、情報分類、承認者を定義する入口です。
agenda / decision design canvas は、議題を、目的、判断基準、必要資料、出力から設計します。
participant context / role map は、参加者の役割、決裁権、準備依頼、会議後の責任を明確にします。
meeting evidence pack は、資料、PDF、表、グラフ、スクリーンショット、前回ログの出所と扱いを確認します。
facilitation runbook は、会議中の論点切り替え、発言促進、対立処理、保留判断を支援します。
minutes と decision log は、決定事項だけでなく、判断理由、根拠、不同意、未決事項、見直し条件を残します。
consensus / dissent register は、合意できたことだけでなく、条件付き合意、不同意、保留を可視化します。
action / follow-up tracker は、担当、期限、成果物、完了条件、承認者を追跡し、会議を実行へつなげます。

次章への橋渡し

第12章では、AIと協働しながら、会議設計、議事録、意思決定ログ、合意形成を、実行につながる成果物として扱う方法を学びました。次の第13章では、会議で整理した論点、利害、反対意見をもとに、営業ヒアリング、提案骨子、反論処理、交渉へ展開します。