【2026年版】プロンプトエンジニアリング実践テクニック10選｜個人開発者がAIを最大限活用する方法

// ExpressのAPIルートを作って

あなたは、個人開発向けのTypeScriptコードを書くシニアエンジニアです。

## 背景
- Express + Prisma + PostgreSQL の構成
- 認証にはJWTを使用
- エラーハンドリングはカスタムミドルウェアで統一

## 命令
ユーザーのプロフィール更新用のPATCHエンドポイントを作成してください

## 要件
1. リクエストボディのバリデーション（zod使用）
2. 更新可能フィールド: name, bio, iconUrl
3. 存在しないユーザーIDの場合は404
4. 自分のプロフィールのみ編集可能（JWTのuserIdと比較）

## 出力形式
- ファイルパス付きのコードブロック
- 主要な処理に日本語のコメントを付与
- 変更が必要な既存ファイルがあればその差分も表示

広告

マネーフォワード

最大2,000円還元

詳しく見る →

2. Few-shotプロンプティング ― 「見本」を見せる

抽象的な指示より、具体例を1〜3個見せるのが最強です。特に出力フォーマットを統一したいときに効きます。

あなたは、GitHubのPRにレビューコメントを書くアシスタントです。
以下のルールでレビューしてください。

【良いレビューの例1】
「この部分、filter()のコールバック内でAPIを叩いていますが、
ループごとにリクエストが飛ぶのでN+1問題が発生しています。
事前にまとめてfetchしてからfilterすると良いです。」

【良いレビューの例2】
「try-catchの中でconsole.errorだけで握りつぶしています。
ユーザーに見えるエラーハンドリングがないので、最低限
toastで通知する処理を入れてください。」

---
では、以下のPRのコードをレビューしてください：

ChatGPTとClaudeは見本のパターンを忠実に模倣する傾向があります。Geminiは例示しすぎると逆に「別のパターンも試したい」と余計なバリエーションを出してくることがあるので、例は少なめ（2個程度）がベターです。

3. Chain-of-Thought（CoT） ― 「考えさせる」

複雑なタスクでは、いきなり答えを出させるより「考えさせてから回答させる」方が精度が上がります。

以下の要件を満たすバックエンドのDBスキーマを設計してください。
設計する前に、ステップバイステップで考えてから回答してください。

要件：
- ユーザーが複数のブログを持てる
- 各ブログに複数の記事
- 各記事に複数のタグ
- いいね機能（ユーザーは1記事に1回のみ）
- ブックマーク機能

手順：
1. まず必要なエンティティと関連を洗い出してください
2. 正規化レベルを検討してください
3. スキーマ定義を書いてください
4. 各テーブルのインデックス設計も含めてください

CoTはClaudeが最も素直に「考えた過程」を出力してくれます。ChatGPTはやや簡潔になりがち。Geminiは一般的な知識の回答になるときがあるので、タスク固有の制約をCoTの最初に明示するのがコツです。

4. 否定より肯定 ― 「しないで」より「して」

これは意外と盲点。「〇〇しないで」と書くより「代わりに××して」と書いた方がAIは素直です。

否定形だとAIが「〇〇しない」というキーワードに引っ張られて、かえってその話題が出てきやすいという逆効果があります。やってほしいことだけを具体的に書くのが鉄則です。

5. Role Prompting の応用 ― 人格を細かく指定する

「あなたはプロのエンジニアです」はもう古い。2026年のプロンプトでは、より具体的な属性・制約・価値観を与えると効果的です。

あなたは、スタートアップのCTOとして10年の経験を持ち、
以下の価値観でコードレビューを行います：
- シンプルさを何より優先（YAGNI）
- テストのないコードは動いていないと同じ
- パフォーマンスより可読性
- ただし、N+1問題や不要なループは指摘する

あなたは、後輩エンジニアに対して優しくも厳しい指導を心がけています。
単に「
        直せ」と言うのではなく、なぜその修正が必要かの理由も説明してください。

単なる「プロのエンジニア」より、「スタートアップCTO」「10年の経験」「YAGNI」「可読性重視」といった属性を盛り込むことで、出力のキャラクターが固定されます。Claudeはこのロールプロンプトの追従が特に優れており、会話が続いてもキャラがブレにくいです。

広告

DMM FX

最大40,000円還元

詳しく見る →

6. 出力形式の指定で後処理をゼロにする

AIの出力をそのまま別のツールに渡したい場合、フォーマット指定は命です。私は以下のテンプレートをよく使います。

以下の形式でJSONのみを出力してください。
説明や補足は一切不要です。
コードブロック（```json）も使用しないでください。

{
  "success": true/false,
  "data": { /* 主要データ */ },
  "errors": [ /* エラーがある場合の配列 */ ]
}

ここで重要なのは「コードブロックも使わないで」という追加指示。ClaudeはデフォルトでMarkdownのコードブロックを付けてくるので、パース処理を書くのが面倒なときは明示的に禁止します。

モデル別のフォーマット追従比較:

7. 反復プロンプト ― 「もっと良くして」の活用

一回で完璧な出力を期待するより、「もっと改善できる？」と問いかける方が最終品質が上がります。これは個人的に一番おすすめのテクニックです。

# 1回目
「このコードをレビューして」

# 2回目（出力を受け取った後）
「ありがとう。では、さらに以下の観点で改善点を探して：
- エッジケース（空配列、null、undefined）
- レースコンディション
- メモリリークの可能性」

# 3回目
「では、それらの改善を全部適用した最終版のコードを書いて」

1回目の出力 → 改善指示 → 3回目の統合の流れが最も品質が高いです。ChatGPTは2回目で結構新しい観点を出してきます。Claudeは1回目から品質が高いので、微調整で済むことが多い。Geminiは2回目で方向性が変わりすぎることがあるので、3回目で「最初の方向性をベースに統合して」と明示すると良いです。

8. コンテキストウィンドウを意識したプロンプト設計

2026年の主要モデルは100万〜200万トークンのコンテキストを持ちますが、コンテキストが長すぎると精度が落ちることが実証されています（Lost in the Middle問題）。

実際に使ってみての感覚値ですが、以下のポイントを守ると精度が安定します：

• 最も重要な指示は最初と最後に書く（中央にある情報は軽視されがち）
• コード全体をそのまま貼らない。必要な関数だけ抜き出すか、ファイル構造を先に説明する
• 長い会話は「要約→リセット」で新しいセッションを切る

# 悪い例：プロジェクト全体のコードを貼る（10,000行）
「このプロジェクトにテストを追加して」

# 良い例：構造を先に説明
「以下の構成のExpress + Prisma APIプロジェクトに、
各エンドポイントの結合テストを追加したいです。

src/
├── routes/
│   ├── auth.ts      # ログイン・登録
│   ├── users.ts     # ユーザーCRUD
│   └── posts.ts     # 記事CRUD
├── middleware/
│   └── auth.ts      # JWT認証ミドルウェア
└── lib/
    └── prisma.ts    # Prismaクライアント

現在のテスト構成：vitest使用。routes/auth.test.tsのみ存在
追加したいテスト：users.tsとposts.tsの結合テスト

必要な部分のコードが必要ならその都度聞いてください。」

この方式にしてから、一度に大量のコードを貼って意図と違う修正をされるケースが激減しました。

9. 複数モデルの「協議」方式

クリティカルな判断が必要な場合、一つのモデルだけで判断するより複数のモデルに同じ質問をして回答を比較するのが効果的です。私は以下のように使い分けています：

個人開発でここまでやるのはオーバーに聞こえるかもしれませんが、「一度実装してからやり直す」コストを考えれば、設計段階で30分使って3モデルに聞くのは余裕でペイします。実際、この方式を導入してから設計ミスによる手戻りが半分以下になりました。

10. メタプロンプト ― 「プロンプト自体をAIに書かせる」

最後は一番高度なテクニック。「このタスクを実行する最適なプロンプトを考えて」とAIに依頼してから、そのプロンプトを実行する手法です。

あなたはプロンプトエンジニアリングの専門家です。
以下のタスクを実行するための、最適なプロンプトを設計してください。

タスク：既存のNode.jsプロジェクトをESMに移行する手順書の作成
対象読者：中級者のエンジニア

プロンプトに含めるべき要素：
- 役割設定
- 背景情報（package.jsonのtypeフィールド、import/export構文など）
- 具体的な指示（移行手順、注意点、検証方法）
- 出力形式

まずプロンプトを設計し、その後に「=== 実行 ===」と書いてから
設計したプロンプトを実際に実行してください。

AIにプロンプトを考えさせると、自分では思いつかなかった视角（視点）や表現を取り入れたプロンプトが生成されます。これを「メタプロンプトテンプレート」として保存しておくと、似たタスクの度に流用できて便利です。

Claudeでこのテクニックを使うと、自己改善的なループが最も効果的に回る印象です。ChatGPTも悪くないですが、やや抽象度が高い提案になりがち。Geminiはメタプロンプトの指示をそのまま実行しようとしすぎて、肝心のプロンプト設計が雑になることがあるので注意。

まとめ：プロンプトは「書く」から「設計する」時代へ

2025年〜2026年にかけてのAIモデルの進化は凄まじく、昨年よりも遥かに「ちょっとしたプロンプトの違い」が結果を大きく左右するようになりました。裏を返せば、プロンプトをちゃんと設計できる人ほど、AIの恩恵を享受できる時代になったということです。

この記事で紹介した10個のテクニックの中で、まずは「1. 構造化プロンプト」「4. 否定より肯定」「7. 反復プロンプト」の3つから始めるのをおすすめします。これだけで出力品質が確実に変わります。

そして慣れてきたら「10. メタプロンプト」で自分専用のテンプレートを作ってみてください。AIとの対話の質が一段上がるはずです。

プロンプトエンジニアリングは、「AIにどう指示を出すか」というよりも、「自分が本当に欲しいアウトプットを明確にする」作業です。これができる人は、AIを使わない開発でも設計力が高い——そんな気がしています。