バイブコーディングだけで、YouTube & Instagram の自動予約ツールが2日で完成した話― 個人開発が「設計者フェーズ」に入った実感 ―

AIでプログラミングする「バイブコーディング」という単語を、最近聞くことがあるかと思います。

私は、YouTube と Instagram の動画を完全に自動で予約投稿するツールを、バイブコーディングだけで 2日で作り切った。

正直に言うと、「早く作れた」こと自体よりも、作り方そのものが、これまでと別物だったことの方が大きい。

これは偶然でも、気合でもない。
開発の役割分担が、はっきり変わった結果だ。

前提：何を作ったのか（技術的な話）

今回作ったのは、いわゆる「投稿ツール」だけど、中身はかなりシンプルにしている。

YouTubeとインスタの自動予約システム

構成はこうだ

・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で日々の情報発信をしていますので、よろしければご覧ください。