AIプロンプトのパターン集 ── コピペで使える実践テンプレート20選

プロンプトは「型」を持つと楽になる

バイブコーディングでAIに指示を出すとき、毎回ゼロから文章を考えるのは非効率だ。プロンプトの品質にもバラつきが出る。

解決策はシンプルで、よく使うパターンを「型（テンプレート）」として持っておくこと。型があれば、穴埋めするだけで一定品質の指示が出せる。この記事では、バイブコーディングの現場で実際に使い回せる20個のパターンを、カテゴリ別に網羅的に紹介する。

---

まず知っておきたい：初心者が使う頻度の高いTop5

20個すべてを覚える必要はない。まずは以下の5パターンを押さえれば、日常のバイブコーディングの8割はカバーできる。

順位	パターン	カテゴリ	こんなときに使う
1	#1 新規サイト作成	Webサイト系	プロジェクトの立ち上げ時
2	#7 バグ修正	修正・改善系	エラーが出たとき（最も頻繁に使う）
3	#4 CRUD機能	アプリ系	データ管理機能を作るとき
4	#17 段階的構築	応用パターン	大きな機能を安全に作りたいとき
5	#19 既存コード理解	応用パターン	他人のコードや過去の自分のコードを読むとき

---

全20パターン カテゴリ一覧

カテゴリ	パターン番号	内容
Webサイト系	#1〜#3	サイト作成、コンポーネント追加、レスポンシブ修正
アプリ系	#4〜#6	CRUD、フォーム、API連携
修正・改善系	#7〜#10	バグ修正、デザイン改善、パフォーマンス、リファクタリング
コンテンツ系	#11〜#12	記事生成、SEO最適化
調査・分析系	#13〜#14	技術調査、コードレビュー
デプロイ・運用系	#15〜#16	Git操作、デプロイ設定
応用パターン	#17〜#20	段階的構築、比較、コード理解、トラブルシューティング

---

Webサイト系

1. 新規サイト作成

使用場面： プロジェクトをゼロから立ち上げるとき。最初の1回だけ使うが、プロジェクト全体の方向性を決める最重要パターン。

[フレームワーク]で[サイトの種類]を作ってください。

ページ構成：
1. [ページ名]（[内容]）
2. [ページ名]（[内容]）

デザイン：
- [カラー]基調
- [フォント]
- レスポンシブ対応

具体的な記入例：

Astroで個人ブログサイトを作ってください。

ページ構成：
1. トップページ（最新記事5件をカード形式で表示）
2. 記事一覧ページ（全記事をタグでフィルタリング可能）
3. 記事詳細ページ（Markdown本文、目次、前後記事リンク）
4. Aboutページ（プロフィール、SNSリンク）

デザイン：
- ダークブルー(#1a1a2e)基調、アクセントにオレンジ(#e94560)
- Noto Sans JP
- レスポンシブ対応（モバイルファースト）

---

2. コンポーネント追加

使用場面： 既存サイトに新しいUI部品を追加するとき。ヘッダー、フッター、カード、モーダルなど。

以下のコンポーネントを作ってください：
- 名前: [コンポーネント名]
- 機能: [何をするか]
- Props: [受け取るデータ]
- デザイン: [見た目の説明]
既存の[ファイルパス]のスタイルに合わせてください。

具体的な記入例：

以下のコンポーネントを作ってください：
- 名前: PricingCard
- 機能: 料金プランを1つ表示する。人気プランにはバッジをつける
- Props: planName(string), price(number), features(string[]), isPopular(boolean)
- デザイン: 角丸カード、ホバーで影が濃くなる、人気プランは枠線を金色に
既存のsrc/components/Card.astroのスタイルに合わせてください。

---

3. レスポンシブ修正

使用場面： PCでは正常だがスマホで崩れている場合。デプロイ後にスマホ実機で確認して気づくことが多い。

[ファイルパス]をモバイル対応にしてください。
現在PCでは正常ですが、スマホ（幅375px）で以下の問題があります：
- [問題1]
- [問題2]

具体的な記入例：

src/components/Header.astroをモバイル対応にしてください。
現在PCでは正常ですが、スマホ（幅375px）で以下の問題があります：
- ナビゲーションメニューが横に溢れて横スクロールが発生する
- ロゴとメニューボタンが重なっている
- フォントサイズが大きすぎて1行に収まらない

スマホではハンバーガーメニューに切り替えてください。

良い結果が出るコツ： 「スマホで崩れている」だけでなく、具体的に何がどう崩れているかを書く。「横に溢れる」「重なる」「はみ出す」など、症状を言語化するのがポイント。

---

アプリ系

4. CRUD機能

使用場面： データの追加・表示・編集・削除を行うアプリを作るとき。TODOアプリ、家計簿、在庫管理など、ほとんどのアプリの基本。

以下のデータを管理するアプリを作ってください：
- データ項目: [名前、日付、金額など]
- 機能: 追加、編集、削除、一覧表示
- 保存先: localStorage
- デザイン: シンプルなカード形式

具体的な記入例：

以下のデータを管理する家計簿アプリを作ってください：
- データ項目: 日付、カテゴリ(食費/交通費/娯楽/その他)、金額、メモ
- 機能: 追加、編集、削除、一覧表示、月別集計グラフ
- 保存先: localStorage
- デザイン: シンプルなカード形式、カテゴリ別に色分け
- ソート: 日付の新しい順
- フィルタ: カテゴリ別、月別

---

5. フォーム作成

使用場面： お問い合わせフォーム、会員登録、アンケートなど、ユーザーからの入力を受け取る画面を作るとき。

以下の入力フォームを作ってください：
- 入力項目: [項目1]、[項目2]、[項目3]
- バリデーション: [必須チェック、文字数制限など]
- 送信後の動作: [何をするか]

具体的な記入例：

以下の入力フォームを作ってください：
- 入力項目: 氏名（テキスト）、メールアドレス（email）、問い合わせ種別（プルダウン: 一般/技術/料金）、内容（テキストエリア）
- バリデーション: 全項目必須、メールは形式チェック、内容は10文字以上
- エラー表示: 各項目の直下に赤文字でメッセージ表示
- 送信後の動作: 「送信しました」のモーダルを表示し、3秒後にトップページへ遷移

良い結果が出るコツ： バリデーションルールとエラーの表示方法を具体的に書く。「適切にバリデーション」では、AIと自分の想定がズレやすい。

---

6. API連携

使用場面： 外部サービスのデータを取得して表示するとき。天気、ニュース、為替、地図など。

[API名]のAPIを使って[機能]を実装してください。
- エンドポイント: [URL]
- 認証: [APIキー/OAuth]
- 取得したいデータ: [フィールド名]
- 表示方法: [カード/テーブル/グラフ]

具体的な記入例：

OpenWeatherMapのAPIを使って天気表示ウィジェットを実装してください。
- エンドポイント: https://api.openweathermap.org/data/2.5/weather
- 認証: APIキー（環境変数 WEATHER_API_KEY から取得）
- 取得したいデータ: 都市名、気温、天気アイコン、湿度、風速
- 表示方法: カード形式で、天気アイコンを大きく表示
- 更新: 30分ごとに自動リフレッシュ

---

修正・改善系

7. バグ修正

使用場面： エラーが出たとき。バイブコーディングで最も頻繁に使うパターン。開発中は何度もお世話になる。

以下のエラーが出ています。修正してください：
[エラーメッセージ全文]

期待する動作: [どう動くべきか]
実際の動作: [何が起きているか]

具体的な記入例：

以下のエラーが出ています。修正してください：
TypeError: Cannot read properties of undefined (reading 'map')
  at PostList (src/components/PostList.tsx:12:18)

期待する動作: 記事一覧がカード形式で表示される
実際の動作: 画面が真っ白になり、コンソールに上記エラーが出る
発生条件: 記事が0件のときに発生する（1件以上あるときは正常）

良い結果が出るコツ： エラーメッセージは省略せず全文コピペする。「エラーが出る」だけでは、AIはエスパーできない。発生条件（いつ起きるか、いつ起きないか）も書くと、原因特定が格段に速くなる。

---

8. デザイン改善

使用場面： 機能は動いているがデザインがイマイチなとき。バイブコーディング初期は「まず動かす」を優先するため、デザイン改善は後回しになりがち。

[ファイルパス]のデザインを改善してください：
- 現在: [現状の説明]
- 希望: [どうしたいか]
- 参考: [参考サイトURL]（あれば）

具体的な記入例：

src/pages/index.astroのデザインを改善してください：
- 現在: 白背景にテキストが並んでいるだけで素っ気ない
- 希望: モダンなメディアサイト風。カードにホバーエフェクト、セクション間に余白、ヒーロー画像を追加
- 参考: https://example.com のトップページのレイアウトに近づけたい
- 制約: 既存のTailwindクラスを使用、新しいCSSファイルは追加しない

---

9. パフォーマンス改善

使用場面： ページの読み込みが遅い、スクロールがカクつくなど、表示速度に問題があるとき。

このページの読み込みが遅いです。改善してください：
- 画像の最適化
- 不要なJSの削除
- CSSの最小化
- 具体的な問題: [計測結果や体感]

具体的な記入例：

トップページの読み込みが遅いです（Lighthouse スコア: Performance 45点）。改善してください：
- 画像の最適化（現在PNGで合計8MB → WebPに変換、遅延読み込み）
- 不要なJSの削除（使っていないアニメーションライブラリがある）
- CSSの最小化
- フォントの読み込み最適化（Google Fontsのdisplay=swap）
目標: Lighthouseスコア80点以上

---

10. リファクタリング

使用場面： コードが複雑になりすぎて読みにくくなったとき。機能追加を重ねた後に整理するのが典型パターン。

[ファイルパス]のコードを整理してください：
- 重複しているコードをまとめる
- 変数名をわかりやすくする
- コメントを追加する
機能は変えないでください。

具体的な記入例：

src/utils/api.tsのコードを整理してください：
- fetchUserData、fetchPostData、fetchCommentDataの3関数で、エラーハンドリングが重複している → 共通関数に切り出す
- 変数名 d, r, res などを data, response のようにわかりやすくする
- 各関数にJSDocコメントを追加する
- マジックナンバー（3000, 5など）を定数に切り出す
機能は変えないでください。テストが通ることを確認してください。

---

コンテンツ系

11. 記事生成

使用場面： ブログ記事やドキュメントを書くとき。構成を先に決めてから本文を書かせると品質が安定する。

以下のテーマで記事を書いてください：
- テーマ: [テーマ]
- ターゲット: [誰向け]
- 文体: [です/ます調 or だ/である調]
- 文字数: 約[数字]文字
- 構成: [見出しの案]

具体的な記入例：

以下のテーマで記事を書いてください：
- テーマ: 初心者向けGit入門
- ターゲット: プログラミング未経験でバイブコーディングを始めた人
- 文体: です/ます調
- 文字数: 約5,000文字
- 構成: 
  1. Gitとは何か（なぜ必要か）
  2. 最低限覚える3コマンド（add, commit, push）
  3. GitHubとの連携方法
  4. よくあるトラブルと解決法
  5. FAQ
- 注意: 専門用語は使うたびに簡単に説明を入れる

---

12. SEO最適化

使用場面： 記事を公開した後、検索流入を増やしたいとき。既存記事の改善に使う。

[ファイルパス]の記事をSEO最適化してください：
- 狙うキーワード: [キーワード]
- タイトルタグ、meta descriptionを改善
- 見出し構造（h2, h3）を最適化
- 内部リンクを追加

具体的な記入例：

src/content/posts/vibe-coding-intro.mdxの記事をSEO最適化してください：
- 狙うキーワード: 「バイブコーディング 始め方」「バイブコーディング 入門」
- タイトルタグ: キーワードを前半に配置、32文字以内
- meta description: 120文字以内、行動を促す文末
- 見出し構造: h2にキーワードを自然に含める
- 内部リンク: 関連する他の記事へのリンクを本文中に3箇所以上入れる
- 画像alt属性: すべての画像にキーワードを含むaltを設定

---

調査・分析系

13. 技術調査

使用場面： 新しいライブラリやサービスを導入するか検討するとき。自分で調べる前にAIに概要をまとめてもらうと効率的。

[技術名]について調査してください：
- 何ができるか
- メリット・デメリット
- 料金体系
- 競合との比較
- 自分のプロジェクトで使えるか

具体的な記入例：

Supabaseについて調査してください：
- 何ができるか（データベース、認証、ストレージなど）
- メリット・デメリット（特にFirebaseとの比較）
- 料金体系（無料枠の制限、有料プランの開始価格）
- 競合との比較（Firebase, PlanetScale, Neon）
- 自分のプロジェクトで使えるか：Astro製ブログサイトにユーザーコメント機能を追加したい
テーブル形式で比較してください。

---

14. コードレビュー

使用場面： 機能が完成した後、本番公開前の最終チェック。一人で開発しているときはAIにレビューしてもらうのが有効。

[ファイルパス]をレビューしてください：
1. バグがないか
2. セキュリティの問題がないか
3. パフォーマンスの問題がないか
4. 改善提案

具体的な記入例：

src/pages/api/contact.tsをレビューしてください：
1. バグがないか（エッジケース、null/undefinedの考慮）
2. セキュリティの問題がないか（XSS, CSRF, SQLインジェクション）
3. パフォーマンスの問題がないか（N+1クエリ、メモリリークなど）
4. エラーハンドリングは適切か
5. 改善提案（コード構成、命名、型定義）
問題があれば修正コードも一緒に提示してください。

---

デプロイ・運用系

15. Git操作

使用場面： 変更をコミットするとき。バイブコーディングでは、AIにコミットメッセージを書いてもらうのが自然。

今の変更をgit commitしてください。
メッセージは日本語で、何を変更したか具体的に書いてください。

具体的な記入例：

今の変更をgit commitしてください。
メッセージは日本語で、以下のルールに従ってください：
- 1行目: 変更の要約（50文字以内）
- 2行目: 空行
- 3行目以降: 変更内容の詳細（箇条書き）
新規ファイルはgit addしてからcommitしてください。

---

16. デプロイ設定

使用場面： 作ったサイトを公開するとき。Cloudflare Pages、Vercel、Netlifyなどが代表的。

このプロジェクトをCloudflare Pagesにデプロイする設定をしてください：
- GitHubリポジトリの作成
- Cloudflare Pagesの接続
- 環境変数の設定

具体的な記入例：

このプロジェクトをCloudflare Pagesにデプロイする設定をしてください：
- GitHubリポジトリ名: my-blog
- ビルドコマンド: npm run build
- 出力ディレクトリ: dist
- 環境変数: NODE_VERSION=20
- カスタムドメイン: example.com（DNS設定手順も教えて）
- デプロイフック: mainブランチへのpushで自動デプロイ

---

応用パターン

17. 段階的構築

使用場面： 大きな機能を一度に作ると不具合の原因特定が難しくなるため、小さく分割して進めるとき。初心者ほどこのパターンを使うべき。

まず[機能1]だけ作ってください。
動作確認してから次の機能を追加します。

具体的な記入例：

ECサイトのカート機能を段階的に作ります。
まず「商品一覧の表示」だけ作ってください。
- ダミーデータ5件をカード形式で表示
- 各カードに商品名、価格、画像を表示
動作確認してから、次に「カートに追加」ボタンを実装します。

---

18. 複数案の比較

使用場面： 実装方法に迷っているとき。AIに複数の選択肢を出してもらい、メリデメを比較してから決める。

[目的]を達成する方法を3つ提案してください。
それぞれのメリット・デメリットも教えてください。

具体的な記入例：

ブログにコメント機能を追加する方法を3つ提案してください。
それぞれについて以下を教えてください：
- 実装の難易度（初心者でもできるか）
- 月額コスト
- メリット・デメリット
- おすすめの人
テーブル形式で比較してください。

---

19. 既存コード理解

使用場面： 他人が書いたコード、またはしばらく触っていなかった自分のコードを理解するとき。修正の前に必ずこのパターンで全体像を把握する。

まずこのプロジェクトの全体構成を把握してください。
その上で以下を教えてください：
- ファイル構成と各ファイルの役割
- データの流れ
- 変更する場合に影響が出そうな箇所

具体的な記入例：

まずこのプロジェクトの全体構成を把握してください。
その上で以下を教えてください：
- ファイル構成と各ファイルの役割（ツリー形式で表示）
- ページ間のルーティング構造
- データの流れ（API → コンポーネント → 表示）
- 使われているライブラリとそのバージョン
- 変更する場合に影響が出そうな箇所

この後、ヘッダーのデザインを変更する予定です。
その影響範囲も合わせて教えてください。

---

20. トラブルシューティング

使用場面： エラーメッセージが出ない不具合（表示がおかしい、ボタンが反応しないなど）や、原因不明の問題を調査するとき。パターン#7（バグ修正）より詳しい情報が必要な場合に使う。

[症状]が発生しています。
- いつから: [タイミング]
- 再現手順: [操作手順]
- 環境: [OS, ブラウザ, Node.jsバージョン]
原因を調査して修正してください。

具体的な記入例：

お問い合わせフォームの送信ボタンを押しても何も起きません。
- いつから: 昨日のデプロイ後から
- 再現手順: 1)フォームに全項目入力 → 2)送信ボタンクリック → 3)何も反応しない
- 環境: macOS, Chrome 124, Node.js 20.11
- エラー: コンソールにエラーは出ていない
- 関連する変更: 昨日contact.tsのバリデーション処理を変更した
原因を調査して修正してください。変更内容を説明してから実行してください。

---

パターンの選び方フローチャート

どのパターンを使えばいいか迷ったら、以下の流れで判断しよう。

何をしたい？
│
├── 新しく作りたい
│   ├── サイト全体 → #1 新規サイト作成
│   ├── 画面の一部 → #2 コンポーネント追加
│   ├── データ管理 → #4 CRUD機能
│   ├── 入力画面 → #5 フォーム作成
│   └── 外部データ表示 → #6 API連携
│
├── 直したい・改善したい
│   ├── エラーが出る → #7 バグ修正
│   ├── 見た目が悪い → #8 デザイン改善
│   ├── 表示が遅い → #9 パフォーマンス改善
│   ├── コードが汚い → #10 リファクタリング
│   └── スマホで崩れる → #3 レスポンシブ修正
│
├── コンテンツを作りたい
│   ├── 記事を書く → #11 記事生成
│   └── 検索対策 → #12 SEO最適化
│
├── 調べたい
│   ├── 技術の比較 → #13 技術調査
│   └── コードの品質 → #14 コードレビュー
│
├── 公開・運用したい
│   ├── 変更を保存 → #15 Git操作
│   └── サイト公開 → #16 デプロイ設定
│
└── 進め方に迷っている
    ├── 大きい機能 → #17 段階的構築
    ├── 方法が複数 → #18 複数案の比較
    ├── コードが読めない → #19 既存コード理解
    └── 原因不明の不具合 → #20 トラブルシューティング

---

パターン同士の組み合わせ方

パターンは単体で使うだけでなく、組み合わせることで効果を発揮する。よくある組み合わせを紹介する。

組み合わせ1：新規プロジェクト立ち上げ

組み合わせ2：バグ対応フロー

組み合わせ3：機能追加フロー（推奨）

---

CLAUDE.mdへの転記方法

よく使うパターンは、プロジェクトのルートにあるCLAUDE.mdに書いておくと、AIが自動的に読み込んでくれる。毎回プロンプトにコピペする手間が省ける。

転記の手順

1. この記事から、自分がよく使うパターンを3〜5個選ぶ
2. [角括弧]の部分を自分のプロジェクトに合わせて埋める
3. CLAUDE.mdにセクションを作って貼り付ける

CLAUDE.mdへの記載例

# プロンプトルール

## コンポーネント追加時のルール
- 新しいコンポーネントはsrc/components/に配置
- Propsは必ずTypeScript型定義する
- 既存のTailwindクラスに合わせる
- 作成後にsrc/pages/のどこかで使用例を追加

## バグ修正時のルール
- エラーメッセージ全文を確認してから修正する
- 修正前に原因を説明してから実行する
- 修正後にテストが通ることを確認する

## コミットルール
- 日本語でメッセージを書く
- 1行目は50文字以内
- 1機能ごとにコミットする

---

よくある質問（FAQ）

Q1. テンプレートをそのまま使うのと、自分の言葉で書くのとどちらがいい？

最初はテンプレートをそのままコピペして[角括弧]を埋めるだけで十分。慣れてきたら自分の言葉でアレンジしよう。重要なのは必要な情報が漏れなく含まれていることであり、表現の自然さは二の次。テンプレートを使えば、「あの情報を書き忘れた」という事態を防げる。

Q2. プロンプトが長すぎるとAIの精度が落ちる？

いいえ、むしろ逆。情報が不足しているプロンプトのほうが、AIが「推測」で補完するため精度が落ちる。テンプレートの項目をすべて埋めた結果プロンプトが長くなるのは問題ない。ただし、関係のない情報を大量に書くのは避けよう。「必要十分」がベストバランス。

Q3. 1つのプロンプトで複数のパターンを混ぜてもいい？

可能だが、推奨しない。たとえば「新規サイト作成 + デプロイ設定」を1回のプロンプトで頼むと、AIの出力が長くなりすぎてミスが増える。1プロンプト1パターンを基本にして、段階的に進めるほうが確実。パターン#17（段階的構築）の考え方をベースにしよう。

Q4. テンプレートにない作業を頼みたいときは？

この20パターンは代表例であり、すべてを網羅しているわけではない。テンプレートにない場合は、以下の3点を意識して自分でプロンプトを書けばOK。

1. 何をしたいか（目的）
2. 現在の状態（前提条件）
3. 完了条件（何ができたら成功か）

この3つが揃っていれば、テンプレートがなくても良い結果が出る。繰り返し使うようなら、自分でテンプレート化してCLAUDE.mdに追加しよう。

Q5. パターンを使っても意図通りの結果にならないときは？

以下の順番で確認してみよう。

1. 情報不足がないか：[角括弧]を埋め忘れていないか、具体性が足りていないか
2. 曖昧な表現がないか：「いい感じに」「適切に」ではなく、具体的な数値や基準を書く
3. スコープが広すぎないか：1回で頼む量を減らして段階的に進める
4. フィードバックを返す：1回で完璧を求めず、「ここは良いがここを変えて」と追加指示を出す

AIとのやりとりは「1回で完成」ではなく「キャッチボール」。2〜3往復で仕上げる前提でいると、ストレスなく進められる。

Q6. 英語で書いたほうが精度は高い？

Claude Code等の最新AIは日本語でも十分な精度が出る。無理に英語で書く必要はない。ただし、技術用語（コンポーネント名、CSS プロパティ名、APIエンドポイントなど）は英語のまま書くほうが正確。「レスポンシブ」を「画面サイズ対応」と言い換えるとかえって伝わりにくくなることもある。

Q7. CLAUDE.mdに全パターンを書くべき？

全部書くとCLAUDE.mdが長くなりすぎる。自分のプロジェクトでよく使う3〜5パターンだけを、プロジェクト固有の情報で埋めた状態で書いておくのがベスト。プロジェクトごとに使うパターンは異なるので、それぞれのCLAUDE.mdに最適化しよう。

---

まとめ

プロンプトのパターンを「型」として持つことで、AIへの指示品質が安定し、開発スピードが上がる。この記事で紹介した20パターンのうち、まずはTop5（#1, #7, #4, #17, #19）から使い始めてみよう。

慣れてきたら自分の頻出パターンをCLAUDE.mdに転記して、プロジェクト専用にカスタマイズしていく。「毎回同じことを書いている」と感じたら、それがテンプレート化のサインだ。