ファイナンシャルプランニングMVPの構築:30日間のAI支援開発、$127 の費やし、そして実際に重要だった教訓

TL;DR: AI支援コーディングを用いて創業者向けのファイナンシャルアドバイザーツールを1ヶ月かけて構築。$127 クレジットを消費し、可能な限り多くのミスを犯し、最終的には1人の創業者から月額$50の検証を得るに至った。本当の教訓:AIはスピードに優れるが、正確さには苦手意識がある。少ない方が多いよりも良い結果をもたらすこともある。


解決すべき価値のある問題

私は何年も創業者と仕事をしてきた。何度も繰り返される同じシーンを見てきた:VCが「解約率が2%下がったらどうなる?」と尋ねると、創業者の顔が真っ白になる。その答えは47タブのExcelの悪夢の中に埋もれている。会議の勢いは失われ、創業者は何時間もかけて数式を再構築し、セルは壊れ、循環参照がすべてをクラッシュさせる。

私が何度も耳にした核心のフラストレーションは:「一度だけ財務モデルを作ったことがある。シナリオの変更を頼まれるたびに、全部作り直さなきゃいけなかった。」

多くのアーリーステージのスタートアップは未だにスプレッドシートを使っている。ほとんどの創業者はそれを嫌っている。だから、AIがこの罠から抜け出す手助けができるか試してみることにした。

設計図なしで構築:最初の2週間

Week 1:楽観主義は高くつく

最初は2-3週間でできると確信していた。SNSでAIインフルエンサーたちが簡単に見せているのを見ていたからだ。

最初のロードマップはこうだった:

  • リアルタイム同期可能なAI搭載のファイナンシャルコックピット
  • QuickBooksとStripeの統合
  • 投資家向けエクスポート付きシナリオプランニング
  • 数ヶ月ではなく数週間で完成

しかし、現実は違った。

曖昧な指示のコスト

最初のミスは、AIエージェントをマルチタスクできると誤解したことだ。前のリクエストが終わる前に3つのリクエストを同時に送った:

  • 「ダッシュボードをもっときれいに」
  • 「ダークモードを追加」
  • 「計算バグを修正」

AIはこれらを同時に処理しようとし、混乱して何も完璧にできないものを作り出した。その結果、6回のロールバック、3時間のデバッグ、$23 クレジットを消費した。待てばよかっただけだ。

UIがすべてを壊した

「夜間モードを追加して」と頼んだら、AIは47の変更を加えた。結果は、白背景に白文字、見えないボタン、インターフェースの完全崩壊だった。フォントや背景を合わせるのに3日かかり、UIの複雑さは予想以上に早く拡大することを学んだ。

魔法の発見

そして、すべてを変えたフレーズを見つけた:「私と理解を確認せずに変更しないでください。」

この一言があれば、$50以上節約できたはずだ。AIに実行前にアプローチを説明させることで、誤解を事前にキャッチできた。

Week 2:移動による進捗遅延

日本の空港ラウンジでの作業は謙虚な教訓をもたらした:

  • ホテルWiFi + Replit開発=絶え間ないフラストレーション
  • モバイルでTypeScriptエラーをデバッグするのはほぼ不可能
  • ロールバックボタンは最も頼れる友人になる

TypeScriptを「モダンな選択」と考えて選んだが、失敗だった。理解していない言語だ。財務数式が複雑になると、構文と格闘する時間の方が多くなる。例:シンプルなランウェイ計算に2時間かかった。TypeScriptは型の不一致を頻繁に指摘してきた。

未来の構築者へのメモ: 実際に理解している言語を選べ。プロトタイピングのために学習コストを払う価値はない。

15日目には、Replitのクレジットは枯渇寸前だった。Week 1は$34、Week 2は$93かかった。変更→テスト→ロールバック→再挑戦のたびに$2-5を消費。新たなルールを設定した:$40 週ごとに最大、または停止してなぜこれほどクレジットを使うのか再考。


すべてが変わった瞬間:ユーザーフィードバックWeek

Day 17:テスター募集

創業者のSlackチャンネルに投稿:「使えないファイナンシャルプランニングツールを作っている。重要なフィードバックが必要だ。」

反応はゼロ。

しかし、粘った。最終的に1人の友人と2人の創業者がテストに協力してくれた。彼らのフィードバックは厳しくも目から鱗だった。

Day 18-20:謙虚さを学ぶ真実

問題#1:私の計算は20%誤っていた

ある創業者の顧客獲得コストは、実際は$58.75のはずだったのに、表示は違った。誤差が大きすぎて、シリーズAのピッチを台無しにしかねない。原因は、曖昧な指示でMistralAIに「顧客獲得コストを計算して」と頼んだことだ。AIは方法論について勝手に仮定を立てた。時には「解約率」を月次と解釈し、他の時は年次と解釈した。整合性が崩壊していた。

問題#2:大きなモデルはエクスポート機能をクラッシュさせる

50行以上のデータはメモリオーバーフローを引き起こした。

問題#3:コア機能が埋もれている

創業者は最も必要としたランウェイ計算を見つけられなかった。3画面深くに埋もれていたため、必要な情報にたどり着くのに5ページも操作しなければならなかった。

$47 6時間のデバッグセッション

LTV/CACの計算は常に誤っていた。6時間の追跡調査で判明したのは、MistralAIが「月次解約率」を「年次解約率」と解釈していたケースと、その逆もあったことだ。「顧客生涯価値」を頼んだとき、隠された仮定をしていた。

悪いプロンプト: LTVを計算して

良いプロンプト:

原文表示
このページには第三者のコンテンツが含まれている場合があり、情報提供のみを目的としております(表明・保証をするものではありません)。Gateによる見解の支持や、金融・専門的な助言とみなされるべきものではありません。詳細については免責事項をご覧ください。
  • 報酬
  • コメント
  • リポスト
  • 共有
コメント
0/400
コメントなし
  • ピン