【連載③】Claude Codeに実装させる対話術：プロンプトの書き方3パターン
連載ナビ
- 前回：[【連載②】cloneとbranch、最初に詰まる2語](https://maahsachi.com/claude-code-clone-branch)
- 次回：【連載④】動作確認とテストの最低ライン（近日公開）
- 連載一覧：Claude Code × GitHub 運用フロー（全8回）
—
「Claude Codeに実装を頼もうとしたけど、何をどう書けばいいかわからない」
最初にそう感じた記憶があります。「コードを書いて」と送っても出てくるものがイメージと違うし、かといって細かく書こうとすると今度は何を書けばいいかわからなくなる。
この連載第3回では、非エンジニアでもそのまま使える「Claude Code 実装プロンプト」の書き方を、3つのパターンと具体的な例文でお伝えします。
—
Claude Code 実装プロンプトの結論：ゴールを最初に書くだけで変わる
最初に結論を言ってしまいます。
実装指示で最も効いたのは「ゴールを一番最初に書く」ことでした。
Claude Codeは、目的・対象・完成条件が明確なほど精度の高い実装をしてくれます。そのため、「最終的に何がほしいか」を先頭に書くことで、全体の方向性がぶれにくくなります。
たとえば、こんな違いがあります。
あいまいな指示の例：
ユーザーが商品を選べる機能を作って
ゴールファーストの指示の例：
【目標】商品リストから1つ選んでカートに追加できる機能を実装してください。
対象ファイル: src/components/ProductList.tsx
仕様:
- 商品名・価格・在庫数を一覧表示する
- 「カートに追加」ボタンをクリックすると選択状態になる
完成条件: 既存のカート状態管理に合わせて、ボタン押下後にカート内商品数が+1されること。状態管理の方法が不明な場合は実装前に確認してください。
同じことを言っているように見えて、出力の精度がまったく違います。最初の例では「どんな商品？」「どこに表示？」「どのファイルを変更する？」といった情報がないため、Claude Codeが推測で補わなければならない部分が増えてしまいます。
—
最初に詰まったこと：どこまで細かく書けばいいの問題
実装を依頼しはじめた頃、いちばん困ったのは「指示の粒度」でした。
ざっくり伝えると意図と違うものが生まれる。細かく書こうとするとそれ自体が難しい。
何度か試してみた結果、規模によって指示パターンを変えると安定するとわかりました。
—
実装指示の3つのパターン
パターン1｜丸ごと依頼（1ファイルで完結する実装向け）
小さな機能や1ファイルで収まるものは、ゴールファーストで丸ごと依頼するのがシンプルで効果的です。
【目標】CSVファイルを読み込んで、商品名・価格・在庫数のHTMLテーブルを生成してください。
ファイル名: product_table.py
入力: data/products.csv（1行目はヘッダー行。ファイルがなければサンプルCSVも一緒に作成してください）
出力: product_table.html
意外とこれくらいの指示で、使えるコードが出てきます。「もっと細かく書かないといけない」という思い込みがあったのですが、実際には目標・入力・出力の3点セットがあれば十分なことが多いです。
パターン2｜段階的に分解して依頼（複数ファイルをまたぐ実装向け）
データベース設計からAPIまでをまとめて作ってもらおうとしたとき、一気にやらせるとどこかがおかしくなっても追いかけるのが大変でした。
そこから試しているのが、段階的に分解して依頼するやり方です。
最初のメッセージ（Step1のみ送る）:
まずデータベースのスキーマ設計案だけを提案してください。
コードはまだ書かないでください。提案が終わったら停止して待ってください。
OKと返したら次を送る（Step2）:
前回提案したスキーマに基づいて、既存プロジェクトの構成を確認したうえでモデルクラスを実装してください。
変更するファイルを先に示してから実装を開始してください。完了したら停止して待ってください。
さらにOKと返したらStep3を送る:
APIエンドポイントを実装してください。
「ここまでは合ってる」という確認ポイントを自分で作れるので、後で修正が必要なときも範囲が絞りやすくなります。
パターン3｜役割を与えてから依頼（品質を上げたいとき）
「あなたはセキュリティを重視するWebエンジニアです」のように役割を先に伝えると、確認してほしい観点が伝わりやすくなる感触があります。
あなたはセキュリティを重視するWebエンジニアです。
以下のログイン画面にバリデーション処理を追加してください。
対象ファイル: src/auth/LoginForm.tsx
要件:
- メールアドレスの形式チェック
- パスワードの最小8文字チェック
- エラーメッセージの表示
- 既存のサーバー側認証ロジックは変更しない
役割なしで同じことを頼むと、バリデーション自体は書いてくれるものの、エッジケースの考慮が甘いことがありました。「セキュリティを重視する」という一言で、確認してほしい観点が伝わりやすくなった感じがします。
—
コピペして使えるプロンプトひな形
以下のひな形をClaude Code CLIのターミナル入力欄にそのまま貼り、`[ ]`の部分を書き換えて使ってください。
【目標】[実現したいことを1文で書く]
【対象ファイル】[変更するファイルのパス]
【仕様】
- [仕様1]
- [仕様2]
- [仕様3]
【完成条件】[どうなっていれば完了とみなすか]
【制約・注意点】[既存の命名規則・使わないライブラリなど、あれば]
不明な点があれば実装前に質問してください。推測で進めず、確認してから作業してください。
埋まらない項目があっても大丈夫です。そういうときは素直に「ここはどうすればいいですか？」とClaude Codeに聞いてしまうのが一番早いです。
—
まだわかっていないこと
正直に言うと、今も迷うことがあります。
実装の途中で「このやり方よりこっちのほうがいい」とClaude Codeが提案してくることがあります。コードが読めないと、その提案が本当に良いものかどうか自分では判断できません。
今は「なぜその方法がいいのか説明してください」と追加で聞くようにしています。説明を読んで「なるほど」と思えたら採用、よくわからなければ「最初の方針で進めてください」と返す。これが今のところの正直な対処法です。
「提案の良し悪しをすぐ判断できるようになる」のがゴールですが、まだそのレベルには至っていません。これは引き続き試行中のテーマです。
—
まとめ
- Claude Code 実装プロンプトは「**ゴールと完成条件をセットで書く**」と安定しやすい
- 小規模な実装は**丸ごと依頼**、複数ファイルをまたぐなら**段階的に分解**
- **役割を与える**と出力の専門性が上がる
- ひな形に当てはめると「何を書けばいいかわからない」が解消される
- わからない部分はそのままClaude Codeに聞くと進めやすい
実装指示は最初から完璧である必要はないです。「ちょっと違う」と思ったら追加の指示で修正していけばいいだけです。この往復の対話のなかで実装が完成していく感覚が、Claude Codeを使った開発の面白いところだと最近思っています。
次回は実装したものの動作確認とテストの最低ラインについて書きます。
—
連載一覧：Claude Code × GitHub 運用フロー（全8回）
