新しく作る

Claudeは最初の一言からでも製品を作り始めてくれます。良い結果との差は、最初に渡す文脈と、途中の確認の仕方で生まれます。

目的と規模から話し始める

設計にどれだけ力を入れるかは、その製品が試作か長期運用か、利用者が何人か、失敗した時に何が起きるかで変わります。この情報はClaudeからは見えないため、最初に伝えます。

社内10人が使う備品予約ツールを作りたい。まず試作として1週間使えれば十分。
弊社の標準スタック（Cloudflare、Next.js、shadcn/ui、Tailwind CSS）で作って。

全部が決まっている必要はありません。決めきれていないところはそう伝えて、質問してもらいながら会話の中で要件を整理します（要件は会話の中で整理する）。技術の指定は推奨する技術スタックの通りに伝えれば十分で、中身の判断はClaudeに任せられます。

予約の仕組みを作りたいけど、要件がまだ固まってない。質問しながら一緒に整理して

雛形から始める

ゼロから書き始めてもらうより、雛形から始めます。弊社ではshadcn/uiのcreateで、フレームワークにNext.js、部品の土台にBase UI（shadcn/uiの部品が下敷きにするライブラリ）を選んで雛形を作ります。標準スタックに沿った初期構成が最初から揃うため、Claudeへの最初の依頼を「作り方の選定」ではなく「作るものの中身」から始められます。自分で操作する必要はなく、雛形作りごとお願いできます。

shadcn/uiのcreateを使って、Next.jsとBase UIの構成で雛形を作るところから始めて

小さく作って、動かして確かめる

コードを読まずに品質を判断する手段は、実際に操作することと、自動テストの2つです（品質の観点）。一度に全部を作ってもらうのではなく、動く最小の形を作ってもらっては操作し、直してもらっては操作する、を繰り返します。

操作するときは、うまくいく手順だけでなく、壊れそうな手順を試します。空のまま送信する、極端に長い文字を入れる、スマホの幅で表示する、戻るボタンを押す、同じボタンを連打する、といった操作です。

利用者がやりそうな操作で壊れるものがないか、自分で試して報告して

公開前の点検

公開の直前に確認することは5つです。秘密情報がコードと履歴に残っていないか（トークン・APIキー）。リポジトリの公開範囲は意図通りか（リポジトリの公開範囲）。個人情報を集めるなら、項目は最小で、プライバシーポリシーはあるか（個人情報・認証・決済）。ホスティング、データベース、外部APIのどこから費用が発生し始めるか。そして、ドメイン、ホスティング、リポジトリといった製品の実体がどのアカウントにあるか。実体が個人のアカウントにあると、その人が抜けた時に誰も触れなくなります。

公開したら終わりではない

公開後の問題は、自分の画面の前では起きません。壊れたことに利用者より先に気づく仕組み（品質の観点の監視）を入れておきます。公開後に直すときは、既存の製品を修正するの手順に移ります。