👋

16時間でアプリの企画・開発・リリースした話

に公開
zennfes2025ai
idea

対象者

  • AIを活用し、開発のコストを減らしたいと考えている事業者

はじめに

開発案件をやっていて、たまには違う技術を使ってみたいと思うことはありませんか？（私はあります）今回は、個人開発でどこまで早くアプリを企画・開発・リリースできるかを挑戦したので共有します。

なお、この記事もAIにリポジトリの中身を解析して書いてもらっています。(最低限の校正はしています)

プロダクト概要

Wikipedia Golfとは

Wikipediaの記事リンクを辿って、スタート記事からゴール記事まで最短で到達することを競うWebゲームです。


※この画像もChatGPT-5に作ってもらいました。

開発スペック

  • 開発時間: 16時間（企画2h + 実装12h + デプロイ・調整2h）

  • 技術スタック: Next.js 15, React 19, Prisma, Supabase, Vercel

  • 主要機能:

    • デイリーチャレンジ
    • ランダム生成モード
    • カスタムモード（任意の記事でプレイ）
    • リーダーボード
    • 多言語対応（日本語、英語、中国語）
    • PWA対応
    • 記事内検索（Ctrl+F）
    • Google AdSense統合

  • 利用したAIツール:

    • ChatGPT-5（企画立案）
    • Google Stitch（UIプロトタイプ生成）
    • GitHub Copilot（コーディング支援）

成果

  • ✅ 即日リリース
  • ✅ SEO完全対応（構造化データ、sitemap）
  • ✅ モバイル対応・レスポンシブデザイン

第1章: 企画プロセス

ChatGPT-5による企画立案

従来の企画立案では、ブレインストーミングや市場調査に膨大な時間がかかりました。今回は自身の経験と課題感をChatGPT-5に入力し、以下を出力してもらいました:

  • ゲームコンセプト
  • ターゲットユーザー
  • マネタイズ戦略（広告、課金要素）
  • 技術的実現可能性

ポイント: 人間は「何を作るか」ではなく「何が売れるか」の判断に集中する。AIに任せられる部分は任せる。

Google Stitchでプロトタイプ生成

ChatGPTの企画を Google Stitch に流し込み、UIプロトタイプを数分で生成しました。

Input: ChatGPTが生成した企画書
Output: インタラクティブなUIプロトタイプ

※Wiki Golfが作りたいと書いただけでトップページや実際のプレイングのイメージなどをAIで作成してもらいました。

このプロトタイプをベースに実装を開始することで、デザイン工数をほぼゼロにできました。また、実際にデザインが出来上がると、この機能も必要そうだな...と、追加の機能なども考えられるようになりました。

なぜ高速企画が重要だと思ったか

これからのビジネスは、AIを活用することでより高速にPDCAを回せるかが重要になるかと思いました。私の経験則にはなりますが、単なるプログラマーとして、フロントエンドができる、バックエンドができる...ではなく、それらの要素技術を組み合わせ、マーケティングやセールスも含めた「開発力」が重要になると考えています。

※ 登大遊さんの「秘密のNTT電話局、フレッツ光、およびインターネット入門」の「第1節 システム領域 (コンピュータシステム、インターネットシステム、通信システム) を深く理解することの重要性」の内容に大きく影響を受けているところではあります。

もちろん大規模なシステム開発になると、利害関係の調整などの要素も絡んできますが、それでも世の中の方向性としては、より早くPDCAを回し、市場検証を繰り返し、成功確率を上げることが重要になると思います。

私自身、普段は開発者としてきちんとした設計になっているか、保守性が高いか、テストが十分かなどを意識していますが、今回はあえて売上にならないコードは不要と割り切り、高速PDCAを最優先にしました。

第2章: 技術選定の思想 - 長期的視野とPoC最適化の両立

技術選定について

個人的に技術選定で最も重要なのは、「将来のビジネスに対して保守性・拡張性があるか」だと思います。

❌ 避けるべき短絡的判断

「NoSQLは簡単だから使おう」
→ 業務要件が膨れ上がると検索要件が増加
→ RDBMSを使えばよかった...（手遅れ）

✅ あるべき思考プロセス

1. 長期的な要件を予測
   - データ構造は複雑化するか？
   - リレーションは増えるか？
   - トランザクション処理は必要か？

2. PoCと本番の両方を見据える
   - PoC: 高速開発できるか？
   - 本番: スケールするか？コスト最適化できるか？

3. 移行可能性を担保
   - ベンダーロックインを避ける
   - 標準技術・OSS優先

Wikipedia Golfの技術選定

技術 選定理由 長期的視野
Next.js 15 + React 19 SSR/SSG、SEO対応、最新パフォーマンス 安定版への移行も容易、コミュニティ巨大
PostgreSQL (Supabase) RDBMS、複雑なクエリ対応、トランザクション 自前PostgreSQLへ移行可能（標準SQL）
Prisma スキーマ駆動、型安全、マイグレーション自動化 どのPostgreSQLでも動作、本番でもそのまま使える ✅
Tailwind CSS 4 高速スタイリング、保守性高い 本番でもそのまま使える ✅
Vercel デプロイ1分、CDN自動、スケーリング自動 AWS/GCP/自前サーバーへ移行可能（Next.js標準）

アーキテクチャ全体像

       [ ユーザーのブラウザ ]
                │
                ▼
┌──────────────────────────────────────────────┐
│               Vercel Edge / CDN              │
│  - 静的アセット配信(Next.js build産物)       　　│
│  - Edge Middleware(レート制限/認可/AB等)        │
└───────────────┬──────────────────────────────┘
                │
     ┌──────────┴──────────┐
     ▼                     ▼
┌──────────────────┐  ┌────────────────────────────┐
│  Frontend (UI)   │  │   Backend (Server/API)     │
│  Next.js 15      │  │   Next.js 15 on Vercel     │
│  App Router      │  │   - Route Handlers(/app/… )│
│  React 19        │  │   - Server Actions         │
│  - Server/Client │  │   - Edge Functions         │
│    Components    │  │   - Node/Serverless Fn     │
│  - fetch('/api') │  │   - Middleware(率制限等)   　│
└──────────────────┘  └────────────────────────────┘
                                 │
                                 │
                                 │
                                 │
                           ┌─────┴────────────────────────┐
                           │        外部サービス/DB         │
                           │                              │
               ┌───────────▼───────────┐      ┌───────────▼───────────┐
               │  Wikipedia API   　 　 │      │  Supabase(PostgreSQL) │
               │  - Edgeから直接fetch  　│      │  - Prisma経由        　│
               │  - キャッシュ/再検証     │      │  - 接続プール/Row-Level │
               │  - レート制限考慮      　│      │    Security(必要なら) 　│
               └───────────────────────┘      └───────────────────────┘

設計の肝: 「移行可能性」の担保

❌ ベンダーロックインの例（Supabase直結）

// Supabaseに直結（移行困難）
import { createClient } from '@supabase/supabase-js'
const supabase = createClient(url, key)

// Supabase固有のクエリ
const { data } = await supabase.from('challenges').select('*').eq('type', 'daily')

問題点:

  • Supabase以外のDBに移行できない
  • Supabase固有のAPIに依存
  • コスト削減やオンプレ移行が不可能

✅ Prismaで抽象化（どこでも動く）

// Prismaで抽象化
import { prisma } from '@/lib/prisma'

// 標準的なクエリ（どのPostgreSQLでも動く）
const challenges = await prisma.challenge.findMany({
  where: { type: 'daily' },
})

メリット:

  • PostgreSQL標準SQLに変換される
  • Supabase → AWS RDS → GCP Cloud SQL → 自前DB、どこでも動く
  • コード変更なしで移行可能

PoCフェーズでのSupabase活用

PoCではSupabaseの以下の機能で高速開発:

  • Database: PostgreSQL（5分でセットアップ）

重要なのは、Prisma経由でアクセスすることで移行可能性を担保していること。

第4章: 得られた学び


**Wikipedia Golfの例**:

- PostgreSQL (Supabase) → 複雑なクエリ・トランザクション対応
- Prisma → ベンダーロックイン回避、どこでも動く
- Next.js → Vercel → AWS/GCP/自前サーバー、どこでも動く

### 2. 売上にならないコードは書かない

❌ 過剰な最適化:

  • マイクロサービス化
  • 完璧なテストカバレッジ
  • 複雑な抽象化

→ 儲からなければ全て無駄

✅ 最小限の実装で市場テスト:

  • モノリスで十分
  • E2Eテストは主要フローのみ
  • 抽象化は2回目のリファクタリングで

まとめ

16時間開発の本質

16時間開発の本質は「速さ」ではなく**「試行回数の最大化」**です。

完璧な1つ < 不完全な10個

AI×人間の分業で企画を量産し、長期的視野を持った技術で高速実装、市場の反応を見て育てる。

これからの開発者

開発者の役割は変わりつつあります:

従来: 「作る人」
→ 要件を受け取り、実装する

これから: 「企画を検証し、儲かるものを選ぶ人」
→ AIと協働して企画を量産
→ 長期的視野で技術選定
→ 市場検証を高速で回す
→ 儲かるものだけに集中投資

Wikipedia Golfの今後

  • ✅ PoC完了、市場反応を測定中
  • 🔄 ユーザー増加に応じてAWS移行検討
  • 🔄 A/Bテストでマネタイズ最適化
  • 🔄 ユーザーフィードバックで機能追加

あなたも16時間で何か作ってみませんか？

この記事が、高速PDCAサイクルを回したい事業者の参考になれば幸いです。

質問やフィードバックがあれば、コメントください!

Discussion