Claude Codeプロンプト書き方｜実装速度が3倍になる型
Claude Codeのプロンプトをどう書けば実装速度が3倍になるのか。タスク分解・コンテキスト・確認ポイント・出力指定の4要素を、現場で再現可能な型として整理しました。
「Claude Codeを入れたが、雑なプロンプトを投げて、結果が雑に返ってくる。生産性が逆に落ちている」——導入直後のエンジニアから最も多い相談です。Cursor／GitHub Copilotとの違いを理解せず、IDE補完ツールの感覚で使うと効果が出ません。
Claude Codeプロンプト書き方｜実装速度が3倍になる型
本記事は、Claude Codeのプロンプトを「タスク分解・コンテキスト・確認ポイント・出力指定」の4要素に分解し、実装速度が3倍になる現場の型として整理したものです。LiftBaseの開発現場で、20名のエンジニアが共通して使っている実用フレームワークを公開します。
「プロンプトエンジニアリング」というと抽象的に聞こえますが、Claude Codeでは「コードを書かせる」という具体的な目的があるため、4要素を埋めるだけで誰でも再現できます。
Claude Codeで成果が出るプロンプトの4要素
良いプロンプトには共通構造があります。
1. タスク分解（何を作るか）
1プロンプト=1タスク。複数機能を一度に依頼すると、Claude Codeが文脈を見失います。「ログイン画面を作って、APIも書いて、テストも追加」ではなく、「ログイン画面のフォームコンポーネントだけ作って」と分解する。
2. コンテキスト（既存コードの前提）
ファイルパス、関連する型定義、既存の命名規則をプロンプト内で指示します。Claude Codeは大きなコンテキストウィンドウを持ちますが、関連ファイルを明示する方が精度が上がります。
3. 確認ポイント（成功条件）
「テストが通ること」「TypeScriptエラーが出ないこと」「既存スタイルガイドに従うこと」など、検証可能な条件を必ず入れます。これがないとClaude Codeは「動きそうな雰囲気のコード」を出して終わります。
4. 出力指定（何を返してほしいか）
「コード差分のみ」「実行手順を最後に箇条書き」「テストコードもセットで」など、出力形式を指定します。曖昧だと過剰な説明文や不要なリファクタが返ってきます。
4要素のうち、最初に投資すべきは「タスク分解」です。これができていないと他の3要素を埋めても効果が出ません。
1領域に絞る：タスク分解が9割
Claude Codeで成果が出ない人の共通点は「タスクを大きく投げる」ことです。
悪い例：「ECサイトのカート機能を作って」
良い例：「src/components/Cart.tsx を編集して、商品の数量変更ボタンを追加して。useCart フックの updateQuantity を呼ぶだけ。テストは Cart.test.tsx に1ケース追加。」
タスク分解の3基準。
基準1：1プロンプト=1ファイル変更が原則
複数ファイル変更を一度に依頼するなら、Claude Codeに「変更計画を先に出して」と指示し、計画レビュー後に実装に進む。
基準2：差分が30行以内に収まる単位
大きすぎる差分はレビューも難しくなります。30行を超えそうなら、さらに分解する。
基準3：単独でテスト可能な単位
「ログイン画面」ではなく「ログイン画面のバリデーションロジック」「ログイン画面のフォーム送信」と分けると、各単位でテストが書けます。
タスク分解の習慣がつくと、Claude Codeは「経験豊富なエンジニアの右手」になります。逆にこれができないと、ジュニアエンジニアに丸投げするのと同じ失敗が起きます。
4要素別・実例とテンプレート
各要素のプロンプト実例をテンプレート化します。
コンテキスト指示の型
このリポジトリの命名規則:
- React コンポーネントは PascalCase
- フックは use プレフィックス
- API クライアントは src/lib/api/ 配下
関連ファイル:
- src/components/Cart.tsx（編集対象）
- src/hooks/useCart.ts（呼び出し元、変更しない）
- src/types/cart.ts（型定義）
スタイル: TailwindCSS、既存の Cart.tsx に合わせるファイルパスを明記し、変更してよい/ダメな範囲を区切るのが要点です。
確認ポイントの型
完了条件:
- pnpm test src/components/Cart.test.tsx が通る
- pnpm tsc --noEmit でエラーゼロ
- 既存の updateQuantity 呼び出しは破壊しない
- 数量0以下は disabled で操作不可検証可能な条件だけ書きます。「使いやすく」のような曖昧な指示は外す。
出力指定の型
出力フォーマット:
1. 変更ファイルの差分（コードブロック）
2. 追加するテストコード（コードブロック）
3. 動作確認手順（箇条書き3行）
過剰な説明文は不要です。出力指定がないと、Claude Codeは「丁寧に解説したつもりの長文」を返してきます。形式を縛る。
Claude Codeで実装速度3倍の現場試算
「実装速度3倍」がどのくらいの規模感か、具体的に見ておきます。Web開発エンジニア5名・週40時間稼働のチームモデルで試算します。
| 業務 | Before（従来） | After（Claude Code） | 削減時間/週 |
|---|---|---|---|
| ボイラープレート実装 | 8h | 2h | 6h |
| テストコード作成 | 6h | 2h | 4h |
| バグ修正調査 | 5h | 2h | 3h |
| ドキュメント更新 | 3h | 1h | 2h |
| 合計 | 22h | 7h | 15h/週 |
エンジニア5名で週75時間削減、月300時間の業務時間が浮きます。時給5,000円換算で月150万円、年間1,800万円分の業務時間が「設計・要件定義・コードレビュー」など、より高単価な業務に振り向けられます。
ただし「3倍」が出るのはタスク分解と4要素プロンプトが習慣化された後です。導入直後は1.5倍程度、3ヶ月後に3倍に達するのが標準的です。
Claude Codeプロンプトでつまずく5つの罠
支援現場で繰り返し見てきた、エンジニアがハマりやすい5つの罠を共有します。
罠1：丸投げプロンプト
「いい感じにECサイトを作って」のような曖昧指示。Claude Codeは推測で動き、再修正コストが大きくなります。タスクを30行差分単位に分解する。
罠2：コンテキスト不足
ファイルパス・既存命名規則・型定義を渡さず実装させる。結果として既存コードと食い違うコードが出てきます。コンテキストブロックを必ず付ける。
罠3：確認ポイント未設定
完了条件がないと、Claude Codeは「動きそうなコード」を出して終わり。テストコマンド・型チェックコマンドを必ず明記する。
罠4：機密情報をプロンプトに直貼り
APIキー・本番DB接続情報・顧客個人情報をプロンプト内に貼ると学習リスクがあります。プロンプトには ${OPENAI_API_KEY} のように環境変数名で参照させ、実値は .env に置く。Claude Codeは公式に学習オプトアウトを提供していますが、機密情報は最初から渡さないのが原則です（出典：Anthropic Privacy Policy）。
罠5：出力形式を放置
形式指定なしで「説明込みで返します」が長文化。差分のみ・手順のみ・コードのみと縛る。
5つの罠は、ツール選定より先に「プロンプト規約」として社内ドキュメント化しておくのが正解です。
チームへの展開：30日で文化を作る
実装の順序を、3フェーズに分けて整理します。
フェーズ1：0-7日（個人で4要素を体得）
- 個人で1日10プロンプト × 7日間
- 各プロンプトを「タスク分解／コンテキスト／確認ポイント／出力指定」の4要素で記述
- 失敗例・成功例をテキストファイルに記録
このフェーズの目的は「4要素プロンプトの筋トレ」です。最初の1週間で習慣化できれば、次のフェーズが楽になります。
フェーズ2：8-21日（チーム3名でレビュー会）
- 週次でプロンプト共有レビュー会（30分）
- 良かったプロンプトをテンプレ化
- 社内Wikiに「プロンプトテンプレ集」を作る
3名の共通言語ができれば、新メンバーへの引き継ぎも楽になります。
フェーズ3：22-30日（チーム全体展開）
- プロンプト規約をリポジトリの
CLAUDE.mdに明記 - 新規メンバー向けオンボーディング資料を整備
- 月次でプロンプト品質レビュー
30日後、Claude Codeが「個人ツール」から「チームツール」に変わります。詳細はClaude Codeのチーム導入ロードマップも参照ください。
よくある質問
Q1. CursorやGitHub Copilotとプロンプトの書き方は違いますか？
違います。Cursor／Copilotは「IDE補完」ベースなのでプロンプトは短文でOK、Claude Codeは「エージェント実行」ベースなので構造化プロンプトが必須です。Cursor感覚で使うと効果が出ません。差分はClaude CodeとCursorの違いに整理しています。
Q2. プロンプトに渡す情報量は多い方がいいですか？
「多い＝良い」ではなく「必要十分」が答えです。コンテキストウィンドウは大きいですが、無関係なファイルを渡すと精度が下がります。変更対象＋直接呼び出される依存ファイル＋型定義の3点に絞る。
Q3. ChatGPTやClaude.aiでも同じ書き方でいいですか？
部分的にはYesですが、Claude Codeはツール実行（ファイル読み書き・bash実行）ができるため、「タスク分解」と「確認ポイント」がより重要です。Claude.aiの会話ベースとは別と捉えてください。
Q4. プロンプト規約は何文字くらいになりますか？
社内 CLAUDE.md は500〜1,500字が現実的です。長すぎるとClaude Codeが読み飛ばします。「命名規則／ファイル構成／テストコマンド／機密情報の扱い」の4項目を簡潔に。
Q5. 失敗した場合のリスクは？
最大のリスクは「Claude Codeが本番ファイルを意図せず書き換える」ことです。これを避けるため、必ず（a）git ブランチを切ってから作業、（b）destructive 操作（rm -rf, force push）には事前確認、（c）API キー・DB 接続情報をプロンプトに含めない、の3点を運用ルールに組み込んでください。
30分の無料AI業務診断
Claude Codeを社内に導入したい方に向けて、30分の無料AI業務診断を実施しています。プロンプト規約の整備、チーム展開、既存IDE環境との接続まで、現場ヒアリングをもとにご提案します。
営業・経理・人事の「どこから始めるか」を、無料で見える化します
30分の無料AI業務診断
御社の業務フローをヒアリングし、AIで何時間が浮くか・どこから始めるべきかを可視化します。
「いきなり契約」ではありません。診断結果のレポートだけでも持ち帰れます。
まずは話を聞いてみたい方は、無料相談から
無料相談（オンライン30分）
「うちの業界でAIは効くのか」「他社事例を聞きたい」「何から手をつけていいか分からない」など、
ふんわりした疑問でも結構です。営業出身の代表 渋谷が直接お話しします。
執筆者プロフィール
渋谷祐太（しぶや ゆうた）｜株式会社LiftBase 代表取締役CEO
学生時代に株式会社エス・エム・エスでインサイドセールスに従事し、顧客接点と業務プロセス設計の基礎を学ぶ。新卒で日本IBMに入社し、コンサルタントとして大手クライアントの業務改革・システム導入を担当。その後、ファインディ株式会社で事業企画としてプロダクトと事業の接続を経験。2024年9月に株式会社LiftBaseを創業し、代表取締役CEOに就任。AI導入が「実装段階で止まる」課題に向き合い、Claude Code・Codex を中心とした AI ネイティブな開発体制づくりを支援している。
「テクノロジーは、使い方次第でビジネスの構造そのものを変える力を持っている。中小企業の『あと一歩』の壁を、現場と経営の両方から越えていきます。」
関連記事
