AIでプログラミングする「バイブコーディング」という単語を、最近聞くことがあるかと思います。
私は、YouTube と Instagram の動画を完全に自動で予約投稿するツールを、バイブコーディングだけで 2日 で作り切った。
正直に言うと、「早く作れた」こと自体よりも、作り方そのものが、これまでと別物だったことの方が大きい。
これは偶然でも、気合でもない。
開発の役割分担が、はっきり変わった結果だ。
前提：何を作ったのか（技術的な話）
今回作ったのは、いわゆる「投稿ツール」だけど、中身はかなりシンプルにしている。
構成はこうだ
・YouTube Data API / Instagram Graph API
・Supabase（DB + Auth + Edge Functions）
・スケジューラ（日時トリガー）
・最小限の管理UI
やっていることは、
- データベース（DB）に「動画パス・投稿文・公開日時」を登録
- 指定時刻にサーバー側でAPIを叩く
- 成功 / 失敗をログに残す
それだけ。
でもこの「それだけ」を、設計ミスなしで一気に通すのが、普通は難しい。
なぜ2日で終わったのか（ここが本題）
答えはシンプルで、
人間がコードを書かなくなったから
もう少し正確に言うと、
- 人間：
- 構造を決める
- 境界条件を決める
- 運用を想定して判断する
- AI：
- 実装を書く
- API仕様に合わせて調整する
- エラーケースを列挙する
この分業が、今回は最初から崩れなかった。
バイブコーディングの実態
バイブコーディングって、「雰囲気で作る」みたいに誤解されがちだけど、実態は違う。
やっていることはむしろ、
- 抽象度の高い要件定義を、対話で詰める
- 設計レビューを、AI相手にリアルタイムで回す
- 実装の正確性は、AIに委譲する
という、かなり設計者寄りの作業。
たとえば今回も、
- 投稿失敗時に「どこで失敗したか」をどう残すか
- 将来、TikTokを足すならどこを分離すべきか
- 1日12本以上になったときの耐久性
完成形をイメージした後に、このような仕様を論理的思考かつ批判的思考に考え、先にAIと詰めた。
だから、あとから壊れない。
「AIが賢いから早い」ではない
ここ、勘違いされやすい。
AIが賢くなったのは事実だけど、それだけでは2日は無理。
重要なのは、
・何を自動化するか
・何を人間に残すか
・どこを捨てるか
この判断ができるかどうか。
つまり、プログラマーというより、アーキテクトの視点。
ここでスクールの話をさせてほしい
こういう開発ができるようになると、よく聞かれる。
「それ、才能ですよね？」
違う。
これは才能じゃなくて、訓練の方向が変わっただけ。
従来のスクールは、
・文法
・フレームワーク
・チュートリアル完走
に時間を使う。
でも今、本当に必要なのは、
・要件を言語化する力
・構造を分解する力
・AIに正しく「仕事を伝える力」
ここが大切だ。
AIDE MODEL ARCHIVES / NOVA Link Lab でやっていること
私たちがやっているスクール（NOVA Link Lab）では、プログラミングだけではなく、デザインも、動画も、最初から バイブコーディングの思考で進めている。
・AIを「答えを出す存在」ではなく、共同開発者として扱う
・コードは「書けるようになる」より「書かなくても設計できる」ことを重視
・デザインや動画も、「何を目的にするか？」を決めてから制作
だから、今回みたいなツールも「特別な成功例」じゃない。
再現できる。
技術者へ
もし今、
- 学習はしているけど、実用物が作れない
- AIを使っているのに、結局自分で詰まる
- 個人開発のスピードに限界を感じている
なら、問題は努力じゃない。
役割のアップデートが起きていないだけ。
まとめ
・YouTube & Instagram の自動予約ツールは、バイブコーディングだけで2日で完成した
・鍵は、人間が設計と判断に集中し、実装をAIに渡したこと
・これは一部の人の話じゃなく、これからの常識になる
もしこの作り方をちゃんと体系的に学びたいなら、NOVA Link Labを訪れるといい。
次は、「何を作るか」じゃなく「どう作るか」を一緒に考えよう。
noteで日々の情報発信をしていますので、よろしければご覧ください。
コメント