- 設計の質は段階的に効いた：最大ファイルは 無指示 2,400〜3,500行 → 分割方針のみ 570〜587行 → 規律つき設計 434〜498行。
- 「分けろ」だけでは過分割が起きる（Fableはフィルタを8ファイルに乱造）。上限・下限つきの規律で初めて適正に収束。
- 規律は初回指示だけで13〜16改修まで持続し、破られた後も成長を抑える「アンカー」として働いた。
- 傾向は Opus・Fable の両モデルで一貫。
実験
読書ログアプリを作り、20回の改修（期限・優先度・履歴・サマリー・詳細画面・タグ・目標・ダッシュボード・設定…）を1つずつ足す。これを3条件で行った。
- B（無指示）：機能列挙のみ
- A1（素の設計）：ドメイン分割・インターフェース設計・UI肥大防止方針を明示
- A2（規律つき設計）：A1に加えてモジュール規律を明示 —— 1ファイル100〜300行目安／些末なウィジェット単位でファイルを乱造しない（類似責務は集約）／CSSも分割／新機能はまず既存モジュールへ／YAGNI
使ったプロンプト（実際に投入したテキスト）：
▶ 初期プロンプト（B・A1・A2）＋改修20回 をまとめてダウンロード（.txt）
結果1：設計の質が段階的に効く
保守性の主指標＝最大コードモジュール行数（1回の改修で触る“1枚のファイル”の最大サイズ。小さいほど良い）。
Opus 4.8：最大コードモジュール行数（最終）
Fable 5：最大コードモジュール行数（最終）
「分けろ」とだけ言ったA1で約1/5になり、規律を書いたA2でさらに15〜24%下がった。
結果2：「分けろ」だけでは過分割が起きる
A1のFableは、フィルタUIを8個の細切れファイルに乱造し41ファイル・CSS1枚1,424行という別種の肥大を起こしていた。A2の「類似責務は1モジュールに集約」「CSSも分割」が効き、filterBar.js 1本（234行）・計32ファイル・CSS4分割に収束。ガードレールは肥大と過分割の両側に必要だった。
結果3：規律の減衰 —— それでもアンカーは効く
最大コードモジュールの推移（第2実験）。破線＝初回ブリーフで課した300行規律
初回に課した「100〜300行」規律は、13〜16改修目まで無指示のまま守られた。Opusは改修14（再読管理）で495行に破ったが、その後6改修は横ばい——それ以上太らせず、新規実装を新ファイルへ逃がした。Fableは改修17まで253行以下を維持し最終434。破られた後も成長は鈍い。
ファイル数の推移：A2は改修を新ファイルで吸収、Bは1ファイルのまま
まとめ — ソフトウェアエンジニアリングの価値
- 最初の1回のブリーフの質が、20改修先の保守性を決める。無指示→素の設計→規律つき設計で、最大モジュールは 3,500 → 587 → 434 行と段階的に下がった。
- 設計指針には上限と下限の両方を書く。「分割しろ」だけでは過分割という別の肥大が起きる。
- 初期設計は減衰する。規律は13〜16改修で破られた——完全に守らせるには、レビューやリンタのような継続的な仕組みも要る。上流設計と継続ガバナンスの両方がエンジニアリング。
凡例：■ Opus-A2／■ Fable-A2／■ Opus-B／■ Fable-B（■■=A1）。各条件1試行の小サンプル。Bは2回実行し再現（Opus 2,976→2,389 / Fable 3,330→3,463）。見た目のUIは全系列で同等に収束し、差はコード構造に現れた。最大コードモジュールはHTML/JSの最大行数（CSS除く）。