AIコードプロンプト事例15選｜AIコーディング効率を高める実践プロンプト集

2026年05月29日

 

スラッグ

 

メタディスクリプション

 

キーワード

 

0. はじめに

AIコードプロンプトとは、生成AIに対してコード生成、修正、テスト作成、レビュー、リファクタリング、ドキュメント生成などを依頼するための指示文です。AIコーディングでは、同じAIツールを使っていても、プロンプトの書き方によって出力品質が大きく変わります。たとえば、「ログイン機能を作ってください」とだけ入力した場合、AIは一般的なログイン処理を推測して生成します。しかし、使用言語、フレームワーク、認証方式、入力検証、エラーハンドリング、セキュリティ、テスト方針まで指定した場合、より実務に近いコードが生成されやすくなります。

プロンプト設計が重要なのは、AIが開発者の意図を自動で完全に理解するわけではないからです。AIは入力された情報をもとにコードを生成しますが、プロジェクト固有の設計ルール、ディレクトリ構成、命名規則、セキュリティ基準、レビュー方針までは、明示しなければ反映されにくい場合があります。そのため、AIコードプロンプトは単なる質問文ではなく、AIへ渡す小さな設計書として考える必要があります。

Copilot、Claude、ChatGPT、CursorのようなAI開発支援ツールは、コード補完だけでなく、設計相談、実装案作成、テスト生成、セキュリティレビュー、ドキュメント作成にも活用できます。ただし、AIが生成したコードをそのまま採用するのではなく、人間が目的を整理し、制約を伝え、生成結果をレビューすることが重要です。本記事では、AIコードプロンプトの基本から、REST API、React、SQL、単体テスト、リファクタリング、セキュリティ、エラーハンドリング、README生成、AIレビュー、エージェント型コーディングまで、実践で使えるプロンプト事例を体系的に解説します。

1. AIコードプロンプトとは？

AIコードプロンプトとは、AIに対して「どのようなコードを、どの技術で、どの制約のもとで、どの形式で出力してほしいか」を伝える文章です。人間同士の開発でも、仕様が曖昧なまま実装を始めると、期待と違う成果物が生まれやすくなります。AIコーディングでも同じで、プロンプトが曖昧であれば、AIは一般的な推測によってコードを生成します。その結果、動くけれど保守しにくいコード、既存設計に合わないコード、セキュリティ要件が不足したコードが出力される可能性があります。

AIコードプロンプトは、単なる命令文ではなく、AIとの開発コミュニケーションの中心です。プロンプトの中に、開発目的、技術スタック、入力と出力、制約条件、禁止事項、期待するコード構造、エラー処理、テスト方針を含めることで、AIはより現場に近いコードを生成しやすくなります。AIコーディングを安定して使うには、プロンプトを感覚で書くのではなく、設計情報を整理してから書くことが重要です。

観点内容AIコーディングでの意味
目的何を作りたいか出力の方向性を決める
文脈既存コードや設計方針プロジェクトに合うコードへ近づける
制約技術・品質・禁止事項使えない実装を避ける
出力形式コードのみ、説明付き、差分形式などレビューしやすくする
品質基準保守性、可読性、テスト容易性長期運用に耐えるコードへ近づける

1.1 AIへコード生成指示を出す文章

AIへコード生成指示を出す文章とは、実装したい機能をAIに伝えるための具体的な依頼文です。たとえば、「ユーザー登録APIを作ってください」という短い指示でもAIはコードを生成できますが、そのままだと使用言語、認証方式、バリデーション、エラー処理、データベース設計、レスポンス形式が曖昧です。実務で使えるコードを得るには、どのような環境で使うのか、どのような要件を満たすべきかを明確にする必要があります。

良いコード生成指示は、AIに作業の範囲を明確に伝えます。たとえば、TypeScriptを使う、Express.jsでAPIを作る、Zodでバリデーションする、bcryptでパスワードをハッシュ化する、Prismaでデータベース操作を行う、エラー時にはHTTPステータスを適切に返す、といった条件を指定します。こうすることで、AIは単なるサンプルコードではなく、プロジェクトへ組み込みやすいコードを生成しやすくなります。

1.2 文脈をAIへ伝える手段

AIコードプロンプトは、文脈をAIへ伝える手段でもあります。文脈とは、既存コード、設計思想、命名規則、ディレクトリ構成、利用しているライブラリ、エラーハンドリング方針、テスト方針など、コード生成に必要な背景情報です。AIは文脈が不足していると、一般的な実装を出力しますが、その一般的な実装が自分のプロジェクトに合うとは限りません。

たとえば、既存プロジェクトがコントローラー層、サービス層、リポジトリ層に分かれているのに、AIがすべての処理を1つのルートハンドラーに書いてしまうと、プロジェクトの設計と合わなくなります。文脈として「コントローラーではリクエスト処理だけを行い、ビジネスロジックはサービス層に分離してください」と指定すれば、AIはより既存設計に沿ったコードを出力しやすくなります。

1.3 AIコーディングの中心技術

AIコーディングの中心技術としてのプロンプトは、AIに作業内容を伝えるだけでなく、出力品質を制御する役割を持ちます。AIコーディングでは、コード補完、関数生成、テスト生成、リファクタリング、セキュリティレビュー、ドキュメント作成など、さまざまな作業をAIへ依頼できます。しかし、どの作業でも、プロンプトが曖昧であれば出力も曖昧になります。

プロンプト設計がうまい開発者は、AIに対して「何を作るか」だけでなく、「なぜ作るか」「どのように作るか」「どのような品質を求めるか」を伝えます。これにより、AIは単純なコード生成ツールではなく、設計補助、品質改善、レビュー支援のパートナーとして機能します。AI時代の開発では、プロンプトを書く力も開発能力の一部になります。

1.4 AIペアプログラミングの基盤

AIペアプログラミングとは、AIを開発パートナーのように使い、実装、レビュー、修正、改善を対話的に進める開発スタイルです。このとき、プロンプトはAIとの会話の基盤になります。人間のペアプログラミングでも、相手に目的や制約を説明しながら進める必要があります。AIとのペアプログラミングでも同じで、文脈を共有しなければ、AIは適切な提案を出しにくくなります。

AIペアプログラミングでは、最初から完璧なコードを出させるよりも、段階的に改善する使い方が有効です。まず要件を整理させ、次に実装案を作らせ、さらにテストを生成し、最後にレビューとリファクタリングを行う流れです。このように段階を分けることで、AIの出力を人間が確認しやすくなり、品質も安定します。

2. プロンプト設計で重要なポイント

プロンプト設計で重要なのは、AIに必要な情報を過不足なく渡すことです。使用言語、フレームワーク、入出力、制約条件、品質基準、出力形式を明示すると、出力の精度が上がりやすくなります。逆に、これらが曖昧だと、AIは一般的なサンプルコードを生成しやすくなり、実務では修正が多くなります。

特にコード生成では、技術スタックの指定が重要です。同じログインフォームでも、Reactだけで作るのか、Next.js App Routerで作るのか、Tailwind CSSを使うのか、React Hook Formを使うのかによって実装は大きく変わります。また、保守性、セキュリティ、テスト容易性を求める場合は、それも明示する必要があります。AIは暗黙の要件を完全に理解するわけではないため、重要な条件はプロンプトに書くべきです。

設計ポイント書くべき内容期待できる効果
使用言語TypeScript、Python、Goなど型や文法のズレを防ぐ
フレームワークNext.js、Express、Djangoなど実装構造を合わせる
入出力引数、戻り値、APIレスポンス仕様と違うコードを減らす
制約条件セキュリティ、性能、保守性実務品質に近づける
出力形式コードのみ、説明付き、差分形式使いやすい回答にする

2.1 使用言語を明示する

使用言語を明示することは、AIコードプロンプトの基本です。AIは多くのプログラミング言語に対応できますが、言語を指定しないと、文脈から推測したり、一般的な言語で回答したりする場合があります。TypeScriptで書いてほしいのにJavaScriptで出力される、Pythonで型ヒント付きにしてほしいのに簡易スクリプトになる、といったズレが起きやすくなります。

また、同じ言語でもバージョンや書き方の方針を指定すると、さらに実務に近い出力になります。たとえば、TypeScriptならstrict mode前提、Pythonなら型ヒントと例外処理を含める、JavaならSpring Boot前提、Goならcontextを受け取る設計にする、などです。使用言語を明示することは、AIに出力の土台を決めさせる重要な条件です。

2.2 フレームワークを指定する

フレームワークを指定することで、AIはプロジェクトに合った実装スタイルを選びやすくなります。たとえば、React、Next.js、Vue、Express、NestJS、Django、FastAPI、Spring Bootなど、フレームワークごとにファイル構成、責務分離、ルーティング、状態管理、エラーハンドリングの考え方が異なります。フレームワーク指定がないと、AIは汎用的なコードを生成しやすくなります。

実務では、フレームワークだけでなく、利用している周辺ライブラリも指定すると効果的です。React Hook Form、Zod、Prisma、TanStack Query、Tailwind CSS、Jest、Vitestなどを指定すれば、AIはよりプロジェクトに組み込みやすいコードを出しやすくなります。フレームワーク指定は、コードの形だけでなく、開発体験や保守性にも影響します。

2.3 入出力を定義する

入出力を定義することは、AIに仕様を正確に伝えるうえで非常に重要です。関数生成であれば、引数の型、戻り値、エラー時の扱いを明示します。API生成であれば、リクエスト本文、レスポンス形式、HTTPステータス、バリデーションエラーの形式を指定します。入出力が曖昧だと、AIは勝手に仕様を補完してしまうため、期待と違うコードが出力される可能性があります。

入出力を定義すると、生成後のテストもしやすくなります。たとえば、「入力が空の場合は400を返す」「存在しないIDの場合は404を返す」「成功時は201と作成済みデータを返す」と書けば、AIは実装とテストの両方で条件を反映しやすくなります。AIコードプロンプトでは、仕様を自然言語で書くだけでなく、入力例と出力例を入れるとさらに精度が上がります。

2.4 制約条件を書く

制約条件を書くことで、AIの出力を実務品質に近づけられます。制約条件には、セキュリティ、パフォーマンス、保守性、可読性、テスト容易性、依存ライブラリの制限、禁止事項などが含まれます。たとえば、「SQLインジェクションを防ぐ」「副作用を関数内に閉じ込めない」「any型を使わない」「既存のサービス層を利用する」「同期処理ではなく非同期処理で書く」といった条件です。

制約条件がない場合、AIは動くことを優先したコードを出すことがあります。しかし、実務では「動く」だけでは不十分です。将来変更しやすいか、チームが理解しやすいか、安全に運用できるかが重要です。プロンプトに制約条件を書くことで、AIへ品質基準を伝えられます。

3. プロンプト記述フォーマット

プロンプト記述フォーマットを決めておくと、AIコーディングの出力が安定します。毎回思いつきで指示を書くと、必要な情報が抜けたり、出力形式がばらついたりします。役割、目的、技術スタック、要件、制約条件、出力形式をテンプレート化しておくことで、AIへ伝えるべき内容を漏れにくくできます。

特にチーム開発では、プロンプト記述フォーマットを共有すると効果的です。開発者ごとにAIへの依頼方法が違うと、生成コードの品質もばらつきます。共通フォーマットを使えば、AIへの依頼内容が標準化され、レビューもしやすくなります。AIコーディングを個人の勘に頼らず、開発プロセスとして運用するためには、プロンプトの型を持つことが重要です。

3.1 基本フォーマット

基本フォーマットでは、まずAIに役割を与え、次に目的を明確にし、技術スタック、要件、制約条件、出力形式を指定します。役割を指定することで、AIは回答の視点を合わせやすくなります。たとえば、「シニアソフトウェアエンジニア」「セキュリティレビュー担当」「テスト設計者」「アーキテクト」など、求める視点に応じて役割を変えると出力も変わります。

以下のフォーマットは、コード生成だけでなく、レビュー、リファクタリング、ドキュメント生成にも応用できます。重要なのは、AIに「何を作るか」だけでなく、「どの条件で」「どの品質で」「どの形式で」出してほしいかを伝えることです。

役割:
あなたはシニアソフトウェアエンジニアです。

目的:
○○機能を実装してください。

技術スタック:
- TypeScript
- Next.js
- Prisma

要件:
- バリデーションを入れる
- エラーハンドリングを行う
- 保守性を重視する
- 既存のディレクトリ構成に合わせる

制約:
- any型を使わない
- 秘密情報をコードに直接書かない
- ビジネスロジックをUI層に書かない

出力形式:
- コードのみ
- 必要なコメント付き
- ファイルごとに分けて出力

 

＊注記: この基本フォーマットは、AIへ作業の前提条件をまとめて渡すためのテンプレートです。実装時は、技術スタックや制約をプロジェクトに合わせて具体化し、既存のファイル構成、命名規則、エラーハンドリング方針も追加すると、生成コードをそのままレビューしやすくなります。

3.2 実務向けに拡張したフォーマット

実務では、単にコードを生成するだけでなく、レビューしやすい出力にすることが重要です。そのため、AIへ「変更対象ファイル」「既存コードとの接続方法」「テスト方針」「失敗時の挙動」も指定すると効果的です。これにより、AIは単発のサンプルではなく、実際のプロジェクトに統合しやすいコードを生成しやすくなります。

また、出力形式で「まず設計方針を短く説明し、その後コードを出す」「差分形式で出す」「テストも同時に出す」などを指定すると、レビューの負担が減ります。AIコーディングでは、出力内容だけでなく、出力の読みやすさも品質の一部です。

役割:
あなたは既存プロジェクトを壊さずに機能追加するシニア開発者です。

背景:
既存プロジェクトはコントローラー層・サービス層・リポジトリ層の3層構造です。
コントローラーにビジネスロジックを書かない方針です。

目的:
ユーザー登録機能を追加してください。

対象ファイル:
- src/controllers/userController.ts
- src/services/userService.ts
- src/repositories/userRepository.ts
- src/routes/userRoutes.ts

要件:
- メールアドレス重複チェック
- パスワードハッシュ化
- 入力バリデーション
- 成功時は201を返す
- 失敗時は適切なHTTPステータスを返す

出力形式:
1. 実装方針
2. ファイル別コード
3. テスト観点
4. 注意点

 

＊注記: このフォーマットは、既存プロジェクトへ機能を追加する場面に向いています。AIに対象ファイルと責務分離ルールを伝えることで、すべての処理を1ファイルに詰め込む出力を避けやすくなります。実際に使う場合は、既存の型定義やエラークラス名も追加するとさらに精度が上がります。

4. REST API生成プロンプト

REST API生成プロンプトでは、エンドポイント、HTTPメソッド、リクエスト形式、レスポンス形式、認証、バリデーション、エラーハンドリングを明確に書くことが重要です。APIはフロントエンドや外部サービスと接続されるため、入出力仕様が曖昧だと後から修正が増えます。AIにAPIを作らせる場合は、単に「登録APIを作る」ではなく、どの条件でどのステータスを返すかまで指定するべきです。

また、REST APIではセキュリティ要件も重要です。パスワードを平文保存しない、SQLインジェクションを防ぐ、認証情報をログに出さない、入力値を検証する、エラー時に内部情報を返さないといった条件をプロンプトに含めることで、より安全なコードが生成されやすくなります。

4.1 API実装プロンプト例

このプロンプトは、Express.jsでユーザー登録APIを作る例です。ポイントは、技術スタック、セキュリティ要件、レスポンス仕様、責務分離を明確にしていることです。AIにAPI生成を依頼するときは、コントローラー、サービス、リポジトリのどこに何を書くかも指定すると、保守しやすい構造になりやすくなります。

Express.jsを使ってユーザー登録APIを作成してください。

技術条件:
- TypeScript使用
- Express.js使用
- Prismaを使ってDBへ保存
- bcryptでパスワードをハッシュ化

要件:
- メールアドレス、パスワード、ユーザー名を受け取る
- メールアドレス形式をバリデーションする
- パスワードは8文字以上にする
- メールアドレスが既に存在する場合は409を返す
- 登録成功時は201を返す
- パスワードはレスポンスに含めない

設計条件:
- コントローラー層、サービス層、リポジトリ層に分離する
- コントローラーにビジネスロジックを書かない
- エラー処理を共通化しやすい形にする
- テストしやすい構造にする

出力形式:
- ファイルごとにコードを分けて出力
- 必要な型定義も含める

 

＊注記: このプロンプトは、APIの仕様と設計方針を同時に伝えるためのものです。実装時は、既存プロジェクトのエラークラス、Prisma Schema、ルーティング規則に合わせて条件を追加してください。特に認証や個人情報を扱うAPIでは、AIが出力したコードを必ずセキュリティ観点でレビューする必要があります。

4.2 期待されるコード形式

期待されるコード形式は、1つのルートハンドラーにすべてを書くのではなく、ルーティング、コントローラー、サービス、リポジトリを分ける形です。以下は簡略化した例ですが、実務ではバリデーションスキーマ、エラークラス、レスポンス型を分離するとさらに保守しやすくなります。

 

router.post("/register", async (req, res, next) => {
  try {
    const result = await userController.register(req.body)
    return res.status(201).json(result)
  } catch (error) {
    next(error)
  }
})

 

＊注記: このコードはルート層を薄く保つ例です。実装時は、req.bodyを直接サービス層へ渡すのではなく、コントローラーまたはミドルウェアでバリデーションを行い、型安全なDTOへ変換してからサービス層へ渡すと安全です。また、next(error)を使う場合は、Expressの共通エラーハンドリングミドルウェアを必ず用意してください。

4.3 実務用の追加プロンプト例

API生成では、最初のコード生成後に追加指示を出して品質を上げることが重要です。たとえば、最初の出力にバリデーションやテストが不足していた場合、以下のように改善プロンプトを続けると実務向けに近づきます。

上記のユーザー登録APIを改善してください。

追加条件:
- Zodでリクエスト本文を検証する
- パスワードをレスポンスに含めない型を定義する
- 例外をAppErrorクラスで統一する
- Jestでサービス層の単体テストを作成する
- メールアドレス重複時、DBエラー時、入力不正時のテストケースを含める

 

＊注記: この追加プロンプトは、AIが最初に生成したコードを実務品質へ近づけるために使います。AIコードは一回で完成させるより、生成、レビュー、改善、テスト追加の順番で育てる方が安定します。特にAPIでは、正常系だけでなく異常系と境界値のテストを必ず追加してください。

5. Reactコンポーネント生成プロンプト

Reactコンポーネント生成プロンプトでは、UIの見た目だけでなく、状態管理、バリデーション、アクセシビリティ、再利用性、レスポンシブ対応を明示することが重要です。AIに「ログインフォームを作って」とだけ依頼すると、シンプルなinputとbuttonだけのコードが出力されることがあります。しかし実務では、エラー表示、送信中状態、入力検証、キーボード操作、画面幅への対応が必要です。

Reactでは、コンポーネントの責務分離も重要です。UIだけを担当する表示用コンポーネント、フォーム状態を管理するコンテナ、API通信を行うカスタムフックなどに分けると保守しやすくなります。AIへReactコンポーネントを生成させる場合は、どの粒度でコンポーネントを分けるか、どのライブラリを使うか、Propsの型をどうするかを指定すると品質が上がります。

5.1 UI生成プロンプト例

このプロンプトは、React + TypeScriptでログインフォームを作る例です。Tailwind CSS、フォームバリデーション、レスポンシブ対応、再利用性を指定しています。さらに実務では、React Hook FormやZodを指定すると、フォーム処理が安定しやすくなります。

React + TypeScriptでログインフォームを作成してください。

技術条件:
- React
- TypeScript
- Tailwind CSS
- React Hook Form
- Zod

要件:
- メールアドレスとパスワードを入力できる
- メールアドレス形式を検証する
- パスワード未入力時にエラーを表示する
- 送信中はボタンを無効化する
- APIエラーをフォーム上部に表示する
- レスポンシブ対応する

設計条件:
- Propsで送信処理を受け取る
- UIとAPI通信を分離する
- 再利用しやすいコンポーネント構造にする
- アクセシビリティを考慮する

出力形式:
- LoginForm.tsxのコード
- 型定義を含める
- 必要な補足説明を短く書く

 

＊注記: このプロンプトは、単なる見た目の生成ではなく、フォームとして実務利用できる構造を狙っています。実装時は、API通信をコンポーネント内部へ直接書かず、親コンポーネントまたはカスタムフックへ分離するとテストしやすくなります。アクセシビリティのためにlabel、aria属性、エラーメッセージの関連付けも確認してください。

5.2 期待されるコード形式

以下は期待されるコンポーネント構造の簡略例です。実際には、Zod Schema、型定義、エラー表示、送信中状態、アクセシビリティ対応をより丁寧に実装する必要があります。

 

type LoginFormValues = {
  email: string
  password: string
}

type LoginFormProps = {
  onSubmit: (values: LoginFormValues) => Promise<void>
}

export const LoginForm = ({ onSubmit }: LoginFormProps) => {
  return (
    <form>
      <label htmlFor="email">メールアドレス</label>
      <input id="email" type="email" />

      <label htmlFor="password">パスワード</label>
      <input id="password" type="password" />

      <button type="submit">ログイン</button>
    </form>
  )
}

 

＊注記: このコードはコンポーネントの最小構造を示す例です。実装時は、React Hook Formのregister、handleSubmit、formState.errorsを使い、入力エラーをUIに表示してください。また、onSubmitをPropsで受け取ることで、UIコンポーネントとAPI通信を分離でき、テストや再利用がしやすくなります。

5.3 改善プロンプト例

Reactコンポーネントは、最初の生成後にUI品質やアクセシビリティを高める追加プロンプトを使うと効果的です。特にAIは見た目を優先して、キーボード操作やエラー読み上げを省略する場合があるため、明示的に改善させることが重要です。

上記のLoginFormを改善してください。

改善条件:
- aria-invalidとaria-describedbyを追加する
- エラー表示をスクリーンリーダーで認識しやすくする
- 入力欄、ボタン、エラー表示の責務を整理する
- Tailwind CSSのclassNameを読みやすく整理する
- Storybookで表示確認しやすいProps設計にする

 

＊注記: このプロンプトは、生成されたUIをアクセシビリティと保守性の観点から改善するために使います。実装時は、見た目だけでなく、フォームエラーが支援技術に正しく伝わるかを確認してください。コンポーネントのclassNameが長くなりすぎる場合は、共通コンポーネントやvariant設計を検討すると保守しやすくなります。

6. SQL生成プロンプト

SQL生成プロンプトでは、取得したいデータ、対象テーブル、条件、ソート、集計、インデックス、パフォーマンス要件を明確に書くことが重要です。AIはSQLを生成できますが、テーブル構造やデータ量を知らないままでは、パフォーマンスの悪いクエリを生成することがあります。実務では、単に正しい結果を返すだけでなく、実行計画やインデックスも意識する必要があります。

SQLでは、データ量が増えたときの性能が重要です。小さな開発DBでは問題なく動くクエリでも、本番環境では遅くなる場合があります。そのため、AIへSQLを依頼するときは、対象テーブルのカラム、想定データ量、WHERE句、ORDER BY、JOIN条件、必要なインデックスも伝えると効果的です。

6.1 SQL最適化プロンプト例

このプロンプトは、PostgreSQLで有効ユーザーを取得する例です。単にSELECT文を作るだけでなく、インデックス最適化を考慮するよう指定しています。SQL生成では、取得条件とソート条件を明確にし、必要なカラムだけを取得するよう指示すると実務向けになります。

以下の条件を満たすPostgreSQLクエリを書いてください。

対象:
- usersテーブル

取得条件:
- 有効ユーザーのみ取得
- created_at降順で取得
- 最新100件のみ取得

カラム:
- id
- name
- email
- created_at

性能条件:
- インデックス最適化を考慮
- SELECT * は使わない
- 大量データでも遅くなりにくい形にする

出力:
- SQLクエリ
- 推奨インデックス
- なぜそのインデックスが有効かの説明

 

＊注記: このプロンプトでは、取得カラム、件数制限、インデックスまで指定しているため、AIが実務に近いSQLを生成しやすくなります。実装時は、実際のデータ量や実行計画をEXPLAIN ANALYZEで確認し、AIが提案したインデックスをそのまま採用せず、更新コストも含めて判断してください。

6.2 期待されるコード形式

以下は期待されるSQLの例です。SELECT * を避け、必要なカラムだけを取得し、LIMITを指定することで、無駄なデータ取得を減らしています。

 

SELECT
  id,
  name,
  email,
  created_at
FROM users
WHERE active = true
ORDER BY created_at DESC
LIMIT 100;

 

＊注記: このSQLは読みやすい基本形ですが、性能はテーブルサイズやインデックス構成に依存します。実装時は、activeとcreated_atを組み合わせた複合インデックスを検討し、実際の検索条件に合っているかを確認してください。取得カラムが増える場合は、インデックスのみで取得できるかどうかも検討対象になります。

6.3 インデックス提案プロンプト例

SQLでは、AIにクエリだけでなくインデックスも提案させると便利です。ただし、インデックスは増やしすぎると書き込み性能やストレージに影響するため、提案をそのまま採用せず、実行計画で確認する必要があります。

以下のSQLに対して、PostgreSQLで有効なインデックスを提案してください。

SQL:
SELECT id, name, email, created_at
FROM users
WHERE active = true
ORDER BY created_at DESC
LIMIT 100;

条件:
- usersテーブルは500万件以上
- active = true のユーザーは全体の約30%
- created_atで最新順に取得する頻度が高い
- 書き込みも多いためインデックスを増やしすぎない

 

＊注記: このプロンプトは、クエリの背景情報をAIに渡してインデックスを検討させる例です。実装時は、AIの提案をもとに実際のEXPLAIN ANALYZEを確認し、読み取り性能と書き込みコストのバランスを見て採用してください。インデックスは追加すれば必ず速くなるものではないため注意が必要です。

7. 単体テスト生成プロンプト

単体テスト生成プロンプトでは、対象関数、期待する挙動、正常系、異常系、境界値、モック対象を明確にすることが重要です。AIに「テストを書いて」とだけ依頼すると、正常系だけの浅いテストが出力されることがあります。実務では、異常系や境界値を含めて、コードの仕様を守るためのテストを作る必要があります。

テスト生成では、AIに実装コードを渡すだけでなく、仕様も渡すことが大切です。実装に合わせたテストだけを生成すると、間違った実装を正しいものとして固定してしまう可能性があります。仕様ベースでテストを書かせることで、AIが実装の問題を見つける補助にもなります。

7.1 テスト生成プロンプト例

このプロンプトは、Jestで単体テストを生成する例です。正常系、異常系、境界値、モック利用を明示することで、テストの抜け漏れを減らします。特に価格計算、権限判定、日付処理のようなロジックでは、境界値テストが重要です。

以下の関数に対するJest単体テストを書いてください。

対象:
calculatePrice(basePrice: number, discountRate: number): number

仕様:
- basePriceが0以上であること
- discountRateは0〜100の範囲
- 割引後価格を返す
- 小数点以下は四捨五入する
- 不正な入力ではErrorをthrowする

テスト条件:
- 正常系
- 異常系
- 境界値
- 小数点を含むケース
- discountRateが0の場合
- discountRateが100の場合

出力形式:
- Jestのdescribe / it形式
- テストケース名を分かりやすくする

 

＊注記: このプロンプトでは、関数の仕様を明確に書いてからテスト生成を依頼しています。実装時は、AIが生成したテストが実装依存になりすぎていないか確認してください。特に、仕様ではなく現在のバグを正としてテストしてしまう場合があるため、期待値は人間が必ず確認する必要があります。

7.2 期待されるコード形式

以下は期待されるJestテストの形式です。実務では、正常系だけでなく、不正入力や境界値も含めてテストケースを増やします。

 

describe("calculatePrice", () => {
  it("有効な値が渡された場合、割引後価格を返す", () => {
    expect(calculatePrice(1000, 10)).toBe(900)
  })

  it("割引率が0の場合、元の価格を返す", () => {
    expect(calculatePrice(1000, 0)).toBe(1000)
  })

  it("割引率が100を超える場合、エラーをthrowする", () => {
    expect(() => calculatePrice(1000, 101)).toThrow()
  })
})

 

＊注記: このコードは単体テストの基本形です。実装時は、エラー型やエラーメッセージまで検証するかをチーム方針に合わせて決めてください。また、金額計算では丸め処理がバグになりやすいため、小数点を含むケースや境界値を追加することが重要です。

7.3 モック利用プロンプト例

外部APIやDBに依存する関数では、モックを使って単体テストを書く必要があります。AIにモック対象を明示しないと、実DBや実APIにアクセスするテストを生成してしまう場合があります。

以下のUserServiceに対する単体テストを書いてください。

対象:
UserService.createUser(input)

依存:
- UserRepository
- PasswordHasher
- Logger

条件:
- UserRepositoryはモックする
- PasswordHasherはモックする
- 実DBには接続しない
- メールアドレス重複時はConflictErrorをthrowする
- 正常時は作成済みUserを返す
- パスワードは返却しない

出力形式:
- Jest
- beforeEachでモックを初期化
- 正常系と異常系を分ける

 

＊注記: このプロンプトは、依存関係をモックしてサービス層を単体テストするためのものです。実装時は、モックが実際の依存の振る舞いとズレすぎないように注意してください。リポジトリやハッシュ化処理のインターフェースを定義しておくと、AIがテストしやすい構造を生成しやすくなります。

8. リファクタリングプロンプト

リファクタリングプロンプトでは、単に「きれいにして」と依頼するのではなく、どの観点で改善したいかを明確にする必要があります。可読性を上げたいのか、責務分離したいのか、重複を減らしたいのか、テストしやすくしたいのかによって、AIの改善方針は変わります。目的が曖昧だと、AIが過剰に抽象化したり、逆に表面的な命名変更だけで終わったりする場合があります。

リファクタリングでは、動作を変えないことが重要です。AIに依頼するときは、「外部仕様を変えない」「既存テストが通る前提」「変更点を説明する」「差分が分かるようにする」といった条件を指定すると安全です。また、AIのリファクタリング案をそのまま採用するのではなく、人間が責務、依存関係、テスト影響を確認する必要があります。

8.1 改善指示プロンプト例

このプロンプトは、既存コードをSOLID原則、重複削減、可読性、保守性の観点で改善する例です。リファクタリングでは、変更目的と禁止事項をセットで書くことが重要です。

以下のコードをリファクタリングしてください。

目的:
- 可読性を向上させる
- 重複コードを削減する
- 責務分離を行う
- テストしやすい構造にする

条件:
- 外部仕様は変更しない
- 関数の入出力は維持する
- 既存テストが通る前提にする
- 過剰な抽象化は避ける
- SOLID原則を意識する

出力形式:
1. 問題点の整理
2. 改善方針
3. リファクタリング後のコード
4. 変更によるメリット
5. 追加すべきテスト

 

＊注記: このプロンプトは、AIにいきなりコードだけを書き換えさせるのではなく、問題点と改善方針を先に説明させる構成です。実装時は、AIの改善案が既存仕様を変えていないか必ず確認してください。リファクタリング後は、既存テストと追加テストを実行し、意図しない挙動変更がないか確認する必要があります。

8.2 期待される改善内容

AIにリファクタリングを依頼した場合、期待される改善内容は、関数分割、責務分離、命名改善、依存性注入、条件分岐の整理などです。ただし、すべてを一度に行うと変更範囲が大きくなるため、段階的に進めることが望ましいです。

期待される改善内容:
- 長すぎる関数を分割する
- コントローラーからビジネスロジックをサービス層へ移す
- 重複しているバリデーションを共通化する
- 曖昧な変数名を具体的にする
- 依存性注入を導入する
- 条件分岐を早期returnで簡潔にする

 

＊注記: この改善内容は、AIにリファクタリングの方向性を明確に伝えるための例です。実装時は、すべての改善を一度に行わず、まず責務分離、次に命名改善、最後にテスト追加のように段階化すると安全です。変更が大きい場合は、プルリクエストを分けてレビューしやすくしてください。

8.3 段階的リファクタリングプロンプト例

大きなコードを一度に書き換えるのではなく、段階的にリファクタリング計画を作らせるプロンプトも有効です。これはレガシーコードやAI生成コードの整理に向いています。

以下のコードを一度に書き換えず、段階的にリファクタリングする計画を作成してください。

条件:
- 既存仕様を変えない
- 1ステップごとにテスト可能にする
- 変更範囲を小さくする
- 依存関係を壊さない
- 最終的に責務分離された構造にする

出力形式:
- Stepごとの目的
- 変更対象
- リスク
- 確認すべきテスト
- 完了条件

 

＊注記: このプロンプトは、複雑なコードを安全に改善するために使います。実装時は、AIが出した計画をそのまま実行するのではなく、既存テストの有無やチームのレビュー体制に合わせて順番を調整してください。段階的な変更は、バグ混入時に原因を特定しやすくする効果があります。

9. セキュリティ改善プロンプト

セキュリティ改善プロンプトでは、AIに確認してほしい脆弱性の種類を明確に書くことが重要です。SQLインジェクション、クロスサイトスクリプティング、クロスサイトリクエストフォージェリ、認証・認可、秘密情報漏洩、ログ出力、依存関係、入力検証など、観点を指定するとレビューの精度が上がります。単に「セキュリティを見て」と依頼するだけでは、一般的な指摘に留まりやすくなります。

セキュリティレビューでは、AIを補助として使うことは有効ですが、AIレビューだけで安全性を保証することはできません。AIが指摘しなかった問題が残る可能性もあります。そのため、AIの出力は一次チェックとして使い、人間のレビュー、静的解析、脆弱性スキャン、テストと組み合わせる必要があります。

9.1 セキュリティレビュープロンプト例

このプロンプトは、コードのセキュリティ問題をレビューするための例です。確認項目を明確にすることで、AIが表面的な可読性レビューではなく、セキュリティ観点に集中しやすくなります。

以下のコードのセキュリティ問題をレビューしてください。

確認項目:
- SQLインジェクション
- クロスサイトスクリプティング
- クロスサイトリクエストフォージェリ
- 認証漏れ
- 認可漏れ
- 秘密情報のログ出力
- 入力バリデーション不足
- エラー情報の過剰露出

出力形式:
1. 問題点
2. 影響範囲
3. 改善案
4. 修正コード例
5. 追加すべきテスト

 

＊注記: このプロンプトは、セキュリティレビューの観点を固定するために使います。実装時は、AIの指摘をそのまま信じるのではなく、実際の認証方式、権限設計、データベースアクセス方法、ログ運用に照らして確認してください。高リスク機能では、専門的なセキュリティレビューも必要です。

9.2 期待される出力形式

セキュリティレビューの出力は、問題点だけでなく、影響範囲と改善案があると実装に移しやすくなります。単に「危険です」と言われても対応しにくいため、どのコードが問題で、どう修正すべきかを明確にさせることが重要です。

問題点:
- SQLインジェクション脆弱性があります。
- ユーザー入力がSQL文字列へ直接埋め込まれています。

影響範囲:
- 攻撃者が任意のSQLを実行できる可能性があります。
- usersテーブルの情報漏洩や改ざんにつながる可能性があります。

改善案:
- プリペアドステートメントを利用してください。
- ORMの安全なクエリAPIを使用してください。
- 入力値のバリデーションを追加してください。

 

＊注記: この出力形式は、レビュー結果を開発タスクに変換しやすくするためのものです。実装時は、改善案をコードに反映した後、攻撃パターンを含むテストを追加してください。SQLインジェクション対策では、入力値のエスケープだけに頼らず、プリペアドステートメントやORMの安全なAPIを使うことが基本です。

9.3 修正コード生成プロンプト例

セキュリティ問題を見つけた後は、AIに修正コードを生成させることもできます。ただし、修正後も必ずレビューとテストが必要です。

上記で指摘されたSQLインジェクション脆弱性を修正してください。

条件:
- Prismaの安全なAPIを使う
- ユーザー入力をSQL文字列へ直接埋め込まない
- 入力値をZodで検証する
- エラー時に内部情報を返さない
- 修正後の単体テストも作成する

出力形式:
- 修正後コード
- 変更理由
- 追加テスト

 

＊注記: このプロンプトは、セキュリティレビュー後の修正作業に使います。実装時は、AIが生成した修正コードが本当に安全なAPIを使っているか確認してください。また、エラー時にスタックトレースやDB情報をレスポンスへ含めないようにすることも重要です。

10. エラーハンドリングプロンプト

エラーハンドリングプロンプトでは、例外発生時にどのようなレスポンスを返すか、どの情報をログに残すか、どの情報をユーザーに見せないかを明確にする必要があります。AIにエラーハンドリングを依頼すると、単純なtry-catchだけが追加されることがありますが、実務ではエラー分類、HTTPステータス、ログレベル、ユーザー向けメッセージ、内部向け情報の分離が重要です。

エラーハンドリングが不十分だと、障害時に原因調査が難しくなったり、内部情報がユーザーに漏れたりします。AIへ依頼する場合は、業務エラー、入力エラー、認証エラー、権限エラー、外部サービスエラー、予期しないエラーを分類するよう指示すると、より実用的な実装になります。

10.1 エラーハンドリング追加プロンプト

このプロンプトは、Node.jsコードへ適切なエラーハンドリングを追加する例です。try-catch、Logger、HTTPステータスを指定するだけでなく、エラー分類も含めると実務向けになります。

以下のNode.jsコードへ適切なエラーハンドリングを追加してください。

条件:
- try-catchを利用する
- Loggerを追加する
- HTTPステータスを整理する
- 入力エラーは400
- 認証エラーは401
- 権限エラーは403
- リソース未存在は404
- 予期しないエラーは500
- 内部エラー詳細をレスポンスに含めない

設計条件:
- AppErrorクラスを使う
- 共通エラーミドルウェアで処理する
- コントローラー内の重複try-catchを減らす
- テストしやすい構造にする

 

＊注記: このプロンプトは、場当たり的なtry-catchではなく、アプリ全体で統一されたエラー処理を作るために使います。実装時は、ユーザーに返すメッセージとログに残す詳細情報を分離してください。内部エラーのスタックトレースやDBエラー内容をAPIレスポンスに含めないことが重要です。

10.2 期待されるコード形式

以下は、サービス実行時のエラーを捕捉し、共通エラーハンドラーへ渡す簡略例です。実務では、コントローラーでtry-catchを繰り返すより、asyncHandlerを使って共通化することも検討できます。

 

try {
  const result = await service.create(input)
  return res.status(201).json(result)
} catch (error) {
  logger.error({
    message: "リソース作成に失敗しました",
    error,
  })

  return res.status(500).json({
    message: "サーバー内部でエラーが発生しました",
  })
}

 

＊注記: このコードは基本形ですが、すべてのコントローラーで同じtry-catchを書くと重複が増えます。実装時は、AppErrorと共通エラーミドルウェアを導入し、コントローラーではエラーをthrowまたはnextへ渡す形にすると保守しやすくなります。また、logger.errorに個人情報や秘密情報が含まれないよう注意してください。

10.3 共通エラーミドルウェア生成プロンプト例

大規模なAPIでは、エラーハンドリングをミドルウェアへ集約する方が保守しやすくなります。AIへ共通ミドルウェアを生成させる場合は、エラー型、レスポンス形式、ログ方針を明確にします。

Express.js用の共通エラーミドルウェアを作成してください。

条件:
- TypeScript使用
- AppErrorを処理する
- AppError以外は500として扱う
- エラーレスポンス形式を統一する
- 本番環境ではスタックトレースを返さない
- Loggerでエラー詳細を記録する
- 個人情報やパスワードをログに出さない

出力:
- AppErrorクラス
- errorHandlerミドルウェア
- 使用例

 

＊注記: このプロンプトは、アプリ全体のエラー処理を統一するためのものです。実装時は、環境変数でdevelopmentとproductionの出力を切り替え、productionでは内部詳細を返さないようにしてください。ログには調査に必要な情報を残しつつ、個人情報や認証情報を出さない設計が必要です。

11. ドキュメント生成プロンプト

ドキュメント生成プロンプトでは、読み手、目的、含める情報、出力形式を明確にする必要があります。AIにREADMEを生成させる場合でも、プロジェクト概要、セットアップ方法、使用技術、環境変数、ディレクトリ構成、API一覧、テスト方法、デプロイ方法、トラブルシューティングなど、何を含めるかを指定すると品質が上がります。

ドキュメントは、開発者のオンボーディングや保守性に大きく影響します。AIが生成したREADMEが見た目だけ整っていても、実際の手順と違っていると逆に混乱を招きます。そのため、AI生成後には、コマンド、パス、環境変数、API仕様が実際のプロジェクトと一致しているかを確認する必要があります。

11.1 README生成プロンプト例

このプロンプトは、プロジェクトのREADMEを生成する例です。READMEはプロジェクトの入口になるため、初めて参加する開発者が迷わずセットアップできる構成にすることが重要です。

以下のプロジェクトのREADMEを生成してください。

プロジェクト概要:
- AIメモ管理アプリ
- Next.js + TypeScript
- PostgreSQL
- Prisma
- Tailwind CSS

含める内容:
- プロジェクト概要
- 使用技術
- セットアップ方法
- 環境変数
- ディレクトリ構成
- 開発コマンド
- テスト方法
- API一覧
- よくあるエラーと対処法

出力条件:
- Markdown形式
- 初めて参加する開発者にも分かる説明
- コマンドはコピーしやすく書く
- 不明な情報は仮定せずTODOとして残す

 

＊注記: このプロンプトは、READMEをオンボーディング資料として使うことを前提にしています。実装時は、AIが推測で書いた環境変数名やコマンドが実際のpackage.jsonや.env.exampleと一致しているか必ず確認してください。不明な情報を無理に埋めさせず、TODOとして残す指定が重要です。

11.2 期待される出力形式

以下はREADMEの基本構成例です。実際には、プロジェクト固有の環境変数、DBセットアップ、マイグレーション手順、テスト実行方法を正確に記載します。

 

# プロジェクト名

## 概要

このプロジェクトは、AIを活用したノート管理アプリケーションです。

## セットアップ

npm install
npm run dev

## 環境変数

DATABASE_URL=
NEXTAUTH_SECRET=

 

＊注記: このREADME例は基本構造を示しています。実装時は、実際のプロジェクト名、起動コマンド、環境変数、DB初期化手順を確認してから反映してください。README内のコマンドは便利ですが、誤ったコマンドを書くと新規開発者が詰まりやすいため、必ずローカルで検証することが大切です。

11.3 APIドキュメント生成プロンプト例

API一覧をAIに作らせる場合は、エンドポイント、メソッド、認証要否、リクエスト、レスポンス、エラーを明示するように依頼します。APIドキュメントはフロントエンドや外部連携の基盤になるため、曖昧さを残さないことが重要です。

以下のAPI仕様をもとに、開発者向けAPIドキュメントをMarkdownで作成してください。

対象API:
- POST /api/auth/register
- POST /api/auth/login
- GET /api/users/me

含める内容:
- エンドポイント
- HTTPメソッド
- 認証要否
- リクエスト本文
- レスポンス例
- エラーレスポンス
- 注意点

条件:
- フロントエンド開発者が実装しやすい形式
- JSON例を含める
- HTTPステータスを明確にする

 

＊注記: このプロンプトは、APIを利用する側が迷わないドキュメントを作るためのものです。実装時は、実際のAPIレスポンスとドキュメントが一致しているか確認してください。API仕様が変わった場合は、ドキュメントも同時に更新する運用が必要です。

12. AIレビュープロンプト

AIレビュープロンプトでは、レビュー観点を明確にすることが重要です。AIに「このコードをレビューして」とだけ依頼すると、一般的な指摘や表面的な改善に留まることがあります。可読性、保守性、パフォーマンス、セキュリティ、テスト容易性、設計整合性など、観点を指定することで、レビューの質が上がります。

AIレビューは、人間のレビューを置き換えるものではなく、事前チェックや観点整理として使うのが効果的です。AIにレビューさせることで、明らかな重複、命名の曖昧さ、例外処理不足、テスト不足を早く見つけられます。ただし、業務文脈やプロジェクト固有の判断は人間が行う必要があります。

12.1 コード品質レビュープロンプト

このプロンプトは、可読性、保守性、パフォーマンス、セキュリティの観点からコードをレビューする例です。レビュー対象の目的や前提も伝えると、より具体的な指摘が得られます。

以下のコードをレビューしてください。

前提:
- TypeScriptのAPI実装です
- 既存プロジェクトはコントローラー層・サービス層・リポジトリ層の構造です
- 保守性とセキュリティを重視しています

レビュー観点:
- 可読性
- 保守性
- パフォーマンス
- セキュリティ
- テスト容易性
- 既存設計との整合性

出力形式:
1. 良い点
2. 問題点
3. 優先度の高い改善
4. 修正案
5. 追加すべきテスト

 

＊注記: このプロンプトは、AIをコードレビュー補助として使うためのものです。実装時は、AIの指摘をそのまま採用せず、プロジェクトの設計方針や業務要件に照らして判断してください。AIレビューは一次チェックに向いていますが、最終判断は人間のレビューで行う必要があります。

12.2 期待される出力形式

レビュー結果は、問題点だけでなく、優先度と修正案があると実装に移しやすくなります。AIに優先度を付けさせることで、すぐ直すべき問題と後で改善できる問題を分けやすくなります。

改善点:
- 関数責務が大きすぎる
- 命名が曖昧
- エラー処理がコントローラーごとに重複している
- 入力バリデーションがサービス層に混在している

推奨:
- サービス層を責務ごとに分離する
- 変数名を具体化する
- 共通エラーミドルウェアを導入する
- Zod Schemaをリクエスト層に分離する

 

＊注記: この出力形式は、レビュー結果をタスク化しやすくするための例です。実装時は、すべての改善を一度に行うのではなく、優先度の高いセキュリティ問題や仕様不整合から対応してください。命名改善や構造整理は、テストを確認しながら段階的に進めると安全です。

12.3 プルリクエストレビュープロンプト例

プルリクエスト単位でAIレビューを使う場合は、変更目的、差分の概要、確認してほしい観点を明確にします。差分レビューでは、AIに全体を書き換えさせるのではなく、変更点のリスクを見つけさせる使い方が向いています。

以下のプルリクエスト差分をレビューしてください。

変更目的:
- ユーザー登録APIを追加する

確認してほしい観点:
- 仕様漏れ
- セキュリティリスク
- エラーハンドリング不足
- テスト不足
- 既存設計との不整合
- 不要な依存関係の追加

出力形式:
- 重大
- 高
- 中
- 提案
の4段階で指摘してください。

 

＊注記: このプロンプトは、プルリクエストレビューをAIに補助させるためのものです。実装時は、AIが指摘した重大・高の項目を優先的に確認し、人間レビューで最終判断してください。プルリクエスト差分が大きすぎるとAIも人間もレビューしにくいため、変更単位を小さく保つことが重要です。

13. エージェント型コーディングプロンプト

エージェント型コーディングプロンプトとは、AIに単発のコード生成ではなく、タスク分解、設計、実装、テスト、修正まで段階的に進めさせるためのプロンプトです。エージェント型コーディングでは、AIが複数ステップを提案したり、作業順序を整理したり、必要なファイルを分解したりします。複雑な機能を作るときは、いきなりコードを書かせるより、まず作業計画を作らせる方が安全です。

エージェント型コーディングでは、AIの自律性が高くなるため、制御も重要になります。AIにすべて任せるのではなく、各ステップごとに人間が確認できるようにする必要があります。プロンプトには、作業を小さく分ける、各ステップに完了条件を付ける、テスト可能な単位にする、既存コードを壊さない、といった条件を含めるべきです。

13.1 タスク分解プロンプト

このプロンプトは、ECサイト開発を段階的に分解する例です。大きな機能をいきなり実装するのではなく、DB設計、API設計、フロントエンド実装、テスト作成に分けています。これにより、AIの出力を人間がレビューしやすくなります。

ECサイトを開発します。

以下を段階的に分解してください:
- DB設計
- API設計
- フロントエンド実装
- テスト作成
- 認証設計
- 注文処理
- 決済連携
- 管理画面

条件:
- 1ステップごとに成果物を明確にする
- 各ステップに完了条件を付ける
- 依存関係を整理する
- セキュリティ上の注意点も含める
- いきなり全コードを書かず、まず計画を出す

出力形式:
- ステップ
- 目的
- 作業内容
- 成果物
- リスク
- 完了条件

 

＊注記: このプロンプトは、AIを設計補助として使うためのものです。実装時は、AIが出したステップをそのまま進めるのではなく、プロジェクト規模、チーム人数、既存コード、納期に合わせて調整してください。特に決済や認証は高リスク領域なので、専門的なレビューを入れるべきです。

13.2 期待される出力形式

エージェント型コーディングでは、出力がステップごとに整理されていることが重要です。各ステップの成果物と完了条件が明確であれば、人間が確認しながら進められます。

ステップ1:
DB Schema作成

目的:
商品、ユーザー、注文、決済情報の関係を定義する

成果物:
- Prisma Schema
- ER図
- マイグレーション

完了条件:
- 商品と注文の関係が表現できている
- ユーザーごとの注文履歴を取得できる

ステップ2:
認証API実装

目的:
ユーザー登録、ログイン、ログアウトを提供する

成果物:
- 登録API
- ログインAPI
- 認証ミドルウェア

完了条件:
- JWT認証が動作する
- 未認証ユーザーが保護APIへアクセスできない

 

＊注記: この出力形式は、AIの作業計画を人間がレビューしやすくするためのものです。実装時は、各ステップをそのままIssueやTaskへ分解できます。完了条件が曖昧なステップは後で品質問題になりやすいため、テスト可能な条件へ書き換えてから実装に進むことが重要です。

13.3 実装ステップ生成プロンプト例

計画を作った後は、1ステップずつ実装させるプロンプトを使います。一度に全ファイルを生成させるより、対象範囲を絞ることでレビューしやすくなります。

ステップ1のDB Schemaだけを実装してください。

条件:
- Prisma Schemaで書く
- User, Product, Order, OrderItemを定義する
- 金額はDecimalで扱う
- createdAt, updatedAtを含める
- 削除は物理削除ではなくstatusで管理する
- インデックスを考慮する

出力:
- schema.prisma
- 設計意図
- 注意点
- 追加で必要なマイグレーション確認項目

 

＊注記: このプロンプトは、エージェント型コーディングを小さな実装単位へ落とし込むためのものです。実装時は、AIが生成したSchemaをそのまま採用せず、実際の注文仕様、決済仕様、在庫管理、税計算に対応できるか確認してください。DB設計は後から変更コストが高いため、最初に丁寧にレビューする必要があります。

14. プロンプト品質を高めるコツ

プロンプト品質を高めるには、曖昧な指示を避け、技術スタックを明示し、出力形式を指定し、保守性要件を書くことが重要です。AIは、与えられた情報をもとに出力を作るため、プロンプトの情報量と構造が結果に大きく影響します。特にコード生成では、曖昧な依頼ほど修正コストが増えます。

良いプロンプトは、AIに自由に考えさせる部分と、守ってほしい制約を分けています。すべてを細かく指定しすぎると柔軟性が失われますが、重要な技術条件や品質条件を指定しないと、使いにくいコードになります。プロンプト設計では、目的、文脈、制約、出力形式のバランスが重要です。

14.1 曖昧な指示を避ける

曖昧な指示を避けることは、AIコードプロンプトの基本です。「いい感じに作って」「きれいにして」「安全にして」といった表現だけでは、AIは何を優先すべきか判断しにくくなります。開発者が求める「きれいなコード」が、短いコードなのか、責務分離されたコードなのか、命名が明確なコードなのか、テストしやすいコードなのかを具体化する必要があります。

曖昧さを減らすには、目的、対象、条件、禁止事項、出力形式を明確にします。たとえば、「ログイン機能を作って」ではなく、「Next.js App Routerで、メールアドレスとパスワードを使うログインフォームを作成し、Zodで入力検証し、APIエラーを表示し、Tailwind CSSでレスポンシブ対応してください」と書くと、AIの出力が安定しやすくなります。

悪い例:
ログイン機能をいい感じに作ってください。

良い例:
Next.js App Router + TypeScriptでログイン機能を作成してください。

条件:
- メールアドレスとパスワードでログインする
- Zodで入力バリデーションを行う
- APIエラーをフォーム上部に表示する
- 送信中はボタンを無効化する
- UIとAPI通信を分離する
- Tailwind CSSでレスポンシブ対応する

 

＊注記: このプロンプト例では、曖昧な「いい感じ」を具体的な実装条件へ分解しています。実装時は、プロジェクトで使用している認証ライブラリ、APIパス、エラー形式も追加してください。AIには暗黙の期待を伝えにくいため、重要な条件は必ず文章にすることが大切です。

14.2 技術スタックを明示する

技術スタックを明示すると、AIはプロジェクトに合う実装を生成しやすくなります。たとえば、同じAPI実装でも、Express、NestJS、Fastify、Next.js Route Handlerでは書き方が違います。また、データベース操作もPrisma、TypeORM、Drizzle、SQL直書きで大きく変わります。技術スタックを指定しないと、AIは一般的な実装を出すため、後から修正が必要になります。

技術スタックは、言語とフレームワークだけでなく、周辺ライブラリまで書くと効果的です。フォームならReact Hook Form、バリデーションならZod、テストならJestやVitest、スタイルならTailwind CSS、ORMならPrismaのように指定します。これにより、AIはチームの標準に近いコードを生成できます。

以下の技術スタックに合わせて実装してください。

言語:
- TypeScript

フロントエンド:
- React
- Next.js App Router
- Tailwind CSS
- React Hook Form
- Zod

バックエンド:
- Next.js Route Handler
- Prisma
- PostgreSQL

テスト:
- Jest
- React Testing Library

条件:
- any型を使わない
- 型安全性を重視する
- Server ComponentとClient Componentの責務を分ける

 

＊注記: このプロンプトは、技術スタックのズレを防ぐために使います。実装時は、プロジェクトで実際に導入済みのライブラリだけを指定してください。存在しないライブラリや未導入の技術を指定すると、AIが使えないコードを生成する可能性があります。

14.3 出力形式を指定する

出力形式を指定することで、AIの回答を使いやすくできます。コードだけが欲しい場合、説明付きが欲しい場合、ファイルごとに分けてほしい場合、差分形式で出してほしい場合など、用途に応じて指定します。出力形式を指定しないと、AIが長い説明を付けたり、逆に必要な説明を省いたりする場合があります。

実務では、レビューしやすい出力形式が重要です。たとえば、「まず設計方針を3行で説明し、その後ファイルごとにコードを出力し、最後にテスト観点を書く」と指定すれば、実装意図とコードを一緒に確認できます。AIを開発フローへ組み込むには、出力の読みやすさも設計する必要があります。

出力形式を以下に固定してください。

1. 実装方針
- 3〜5行で説明

2. 変更ファイル一覧
- ファイルパス
- 役割

3. コード
- ファイルごとに分ける
- TypeScriptで書く

4. テスト観点
- 正常系
- 異常系
- 境界値

5. 注意点
- セキュリティ
- 保守性
- 追加で確認すべきこと

 

＊注記: このプロンプトは、AIの出力をレビューしやすい形に整えるためのものです。実装時は、コードだけを急いで使うのではなく、実装方針と注意点も確認してください。AIが自分で書いた注意点に反するコードを出す場合もあるため、出力全体を人間がレビューする必要があります。

14.4 保守性要件を書く

保守性要件を書くことで、AIに「動けばよいコード」ではなく、長期的に扱いやすいコードを出させやすくなります。保守性には、責務分離、命名の明確さ、テスト容易性、依存関係の整理、過剰抽象化の回避、既存設計との整合性が含まれます。AIに保守性を求める場合は、具体的に何を守るべきかを書く必要があります。

たとえば、「保守性を重視してください」だけでは抽象的です。「コントローラーにビジネスロジックを書かない」「サービス層はリポジトリのインターフェースに依存する」「副作用を分離する」「関数は1つの責務にする」「テストしやすいように依存を注入する」と書くと、AIはより具体的に設計できます。

保守性を重視して実装してください。

具体的な条件:
- 1つの関数に複数の責務を持たせない
- コントローラーにビジネスロジックを書かない
- サービス層に業務ロジックを集約する
- リポジトリ層にDBアクセスを集約する
- 外部サービス依存はインターフェース化する
- 単体テストしやすいように依存性注入を使う
- 命名は処理内容が分かる具体名にする
- 過剰な抽象化は避ける

 

＊注記: このプロンプトは、保守性を抽象論ではなく実装条件へ落とし込むためのものです。実装時は、AIが生成した抽象化が本当に必要か確認してください。過剰にインターフェースやファクトリーを増やすと、逆に読みにくくなる場合があります。

14.5 段階的に改善するプロンプトを使う

AIコード生成では、一度で完成を狙うより、段階的に改善する方が品質が安定します。まず要件整理、次に設計案、次に実装、次にテスト、最後にレビューという順番にすると、人間が各段階で確認できます。複雑な機能を一回のプロンプトで全部作らせると、抜け漏れや設計崩れが起きやすくなります。

段階的なプロンプトは、エージェント型コーディングにもつながります。ただし、AIに完全自律で進めさせるのではなく、各ステップの完了条件を明確にし、人間が確認してから次へ進む構成にすることが重要です。

以下の機能を一度に実装せず、段階的に進めてください。

対象機能:
ユーザー認証機能

進め方:
ステップ1: 要件整理
ステップ2: DB設計
ステップ3: API設計
ステップ4: 実装
ステップ5: 単体テスト作成
ステップ6: セキュリティレビュー
ステップ7: リファクタリング

条件:
- 各ステップで成果物を明確にする
- 次ステップへ進む前に確認ポイントを書く
- 既存コードを壊さない
- 高リスク箇所を明示する

 

＊注記: このプロンプトは、複雑な機能を安全に開発するために使います。実装時は、AIが出したステップを人間が確認し、必要に応じて順番や範囲を調整してください。特に認証機能では、セキュリティレビューを最後だけでなく設計段階にも入れると安全です。

15. AIコードプロンプト活用で重要な考え方

AIコードプロンプトを活用するうえで重要なのは、プロンプトを単なる質問ではなく、設計情報を伝える文書として扱うことです。AIは、入力された情報をもとにコードを生成します。つまり、プロンプトの中に設計の質が反映されます。良いプロンプトは、目的、文脈、制約、品質基準、出力形式が明確であり、AIが迷わず実装方針を決められるようになっています。

AI時代では、開発者の役割が「コードを書く人」から「意図を設計し、AIの出力を評価する人」へ広がっています。AIに正確な指示を出す力、生成されたコードを読む力、問題点を見抜く力、改善プロンプトを出す力が重要になります。プロンプト設計は、AIコーディングの効率だけでなく、コード品質にも大きく影響します。

考え方内容実務での意味
プロンプトは設計書に近い要件と制約を整理して伝える出力品質が安定する
意図を正確に伝える曖昧な表現を避ける修正コストが下がる
人間の設計力が重要AI任せにしない保守性が上がる
プロンプト設計も開発能力AIとの協働力が必要開発効率が高まる

15.1 プロンプトは設計書に近い役割を持つ

プロンプトは、AIにとって小さな設計書に近い役割を持ちます。設計書が曖昧だと実装がぶれるのと同じように、プロンプトが曖昧だとAIの出力もぶれます。特に、複雑な機能やチーム開発で使うコードを生成する場合は、プロンプトの中で仕様、責務分離、データ構造、エラー処理、テスト方針を整理する必要があります。

プロンプトを設計書として扱うと、AIコーディングはより安定します。まず人間が要件を整理し、AIに実装案を出させ、その後レビューして改善する流れになります。これは、AIに丸投げする開発ではなく、人間が設計を主導し、AIが実装を補助する開発です。

以下の仕様をもとに、実装前の設計案を作成してください。

対象:
ユーザー通知機能

要件:
- ユーザーは通知一覧を取得できる
- 未読通知のみ取得できる
- 通知を既読にできる
- 管理者は全ユーザーへ通知を送信できる

設計してほしい内容:
- DB Schema
- API一覧
- サービス層の責務
- エラーケース
- テスト観点
- セキュリティ上の注意点

まだコードは書かず、まず設計案だけ出してください。

 

＊注記: このプロンプトは、いきなり実装させず、まず設計を整理するためのものです。実装時は、AIが出した設計案をレビューし、データ量、権限、通知配信方法、将来の拡張性を確認してからコード生成へ進んでください。設計段階でAIを使うと、実装後の手戻りを減らせます。

15.2 AIへ正確に意図を伝えることが重要

AIへ正確に意図を伝えることは、AIコーディングの品質を決める重要な要素です。AIは人間の頭の中にある暗黙の前提を読み取ることはできません。たとえば、「管理者向け画面」と書くだけでは、認証、権限、監査ログ、操作履歴、エラーハンドリングが必要かどうかはAIに伝わりにくいです。重要な意図は、プロンプトに明示する必要があります。

意図を正確に伝えるには、なぜその機能が必要なのか、誰が使うのか、どのような失敗を避けたいのかを含めると効果的です。AIは目的が分かると、単なるコード生成ではなく、実装方針や注意点も提案しやすくなります。

管理者向けのユーザー停止機能を実装してください。

目的:
不正利用が疑われるユーザーを管理者が一時停止できるようにするため。

利用者:
- 管理者のみ

重要な意図:
- 一般ユーザーはこの操作を実行できない
- 停止理由を必ず保存する
- 操作履歴を監査ログとして残す
- 停止されたユーザーはログインできない
- 誤操作を防ぐため確認処理を入れる

出力:
- API設計
- DB変更案
- 実装コード
- テスト観点

 

＊注記: このプロンプトは、機能の背景と意図をAIに伝える例です。実装時は、管理者権限の確認をフロントエンドだけでなくバックエンドでも必ず行ってください。また、監査ログは後から問題調査に必要になるため、誰が、いつ、誰を、なぜ停止したのかを保存する設計にしてください。

15.3 人間の設計力が出力品質を決める

AIの出力品質は、人間の設計力に大きく左右されます。AIはコードを速く生成できますが、何を作るべきか、どの責務に分けるべきか、どのリスクを避けるべきかは、人間が判断する必要があります。設計が曖昧なままAIにコードを書かせると、動くけれど保守しにくいコードになりやすくなります。

人間の設計力とは、要件を整理し、責務を分け、データの流れを考え、失敗ケースを想定し、テスト可能な構造にする力です。AI時代では、手でコードを書く量は減るかもしれませんが、設計を考える力の重要性はむしろ高まります。AIに良いコードを書かせるには、人間が良い指示を出す必要があります。

以下の機能を実装する前に、設計レビューをしてください。

機能:
チームメンバー招待機能

現在の案:
- 管理者がメールアドレスを入力する
- 招待メールを送る
- ユーザーがリンクを開く
- アカウントを作成する

レビュー観点:
- 責務分離
- セキュリティ
- 招待リンクの有効期限
- 重複招待
- 権限管理
- テスト容易性
- 将来の拡張性

出力:
- 設計上の問題点
- 改善案
- 実装前に決めるべきこと

 

＊注記: このプロンプトは、実装前に設計リスクを洗い出すためのものです。実装時は、招待トークンの有効期限、再送制御、既存ユーザー招待時の挙動、権限付与のタイミングを明確にしてください。AIにコードを書かせる前に設計レビューを行うことで、後から大きな修正が発生しにくくなります。

15.4 AI時代ではプロンプト設計も開発能力になる

AI時代では、プロンプト設計も開発能力の一部になります。コードを書く能力だけでなく、AIへ正確に指示を出し、出力を評価し、改善プロンプトを出し、必要なテストやレビューへつなげる能力が求められます。AIを使えば誰でもコードを生成できますが、実務で使える品質にするには、開発者の判断力が必要です。

プロンプト設計が上手い開発者は、AIを単なるコード自動生成ツールとしてではなく、設計相談、レビュー補助、テスト設計、ドキュメント作成、リファクタリング支援に活用できます。これにより、反復作業を減らし、より本質的な設計や品質改善に集中できます。

以下のAI生成コードを、実務で採用できる品質に近づけるための改善プロンプトを作成してください。

対象:
- 生成済みのAPIコード
- テストなし
- エラーハンドリングが簡易的
- バリデーションが不足
- サービス層とリポジトリ層が分離されていない

作成してほしいプロンプト:
- リファクタリング用プロンプト
- テスト追加用プロンプト
- セキュリティレビュー用プロンプト
- ドキュメント生成用プロンプト

 

＊注記: このプロンプトは、AIに直接コードを書かせるのではなく、AI活用の次の指示を作らせる例です。実装時は、生成済みコードを一度に修正するのではなく、リファクタリング、テスト追加、セキュリティ確認、ドキュメント化の順に分けると安全です。プロンプトを改善する力は、AI時代の開発効率に直結します。

おわりに

AIコードプロンプトは、AIコーディングの基盤技術です。Copilot、Claude、ChatGPT、CursorのようなAI開発支援ツールを使う場合でも、出力品質はプロンプトの書き方に大きく左右されます。使用言語、フレームワーク、入出力、制約条件、出力形式、保守性要件を明確に伝えることで、AIはより実務に近いコードを生成しやすくなります。

AIコードプロンプトは、単なる命令文ではなく、設計情報をAIへ伝えるための小さな設計書です。曖昧なプロンプトでは、動くけれど保守しにくいコードや、プロジェクト構造に合わないコードが生成される可能性があります。一方で、目的、文脈、制約、品質基準を整理したプロンプトであれば、AIはコード生成だけでなく、レビュー、テスト、リファクタリング、ドキュメント作成まで強力に支援できます。

特に今後は、エージェント型コーディング向けのプロンプト設計がさらに重要になります。AIが単発のコード補完だけでなく、タスク分解、設計、実装、テスト、修正を段階的に支援するようになるほど、人間はAIへ正確に意図を伝え、各ステップを確認し、品質を管理する必要があります。AIに任せる範囲と人間が判断する範囲を分けることが、AI時代の開発では重要です。

AIコードプロンプト活用の本質は、AIに丸投げすることではありません。人間が設計意図を整理し、AIに具体的な指示を出し、生成されたコードをレビューし、必要に応じて改善することです。プロンプト品質がコード品質へ大きく影響するため、AI時代の開発者には、コードを書く力だけでなく、良いプロンプトを設計する力も求められます。

LINE Chat