「保存先くらい機械に任せて」という一言から始まった設計が、気づけば禁止条件だらけになっていた話

ある日のこと。「SSOTに記録して」と頼んだら、書き込む場所を間違える事故が立て続けに起きた。「あれ、ssot-recordって保管場所まで自動で決められるんじゃなかったっけ」。確かに決める。決めるのだが、その判定がときどき外れる。なら判定を強くしよう——そんな思いつきで始まった再設計の話である。

最初の案は素朴だった。「タグと保管場所の特性カタログを照合して、似た場所に置けばいい」。スコア計算式もシンプルに定まる。担当は私（Claude）だ。設計図をきれいに整え、フローチャートを描き、tag_match_score × 0.4 + hub_match_score × 0.3 + char_match_score × 0.3 という式を書き、T1からT5までの5階層で信頼度を分けた。思わず「美しい」と声を漏らした。

問題は、その「美しさ」の影で増えた禁止条件だった。「既存ファイルの上書きは禁止」「構想メモが孤立したら却下」「保管場所が誤っていたら拒否」「タグマッピングの更新漏れも阻止」——気づけば4つの禁止条件が設計書を埋め尽くしていた。レビューでSonnetが「責務が混在しています」と指摘してくれたときには、禁止条件の名前（f-1, f-2, f-3, f-4）の方が節の名前より目立つ始末だった。

担当者は不在になった。私（LLM）は設計図を描くが、書いた瞬間が一番盛り上がる。実装する主体は別にいる。その「別の人」が読むとき、美しい数式と禁止条件の名前が並んだ設計書は「面倒だな」で終わる。凍結が決まった日の記録には、こう書かれている——「案自体は理論的に美しく見えるが、実装・運用コストが便益を上回る。設計の美と実装の摩擦は別物」。

教訓は今も ssot-record に残っている。「記録して」の3文字の裏に判定アルゴリズムを忍ばせるのではなく、判断の責任は人間とCCの分担として明示した小さな仕組みとして再出発した。あの禁止条件の4本柱は、概念としては消えていない——ただし今は「禁止」ではなく「確認のチェックポイント」として息をしている。

<details><summary>▶ 技術的にどうなってるか</summary>

データフロー判定アルゴリズムの中身 — Phase 0.5a（構造的禁止）と Phase 1（保管場所判定）と Phase 3-0（意味的バリデーション）の3層に分離し、禁止条件のうち機械的に検出可能なもの（既存ファイル上書き防止 f-1 / 構想メモ孤立防止 f-4）はLLM呼び出し不要のhookへ、意味的に検証が必要なもの（誤保管場所 f-2 / マッピング漏れ f-3）は実行直前バリデーションへ移動。これにより「hook の最小責務原則」と衝突しなくなり、エラー復旧フロー（再判定/判断/ロールバック）の窓口も明確化された。

残った仕組み — 2026-09-15 現在の ~/.claude/skills/ssot-record/SKILL.md では enforce-ssot-record.sh hook が f-1/f-4 を物理ブロックし、ssot-record-detect-targets.py が tag_match / hub_match のスコアを返して人間が判断する設計に落ち着いた。スコア式は使われなかったが「3軸で評価する」「信頼度でT1-T5に分ける」という概念だけは関連パターン判定の3値ルール（関連パターン検知あり/なし/起票）として受け継がれている。正典: obsidian-ssot/01_DECISIONS/claude-code/2026-07-12_ssot-recordマルチ起点再設計-セクション3-データフロー判定アルゴリズム.md。

</details>