新しく作る

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

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

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

以前の会話で伝えた条件も、今回の依頼に関係するものは改めて示します。判断の前提になる資料がある場合は、ファイル名を指定して読んでもらいます。公開範囲、利用対象、本番運用の有無など、CLAUDE.mdに残す前提の一覧を見ながら、分かっていることから記録します。

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

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

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

雛形から始める

弊社では、標準スタックに沿った雛形から始めます。画面の部品や検査の仕組みを製品ごとに選び直す手間を減らし、作るものの中身を確かめる時間に使うためです。雛形を用意した後も、まず小さな画面で目的に合っているか確認します。

弊社の標準スタックで雛形を用意して、最初に確認する画面を一つ作って

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

コードを読まずに品質を判断する手段は、実際に操作することと、自動テストの2つです（品質の観点）。データベースやAPIより先に、モックデータ（モック）を入れた画面から作ってもらいます。一度に全部を作ってもらうのではなく、動く最小の形を作ってもらっては操作し、直してもらっては操作する、を繰り返します。

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

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

公開前の点検

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

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

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