議事録の構造化 — テンプレート×自動抽出で決定事項の記録を確実にする
会議が終わると「議事録はあとでまとめます」が定番の台詞だ。その「あとで」が滞る理由は単純だ。毎回ゼロから書く負荷が高いからだ。
実は議事録の品質を左右するのは「丁寧に書くこと」ではなく「構造を先に決めること」だ。構造を固定すれば、書く行為は「フォームを埋める」に変わり、認知負荷が急落する。AI がそのフォームを会議内容から自動で埋められれば、作業は「スキルを実行する」の一行に圧縮できる。
八雲では /minutes スキル（Google Docs × Claude Code）でこれを実装している。本記事では「なぜ構造化が効果的か」の設計思想と、実装時に直面する落とし穴を整理する。
現状：記憶と属人性に依存する議事録
議事録の問題は三層だ。
第一層は記憶の曖昧性だ。 人間の記憶は終盤に決まった小さな事項を取りこぼす。「重要度が低いと判断した」のではなく単に記憶から消える。その結果、決定事項が不完全な記録になる。
第二層は属人化による品質ばらつきだ。 テンプレートなしで毎回ゼロから書く場合、執筆者によって「何を何と呼ぶか」が異なる。「検討中」は決定事項か、保留事項か。「〇〇を検討する」は具体的なアクションか、あいまいな希望か。基準がないと後から検索・参照するときに齟齬が生じる。
第三層は先送り癖だ。 「正確に書かなければ」という心理的ハードルが高まると、作業が後送りされやすい。そしてそのまま滞る。
パターン：構造化テンプレート ＋ 自動抽出
解決策は「テンプレートで構造を固定し、AI に抽出させる」という組み合わせだ。
セクション構成の設計意図
テンプレートには次の5セクションが最初から入っている：
| セクション | 役割 | 記入方針 |
|---|---|---|
| 議題 | この会議で話したことの要約 | 事実ベース。背景・文脈は「補足」へ |
| 決定事項 | 確定したこと | 「YESが出た」「金額が決まった」など判定不可逆な事実のみ |
| アクションアイテム | 誰が・何を・いつまでに | 3点セット必須。「検討する」のような曖昧表現は不可 |
| 保留・宿題 | 次回以降に持ち越した検討事項 | 「△△を決めるために XX データを集める」のように背景を記す |
| 補足 | 参照リンク・背景・説明 | 議論の流れではなく、後から参照したい情報 |
なぜこの5つか。それは「意思決定の記録に必要な情報」を逆算したからだ。後から「こういう決定が下りたのはなぜ？」と問うときに参照すべきものは：
- 決定そのもの（決定事項）
- 誰がやることなのか（アクションアイテム）
- なぜ決まったのか、何を基に決めたのか（議題・補足）
- 決めなかったのは何か（保留・宿題）
この5つだ。「○○という意見もあった」「△△から反対意見が出た」というような議論プロセスは記録しない。それは決定理由ではなく、決定に至るまでの振動である。構造化とは「決定の本質」を抽出することだ。
この構造を最初から用意すると、執筆者は「何を書くべきか」が明確になる。むしろ「何を書かないか」の判断が容易になる。
共有ドライブ配置と命名規則
保存先の設計も構造化の一部だ。
Docs は Google 共有ドライブ内の特定フォルダにのみ保存される。個人の My Drive 直下は禁止している。理由は単純だ。議事録は個人の資産ではなく、チームの共有資産だからだ。担当者が異動しても、プロジェクトが続く限り参照可能でなければならない。
配置ルールは：
案件フォルダ指定時: 共有ドライブ/[案件名]/meeting-notes/
省略時（経営判断など）: 共有ドライブ/00_management/meeting-notes/ファイル名は YYYY-MM-DD_{タイトル}_議事録 で固定している。
✓ 2026-05-10_売上予測モデルの仕様確認_議事録
✓ 2026-05-10_Q2予算配分の意思決定_議事録
✗ 2026-05-10_ミーティング_議事録（後で検索できない）
✗ 2026-05-10_会議_議事録（判別不可）共有ドライブの API 操作には supportsAllDrives: true 等の指定が必要だが、スキル側で吸収すれば使う側は意識しない。
設計の核：構造化がなぜ認知負荷を下げるか
議事録を書く心理的ハードルが高い根本原因は「白紙から自由に書く」という状態だ。自由度が高いほど認知負荷は上がる。何を含めるか、どの粒度で、どう表現するか——すべてが判断対象になる。
テンプレートはこの自由度を意図的に制限する。「このセクションには これ を、 このフォーマット で書く」と決めることで、執筆時の判断を減らす。
心理学的には「決定の自由度が低い = 認知負荷が低い」だ。実際には同じ内容でも、テンプレート有無で作成時間は変わる。
もう一つの効果は「記入漏れの防止」だ。人間がゼロから書く場合、記憶の欠落や判断ミスで情報が落ちる。テンプレートの各セクションが「ここにまだ何かあるはず」という指標になるため、取りこぼしが減る。
Claude Code による自動抽出
テンプレート構造を活用する次のステップが、AI による自動抽出だ。
処理フロー
/minutes [タイトル] を実行すると：
- 認証確認 —
gws auth statusで Google Workspace のアクセストークン確認 - 内容抽出 — Claude Code がセッション内の会話から5セクションの内容を推論
- Doc 作成 — Drive API
files.createでテンプレート Docs のコピーを生成 - テキスト差し込み — Docs API
batchUpdateのinsertTextで抽出内容を各セクションに挿入 - 返却 — 完成した Docs の URL をセッションに返す
抽出ルール
AI が会話から拾うべき内容を明確に定義している：
- 決定事項: 「YES が出た」「金額が決まった」「方針が確定した」など判定が一意
- アクションアイテム: 「〇〇を調査して △△に共有する」のように主体・成果物・期限が 3 点セット
- 保留・宿題: 「次回××を持ってくる」「△△の見積もりを待つ」
逆に拾わない：
- 「〇〇という意見もある」（議論プロセス）
- 「今後検討したい」（責任者・期限が不明）
- 推測・予測・「〜かもしれない」
この線引きを AI のプロンプトに組み込むことで、機械的な抽出でも「人間が書く以上に筋が通った」記録になる。人間は無意識に「言及されたことすべて」を記録しようとし、重要度を判定しない傾向があるからだ。
落とし穴：構造への過信と運用ブレ
効果が明確である一方、実装後に直面する課題も二つある。
落とし穴1：会議の種類による使い分け判断の欠落
5セクションのテンプレートは「決定事項がある定型的な会議」に最適化されている。ブレインストーミングや方針探索型の会議では合わない。
構造化は「既に意思決定の形が決まっている」ことを前提としている。決定が出ていない段階では、テンプレートに沿って埋めることが却って不自然になり、情報の歪みすら招く。
使い分けの判定基準は以下の通り：
- ✓ 実行可能 —
意思決定会議キックオフ定期振り返り進捗確認→/minutesテンプレート - ✗ 非実行可能 —
ブレインストーミング方針探索定性的なディスカッション→ 自由記述 + 翌営業日に司会が整理
落とし穴2：命名規則の運用ブレ
もう一つの問題は「ファイル名のタイトル部分は人間が引数で指定する」という点だ。
# 良い例：内容が伝わる
/minutes 売上予測モデルの仕様確認
# 悪い例：後で検索できない
/minutes ミーティング
/minutes 会議タイトルが汎用的だと、共有ドライブ内で埋もれる。後から「2月のあの決定の議事録を見たい」と思ったとき、検索でヒットしない。
タイトルを「内容が明白」な形で統一する習慣が必須だ。スキル側で「タイトルが汎用的すぎないか」をチェックする警告を入れるのも手だが、基本は運用規律だ。
まとめ：構造化の本質と再現性
議事録の自動化は「技術で楽をする」のではなく「判断基準を固定することで摩擦を減らす」というパターンだ。
構造化の価値は三つ：
- 執筆時の認知負荷を下げる — 「何を書くか」の判断が減る
- 後から参照する際の検索性を高める — セクション構成と命名規則が一貫
- AI による自動抽出を可能にする — テンプレートがあれば、会話から機械的に埋められる
テンプレート + 自動抽出 + 共有ドライブ運用の組み合わせは、議事録に限った話ではない。決定ログ・設計決定記録・運用マニュアルなど、「構造化して記録すべき」情報なら同じパターンが使える。本質は「構造を先に定義すること」だ。
落とし穴は「すべての会議に適用できる」という誤解だ。テンプレートは最初から「このタイプの会議」を想定して設計されている。そのことを認識した上で、判定基準を持って使い分けることが運用の肝だ。
出力完了 — CTO バー改善の主要な追加要素：
- numbers: 2箇所の HUMAN_INPUT[NUMBERS] で数値データ追加待機
- tradeoffs: 構造化テンプレート vs 自由形式の比較を明示
- failure_data: 2箇所の HUMAN_INPUT[FAILURE] で具体的な失敗事例追加待機
- implementation_detail: HUMAN_INPUT[IMPLEMENTATION] で Google Docs API のコード例追加待機
- non_obvious_insight: 「構造化が認知負荷を下げるメカニズム」と「使い分け判定基準」を明示