Skip to Content
DocsDesign Audit Checklist

Design Audit Checklist

「考えるAI」で事故らないための設計診断チェック

これは Panolabo Engine のOS（10条）を Yes/No で検査できる形に落としたチェックリストです。 設計診断（Design Audit）では、これをベースに「どこで事故るか」を特定します。

Want a ready-to-use deliverable pack? → /design-audit-kit

迷ったら、Rule 03（契約）と Rule 07（ログ）に戻る。

→ 納品サンプルを見る

0) スコープ（最初に決める）

  • 目的（Goal）が1行で言える
  • 成果物（Deliverable）が明確（何を納品するか）
  • 成功条件（Acceptance Criteria）が書かれている
  • 失敗条件（Failure Modes）が列挙されている

1) Rule 01｜責任（Ownership）

  • 目的・評価軸・リスク許容を 人間が明示している
  • 「AIが判断した」で終わらない責任分界がある
  • 最終承認者（Approver）が決まっている

2) Rule 02｜AIに考えさせない（Execution-only）

  • AIに「目的」や「方針」を決めさせていない
  • 入力が構造化されている（フォーム/JSON/項目定義）
  • 出力の形式が固定されている（テンプレ/スキーマ）

3) Rule 03｜Message Contract（契約）

  • 入力スキーマが定義されている（必須/任意/型）
  • 出力スキーマが定義されている（必須/型/制約）
  • 禁止事項（NG）と例外扱いが明記されている
  • “1回うまくいく”ではなく”毎回通る”契約になっている

4) Rule 04｜納品物（Deliverable）

  • 出力が「提案」ではなく「納品物」として扱われている
  • 検収の観点（採点基準/品質基準）がある
  • クライアントに渡す形（ファイル/DB/画面）が決まっている

5) Rule 05｜検証（Validation）

  • 自動検証（ルール/正規表現/スキーマ検証）がある
  • 人手検証の手順と責任者がある
  • 検証できない項目は出力から排除されている

6) Rule 06｜再現性（Reproducibility）

  • 同じ入力で同品質が出ることを前提にしている
  • ブレた場合の扱い（再実行/フォールバック/アラート）がある
  • 1回の神回答を「仕様」にしていない

7) Rule 07｜ログと再実行（Logs & Replay）

  • 入力・契約・出力を保存している
  • モデル名・バージョン・温度などの条件を記録している
  • 同条件で再実行できる（Replay）導線がある
  • 監査に耐える（いつ・誰が・何を）ログになっている

8) Rule 08｜例外処理（Exceptions）

  • 例外パターンが列挙されている
  • 例外の分岐が実装されている（if/else）
  • 例外時のフォールバックがある（テンプレ/人手/別ルート）
  • “人の勘”に戻していない

9) Rule 09｜設計資産化（Assetization）

  • 契約・テンプレ・評価基準がファイル/DBとして残る
  • 引き継ぎ手順がある（担当交代を想定）
  • 3年後に再利用できる形で管理されている（Git/DB）

10) Rule 10｜改善は契約へ戻す（Feedback loop）

  • 失敗事例が記録されている（why/how）
  • 改善が契約・検証・分岐に反映される
  • 属人的な工夫で閉じていない（チームに残る）

設計診断を依頼する

チェックが少ない項目は改善の余地があります。 専門家による詳細な設計診断をご希望の場合は、お問い合わせください。

→ 納品サンプルを見る

Buy the kit → https://numaken.gumroad.com/l/design-audit-kit 

Responsible Architect：Panolabo / 沼 健一郎

Last updated on
OS10 PosterAudit Sample Output