【英語プロンプト対応】開発者がすぐ使えるAIプロンプト20選｜コーディングから設計レビューまで
「コードレビューに時間がかかる」「ドキュメントを書くのが億劫」「バグの原因調査で詰まる」——エンジニア・開発者が日々直面するこれらの悩み、AIプロンプトを使えば大幅に解消できます。この記事では、エンジニア・開発者がすぐに使えるAIプロンプト20選を、使い方の解説とセットで紹介します。日本語・英語どちらのプロンプトも収録しているので、用途に合わせて使い分けてください。
✅ この記事でわかること
- エンジニア・開発者の業務別おすすめAIプロンプト20選
- 日本語・英語プロンプトの使い分け方
- AIコーディングアシスタントの精度を上げるコツ
AIはコードを「書いてくれる」ツールですが、「何を作りたいか・何が問題かを正確に伝える力」がアウトプットの質を決めます。また、英語プロンプトは日本語より精度が高くなるケースが多いため、コーディング系のタスクは積極的に英語を使うのがおすすめです。
- 言語・環境を明示する：Python 3.11・React 18・Node.js 20など、バージョンまで書く
- コンテキストを渡す：既存コードをそのまま貼り付けてから指示を出す
- 期待する出力形式を指定する：「コードのみ」「説明付き」「テストコードも」など明記する
開発の中心となるコーディング業務をAIで加速するプロンプトです。英語プロンプトが特に効果を発揮します。
📋 プロンプト（コピーしてそのまま使えます）
Write a [LANGUAGE] function that does the following:
[DESCRIBE THE FUNCTION IN DETAIL]
Requirements:
– Language/Runtime: [e.g. Python 3.11 / Node.js 20 / TypeScript 5]
– Handle edge cases: [list edge cases]
– Include error handling
– Add inline comments for complex logic
– Follow [style guide, e.g. PEP8 / Airbnb]
Output: code only, no explanation unless asked.
「Output: code only」を入れることで、不要な説明文なしにコードだけが返ってきます。説明が必要なときは最後に「Explain the key decisions」と追加するのがおすすめです。
📋 プロンプト（コピーしてそのまま使えます）
1. Improve readability
2. Reduce duplication (DRY principle)
3. Improve performance where obvious
4. Follow [Python/JS/etc.] best practices
Do NOT change the external behavior or function signatures.
Flag any potential bugs you notice (but don’t fix them unless asked).
“`[language]
[paste your code here]
“`
Output format:
– Refactored code
– Bullet list of changes made
– Any bugs or risks flagged
「外部の振る舞いを変えるな」という制約が重要です。これを入れることで、AIが勝手に仕様を変えてしまうリスクを防げます。バグの発見も同時にやってもらうのがポイントです。
📋 プロンプト（コピーしてそのまま使えます）
**Environment:** [OS, runtime version, framework version]
**Expected behavior:**
[what should happen]
**Actual behavior:**
[what actually happens]
**Error message / Stack trace:**
“`
[paste error here]
“`
**Relevant code:**
“`[language]
[paste code here]
“`
Please:
1. Identify the most likely root cause
2. Explain why this causes the bug
3. Provide a fix
4. Suggest how to prevent this class of bug in the future
エラーメッセージ・スタックトレース・コードの3点セットを渡すのがコツです。「なぜ起きるか」と「今後の予防策」まで聞くことで、同じバグを繰り返さなくなります。
📋 プロンプト（コピーしてそのまま使えます）
Context: [brief description of what this code does]
“`[language]
[paste your code here]
“`
Review criteria:
– Correctness: logic errors, edge cases not handled
– Security: potential vulnerabilities (injection, auth issues, etc.)
– Performance: inefficiencies, N+1 queries, memory leaks
– Maintainability: readability, naming, structure
– Test coverage: what tests are missing?
Format your response as:
🔴 Critical issues (must fix)
🟡 Suggestions (should fix)
🟢 Positive notes (what’s done well)
🔴🟡🟢の3段階で優先度が明確になるので、レビュー結果をそのままPRのコメントに活用できます。本番コードのセルフレビューとして、PushやPR作成前の習慣にするのがおすすめです。
📋 プロンプト（コピーしてそのまま使えます）
**Task:** [Write a new query / Optimize the existing query below]
**Database:** [PostgreSQL 15 / MySQL 8 / SQLite / etc.]
**Schema (relevant tables):**
“`sql
[paste CREATE TABLE statements or describe the schema]
“`
**What I need:**
[describe what data you want to retrieve or what the query should do]
**Existing query (if optimizing):**
“`sql
[paste existing query]
“`
Please provide:
1. The SQL query
2. An explanation of the approach
3. Index suggestions if relevant
4. Any potential performance concerns for large datasets
スキーマ情報を渡すことで、実際のテーブル構造に合ったクエリを生成してくれます。インデックスの提案まで出してもらうことで、パフォーマンス改善にも活用できます。
📋 プロンプト（コピーしてそのまま使えます）
**Language/Flavor:** [JavaScript / Python / PCRE / etc.]
**Match:** [describe exactly what should match]
**Don’t match:** [describe what should NOT match]
**Examples:**
– Should match: [example1], [example2]
– Should NOT match: [example3], [example4]
Please provide:
1. The regex pattern
2. A breakdown explaining each part
3. A code snippet showing how to use it in [language]
正規表現は「書ける」人でも「読める」人が少ないため、AIに分解説明まで出させることでチーム内の理解共有にも使えます。
テストコードの作成は重要ですが手間がかかります。AIで自動化の第一歩を踏み出しましょう。
📋 プロンプト（コピーしてそのまま使えます）
**Testing framework:** [Jest / pytest / JUnit / RSpec / etc.]
**Language:** [JavaScript / Python / Java / Ruby / etc.]
**Code to test:**
“`[language]
[paste your function or class here]
“`
Test cases to cover:
– Happy path (normal expected inputs)
– Edge cases (empty, null, zero, max values)
– Error cases (invalid inputs, exceptions)
– Boundary conditions
Format: ready-to-run test file with descriptive test names.
Add a comment above each test explaining what it’s testing and why.
テストケースの網羅性をAIに任せることで、「思いつかなかったエッジケース」を拾えます。生成されたテストは必ず実行して、パスすることを確認してから使いましょう。
📋 プロンプト（コピーしてそのまま使えます）
以下の機能仕様をもとにテスト設計書を作成してください。
【機能名】○○
【機能の概要】○○
【対象ユーザー・権限】○○
【正常系の動作】○○
【異常系・エラーの仕様】○○
出力形式：
| No | テスト項目 | 前提条件 | 操作手順 | 期待結果 | 優先度 |
の表形式で出力してください。
カテゴリ：
– 正常系テスト
– 異常系テスト
– 境界値テスト
– 権限・セキュリティテスト
をそれぞれセクション分けして作成してください。
非エンジニアのQA担当やPMと共有する際は日本語の方が伝わりやすいです。表形式で出力されるので、そのままスプレッドシートやNotionに貼り付けて使えます。
📋 プロンプト（コピーしてそのまま使えます）
**Context:** [e.g. this handles user authentication / payment processing / file uploads]
**Language/Framework:** [e.g. Node.js + Express / Django / Rails]
“`[language]
[paste your code here]
“`
Check for (but not limited to):
– Injection vulnerabilities (SQL, NoSQL, command, LDAP)
– Authentication/authorization flaws
– Sensitive data exposure
– Input validation issues
– Insecure dependencies or configurations
– OWASP Top 10 issues relevant to this code
For each issue found:
– Severity: Critical / High / Medium / Low
– Description of the vulnerability
– Proof of concept (how it could be exploited)
– Recommended fix with code example
OWASP Top 10を参照軸として指定することで、業界標準の観点から網羅的にチェックしてくれます。ただしAIの指摘は完全ではないため、重要なコードは専門のセキュリティツールやレビューと併用しましょう。
📋 プロンプト（コピーしてそのまま使えます）
**Language:** [language]
**Context:** [e.g. this runs on every API request / processes 1M records daily]
**Current performance issue:** [e.g. takes 5s for 10k records, memory usage spikes]
“`[language]
[paste your code here]
“`
Please:
1. Identify performance bottlenecks (explain the time/space complexity)
2. Provide an optimized version
3. Explain each optimization and its expected impact
4. Suggest profiling tools or metrics to measure improvement
「どんな規模・頻度で動くか」というコンテキストを渡すと、最適化の方向性が変わります。理論的な改善案をAIに出させてから、実際にプロファイリングして効果を確認する流れが王道です。
後回しになりがちなドキュメント作成こそ、AIで一気に片付けましょう。
📋 プロンプト（コピーしてそのまま使えます）
**Language:** [Python / JavaScript / TypeScript / Java / etc.]
**Doc style:** [JSDoc / Google Style / NumPy / reStructuredText / etc.]
“`[language]
[paste your functions or classes here]
“`
For each function/class, include:
– Brief description (1 sentence)
– @param / Args: for each parameter (name, type, description)
– @returns / Returns: (type and description)
– @throws / Raises: (exceptions that may be thrown)
– @example / Example: (a short usage example)
Output: the original code with documentation comments added.
既存コードを渡すだけでJSDoc・Googleスタイルなどの形式でドキュメントが完成します。チームのドキュメント規約に合わせてスタイルを指定するのがポイントです。
📋 プロンプト（コピーしてそのまま使えます）
**Project name:** [name]
**What it does:** [brief description]
**Tech stack:** [languages, frameworks, databases]
**Target users:** [who will use this]
Sections to include:
– Project title + badges (build, license, version)
– Overview (2-3 sentences)
– Features (bullet list)
– Prerequisites
– Installation & setup (step-by-step)
– Usage (with code examples)
– Configuration (environment variables)
– API reference (if applicable)
– Contributing guidelines
– License
Write in [English / Japanese / both].
Use proper Markdown formatting.
プロジェクト情報を入力するだけで、OSS品質のREADMEが完成します。「Write in both」と指定すれば日英バイリンガルのREADMEも生成できます。
📋 プロンプト（コピーしてそのまま使えます）
**API overview:** [brief description of the API]
**Endpoints to document:**
1. Method: [GET/POST/PUT/DELETE]
Path: [/api/v1/users/{id}]
Description: [what this endpoint does]
Auth: [Bearer token / API Key / None]
Request body: [describe fields, types, required/optional]
Response (200): [describe response fields]
Error responses: [e.g. 400, 401, 404, 500]
Output: valid OpenAPI 3.0 YAML that can be imported into Swagger UI or Postman.
エンドポイントの仕様を自然言語で書くだけで、SwaggerやPostmanにそのまま読み込めるYAMLが生成されます。フロントエンドとの連携ドキュメントとして即活用できます。
📋 プロンプト（コピーしてそのまま使えます）
以下の情報をもとにADR（Architecture Decision Record）を作成してください。
【決定したこと】○○（例：データベースをMySQLからPostgreSQLに移行する）
【背景・きっかけ】○○
【検討した選択肢】○○（例：MySQL継続 / PostgreSQL移行 / NoSQL導入）
【決定の理由】○○
【トレードオフ・デメリット】○○
【影響範囲】○○
ADRのフォーマット：
# ADR-[番号]: [タイトル]
## Status / Date / Context / Decision / Consequences / Alternatives Considered
の順で、Markdownで出力してください。
「なぜこの技術選定をしたか」を記録するADRは、将来のチームへの重要な資産です。口頭で決めたことを後からAIで文書化するだけでも価値があります。
システム設計の壁打ち相手としてもAIは有効です。
📋 プロンプト（コピーしてそのまま使えます）
**System overview:**
[describe what the system does]
**Current architecture:**
[describe components, how they communicate, data flow, tech stack]
**Scale requirements:**
– Expected users: [e.g. 10k DAU / 1M DAU]
– Data volume: [e.g. 1TB/year]
– Availability: [e.g. 99.9% uptime]
**My concerns / questions:**
[what you’re unsure about]
Please review for:
1. Single points of failure
2. Scalability bottlenecks
3. Security considerations
4. Operational complexity
5. Cost efficiency
Suggest specific improvements with trade-offs for each.
スケール要件を具体的に入力することで、「将来1M DUAになったときのボトルネック」まで見越した設計レビューが得られます。設計の壁打ち相手として、週次のアーキテクチャ議論前に活用するのがおすすめです。
📋 プロンプト（コピーしてそのまま使えます）
**Database:** [PostgreSQL / MySQL / MongoDB / etc.]
**Use case:** [describe the application]
**Schema:**
“`sql
[paste your CREATE TABLE statements]
“`
**Typical query patterns:**
[describe the most frequent and most critical queries]
Review for:
1. Normalization issues (over/under normalized)
2. Missing or redundant indexes
3. Data type choices
4. Naming conventions
5. Relationships and foreign key constraints
6. Potential performance issues at scale
Provide specific ALTER TABLE or index recommendations.
「典型的なクエリパターン」を伝えることが重要です。どんなクエリが多いかによって、最適なインデックス設計が大きく変わります。
📋 プロンプト（コピーしてそのまま使えます）
以下の条件で技術選定の比較検討をサポートしてください。
【解決したい課題・要件】○○
【チームのスキルセット】○○（例：TypeScript得意・Rustは未経験）
【プロジェクトの規模・期間】○○
【比較したい選択肢】○○（例：Next.js / Remix / Nuxt.js）
出力内容：
1. 各選択肢の特徴まとめ（表形式）
2. この要件に最も適した選択肢の推薦と理由
3. 各選択肢のトレードオフ（長所・短所）
4. 選定する際に追加で確認すべきポイント
5. 参考になる実際の採用事例
チームのスキルセットと要件を正直に入力することで、「理想論ではなく現実的な」技術選定のアドバイスが得られます。最終判断は必ず自分たちで行いましょう。
新しい技術のキャッチアップや概念理解にもAIは強力なパートナーです。
📋 プロンプト（コピーしてそのまま使えます）
My current level: [beginner / intermediate / I understand X but not Y]
Please:
1. Start with an analogy to something non-technical
2. Explain the core idea in 3 sentences
3. Show a minimal working code example
4. Explain a real-world use case where this matters
5. List 2-3 common mistakes or misconceptions
Keep the explanation concise. Ask me if I want to go deeper on any part.
「自分のレベル」を伝えることで、説明の深さが最適化されます。最後の「Ask me if I want to go deeper」を入れることで、続きを対話形式で深掘りできます。
📋 プロンプト（コピーしてそのまま使えます）
【使用言語・フレームワーク】○○
【エラーメッセージ・スタックトレース】
（ここにエラーをそのまま貼り付け）
解説してほしいこと：
1. このエラーが何を意味するか（専門用語なしで）
2. 最もよくある原因（3つ）
3. 原因を特定するための確認手順
4. それぞれの原因に対する修正方法
英語のエラーメッセージを日本語で解説してもらうことで、エラー対応のスピードが大幅に上がります。特に経験の浅いエンジニアの学習加速に効果的です。
📋 プロンプト（コピーしてそのまま使えます）
**Context:** [where does this code live? what calls it?]
“`[language]
[paste the code here]
“`
Please explain:
1. The overall purpose (1 sentence)
2. Step-by-step walkthrough of the logic
3. What each parameter/variable represents
4. Any non-obvious or tricky parts
5. Potential side effects or edge cases I should be aware of
Use plain language. Avoid jargon where possible.
他人のコードや数ヶ月前に自分が書いたコードを読む際に活躍します。「コンテキスト（どこから呼ばれるか）」を渡すことで、単体での説明より深い理解が得られます。
コードだけ貼っても、AIは「何のためのコードか」を知りません。「このAPIは1日100万リクエストを処理する」「このコードはモバイルアプリのオフライン同期に使う」といったコンテキストを添えるだけで、アドバイスの質が大きく変わります。
コーディング系のタスクはLLMの学習データに英語が圧倒的に多いため、英語プロンプトの方が精度が高い傾向があります。ドキュメントや社内共有が目的のときは日本語、コーディング・デバッグ系は英語、と使い分けましょう。
AIが生成したコードは必ずレビューし、テストを通してから使いましょう。特にセキュリティ関連・認証・決済処理は、AIの出力を信頼しすぎず必ず専門知識でダブルチェックすることが重要です。
今回紹介したエンジニア・開発者向けAIプロンプト20選は、コピーしてそのまま使えます。AIはコードを書いてくれますが、設計判断・コードレビューの最終確認・セキュリティチェックは人間の責任です。AIを「ジュニアエンジニア」として使いこなすイメージで、うまく活用してください。
