第1話 「テストは充分?」という一言
困ったこと
最近、二日続けて同じ形の失敗がありました。一日目は「プログラムのテストを作った」と報告したのに、実は“うまくいく場合だけ”試していて、変な入力のときの確認が抜けていました。二日目は「どこにも使われていないはず」と調べた鍵が、実は大事なソフト(NexusCore)で使われていました。どちらも、ふくけいが「テストは充分?」と一言聞いたことで初めて見つかったのです。
どう解決したことになるか
「聞かれないと気づけない」のは困るので、この一言を自動化することにしました。ただ「ちゃんとやりなさい」と注意文を増やしても、注意文は読まれるだけで守られません(実際に二日連続で効きませんでした)。そこで方針を「申告させる」から「照合する」へ変えました。やったと書かせるのではなく、本当にやった証拠と突き合わせて機械が確かめる方式です。設計は別のAI三社に合計四回レビューしてもらい、そのたびに「このままだと間違えて止めすぎる」「自動実行では門番が動かない」などの落とし穴を潰しました。
flowchart TB
A["テスト全部成功 🎉"] --> B{"でも本当の効果は?"}
B -->|"中間指標だけ見て安心"| C["😭 実は効果ゼロだった"]
B -->|"完了の前に実測"| D["✅ 効果を1コマンドで確認"]
D --> E["「完了」と言える"]
何が変わったか
完成したのは三つの門番です。①報告の形式と実際の実行記録が一致しているか確かめる係 ②「ゼロ件」と言い切る時に、別の探し方での再確認を要求する係 ③自動開発の間も報告の形式を強制する係。テストは全部で十八個、すべて合格。しかも作業の最中に「テストが合格と表示されているのに、実は試す準備ができておらず何も試していなかった」という失敗を門番の仕組みが見つけて直しました。作った当日に元が取れています。
<details><summary>▶ 技術的にどう作ったか</summary>
作ったもの
check-fail-coverage.sh(既存Stop hook拡張): 完了宣言に「検証範囲宣言」セクション(タイプI/II/III・正常系/異常系/境界・EXIT証跡のtool_result突合)を必須化。grace期間〜2026-09-15は警告のみcheck-zero-assert.sh(新規Stop hook): 「ゼロ件」断定語×検索語の共起時に、固定プロトコル再検索(grep -rln --include={py,sh,md,ts,js,json,yaml}・head無し)の実行事実を要求。!override <理由>で人間判断の通過も可能run-task.sh拡張: 自動開発ループの検証プロセス出力から宣言セクションを機械抽出・不在なら即NG(自己修復なし・r3レビューで「自己修復1回許可」は逆用可能と判定され撤回)
設計の要点
- 設計原則は「書かせるでなく突合する」— 宣言の形式でなく宣言と実態(実行コマンド・exit code証跡・再検索差分)の一致を機械検査。層1ルール文が2日連続で防げなかった事実が根拠
- 判定方式はMLR(マルチLLMレビュー)4ラウンド81指摘で確定。r4では「POC(F層発火実証)を先にやれ」というNO-GO指摘を採用し条件付きGO→実際に
claude --print内でもhook発火を実証してから実装した - TDD(テスト先書き)で18ケース。実装中に「fixture不在でもexit 0で通る偽PASS」を実測発見・修正
所在情報(要約・原文リンクなし)
- 設計正典: SSOTの docs/superpowers/specs/(2026-09-01_テストは充分-体系化-design.md)
- レビュー正典: SSOTの 00_SYSTEM/マルチLLMレビュー/2026-09-01_テストは充分-体系化設計レビュー/(4ラウンド81指摘)
- 実装記録: SSOTの 01_DECISIONS/claude-code/2026-09-01_テストは充分-体系化実装-POC〜Phase1完走.md
</details>