議事録 テンプレート 無料：3セクションの基本構成

議事録 テンプレート 無料 で検索すると多くの選択肢が出てくる。だが実際に機能するものは少ない。ops チームが週次シンク、ディールレビュー、QBR で使えるテンプレートに必要なのはシンプルだ。決定事項・担当者と期限付きのアクションアイテム・持ち越し事項の3セクション。この記事ではそのテンプレートの構成と、CommanderGPT の /meeting-minutes コマンドで後処理を10分以内に終わらせる方法を解説する。

ほとんどの議事録テンプレートが機能しない理由

GTM ops と CS ops チームで繰り返し見てきたパターンがある。誰かが Notion にドキュメントを作り、テンプレートを貼り付け、ノートテイカーをローテーションで決める。2週間後にはテンプレートが白紙か、誰も読まない長文段落で埋まっている。問題はフォーマットではない。ほとんどのテンプレートが「話された内容」を記録するために設計されていることだ。

ops チームにトランスクリプトは要らない。名前付きの意思決定ログが要る。

2つ目の失敗パターンはオーナーシップの欠如だ。担当者のないアクションアイテムはただの希望リストだ。完璧に構造化されたテンプレートを使っていても、3日後に「火曜のシンクでXはどうなった？」という Slack メッセージを送ることになる。テンプレートが「価格戦略を議論」と記録しているからだ。「Mayaが金曜までに価格デッキを更新」と書いていれば、この追いかけっこは発生しない。

3つ目の失敗は速度だ。会議から72時間後に共有された議事録は考古学だ。その頃には2つのフォローアップスレッドが走り、誰かが独断で決めていて、議事録はそれを後付けで正当化するためだけに存在する。目標は24時間以内、理想は当日だ。

アジェンダ項目ごとに文章で要約するテンプレートはスキップしていい。それは会議後45分かけた文章作成だ。誰も頼んでいない要約を作っているだけだ。

ops テンプレートに必要な3セクション構成

すべてを3セクションに絞り込む。3つ以上のセクションがあるなら、それは作業文書ではなくレポートだ。

セクション1：決定事項

「議論された内容」ではなく「決定した内容」のみを列挙する。1行1決定、現在形で書く。例：「価格ティア3はQ4に月額$149でローンチ。担当：Derek。」

このセクションは、会議に出席できなかったメンバーが最初に開く場所だ。30秒で読めるべきだ。

セクション2：アクションアイテム

すべてのアクションアイテムには例外なく3つのフィールドが必要だ。

• タスク（何を）

• 担当者（誰が：チームではなく個人名1名）

• 期限（いつ：「来週」ではなく具体的な日付）

3つのフィールドすべてを埋められなければ、そのアクションアイテムはまだログに記録する状態ではない。会議中に押し戻して、具体化してから次に進む。

セクション3：持ち越し事項

ほとんどのテンプレートが省いていて、ほとんどの ops チームが後悔するセクションだ。浮上したが解決されなかったトピックを、「なぜ持ち越したか」と「誰が次回持ち込むか」の注釈付きで記録する。このセクションがないと、持ち越し事項は静かに消えるか、同じ20分を費やして3回以上の会議に再浮上する。

ミーティングタイプ別：4つのテンプレート形式

すべての会議が同じ構造を必要とするわけではない。ops チームが最もよく遭遇する4つのフォーマットを紹介する。

週次シンクテンプレート

シンプルで速い。5つのフィールド：日付、参加者、決定事項、アクションアイテム、次回シンク日。アジェンダセクションは不要。アジェンダはカレンダー招待の中にある。要約段落はスキップ。記入時間：ライブで8〜10分。

向いている会議：週次スタンドアップ、スプリントレビュー、パイプラインシンク。

省いてよいもの：誰が何を言ったかのナレーティブな要約。会議を欠席した人には、3文の Slack サマリー（後述）の方が3段落の要約より速く読める。

ディールレビューテンプレート

フィールドを2つ追加する：ディール名/リンクと、ディールが現在どこにあるかの1文コンテキスト。決定事項セクションは「依頼事項」のリストになる。AEがこのディールを進めるためにopsから何が必要か？アクションアイテムはディールステージ要件に直接マップされる。ディールレビューの議事録はCRMにフィードされるべきだ。統合が構築されていなければ手動で、構築されていれば自動化で。

向いている会議：パイプラインレビュー、オポチュニティレビュー、ディールデスクセッション。

QBRテンプレート

より長い構成が有効なフォーマットだ。コンテキスト指標セクションを追加する：四半期のトップ3の数字を会議前に記入しておき、共有データから議論をスタートさせる。コミットメントvs結果の独立したセクションも追加する。

アクションアイテムセクションは思ったより軽くていい。18個のアクションアイテムを生成するQBRは、18個の完了しない事項を生成している。DRI（直接責任者）と四半期ターゲット日付付きで、5つのコミットメント事項に上限を設ける。

向いている会議：四半期ビジネスレビュー、取締役会アップデート、クロスファンクショナル振り返り。

レトロスペクティブテンプレート

「決定事項」を「うまくいったこと」と「変えるべきこと」に置き換える。それぞれ1〜3つの具体例を添える。ここでのアクションアイテムは次のスプリントまたは次の四半期のプレイブックに直接フィードされる。持ち越し事項セクションはレトロで特に重要だ。すぐに対処が必要ない低優先度の摩擦ポイントをここに記録し、次の四半期レトロで確認する。

向いている会議：スプリントレトロ、ポストモーテム、プロジェクト完了振り返り。

ノートテイカーのローテーションをやめる：/meeting-minutes コマンドを作る

ローテーションするノートテイカーはチームへの隠れた課税だ。ノートを取る人は会議に完全に参加できない。ドラフトのクリーンアップに30〜45分費やす。その週に担当になった人によってクオリティが変わる。

代替案：1人が生のディスカッションノートまたはAIトランスクリプトを CommanderGPT に貼り付けて /meeting-minutes を実行する。コマンドはテンプレート形式で構造化されたアウトプットを返す。決定事項、会話から抽出された担当者付きアクションアイテム、自動的にフラグされた持ち越し事項。

ステップ1：CommanderGPT でコマンドを作成する

コマンドライブラリを開き、/meeting-minutes を作成して、以下のインストラクションブロックを追加する：

You are an ops lead turning raw meeting notes into a structured minutes doc.

Extract and format:
1. DECISIONS MADE: what was decided, one line each, present tense, with owner if mentioned
2. ACTION ITEMS: task | owner | due date (one per row, due date required; infer from context if stated, flag as [TBD] if not)
3. DEFERRED ITEMS: topics raised but not resolved, with reason and who brings it back

Output format: clean markdown, no preamble, no summary paragraph.
Format for Notion / Google Docs paste.

ステップ2：毎回の会議後に実行する

生のノートをコピーするか、文字起こしツールからのAIトランスクリプトを貼り付ける。/meeting-minutes を実行する。2〜3分でアウトプットを確認し、誤って抽出されたオーナー名を修正し、モデルが見落とした決定事項を追加する。Notion または Google Docs のテンプレートに貼り付ける。

ステップ3：/summarize と連携して非同期配布する

/meeting-minutes の後に、アウトプットに対して /summarize を実行し、Slackチャンネル用の3文非同期アップデートを生成する。フォーマット：何が決まったか、何が動いているか、何がブロックされているか。1時間以内に関連チャンネルに投稿する。生のノートから配布済み議事録まで10分以内。

3コマンド、1ワークフロー、0フリクション。

会議後24時間以内にやること

テンプレートは会議終了後に何をするかで初めて価値を発揮する。

当日中：3文の Slack サマリーを非同期投稿する（/summarize から）。会議を欠席した人をキャッチし、「何が起きた？」スレッドの発生を防ぐ。

24時間以内：完全な議事録ドキュメントを共有する。非同期サマリーの Slack スレッドにリンクを貼る。アクションアイテムをタスク管理ツール（Linear、Notion、ClickUp）に直接貼り付ける。議事録ドキュメントを読んでもらうのではなく、仕事が既に行われている場所にタスクを浮かび上がらせる。

次の会議まで：次のシンクの前に、前回のアクションアイテムを /status-check コマンドに貼り付けるか手動でレビューし、「何がクローズしたか？何がブロックされているか？」という定番アジェンダ項目を追加する。これでループが閉じ、テンプレートが一度開かれて更新されない静的ドキュメントではなく、生きた記録になる。

はっきり言っておくことがある。議事録のアクションアイテムが繰り返しクローズされないなら、問題はテンプレートではない。オーナーシップが不明確か、期限が非現実的か、そもそも会議でコミットメントされていないかだ。テンプレートはこのパターンをすぐに可視化する。だが修正するには、より良い Notion の設定ではなく、チームの意思決定方法についての会話が必要だ。

今すぐデプロイする次のコマンド

上の3セクションテンプレートから始める。チームのベースラインとして Notion または Google Docs にコピーする。今週 CommanderGPT で /meeting-minutes コマンドを構築する。設定に約10分かかり、最初の会議後から同じ時間を節約できる。

3〜4回の会議で実行した後、何を調整すべきかわかる。チームがオーナーを明示せずに口頭で行う傾向がある決定はどれか。より長いまたは短いフォーマットが必要な会議タイプはどれか。持ち越し事項セクションが実際に重要なフリクションを浮かび上がらせているかどうか。

2つの方法で測定する。会議終了から議事録配布までの時間（目標：24時間以内）と、次の会議前にクローズするアクションアイテムの割合。非公式な議事録を使っているほとんどのチームはクロージャー率40〜50%だ。名前付きオーナーのある構造化テンプレートは、通常1ヶ月以内に65〜75%に移行する。テンプレートが魔法なのではなく、明示的なオーナーシップが会議での会話自体を変えるからだ。

テンプレートは簡単な部分だ。規律はコマンドを例外なく毎回実行し、クローズしないものをレビューすることだ。