Claude Codeは、YouTubeのようなアプリの計画を、動画のアップロード、再生、視聴者の反応機能、クリエイター向けツールを備えた動くプロトタイプに仕上げる手助けをしました。役に立つ教訓は、1つのプロンプトで完成品ができたということではありません。開発は要件定義、サービス連携、デザインの決定、実装、そして確認という段階を経て進み、確認の段階では開発者自身が判断すべき問題が見つかりました。
コードを生成する前に範囲を決める
プロジェクトは技術スタックを決めるところから始まりました。ウェブアプリにはNext.js App Router、スタイルにはTailwind CSS、アカウントとアプリのデータにはSupabase、メディアの処理にはImageKitを使います。Claude CodeのPlan Modeで示した最初の要件には、公開の視聴ページ、認証付きのクリエイター画面、アップロードの流れ、分析機能が含まれていました。確認のための質問をするよう求めたことで、エージェントはファイルを変更する前に曖昧な点を解消できました。
最初のMVP（必要最小限の機能を備えた製品）の計画では、除外する機能も明記しました。コメント、高評価、検索、登録者に関する処理です。Claude Codeは、データベース構造、ルート、APIエンドポイント、SupabaseのRow-Level Securityポリシー、ImageKitプレーヤーの統合を網羅した8つのマイルストーンの計画をPLAN.mdにまとめました。Row-Level Security（RLS）は、ユーザーがどのレコードにアクセスできるかを定めるデータベースのルールです。
この計画は精査すべき出発点であり、すべての判断が正しいと見なす許可ではありません。後の開発では、高評価、コメント、検索、登録者に関するダッシュボードの数値も加わりました。こうした追加は、要望が変われば開発者が合意した範囲を見直す必要があることを示しています。実装された機能が、当初のMVPの一部とは限りません。
▲ アプリ構造の計画
エージェントに必要なツールとデザインのルールを渡す
Claude Codeは、専用のフロントエンド向けスキルを使ってインターフェースを作りました。また、AIエージェントが外部サービスのツールを使うための仕組みであるModel Context Protocol（MCP）を通じてSupabaseに接続しました。この接続により、エージェントはデータベースの構造を確認し、マイグレーションを扱えるようになりました。ImageKitのプラグインがメディア機能の手引きを提供し、ImageKitプレーヤーの詳細なドキュメントをプロジェクトのコンテキストに加えたうえで計画を更新しました。
計画が固まると、Claude CodeはTypeScriptとTailwind CSSを使ってNext.jsアプリのひな形を作りました。独自のメディア処理の仕組みを作る代わりに、アップロードした動画の保存と再生の基盤はImageKitが担いました。それでも接続を確認するには、サービスの認証情報とローカルでのテストが必要でした。今回の開発では認証情報をClaude Codeに貼り付けましたが、この手軽さは本番用リポジトリの標準的なやり方としては適切ではありません。機密性の高い値は、AIとのチャット履歴に残さず環境設定ファイルに入れるべきです。
インターフェースにも独自の確認段階がありました。アプリ全体にテーマを適用する前に、Claude Codeは文字、色、カード、ボタン、操作部品をまとめたスタイルガイドのページを/designに作りました。確認したデザインは、暗い背景に控えめなアンバー色のアクセントを使ったものです。このプレビューを経てから、デザインのルールを主要なページに反映しました。これにより、見た目の仕組みが機能するかという問題を、すべてのルートをつなぐという大きな作業から切り離せました。
機能をつなぎ、その動作を試す
完成したアプリは、視聴者向けの再生ページとクリエイター画面を1つにまとめたものです。アップロードしたメディアはImageKitのメディアライブラリに表示され、動画は埋め込みプレーヤーで再生されました。再生ページでは高評価、低評価、コメントの投稿が機能しました。検索は該当する動画を返し、視聴履歴には視聴したコンテンツが記録されました。
アップロードの流れには、サムネイルの選び方が2つ加わりました。動画をスクラブして特定のフレームを選ぶ方法と、別の画像をアップロードする方法です。フレーム選択のテストには78.6MBの道路の動画を使いました。字幕の操作とImageKitによる自動字幕も確認しましたが、文字起こしは初回アップロードの直後にすぐ表示されるわけではなく、数分かかりました。
▲ メディア機能と動作確認
こうした確認によって、すべての画面や数値が同じ程度に裏付けられたわけではありません。今回の開発で何が確かめられたかを評価するうえでは、次の区別が重要です。
| 領域 | 開発で確かめられたこと | なお開発者の判断が必要なこと |
|---|---|---|
| アカウント | 登録時にメール確認のメッセージが表示されたが、Supabaseのメール確認設定を変え、プロフィールの不具合を直すまでサインインに失敗した | その認証方針が想定するアプリに適切か |
| 再生とアップロード | サンプルの素材がアップロード・再生でき、サムネイルも選べた | 縦長動画のサイズを含むレイアウトの問題が解決したか |
| 反応機能 | 高評価、低評価、コメント、検索、視聴履歴を試した | それらの追加が合意した製品範囲に含まれるか |
| クリエイター分析 | ダッシュボードに28日間で1.2Kの再生回数と動画ごとの数値が表示された | 数値は検証された利用実績ではなく、プラットフォームの模擬データによるもの |
再生回数がすぐに更新されないことも、目に見える問題でした。クリエイター向けダッシュボードはレイアウトと画面遷移のテストには役立ちましたが、合成したチャンネルや指標を実際の利用の証拠として読むべきではありません。メンバー限定のアクセスなど、計画にあった一部の機能は、実施した確認では裏付けられていません。
人による確認の流れを作業に組み込む
同じようなアプリを作るなら、まず対象ユーザー、必要な機能、除外する機能、技術スタック、完成の基準を決めます。広い範囲の実装に進む前に、生成された計画を確認します。そのうえで、サービスへのアクセス、認証、デザイン、アップロード、再生、各ダッシュボードの裏にあるデータという段階ごとにアプリを確認します。うまくいかないときは、今回のサインイン失敗のように、期待した動作と実際の結果をClaude Codeに伝えます。
エージェントは部品を素早くつなぎ、修正できます。それでも、範囲、アクセスのルール、修正内容、表示された指標がアプリに合っているかを決めるのは開発者です。