Claude CodeにCONTEXT.mdとSPEC.mdとADRを書かせると、途中で破綻しなくなる

非エンジニアが社内ツール6本を5か月で本番稼働させた。教育系の事業所で現場運営をしている人物だ。使ったのはClaude Codeという生成AIコード開発ツール。最初の数本は試行錯誤で時間がかかったが、途中からあることに気づいた。途中で「破綻する」のだ。同じ機能をAIが週ごとに何度も提案してくるとか、「問」「項目」「単元」という似た概念が別の名前で呼ばれて別物として実装されるとか、一度決めた実装が別の機能を足したときに元に戻されるとか。原因はどれも同じで、「決定が人間の頭の中にしかない」ため、AIが毎回リセットされるたびに、前回の判断を忘れているから。そこで編み出したのが、3つのファイルを分ける戦略だ。CONTEXT.mdには用語の定義だけ（29語）、SPEC.mdには仕様とその仕様に含まれない機能を列挙（13節），そしてdocs/adr/フォルダには「なぜそう決めたか」という過去の決定理由を1ファイル1決定で残す（6本）。合わせて約14000字、原稿用紙35枚分。

なぜこれが効くのか。CONTEXT.mdが「用語がぶれる」を潰し、SPEC.mdが「頼んでいない機能が勝手につく」を潰し、ADRが「同じ案を何度も出す」を潰すからだ。特に効いているのは「禁止語」の明記。「問」と定義していても、AIは自然言語なので時々questionやcardという変数名を使う。しかし「避けるべき言葉：カード、タスク、問題、設問」と書いておくと、AIはそれらを避ける。また、「作らないもの」を明記するのも効果的。統計画面やリマインド機能を「作らないと決定した」と書き、その横に「理由はADR 0001を参照」と書いておくと、AIが「こんな機能があると便利では」と提案してきても、「SPEC 11節に書いてあります」で会話が終わる。従来は「なぜですか」という問い返しが何度も起きていた。理由を書かないと「本当にいらないのか」と当事者自身が疑い始める。

これは一見、エンジニア向けの話に見えるが、実はむしろ逆だ。この仕事をやった人はエンジニアではなく、ビジネス側の人間だ。つまり、仕様書が明確に書けるなら、非専門家でもAIとの開発は成立するということ。むしろ、あいまいな仕様で勝手に細部を埋めてくれるエンジニアより、「作らないもの」を明言し、用語を厳密に使い分ける非エンジニアの方が、AIと相性がいいかもしれない。中小企業が内製ツール開発を考えるなら、まずやるべきは、エンジニアの採用ではなく、仕様書を骨太に書く訓練だ。AIはそこまで丁寧に教えてくれる。