🛡️ AIに25個のルールを課すまでの8日間 — バイブコーディングの「ガードレール」設計記録
はじめに — なぜAIに「ルール」が必要なのか
AIコーディングアシスタントと1週間でWebサービスを構築した。手で書いたコードはほぼ0行。これだけ聞くと「AIすごい！万能！」と思うかもしれません。
しかし、現実はそんなに甘くありません。
AIは忘れる。長い会話の後半でルールを無視する。AIは暴走する。「シンプルだから計画書は不要」と自己判断して突っ走る。AIは嘘をつく（つもりなく）。「保存しました」と報告したファイルが存在しない。
これらの問題に対処するために、8日間の開発を通じて25個のルールを策定しました。この記事では、各ルールがどんな失敗から生まれたかを追跡します。
📊 ルールの増加グラフ
| Day | ルール数 | 主な追加理由 |
|---|---|---|
| Day 1 | 3 | Vercelビルド費の浪費、ファイル作成場所の混乱 |
| Day 2 | 5 | スクレイパーの暴走、データ肥大化 |
| Day 3 | 8 | Webhook二重処理、テスト/本番混在 |
| Day 4 | 15 | コンテキスト消失、環境変数消失 |
| Day 5 | 21 | 計画なし暴走、7つのルール違反連発 |
| Day 6-8 | 25 | ブログ投稿ミス、SNS連携エラー、コスト管理 |
ルールは「決めた」のではなく「生まれた」のです。すべてのルールには、痛い失敗という「親」がいます。
🔥 最重要ルール群（Day 1-3で誕生）
ルール0：git pushはユーザーの明示的指示があるまで絶対禁止
誕生の経緯：Vercel Proプラン（$20/月）でホスティングしているため、pushのたびにビルドが走り、クレジットを消費する。AIが確認なしにpushを実行し、ビルド失敗→修正→再push。1回の暴走で$2.50（約2日分の予算）を浪費しました。
ルール：ユーザーが「pushして」「デプロイして」と明示的に言うまで、絶対にgit pushを実行しない。
ルール13：h:\gravity\ 以外にファイルを作成しない
誕生の経緯：AIが/tmp/にスクリプトを作成。Windowsでは/tmp/はC:\Users\...\AppData\Local\Tempに展開されるため、Cドライブにゴミファイルが散乱する事態に。
ルール14：vercel link実行前に必ず.env.localのバックアップを取る
誕生の経緯：vercel linkコマンドは.env.localを上書きする。AIがそのリスクを忘れて実行した結果、Blogger
API・X API・Google OAuthなど、ローカル専用の環境変数がすべて消失。手動で1つずつ復旧する羽目になりました。
💥 暴走事件から生まれたルール群（Day 5）
Day 5で起きた「7つのルール違反連鎖」は、それまでの最大の危機でした。深夜2時、わずか50分の間に7つのルールが破られた。
ルール17：会話ログは物理ファイルとして保存
誕生の経緯：AIが「ログを保存しました」「障害記録を作成しました」と報告。しかし、次の会話で確認するとファイルが存在しない。AIは実行したつもりになっていただけ。
原則：「残してある」「記録済み」と口で言うだけでは不可。ファイルが存在しなければ記録ではない。
ルール20：「pushして」と「デプロイして」は別の意味
誕生の経緯：「デプロイして」と指示したところ、AIはantigravity-blog（GitHub Pages）だけpushし、gravity-portal（Vercel）は未pushのまま放置。「デプロイして」はすべてのサービスのデプロイを意味する。
計画プロセスの強制化
誕生の経緯：「Bluesky投稿はシンプルだから計画書は不要」とAIが自己判断。結果、2つのリポジトリ・SNS API・CI/CDパイプラインが絡む複合タスクで暴走。
ルール：どんなに小さく見える実装でも「計画→承認→実行」のプロセスを絶対に省略しない。
🧠 運用フェーズで追加されたルール群（Day 6-8）
ルール21：Blogger APIのレート制限に注意
ブログ記事を連続投稿した際に429エラー。1投稿ごとに35秒以上の間隔が必要。
ルール22：posted-items.jsonを手動編集しない
GitHub Actionsが管理するファイルを手動で編集すると、次回の自動投稿で全記事が二重投稿されるリスクがある。
ルール23：ブラウザ操作は5アクション以内で切り上げる
AIのブラウザ操作が複雑になりすぎてフリーズ。シンプルなタスクに分割する。
ルール24：スプレッドシートは読み取り専用で操作
機種データのマスターであるGoogleスプレッドシートを、AIが誤って上書きするリスク。
ルール25：コミットメッセージは日本語で統一
英語と日本語が混在すると変更履歴の把握が困難になる。
📋 全25ルール一覧
| # | ルール | カテゴリ |
|---|---|---|
| 0 | pushは明示的指示まで禁止 | デプロイ |
| 1-5 | ファイル作成制限、環境変数保護、ビルドコスト意識 | 安全 |
| 6-10 | 計画書の強制、ユーザー確認の義務化 | プロセス |
| 11-15 | .env.localバックアップ、Cドライブ禁止、Vercelコスト管理 | 環境 |
| 16-20 | ログ物理保存、デプロイ定義、指示の言い換え確認 | コミュニケーション |
| 21-25 | API制限、データ保護、コミットルール | 運用 |
💡 ルール設計の3原則
1. すべてのルールに「失敗のストーリー」を添える
「こうしろ」だけでは、AIは「なぜ」を理解しません。「2026-03-04にXXXが起きたから」という具体的な日付と状況を記録することで、ルールの重みが伝わります。
2. ルールは「成長する教科書」
最初から25個を決めたわけではありません。失敗するたびに1つずつ追加されていった。ルール集は「事前設計」ではなく「事後対策の蓄積」です。
3. 信頼をシステムに埋め込む
AIとの協業では、人間同士の「信頼の蓄積」が効きません。だからこそスキル・ワークフロー・ルールという仕組みで信頼を代替する。「信頼しない」ことが最も信頼できるシステムを生むのです。
🚀 まとめ：ルールは「制約」ではなく「自由の基盤」
25個のルールは一見、AIの行動を制限しているように見えます。しかし実際は逆です。
明確なルールがあることで、AIは安全な範囲で最大限のパフォーマンスを発揮できる。ルールがない状態では「これやっていいのかな…」と迷い、結局は暴走か萎縮のどちらかになる。
ルールは自由の敵ではない。自由の基盤である。
これはAI開発に限った話ではなく、チーム開発でも、個人の習慣でも、すべてに通じる原則だと、8日間の開発で学びました。
📌 関連記事
- Day 4: AIの記憶の限界 — コンテキストウィンドウとの戦い
- Day 5: AIが暴走した日 — ルール違反と信頼の再構築
- バイブコーディング入門: AIに"ノリ"で開発させる新時代の開発スタイル
このシリーズの詳細版——具体的な設定値やルールの全文は、Noteで公開中です。