クイックヒント — これだけ知れば始められる
アプリが壊れた。昨日動いていたログインが今日は動かない。決済が二重に引き落とされる。コードを触るたびに別の場所が壊れる。AI に「直して」と言うと、さらに壊れる。
作り直してはいけない。 作り直しても三ヶ月後に同じ場所で壊れる。まず現在の状態をロックせよ。
三つの構造的ツール：
- codistill — 診断。既存コードから API エンドポイント、DB スキーマ、認証フローを自動的に抽出する。
- huma — ロック。全エンドポイントに回帰テストをかけて現在の動作を保護する。
- yongol — 移行。SSOT から新しいバックエンドを生成し、既存のテストで同一動作を証明する。
左から右へ進む。codistill で診断し、huma でロックし、準備ができたら yongol で移行する。
エージェントに：「codist scan を実行して、このプロジェクトのエンドポイント、DB スキーマ、認証フローを抽出して。」
現状が見えてくる。25 個のエンドポイントのうち何個が生きていて何個が死んでいるかわかる。
エージェントに：「huma verify を実行して、すべてのエンドポイントの状態を確認し、生きているものそれぞれに Hurl テストを書いて。」
これが回帰テストスイートだ。現在動いているものをロックする。これらのテストが通過する限り、エージェントがコードを修正しても既存の動作は壊れない。
エージェントに：「ログインのバグを直して。ただし、すべての Hurl テストをパスしなければならない。」
バグを直しつつ他を壊さない。ratchet をかけた状態で修理する。
体験してみよう
壊れたアプリがなくても体験できる。「作る → 壊す → 救う」のサイクルを 3 分以内に経験する。
ステップ 1 — アプリを作る
Claude Code で：
「シンプルなタスクリスト API を作って。5 つのエンドポイント：タスク一覧の取得、タスクの追加、タスクの更新、タスクの削除、タスクの完了処理。サーバーを起動して。」
ステップ 2 — codist で診断する
「codist scan を実行して、このプロジェクトのエンドポイント一覧を抽出して。」
codist が 5 つのエンドポイントのパス、メソッド、パラメータを自動的に取り出す。これが現在の地図だ。
ステップ 3 — huma でロックする
「huma verify を実行して、すべてのエンドポイントに Hurl テストを書いて。」
5 つのエンドポイントそれぞれに Hurl ファイルが生成される。現在の動作がロックされた。
ステップ 4 — わざと壊す
「タスク更新エンドポイントのレスポンス形式を変えて。title フィールドを name に変更して。」
変更した後：
「Hurl テストを実行して。」
テストが失敗する。「title を期待したが name が来た。」ドリフトが捕捉された。ratchet が動作している瞬間だ。
ステップ 5 — ratchet をかけた状態で修理する
「すべての Hurl テストがパスするように修正して。ただし、name フィールドを使う新機能も維持しなければならない。」
エージェントが後方互換性を保ちながら修正する。Hurl がパスすれば、既存の動作が保存されたことになる。
これが codistill → huma → 修理 の縮小版だ。本当に壊れたアプリでは、このプロセスが 25 個、50 個、200 個のエンドポイントに拡大されるだけで、原理は同じだ。
なぜこのアプローチが正しいのか
導入：あなたのアプリが壊れた本当の理由
2025 年、Lovable で作られた 170 個のアプリのデータベースがインターネットに丸ごと公開された——メール、API キー、決済情報。原因はコードのバグではなかった。AI がセキュリティポリシーを省いたままアプリを作り、誰も検証しなかった。
2026 年 1 月、AI ソーシャルネットワーク Moltbook で 150 万の API トークンが流出した。同じ原因。AI が作り、人間が確認しなかった。
これは他人の話ではない。vibe coding でアプリを作った人なら、同じ構造の上に座っている。
「ログインを作って」— 30 秒。「決済をつけて」— 2 分。「管理者ダッシュボードを追加して」— 5 分。3 ヶ月後、AI が決済ロジックを「整理」しながら割引計算を変え、新機能を追加すると認証が壊れ、昨日動いていたページが今日 500 エラーを返す。
あなたは二つの選択肢の前に立っている：
- 作り直す
- 救う
作り直すことは三ヶ月前にもできた。問題は作り直しても同じパターンが繰り返されることだ。ドリフトはコードの問題ではなく、構造の問題だからだ。
救う方法を学ばなければならない。
遭難者の自己救助法 — 5 ステップ
壊れたアプリを救う過程は、登山の遭難対応と同じだ。走るな。現在地を把握し、安全を確保し、一歩ずつ移動せよ。
ステップ 1. 診断 — 今何が生きているか
最初にすることはコードを直すことではない。現状を把握することだ。
エージェントに：「このプロジェクトのすべての API エンドポイントをスキャンして。
各エンドポイントに実際にリクエストを送って
レスポンスのステータスコードを記録して。
結果を表にまとめて：パス、メソッド、ステータスコード、レスポンスタイム。」
25 個のエンドポイントのうち 18 個が 200 を返し、4 個が 401 で、3 個が 500 なら — これが現在の地図だ。地図なしで修理を始めると、直した場所が別の場所を壊す。
codistill の codist scan がこの作業を自動化する。既存コードからエンドポイント、データモデル、認証フローを抽出する。
ステップ 2. ロック — 生きているものを先に保護する
診断が終わったら、生きているエンドポイントをロックする。
エージェントに：「200 を返す 18 個のエンドポイントそれぞれに
Hurl テストを書いて。
現在のレスポンスをそのまま期待値にして。
認証が必要なものはログインシーケンスを先に実行して
トークンを受け取って使って。」
この 18 個の Hurl ファイルが安全網だ。その後どんな修正をしても、このテストが通過すれば既存の動作が保存されたことになる。
huma の huma verify がこのプロセスを体系化する。エンドポイントごとに状態を追跡し、PASS/IMPROVE/FAIL を判定する。
重要：部分的なロックは機能しない。 18 個のうち 10 個だけロックしたら、残りの 8 個が修理中に壊れてもわからない。全量ロックが原則だ。
ステップ 3. 修理 — ratchet をかけた状態でバグを直す
安全網があるので、いよいよバグを直せる。
エージェントに：「ログインが失敗する原因を見つけて直して。
ただし、すべての Hurl テストがパスしなければならない。
一つでも失敗したら修正を元に戻して。」
これが第 6 講で学んだ Ratchet Pattern の実戦応用だ。直すが壊さない。一つ修理するたびに Hurl を回す。パス — 次のバグへ。失敗 — 元に戻す。
500 エラーを返していた 3 個のエンドポイントも同じ方法で修理する。修理が終わったら新しい Hurl テストを追加する。ratchet がもう一段かかった。
ステップ 4. 抽出 — ブラックボックスからロジックを取り出す
ここが核心だ。アプリが壊れた根本原因は大抵ここにある。
Supabase を使っているなら：
- RLS ポリシーがダッシュボードにしかなく、コードにない
- Edge Functions にビジネスロジックが隠れている
- 認証ロジックが Supabase Auth に紐付いている
Firebase を使っているなら：
- Security Rules がコンソールにしかない
- Cloud Functions にロジックが分散している
どの BaaS を使っても構造は同じだ。ビジネスロジックがコードベースの外にある。
エージェントに：「Supabase ダッシュボードからすべての RLS ポリシーを抽出して。
各テーブルの SELECT、INSERT、UPDATE、DELETE ポリシーを
SQL ファイルとして保存して。git にコミットして。」
エージェントに：「Edge Functions のビジネスロジックを分析して。
どの関数がどのビジネスルールを実装しているかを
ドキュメントとしてまとめて。」
ブラックボックスの中のロジックをコードベースに取り出すことだ。取り出してからエージェントが読め、テストでき、ratchet でロックできる。
codistill の codist ddl が既存の DB から DDL を抽出する。codist scan がコードから SSOT を抽出する。ブラックボックスから宣言的レイヤーに移す道具だ。
ステップ 5. 移行 — 準備ができたときだけ
1〜4 ステップを終えると、アプリはこんな状態だ：
- すべてのエンドポイントに Hurl 回帰テストがある
- バグが修理されている
- ブラックボックスのロジックがコードベースに文書化されている
- ratchet がかかっていて、新しい修正が既存の動作を壊さない
この状態で移行を決める。Supabase から自前のバックエンドへ、Deno から Go へ、何でも。
移行の安全網は、ステップ 2 で書いた Hurl テストだ。新しいサーバーに同じ Hurl を回して全部パスすれば — レガシーと同一動作であることが証明される。
エージェントに：「yongol generate で Go+Gin バックエンドを生成して。
既存の Hurl テストを全部パスさせて。」
移行はステップ 5 であり、ステップ 1 ではない。ステップ 1 で移行を試みると失敗する。インシデントのオンボーディングで確認された教訓だ。
Supabase から抜け出す方法
第 11 講の最も頻繁なケースが Supabase だ。vibe coding で始めて、Supabase に全振りして、3 ヶ月後に壊れる。
抜け出す順序：
1. DB はそのままで ratchet だけかける
Supabase の PostgreSQL はそのまま使う。DB を変えるのは最後だ。
codist ddl → 既存のテーブルから DDL を抽出
huma verify → エンドポイントの現状把握
hurl → 生きている API を全量ロック
2. ロジックをコードに移す
RLS ポリシー → Rego ファイルへ。Edge Functions → SSaC アノテーションへ。ダッシュボードからコードベースへ移動。
3. 認証を分離する
Supabase Auth は最後に切り離す。auth.users のパスワードハッシュを抽出できないため、ユーザーがまだいなければ即時移行し、ユーザーがいれば二重認証期間を設ける。
4. 新しいサーバーを立てて Hurl で検証する
yongol generate → Go+Gin バックエンドを生成
hurl を全量実行 → レガシーと同一動作を証明
Hurl が全部パスしたら、トラフィックを切り替える。
なぜ作り直してはいけないのか
「いっそ新しく作り直せばいいじゃないか？」
駄目だ。三つの理由：
1. 同じパターンが繰り返される
ドリフトはコードの問題ではなく構造の問題だ。ratchet なしで作り直すと、三ヶ月後に同じ場所で壊れる。
2. レガシーに知識が埋まっている
三ヶ月間 vibe coding しながら積み上げたビジネスルールがコードにある。作り直すとこのルールを記憶から再構成しなければならない。記憶は間違う。
3. すでにユーザーがいるかもしれない
プロトタイプがプロダクションになる瞬間がある。ユーザーが 1 人でもいれば「作り直し」はデータ移行、認証の切り替え、ダウンタイムを伴う。
救う方法を学ぶことは、作り直す方法を学ぶことより価値がある。 なぜならレガシーは常に存在し、新しいコードも 6 ヶ月でレガシーになるからだ。
第 11 講と第 1〜10 講の関係
| 講 | 最初からきちんと作る方法 | 第 11 講：壊れたものを救う方法 |
|---|---|---|
| 第 3 講 Hurl | API の契約を宣言する | 既存の動作を回帰テストとしてロックする |
| 第 4 講 yongol | SSOT から生成する | 既存コードから SSOT を抽出する |
| 第 6 講 Ratchet | パスしたらロックする | 直すが壊さない |
| 第 8 講 filefunc | コードを構造化する | レガシーコードを整理する |
| 第 10 講 DDL | スキーマを宣言する | 既存 DB から DDL を抽出する |
同じツール、逆方向。 第 1〜10 講が「上から下へ」（宣言 → 生成）だとすれば、第 11 講は「下から上へ」（既存コード → 抽出 → 宣言）だ。
codistill がこの「下から上へ」を自動化するツールだ。既存コードから SSOT を絞り出す。
遭難者から救助者へ
このプロセスを終えると、あなたは二つの能力を持つ：
- 最初から作る方法（第 1〜10 講）— 宣言して、検証して、ロックして、永続させる
- 壊れたものを救う方法（第 11 講）— 診断して、ロックして、修理して、抽出して、移行する
世の中のコードのほとんどはレガシーだ。最初から作るプロジェクトは少ない。救う能力の方が頻繁に使われる。
vibe coding は終わっていない。手綱の握り方を学んだのだ。
関連記事
- Supabase は vibe coding の罠だ — 第 11 講の理論的背景。なぜ BaaS で壊れるのか。
- Hurl が vibe coding のドリフトを止める — ステップ 2 のロックの詳細。
- codistill — 既存コードから SSOT を絞り出す — ステップ 1 の診断とステップ 4 の抽出のツール。
- huma — 一つのエンドポイントも漏らさない ratchet — ステップ 2 のロックのツール。
- yongol — AI コーディング SaaS の竜骨 — ステップ 5 の移行のツール。SSOT からフルスタックを生成。
- エージェントが操作できるコードベース — ブラックボックスを工場に変える原理。
- tsma — レガシーコードの回帰防衛線 — ratchet をかけた状態で修理する方法。
- エージェント操作可能なシステムの構築 — ロックされたレガシーをエージェントが触れるようにする方法。
Reins Engineering 全講義
| 講 | タイトル |
|---|---|
| 第 1 講 | AI に指示する方法 |
| 第 2 講 | AI を信じない方法 |
| 第 3 講 | 壊れないアプリ |
| 第 4 講 | 決定をコードの外へ |
| 第 5 講 | 手綱のある AI |
| 第 6 講 | パスしたらロックする |
| 第 7 講 | 忖度を反転させる方法 |
| 第 8 講 | エージェントの工場 |
| 第 9 講 | コードを超えた自動化 |
| 第 10 講 | データの法 |
| 第 11 講 | 壊れた vibe coding アプリを救う方法 |
出典
- Feathers, M. (2004). Working Effectively with Legacy Code. Prentice Hall. — Characterization testing の原典。レガシーコードにテストを被せて現在の動作をロックする技法。第 11 講ステップ 2 の理論的基礎。
- CVE-2025-48757 (2025). Lovable 生成アプリ 170 件以上で RLS が欠落し Supabase DB が公開。ameeba.com
- OG William (2026). “Moltbook Hack: Supabase Vibe Coding.” 150 万 API トークンが流出。blog.ogwilliam.com
- Cursino, D. et al. (2026). “Speed at the Cost of Quality? The Impact of AI Coding on Software.” MSR 2026. arxiv.org/abs/2511.04427 — Cursor 導入後にコードの複雑度が 41.6% 永続的に増加。vibe coding が壊れる定量的根拠。
- Liu, Z. et al. (2026). “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild.” arxiv.org/abs/2603.28592 — 6,299 リポジトリ・302,600 件の AI コミットを分析。未解決の技術的負債が 2025 年初の数百件から 2026 年 2 月に 110,000 件超に急増。
- Storey, M.-A. (2026). “From Technical Debt to Cognitive and Intent Debt.” arxiv.org/abs/2603.22106 — ドリフトの根本原因を「認知的負債」（共有理解の侵食）と「意図的負債」（根拠の未外部化）として理論化。
- Nguyen, H. et al. (2025). “Vibe Coding in Practice: Flow, Technical Debt, and Guidelines for Sustainable Use.” arxiv.org/abs/2512.11922 — vibe coding の flow-debt トレードオフを文書化した最初の学術論文。
- Cloud Security Alliance (2026). “Vibe Coding Security Crisis: Credential Sprawl and SDLC Debt.” labs.cloudsecurityalliance.org — AI 生成コードの 45% に OWASP Top 10 の脆弱性が含まれる。AI コミットでの秘密情報の露出率は 2 倍。
- GitClear (2025). “AI Copilot Code Quality 2025.” gitclear.com — 2 億 1100 万行を分析。コードの重複が 4 倍に増加、リファクタリング比率が 25% から 10% に低下。
- Encore (2026). “Backend as a Service (BaaS) in 2026: Providers, Tradeoffs, and Migration Paths.” encore.dev — BaaS からの移行はポーティングではなく、バックエンドの再書き換えになる。