Research / 2026-08-15
議事録の良し悪しは、書き手の要約力では決まらない。その場にいなかった人が、読んだだけで正しく次の一手を打てるか——判定基準はこれ一つ。だから「会議で何が言われたか」を上手に縮めても、いい議事録にはならない。必要なのは要約ではなく、決まったこと・動くこと・まだ決まっていないことへの仕分けである。
本文中の 出典名 は、その記述の根拠になった文書へのリンク(別タブで開く)。チップが付いていない記述は、複数の出典を突き合わせた本レポート側の整理・解釈である。全出典の一覧は末尾。
この3つを満たしていれば、体裁がどうであれいい議事録である。逆に、どれだけ丁寧に会話を再現しても、この3つが欠けていれば議事録として機能しない。
誰が何を言ったかの再現は目的ではない。むしろ意思決定の質を下げる(→ 原則1)。文字起こしがすでにその役目を持っている。
会議の種類を問わず効く原則。後半のプロンプトは、すべてこの7つを機械的に守らせるための翻訳になっている。
取締役会議事録の法定記載事項は「議事の経過の要領及びその結果」(会社法369条3項・会社法施行規則101条3項)。経過は要約でよいが、結果は落とせない。発言についても記載義務があるのは「意見又は発言の概要」にとどまる。逐語ではなく、要領と結果——法定文書でも設計思想は同じである。
Governance Cloud KEIYAKU-WATCH マネーフォワード「要約する」ではなく「仕分ける」。この5分類が、そのまま出力スキーマになり、そのままAIへの指示になる。右端の列は、AIに任せたときに最も壊れやすい箇所。
| 区分 | 何を書くか | 必須項目 | 落とすと起きること | AIが間違えやすい点 |
|---|---|---|---|---|
| 決定事項 iBabs Umbrex |
この会議で確定したこと。言い切りの形で書く | 内容 / 理由 / 決定者・承認者 / 根拠の時刻 | 「決まったつもり」の齟齬。数か月後に同じ論点が再燃 | 条件付き合意を無条件の決定に圧縮する。検討中の案を決定に昇格させる サイバーレコード テックエイド |
| アクション Convene Wrike |
会議後に人が動くこと。動詞で始める | やること / 担当(個人名) / 期限(日付) / 完了の定義 | 誰も動かない。次回が同じ議題の再演になる | 文脈から担当者・期限を推測して埋める。「検討する」で終える Granola テックエイド |
| 未決・論点 Plane GoTranscript |
決まらなかったこと、意見が割れたこと、持ち帰り | 論点 / 現状 / 誰がいつ決めるか | 宙に浮いたまま忘れられ、後日ゼロから議論し直す | そもそも出力しない。要約の過程で最初に消える情報 Granola |
| 前提・共有事実 monday |
決定の背景として共有された数値・状況・制約 | 事実 / 出所(資料名・発言者) | 半年後に決定の理由が読めなくなる | 数値・金額・日付・固有名詞の聞き違い。意味が変わる誤りになる サイバーレコード LINE WORKS |
| 見送った案 Plane monday |
検討したが採らなかった選択肢と、その理由 | 案 / 不採用の理由 | 同じ案が繰り返し再提案される | 明示的に指示しない限り出力しない。「採用されなかった＝不要」と判断する (本レポートの推論。直接の出典なし) |
原則を具体的な文面に落とすとこうなる。左が実際によく見る書き方、右が原則を満たした書き方。例文自体は本レポートで作成したもので、各組の「差」の根拠を出典で示す。
新機能のリリース時期について意見交換した。9月がよいのではという意見が出た。
【決定】 v2.0 のリリース日を 2026-09-30 とする。
理由: 8月末の大型案件と実装工数が競合するため。
決定者: 田中(PO) 根拠: [00:12:40]
認証まわりの負荷について、引き続き検討する。
佐藤が 2026-08-22 までに認証APIの負荷試験を実施し、#dev-auth に結果を投稿する。
完了の定義: 同時1,000接続時の p95 レイテンシを数値で提示する。
Bベンダーに発注することになった。
【条件付き決定】 Bベンダーの見積が 300万円以下であれば発注する。
超過した場合は発注せず、次回この場で再判断する。
見積回答期限: 2026-08-25
田中「それは厳しいと思う」／鈴木「やってみないと分からない」／田中「でも前回も同じことを言って…」
スケジュール前倒しについて、既存案件との工数競合を理由とする慎重論と、小さく試してから判断すべきという意見が出た。結論は次回に持ち越し。
(記載なし。決まらなかったので書くことがない)
【未決】 料金改定の適用開始日。9/1 案と 10/1 案で意見が分かれた。
山田が両案の売上影響試算を用意し、次回(8/22)に決定する。
原則は共通でも、どこに紙面と厳密さを割くかは変わる。AIへの指示を分けるべきなのもこの軸。この表自体は各出典を突き合わせた本レポートの整理で、行ごとに根拠を示す。
| 観点 | チーム定例・進捗共有 | 意思決定会議・承認の場 |
|---|---|---|
| 議事録の主目的 | 状態の同期と、滞留の早期発見 GitLab | 決定の確定と、根拠の保全 Jurassic Parl. 会社法 |
| 最重要ブロック | アクション(前回分の消化状況を含む) GitLab Wrike | 決定事項 + 見送った案 + 反対意見の扱い monday |
| 分量の目安 | 1画面。読むのに1分 iBabs | 決定1件につき、根拠まで数行かけてよい Plane |
| 前回との接続 | 前回アクションの done / 継続を必ず冒頭に置く GitLab | 過去の決定を上書きする場合、どの決定を差し替えたか明記する monday |
| 議論の要約 | ほぼ不要。残す論点だけ | 必要。ただし個人に帰属させない「要領」として Jurassic Parl. 会社法 |
| 保存の期待 | 直近数回が追えれば十分 | 検索可能な形で恒久保存(決定ログとして蓄積) Plane 会社法 |
| AIへの指示の重心 | アクション抽出 担当・期限・完了条件の網羅性 Granola | 決定の厳密さ 文言・条件・承認者・不採用理由 GoTranscript |
議事録はAIにとって比較的得意な仕事だが、素朴に頼むと必ず同じ3つの壊れ方をする。プロンプトはこの3つを潰すために書く。
担当者や期限が文字起こしから特定できないとき、AIは黙って埋めようとする。ここで「わからないものは TBD と書き、要確認リストに理由付きで挙げよ」と明示すると、捏造が「宿題」に変わる。不確実性を出力の一部として扱えることが、AI議事録の品質を最も左右する。
GoTranscript Benchmarks Granola| 要素 | 何を書くか | 効く理由 | 根拠 |
|---|---|---|---|
| 1. 役割と読み手 | 議事録担当として、欠席者と半年後の他人に向けて書く | 文体と粒度が一撃で決まる。主語や前提の補完が自然に起きる | Claap GitLab |
| 2. 入力の定義 | 文字起こし / アジェンダ / 前回議事録を明示的に渡す | アジェンダがあると論点の取りこぼしが減り、前回分があるとアクションの継続が追える | GitLab ScreenApp |
| 3. 出力スキーマ | 見出し・表の列・行の形式まで固定する | 毎回同じ形になり、比較・検索・自動処理ができる。人の確認も速い | GoTranscript Claap |
| 4. 仕分けルール | 決定 / アクション / 未決 の判定基準を言語化する | 「要約」から「分類」へタスクを変える。AIの判断がぶれなくなる | Granola Umbrex |
| 5. 禁止事項 | 推測禁止・逐語転記禁止・空欄の穴埋め禁止 | 失敗モードA〜Cを直接封じる | サイバーレコード Jurassic Parl. |
| 6. 不確実性の扱い | 不明は TBD、理由付きで「要確認」へ回す | 捏造を宿題に変換する。人の確認対象がリスト化される | GoTranscript |
| 7. 根拠の付与 | 各行に時刻 [hh:mm:ss] または短い引用を必須にする | 検証可能性が担保され、誤りの発見が数秒で済む。ハルシネーション自体も減る | GoTranscript Benchmarks |
上の7要素をすべて盛り込んだ実物。【 】の部分を差し替えて使う。チームで同じものを共有すると、出力の形が揃って比較できるようになる。
あなたは社内会議の議事録担当です。読み手は「会議に出ていない関係者」と 「半年後にこの決定の経緯を調べる人」です。出席者向けには書かないでください。 # 入力 - 文字起こし: 【ここに文字起こしを貼る。話者ラベルとタイムコード付きが望ましい】 - アジェンダ / 事前資料: 【あれば貼る。なければ「なし」】 - 前回の議事録: 【あれば貼る。なければ「なし」】 # あなたの仕事 文字起こしを要約するのではなく、次の5種類に「仕分け」してください。 1. 決定事項 … この会議で確定したこと 2. アクション … 会議後に誰かが動くこと 3. 未決・論点 … 決まらなかったこと、意見が割れたこと、持ち帰り 4. 前提・共有事実 … 決定の背景として共有された情報・数値・制約 5. 見送った案 … 検討したが採らなかった選択肢と、その理由 # 出力フォーマット ## サマリ 3行以内。何が決まり、次に何が動くか。 ## 決定事項 表: | # | 決定内容 | 理由・根拠 | 決定者/承認者 | 根拠 | - 決定内容は「〜する」と言い切る。「〜する方向で進める」は使わない。 - 条件が付く場合は「【条件】を満たせば〜する。満たさない場合は〜」と条件と例外を書く。 ## アクション 表: | # | やること | 担当(氏名) | 期限(YYYY-MM-DD) | 完了の定義 | 根拠 | - 動詞で始める(作成する / 確認する / 送付する / 実施する)。 - 「検討する」「対応する」は禁止。何をもって完了とするかを「完了の定義」に書く。 ## 未決・次に決めること 表: | # | 論点 | 現在の状況 | 誰が・いつ決めるか | 根拠 | ## 前提・共有された事実 箇条書き。数値・日付・固有名詞は文字起こしの表記をそのまま使う。 ## 見送った案 箇条書き。「案 — 見送った理由」の形式。言及がなければ「なし」と書く。 ## 要確認 箇条書き。TBD にした項目を、理由とともにすべてここに集める。 # ルール - 文字起こしに書かれていないことは書かない。推測・補完・一般論の追加は禁止。 - 決定事項・アクション・未決の各行には、根拠となった発言の時刻 [hh:mm:ss] を必ず付ける。 タイムコードがない場合は、その発言を20字以内で引用する。 - 担当者・期限・数値が文字起こしから特定できないときは、埋めずに「TBD」と書き、 「要確認」に『◯◯の担当者が特定できない』のように理由付きで挙げる。 - 「〜だと思う」「〜かもしれない」「〜の方向で」は決定事項にしない。未決・論点に入れる。 - 条件付き・仮の合意を、無条件の決定として書かない。条件は決定文の一部として残す。 - 発言の逐語転記はしない。ただし決定の文言・数値・固有名詞は言い換えない。 - 誰が言ったかは、決定・承認・担当の帰属に必要な場合だけ書く。それ以外は個人に紐づけない。 - 挨拶・雑談・脱線は落とす。 - 出力は日本語。常体(だ・である)、1文1情報。
# 追加ルール(意思決定会議) - 決定事項ごとに、次を必ず埋める。 - 適用範囲: 何に適用され、何には適用されないか - 検討した選択肢: 採用・不採用の理由をそれぞれ一行で - 見直し条件: 何が起きたらこの決定を再検討するか - 反対・懸念: 出ていた場合はその内容と、それに対する結論 - 「決定」と「合意した雰囲気」を区別する。決裁者の明示的な承認発言が確認できない項目は 決定事項に入れず、未決に『承認者の明示的な合意が確認できない』と書く。 - 過去の決定を変更する場合は、どの決定を差し替えたのかを決定内容の中に明記する。
# 追加ルール(定例・進捗共有) - 出力の先頭に「前回アクションの状況」を置く。前回議事録の各アクションを 完了 / 継続 / 中止 に分類し、継続のものは新しい期限を書く(不明なら TBD)。 - 決定事項がない回は、決定事項の欄に「なし」と書く。無理に決定を作らない。 - 全体で 1 画面に収まる分量にする。議論の要約は、次に判断が必要な論点だけに絞る。 - 進捗の遅れが述べられた項目は、未決・論点に「ブロッカー」として挙げる。
AIの下書きを検証なしで配らない。逆に言えば、人の仕事はここだけに絞れる。上から順に、誤ると被害が大きい順。各項目のチップは、その確認が必要だと指摘している文書。
決定とアクションだけをその場で声に出し、担当と期限を確認する。AIの下書きの品質は、この30秒で決まる。文字起こしに明示的な確定発言が残るため、AIが推測する余地がなくなる。
毎回書き直さない。上のベースをチームの共有物として置き、会議種別ごとの add-on だけ足す。出力の形が揃うと、確認が「読む」から「見比べる」に変わる。
本文中のチップはすべてここに対応する。カッコ内は、本レポートがその文書から取った内容。