株式会社CAENのロゴ

嘘MBTI診断メーカーの失敗から学ぶAI駆動開発3つの注意点｜体験談

この記事で分かること

AI 駆動開発は 「早く作れる」が故に落とし穴も深い です。

  • (1) 品質担保を軽視しやすい
  • (2) API 課金の想定が甘くなりがち
  • (3) 拡散したときの負荷対策が後手に回る

この記事では 大森翔吾 が、自分がエイプリルフール企画で作って見事にスベった「嘘MBTI診断メーカー」の体験談をもとに、AI 駆動開発で個人開発者が踏みやすい3つの罠と、その回避策を正直に話します。

そもそも「嘘MBTI診断メーカー」とは何だったのか

嘘MBTI診断メーカー は、2025年4月1日のエイプリルフールに向けて僕が2日間で開発・公開した Web サービスです。

本家 MBTI 診断（ENTP、INTPなど4文字アルファベットで性格を分類する診断）を皮肉ったパロディで、「AEON タイプ（完全にうどん屋のチェーン）」みたいな大喜利的な嘘のMBTIタイプを作れるジェネレーターでした。

きっかけは成功体験です。2025年2月22日の猫の日に公開した「猫型MBTI診断」が4日間で1.5万人に使われ、「エイプリルフールもいける！」と完全に調子に乗ってしまった、という話です。

結果：3リツイート、900インプレッション

「ほぼ誰の目にも止まらなかった」というのが正確な表現です。シンプルに、スベりました。

ただ、このスベりのおかげで AI 駆動開発の弱点が言語化できたので、ここからが本題です。

AI 駆動開発は「作るスピード」が異常に速い

前提を共有します。僕は 株式会社CAEN という一人法人で、AI を使って Web サービスやモバイルアプリを個人開発しています。

AI 駆動開発（Claude Code、Cursor、Codex などの AI エージェントに実装を任せる開発スタイル）を始めてから、開発スピードは体感で3〜5倍になりました。ゼロからAI駆動開発を始める体験談 にも書いた通り、従来なら1週間かかる Web サービスが2日で動くのは現実です。

問題はここからです。速く作れるが故に、昔なら当たり前だった「前工程」を端折りやすくなります。僕が 嘘MBTI で踏んだ3つの罠は、全部この「速さ故の油断」から来ています。

注意点1：品質担保を軽視しやすい

AI に「プロトタイプ作って」とお願いすると、数分で動くものが出てきます。動いてしまうので、そのまま本番に出したくなるんですよね。

嘘MBTI の場合、僕はデザインだけは Web デザイナーの魂を込めて作り直した（黒ベース、真っ赤な嘘だから差し色は赤）のですが、エッジケースの検証が圧倒的に甘かったです。たとえば、

  • スマホの特定ブラウザで表示が崩れないか
  • 長すぎる入力を入れたときに画面が壊れないか
  • シェア画像の OGP が全 SNS で意図通りに出るか

こういうチェックを、「AI が作ったから大丈夫でしょ」で飛ばしました。結果、公開後に細かい破綻を後追いで直す時間が発生し、肝心の「公開当日のプロモ時間」を食われる、という二次被害を受けました。

回避策

  • プロトタイプ段階で、テストケースも AI に書かせる（1分で書いてくれます）
  • スペック駆動開発 の考え方で、仕様 → 実装 → 検証の順を崩さない
  • 「早く作れる」の分、検証に時間を使う余裕が生まれた と捉える

AI 駆動開発は「検証を飛ばしていい」という話では決してなくて、「検証に回せる時間が増える」という話です。ここを勘違いすると、僕みたいに公開直後にバタバタします。

注意点2：API 課金の想定が甘くなりがち

AI を活用したサービスを作ると、LLM の API コストが常に裏で走ります。

嘘MBTI も生成 AI の API を叩く箇所があり、僕の脳内では「まあ無料枠で十分でしょ、そんなに使われないし」で済ませていました。ところが、AI駆動開発でアイデアを形にする話でも触れた 通り、API 課金は「使われない想定」で引くと事故ります。

今回は大してバズらなかったので結果的に軽傷でしたが、一方で想定より大きな API コストが発生した局面はあります。仮に猫の日みたいに1.5万人規模でアクセスが来ていたら、単価 × リクエスト数で想像以上に膨らんだはずで、正直、冷や汗が出ました。

回避策

  • 公開前に「1,000リクエストあたり何円か」を概算する（ドキュメントに書いてある）
  • API キーには 使用量上限（hard limit）を必ずセット しておく
  • キャッシュできる結果はキャッシュする（特に定型プロンプト）
  • 初期はゲスト利用に制限をかける／1日の上限を設ける、などのガードを1個でも入れる

「バズったら嬉しい、でも API 請求で泣く」は避けたいので、上限セットは無料15分の作業 です。これだけは絶対やっておきましょう。

注意点3：拡散したときの負荷対策が後手に回る

3つ目が一番「AI 駆動開発あるある」だと思います。サーバーとインフラが最後に詰められる 問題です。

僕は Vercel にデプロイすることが多いのですが、個人開発の Hobby プラン（非商用利用限定、使用量上限あり）は、バズると帯域や関数実行回数の上限にぶつかる可能性があります。

嘘MBTI は結果的に誰にも届かなかったので無傷でしたが、仮に猫の日のように伸びていたら、

  • サーバーレス関数の同時実行上限
  • 画像生成 API のレート制限
  • CDN キャッシュのミスヒット

あたりでボロが出ていた可能性が高い です。AI に「負荷試験も書いて」と頼めば書いてくれるのに、「たぶん大丈夫でしょ」で素通りしていた。これは完全に油断でした。

回避策

  • 公開前に 1分間100アクセス程度の簡易負荷テスト を回す（Playwright でも可能）
  • 商用利用になる可能性があるなら、最初から Vercel Pro 以上を検討する
  • データベースアクセスが重い処理はキャッシュ層を挟む
  • エラーが出たときに 優雅にフォールバック する UI を用意する（「混雑中です、少し待って」程度でいい）

AI駆動開発のフロー全公開 でも書いた通り、公開前チェックリストを1枚持っておくと、この手の抜け漏れがだいぶ減ります。

失敗を「学び」に変換するのが一番コスパがいい

ここまで読んで気付いた方もいるかもしれませんが、この3つの罠は、どれも AI 駆動開発を始めた瞬間に踏みやすいもの です。

ただ、僕はこの失敗で AI 駆動開発を嫌いになったかと言うと、全くその逆 です。

  • 2日で Web サービスを公開できた（従来開発では無理）
  • スベっても「勉強代」として小さく済んだ
  • 次の企画ではすぐに反省を活かせる

失敗の単価が安い のが AI 駆動開発の最大の強みだと、今回の件で確信しました。元役者だった僕が AI 開発者になれた のも、この「小さく失敗して学ぶ」サイクルが回せるからです。

リリース直後の恥ずかしさ（これ滑ってる？感）は、正直めちゃくちゃあります。でも、出さない開発者より、出してスベる開発者の方が100倍成長します。これは舞台に立ってきた経験から断言できます。

結論：AI 駆動開発は「速さ × 検証」で真価を発揮する

最後にまとめます。AI 駆動開発の3つの注意点は、

  1. 品質担保を軽視しない（検証時間が増えたと捉える）
  2. API 課金の上限は必ず引く（無料15分の保険）
  3. 負荷対策を公開前に1回は回す（Playwright で十分）

どれも大した手間ではなくて、「速く作れたからこそ、これくらいは守ろう」 という話です。失敗してから学ぶのも悪くないですが、この記事を先に読んでくれた人は、ぜひ僕の勉強代を横取りしてやってください。

それでも間違いなく、AI 駆動開発は個人が勝負できる最強の武器 です。嘘MBTI はスベりましたが、次のエイプリルフールでリベンジする気は満々です。

関連する記事

AI駆動開発のご相談・お仕事のご依頼

株式会社CAEN（代表：大森翔吾）では、AI 駆動開発の導入支援、企画から公開までのワークフロー設計、API コスト設計や負荷対策のアドバイスを承ります。

「AI で Web サービスを2週間で立ち上げたい」「個人開発のプロダクトを商用レベルまで品質担保したい」など、お気軽にご相談ください。スベった経験込みでお手伝いします。