議事録の書き方 会議別テンプレート6種と決定事項・ToDoの例文

議事録とは、会議で「何が決まり、誰が、いつまでに、何をするか」を、出席していない人にも伝わる形で残す文書です。 発言を順番に書き写すものではなく、発言を「決定事項」「ToDo」「保留」「宿題」の4つに仕分けて書くと、読む人が次の行動をすぐに取れます。

この記事では、システム開発でよく開く6種の会議（定例・要件ヒアリング・設計レビュー・障害振り返り・キックオフ・1on1）について、そのまま貼って使えるテンプレートを Markdown とプレーンテキストの両方で載せます。あわせて、話し言葉のメモを議事録の文に直す言い換え40例、ToDo を課題管理表へ移すための列構成と変換スクリプト、送付文例、文字起こしを整えるプロンプトをまとめました。題材は架空の「社内の備品予約システム」です。

確認環境：Ubuntu 24.04 / Python 3.11.15（ToDo 表をタブ区切りに変換するスクリプトを実行）。

議事録の書き方の早見表

4つの区分の違いは次のとおりです。

議事録に書く項目と順番

読む人が最初に知りたいのは結論なので、決定事項と ToDo を上に、議論の経緯を下に置きます。 議題ごとに「経緯→結論」と並べる形式もありますが、会議の後に見返されるのは決定事項と ToDo が中心です。

「決定事項」と「ToDo」は、該当が無い回でも見出しを残して「なし」と書きます。見出しごと消すと、読む人は書き漏れなのか本当に無かったのかを見分けられないためです。

会議別テンプレート6種

6種とも、Markdown 版は記入例つき、プレーンテキスト版は空欄（かっこ内に書き方の例）で載せています。Markdown が使えるツール（GitHub、Wiki、ドキュメントツールなど）には前者を、メール本文やチャットには後者を使うと崩れずに貼れます。

1. 定例の議事録テンプレート

定例は回数が多いので、毎回同じ見出しで短く書くことが続けるこつです。前回の ToDo の状況を先頭の表で確認すると、期限を過ぎた作業が埋もれません。

# 備品予約システム 週次定例 議事録

- 日時: 2026-10-05(月) 10:00〜10:30
- 場所: オンライン
- 出席: 佐藤(進行)、鈴木、高橋、田中(記録)
- 欠席: 伊藤
- 目的: 進み具合の確認と、今週の作業の合意

## 前回 ToDo の状況

| No | 内容 | 担当 | 期限 | 状態 |
|---|---|---|---|---|
| 1 | 予約登録画面の単体テストを完了する | 鈴木 | 2026-10-02 | 完了 |
| 2 | 通知メールの文面案を作成する | 田中 | 2026-10-02 | 完了 |

## 決定事項

1. 予約一覧画面の並び順は「利用開始日時の昇順」とする。
2. 結合テストの開始日を 10/19(月) とする。

## ToDo

| No | 内容 | 担当 | 期限 | 状態 |
|---|---|---|---|---|
| 1 | 予約一覧画面の並び順を修正し、レビューを依頼する | 鈴木 | 2026-10-07 | 未着手 |
| 2 | 結合テストのテストデータ 30 件を作成する | 高橋 | 2026-10-14 | 未着手 |
| 3 | 通知メールの文面案を利用部門に送り、確認を依頼する | 田中 | 2026-10-09 | 着手 |

## 保留

- 予約の繰り返し登録(毎週など)は、利用状況の集計が出る 10/19 の定例で再度判断する。

## 宿題

| No | 確認すること | 担当 | 回答日 |
|---|---|---|---|
| 1 | 会議室カレンダーとの連携で取得できる項目 | 鈴木 | 2026-10-09 |

## 次回

- 2026-10-13(火) 10:00〜10:30 オンライン

【議事録】（対象） （会議名） （日付）

日時：（例：2026-10-05(月) 10:00〜10:30）
場所：（例：オンライン）
出席：（進行と記録が分かるように書く）
欠席：
目的：（例：進み具合の確認と、今週の作業の合意）

■前回ToDoの状況
1. （内容）／（担当）／（期限）／（完了・着手・未着手）

■決定事項
1. （〜とする。）

■ToDo
1. （内容）／担当：（1名）／期限：（日付）

■保留
・（事項）：（再び判断する時期または条件）

■宿題
1. （確認すること）／担当：／回答日：

■次回
（日時・場所・持ち越す議題）

2. 要件ヒアリングの議事録テンプレート

要件ヒアリングでは、「確認できた要望」と「まだ決まっていないこと」を分けて書くと、相手が読んで認識の違いを指摘しやすくなります。要望には「なぜ必要か」を1列足しておくと、後で優先順位を決める材料になります。

# 備品予約システム 要件ヒアリング（第2回）議事録

- 日時: 2026-10-06(火) 14:00〜15:00
- 場所: 3階 会議室B
- 出席: 利用部門 山本、中村 / 開発 佐藤(進行)、田中(記録)
- 目的: 予約の登録・変更・取り消しの要望を確認する

## 確認できた要望

| No | 要望 | 理由・背景 | 優先度 |
|---|---|---|---|
| 1 | 備品は30日先まで予約できるようにしたい | 月次の行事の準備で、1か月前に押さえたい | 高 |
| 2 | 予約の取り消しは利用開始の1時間前まで可能にしたい | 直前の取り消しで、次の人が使えない状況を減らしたい | 高 |
| 3 | 予約の前日に通知メールを受け取りたい | 予約したことを忘れて、未使用になる例がある | 中 |

## 決定事項

1. 予約の単位は30分とする。
2. 1人が同時に持てる予約は5件までとする。

## 未確定事項（次回までに決める）

| No | 事項 | 選択肢 | 決める人 | 決める日 |
|---|---|---|---|---|
| 1 | 上長の承認を必要とするか | A: 不要 / B: 高額の備品のみ必要 | 山本 | 2026-10-13 |

## 宿題

| No | 確認すること | 担当 | 回答日 |
|---|---|---|---|
| 1 | 現在の台帳に登録されている備品の件数 | 中村 | 2026-10-09 |
| 2 | 通知メールを前日以外にも送れるか(技術面) | 佐藤 | 2026-10-09 |

## ToDo

| No | 内容 | 担当 | 期限 | 状態 |
|---|---|---|---|---|
| 1 | 本議事録を利用部門に送り、認識の違いが無いか確認を依頼する | 田中 | 2026-10-07 | 未着手 |
| 2 | 要望 No.1〜3 を要件一覧に追記する | 佐藤 | 2026-10-08 | 未着手 |

## 次回

- 2026-10-13(火) 14:00〜15:00 議題: 承認の要否、管理者向け機能

【議事録】（対象） 要件ヒアリング（第n回） （日付）

日時：
場所：
出席：（相手側）／（自分たちの側）
目的：（例：予約の登録・変更・取り消しの要望を確認する）

■確認できた要望
1. （要望）／理由：（なぜ必要か）／優先度：（高・中・低）

■決定事項
1. （〜とする。）

■未確定事項
1. （事項）／選択肢：（A案・B案）／決める人：／決める日：

■宿題
1. （確認すること）／担当：／回答日：

■ToDo
1. （内容）／担当：／期限：

■次回
（日時・議題）

※認識の違いがありましたら、（日付）までにご連絡ください。

3. 設計レビューの議事録テンプレート

設計レビューは、指摘を1件1行の表にして、対応の要否を区分で示すと、後の修正確認が楽になります。最後に「承認・条件つき承認・再レビュー」の判定を書くと、次に進んでよいかが一目で分かります。

# 備品予約システム 基本設計レビュー（予約機能）議事録

- 日時: 2026-10-08(木) 15:00〜16:00
- 場所: オンライン
- 出席: 佐藤(レビュー担当)、高橋(レビュー担当)、鈴木(作成者)、田中(記録)
- 対象: 基本設計書 第3章「予約機能」 版 0.9
- 目的: 設計内容の指摘と、次工程へ進む判定

## 判定

- 条件つき承認(必須の指摘 2 件の修正を佐藤が確認した時点で承認とする)

## 指摘一覧

| No | 箇所 | 指摘 | 区分 | 対応 |
|---|---|---|---|---|
| 1 | 3.2 予約登録 | 同じ備品・同じ時間帯に2人が同時に登録した場合の動きが書かれていない | 必須 | 後から登録した側をエラーとし、文言を追記する |
| 2 | 3.4 取り消し | 取り消しの期限(利用開始の1時間前)の判定に使う時刻が不明 | 必須 | サーバーの時刻で判定すると明記する |
| 3 | 3.1 一覧 | 一覧の件数が多い場合のページ分けの件数を書くとよい | 推奨 | 1ページ20件と追記する |
| 4 | 3.3 変更 | 変更時に通知メールを再送するか | 質問 | 再送する(3.5 節に記載あり)。相互参照を追加する |

## 決定事項

1. 予約の重複は、データベースの一意制約で防ぐ方式とする。

## ToDo

| No | 内容 | 担当 | 期限 | 状態 |
|---|---|---|---|---|
| 1 | 指摘 No.1〜4 を設計書に反映し、版 1.0 として提出する | 鈴木 | 2026-10-13 | 未着手 |
| 2 | 版 1.0 で必須の指摘 2 件の修正を確認する | 佐藤 | 2026-10-14 | 未着手 |

【議事録】（対象） （工程）レビュー（範囲） （日付）

日時：
場所：
出席：（レビュー担当）／（作成者）／（記録）
対象：（文書名・章・版）
目的：設計内容の指摘と、次工程へ進む判定

■判定
（承認／条件つき承認／再レビュー）（条件があれば書く）

■指摘一覧
1. 箇所：（章・節）／指摘：／区分：（必須・推奨・質問）／対応：

■決定事項
1. （〜とする。）

■ToDo
1. （内容）／担当：／期限：

指摘の区分は、次の3つにそろえると判断がぶれません。

4. 障害振り返りの議事録テンプレート

障害の振り返りは、人ではなく仕組みに目を向けて書くのが基本です。「誰が見落としたか」ではなく「どの手順・どの確認が無かったか」を主語にすると、再発防止の ToDo が具体的になります。顧客や関係者に提出する障害報告書とは別に、チーム内の学びを残す文書として書きます。

# 備品予約システム 障害振り返り(通知メールの未送信)議事録

- 日時: 2026-10-09(金) 16:00〜16:45
- 場所: オンライン
- 出席: 佐藤(進行)、鈴木、高橋、伊藤、田中(記録)
- 対象: 2026-10-07 に発生した、予約前日の通知メールが送信されなかった事象
- 目的: 経緯を整理し、再発防止の作業を決める

## 概要

- 発生: 2026-10-07 18:00(通知の定時処理)
- 気づいた時刻: 2026-10-08 09:10(利用者からの問い合わせ)
- 復旧: 2026-10-08 10:30(処理を手動で再実行し、42 件を送信)
- 影響: 10/8 利用分の通知メール 42 件が約 16 時間遅れて届いた

## 時系列

| 時刻 | 出来事 |
|---|---|
| 10/07 15:00 | メール送信の設定を変更するリリースを実施 |
| 10/07 18:00 | 定時処理が設定の読み込みエラーで終了 |
| 10/08 09:10 | 利用者から「通知が届かない」と問い合わせ |
| 10/08 09:40 | ログを確認し、設定ファイルの項目名の誤りを特定 |
| 10/08 10:30 | 設定を修正し、処理を再実行。42 件を送信 |

## うまくいった点

- 問い合わせから 30 分で原因を特定できた(ログにエラー内容が出力されていた)。
- 再実行の手順が手順書にあり、迷わず実施できた。

## 改善点

- 定時処理がエラーで終了しても、通知が届く仕組みが無かった。
- リリース後の確認項目に、定時処理の動作確認が含まれていなかった。

## 決定事項

1. 定時処理がエラーで終了した場合は、チームのチャットに自動で通知する。
2. リリース後の確認項目に「定時処理を手動で 1 回実行する」を追加する。

## ToDo

| No | 内容 | 担当 | 期限 | 状態 |
|---|---|---|---|---|
| 1 | 定時処理のエラーをチャットに通知する処理を追加する | 鈴木 | 2026-10-16 | 未着手 |
| 2 | リリース手順書の確認項目を更新する | 伊藤 | 2026-10-13 | 未着手 |
| 3 | 設定ファイルの項目名を起動時に検査する処理を追加する | 高橋 | 2026-10-20 | 未着手 |

【議事録】（対象） 障害振り返り（事象の名前） （日付）

日時：
場所：
出席：
対象：（いつ発生した、どの事象か）
目的：経緯を整理し、再発防止の作業を決める

■概要
発生：
気づいた時刻：
復旧：
影響：（件数・時間など数字で）

■時系列
（時刻） （出来事）

■うまくいった点
・

■改善点
・（手順や仕組みを主語にして書く）

■決定事項
1. （〜とする。）

■ToDo
1. （内容）／担当：／期限：

5. キックオフの議事録テンプレート

キックオフの議事録は、後から参加した人が最初に読む文書になります。目的・ゴール・体制・進め方のルールを、資料を開かなくても分かる粒度で書きます。

# 備品予約システム開発 キックオフ 議事録

- 日時: 2026-10-01(木) 13:00〜14:00
- 場所: 5階 大会議室
- 出席: 利用部門 山本、中村 / 開発 佐藤(責任者)、鈴木、高橋、伊藤、田中(記録)
- 目的: 目的・範囲・体制・進め方を関係者全員で合意する

## 目的とゴール

- 目的: 紙の台帳で行っている備品の予約を、システムに置き換える。
- ゴール: 2026-10-30(金) に、予約の登録・変更・取り消し・通知を利用できる状態にする。
- 範囲外: スマートフォン向けの専用画面、他システムとの連携。

## 体制と役割

| 役割 | 担当 | 主な責任 |
|---|---|---|
| 責任者 | 佐藤 | 計画・進み具合の管理、判断 |
| 利用部門の窓口 | 山本 | 要望の取りまとめ、受け入れテストの判定 |
| 画面・機能の開発 | 鈴木、高橋 | 設計・実装・テスト |
| 環境・リリース | 伊藤 | 環境の準備、リリース作業 |
| 記録・連絡 | 田中 | 議事録、課題管理表の更新 |

## 主な日程

| 節目 | 日付 |
|---|---|
| 要件の確定 | 2026-10-09 |
| 結合テスト開始 | 2026-10-19 |
| 受け入れテスト | 2026-10-26〜10-28 |
| リリース | 2026-10-30 |

## 決定事項

1. 定例は毎週月曜 10:00〜10:30 にオンラインで行う。
2. 連絡はチームのチャットを基本とし、決定を伴う内容は議事録か課題管理表に残す。
3. 要望の追加・変更は山本を窓口とし、佐藤が影響を確認してから受けるかどうかを回答する。
4. 議事録は当日中に田中が送付し、翌営業日までに指摘が無ければ確定とする。

## ToDo

| No | 内容 | 担当 | 期限 | 状態 |
|---|---|---|---|---|
| 1 | 課題管理表を作成し、全員に場所を知らせる | 田中 | 2026-10-02 | 未着手 |
| 2 | 第1回の要件ヒアリングの日程を調整する | 佐藤 | 2026-10-02 | 未着手 |

【議事録】（対象） キックオフ （日付）

日時：
場所：
出席：
目的：目的・範囲・体制・進め方を関係者全員で合意する

■目的とゴール
目的：
ゴール：（いつまでに、何ができる状態にするか）
範囲外：

■体制と役割
（役割）：（担当）／（主な責任）

■主な日程
（節目）：（日付）

■決定事項（進め方のルール）
1. 定例：
2. 連絡手段：
3. 変更の受け付け：
4. 議事録の確定：

■ToDo
1. （内容）／担当：／期限：

6. 1on1の議事録テンプレート

1on1 の記録は、本人と上長の2人が見返すためのメモです。会議の議事録と違い、話した内容をすべて残す必要はありません。「合意したこと」と「次回までにやること」に絞り、だれに共有してよいかを最後に書いておくと、本人が安心して話せます。

# 1on1 メモ(高橋 / 佐藤)

- 日時: 2026-10-15(木) 17:00〜17:30
- 場所: オンライン
- 共有範囲: 本人と上長のみ

## 話したテーマ

1. 結合テストの準備の進み具合
2. 今後挑戦したい作業
3. 働き方で困っていること

## 合意したこと

1. テストデータの作成は、鈴木が半日分を手伝う(高橋から依頼する)。
2. 次の開発では、高橋が設計レビューの進行役を 1 回担当する。
3. 集中したい作業がある日は、午前の会議を午後に移してよい。

## 次回までにやること

| No | 内容 | 担当 | 期限 |
|---|---|---|---|
| 1 | 鈴木にテストデータ作成の分担を依頼する | 高橋 | 2026-10-16 |
| 2 | 設計レビューの進行役の進め方を資料で共有する | 佐藤 | 2026-10-22 |

## 次回

- 2026-10-29(木) 17:00〜17:30

1on1メモ（本人）／（上長） （日付）

日時：
場所：
共有範囲：（本人と上長のみ／チームに共有可 など）

■話したテーマ
1.

■合意したこと
1.

■次回までにやること
1. （内容）／担当：（本人または上長）／期限：

■次回

発言メモを書き分ける言い換え早見表（書き直し前後40例）

会議中のメモは話し言葉のままで構いません。議事録にするときに、主語・対象・期限を補って、区分ごとの文末にそろえます。 4区分を10例ずつ、合計40例を載せます。日付は 2026 年 10 月の例です。

決定事項に直す10例

ToDo に直す10例

保留に直す10例

宿題に直す10例

書き直すときの4つの確認

迷いやすい「ToDo と宿題」「保留と宿題」は、次の基準で分けます。

ToDo を課題管理表に転記する列構成

議事録の ToDo は、会議のたびに別の文書へ散らばります。ToDo と宿題を1つの課題管理表に集めると、期限を過ぎた作業をまとめて確認できます。 議事録側の表は5列、課題管理表側は10列にそろえます。

表計算ソフトの1行目に貼れる見出し行（タブ区切り）は次のとおりです。

ID  起票日 発生元 区分  内容  担当  期限  状態  完了日 備考

Markdown の議事録をタブ区切りに変換するスクリプト

「1. 定例の議事録テンプレート」の記入例を teirei.md として保存し、ToDo 表と宿題表を課題管理表の列構成に変換します。見出しが ## ToDo と ## 宿題 で、表の列名がテンプレートと同じであることが前提です。

"""議事録(Markdown)の ToDo 表と宿題表を、課題管理表に貼れるタブ区切りにする。
使い方: python3 minutes2tsv.py teirei.md > todo.tsv
"""
import re
import sys

COLUMNS = ["ID", "起票日", "発生元", "区分", "内容", "担当", "期限", "状態", "完了日", "備考"]


def cells(line):
    return [c.strip() for c in line.strip().strip("|").split("|")]


def read_tables(lines):
    """見出し(## ...)ごとに、表の行を辞書のリストにして返す"""
    tables, section, header = {}, None, None
    for line in lines:
        if line.startswith("## "):
            section, header = line[3:].strip(), None
        elif line.startswith("|") and section:
            row = cells(line)
            if header is None:
                header = row
            elif not set("".join(row)) <= set("-: "):   # 区切り行は読み飛ばす
                tables.setdefault(section, []).append(dict(zip(header, row)))
    return tables


def main(path):
    lines = open(path, encoding="utf-8").read().splitlines()
    title = lines[0].lstrip("# ").replace(" 議事録", "")
    date = re.search(r"\d{4}-\d{2}-\d{2}", "\n".join(lines)).group()
    prefix = date.replace("-", "")
    tables = read_tables(lines)
    out = [COLUMNS]
    for r in tables.get("ToDo", []):
        out.append([f"{prefix}-T{r['No']}", date, title, "ToDo", r["内容"], r["担当"], r["期限"], r["状態"], "", ""])
    for r in tables.get("宿題", []):
        out.append([f"{prefix}-H{r['No']}", date, title, "宿題", r["確認すること"], r["担当"], r["回答日"], "未着手", "", ""])
    for row in out:
        print("\t".join(row))


if __name__ == "__main__":
    main(sys.argv[1])

実行結果（python3 minutes2tsv.py teirei.md）です。そのまま表計算ソフトに貼り付けられます。

ID  起票日 発生元 区分  内容  担当  期限  状態  完了日 備考
20261005-T1 2026-10-05  備品予約システム 週次定例   ToDo    予約一覧画面の並び順を修正し、レビューを依頼する    鈴木  2026-10-07  未着手     
20261005-T2 2026-10-05  備品予約システム 週次定例   ToDo    結合テストのテストデータ 30 件を作成する  高橋  2026-10-14  未着手     
20261005-T3 2026-10-05  備品予約システム 週次定例   ToDo    通知メールの文面案を利用部門に送り、確認を依頼する   田中  2026-10-09  着手      
20261005-H1 2026-10-05  備品予約システム 週次定例   宿題  会議室カレンダーとの連携で取得できる項目    鈴木  2026-10-09  未着手     

「前回 ToDo の状況」の表は見出しが異なるため、変換の対象になりません。同じ作業が二重に登録されないよう、前回分は課題管理表の状態を更新する運用にします。

議事録を送るメールとチャットの文例

送付文には、決定事項と ToDo の要点を本文に書きます。 添付やリンクを開かなくても、自分に関係する作業が分かるようにするためです。

メール（社内の関係者向け）

件名：【議事録】備品予約システム 週次定例（2026-10-05）

関係者各位

田中です。本日の週次定例の議事録をお送りします。

■決定事項
1. 予約一覧画面の並び順は「利用開始日時の昇順」とする。
2. 結合テストの開始日を 10/19(月) とする。

■ToDo
1. 予約一覧画面の並び順の修正とレビュー依頼／鈴木／10/7
2. 結合テストのテストデータ30件の作成／高橋／10/14
3. 通知メールの文面案の確認依頼／田中／10/9

全文は次の場所にあります。
（議事録の保存場所）

内容に認識の違いがありましたら、10/6(火) 12:00 までにご連絡ください。
ご連絡が無い場合は、この内容で確定とします。

次回は 10/13(火) 10:00〜10:30 です。

メール（社外の相手向け）

件名：【議事録のご確認のお願い】備品予約システム 要件ヒアリング第2回（2026-10-06）

（相手の会社名・部署名）
山本様、中村様

いつもお世話になっております。（自分の会社名）の田中です。
本日はお時間をいただき、ありがとうございました。
打ち合わせの議事録を添付にてお送りします。

特にご確認いただきたい点は、次の2点です。
1. 「確認できた要望」の No.1〜3 に、認識の違いが無いか
2. 未確定事項 No.1（承認の要否）を 10/13(火) までにご決定いただけるか

お気づきの点がありましたら、10/8(木) までにご連絡をお願いいたします。
次回は 10/13(火) 14:00 より、同じ会議室で予定しております。

引き続きよろしくお願いいたします。

チャット

【議事録】週次定例 10/5
▼決定
・予約一覧の並び順＝利用開始日時の昇順
・結合テスト開始＝10/19(月)
▼ToDo
・@鈴木 並び順の修正とレビュー依頼（10/7）
・@高橋 テストデータ30件の作成（10/14）
・@田中 通知メール文面の確認依頼（10/9）
▼宿題
・@鈴木 カレンダー連携で取得できる項目の確認（10/9）
全文：（議事録の保存場所）
認識の違いがあれば、明日12時までにこのスレッドへお願いします。

欠席者への補足

伊藤さん

本日の定例の議事録です。伊藤さんに関係する点は次の1件です。
・権限の区分は、10/13(火) の定例で伊藤さんの意見を聞いて決めることになりました。
 当日までに、現在の案（資料5ページ）へのご意見をまとめておいていただけますか。
全文：（議事録の保存場所）

文字起こしから議事録に整えるプロンプトのテンプレート

会議の録音を文字起こしした文章は、生成 AI に渡して議事録の下書きに整えられます。出力の見出しと表の列を指定し、書かれていないことを補わないよう指示するのがポイントです。かっこの部分を書き換えて使います。

あなたは会議の記録係です。下の文字起こしから議事録の下書きを作ってください。

# 会議の情報
- 件名: （例：備品予約システム 週次定例）
- 日時: （例：2026-10-05 10:00〜10:30）
- 出席: （例：佐藤、鈴木、高橋、田中）
- 欠席: （例：伊藤）

# 出力の形式（Markdown。見出しはこの順番と名前で固定）
## 決定事項
番号つきで、「〜とする。」で終える。
## ToDo
| No | 内容 | 担当 | 期限 | 状態 | の表。内容は動詞で終える。担当は1名。期限は YYYY-MM-DD。状態は「未着手」。
## 保留
見送った事項と、再び判断する時期または条件。
## 宿題
| No | 確認すること | 担当 | 回答日 | の表。
## 議論の要点
決定に至った理由と、出た案を箇条書きで5行以内。
## 確認が必要な点
文字起こしから読み取れなかった担当・期限・固有名詞を、質問の形で列挙する。

# 守ること
- 文字起こしに無い内容を補わない。担当や期限が話されていない場合は「（要確認）」と書き、「確認が必要な点」に挙げる。
- 「来週」「明日」などは、会議の日付をもとに日付に直す。直せない場合は「（要確認）」と書く。
- 雑談、相づち、言い直しは含めない。
- 人名と数字は文字起こしの表記のまま書き、聞き間違いの可能性があるものは「確認が必要な点」に挙げる。
- 該当が無い見出しは「なし」と書く。

# 文字起こし
（ここに貼り付ける）

生成 AI が作った下書きは、そのまま送らずに次の点を人が確認します。

また、社外秘の内容を外部のサービスに入力してよいかは、所属先のルールに従って判断します。

会議の前・中・後にやること

終了5分前の読み上げは、効果の大きい手順です。「担当：誰か」「期限：早めに」のまま会議が終わると、後から個別に聞いて回る手間がかかります。その場で読み上げれば、30秒ほどで埋まります。

よくある質問

Q. 議事録はいつまでに送ればよいですか？ A. 当日中が目安で、遅くとも翌営業日の午前までに送ります。時間がたつほど出席者の記憶が薄れ、認識の違いを指摘してもらいにくくなります。全文が間に合わない場合は、決定事項と ToDo だけを先にチャットで共有し、全文を後から送る方法もあります。

Q. 発言者の名前は書いたほうがよいですか？ A. 決定事項と ToDo には不要です。議論の要点で「誰の意見か」が判断に関わる場合（利用部門の要望、責任者の判断など）にだけ、名前か立場を書きます。発言を順番にすべて残す必要がある会議は、文字起こしを別に保存し、議事録には要点を書く形が読みやすくなります。

Q. 「検討する」と決まった事項は、どの区分に書きますか？ A. 検討する人と期限が決まっていれば ToDo か宿題、決まっていなければ保留です。「検討する」のまま書くと終わりが判定できないため、「A 案と B 案の工数を比較し、10/13 の定例で報告する」のように、何を出せば完了かが分かる文に直します。

Q. Markdown とプレーンテキストは、どちらで書くのがよいですか？ A. 保存先に合わせます。GitHub や Wiki など Markdown を表示できる場所に残すなら Markdown、メール本文に書くならプレーンテキストが崩れません。Markdown で書いておくと、この記事のスクリプトのように ToDo 表を機械的に取り出せる利点があります。

まとめ

• 議事録は発言の記録ではなく、決定事項・ToDo・保留・宿題の4区分に仕分けた文書として書く。
• 決定事項は「〜とする。」、ToDo は「動詞＋担当1名＋日付の期限」にそろえる。
• 保留には再び判断する時期か条件を、宿題には回答日を必ず書く。
• 会議の種類ごとに欄を変える。定例は前回 ToDo、ヒアリングは未確定事項、設計レビューは指摘一覧と判定、障害振り返りは時系列、キックオフは役割とルール、1on1 は共有範囲が要点。
• ToDo と宿題は課題管理表（10列）に集める。 Markdown で書いておけば、スクリプトでタブ区切りに変換できる。
• 送付文の本文に決定事項と ToDo の要点を書き、確認の期限を添える。
• 文字起こしを生成 AI で整えるときは、出力の形式を固定し、書かれていないことを補わない指示を入れ、担当・期限・数字を人が確認する。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。