公式スキル · 業務管理・総務

意思決定の記録（意思決定ログ）

v1.0.0・2026年11月4日更新

決まったことを短いログ 1 件にまとめる。決定、背景、検討した選択肢、理由、決定者、日付、ステータス、見直す条件を書く。

Claude・ChatGPT・コーディング用の AI で使えます。TeamとBusiness では、Pod に入れた公式スキルが改善のたびに自動で最新版になります。

使う場面

• 元に戻しにくい、またはあとで疑問が出そうなことがチームで決まった
• なぜそれを選んだのか何度も聞かれるが、どこにも書いていない

AI に渡すもの

• 何が決まり、だれが決めたか
• 日付
• 話に出た選択肢と、落ちた理由
• スレッド・議事録・文書（任意）

できあがるもの

番号つきの Markdown の意思決定ログ 1 件。ステータス、決定者、背景、選択肢、理由、影響、見直す条件を含む。

手順

1. 決定を能動態の1文で書く Nygard は決定の欄を「完全な文で、能動態で」書くとし、たいてい「We will（〜する）」で始める。例：「3月1日から、CRM に Dealbook を使う。」
2. 背景を2〜4文で書く 選択を迫った事実と事情（締め切り、コスト、顧客、制約）。Nygard はこの欄を「価値判断を含まない。事実を述べるだけ」としている。意見は理由の欄に書く。
3. 検討した選択肢を挙げる 1案1行で、主なトレードオフを書く。Atlassian の DACI のプレイブックは、選択肢ごとに長所・短所・コストを表にまとめる。「何もしない」が実際の選択肢だったなら入れる。実際に話に出た選択肢だけを書く。
4. 理由を書く 背景に結びつく2〜4点の箇条書きで、なぜこの案がほかに勝ったか。続けて、良い面も悪い面も含めて影響を書く。Nygard：「良い影響だけでなく、すべての影響をここに書く。」
5. 決めた人と相談した人を書く 決めた人は1人（Atlassian の DACI では Approver と呼び、「決定を下す1人（そう、1人だけ）」としている）と、相談した人。英国政府の ADR のフレームワークも、相談した関係者を記録している。
6. 見直す条件を決める 決定を見直すきっかけになる具体的な条件（日付、数字、出来事）。例：「営業が20人を超えたら」「価格が予算を超えたら」「来年3月1日に見直す」。このスキルの既定値：どの記録にも必ず書く。「見直さない」は決定が本当に恒久的なときだけで、その理由も書く。
7. ステータスと番号をつける 提案中、承認済み、置き換え済みのどれか。Nygard の形式どおり、番号は順につけ、再利用しない。古い決定を置き換えるなら、古いほうに「#[n] で置き換え」と書いて残す。Nygard は覆された決定も「残しておき、置き換え済みと印をつける」としている。

SKILL.md の全文

AI が読むファイルそのものです。 ダウンロード

---
name: decision-record
description: すでに決まったことを、短い意思決定ログの1件として記録する。決定を1文で、背景、検討した選択肢、選んだ理由、決めた人、日付、ステータス、見直す条件を書く。アーキテクチャ決定記録（ADR）と意思決定ログのやり方をもとに、どんな業務上の決定にも使える形にしている。チームで何かが決まったとき、決定の記録や議事の要点を頼まれたとき、「なんでこうしたんだっけ？」と何度も聞かれるときに使う。
---

# 意思決定の記録

意思決定の記録があれば、半年後の人が、その場にいた人に聞かずに、何が・なぜ決まり、いつ見直すべきかがわかる。記録するのは決まったことで、決めるための議論ではない。短く書く。アーキテクチャ決定記録（ADR）の形式を紹介した Michael Nygard の2011年の記事は、文書全体を1〜2ページにとしている。このスキルの既定値は半ページ。

## 使う場面

- 元に戻すのに手間がかかる、またはあとで疑問が出そうなことが決まったとき（ツール、取引先、価格、方針、採用計画、業務の流れ）。
- 「書き残しておこう」と言われたとき、意思決定ログへの記録を頼まれたとき。
- 「なぜ X にしたの？」とスレッドで何度も聞かれ、答えがだれかの頭の中にしかないとき。
- 決めるためには使わない。選択肢を並べて推奨案の承認を取るなら、先に意思決定メモを作り、決まった結果をここに記録する。

## 用意するもの

- 何が決まり、だれが決めたか。決めた人がはっきりしなければ一度だけ聞き、推測しない。それでも不明なら「[決定者未確認]」と書く。
- 決まった日付。なければ元のメッセージの日付を使い、「[メッセージの日付]」と書く。
- 検討した選択肢と、ほかの案が落ちた理由。1案しか話していなければそう書き、選択肢を作らない。
- あれば：議論したスレッド、議事録、文書と、ログの最後の番号。

## 手順

1. **決定を能動態の1文で書く。** Nygard は決定の欄を「完全な文で、能動態で」書くとし、たいてい「We will（〜する）」で始める。例：「3月1日から、CRM に Dealbook を使う。」
2. **背景を2〜4文で書く。** 選択を迫った事実と事情（締め切り、コスト、顧客、制約）。Nygard はこの欄を「価値判断を含まない。事実を述べるだけ」としている。意見は理由の欄に書く。
3. **検討した選択肢を挙げる。** 1案1行で、主なトレードオフを書く。Atlassian の DACI のプレイブックは、選択肢ごとに長所・短所・コストを表にまとめる。「何もしない」が実際の選択肢だったなら入れる。実際に話に出た選択肢だけを書く。
4. **理由を書く。** 背景に結びつく2〜4点の箇条書きで、なぜこの案がほかに勝ったか。続けて、良い面も悪い面も含めて影響を書く。Nygard：「良い影響だけでなく、すべての影響をここに書く。」
5. **決めた人と相談した人を書く。** 決めた人は1人（Atlassian の DACI では Approver と呼び、「決定を下す1人（そう、1人だけ）」としている）と、相談した人。英国政府の ADR のフレームワークも、相談した関係者を記録している。
6. **見直す条件を決める。** 決定を見直すきっかけになる具体的な条件（日付、数字、出来事）。例：「営業が20人を超えたら」「価格が予算を超えたら」「来年3月1日に見直す」。このスキルの既定値：どの記録にも必ず書く。「見直さない」は決定が本当に恒久的なときだけで、その理由も書く。
7. **ステータスと番号をつける。** 提案中、承認済み、置き換え済みのどれか。Nygard の形式どおり、番号は順につけ、再利用しない。古い決定を置き換えるなら、古いほうに「#[n] で置き換え」と書いて残す。Nygard は覆された決定も「残しておき、置き換え済みと印をつける」としている。

## 出力の形式

```markdown
## #[番号] — [短い名詞句のタイトル]

**ステータス:** [提案中 / 承認済み / #n で置き換え] · **日付:** [日付] · **決定者:** [1人の名前]  
**相談した人:** [名前] · **出典:** [スレッド・議事録・文書へのリンク]

**決定:** [〜する、の1文]

**背景:** [事実を2〜4文で]

**検討した選択肢:**
- **[案 A、採用]:** [主なトレードオフ]
- **[案 B]:** [主なトレードオフ]
- **[何もしない]:** [主なトレードオフ。検討した場合のみ]

**理由:**
- [背景に結びつく理由]

**影響:**
- [良い影響と悪い影響。だれにとって何が変わるか]

**見直す条件:** [具体的な日付・数字・出来事]
```

## 例

**入力:** Slack のスレッドの要約：「2月3日、山田さん（COO）の最終判断：FunnelHQ ではなく Dealbook でいく。石井さんと松本さんも同席。FunnelHQ の営業向けプランは、うちの営業6人だと約3倍の費用で、マーケティングオートメーションはまだ使っていない。Dealbook には必要なメール連携がある。デメリットは、あとでマーケが FunnelHQ を使いたいとなったら、もう一度移行が必要なこと。スプレッドシートは限界で、先月はフォローアップが2件漏れた。ログの最後は #11。」

**出力:**

```markdown
## #12 — 営業チームの CRM

**ステータス:** 承認済み · **日付:** 2月3日 · **決定者:** 山田（COO）  
**相談した人:** 石井、松本 · **出典:** Slack のスレッド、2月3日

**決定:** 営業チームは、共有スプレッドシートから Dealbook に移行する。

**背景:** 営業6人のチームは、限界にきているスプレッドシートで案件を管理している。先月はフォローアップが2件漏れた。CRM とのメール連携が必要。マーケティングオートメーションは今は使っていない。

**検討した選択肢:**
- **Dealbook、採用:** 必要なメール連携がある。マーケティングオートメーションはない。
- **FunnelHQ の営業向けプラン:** マーケティングオートメーションつき。営業6人で Dealbook の約3倍の費用。

**理由:**
- 限界にきているスプレッドシートを置き換えられ、必要なメール連携がある。
- FunnelHQ の営業向けプランは6人で約3倍の費用がかかり、マーケティングオートメーションはまだ使っていない。

**影響:**
- 営業は進行中の案件を Dealbook に移し、スプレッドシートの使用をやめる。
- あとでマーケが FunnelHQ を必要とした場合、CRM のデータをもう一度移行する。

**見直す条件:** マーケが FunnelHQ を使いたいとなったとき、またはマーケティングオートメーションを使いはじめたとき。
```

## 送る前のチェック

- [ ] 決定が、そのまま行動に移せる能動態の1文になっている。
- [ ] 決定者がちょうど1人書いてあるか、「[決定者未確認]」になっている。
- [ ] 挙げた選択肢はすべて実際に話に出たもの。網羅的に見せるために足していない。
- [ ] 影響に、コストか悪い面が1つ以上ある。
- [ ] 見直す条件が、具体的な日付・数字・出来事になっている。
- [ ] 事実、名前、数字、日付はすべて元の情報から取っている。

## よくある失敗

- 議論を決定として記録する。権限のある人が了承していなければ、ステータスは「提案中」。
- 決定が変わったときに古い記録を書き換える。新しい記録を書き、古いほうを置き換え済みにする。履歴こそが目的。
- 背景の欄で主張する。選んだ理由は「理由」の欄に書く。

チームで使う

AI Skill Pod に追加すると、業務委託の方も含めてチーム全員が、自分の AI から同じ版を使えます。 AI スキルをチームで共有する方法を読む

チームのPodに追加

変更履歴

• v1.0.0 · 2026年11月4日 · First release.