要約
- 50以上のMVP構築経験を持つHarshil Tomarが「Vibe Coding 2.0」として18のルールを公開
- 核心メッセージ: 最強のビルダーは「コーディングが上手い人」ではなく「何を作らないかを知っている人」
- 日本でもバズ中 — チャエンさん、すぐるさんなど多数が紹介
元記事について
2026年2月24日、Harshil Tomar（@Hartdrawss）がXで公開したX Article「Vibe Coding 2.0 : 18 Rules to be the Top 1% builder」が海外で大きな反響を呼んでいる。
著者のHarshil Tomarは、AIプロダクト開発サービス「hartdraws.com」を運営し、過去365日で50以上のMVPを構築してきた実績を持つ。
Most people waste months building things that should have taken weeks. Not because they're bad developers. Not because they picked the wrong idea. Because they made decisions that felt right in the...
元記事URL: x.com/i/article/2025145098120691716
18のルール全文
✅ やるべきこと（DO's）
1. 認証は自作するな → Clerk / Supabase Auth を使え
2週間かけて誰も見ないログイン画面を作るのは最悪の時間の使い方。
2. UI は Tailwind + shadcn/ui 一択
Figma→実装が2-3時間で完了。手書きCSSは2026年にはもう不要。
3. 状態管理は Zustand + Server Components でシンプルに
ReduxもContext地獄も不要。ユーザー12人のMVPに過剰設計するな。
4. API は tRPC + Server Actions で十分
REST APIをゼロから書くのはMVP段階では過剰。
5. デプロイは Vercel ワンクリック
サーバー設定に使う時間＝プロダクトに使えたはずの時間。
6. DB は Prisma + マネージドPostgres
生SQLはMVPには不要。Supabase/Neon/Railwayで即セットアップ。
7. バリデーションは Zod + React Hook Form
フォーム周りの地獄を一発で解決。
8. 決済は Stripe 一択（45分で統合完了）
自作決済＝コンプライアンス違反リスク。絶対やるな。
9. エラー監視（Sentry）は初日から入れろ
本番で壊れた時、ユーザーのツイートで知るのは最悪。
10. アナリティクス（PostHog/Plausible）もローンチ前に設置
データなしの意思決定＝3ヶ月間違ったものを作り続ける。
11. APIキーは.envに。絶対にハードコードするな
12. ファイルアップロードは UploadThing / Cloudinary に任せろ
13. プレビューデプロイを設定せよ（Vercelなら自動）
14. UIコンポーネントは Radix + shadcn で車輪の再発明をやめろ
15. README は初日から書け（20分で4時間の節約）
16. フォルダ構成はクリーン&モジュラーに
17. オンボーディングと空状態のUXを作れ
混乱したユーザーは離脱する。使い方を教えろ。
18. Lighthouse でパフォーマンス計測（スコア70未満は危険信号）
❌ やってはいけないこと（DON'Ts）
| やってしまいがちなこと | なぜダメか |
|---|---|
| 認証の自作 | 時間泥棒No.1 |
| 生CSS | Tailwindで99%カバーできる |
| 状態管理の過剰設計 | 10人のユーザーに1000万人用の設計は不要 |
| カスタムAPI早期構築 | ユーザー0人で完璧なAPIは意味なし |
| 手動デプロイ | ヒューマンエラーの温床 |
| 生SQL | ORMを使え |
| 自作決済 | PCI準拠だけで数ヶ月かかる |
| 自作検索エンジン | Algolia/Meilisearchに任せろ |
| ログ/監視なしで本番リリース | 目を閉じて運転するようなもの |
| APIキーのハードコード | GitHubに漏れたら終わり |
| ファイルアップロードの自作 | 本番で想定外に壊れる |
| mainに直push | ブランチ運用は1人開発でも必須 |
| リアルタイム機能の自作 | Supabase Realtime/Pusherに任せろ |
| パフォーマンス無視 | 遅いアプリ＝死んだアプリ |
| オンボーディング省略 | ユーザーが勝手に理解すると思うな |
| リファクタリングの先延ばし | 2-3機能ごとに整理せよ |
| 完璧を目指して出荷しない | 「不完全でも出す」が常に勝つ |
💡 核心メッセージ
最強のバイブコーダーは「コーディングが上手い人」ではなく「何を作らないかを知っている人」
- ✔ 既存ツールを信頼せよ
- ✔ エコシステムを活用せよ
- ✔ 速く出して、本物のユーザーから学べ
"誰かが既により良く作ったものを、ゼロから作るな"
反響と議論
コミュニティの声
"Top 1% builders don't code better — they decide better." — @Tonynsight
"The discipline of not building is harder than building itself！！" — @Lovanaut
"the real rule 19: if you're still doing any of the 'don'ts' manually, you're not vibe coding. you're just coding with vibes." — @clwdbot
日本での反応
- チャエン (@masahirochaen): 全18ルールの日本語解説を投稿
- すぐる (@SuguruKun_ai): 記事を紹介・拡散
個人開発者視点での考察
2026年のVibe Coding = AIエージェント活用
clwdbotの指摘が核心を突いている：
18のルール全ての背後にあるメタパターン：「誰かが既に解決したところに時間を使うな」
2026年のアップデート — AIエージェントが「その誰か」になった。認証統合、決済設定、ファイルアップロード設定。エージェントなら各10分以内。
本当のルール19： 'やるな'リストを今も手動でやっているなら、それはVibe Codingではない。「バイブスでコーディングしている」だけ。
日本市場での適用ポイント
| ルール | 日本での注意点 |
|---|---|
| Stripe一択 | 日本向けにはPAY.JPも選択肢（Stripe日本法人の審査が厳しい場合） |
| Vercelワンクリック | 日本リージョン（東京）を選べばレイテンシ問題なし |
| shadcn/ui | 日本語フォントとの相性は要調整（font-sans設定） |
| Sentry | 日本語エラーメッセージの文字化け注意 |
まとめ
「Vibe Coding 2.0」の18ルールは、MVP段階での意思決定を高速化するためのチェックリストとして機能する。
重要なのは「何を作るか」ではなく「何を作らないか」。既に解決されている問題に時間を使わず、本当に価値のある部分—ユーザー体験とプロダクトの核心—に集中すること。
2026年、AIエージェントの進化により、これらのルールを守るコストはさらに下がっている。Vibe Codingの次のステージは、エージェントに「やるな」リストを任せ、人間は「何を作るか」の判断に集中することかもしれない。
参考リンク
- 元記事: Vibe Coding 2.0 : 18 Rules to be the Top 1% builder by @Hartdrawss
- 著者サービス: hartdraws.com
- 日本語紹介: チャエンさんの解説