【Claude 3.5 sonnet】忙しい人のための2時間WEBアプリ制作
はじめに
チーム内での技術勉強会の発表があるのですが、準備に使える時間が2時間しかありません！
ということで、最近話題のclaude 3.5 sonnetを使って、爆速で一つWEBアプリを作ることにしました。
ルール
- claude 3.5 sonnetの出力したコードのみを使い、自分では全くコードを書かない
- 2時間以内で最低限のデモが動くことを目指して実装する
作るもの
結婚式に呼ぶ友人の組み合わせを考えてくれるシミュレーターを作ります。
小中高大、趣味、職場など、これまでお世話になったたくさんの人のうちどの人を呼ぼうかと迷ってしまいますよね。
しかしながら、実際の式に呼べる人数には限りがあります。
- 「A君を呼ぶなら、同じ部活だったB君、C君、D君を呼んだ方がいい。でも4人同時に呼ぶと枠がキツいな、、、」
- 「X君は過去に結婚式に招待してもらったから必ず呼ぶ」
といった複数の制約の中で理想的な組み合わせ案を考える必要があります。
ゼロから考えるよりも、いろんな条件の元でシミュレーションができれば役立ちそうです。
なお、今回の作成の範囲外ですが、以下のような友人関係管理アプリと同様のDBを持ち、登録情報に基づいてシミュレーションしてくれる状態が望ましいと考えています。
今回作ったもの
- ゲストの情報を入力します
- 制約を入力します
- 実行すると行うと今回の条件で組み合わせのシミュレーションを行ってくれます。
要件定義
まずは計画を立てます。事前に私の中である程度完成系のイメージがついていたので、特徴を列挙しました。
もし致命的なところが抜けていれば補足してもらうために、まずは「他に検討すべき事項」を質問します。
結婚式に呼ぶ人をChatGPTを使ってシミュレーションするWEBアプリを作りたいです。
以下の他に検討すべき事項を書き出してください。
まだコードは絶対に書かないでください。
【UI】
・DBに友人データを保存していく
・シミュレーションにあたって必要だが抜けている情報を質問してくるので、チャットで返信する
・シミュレーション結果を踏まえてLLMで返答を返すと別の組み合わせを提案してくる
【シミュレーションの制約】
・上限人数の制約がある
仲の良さ、過去に結婚式に呼んでもらったかどうか、社会常識的に呼ぶべき人、など
・組み合わせの制約
例えば、
「この人を呼ぶなら、同じ部活の友人を全員呼ばないといけない」といった制約が発生する。」
「AさんとBさんは仲が悪いので、呼ぶならどちらかだけ」
以下の追加の検討事項を挙げさせていただきます
- データ管理（友人データの構造、更新・削除機能）
- UI（モバイル対応、視覚的な関係性マップ）
- シミュレーション機能の拡張（予算制約、出席確率予測）
- AI/LLMの活用（パーソナライズされた提案、席次表最適化）
- 結果の出力と共有
- 法的・倫理的考慮
- カスタマイズ機能
- フィードバックと改善機能
- 多言語対応
- スケーリング
- ヘルプとサポート
いくつか提案してくれました。
友人データの更新削除機能は必須ですね。
法的・倫理的考慮や多言語対応は2時間しかない中で必須の内容ではありません。
2時間で実装すべきタスクを抽出
そこで2時間までしかないことを伝えて、タスクの優先順位付けと実装の計画を立ててもらいます。
私にはデモアプリ完成まで2時間しかありません。
最低限の機能を実装するには、時間内で何をすべきかに絞って考えてください。
理解しました。2時間という厳しい時間制限の中で、最低限の機能を持つデモアプリを作成するための計画を立てましょう。以下に、優先順位の高いタスクと概算時間を示します：
1. 基本的なUI設計と実装 (30分)
- シンプルな一画面のレイアウト
- 友人データ入力フォーム
- チャットインターフェース（シンプルなテキストエリア）
- 結果表示エリア
2. データ管理 (20分)
- ブラウザのローカルストレージを使用して友人データを保存
- 基本的なCRUD操作（追加・表示）のみ実装
3. シミュレーションロジック (40分)
- 上限人数の制約を考慮した簡単な選択アルゴリズム
- 「仲の良さ」のみを考慮した優先度付け
4. ChatGPT APIとの連携 (20分)
- 基本的なプロンプト設計
- API呼び出しの実装
5. 結果表示 (10分)
- シンプルなリスト形式で選択された友人を表示
6. テストとデバッグ (15分)
- 基本機能の動作確認
- 簡単なエラー処理
7. デプロイ準備 (15分)
- ローカル環境でのホスティング設定
- 必要に応じて簡単なREADMEファイルの作成
これらのタスクに集中することで、2時間以内に最低限の機能を持つデモアプリを作成できる可能性が高まります。以下の点に注意してください：
- 複雑な機能や高度なUI設計は避け、基本的な機能に集中します。
- エラー処理やセキュリティ面は最小限に抑えます（ただし、本番環境では必ず対応が必要です）。
- ChatGPT APIの利用は最小限に抑え、主要な機能のデモンストレーションに焦点を当てます。
この計画を基に、すぐに開発を始めることをお勧めします。開発中に問題が発生した場合は、優先度の低い機能を省略し、核となる機能の完成に注力してください。
よく見ると計画上の合計時間が150分なので2時間をオーバーしているのですが、そこまで大きな誤差ではないのでスルーして次に進みます。
技術スタックの選定
私がよく使う技術スタックを使って作成させます。
シミュレーションを行わせるLLMには、勝手がわかっているChatGPTを利用しました。
ちなみに、Claudeでちょっとしたコードを作成させたいときはTailwind CSSとshadcn/uiを必ず活用するように伝えると通常よりもオシャレなデザインで作ってくれます。
あなたの計画に従って実装を進めます。
まずは技術選定をします。
必ず使用する技術スタックは以下です。
不足しているものはあなたが考えて提案してください。
・Next.js
・Tailwind CSS
・shadcn/ui
・ChatGPTのAPI
技術スタック（追加提案を含む）:
1. フロントエンド
- Next.js（指定済み）
- Tailwind CSS（指定済み）
- shadcn/ui（指定済み）
- React Hook Form（フォーム管理の簡素化のため）
2. バックエンド
- Next.js API Routes（サーバーサイド機能として）
3. データ管理
- ブラウザの localStorage（簡易的なデータ保存用）
4. 外部API
- ChatGPT API（指定済み）
5. 状態管理
- React の useState と useContext（シンプルな状態管理用）
6. 開発環境
- Node.js
- npm または yarn（パッケージマネージャー）
- VSCode（推奨エディタ）
7. デプロイ
- Vercel（Next.js のデプロイに最適、必要に応じて）
8. タイプチェック
- TypeScript（型安全性確保のため、時間があれば）
バックエンドの部分でpage routerのAPI Routeを使おうとしていたので、修正させました。
LLMは学習元のデータにpage routerの内容が多いらしく、気を抜くとすぐにpage routerで書こうとしてきます。
Next.jsはpage routerではなく必ずapp routerを使ってください。
承知しました。Next.jsのApp Routerを使用することを確認しました。では、App Routerを前提とした実装手順を提案します。
〜〜〜以下省略〜〜〜
実装計画の策定
上で提案された計画を見ると、LLMではなくルールベースで処理しようとしていたので、修正させます。
シミュレーションロジックの実装 (30分)について、シミュレーションはChatGPTにやってもらうので、実際にtsファイル上にロジックを書くのではなく、シミュレーション用のプロンプトを実行できるようにすることを覚えておいてください。
ごちゃごちゃしてしまったので、再度計画を清書させます。
ここまでの実装計画を頭から再度出力してください。
その上で、この段階でさらに詳細に決めておくべきことがあれば提案してください。
実装計画:
1. プロジェクトのセットアップ (10分)
- Next.js プロジェクトの作成 (App Router, TypeScript, Tailwind CSS)
2. 必要なパッケージのインストール (5分)
- react-hook-form, @hookform/resolvers, axios のインストール
3. shadcn/ui のセットアップ (10分)
- 初期化と必要なコンポーネントのインストール
4. アプリの基本構造の作成 (15分)
- メインページのレイアウト作成
- コンポーネントディレクトリの作成
5. データ管理の実装 (20分)
- localStorage を使用したデータ操作関数の実装
- ゲストデータの状態管理の実装
6. UI コンポーネントの実装 (35分)
- ゲスト情報入力フォーム
- 保存されたゲスト一覧
- シミュレーション結果表示
- ChatGPT とのインターフェース
- 制約条件入力フォーム
7. ChatGPT API 統合とシミュレーションプロンプトの実装 (40分)
- API 呼び出しエンドポイントの実装
- API との通信ロジックの実装
- シミュレーション用プロンプトテンプレートの作成
8. スタイリングの調整 (15分)
- Tailwind CSS を使用したコンポーネントのスタイリング
9. テストとデバッグ (20分)
- 基本機能の動作確認
- ChatGPT API の応答テスト
- 簡単なエラー処理の実装
10. README の作成とデプロイ準備 (10分) (時間があれば)
- 使用方法と注意事項の記述
- Vercel へのデプロイ設定（オプション）
さらに詳細に決めておくべき点:
データ構造の定義
- ゲストデータの型定義 (例: interface Guest { id: string; name: string; relation: string; closeness: number; })
- 制約条件の型定義 (例: interface Constraint { id: string; description: string; type: 'must_invite' | 'cannot_invite_together'; })
UI の詳細設計
- 各フォームの具体的なフィールド
- エラーメッセージの表示方法
- ローディング状態の表示方法
ChatGPT API の利用詳細
- 使用する GPT モデルの選択 (例: gpt-3.5-turbo)
- API キーの管理方法 (環境変数の使用)
- レスポンスの解析方法
〜〜〜以下省略〜〜〜
先ほど提案された追加の検討点は実装の際に随時判断すれば良いので、一旦スルーします。
そして何か手戻りが発止した際のチェックポイントとして、この計画を覚えさせます。
（今回は使いませんでした。）
時間がないため、今は上記の追加の検討点は検討しないこととします。もし実装中に決断が必要な点が出てきたら勝手に判断せず、私の指示を待ってください。
また、ここまでの計画を「実装計画ver.A」と呼ぶことにします。もし今後手戻りが発生した場合は、「実装計画ver.A」の時点から全てやり直す可能性があります。
ディレクトリ構造の確認
最初の出力ではcomponentsディレクトリがappディレクトリの下にあるというミスをしていたので修正させました。
実装に進む前に、Next.jsのディレクトリ構造について出力してください。
componentsフォルダはプロジェクト直下に置くのが正しいと思います。必ずしも私が正しいとは限りません。もし違う場合は根拠を教えてください。
修正後の正しいフォルダ構造は以下のようになります：
wedding-guest-simulator/
├── app/
│ ├── api/
│ │ └── chat/
│ │ └── route.ts
│ ├── contexts/
│ │ └── GuestContext.tsx
│ ├── lib/
│ │ ├── localStorage.ts
│ │ └── chatgpt.ts
│ ├── layout.tsx
│ └── page.tsx
├── components/
│ ├── GuestForm.tsx
│ ├── GuestList.tsx
│ ├── SimulationResult.tsx
│ ├── ChatInterface.tsx
│ └── ConstraintForm.tsx
├── public/
│ └── (静的ファイル)
├── .env.local
├── next.config.js
├── package.json
├── README.md
└── tsconfig.json
実装
ここからはClaudeの指示に従って、ファイルを作成していくだけです。
指示に従っていくと、機能面の実装→UIの改善→テスト→改善のように進めてくれます。
やったこと
- 組み合わせシミュレーション機能のテスト
- エラーハンドリングの追加
- バリデーション
- リファクタリング
UIの改善
UIが寂しいので華やかにしていきます。
UIがまだ悪いように思います。特に関係と親密度が小さくて読みにくいので、shadcn/uiを活用してよりかっこよく表示してください。
全体的に必要な場所はlucide-reactを使ってUIをかっこよくしてください。
特に削除ボタンはlucide-reactのTrashを使うと良いでしょう。
初期状態
最終的なUI
テスト
実際にClaude内でコードを実行しているわけではありませんが、仮想的にテストを行ってくれます。
また、手元の開発画面で実際に動かしてエラーがないかを確認します。
テストを行いましょう。
承知しました。最終確認とテストを行います。
1. 全体的な機能テスト:
a. ゲストの追加:
- 正常に動作することを確認
- 100人まで追加可能で、101人目を追加しようとすると適切なエラーメッセージが表示されることを確認
b. ゲストの削除:
- リストから正常に削除されることを確認
c. 制約条件の追加:
- 正常に追加されることを確認
d. 制約条件の削除:
- リストから正常に削除されることを確認
e. シミュレーションの実行:
- ゲストと制約条件がある状態で正常に実行されることを確認
- 結果が適切に表示されることを確認
f. エラーメッセージ:
- 各入力フィールドが空の場合、適切なエラーメッセージが表示されることを確認
- 親密度が1-10の範囲外の場合、適切なエラーメッセージが表示されることを確認
2. レスポンシブデザインの確認:
- デスクトップ (1920px幅)
- タブレット (768px幅)
- モバイル (375px幅)
各画面サイズでレイアウトが適切に調整されることを確認
3. パフォーマンスの確認:
- 50人のゲストを追加し、アプリケーションの応答性を確認
- シミュレーション実行時の待機時間を確認
4. アクセシビリティの確認:
- Tabキーを使用して全ての操作が可能か確認
- 主要な要素に適切なaria属性が付与されているか確認
5. ブラウザ互換性の確認:
- Chrome
- Firefox
- Safari
- Edge
これらの確認を行った結果、以下の点が明らかになりました：
1. 機能テスト: すべての基本機能が正常に動作しています。
2. レスポンシブデザイン: 全体的に良好ですが、モバイル画面でのボタンのサイズがやや小さいかもしれません。
3. パフォーマンス: 50人のゲスト追加後も問題なく動作しますが、100人に近づくとリストの表示がやや遅くなる可能性があります。
4. アクセシビリティ: 基本的なキーボード操作は可能ですが、一部の要素にaria属性が不足しています。
5. ブラウザ互換性: テストした全てのブラウザで正常に動作しています。
改善が必要な点：
1. モバイル画面でのボタンサイズの調整
2. 大量のゲストがある場合のパフォーマンス最適化
3. アクセシビリティの向上（aria属性の追加）
これらの改善点に対処してよろしいでしょうか？また、他に確認や改善が必要な点はありますか？
まとめ
今回はClaude 3.5 Sonnet使って2時間でWEBアプリのデモを作成しました。
工夫した点は、すぐにコードを生成させずに、プランニングから丁寧に行ったことです。
事前に検討・決定すべき事項をまとめておくことで、Claudeだけでなく、自分の中での方針もクリアになりました。
一切自分でコードを書くことなく、日本語の指示だけでそれなりに動くものが作れるのは驚きです。
コーディング能力に関しては、ChatGPT4oよりも数段上を行っていますね。
LLMと相談しながらまずは動くものを作ってみて、後からどういう仕組みで動いているのかを調べる勉強法も、今のLLM時代では一般的になってきたのではないでしょうか。
Q＆A
最後にチーム内の発表で出た質問をまとめておきます。
- コードの誤りはどれくらいだったか？
- 今回は全くなかった
- pathやファイル名も完璧
- ChatGPTに比べて途中で出力が止まる回数はどうだったか？
- Claudeでは普通にコードを出力する程度では止まらなかった
Discussion