個人開発に 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 にまとめています（無料）: