Claude Code でアイデアを動く試作品にする手順

日本の会社で新しいアイデアを通そうとすると、まず企画書、次に稟議、そして予算の話になります。その間に数か月が過ぎることも珍しくありません。私は順番を逆にすることをすすめています。先に動くものを作り、それを見せて話を進める。Claude Code を使えば、週末で「触れる試作品」まではたどり着けます。

ここでは、アイデアを動くアプリにするまでの手順を、私が実際に使っている流れで紹介します。

最初に書くのは企画書ではなく一段落

ターミナルを開く前に、次の三つを日本語で一段落にまとめます。誰のためのアプリか。そのアプリがやる一つの仕事は何か。最初のバージョンが「できた」と言える状態は何か。

ここで欲張らないことが大切です。ログイン、決済、管理画面、通知設定。どれも後から足せます。最初は「このアイデアは成立する」と証明できる一つの流れだけに絞ります。

Claude にヒアリングしてもらう

空のフォルダをターミナルで開き、claude を起動します。インストールがまだなら、公式のセットアップページに最新のコマンドがあります。

起動したら Shift+Tab を押して plan mode に切り替えます。このモードでは Claude はファイルを書き換えず、読んだり質問したりするだけです。プロンプトは日本語でまったく問題ありません。

こういうアプリを作りたいです：[一段落の説明]
コードを書く前に、私にヒアリングしてください。
利用者、主要な操作の流れ、保存するデータ、例外ケース、
最初のバージョンでやらないことを、一つずつ質問してください。
終わったら SPEC.md に、課題、操作の流れ、データ構造、画面一覧、
対象外の範囲、完成の判定基準をまとめてください。

ヒアリングが終わったら、もう一度 Shift+Tab で plan mode を抜け、SPEC.md を保存してもらいます。Anthropic のベストプラクティスでも、大きめの機能では先に Claude にインタビューさせる方法が紹介されています。

日本向けのアプリなら、この段階で日本特有の仕様も質問させておくと後が楽です。氏名とフリガナの扱い、全角と半角、郵便番号からの住所入力、和暦の表示、請求書の形式などです。後から直すと、データ構造ごと作り直しになることがあります。

調査は並列で、技術選定は軽く

Claude Code はサブエージェントを使って、複数の調査を同時に進められます。

サブエージェントを並列で使って調べてください。
1. 同じ課題を解決している既存サービスと、その不満点
2. SPEC.md を一人で作るのに一番シンプルな技術構成
3. 依存する外部 API の制限と料金ページ
結果を RESEARCH.md にまとめ、おすすめの構成を一つ理由つきで提案してください。

提案が重すぎると感じたら、遠慮なく削ってもらいます。最初のバージョンは部品が少ないほど強いです。

CLAUDE.md にルールを書く

ある程度ファイルができたら /init を実行します。CLAUDE.md が作られ、Claude は毎回のセッションの最初にこれを読みます。詳しくはメモリのドキュメントにあります。

# プロジェクト
フリーランス向けの請求管理アプリ。仕様は SPEC.md。

# 進め方
- 機能は PLAN.md の順番に一つずつ作る
- 一つ終わるたびにチェックを実行し、結果を見せて止まる
- 新しいライブラリを追加する前に必ず確認する
- 画面の文言は自然な日本語、です・ます調

# チェック
- npm run lint
- npm test

同じ注意を二回したら、チャットで繰り返すのではなく、ここに一行足します。

縦に切って、一枚ずつ作る

SPEC.md から PLAN.md を作ってもらい、番号つきの小さな単位で進めます。一つの単位にはデータ、処理、画面、テストまで含めます。「先にバックエンドを全部」というやり方は整理されて見えますが、実際には何日も動くものが見えません。

一つ終わったら自分で触って確認し、git でコミットします。それから次へ進みます。途中で壊れても、戻れる場所が常にある状態にしておきます。

「できました」ではなく証拠を出してもらう

品質を一番上げるのは、Claude が自分の仕事を確認できる仕組みです。テスト、型チェック、ビルドの結果を毎回見せてもらいます。画面については、Chrome 連携を使えば Claude がブラウザでアプリを開き、スクリーンショットを見ながら直せます。

ブラウザでアプリを開き、新規ユーザーとして SPEC.md の流れを一通り操作してください。
各ステップでスクリーンショットを撮り、壊れている点、分かりにくい点を一覧にして直してください。

チェックを毎回確実に走らせたい場合は、ベストプラクティスで紹介されている考え方と同じく、「確認できないものは完成と呼ばない」をルールにします。CLAUDE.md に書いたチェックの結果を、機能ごとに必ず出してもらいましょう。

試作品と製品は別物

週末で手に入るのは、上司や顧客に見せられる動く試作品です。稟議の場で「こういうものです」と画面を見せられるのは、資料十枚より説得力があります。ただし、お金を受け取る製品にするには、ログインと決済まわりのセキュリティ確認、失敗時の動作確認、本番環境での監視が必要です。決済サービスのアカウントや本番用の鍵はあなた自身が用意するもので、鍵はリポジトリに入れず環境変数で管理します。

今夜はヒアリングの手順だけやってみてください。一段落を書き、Claude の質問に答え、できた SPEC.md を読む。翌朝もまだ作りたいと思えたら、最初の一枚を作り始めましょう。