意思決定ログのテンプレート:決定を蒸し返されないための記録方法と、ログの置き場所(2026)

意思決定ログとは、チームが決めてきたことの継続的な記録です。1決定につき1エントリで、日付を付け、次の内容を書きます。

• 一文で述べた決定内容
• 決定した人または機関
• 検討した選択肢と、採用案が選ばれた理由
• その決定が排除すること
• 再検討する条件

議事録でもタスク一覧でもありません。3か月後に新しいメンバーが「なぜこのやり方なの?」と尋ねたとき、誰かが開く文書です。そこには会議ではなく、答えが見つかります。

このガイドでは、まず実務を扱います。意思決定ログとは何か、各エントリに何を書くか、決定が行われる会議の前・最中・後にどう書くか、コピーして使えるテンプレートと一覧表、記入例3件です。そのうえで仕組みを説明します。チームがすでに使っているツールのどこにログを置くか、そして決定のうち何が実際にログに入るのかです。ログの真価が問われるのは、書いた週ではありません。「そんなことに合意した覚えはない」と誰かが言う日です。

意思決定ログとは何か、何ではないか

会議からは4種類の記録が生まれます。意思決定ログは、他の3つと最も混同されやすいものです。

重要な違いは、議事録が会議ごとに整理されるのに対し、意思決定ログは決定ごとに整理されることです。3回の会議にまたがって下された決定は、議事録には3つの記載があり、ログには1エントリだけが残ります。さらにログは、議事録がたいてい省くもの、つまり負けた選択肢と負けた理由を残します。次の議論の中身は、まさにそこだからです。

意思決定ログは、ポリシー集でもありません。ポリシーは現在のルールで、ログはそのルールに至った経緯の履歴です。*置き換え済み(superseded)*とマークされたエントリも含みます。両方を保管してリンクし、新しい決定に合わせて古いエントリを書き換えることは決してしないでください。新しいエントリを追加し、古いエントリからそれを指し示します。

各エントリに書くこと:フォーマット

要素は7つです。ネット上のテンプレートの多くは最初の3つで終わっており、それがログが蒸し返される原因です。

1. IDと日付。 「D-14、10月9日」。IDは、決定を言い直して誤って蒸し返す代わりに、チャットで引用するためのものです(「それは D-14 だよ」)。
2. 決定を、現在形の一文で。 「見積りは EUR 建てのみとする。」「価格について話し合った」や「〜という雰囲気だった」ではありません。一文で書けず段落が必要なら、それは2つの決定か、決定ではありません。
3. 誰が決め、誰に相談し、誰に伝えたか。 決定には1人の名前か1つの機関を書きます。あわせて、意見を聞いた人々と、通知したチャンネルやリストも書きます。1つ目は「誰なら変更できるか」に答えます。残りの2つは「自分は聞かれたのか」に答えます。これが決定に異議が出る最も多い理由です。
4. 検討した選択肢(採用案を含む)。 1つにつき1行です。選択肢が1つしかないエントリは、決定の記録ではなく結果の記録です。却下された選択肢があるからこそ、同じ提案が次の四半期に名前を変えて戻ってくるのを防げます。
5. 採用案が選ばれた理由。 1行で、決め手となった制約、数字、リスクを書きます。新しいメンバーが本当に探しているのは、この一文です。
6. 影響:何が変わり、何がかかり、何が排除されるか。 EUR 建てのみで見積もるという決定は、USD 価格表を排除します。誰も作らないよう、そう書いておきます。
7. 再検討の条件と出典。 正当に再検討を始められる日付、数字、出来事(「通貨を理由に見積りが10%超断られた場合」)と、決定が行われた場所へのリンクです。リンク先は、ミーティングのリキャップ、スレッド、文字起こしのその瞬間などです。再検討条件が明記された決定は証拠に基づいて再検討されますが、条件のない決定は気分で再検討されます。

入れないものは、議論そのものです。誰が何を言ったかの3段落は議事録か文字起こしに置き、ログからはそこへリンクします。エントリは1つの答えを探す人が読むものですから、1画面に収まるべきです。

書き方:会議の前、最中、後

会議の前に、決定を「決定事項」としてアジェンダに載せます。 エントリを生むアジェンダ項目に決定と印を付け、問いと選択肢をあらかじめ書いておきます。「決定: EUR のみ、二本立ての価格表、または USD は要望ベース — Lena、15分、決定」のようにです。誰かが話す前にエントリの半分はできており、参加者は選択肢の再構築ではなく、理由の検討に時間を使えます。

会議の最中は、次へ進む前に決定を読み上げて確認します。 ファシリテーターが、負けた案も名指しして一文を声に出します。「では記録します。EUR のみ、二本立ての価格表は保守コストを理由に却下、決定者は Lena、断られる見積りが10%を超えたら再検討」。この読み上げ確認の瞬間に、エントリが実際に作られます。異議を唱えられる人が同じ場にいて、今の異議は6週間後の同じ異議よりずっと安上がりです。一文で読み上げられない項目はまだ決まっていません。*未決(open)*と印を付けて残っている問いを書き添え、次回のアジェンダへ回します。

会議の後は、その日のうちにエントリを書き、チームがすでに読んでいる場所に公開します。 読み上げた一文をコピーし、メモから選択肢と理由を足し、IDを付け、リキャップにリンクします。そして投稿します。置き場所は、特定の個人の文書ではなく、その会議が行われているチャンネルです。個人のフォルダにあるログは、チームが持っていないログです。チームが見つけられない決定は、チームがもう一度下すことになる決定です。

規律の核心は、読み上げ確認です。ログとは、読み上げ確認を書き留めたものです。

意思決定ログのテンプレート

文書やチャンネル投稿向けの1エントリ分です。

D-[番号] · [日付] · [決定を現在形の一文で]
ステータス: 提案中 / 決定済み / D-[番号] により置き換え
決定者: [名前または機関] · 相談先: [名前] · 共有先: [チャンネルまたはリスト]
背景: [2行 — 問いと、なぜ今決める必要があったか]
選択肢: A — [1行]; B — [1行]; C — [1行]。採用: [記号]
理由: [決め手となった制約、数字、リスク]
影響: [何が変わり、何がかかり、何が排除されるか]
見直し条件: [日付、数字、または出来事]
出典: [リキャップまたはスレッドのリンクと、その瞬間]

1年にわたる一覧用の台帳は次のとおりです。

どちらも、書式を整え直さずに、文書、スプレッドシート、キャンバス、チャットメッセージに貼り付けられます。テンプレートに欠けていることが多い列は却下と見直し条件です。この2つが、そのエントリが再び読まれるかどうかを左右します。

記入例3件

価格の決定 — 週次ミーティングから

D-14 · 2026年10月9日 · 見積りは EUR 建てのみとし、USD の要望にはその日のレートで換算した EUR 価格を提示する。
ステータス: 決定済み
決定者: Lena · 相談先: Anna、Mateusz · 共有先: #sales
背景: 9月に2社のディストリビューターから USD 建て見積りの依頼があり、2つ目の価格表の維持が提案された。
選択肢: A — EUR のみ; B — EUR/USD の二本立ての価格表; C — 要望に応じて USD、手作業で換算。採用: A
理由: B は価格改定のたびに保守作業が倍になる。C はすでに3件の不整合な見積りを生んでいる。
影響: USD 価格表は作らない。見積りテンプレートのヘッダーに「EUR」と明記する。通貨を理由とする辞退は件数を数える。
見直し条件: 1四半期の見積りのうち10%超が通貨を理由に断られた場合。
出典: 週次ミーティング、10月9日、リキャップ項目2、14:05。

採用の決定 — 単発のミーティングから

D-15 · 2026年10月10日 · 2人目のサポート担当は、ミラノオフィスではなく、ポルトガル語とスペイン語を話せる人材をリスボンで採用する。
ステータス: 決定済み
決定者: Tomás · 相談先: Priya、Dana · 共有先: #team
背景: スペインとブラジルからのサポートチケットが、第3四半期にキューの40%を超えた。
選択肢: A — ミラノで2人目を採用; B — リスボンで採用; C — スペイン語サポートを外部委託。採用: B
理由: C は、パイロットでの引き継ぎ品質を理由に却下。A ではスペイン語のキューが現状のまま残る。
影響: 求人はポルトガル語とスペイン語で出す。オンボーディングはリモートで行う。サポートチャンネルでのチームの作業言語は、引き続き混在とする。
見直し条件: スペイン語・ポルトガル語のチケット比率が2四半期連続で20%を下回った場合。
出典: 採用に関する通話、10月10日、リキャップ項目3。

置き換えられた決定

D-9 · 2026年8月14日 · 顧客との通話は、デフォルトで録画する。
ステータス: D-16 により置き換え
D-16 · 2026年10月13日 · 顧客との通話は、招待状で顧客が同意した場合にのみ録画する。リキャップはどちらの場合も作成する。
決定者: Lena · 相談先: Kenji(法務)、Anna · 共有先: #sales、#team
選択肢: A — デフォルト録画を継続; B — 招待状で確認する; C — 顧客の録画をやめる。採用: B
理由: 9月に2社の顧客が異議を唱えた。チームが後で実際に読むのは、録画ではなくリキャップである。
影響: 招待状テンプレートに一文を追加する。D-9 は削除せず、クローズする。
見直し条件: 顧客との契約で録画が求められた場合。
出典: 週次ミーティング、10月13日、リキャップ項目1、03:40。

3件に共通するものに注目してください。部外者でも行動に移せる一文、理由とともに名指しされた負けた案、そして問いが正当に再び開かれる時を示す条件です。これが実務のすべてです。このガイドの残りは、会議が終わった後もそのエントリを見つけられる状態に保つための話です。

なぜ決定は蒸し返されるのか

チームが決定を再び持ち出すのは、たいてい決定に反対だからではありません。記録が次の4つの問いのどれかに答えられないからです。

• 「本当にそう決めたっけ?」 結果は話し合われたものの読み上げ確認がなく、各自が自分なりの理解を持って帰りました。解決策は、よりよい文書ではなく、読み上げ確認です。
• 「なぜそう決めたの?」 一文は残ったのに、理由が残りませんでした。6週間後には理由が分からず、決定は恣意的に見え、負けた提案が新しい案のような顔で戻ってきます。解決策は、理由と却下の行です。
• 「自分は聞かれた?」 影響を受ける人が相談も通知もされず、変えたいからではなく、聞いてもらうために決定に異議を唱えます。解決策は、相談先と共有先の行、そしてその人が読む場所にエントリを公開することです。
• 「状況は変わった?」 再検討条件のない決定は、誰かがその気になるたびに再び開かれます。条件のある決定は、条件が満たされたときに再び開かれ、それ以外はIDで引用されます。解決策は、見直し条件の行です。

7つの要素すべてを備えたログは、4つの問いすべてを閉じます。一文だけのログは、最初の1つを閉じ、残り3つを開いたままにします。

意思決定ログを、すでに使っているツールのどこに置くか

主要なプラットフォームにはそれぞれ決定を書き留める場所があり、それぞれ違うところで止まります。以下は、各ベンダー自身のページに記載された動作のみを、確認した月とともにまとめたものです。

どこでも共通することが2つあります。1つは、決定が、会議の隣にある文書へ人が入力する一行であり、その部屋で使われた1つの言語で書かれることです。もう1つは、理由、却下された選択肢、それが語られた瞬間が文書に入るのは、その人が書き留めた場合だけだということです。

決定がリキャップとして戻ってくる仕組み

InterMIND は、ミーティングがチャンネルの中にある日常のコミュニケーションの場です。そのため、ログの置き場所は明快です。チャンネルのチャットで、前日にアジェンダを載せ、会議後にエントリを投稿します。そこでは各メンバーが自分の言語で入力し、他の人の発言を自分の言語で読めます。台帳をスプレッドシートや文書など別の場所で管理している場合も、その更新をメールでチャンネルに届けられます。チャンネルのホストがチャンネル専用のアドレスを発行すると、そこに送ったメッセージは、送信者名が付き、添付ファイルも保たれた通常のメッセージとして表示されます。

通話中は、議論中のエントリを Share to conference で全員の画面のビデオタイルの隣に表示できます。共有した人がノートをライブで編集し、参加者は読み上げ確認が形になっていく様子を見守ります。すべての参加者が自分の言語でそれを読み、原文はワンタップで切り替えて見られます。

通話が終わると、リキャップはミーティングそのものから作成されます。リキャップには、概要と重要なポイントに続いて、各ポイントが並びます。各ポイントには 合意済み、未決、意見が分かれている のいずれかの印が付き、発言者と、文書化された文字起こしのその瞬間を開くタイムスタンプが添えられます。その後に、担当者付きのアクションアイテムと未解決の質問が続きます。これが、ログのエントリの素材です。決定の一文、誰が賛成し、誰がどこで反対したか、そして出典としてリンクすべき瞬間です。リキャップはメール、チャンネル内のメッセージ、カレンダーイベント内のリンクとして届き、サインインしているすべてのメンバーが自分の言語で読みます。記録は、その場で使われた言語で一度だけ書かれるのではなく、読み手ごとに翻訳されます。どのメンバーも編集でき、編集のたびに作成者とリビジョン履歴が残ります。チャンネルには過去のすべてのセッションのリキャップが保管されるため、D-14 が決まったミーティングは、それを引用するエントリからワンクリックの距離にあります。

エントリを基幹システムに入れる必要がある場合、ホストは任意のアドレス(CRM やトラッカーの受信用メールボックスなど)にリキャップのコピーを追加できます。アドレスを一度確認すると、そのミーティングまたはチャンネルのすべてのリキャップがそこにも送信されます。仕組みは a copy of every meeting recap in your CRM, by email で説明しています。同じリキャップは、要約を Markdown として Zapier、Webhook、API にも届きます。また、メンバー自身のアシスタント(Claude、ChatGPT、Copilot、Gemini)は MCP コネクタ経由でリキャップを検索できます。そのため「USD の見積りについて何を決めたっけ?」という質問を、すでに使っているツールで尋ね、リキャップとその瞬間とともに答えを得られます。

ゲストは、アカウントなしで無料で、リンクから参加できます。スマートフォンからでもブラウザからでも参加でき、ミーティングを自分の言語でライブで聞けます。ゲストには、その後に残る記録はありません。アカウントは無料で、そのアカウントこそが記録に手が届くようにします。ホストは場を提供し、有料プランでは直近28日間にアクティブだったメンバーの分だけを支払います。静かになったメンバーも、費用なしでアクセスを保てます。

• 完全なリキャップを開く — あなたのリキャップを書くのと同じコードで描画された、実際の記録です。ポイントとタイムスタンプも含まれます。
• ライブデモを試す — サインアップ不要。話すと、聞き手ごとに翻訳された会議の様子が聞こえます。

意思決定ログという実務は、どのツールを使っても変わりません。誰かが一文を声に出し、負けた選択肢を名指しし、その問いをいつ再び問えるかを書き留める必要があります。なくなってよいのは、2つ目の仕事です。誰が何に合意したかを、記憶を頼りに、1つの言語で、他の言語で読む人々のために再構築する作業です。

FAQ

意思決定ログとは何ですか?

意思決定ログは、チームの決定を継続的に記録するもので、1決定につき1エントリです。次の内容を記録します。

• 一文で述べた決定
• 日付
• 決定者
• 相談先と共有先
• 検討した選択肢と、採用案が選ばれた理由
• 排除されること
• 再検討の条件
• 決定が行われた場所へのリンク

会議ごとではなく決定ごとに整理されており、そこが議事録との違いです。

意思決定ログには何を含めるべきですか?

1エントリにつき7つです。IDと日付、決定を現在形の一文で、決定者・相談先・共有先、却下したものを含む検討した選択肢、採用案が選ばれた理由、影響(何が変わり、何が排除されるか)、そして再検討条件と出典へのリンクです。最も抜け落ちやすいのは、却下された選択肢と再検討条件です。この2つが、決定が蒸し返されるのを防ぎます。

意思決定ログはどう書きますか?

決定を、選択肢をあらかじめ書いたうえで、決定事項としてアジェンダに載せます。会議では、次へ進む前に決定を声に出して読み上げて確認します。決定の一文、負けた案とその理由、決定者、再検討の時期です。その日のうちに、読み上げた内容からエントリを書き、IDを付け、リキャップにリンクし、チームがすでに読んでいる場所に投稿します。読み上げ確認から書かれたログは正確です。1週間後に記憶から再構築したログは、次の議論の始まりです。

意思決定ログとアクションログの違いは何ですか?

意思決定ログは何がなぜ決まったかを記録します。アクションログ、つまりアクションアイテムのリストは、それを受けて誰が何をするかを、担当者と期限とともに記録します。「見積りは EUR 建てのみとする」は決定で、「Anna — 見積りテンプレートを EUR に更新 — 10月16日まで」は、それが生んだアクションです。決定は何か月も引用されますが、アクションアイテムは数日でクローズします。両方を1つのリストに入れると、理由がタスクの下に埋もれてしまいます。

意思決定台帳(decision register)とは何ですか?

プロジェクト管理やガバナンスの用語で言う、意思決定ログと同じものです。1決定につき1行の表で、ID、日付、決定、決定者、理由、ステータスを持ちます。「台帳」は表形式の見方、「ログ」は継続的な記録を指す傾向があります。このガイドの表は両方を兼ねており、通常の列に却下と見直し条件を加えています。

意思決定ログの Excel や Word のテンプレートはありますか?

このガイドの台帳はシンプルな表で、エントリはプレーンテキストです。どちらも Excel、Google スプレッドシート、Word、Slack のキャンバス、Loop ページ、チャットメッセージに、書式を整え直さずに貼り付けられます。ファイル形式より重要なのはフォーマットです。ログを保管するものには、理由と却下された選択肢を含む決定ごとの行が必要で、しかもチームがすでに読んでいる場所にあることが必要です。

意思決定ログは誰が管理すべきですか?

決定が行われた会議のファシリテーターが、その日のうちに、読み上げ確認からエントリを書きます。決定者に名前のある人が、決定そのものの責任を持ちます。小さな組織では、たいていのエントリで同じ人になります。役割より大切なのは場所です。個人ごとではなく、チームがすでに使っているチャンネルに、チームで1つのログを置いてください。

アーキテクチャ決定記録(ADR)とは何ですか?

アーキテクチャ決定記録、つまり ADR は、意思決定ログのエントリのソフトウェア工学における形式です。決定ごとに短い文書を1つ、プロジェクトのリポジトリに保管し、コンテキスト、決定、その影響を書き、ステータスは proposed から accepted、superseded へと移ります。このガイドのテンプレートは、同じ考え方をチームの運営上の決定に当てはめたものです。エンジニアリング以外では異議が出るのは人に関することなので、誰が決め、誰に相談し、誰に伝えたかを加えています。

出典: Microsoft — Microsoft Teams で会議のノートを取る; Zoom — AI Companion によるミーティング要約の使用; Google Meet — Google Meet の「Take notes for me」; Google Workspace Updates — 「Take notes for me」が「next steps」を取得するようになりました; Slack — ミーティングアジェンダのテンプレート(キャンバス)。Microsoft のノートのページ、Google の Meet ヘルプページ、Slack のテンプレートは2026年10月に確認、Zoom のミーティング要約のページは2026年8月に確認、Google の next steps の発表は2026年9月に確認しました。ベンダーはプラン、機能、対応言語の一覧を随時変更します。最新の状況は各社のページでご確認ください。