個人開発に AI を入れると、実装速度は爆上がりします。
でも最近増えてるのが、「それっぽい機能は増えたのに、運用で死ぬ」パターン。
バグが怖いんじゃない。
“動くのに、説明できないコード” が積み上がるのが怖い。
この記事は、AI を使いながらも事故らないために、僕が PR に入れた AI 採用ゲート（チェックリスト）を公開します。
※Stripe / Webhook の具体例も入れます。
先に結論
- AI 出力の最大リスクは バグではなく「それっぽさ」
- “動くから OK” でマージすると、未来の自分に AI 借金 が回ってくる
- 対策は「上手く任せる」ではなく、マージする条件（採用ゲート）を固定すること
トランキーロ。
アクセルは AI に任せていい。
でもマージの許可証は、人間が出す。
【具体例】 Stripe / Webhook で 「動くのに壊れる」 を踏んだ話
ある夜、AI にこう投げました。
「Next.js + Supabase で認証つけて、Stripe 課金も繋いで」
朝には “動く” ところまでできてた。
ログインも通る。
課金も通る。
最高。
……でも 1 週間後、テストユーザーから連絡が来ました。
- 「解約したのに有料のまま」
- 「二重請求っぽい挙動がある」
原因は Stripe じゃなく、こちらの実装でした。
Webhook の処理が idempotency（同じ通知が複数回届いても 1 回だけ反映する性質） を考慮してなくて、イベントが再送されるたびに DB 更新が走って 状態がズレる。
しかも、そのコードを僕が説明できなかった。
“動くから OK” でマージしたのが、未来の自分への請求書になった。
【AI 借金の正体】 速度じゃなく 「止まれないこと」
AI 借金は、こういう流れで増えます。
- 動く → 安心する
- 理解が浅いままマージする
- 例外ケースで壊れる
- ログが薄くて追えない
- 修正が怖くて触れない
- さらに AI に継ぎ足す（借金の複利）
個人開発で怖いのは速度じゃない。
止まれないことです。
だから必要なのは「AI に上手に任せる技術」ではなく、“マージしない勇気” を仕組みにすること。
【解決策】 PR に入れる 「AI 採用ゲート」
AI 出力を採用するかどうかを、感覚で決めない。
PR にチェックを置いて、条件を満たさない限りマージしない。
これだけで事故率が下がります。
【コピペ OK】 AI 出力をマージする前の PR 採用ゲート （必須）
そのまま PR テンプレに貼ってください。
カスタマイズしても OK。
## 🤖 AI 出力をマージする前の採用ゲート（必須）
- [ ] 目的: この変更で「誰のどんな痛み」が減るか 1 行で言える
- [ ] 説明: 自分の言葉で処理 / 設計の流れを説明できる（AI の言い回し禁止）
- [ ] 例外: 壊れ方を最低 3 つ列挙した（入力 / 権限 / 外部 API / ネットワーク / 再送など）
- [ ] 捨てやすさ: 差し替え可能（境界が切れてる・モジュール化・feature flag）
- [ ] 観測性: ログ / メトリクスの最低限がある（必要箇所のみ）
- [ ] テスト: クリティカルパスに最低 1 つ（ユニットでも E2E でも可）
- [ ] リスク: 課金 / 認証 / 権限 / DB 根幹に触れるなら、人間レビュー必須
【“壊れ方” を先に見る】 Pre-mortem テンプレ （これが効く）
AI 出力は「理想系」を書くのが得意です。
でも現実は「最悪ケース」で壊れます。
そこで、壊れ方を先に列挙する Pre-mortem を PR にセットで置きます。
なぜ効くのか
- 再送 / タイムアウト / 例外みたいな「現実の敵」を先に想像できる
- “動く” ではなく “壊れても戻れる” へ視点が移る
- ログ / 監視 / リカバリを 必要最小限で入れられる
コピペ用テンプレ
## 🧨 Pre-mortem（壊れ方を先に考える）
| 失敗 | 起きると何が痛い？ | 対策 | 今やる/後でやる |
|---|---|---|---|
| Webhook 再送で二重反映 | 課金状態ズレ / 信用低下 | idempotency / event_id 記録 / upsert | 今やる |
| 例外時に状態が中途半端 | サポート地獄 | トランザクション / リトライ方針 | 今やる |
| ログが薄く原因不明 | 復旧が遅い | request_id / event_id をログに残す | 今やる |
| 重複イベント順序が逆転 | 状態が巻き戻る | 最新イベント判定（timestamp） | 後でやる |
Stripe / Webhook で最低限やること （例）
- event_id を DB に記録して二重処理を弾く
- ログに event_id / customer / subscription_id を残す
- “状態更新” は 単純な上書きにしない（イベント順序に注意）
AI に任せていい領域 / 危険な領域 （線引きルール）
✅ AI に任せて良い（むしろ任せたい）
- 雛形生成（CRUD、フォーム、型定義、UI の土台）
- 仕様の抜け漏れチェック
- ドキュメントの下書き
- 単純作業の自動化
- （販売寄り）訴求案・FAQ の候補出し
⚠️ AI に任せすぎると危険 （人間が責任を持つ）
- 課金・認証・権限・セキュリティ（責任が重い）
- データ設計の根幹（後で変えにくい）
- 運用設計（監視、障害対応、例外処理方針）
AI は優しい。
だからこそ、こちらが甘えると、静かに借金が増えます。
【まとめ】 AI 時代に強い個人開発は 「速さ」 じゃなく 「壊れても戻れる」
- AI 出力の最大リスクは “それっぽさ”
- “動くから OK” でマージすると、未来の自分が死ぬ（AI 借金）
- 対策は PR 採用ゲートで、マージ条件を固定する
- Pre-mortem で 壊れ方を先に見る とさらに強い
トランキーロ。
アクセルは AI に任せても、ハンドルは握る。
補足（任意）: 背景や、収益化の順番について
「なぜ AI で “進んでる感” に酔うと迷子になるのか」
「実装より先に固めるべき収益化の順番（LP → 価格 → 導線 → 検証 → 実装）」
このあたりの背景は note にまとめています（無料）: