Assumption Audit

Purpose

「当たり前と思っていた前提」が間違っていた、または未検証のまま設計が進んでいる状況を早期に発見する。 前提の可視化によって、判断の根拠を明確にし、見直しコストが低い段階でリスクを潰す。

Use When

• 設計書・仕様書のレビュー前
• ADR（設計決定記録）の作成前
• 技術選定・アーキテクチャ決定の前
• 「なぜこうなっているのか」の根拠が曖昧な場合
• issue-framing の後に前提をより深掘りしたい場合
• 実装前に「このまま進んでよいか」を確認したい場合

Inputs

以下を準備すること。不足している場合は推測せず、不足を明示する。

• 対象: 前提を洗い出す対象（設計書・仕様・方針・会話ログ等）
• 判断の背景: なぜこの設計・方針になったか（わかる範囲で）
• 懸念点: すでに気になっている前提・違和感（ある場合）
• 判断の時期: この設計がいつ決まったか（情報が古い可能性の確認）

Output Contract

以下の順で出力すること。順序を変えない。

1. 論点: この設計・方針に埋め込まれた前提の核心は何か
2. 根拠: その前提をそう判断した理由・出典
3. リスク: 前提が崩れた場合の影響（コスト・時間・品質・ユーザー影響）
4. 含意: 前提の検証結果が示す設計上の意味
5. 改善案: 前提を検証・修正するための具体的な手順
6. 代替案: 前提を取り除いた場合の別設計・別アプローチ
7. 判断材料: 前提の妥当性を判断するために人間が確認すべき情報

Review Lens

• 目的妥当性: 洗い出した前提が、本来の目的と整合しているか
• 範囲の過不足: 重要な前提を見落としていないか。細かすぎる前提を拾いすぎていないか
• 中長期リスク: 今は正しくても将来崩れうる前提はないか
• LAB全体との整合性: LMS / 自動化 / データ設計との前提矛盾がないか
• 非エンジニア理解可能性: 前提の説明が、非エンジニアにも伝わる言葉か
• 他LLM移植耐性: Claude 固有の解釈・推論に依存した前提整理になっていないか

Instructions

1. 対象テキストを読み、明示的な前提（「〜だから」「〜を前提に」等）を抜き出す
2. 暗黙の前提（「当然〜だろう」として書かれていない前提）を推定・列挙する
3. 各前提を以下の3分類に振り分ける:
   • 検証済み: 根拠がある、または実測・実験済み
   • 合理的推定: 根拠はないが現時点では妥当と考えられる
   • 未検証: 根拠なし、または確認が必要
4. 未検証の前提を優先度順にランク付けする（影響が大きいもの優先）
5. 各未検証前提に対して「どう検証するか」を具体化する
6. 前提が崩れた場合の影響（コスト・スケジュール・品質）を見積もる
7. 不明な前提は推測せず「要確認」として明示する

Guardrails

• 前提の正誤を自分で断定しない。「未検証」「検証済み」の分類に留める
• 推測で前提を補完しない。「前提として確認が必要」と明示する
• 前提が崩れた場合の代替案を必ず1つ以上示す
• 検証方法が「誰かに聞く」だけで終わらないよう、具体的な確認先・確認項目を示す
• コスト影響（修正工数・機会損失）を省略しない
• 人間が最終的に前提の妥当性を判断する余地を残す

LAB Cross-Check

実行結果に対して以下を確認すること。

状態は OK / 注意 / NG / 対象外 で記入すること。

Handoff Notes

施工AI へ渡す前に以下を確定させること。

• 要件: 検証が必要な前提の一覧（優先度付き）
• 成功条件: 各前提の検証方法と、「検証済み」と判断できる基準
• 失敗条件: 前提が崩れた場合の影響範囲と判断基準
• 実行範囲: 前提検証のために確認してよいファイル・DB・外部API
• 影響範囲: 前提の修正が波及する設計・実装の箇所
• ロールバック方針: 前提修正に伴う設計変更が失敗した場合の戻し方
• コスト比較: 「前提を検証してから進む」vs「前提をそのまま進む」のコスト差

Further Reading

• issue-framing skill — 前提洗い出し前の論点整理に使う
• risk-scan skill — 前提崩壊のリスクを深掘りしたい場合に使う
• docs/DECISIONS.md — 過去の設計決定と前提を確認する
• boundary-check skill — 前提に関わるスコープの境界を確認したい場合に使う