ハクソク

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

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

45日前原文(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がテストしても、数時間かかるテストワークロードはやっぱり数時間かかる（つまりそれがボトルネック）」その通りだね。フィードバックループはコーディングエージェントにとって重要で、パイプラインをローカルで動かすことはできないからね。
└
>「これは部分的に、私が苦手なこと（例えばフロントエンドデザイン）が得意だから」みんなLLMが自分が苦手なことが得意だと思ってるよね。多くの場合、彼らは「もっともらしい」コードを出してるだけで、正確に判断する経験がないんだ。私はフロントエンドアプリ開発の経験が豊富だから、現代のツール（Claude w/Opus 4.6とそこそこ良いClaude.md）でも、フロントエンドの変更においてメンテナンス不可能なスラッジが混ざることがある。コードレビューで一日に何度もそのケースを見つけるよ。あなたの広いポイントには反論しないけど、何年もそのトピックに取り組んできたら、Claudeがその分野で生産品質のコードを作るには人間のガイダンスが必要だってすぐに気づくと思う。
└
現実とLLMについてのインフルエンサーの投稿の間には大きなギャップがあるね。LLMがかなりの加速を提供することには同意するけど、インフルエンサーたちはそれを信じられない数字に誇張しようとしてる。非インフルエンサーも、自分のLLMスキルを誇張して雇われたりLinkedInでの地位を上げようとしてる。私はLinkedInのフィードはほとんど読まないけど、チェックすると、アイデアから製品をN日で出荷したっていう投稿が溢れてる（その下には新しい仕事を探してるとか、あなたの会社と相談可能って書いてある）。これらの投稿の多くは、数年前にクリプト企業に夢中だった人たちから来てる。世界は本当に変わってるけど、新しいフロンティアでリーダーとしての主張をしようとするインフルエンサーやトレンドフォロワーの波がある。リアルな情報が欲しいなら、彼らは無視すべきだと思う。これらの誇張された投稿が、多くの人が実際に進行中の真の進展を見逃す原因になってるとも思う。彼らは明らかに虚偽の誇張を見て、逆にLLMが全く利益をもたらさないと思ってしまう。これがLLM否定派の逆波を生んでいて、彼らはただの流行で、すぐに消えると思ってる。彼らの数は減ってきてるけど、HNのLLMスレッドには、すべてが一時的で、数年後には昔のやり方に戻ると思ってる人が何人か集まってくる。
└
今やってるのは、AIを使ってMVPを作って、動くようにすること。その後、全部壊してもう一度始めるけど、少しずつ進める感じかな。もう一回壊して、さらにゆっくりやっていく。AIがやることやコードの一行一行を自分で確認できるところまで行くまでね。
└
あと、今は他の人のコードを読んでるわけだけど、みんながそれを好きなわけじゃないよね。実際、自称10倍コーダーのほとんどはそれを嫌ってる。だから10倍コーダーがやる代わりに、1倍コーダーがやることになるけど、その結果3倍の効率が0.3倍になっちゃう。
└
これ、Lovableでの私の経験そのものだよ。組織の一部では、LLMは信じられないほど強力で生産性を上げる存在。でも、私がいるInfraチームでは、逆に気が散ることが多くてマイナスの効果がある。LLMが提案する解決策が、ジッターのある挙動に対してリトライを追加することが多すぎる。今は、ホットパスでの実装をさらに注意深く管理しなきゃいけない。とはいえ、Amp/Claude CodeにGrafana MCPと読み取り専用のkubectlを与えたおかげで、デバッグにかかる時間が数日分節約できたから、やっぱりトレードオフはあるよね！
└
DevSecOpsの側面については、もっと具体的な理由で同意するよ。もし、ThirdPartyTool69があなたのコードスタイルを気に入らなくてパイプラインが失敗するなら、LLMに直してもらえるんだ。あるいは、100%のテストカバレッジに到達させたりとか。手作業でやるよりも、Cypress/Jest/SonarQubeの設定を更新してパイプラインが通るようにしたり、通る依存関係のバージョンを見つけてくれたりするんだ。
└
> 数時間かかるワークロードのテストは、人間でもLLMでもやっぱり数時間かかる（つまり、それがボトルネック）。実際、エージェントにコードベースで簡単なこと（ファイル名を変更したり、ビルドスクリプトや依存関係を修正したり）を頼んだとき、すごくひどい経験をしたことがある。人間よりもずっと時間がかかって、変更を試みるたびにフルCIパイプラインを実行して問題をチェックしてたから。人間なら、例えばリンターを使って基本的な問題を検出したり、影響を受けるターゲットで部分ビルドを実行したりして、時間を節約するけど、エージェントは経過時間の感覚がないんだろうね。
2026年にNFT製品をローンチするって… この記事の主旨じゃないのは分かってるけど、マジで？
└
そうだね。LLMのコーディング体験には共感できる部分が多いけど、NFTの件は残念だわ。
└
友達（まあ、友達の友達だけど）がまだNFTの宝くじをやってるよ。みんなギャンブルが好きなんだね、笑
└
その「製品」の開発からの視点で、いわゆる「製造されたバイラリティ」について話してるけど、全然意味がないよね。
Claude Codeを評価すればするほど、世界で一番不安定なゴルファーみたいに感じる。ホールの近くまで一発で行けることもあるけど、パットを決めるのに何時間も、何日も、何週間もかかることがある。プログラミングには80-20の法則があるけど、今の最先端のコーディングモデルでは、その分布が過去最も極端になってる。
ギャップは確かに存在する。でも、このスレッドのほとんどはその理由を誤診してると思う。AIが生産品質のコードを生成できないわけじゃなくて、多くの人が持っているAIのメンタルモデルが、プロダクションコードの複雑さの最後の20%を解消するための間違ったインタラクションモデルを使わせてるんだ。著者はそれを偶然証明しちゃったね。プロンプトをやめてFigmaを開いてデザインを始めた瞬間、Claudeは実装をバッチリ決めた。ボトルネックは決してコード生成じゃなくて、そのコードを生成する前に必要な思考だったんだ。多くの人は複雑さが出てから思考を外注してるけど、実際にはコードの一行も生成する前にアーキテクチャの思考を前倒しで行うのが正しいパターンなんだ。100時間のギャップのほとんどは、常に時間がかかるアーキテクチャとデザインの作業なんだよね。生産グレードのソフトウェアを望むなら、その作業をAIが排除することはない。でも、正しく活用すれば、思考そのものを劇的に速くできる。実際に思考パートナーとして使わないと、ただのコードマシーンになっちゃうよ。
└
うん、何を望んでるかを伝えるのは難しいよね。今、シンプルな一行のテキストエディタを作ってて、フレームオプションをデザインしてる。スタートとエンドのマーカーがあってね。これをLLMに正しくやらせるのがすごく難しかったんだ。でも、結局ペンと紙を使って、欲しいものを描いて、写真を撮ってLLMに渡したらうまくいった。
└
他の人がどうやってるかはわからないけど、コードを書くことは問題の理解に欠かせないんだ。アーキテクチャやデザインの作業は、そのプロセスを経ないと難しいことが多いよ。
└
そうそう、時間を戻して、ここで言ってること以外を提案しなかったらいいのにって思う。AIは自分のためにやってくれるわけじゃなくて、一緒にやってくれるんだ。AIがコードを書く前に、自分が何を望んでるかを考えなきゃいけない。考えることが全てのゲームなんだ。ただ、デザインを考えるためにClaudeをよく使うってことも言っておくよ。時には何時間も考えながらやってるし、それでもたくさんのことが進んで、今の素晴らしい時代以前には絶対に手を出さなかった技術を使ってる。
└
その通り。最初から本当のプログラムのように扱う必要があるよ。
└
これ。さらに、著者は本当にビジネスの深刻な問題を解決するためじゃなくて、アプリを作ること自体や学ぶためだけにアプリを作ってるみたい。単なるおもちゃプロジェクトに基づいた「大きな」LLMの能力の主張だよね。
「動いている」ことと「出荷する」ことは別物だよね。ソフトウェアを売り始めて、人にお金を払わせたり、頼らせたりするようになると、ルールが大きく変わる。授業を受けたりデモを見たりすると、いつも慎重に選ばれた例を使って、教えていることをめちゃくちゃ簡単に見せるんだ。それが、新しい技術が「簡単」だってデモする時に見えることだよ。数日前、友達のオフィスに行ったんだけど、彼はインターネットテクノロジーの会社を経営してて、サイトを作ったり、SEOやホスティング、いろんな技術サービスを提供してる。彼はOpenClawに夢中になってて、会社全体を再配線してるみたいだった。本当にワクワクしてたよ。帰る時に、彼の部下のデスクに静かに寄って、尊敬してる冷静な若い女性に「バックアップはちゃんと取ってね」ってささやいた。
ソロプロジェクトに100時間ってのは妥当な感じだね。みんなが過小評価してるのは、最後の20%がただの仕上げじゃないってこと。アプリが他の人のスマホでクラッシュしないようにするための、地味な防御的な作業が必要なんだ。最近React Nativeのアプリを出したんだけど、開発時間の約30%は、すべての非同期呼び出しをtry/catchでタイムアウト付きでラップしたり、権限拒否をうまく処理したり、壊れたAsyncStorageがアプリを壊さないようにしたり、古いデバイスでのエッジケースをテストしたりするのに使った。どれも楽しい部分じゃないし、デモにも出てこない。でも、「自分のマシンでは動く」と「本番環境で動く」の違いなんだよね。Vibecodingはデモまで持っていくけど、その後のギャップが全てなんだ。
└
もうやめてよ、その話
└
> 開発時間の約30%は、すべての非同期呼び出しをtry/catchでタイムアウト付きでラップしたり、権限拒否をうまく処理したり、壊れたAsyncStorageがアプリを壊さないようにしたりするのに使った これはまさにLLMが得意とするタスクだね。
└
このコメント、LLMが書いたんじゃないの？追記: pangramがこれが100% AI生成だって確認してくれたのに、なんでここでダウンボートされてるのか面白いね。
みんな80/20って言うけど、それじゃ実際の状況を過小評価してるよ。最後の20%はただ難しいだけじゃなくて、最初の80%で起きたことが影響してるんだ。エージェントが早い段階でショートカットを取ると、次のステップはそれがショートカットだとは気づかない。ただ渡されたものを基に構築するだけだから。そして、その次のステップも同じことをする。だから80時間目には、UIバグみたいに見えるものを修正しようとして、実際の問題は三層も前にあることに気づくんだ。「難しい20%」をやってるわけじゃなくて、知らないうちに取ったショートカットの利息を払ってる感じ。これを書きながら、子供にレゴを組み立てるのを手伝った時のことを思い出してる。著者は偶然にこれを理解したんだ。プロンプトをやめて、実際に欲しいものをデザインするためにFigmaを開いた。それが正解だよ。次のステージがそれに基づいて構築する前に、チェーンを断ち切ったんだ。100時間ってのは、そうしなかった時のコストなんだよ。
僕の経験では、Claude Codeを適切に使えば、ほとんどのプログラマーよりも良い仕事ができるよ。「適切に使う」っていうのは、例えば: - ガードレールを設定すること: 静的型付け言語を使う、リンターを使う、CLAUDE.md/skillsでベストプラクティスを確認する。 - 技術的な決定をする際にリサーチを指示すること、例えば「先行技術をオンラインで調べて」や「Xのライブラリを比較してリサーチして」など。 - スピードよりも品質とメンテナンス性を優先するよう指示すること。締切や予算がないと言ってもいい。 - 使用するライブラリやAPIのために詳細なドキュメントを用意すること。通常、これを前処理ステップとして行うよ。「Yのドキュメント50ページを見て、それをスキルにまとめて」みたいに。 - 自分の仕事をチェックするためのフィードバックループを持つこと。 - ショートカットを取れないように外部システムで制約をかけること、例えば「ラチェット」チェックを使って、リンターの抑制や`unsafe`ブロックを追加できないようにする。 そして、最も重要なことは: - 良いコードを書く方法を知っているオペレーターがいること。何が良いUIやアプリかを伝えられないと、いいものはできないよ。例えば、JSよりもネイティブのHTML/CSSを優先するように指示したり、Reduxのような複雑さを避けたり、アニメーションを追加するけど使いやすさに焦点を当てたり、UIがアクセシブルであることを確認したりすること。 - 良い計画を作るように導いてくれるオペレーターがいること。正しいものを作るだけでなく、それをテストする方法や、他に必要な特性（監視/可観測性、レイテンシー、可用性など）を説明すること。これらの多くは「正しいものを文脈/計画に入れる」ことにかかってる。そうしないと、LLMから悪い出力が出るのは当然だよ。開発者に「Xを作って」と言っても、詳しく説明しないと悪い出力が出るのと同じだね。
└
生成されたスキルはどこに保管してるの？これって、めちゃくちゃにならない？
最近のサイドプロジェクト（WasmからGoへの「トランスパイラ」）を作ったのは、LLM/エージェントでできる限界を試すためだった。確かにスピードアップにはなったし、いくつかのアイデアにも本当に役立ったけど、10倍にはならなかった。自分で設計しなかった部分は、忙しいビーバーがそれを壊す前に必ずチェックして改善する必要があった。それでも、フロンティアモデルがGoコードを「推論」してASTを生成して他のGoコードを作る様子には感心したし、生成時と実行時で何が利用可能かを明確に分けているのもすごいと思った。そこには洗練さがあって、「これが生成したいコードの種類だ、ASTを作って」とよく伝えていた。さらに、より速いモデルが少し曖昧な検索と置換に十分な性能を持っているのも良かった。例えば、「このリファクタリングをやりたい、ここで2つのサンプルを作ったから、他の400もやってくれる？」とか、「言語Xでこのテストケースがあって、2つ変換したから、他の100もできる？」みたいな。こういうシンプルなことでも、かなりの時間を節約できたよ。その結果、SQLiteをWasmにコンパイルして、約1ヶ月の暇な時間で500k行のGoに変換できるものができた。https://github.com/ncruces/wasm2go