デモでも Todo アプリでもない、実際にユーザーが課金している AI 音楽生成プラットフォームの開発記録です。
はじめに
2025年末、AI 音楽生成プラットフォーム Music0 AI を作ることにしました。
「作ることにした」と言うと少し格好つけていますが、正直なところ 「アイデアを検証したいけど、3ヶ月もコードを書きたくない」 というのが本音でした。
ちょうどその頃、Codex が急速に進化していました。「コード補完ツール」ではなく、本当の意味で「ペアプログラミングの相棒」として使えるのだろうか？ そんな疑問が出発点です。
結果として、init から本番リリースまで、65コミット、約400のTS/TSXファイル、58,000行超のコード。フロントエンド・バックエンド・決済・多言語・SEO・管理画面まで、すべてカバーしています。 私がやったことの大半は、「Codex に何が欲しいかを伝える」ことと「Codex が書いたコードをレビューする」ことでした。
この記事は AI の宣伝ではないですし、「エンジニアが不要になる」と言いたいわけでもありません。プロダクションレベルのプロジェクトにおいて、Codex で何がどこまでできて、何ができなかったのか を率直に共有したいと思います。
1. プロジェクト紹介：Music0 AI とは
Music0 AI は、テキスト入力から音楽を生成できる AI プラットフォームです。
- 🎵 AI 音楽生成 — スタイルと歌詞を入力して、完成度の高い楽曲を生成
- 🎤 AI ラップ — Rap / Hip-Hop に特化したジェネレーター
- 🎧 AI Lo-fi — Lo-fi / Chill 系の楽曲を生成
- 🎬 AI ミュージックビデオ — 生成した音楽に映像を自動的に付与
技術スタック
| レイヤー | 技術選定 |
|---|---|
| フレームワーク | Next.js 16 (App Router) + React 19 |
| 言語 | TypeScript（strict モード） |
| スタイリング | Tailwind CSS 4 + shadcn/ui + Radix |
| データベース | Drizzle ORM + PostgreSQL |
| 認証 | better-auth + RBAC |
| AI プロバイダー | 複数のAI音楽API（ホットスワップ対応） |
| 決済 | Stripe / PayPal / Creem（3チャネル） |
| ストレージ | Cloudflare R2（S3互換） |
| 国際化 | next-intl（中/英/日/韓/西/仏の6言語） |
| ドキュメント | Fumadocs MDX |
| デプロイ | Vercel / Cloudflare Workers |
単なるデモではありません。以下の機能を備えています：
- 完全なユーザー認証・権限管理システム（RBAC）
- クレジット制 + サブスクリプション + 単発購入
- 管理画面（ユーザー管理、注文管理、AIタスク管理など）
- SEO 最適化（sitemap、robots、OG Image、多言語 SEO ページ）
- ブログシステム・ドキュメントシステム
2. ゼロから1までのリアルなタイムライン
Git ログをそのまま振り返ってみます。
2025-12-15 init → プロジェクト初期化
2025-12-15 update index → トップページ構築
2025-12-16 update studio → スタジオページ
2025-12-17 implement function → コア機能実装
2025-12-17 update cicd → デプロイパイプライン
...
2026-06-30 feat(i18n): add French locale → 6番目の言語追加
2026-07-01 feat: add localized song SEO pages → SEO 最適化
1日目（12/15）： テンプレートから初期化、トップページと基本ルーティングを構築。
2日目（12/16）： スタジオのコアページが形になる。
3日目（12/17）： AI 音楽生成のコア機能が動作 + CI/CD デプロイ完了。
そうです、3日で MVP が動きました。
その後は継続的な改善です。ラップアシスタント、ミュージックビデオ生成、クレジットシステム、料金調整、ゲスト制限、多言語対応、共有機能、再生可能な作品ライブラリ……。すべての機能追加が「Codex に伝える → レビュー → 調整 → マージ」というサイクルの繰り返しでした。
3. ワークフロー：Codex とどうペアプロしたか
3.1 「AI にコードを書かせる」のではなく「AI と協働する」
これが最も重要な意識の転換でした。
多くの方が AI Coding と聞くと「コード補完」や「プロンプトを投げてコードを生成する」ことをイメージすると思います。しかしプロダクションレベルのプロジェクトでは、「AI がコードを書けるかどうか」ではなく、「自分が何を作りたいかを明確に伝えられるか」 が鍵になります。
私のワークフローは次の通りです：
┌──────────────────────────────────────────────────────┐
│ 自分（プロダクト設計 + アーキテクチャ + レビュー） │
│ │
│ 1. 要件定義（自然言語で機能を記述） │
│ 2. コンテキスト提供（関連コードや参考デザインを指示） │
│ 3. コードレビュー（重要なロジックを一行ずつ確認） │
│ 4. イテレーション（問題点を指摘し、修正を依頼） │
│ 5. テスト・検証（pnpm build + 手動テスト） │
└──────────────────────────────────────────────────────┘
↕
┌──────────────────────────────────────────────────────┐
│ Codex（コーディング + 実装 + リファクタリング） │
│ │
│ 1. 要件を理解し、不明点を質問 │
│ 2. 既存のコード構造と規約を分析 │
│ 3. 完全な実装コードを生成 │
│ 4. フィードバックに基づいて修正 │
│ 5. 面倒な繰り返し作業を処理 │
└──────────────────────────────────────────────────────┘
3.2 良質な「コンテキスト」を渡すことがすべて
Music0 のプロジェクトでは、AGENTS.md というファイルを常にメンテナンスしています。これはプロジェクト全体の「開発者ガイド」のようなもので、Codex が起動するたびに読み込まれます。中身は以下の通りです：
- 技術スタックとフレームワークの規約
- コーディングスタイルガイド
- ファイル構成の説明
- ビルド・デプロイコマンド
- よくあるハマりどころと注意点
最大の学びはこれです：Codex に渡すコンテキストの質が、そのまま生成されるコードの質に直結します。 AGENTS.md は一度書いて終わりではなく、プロジェクトの進行に合わせて継続的に更新しています。
例えば、私の AGENTS.md にはこんなルールがあります：
js/ts/tsx/mjs ファイルを変更した場合、作業完了前に必ず
pnpm buildを実行してコンパイルが通ることを確認すること。
このルールのおかげで、Codex は毎回自分でビルド検証を行ってくれます。コンパイルが通らないコードを渡されることがなくなりました。
3.3 実例：新しい AI プロバイダーの追加
新しい AI 音楽 API プロバイダーの接続を例に挙げます。Codex に渡すプロンプトはこんな感じです：
新しい AI 音楽生成プロバイダーを追加したい。
src/extensions/ai/ にある既存の provider の実装パターンを参考にしてください。
必要なこと：
1. 新しい provider ファイルを作成し、他の provider と同じインターフェースを実装
2. index.ts に新しい provider を登録
3. API キーは config テーブルから読み込む
Codex は次のように動きます：
- 既存の provider のコードを読み、インターフェースパターンを理解
- 同じ interface に沿って新しい provider ファイルを作成
-
index.tsに登録 -
pnpm buildを実行してコンパイル確認
私がやるのは 生成されたコードのレビュー だけ。API の呼び出し方法、エラーハンドリング、レスポンスフォーマットが正しいかを確認します。所要時間は約10分。自分でゼロから書いたら1〜2時間はかかるでしょう。
3.4 実例：多言語対応
Music0 は6言語（中/英/日/韓/西/仏）に対応しています。この種の作業こそ、AI の効率化効果が最も顕著に現れるところです。
やり方はシンプルです：
- まず中国語と英語でコア文言を完成させる
- Codex に「en と zh の locale ファイルを参考に、すべてのキーを日本語/韓国語/スペイン語/フランス語に翻訳して」と伝える
- Codex は翻訳だけでなく、JSON 構造の一貫性や複数形の処理まで対応してくれる
一人で6言語の SaaS プロダクトを運用する——以前なら考えられないことです。
4. Codex が本当に得意なこと
✅ 1. パターンに沿ったコード生成
プロジェクトに明確なコーディング規約（convention）がある場合、「N番目の同じようなもの」を作るのが非常に速いです。例えば：
- 2つ目・3つ目の AI プロバイダーの追加
- 既存のユーザー管理ページを参考にした新しい管理画面
- 既存の CRUD パターンに沿った新しい API エンドポイント
✅ 2. 地味だけど必要な繰り返し作業
- 多言語翻訳
- SEO 関連の metadata・sitemap 生成
- フォームバリデーション（zod スキーマ）
- 型定義
✅ 3. リファクタリング
「このコンポーネントを小さなサブコンポーネントに分割して」「このファイルが長すぎるからリファクタリングして」といった指示には、非常にうまく対応します。リファクタリングのルールは通常明確だからです。
✅ 4. ドキュメント・コメントの記述
AI が書くコメントやドキュメントは、人間が書くものより丁寧なことが多いです（人間はたいてい面倒がって書かないので）。
✅ 5. デバッグ・問題の切り分け
エラーメッセージを渡すだけで、素早く原因を特定してくれます。特に TypeScript の型エラーに関しては、AI の対応速度は人間を大きく上回ります。
5. Codex にできなかったこと（踏んだ地雷）
❌ 1. プロダクトの意思決定
「ゲストユーザーに利用制限を設けるべきか？」「クレジットの価格設定は？」「ラップと Lo-fi を別ページにすべきか？」
こうした判断は AI には代替できません。どんな方針でも実装はしてくれますが、どの方針がユーザーにとって最適かは分かりません。
❌ 2. 複雑なアーキテクチャ設計
Music0 では、複数の AI プロバイダーのホットスワップ機構、複数決済チャネルの統一抽象化、クレジットとサブスクリプションの混合課金モデルなど、アーキテクチャレベルの設計が必要でした。Codex は設計済みのアーキテクチャを実装するのは得意ですが、ゼロから良いアーキテクチャを設計するのは苦手です。
❌ 3. UI/UX の微妙なニュアンス
機能的に完全なページは生成できますが、「このボタンの配置でユーザーは迷わないか？」「アニメーションの duration は 200ms か 300ms か？」「この色の組み合わせは心地よいか？」——こうした判断には人間の感性が必要です。
❌ 4. サードパーティ API の細かい仕様
Codex が持っている API の知識は最新とは限りません。決済サービスや AI プロバイダーを接続する際は、自分で公式ドキュメントを読み、正しい API フォーマットを Codex に伝える必要があります。Codex の「記憶」に頼り切るのは危険です。
❌ 5. パフォーマンス最適化の勘所
「このページの初回表示が遅いのはなぜ？」「このクエリにインデックスは必要か？」——一般的なアドバイスは出せますが、実際のランタイムデータを見ていない以上、的確な判断はできません。
6. Codex でプロダクト開発をしたい方へのアドバイス
1. テンプレートから始める
Music0 は ShipAny テンプレートをベースにスタートしました。Codex の最大の強みは「ゼロから創造する」ことではなく、「既存の基盤を高速に拡張する」 ことにあります。良いテンプレート + Codex = 圧倒的な開発速度です。
2. コンテキストドキュメントを整備する
AGENTS.md（あるいは .cursorrules、CLAUDE.md など）は、あなたと Codex の「コミュニケーションプロトコル」です。その品質がそのまま出力の品質に直結します。以下を含めることをお勧めします：
- 技術スタックの説明
- コーディング規約
- ファイル構成の説明
- ビルド・テストコマンド
- よくあるエラーと解決策
3. 良いプロンプトの書き方を身につける
Codex とペアプログラミングする際、最も効果的なプロンプトのパターンはこうです：
[何をしたいか] を実装したい。
[どの既存コード] のパターンを参考にしてください。
具体的に必要なこと：
1. [具体的なステップ1]
2. [具体的なステップ2]
注意：[特殊な制約や注意事項]
具体的でコンテキストが豊富なプロンプトほど、生成されるコードの品質は高くなります。
4. 重要なコードは必ずレビューする
AI が生成したコードを無条件に受け入れてはいけません。 特に以下は要注意です：
- セキュリティ関連のコード（認証、権限、決済）
- データベース操作（データの安全性）
- サードパーティ API 呼び出し（フォーマットの正確性）
Music0 では、決済関連のコードはすべて一行ずつ手動でレビューしました。
5. AI には「やりたくない仕事」を任せる
「面倒だけど必要」な作業こそ AI の出番です：
- 多言語翻訳
- テストケースの作成
- SEO 最適化
- 繰り返しの CRUD コード
- コードフォーマットやリファクタリング
節約した時間は、プロダクト設計、アーキテクチャ、ユーザー体験の改善に投資しましょう。
7. 数字で振り返る
| 指標 | データ |
|---|---|
| プロジェクト開始日 | 2025-12-15 |
| 総コミット数 | 65 |
| TS/TSX ファイル数 | 約400 |
| コード行数 | 約58,000行 |
| 対応言語数 | 6（中/英/日/韓/西/仏） |
| AI プロバイダー | 複数（ホットスワップ対応） |
| 決済チャネル | 3 |
| ルーティングページ | 20以上 |
| 再利用可能 Block コンポーネント | 12種 |
| Extension モジュール | 8 |
8. まとめ
Codex は「コードを書かなくてよくなるツール」ではなく、本当に重要なことに集中するためのツール です。
Music0 の開発を通じて、私の役割はテックリードに近いものでした：
- プロダクトの意思決定
- システムアーキテクチャの設計
- 要件を Codex が理解できるタスクに分解
- すべてのアウトプットのレビュー
- Codex では対処しきれないエッジケースの処理
Codex は最高の「ジュニアエンジニア」です。実行力があり、疲れず、文句も言わず、安定したアウトプットを出してくれます。ただし、何を作るべきかを知っている人間の導き が不可欠です。
本当の生産性向上とは、「AI がどれだけコードを書けるか」ではなく、「アイデアをどれだけ速くプロダクトに変換できるか」 にあります。
もし AI を使ったプロダクト開発に興味があるなら、今すぐ始めてみてください。 ツールが完璧になるのを待つ必要はありません。実際のプロジェクトで試行錯誤することが、最良の学習方法です。
技術的な詳細に興味がある方は、ぜひコメントでお気軽にどうぞ。