要約の書き方：3Dフレームワーク実践ガイド
要約
ビジネスの要約の書き方は、学校で習ったものと根本的に違う。Decision・Delta・Dueの3Dフレームワークを使えば、ミーティング要約からディールレビューまで、どのタイプも核心を先に届ける。AIコマンドとの組み合わせで、会議終了から送信まで8分。読まれなかった長文要約に費やしていた週3〜4時間を解消できる。
要約の書き方を正しく理解すると、会議後のSlackスレッドが劇的に減る。 このガイドは学生向けではなく、GTMオペレーター向けだ。ディールレビュー、QBR準備、リサーチのハンドオフ、それぞれの要約には異なるルールがある。決定を先頭に置き、オーナーと期限を説明より前に書く。Slackのメッセージに収まる長さで仕上げる。毎週書く4種類の要約に対応したフォーマットと、AIコマンドで90秒でドラフトを完成させる方法を解説する。
学校で習った要約とビジネスの要約はまったく別物
Series A SaaSの6人規模GTMチームのオンボーディングを担当したとき、3ヶ月後に彼らのミーティング後ドキュメントを確認した。そこで見たもの：長い文章形式の要約、議事録のように書かれ、24時間後に送られ、全員にCC、アクションアイテムには担当者の名前なし。
誰も読んでいなかった。チームリードも読まれていないとわかっていた。それでも「書くべき気がする」という理由で書き続けていた。
問題は努力の量ではなく、フォーマットだった。学術的な要約は理解の証明だ。ビジネス要約はコーディネーションのためにある。分散したチームが「次に何をすべきか」を追加のSlackスレッドなしで把握できるようにする。
違いは明確だ。学術版：「会議ではQ3パイプラインレビュー、EMEAリージョンの課題、CSチームによる更新バックログの報告が行われました。」オペレーション版：「決定：EMEAアウトバウンドを加速。オーナー：Marcus（AEリード）。期限：金曜EOD。CSバックログ問題：次スプリントに延期。」
同じ会議。17語少ない。曖昧さゼロ。
毎週書く4種類の要約
全ての要約を同じものとして扱うのが最初の間違いだ。
ミーティング要約。 標準フォーマット。決定事項、オーナー付きアクションアイテム、次回ミーティング日時をカバーする。最大200文字。送信は2時間以内、24時間後ではない。
ディールレビュー要約。 パイプラインレビューまたはコールデブリーフ後に書く。ディールステージの更新、ブロッカー、次のステップ、確率の変化をカバー。通常はメールスレッドではなくCRM（顧客管理システム）ノートに入れる。最大150文字。
リサーチハンドオフ要約。 プロスペクトや競合リサーチをAE、CSリード、SDRに渡す際に書く。何を見つけたか、ピッチへの意味、省略できる部分をカバー。最大300文字。受け取り側がソースドキュメントを読まずに動ける十分なコンテキストが必要だ。
非同期ステータス更新。 ステータスミーティングの代わりになる週次または隔週の書面更新。何をリリースしたか、何がブロックされているか、次は何かをカバー。最大250文字。月曜のボードコール前に、マネージャーが金曜夕方に読むフォーマットだ。
各フォーマットには異なるオーディエンスと第一優先の問いがある。ミーティング要約：「何に合意したか？」ディールレビュー：「このディールは今どこにあるか？」リサーチハンドオフ：「このコールの前に何を知っておくべきか？」非同期更新：「順調に進んでいるか？」
コンテキストに合わないフォーマットで書いた要約は、内容が正確でも無視される。
3Dフレームワーク：Decision、Delta、Due
4つのタイプすべてに対して、1つのフレームワークが機能する。3Dフレームワーク：Decision（決定）、Delta（変化）、Due（期限）だ。
Decision（決定）： 何が解決、選択、確定されたか。「価格について話し合った」ではなく、「Q3ディールターゲットを240万円から280万円に設定した」のように書く。
Delta（変化）： 前回からの変化。最もよく省略される要素だ。オペレーターは前回のミーティングにいたから忘れがちだが、読み手はいなかったかもしれないし、忘れているかもしれない。Deltaが答えるのは：「先週と違って今日は何が変わったか？」
Due（期限）： 次のアクションはいつ、誰が担うか。名前一つ、日付一つ。「チームがフォローアップする」ではなく、「Priyaは木曜正午までに改訂comp分析を提出する」のように書く。
この3行を先に書く。それから、読み手がアクションするために必要な場合のみコンテキストを追加する。ほとんどの場合、追加は不要だ。Decision-Delta-Dueブロックが要約本体だ。残りはすべて付録だ。
ディールレビューの3D要約例：
Decision（決定）： ステージ4に進める、今週中にカスタム価格資料を送付する。
Delta（変化）： 先週のコール後、チャンピオンがITからCFOに変わった。予算権限者が変更になった。
Due（期限）： Alexが水曜までに価格資料を送付。Priyaが木曜までにCFOとのイントロをスケジュールする。
44文字。読まれる。同じ会議の400文字のナラティブ要約は読まれない。
要約が失敗する原因はほぼ同じ場所にある
ほぼ必ずアクションアイテムリストだ。
壊れたアクションアイテムの例：「クライアントにフォローアップする。」4文字、オーナーゼロ。1週間後、誰もフォローアップしていない。
修正済みの例：「Derekが金曜午後5時（東京時間）までにcontact@client.comへ改訂SLA文書を送付する。」
名前付き担当者。名前付きタスク。名前付き宛先。タイムゾーン付き期限。曖昧から具体への変換が、行動を促す要約と、コーディネーションの幻想を生む要約の違いだ。
2番目の崩壊ポイント：タイミング。ミーティング24時間後に送られた要約はほぼ無意味だ。人々は次の問題に移っている。書面記録がないせいで、決定事項がもうSlackで疑問視されている。2時間以内に送る。理想的にはミーティングのコンテキストを離れる前に。
3番目の崩壊ポイント：配布。アクションアイテムが3人しかない20人全員にフルの要約を送ると、ノイズが生まれる。タスクのない17人は将来の要約を読まなくなる。セグメント化する：コアグループにフルドキュメントを送り、広範なリストには3ブレットの抜粋を送る。
AIを使えば90秒以内に要約を作成できる
CommanderGPTを使っているオペレーションチームで実践しているプレイブックだ。
ステップ1。 ミーティング中にラフなメモを取る。Decision、Delta、Dueのポイントをとらえるだけで十分だ。書き起こしは不要。10〜15のフラグメント形式のブレットを目標にする。
ステップ2。 ミーティング後、メモを/summarizeコマンドに貼り付け、このプロンプトサフィックスを追加する：「フォーマット：1. 決定 2. 前回セッションからの変化 3. アクションアイテム（オーナーと期限付き）。最大200文字。前置き不要。」
ステップ3。 出力を読む。オーナー名と日付を修正する（メモが曖昧だった場合、モデルがこれを一般化することがある）。送信する。
ミーティング終了から要約送信までの合計時間：8分。過去6ヶ月で3つのクライアントチームで計測した。入力メモの質によって6〜12分の範囲だった。
レバレッジはプロンプトサフィックスにある、ベースコマンドではない。汎用の/summarizeは大幅な編集が必要な散文要約を返す。構造化されたサフィックスが3Dアウトプットフォーマットを強制するため、モデルの出力が再フォーマットなしに必要なものと直接対応する。
カスタムスラッシュコマンドがない場合、AIインターフェースに保存したプロンプトテンプレートで80%は達成できる。CommanderGPTが追加する違いは、プロンプトが共有チームプレイブックに存在することだ。チームのAE、CSリード、SDR全員が、毎回サフィックスを追加することなく同じフォーマットを実行できる。そのスケールでの一貫性が、同じチーム内で複数の異なる要約フォーマットが乱立する問題を解決する。
要約を確実に読まれる形で配布する
送信することと配布することは違う。多くのオペレーターはこれを混同している。
8つの他のメッセージがあるメールスレッドに届いた要約は、その日には読まれない。決定事項がピンされ、アクションアイテムが直接オーナーにスレッドされた正しいSlackチャンネルに投稿された要約は、15分以内に読まれる。
GTMオペレーションチームで機能する配布フォーマット：
ミーティング専用SlackチャンネルまたはNotionページにフルの3D要約を投稿する
アクションオーナーがアクティブなチャンネルに3ブレット抜粋を送る：決定事項、次のアクション、誰がいつまでにするか
チャンネルではなく、アクションアイテムのオーナーに直接タスクをタグ付けする
これにより2つのレイヤーが生まれる：説明責任と参照のためのフルレコードと、アクションが必要な人への的を絞った通知だ。誰もタスクを見つけるためにフルの要約を掘り起こす必要がない。
週次非同期更新の場合、配布はさらに絞る。マネージャーは15のブレットポイントを必要としていない。必要なのは：リリース済み、ブロック中、次のアクション。3行だ。詳細が欲しければ、フルドキュメントの場所はわかっている。
次のコマンド：自走する要約ワークフローを構築する
この問題を恒久的に解決したオペレーターには共通点がある。要約を一発書きのタスクとして扱うのをやめ、パイプラインとして扱い始めたことだ。
インプット：イベント中に取得したラフなメモ。プロセス：固定フォーマットサフィックス付きのAIコマンド。アウトプット：送信準備済みの3D要約。配布：2レイヤーアプローチ（フルレコードと的を絞った抜粋）。アーカイブ：関連するNotionページまたはCRMフィールドにタグ付け。
パイプライン全体が、ミーティング1回、ディールレビュー1件、リサーチハンドオフ1件につき10分未満で動く。スケールでは、1人のオペレーターあたり週8〜12件の要約イベントで、ドキュメント時間は最大120分だ。体系化する前、担当するチームは結局誰も読まなかったドキュメントに週3〜4時間を費やしていた。
3Dフレームワークをフォークする。フォーマットサフィックス付きの/summarizeコマンドを構築する。2レイヤー配布を設定する。2週間実行し、費やした時間と受けた確認Slackの数を計測する。5日目には機能しているかどうかがわかる。