ハクソク

世界を動かす技術を、日本語で。

「バイブコーディング」プロトタイプと実用製品の間の100時間のギャップ

2026年3月15日原文(kanfa.macbudkowski.com)

概要

  • vibecoding でアプリ開発を行った100時間の詳細な体験記
  • 「30分でアプリ完成」の現実と実際の開発のギャップを検証
  • AIツール を使いながらも本番品質を目指した苦労と工夫
  • UI/UX設計、インフラ構築、ローンチ までの課題と学び
  • AI時代の開発で大切なことと、今後の展望についての考察

vibecodingの現実：100時間で学んだこと

  • 「30分でアプリ完成」 という言説の現実性を疑問視
    • 単純なコピー、バグだらけ、エンゲージメント目的の投稿が多い印象
  • AI活用の経緯
    • 2023年末、前職スタートアップでAIコーディングを導入
    • LLMの精度不足 やOSSプロジェクトでの懸念もあったが、早期導入で優位性を獲得
    • GPT-4 preview、Claude、Cursor などを活用
  • AIの限界を見極めたかった理由
    • Kiwiでのvibecoding経験や、Python/JS/スマートコントラクトの実践経験
    • インフラの隠蔽されたReplitやLovableを避け、自分で全工程を体験したかった
  • SLC（Simple, Lovable, Complete）モデルを採用
    • Jason Cohenの提唱するSLCを目指し、「Cryptosaurus」アプリを企画
    • pfp（プロフィール画像）を恐竜化するシンプルな構成

プロトタイプ作成から本番品質への道

  • プロトタイプは1時間で完成
    • ChatGPTやOpus 4.5、Gemini APIを使い、最初の動作確認までスムーズ
  • デザイン・UI/UXの壁
    • Coolorsでカラーパレット選定、UIの再設計を何度も繰り返し
    • ClaudeのUI提案が複雑化し、Figmaを使えば10倍速いと実感
    • LLMへのプロンプトと確認・修正の繰り返しで時間がかかる
  • 画像生成のチューニング
    • edge caseのpfpで画像生成が崩れるため、プロンプトやスクリプトを200回以上調整
    • prompt.tsは274行に膨れ上がる

インフラ構築と本番公開への苦闘

  • 独自ドメイン取得とVercel/AWS構築
    • Cloudflareでドメイン取得、Vercelでフロント、AWS（S3/Lambda）でバックエンド
    • AWSの複雑さに苦戦しつつ、LLMの指示で何度も修正
  • Farcaster Mini App対応
    • テスト環境の制約や、マニフェスト・noindex対応、複数アカウント運用
    • モバイルUIとMini App UIの不具合修正に時間を要する
  • NFTミント・スマートコントラクトのセキュリティ強化
    • onlyMinterの設定やSafeによる権限管理
    • 100人同時利用時のスケーラビリティ対策、レートリミット・有料APIへの移行

ローンチとその後の課題

  • 事前登録500人、ローンチ直後にシステム障害
    • 複数人同時利用でAPIが正常動作せず、支払いのみ通るバグ発生
    • 迅速な返金対応とDMでユーザー満足度を維持
  • 最終的な成果
    • 1,000人以上がダウンロード、180人以上が有料購入（$2）
    • Farcaster Mini AppストアでTOP3入り
    • SLCとしては十分な成果と自己成長を実感

振り返りとAI開発の本質

  • 「30分で完成」と「本番品質」のギャップ
    • プロトタイプは早いが、UI/UXやエッジケース対応、本番運用で100倍の時間
    • ユーザー体験や品質へのこだわりが時間を要する主因
  • AI活用の工夫
    • LLMごとの特性を理解し、シンプルな設計を指示
    • フローチャートや設計図の作成をAIに任せて効率化
    • デザインはFigmaなど専用ツールと併用することでストレス軽減
  • エンジニア経験の重要性
    • LLMでは解決できない細かなバグやUI問題は、経験豊富なエンジニアの助けが不可欠
    • 高度な問題は人間の知見が最速
  • AI時代の開発体験
    • かつての「手を動かすクリエイティブな楽しさ」は薄れ、今は「デジタル従業員への指示役」に
    • それでも、反復作業が減り、より多くの創造に時間を使えるメリット
    • 「最後の10%」こそがプロダクトの質を分ける

まとめと今後

  • Tom Cargillの名言 「最初の90%が開発時間の90%、残り10%が残りの90%」を実感
  • AIで最初の90%は高速化、残り10%でクラフトマンシップを発揮できる時代
  • Lovableなアプリ を作るためには、細部へのこだわりが不可欠
  • vibecodingは「つまらない作業」を減らし、より良い体験創出の余地を広げる
  • 今後も「楽しくものづくり」できる環境を大切にしたい

謝辞・参考

  • Cryptosaurus の体験はFarcasterのMini Appで公開中
  • Pugson、Kris Kaczor、Sayangel に感謝
  • Stage 2ではdinoで遊べるゲーム機能を追加予定

Hackerたちの意見

進化したバイブコーディングがあれば、特定の製品の必要性なんて消えちゃうよね。必要だったから、自分のためだけにサクッと作っちゃった。

└

添付ファイルやいろんな機能をつけたJiraを作ったんだ。まるで子猫みたいにスムーズに動くよ。SaaSは絶滅危惧種だね。特に、Jiraプラグインを書くのに1日1000ドルも取ってた仕事はね。

└

でも、そんなのは要らないんだ。もっと時間をかけて、完璧な製品を考えてくれる人がいて、その製品にお金を払って心配しなくて済むのがいいな。

└

これは夢物語で、「十分に進化した」ってのはかなりの重みがあるよ。人々が、自分で作ったソフトウェアを立ち上げてデバッグするよりも、何千人ものユーザーによってテストされ、デバッグされ、証明されたものにお金を払う方がいいと思ってるって本気で思ってるの？ そんなの、すごくシンプルなスクリプト以外で誰がやるの？ LLMが完璧なワンショットソフトウェアを安定して出力するなら話は別だけど。

└

関連エピソード：12歳の息子が使ってたスピードキュービングのオンラインタイマーが、ブラウザをクラッシュさせて広告で邪魔されるのが嫌だったんだ。より良い代替をググる代わりに、クラウドコードを使って、彼が望む通りに動くウェブサイトを一緒に作った。彼は10回以下のプロンプトで1時間以内に自分で動かせるようにしたよ。自分はちょっとだけ、GitHub Pagesでオンラインにするのを手伝っただけ。

└

実際にそんな製品はどれくらいあるの？ GitHubやDatadog/Sentry/Cloudflare、AWS、Tailscaleを簡単に置き換えられるなら最高だね。自分の考えでは、作って所有する方が買ったり借りたりするよりもいいと思う。特にデータに関しては、他の会社に送るよりも自分のテレメトリーデータを所有する方がずっといいから。でも、あなた（または誰か）がこれらのサービスの代替をバイブコーディングで作るのは、そう簡単じゃないと思う。彼らは大きくて難しい問題を解決してるから。

└

https://xkcd.com/1205/ （時間マトリックスは価値があるのか）LLMは上のチャートの計算を劇的に変えるよね。

└

コードだけが価値のある製品は確かに厳しい状況にあるね。でも、実際にそんな製品はどれくらいあるんだろう？みんなにおすすめなのは、今投資で人気のHALOを調べてみること。それから、コードの価値がゼロだと仮定して、他にどんな価値があるかを考えてみてほしい。意外と気づいてない価値がたくさんあるから。

自分はDevOps/SREとして、ほぼ20年間フィンテック（銀行、ヘッジファンド、スタートアップ）やクリプト（L1チェーン）をやってきた。バイブコーディングとプロダクションコードについての考えをまとめると：

  • バイブコーディングは、LLM以前よりもPoC/MVPを10倍速く作れる可能性がある。
  • これは、自分が苦手なこと（例えばフロントエンドデザイン）を得意としているから。
  • でも、その後はパフォーマンスや正確性、情報の流れ、セキュリティなどを確認しないといけない。
  • LLMがこれを楽にしてくれるけど、やり取りが多いから改善は2〜3倍に落ちる。自分がコードを確認する必要もあるしね（もちろん、別のLLMがその一部をやることもできるけど、ちゃんと設定しないといけないし）。
  • 例えば、出力を決定的にチェックするスクリプトやプログラムがあれば、やり取りは早くなる。
  • でも、数時間かかるテストワークロードは、人間でもLLMでも結局数時間かかるから、そこがボトルネックなんだよね。 だから、バイブコーディングの効果について、みんなが全然違う報告をしてるのはこういう理由だと思う。データパイプラインを作ったことがない人が、LLMが数分で作れるのを見たら魔法みたいに思うだろうけど、複雑なトレーディングやコンプライアンスのデータパイプラインをデバッグしてきた人は、LLMが少し時間を節約してくれるけど、10倍の時間は節約できないって気づくんだよね。
└

今、JavaのHFTエンジンを作ってるんだけど、AIが間違えることの多さに驚いてる。すべてをベンチマークしなかったら、もっと最適化されてないソリューションになってたと思う。例を挙げると、AIはProject Panama（FFM）を使いたがるけど、確かに従来のOOアプローチよりは速いけど、ほとんどの場合ベストではない。非推奨のUnsafeコールを使うことじゃなくて、大量のデータに対するVector/SIMD操作にはプリミティブ配列の方が良いって話。ファイル読み込みにはNIOがFFM + mmapよりも優れてる。AIを使って、専門知識がない人が開発するよりも時々良いものを作ることはできるけど、そのギャップは100時間以上あるんだよね。

└

テストが魔法みたいなもんだね。ローカルでのテストや、高スループットのテストができるようになったおかげで、スピードが上がる。テストケース自体が焦点になってくるけど、LLMはそれを正しく処理できないことが多いんだよね。

└

「人間かLLMがテストしても、数時間かかるテストワークロードはやっぱり数時間かかる（つまりそれがボトルネック）」その通りだね。フィードバックループはコーディングエージェントにとって重要で、パイプラインをローカルで動かすことはできないからね。

Hacker Newsで議論の続きを見る