ライブ議事録で会議を回す——全員編集ドキュメントを軸にしたミーティング運営

[!NOTE] Slack でのコミュニティ内議論をきっかけに、普段やっているやり方を Claude を活用して整理したものです。本記事に登場する議事録サンプル（および後述の Google Docs）は、すべて 架空のプロジェクト をもとにしたものです。この記事は Zenn にも公開しています: Zenn 版を読む

はじめに

この記事は、「会議に呼ばれたけど何が決まったのか結局わからない」「AIに議事録を生成させているけど誰も見返していない」 といった経験のある方を対象にしています。

きっかけは、ドン・キホーテの「マジボイス実現委員会」の以下のような一節が Slack で話題になったことでした。

なんで具体的な改善プランを持って来ないんですか？お客様から「香りが弱い」「コクが弱い」という声を頂いているのであれば、「なぜそれが起こったのか」を分析して、原因を見つけて改善するのがこの会議の一丁目一番地ですよね？ — マジボイス実現委員会 | 記事詳細

これに対して仲間内で出てきた「会議は決める場」「ゆるふわで招集される会議は時間の無駄」という共通認識があり、では具体的にどう運営すれば「決まる会議」になるのか、運営方法を共有することにしました。

全員編集権限のある議事録を投影しながら、その場で書き、その場で認識を合わせて解散する というやり方が、一番ワークしています。

1. なぜ「会議後に AI で議事録」だと不十分なのか

最近は、録音 → 文字起こし → AI で議事録生成、というワークフローを採用している組織も多いと思います。便利ではあるのですが、現場で運用していると以下の課題が見えてきます。

1.1. ほとんど見返されない

きれいな議事録ができても、誰も読み返さない ことが多い。強弱なくまとめられたテキストは、後から「あの件どうなったっけ？」と参照するには情報密度が高すぎます。検索用のログとしては有用でも、認識合わせの道具としては機能しにくい。

1.2. 「誰が・何を・いつまでに」が落ちやすい

AI 議事録運用で一番痛いのは、TODO（誰が、何をするか）が結果として落ちる ことです。落ち方には大きく 2 パターンあります。

ボールが浮く: 「じゃあそれ、誰がやる？」が暗黙のまま流れてしまい、結局誰も着手していない。会議中に発生していない事実を AI に起こさせるのは無理なので、AI 議事録にも出てこない
ボールの持ち主認識がズレる: A さんは「B さんがやる」と思い、B さんは「A さんがやる」と思っている。会議では「やっておきます」のような曖昧な発話だけで進み、AI 議事録もそれをそのまま文字にしてしまう

どちらの場合も、会議の場で 「これは誰が、いつまでに、何をやるか」 を声に出して文字にして、全員でその文字列を見る、というステップを踏まないと検出できません。事後に AI が起こす議事録では、すでに発生したズレや欠落を救えないのです。

1.3. 認識のズレがその場で解消されない

1.2 は TODO（担当・期限・内容）に関するズレの話でしたが、ここで扱うのは TODO 以外の認識ズレ です。

会議後に議事録が出てくる方式だと、「実は同じ言葉で違うものを指していた」 ことに後から気づくことがあります。スコープの狭間にある認識合わせは、その場で文字にして「これで合ってますか？」と確認しないと、検出できません。

つまり、AI 議事録は 会議の質が高いことが前提 で、ゆるふわな会議の救済策にはならない、というのが実感です。

2. ライブ議事録方式のやり方

ここからが本題です。やっていることは非常にシンプルで、以下の通りです。

2.1. 全員が編集権限を持つドキュメントを 1 枚用意する

Google Docs を使っています。Notion / 社内 Wiki / その他クラウド型のドキュメントツールでも、以下の条件を満たせば何でも OK です。

全員に編集権限 を付与しておく （重要）
同じファイルをずっと使い続ける。回を重ねるごとに上に追記していく
複数人が同時に編集してもレイアウトが崩れない（リアルタイム共同編集ができる）

「同じファイルを更新し続ける」ことが大切です。前回の議事録、その前の議事録、決まった TODO がすべて 1 つのスクロールで辿れるので、前回参照のコストがほぼゼロ になります。

2.2. ファシリテーターが事前にアジェンダを書く

実は、ライブ議事録方式が機能する一番の前提は、ここのアジェンダ整理です。会議の曖昧さを除去するのはアジェンダ であって、議事録テクニックはその上に乗っているにすぎません。

会議の前に、ファシリテーターが 議題を整理した状態 でドキュメントを用意
参加者には 事前配布（リンクを共有 or Slack に投げる）

事前にアジェンダがあると、2 つの効果があります。

参加者が 「自分は何を決めに行くのか」 を考えてから来られる。これだけで会議の濃度がだいぶ変わる
アジェンダを見た参加者が Slack 上で先に議論・合意 できる。そうなれば会議自体をスキップできる。「集まらなくても決まった」は最高の会議運営です

定例会の場合：開催判断はファシリテーターに委ねる

定例会は「曜日と時間が決まっているから集まる」という運用になりがちですが、これだと議題のない回でも惰性で開催されてしまいます。以下のような運用にすると無駄が減ります。

定例会も 開催の都度ファシリテーターがアジェンダを整理 する
ファシリテーターが「議題がない」と判断したら スキップして良い
次回を開催するかどうかは、会議の最後に決める（その時点で判断できなければ前日や当日朝でも OK）
議題が早く片付いたら 30 分枠でも 10 分で終わって OK。時間を埋めにいかない

「議題がなければやらない」「片付いたら早めに終わる」という運用にすると、ファシリテーターが議題を真面目に集める動機ができ、参加者側も「呼ばれたということは決めることがある」と認識できます。

日程は固定するか、プロジェクト終了まで先に押さえる

定例会をやると決めたら、日程調整のコストを下げる工夫もセットでやっておきます。

曜日と時間帯を固定 する（例: 毎週火曜 10:00-10:30）
固定が難しい案件なら、プロジェクト終了までの全回をまとめて日程調整 する

毎回ゼロから日程調整をすると、それだけで時間が溶けます。固定 or 一括押さえにしておけば、後は「今回はやる／やらない」を直前に判断するだけになり、運用が軽くなります。

2.3. 前回の TODO は各担当者が事前に進捗を書いておく

次回の会議までに完了すべき TODO（宿題）は、会議が始まる前に各担当者が進捗を記入 しておきます。冒頭で「前回の TODO どうなりました？」と口頭で確認するだけだと、状況が曖昧なまま流れがちです。事前に書いてあれば、会議の冒頭はそれを見て確認するだけで済み、すぐに本題に入れます。

前回 TODO 進捗を各担当者が会議前に記入した例

各 TODO の下に 済。… と進捗をぶら下げておくイメージです。

2.4. 会議中はファシリテーターが書く（が、誰が書いても良い）

ドキュメントを画面共有 or プロジェクター投影
基本はファシリテーターが議論を聞きながら その場でタイピング
補足・修正は 誰が書き込んでも OK（全員編集権限なので）

タイピングしている人は議論への参加が薄くなる、という指摘もあります。これは確かにそうで、全員編集にしておくことで、ファシリテーターが議論に集中したい瞬間は他の人が書く という分散ができるのが利点です。

2.5. 決まったことはその場で書く

「じゃあこれは A 案で」と決まったら、その瞬間にドキュメントへ書く
書いたものを画面で見せながら 「これで合ってますか？」 と確認
ズレていたら、その場で修正

これが最重要ポイントです。書いた瞬間に認識合わせが起こる ので、会議が終わった後に「実はそうじゃなかった」が発生しにくくなります。

2.6.（オプション）最後に TODO を一覧で確認する

2.5 までやれていれば、TODO は各議題のすぐ下にインラインで残っているので、必須の手順ではありません。ただし、会議の最後に TODO だけを見渡して「これで全部？」と確認する ステップを入れると、抜け漏れの検出に効きます。

会議の最後にスクロールして TODO を一覧で確認する。必要なら最終 TODO 一覧セクションをまとめて作っても良い
セクション名自体が「TODO」なので、毎行に TODO: プレフィックスを付ける必要はない（議題のインラインに書くときだけ TODO: を付ける）
フォーマット例: [担当者] [いつまでに] [何を]

[!TIP] コラム: TODO は「色」じゃなくて「文字」で目立たせる

以前は 黄色ハイライト + 赤文字 で目立たせていましたが、LLM との協業（TODO 抽出、未決事項の一覧化など）を前提にすると、LLM フレンドリーにテキスト情報として残した方が良さそうです。
❌ 色だけで目立たせる
   （赤字で）来週までに API 仕様を確定する

✅ 文字列で表現する
   TODO: [担当: ○○] [期限: 2026-05-07] API 仕様を確定する
TODO: DECIDED: OPEN: のようなプレフィックスを統一しておくと、後から人間でも LLM でも検索が容易になります。色で目立たせるのは「人間の目に止めるため」の補助手段です。情報は文字列で持つ のが、AI 時代のドキュメント運用としては安全です。

2.7. 実際のフォーマット例

実際に使っている Google Docs のサンプルを、会議前（左） と 会議後（右） で並べました。左（会議前）は当回（06/10）がまだアジェンダだけ。右（会議後）は各議題の下に決定・TODO・DECIDED が追記されています（会議中にその場で書いた部分を、この図とリンク先の Doc では分かりやすさのため赤字にしています。実際の運用では後述のコラムの通り、色ではなく文字で表現します）。

会議前（左）と会議後（右）のサンプル議事録

全文は以下から開けます（どちらも閲覧専用）。

会議前（アジェンダ配布時点）

会議前のサンプル議事録を開く（Google Docs・閲覧専用）

会議後（決定・TODO が埋まった状態）

会議後のサンプル議事録を開く（Google Docs・閲覧専用）

サンプルの構成は次の通りです（上の 2 つの Doc を見比べると分かります）。

会議前に配布した内容: アジェンダと、各議題の 決めたいこと ＋ 選択肢/案
前回 TODO 進捗 も会議前に用意する。各担当者が事前に進捗を記入しておく（→ 2.3）
会議中に追記する内容: 各議題の下に、決定・TODO・補足をその場で書き足す。TODO には TODO: プレフィックスを付けて該当議題にぶら下げる

実運用で効いたポイントは以下です。

各議題に 決めたいこと + 案 まで書いておくのが本番。案が事前にあるからこそ、会議中は 「A か B か」 の決断に集中できる
議論ログは捨てない。決定に至った経緯を議題の下に残しておくと、「なぜそう決まったか」が後から振り返れる
議論のすべてに TODO を付ける必要はない。「前回は名刺 120 枚」「来場者は 1 ブース平均 2〜3 分」のような 背景事実はメモとして残すだけ で、TODO はアクションが発生した行にだけ付ける
よく使う URL（Google Meet のリンク、関連ドキュメントなど）は 冒頭の「関連リンク」に集約。各回のメモから個別にリンクを張ると後で迷子になる

3. ライブ議事録 vs AI 議事録の比較

観点	ライブ議事録（その場で書く）	AI 議事録（事後に生成）
認識合わせ	会議中に完了	事後に齟齬が判明することがある
TODO の明確さ	その場で全員確認	抽出精度に依存
見返しやすさ	同一ファイルで時系列に蓄積	ファイルが分散しがち
ファシリテーター負荷	高い（タイピングしながら進行）	低い（録音だけ）
会議の質への要求	中（書ける程度に整理されていればよい）	高（質が低いと AI も拾えない）

両者は対立するものではなく、ライブ議事録をベースにしつつ、AI 文字起こしを補助 として使うのが実用的だと思っています。

4. それでもライブで書ききれないとき

タイピングが追いつかない、議論が白熱している、といった場面は当然あります。そういう時に ライブ文字起こし → 定期的に要約 が補助として機能する余地はあります。

イメージとしては、

文字起こしは裏でずっと走らせておく
5〜10 分に 1 度、AI が 要点と未決事項 を抽出してドキュメントに追記
ファシリテーターはそれを見て、必要なものだけ正式な議事録セクションに昇格させる

このあたりはツール化の余地があり、いずれ Skill / プラグインとして整理したいテーマです。

5. 関連リンク

ミーティング自体を減らす・最小化するという上位の方針については、以下を参考にしています。

ミーティング（会議）の進め方

要旨は「ミーティングは極力減らし、非同期コミュニケーションを優先する。どうしても必要なときだけ最小人数で開催する」というもので、本記事のライブ議事録方式は「開催すると決めた会議の質を上げる」レイヤーの話です。

まとめ

会議は 決める場。ゆるふわで集まらない
アジェンダは 事前配布、ファシリテーターは整理した状態で臨む
全員編集権限 のあるドキュメントを 1 枚、ずっと使い続ける
決まったことは その場で書いて、その場で確認 する
TODO は 色ではなく文字列 で目立たせる（LLM フレンドリーに）
会議が終わるまでに 誰が・何を・いつまでに が確定している状態で解散する

「会議後に AI に議事録を作らせる」は便利ですが、それだけでは会議の質は上がりません。決める場としての会議を取り戻すには、まず会議中に書ききって、その場で認識を合わせる、という地道な運営が一番効くというのが、今のところの結論です。