ヒント — これだけ知れば指示できる
4つのフレーズがすべて。
エージェントに：「Hurlテスト作って」 → 機能の動作確認契約書をAIが作成。コードを知らなくても読めるplain text。
エージェントに：「この機能追加して。ただし既存Hurlが通ること」 → ドリフト防止の一言。
エージェントに：「コミットして」 → うまくいっている状態をセーブ。
エージェントに：「元に戻して」 → 最後のセーブポイントに復帰。
これがラチェット。前にだけ進み、後ろに戻らない歯車。
なぜ効くのか？ 第2講で学んだ。意見を与えればおべっかし、事実を与えれば修正する。Hurlが返すのは意見ではなく事実だ。
なぜこう指示すべきなのか
Hurl — API契約をplain textで宣言する
Hurlは「このAPIがどう動くべきか」を書いたファイル。コードを知らなくても読める。Hurlが検証するのはコードではなく振る舞い。 コードはAIが自由に変えてよい。振る舞いは変わってはいけない。
TDAD研究（2026）：「TDDをしろ」という手続き的指示 → 回帰率9.94%に悪化。「このテストファイルが通るべき」という具体的契約 → 回帰70%減少。
Git — 戻れるセーブポイント
ゲームのセーブ。「コミットして」と「元に戻して」の2つだけ。
CI/CD — 機械が自動で守る
コードをプッシュするたびに自動でHurlテストを実行。火災報知器のように。
3つが合わさると：ラチェット固定
機能完成 → Hurlテスト → 全パス → コミット → 固定。新機能追加時に既存テストが壊れたらコミット拒否。前にだけ進む。
関連記事
Reins Engineering 全講義
| 講 | タイトル |
|---|---|
| 第1講 | AIへの指示の仕方 |
| 第2講 | AIを信じない方法 |
| 第3講 | 壊れないアプリ |
| 第4講 | 決定をコードの外へ |
| 第5講 | 手綱のあるAI |
| 第6講 | 通過したら固定する |
| 第7講 | おべっかを逆手に |
| 第8講 | エージェントの工場 |
| 第9講 | コードを超えた自動化 |
| 第10講 | データの法 |
根拠資料
- TDAD (Test-Driven AI Development) 2026 — 手続き的指示で回帰率9.94%に悪化、テストファイルをコンテキストに提供で回帰率1.82%に70%減少
- Ratchet Pattern実験 — 自律エージェント40/527 (7.6%) vs ラチェットCLI 527/527 (100%)