decision-logger

Decision Logger

経営上の決定事項を記録する2層メモリシステムです。第1層には議論された内容をすべて保存します。第2層には創業者が承認した内容だけを保存します。以降のセッションでは第2層のみを読み込みます。これにより、過去の議論で生じた合意の捏造が新たな審議に持ち越されるのを防ぎます。

キーワード

決定ログ、メモリ、承認済みの決定事項、アクションアイテム、取締役会議事録、競合検出、DO_NOT_RESURFACE、決定履歴、期限超過、置き換え、決定事項の検索、決定事項の追跡、説明責任

---

2層アーキテクチャ

なぜ2層なのか？

単層の決定ログには危険な問題があります。エージェントが過去の議論、却下された提案、破棄されたアイデアを読み、新たな決定のコンテキストとして扱ってしまうのです。その結果、却下されたアイデアが繰り返し取り上げられるうちに受け入れられたかのようになる「合意の捏造」が起こります。

2層システムでは、生の議論と承認済みの決定事項を厳密に分離し、これを防ぎます。

層のアーキテクチャ

Layer 1: Raw Transcripts (NEVER auto-loaded)
  Location: memory/board-meetings/YYYY-MM-DD-raw.md
  Contains: Full deliberation, all perspectives, rejected arguments
  Loaded: Only on explicit founder request
  Retention: Active 90 days, then archived

Layer 2: Approved Decisions (AUTO-LOADED every session)
  Location: memory/board-meetings/decisions.md
  Contains: Only founder-approved decisions and action items
  Loaded: Automatically at start of every board meeting (Phase 1)
  Mutation: Append-only. Decisions are never deleted, only superseded.

層の相互作用ルール

ルール	理由
第2層は追記専用	決定履歴を完全な状態で保持します
第1層は自動読み込みしない	合意の捏造を防ぎます
第2層に書き込めるのはChief of Staffのみ	一元管理を実現します
エージェントは直接書き込まない	書き込みはすべて、創業者の承認後にChief of Staffを経由します
置き換えられた決定事項も第2層に残す	履歴が記録そのものです。削除されるものはありません

---

決定記録の形式

標準的な決定記録

## [YYYY-MM-DD] -- [DECISION TITLE]

**Decision:** [One clear statement of what was decided]
**Context:** [1-2 sentences on why this decision was needed]
**Owner:** [One person or role accountable for execution]
**Deadline:** [YYYY-MM-DD]
**Review Date:** [YYYY-MM-DD]
**Confidence:** [High / Medium / Low]
**Rationale:** [Why this option over alternatives, 1-2 sentences]

**User Override:** [If founder changed agent recommendation -- what and why]

**Rejected Alternatives:**
- [Proposal] -- [reason for rejection] [DO_NOT_RESURFACE]
- [Proposal] -- [reason for rejection]

**Action Items:**
- [ ] [Action] -- Owner: [name] -- Due: [YYYY-MM-DD]
- [ ] [Action] -- Owner: [name] -- Due: [YYYY-MM-DD]

**Dependencies:** [Other decisions this depends on]
**Supersedes:** [DATE of previous decision on same topic, if any]
**Superseded by:** [Filled retroactively if overridden later]
**Raw transcript:** memory/board-meetings/[DATE]-raw.md
**Tags:** [topic tags for search -- e.g., pricing, hiring, market-entry]

完了したアクションアイテムの形式

- [x] [Action] -- Owner: [name] -- Completed: [YYYY-MM-DD] -- Result: [one sentence]

---

競合検出システム

新たな決定事項を記録する前に、システムは3種類の競合を確認します。

競合の種類1：DO_NOT_RESURFACE違反

新たな決定事項が、以前に却下された提案と一致します。

Detection: New proposal text similarity > 70% to a rejected proposal

Response:
  BLOCKED: "[Proposal]" was rejected on [DATE].
  Reason: [original rejection reason]

  To reopen: Founder must explicitly say "reopen [topic] from [DATE]"
  This cannot be overridden by agents.

競合の種類2：トピックの矛盾

同じトピックに関する2つの有効な決定事項で、結論が異なります。

Detection: Same tags + contradictory conclusions

Response:
  DECISION CONFLICT DETECTED

  Active decision (older): [DATE] -- [decision text]
  New decision: [DATE] -- [decision text]

  These decisions contradict each other.

  Options:
  1. Supersede old decision (new replaces old)
  2. Merge decisions (reconcile the conflict)
  3. Defer to founder (present both, let founder choose)

競合の種類3：担当者の競合

異なる決定事項で、同じアクションが別々の担当者に割り当てられています。

Detection: Same action description, different owners

Response:
  OWNER CONFLICT

  Action: "[action text]"
  Decision 1 ([DATE]): Owner = [Person A]
  Decision 2 ([DATE]): Owner = [Person B]

  Resolve: Which owner is correct?

競合解決の決定木

START: Conflict detected
  |
  v
[What type of conflict?]
  |
  +-- DO_NOT_RESURFACE --> Block automatically. Only founder can reopen.
  |
  +-- Topic contradiction --> [Is the new decision from a board meeting?]
  |                           |
  |                           +-- YES --> Supersede old by default (board > individual)
  |                           +-- NO  --> Present both to founder for resolution
  |
  +-- Owner conflict --> [Which decision is more recent?]
                         |
                         +-- Flag to founder with both dates
                         +-- Default to more recent unless founder overrides

---

決定事項のライフサイクル

状態

PROPOSED --> APPROVED --> ACTIVE --> [COMPLETED | SUPERSEDED | EXPIRED]

PROPOSED:    Agent synthesis presented to founder
APPROVED:    Founder explicitly approved
ACTIVE:      Being executed, action items in progress
COMPLETED:   All action items done, review confirmed success
SUPERSEDED:  New decision replaced this one
EXPIRED:     Review date passed without renewal

状態の遷移

From	To	Trigger	Who
Proposed	Approved	創業者が「はい」または「承認」と言う	創業者
Proposed	Rejected	創業者が「いいえ」または「却下」と言う	創業者
Approved	Active	アクションアイテムの実行を開始	自動
Active	Completed	すべてのアクションアイテムを完了としてマーク	Chief of Staff
Active	Superseded	同じトピックに関する新たな決定事項	Chief of Staff
Active	Expired	レビュー日を過ぎ、更新されていない	システムアラート

---

最初に確認する

決定事項を記録する前に、以下の情報を確認してください。不明な点や曖昧な点があれば、推測せずに質問してください。

• 決定事項の正確な記述（決定された内容を明確な1文で示すこと） — これが記録の要です。記述が曖昧だと、今後の競合検出にログを役立てられません
• 担当者と期限 — 追跡したり期限超過として通知したりするには、各決定記録に説明責任を負う担当者を1人指定し、日付を記載する必要があります
• 却下された代替案とその理由 — これらはDO_NOT_RESURFACEの記録となり、却下されたアイデアが今後の審議に再び持ち込まれるのを防ぎます
• 同じトピックに関する過去の決定事項を置き換えるかどうか — 既存ログとの競合検出と置き換えの追跡に必要です

中止ルール：出力を大きく左右する2～3点だけを質問してください。ユーザーが「とりあえず下書きして」と言った場合は、そのまま進め、成果物の冒頭に前提を列挙してください。

記録のワークフロー

決定後の記録（取締役会ミーティングのフェーズ5後）

Step 1: Founder approves synthesis
  |
Step 2: Write Layer 1 raw transcript
  --> memory/board-meetings/YYYY-MM-DD-raw.md
  |
Step 3: Run conflict detection against decisions.md
  |
  +-- Conflicts found --> Surface to founder, wait for resolution
  +-- No conflicts --> Continue
  |
Step 4: Append approved entries to decisions.md (Layer 2)
  |
Step 5: Set review dates and action item deadlines
  |
Step 6: Confirm to founder:
  "Logged: [N] decisions, [M] action items tracked, [K] flags added"

---

アクションアイテムの管理

期限超過の検出

各セッションの開始時に、以下を確認します。

1. 期限を過ぎたアクションアイテム
2. レビュー日を過ぎた決定事項
3. 完了状況が記録されていない、90日を超える決定事項

アラートの形式

OVERDUE ITEMS (as of [today's date])

Action Items Past Deadline:
  1. [Action] -- Owner: [name] -- Due: [date] -- [X] days overdue
     From decision: [decision title] ([date])

  2. [Action] -- Owner: [name] -- Due: [date] -- [X] days overdue

Decisions Pending Review:
  1. [Decision title] -- Review was due: [date]
     Original decision: [summary]
     Prompt: "You decided [X] on [date]. Worth a check-in?"

Stale Decisions (> 90 days, no status update):
  1. [Decision title] -- Decided: [date] -- Last update: [date]

アクション項目の優先度マトリックス

緊急度	影響度	優先度	対応
期限超過	高	重大	直ちに創業者にエスカレーションする
期限超過	低	高	次回のセッションで提示する
今週が期限	高	高	先回りして提示する
今週が期限	低	中	週次サマリーに含める
来月が期限	任意	低	監視のみ

---

検索と取得

検索機能

クエリの種類	例	返される内容
トピック別	"pricing"	pricing のタグが付いたすべての決定
担当者別	"CTO"	CTO が担当するすべての決定とアクション
期間別	"Q4 2025"	2025年10月から12月までのすべての決定
ステータス別	"overdue"	期限超過のすべてのアクション項目
競合別	"conflicts"	検出されたすべての矛盾
タグ別	"hiring AND engineering"	タグの共通部分

決定のサマリー表示

表示	内容	使用する場面
最新10件	承認済みの最新10件の決定	デフォルトのクイック表示
全履歴	すべての決定を時系列順に表示	監査または詳細なレビュー
担当者別	説明責任を負う人物ごとにグループ化	説明責任の確認
トピック別	タグごとにグループ化	戦略的レビュー
期限超過のみ	期限超過の項目のみ	アクション管理
対応中のみ	未完了のアクション項目がある決定のみ	実行状況の追跡

---

ファイル構成

memory/
  board-meetings/
    decisions.md           # Layer 2: append-only, founder-approved
    YYYY-MM-DD-raw.md      # Layer 1: full transcript per meeting
    archive/
      YYYY/                # Raw transcripts after 90 days

---

他のスキルとの連携

スキル	連携ポイント
Chief of Staff (chief-of-staff)	記録ワークフローを管理し、Layer 2 に書き込みます
Board Meeting (board-meeting)	Phase 5 の承認後に記録を開始します
Strategic Alignment (strategic-alignment)	決定がチームの目標へ適切に展開されているか確認します
Executive Mentor (executive-mentor)	再評価のため、古い決定をレビューします
Org Health (org-health-diagnostic)	決定の速度を健全性の指標として使用します

---

注意すべき兆候

• 同じトピックが記録された決定なしに3回以上議論されている — 決定の回避
• 同じ担当者のアクション項目が一貫して期限超過になっている — キャパシティまたは説明責任の問題
• 履歴を確認せずに決定が下されている — 矛盾のリスク
• 明示的なリクエストなしに Layer 1 が読み込まれている — 合意を捏造するリスク
• 決定にレビュー日が設定されていない — 再評価されないまま決定が古くなる
• 却下された提案が新しい表現で再び持ち出されている — DO_NOT_RESURFACE が適用されていない
• 取締役会の会議開始時に決定ログが参照されていない — 組織の記憶が活用されていない
• すべての決定を1人が担当している — ボトルネックまたは委任の失敗

---

先回りのトリガー

• 決定のレビュー日を過ぎた — プロンプト：「[date] に [X] を決定しました。状況を確認してみませんか？」
• アクション項目が7日を超えて期限超過している — 担当者の状況を添えて創業者にエスカレーションする
• 同じトピック領域に対応中の決定が3件以上ある — 統合レビューが必要
• 記録された決定が30日以上ない — このシステムは利用されていますか？
• 新たに提案された決定が DO_NOT_RESURFACE に該当する — ブロックして説明する
• 6か月以上前の決定にステータス更新がない — 古いものとしてマークし、レビューを促す

---

出力成果物

リクエスト	提供内容
"Show recent decisions"	ステータス付きの承認済み最新10件の決定
"What's overdue?"	担当者と期限超過日数を含む、期限超過のすべてのアクション項目
"Search decisions about [topic]"	トピック／タグで絞り込んだ決定履歴
"Log this decision"	すべてのフィールドを含む、書式設定済みの決定エントリー
"Check for conflicts"	すべての対応中の決定との競合をスキャンした結果
"Decision summary for board"	決定の速度、完了率、未完了項目

---

ツールリファレンス

1. decision_tracker.py

提案 > 承認済み > 実行中 > 完了／置き換え済み／期限切れの全ライフサイクルを管理し、経営上の意思決定を追跡します。期限超過のアクションアイテムや古い意思決定を検出し、状況の概要を生成します。

python scripts/decision_tracker.py --input decisions.json --json
python scripts/decision_tracker.py --input decisions.json

フラグ	型	説明
--input	必須	意思決定の記録（タイトル、ステータス、担当者、期限、アクションアイテム、タグ）を含む JSON ファイルのパス
--json	任意	人が読みやすいテキスト形式ではなく、JSON 形式で出力します

2. decision_quality_scorer.py

意思決定の質を、6 つの側面（フレーミング（問題の定義）、代替案（検討した選択肢）、情報（証拠の質）、推論（論理の妥当性）、コミットメント（行動の明確さ）、メタ認知（不確実性への認識））から評価します。改善案を生成します。

python scripts/decision_quality_scorer.py --input decision_assessments.json --json
python scripts/decision_quality_scorer.py --input decision_assessments.json

フラグ	型	説明
--input	必須	意思決定の評価（各側面のスコア 1～10、任意の成果データ）を含む JSON ファイルのパス
--json	任意	人が読みやすいテキスト形式ではなく、JSON 形式で出力します

3. decision_tree_builder.py

期待値分析を用いて意思決定ツリーを構築します。確率で重み付けした結果に基づいて最適な経路を計算し、最も価値の高い意思決定を特定し、主要な前提条件の感度分析を生成します。

python scripts/decision_tree_builder.py --input tree_data.json --json
python scripts/decision_tree_builder.py --input tree_data.json

フラグ	型	説明
--input	必須	意思決定ノード（選択肢、確率、結果、価値）を含む JSON ファイルのパス
--json	任意	人が読みやすいテキスト形式ではなく、JSON 形式で出力します

---

トラブルシューティング

問題	考えられる原因	解決策
同じトピックが、意思決定を記録しないまま 3 回以上話し合われる	意思決定の回避、または明確な意思決定権限がない	次のセッションで必ず決定します。意思決定ツリービルダーを使って選択肢を明確にし、明示的な意思決定担当者を割り当てます
同じ担当者のアクションアイテムが一貫して期限超過になる	担当者の過剰なコミットメント、能力不足、または説明責任の問題	担当者の作業負荷を確認します。能力不足が原因であれば再配分し、説明責任の問題であれば創業者にエスカレーションします
履歴を確認せずに意思決定が行われる	セッション開始時に意思決定ログを参照していない、または参照する習慣がない	取締役会のフェーズ 1 で意思決定ログの読み込みを自動化し、関連する過去の意思決定を先回りして提示します
却下された提案が、表現を変えて再び持ち込まれる	DO_NOT_RESURFACE が徹底されていない、またはチームメンバーが以前の却下を把握していない	記録前に競合を検出するよう徹底し、却下された項目と一致する提案をブロックします。再検討には創業者からの明示的な「再開」の指示を必須とします
意思決定ログは増えているが、傾向の把握に活用されていない	ログが戦略的なツールではなく、アーカイブとして扱われている	四半期ごとに意思決定をレビューし、意思決定の速度、完了率、品質の傾向を分析します
すべての意思決定を 1 人が担当している	ボトルネック、または委任の失敗	担当を分散します。意思決定品質スコアラーを使って、集中化によって品質が向上するか低下するかを評価します
意思決定品質スコアの「代替案」項目が低い	チームが最初の選択肢に固執し、幅広く検討していない	一定の基準を超える意思決定では、最低 3 つの代替案を必須にします。意思決定ツリービルダーを使って選択肢をモデル化します

---

成功基準

• 取締役会での意思決定をすべて、承認から 24 時間以内にレイヤー 2 に記録する
• 定められた期限内のアクションアイテム完了率が 80％を超える
• DO_NOT_RESURFACE 違反が 0 件（却下された提案が意思決定の流れに再び入らない）
• 実行中の意思決定の 90％以上で、レビュー日が守られる
• 6 つのすべての側面における意思決定品質スコアの平均が 7/10 を超える
• 新たな意思決定の記録前に、トピックの矛盾を競合検出が 100％検出する
• すべての取締役会セッションの開始時に意思決定ログを参照する

---

対象範囲と制限事項

対象範囲： 2 層構造の意思決定メモリーアーキテクチャ、意思決定の記録とライフサイクル管理（提案 > 承認済み > 実行中 > 完了／置き換え済み／期限切れ）、競合の検出（DO_NOT_RESURFACE、トピックの矛盾、担当者の競合）、期限超過のアラートを含むアクションアイテムの追跡、トピック／担当者／日付／ステータスによる意思決定の検索と取得、意思決定の品質スコアリング、意思決定ツリーによる期待値分析。

対象範囲外： CRM またはプロジェクト管理ツールとの統合（ツールでは JSON エクスポートを使用します）、会議の文字起こしまたは録音、チームレベルのタスク管理（project-management/ スキルを使用してください）、戦略策定または OKR の追跡（strategic-alignment または ceo-advisor を使用してください）、自動意思決定。このスキルは意思決定を追跡・評価しますが、意思決定を行うものではありません。

制限事項： 競合の検出にはタグとテキストの照合を使用するため、意味的には類似していても表現が異なる提案は検出されない場合があります。意思決定の品質スコアリングは事後的に行われ、正直な自己評価に依存します。意思決定ツリーによる期待値の計算では、確率を推定できることを前提としています。不確実性が非常に高い環境では、確率の割り当てが誤解を招く可能性があります。2 層構造のアーキテクチャを維持するには規律が必要です。レイヤー 2 が継続的に更新されない場合、組織の記憶は劣化します。

---

統合ポイント

• chief-of-staff -- 記録ワークフローを管理します。レイヤー 2 への書き込みを一元管理します
• board-meeting -- フェーズ 5 での承認後に意思決定の記録を開始し、フェーズ 1 で意思決定ログを読み込みます
• strategic-alignment -- 意思決定がチームの目標や OKR に適切に反映されているか確認します
• executive-mentor -- 再評価が必要な古い意思決定を確認し、意思決定の品質向上を支援します
• ceo-advisor -- 戦略的意思決定を記録・追跡し、意思決定の傾向をリーダーシップコーチングに活用します