記録してと言ったら書込先を決めるまでに5回も検問された話

困ったこと

「記録して」と言うだけなのに、AIが書き込む場所を一発で見つけられない日々が続いていました。01_DECISIONS（決定の正典）・00_SYSTEM（仕組みの正典）・10_DAILY（日記）など保管場所が複数あって、内容に応じて振り分ける必要がある。さらに「書き込む前に守るべき禁止条件」と「書き込む場所を絞り込む判定」が同じレイヤで扱われていたため、責務が混ざり、どこかでミスをすると全部やり直しになる構造でした。

どう解決したか

「検問」を5つのフェーズに分けて、それぞれに責務を持たせました。

• 入口の検問（hook）: 保管場所のカタログに無い書き込みを即却下
• 構造の検問（Phase 0.5a）: 既存ファイルを上書きしない・構想メモを消さないという「形」の禁止
• 判定（Phase 1）: タグ・ハブ・特性の3軸で0.0〜1.0のスコアを出し、T1〜T5の信頼度ラベルで振り分け先を確定
• 意味の検問（Phase 3-0）: タグマップの更新漏れやリンク切れを、実行直前にバリデーション
• 実行（Phase 2）: 振り分け結果を画面で見せてから、yesで連携更新

「検問を分ける」ことで、hookは最小責務に保ったまま、判定の精度はスコアで数量化できました。

何が変わったか

「記録して」から書き込みまでの流れが、データフローとして図で追えるようになりました。6種類の失敗×4種類の対応=24マトリクスで「何がどうなったらどうするか」が網羅され、新しい失敗が起きても対応パターンを組み合わせれば対処できます。Sonnetに10件レビューされて指摘の大半が反映された結果、責務分離の脆さがほぼ消えました。

<details><summary>▶ 技術的にどう作ったか</summary>

• 仕様書: obsidian-ssot 01_DECISIONS/claude-code/2026-07-12_ssot-recordマルチ起点再設計-セクション3-データフロー判定アルゴリズム（615行）
• 旧: 禁止条件と判定が同一レイヤで混在 → 新: 構造禁止（hook）と意味禁止（実行前バリデーション）に分離
• Phase 0.5a → 1 → 3-0 → 2 → 3-1〜3-7 の順で「禁止→判定→検証→確認→実行」を直線化
• 階層ラベル L1-L5 → T1-T5 にリネーム（既存 L1/L2/L3 との衝突回避）
• スコアリング: total_score = tag*0.4 + hub*0.3 + char*0.3 で0.0〜1.0に正規化し、T1(0.8+)〜T5(<0.2)で振り分け
• 6失敗×4対応=24マトリクスで失敗パターンを網羅
• 経緯: Sonnetレビューで10点採用・旧設計の責務混在を解消
• 状態: 2026-09-10に別件（実行主体不在）で凍結・参考設計書として保持 </details>