概要
モデルを変えず、入力の工夫だけでAIの出力品質を高める技術です。「何をどう伝えるか」を設計するだけで、結果が大きく変わります。
- PTCFE/R フレームワークを使うことで、プロンプトの抜け漏れが減り出力が安定します
- Few-shot・CoT・ToT はタスクの性質に合わせて使い分けることが重要です
- コーディングでは「環境情報の明記」が品質を左右する最大のポイントです
テクニック早見表
各手法の使いどころを一覧で把握しておくと、場面ごとの選択に迷いません。
| 手法 | 一言で言うと | 向いているタスク |
|---|---|---|
| Zero-shot | 例なし・指示だけ | シンプルな質問・翻訳・整形 |
| Few-shot | 例を見せて形式を統一 | 出力形式・トーン・粒度を揃えたいとき |
| CoT | 推論過程を段階的に出力 | バグ分析・設計・複雑な推論 |
| ToT | 複数経路を並べて比較 | アーキテクチャ選定・意思決定 |
| Meta-prompting | プロンプトをAIに作らせる | プロンプト設計に慣れていないとき |
| PTCFE/R | 6要素でプロンプトを構造化 | 全タスク共通の設計テンプレート |
プロンプトエンジニアリングとは
LLMに意図した出力を引き出すための「入力設計・改善技術」です。モデル自体は変えません。
AIへの指示（プロンプト）を工夫することで、同じモデルでも出力の質を大きく変えられます。
あなた → [プロンプト] → LLM → [レスポンス]
↑
ここを設計・改善する技術
ファインチューニングとの違いを押さえておくと理解が早まります。
| 手法 | 何を変えるか | コスト | 始めやすさ |
|---|---|---|---|
| プロンプトエンジニアリング | 入力（プロンプト）のみ | 低 | ✅ 今日から |
| ファインチューニング | モデルの重み（内部パラメータ） | 高 | ❌ 専門知識が必要 |
APIの引数設計と同じ発想で考えると分かりやすいです。渡す情報が具体的なほど、期待通りのレスポンスが返ります。
❌ fetch('/api/data')
✅ fetch('/api/users?role=admin&status=active&limit=10')
ポイント: まずここから始めるのが正解です。ファインチューニングはモデル自体を書き換えますが、プロンプトエンジニアリングは入力だけで勝負できます。
用語
| 用語 | 説明 |
|---|---|
| プロンプト | LLMへの入力テキスト全体 |
| ファインチューニング | モデルの重みを追加学習で書き換えること |
| Zero-shot | 例なしで指示だけ与えるプロンプト |
| Few-shot | 例を2〜5個添えて出力を制御するプロンプト |
PTCFE/R フレームワーク
プロンプトを6つの要素に分けて構造化します。全要素が必須ではなく、タスクに応じて組み合わせます。
「何を書けばいいか分からない」という迷いをなくすための設計テンプレートです。要素を足すほど出力が安定します。
{{image:ptcfe_diagram}}
| 要素 | 意味 | 例 |
|---|---|---|
| P - Persona | 誰として答えるか | 「Next.js専門のシニアエンジニア」 |
| T - Task | 何をしてほしいか（唯一の必須要素） | 「エラーハンドリングを説明して」 |
| C - Context | 背景・前提条件 | バージョン・チーム規模・現状の課題 |
| F - Format | 出力の構造・長さ | Markdown・表・コード・文字数 |
| E - Examples | 期待する入出力の見本 | Few-shotの例と組み合わせる |
| R - Restrictions | やってはいけないこと | 否定形指示はここに集約する |
PTCFE/R を使ったプロンプト例
# P
あなたはNext.js専門のシニアエンジニアです。
# T
App RouterのServer Actionsにおけるエラーハンドリングのベストプラクティスを説明してください。
# C
- Next.js 14 + Supabase使用
- チーム3人・Next.js歴1年未満
# F
- Markdown形式・TypeScriptのコードブロック付き・500字以内
# E
悪い例と良い例をそれぞれ1つずつ示してください。
# R
- Pages Routerの内容は含めない
- 外部ライブラリ導入前提の解決策は除外
ポイント: TだけのプロンプトはZero-shotです。C・F・E を足すほど出力が安定します。否定形の指示は R にまとめると整理しやすくなります。
Few-shot Prompting
例（shot）を見せることで出力の形式・粒度・トーンを制御します。言葉で説明するより、見本を見せる方が早くて正確です。
初心者がまず取り入れやすいテクニックです。「こういう形式で答えてほしい」という型を、例として渡すだけで機能します。
Zero-shot：例なし → 指示だけで判断させる（出力がバラつきやすい）
One-shot ：例1つ → なんとなく形式が伝わる
Few-shot ：例2〜5つ → 形式・粒度・トーンが安定する ✅ おすすめ
エラーログ分類の例
以下の形式でエラーログを分類してください。
例1）
入力: "JWT expired at 2026-03-31T10:00:00Z"
出力: { "category": "認証エラー", "severity": "medium", "action": "再ログインを促す" }
例2）
入力: "relation 'users' does not exist"
出力: { "category": "DBエラー", "severity": "high", "action": "マイグレーションを確認" }
例3）
入力: "new row violates row-level security policy"
出力: { "category": "権限エラー", "severity": "high", "action": "RLSポリシーを見直す" }
本題）
入力: "invalid input syntax for type uuid"
出力:
良い例・悪い例の違い
| 良い例の条件 | 悪い例の条件 |
|---|---|
| エッジケースをカバーしている | 全部似たようなケースばかり |
| 形式が完全に統一されている | 微妙に形式がバラバラ |
| 2〜5個（多すぎない） | 1個だけ（出力が安定しない） |
ポイント: Few-shotは「例の質」が命です。曖昧な例を入れると曖昧な出力が返ってきます。PTCFE/R の E（Examples）と実質同じ概念なので、セットで覚えておくとよいでしょう。
Chain-of-Thought（CoT）
推論の過程を段階的に出力させることで、複雑なタスクの精度を上げるテクニックです。
「ステップバイステップで考えてから答えてください」という一言を加えるだけで、精度が上がる場合があります。
{{image:cot_vs_tot}}
【通常のプロンプト】
問い → 即答 ← 複雑な問題だと精度が落ちやすい
【CoTプロンプト】
問い → ステップ1 → ステップ2 → ステップ3 → 答え ← 精度が上がる
Zero-shot CoT（最もよく使う）
以下の要件でSupabaseのRLSポリシーを設計してください。
ステップバイステップで考えてから、最終的なSQLを出力してください。
要件：
- usersテーブルへのSELECTは本人のみ許可
- INSERTは認証済みユーザーなら誰でも可
- DELETEは管理者ロールのみ許可
Few-shot CoT（出力形式を揃えたいとき）
バグの原因を以下の形式で分析してください。
例）
コード: const data = res.json()
分析:
- 観察: awaitがない
- 原因: res.json()はPromiseを返すが解決前に使っている
- 修正: const data = await res.json()
本題）
コード: const { data } = supabase.from('posts').select('*')
CoT を使う・使わない判断基準
| CoT向き ✅ | CoT不要 ❌ |
|---|---|
| 複雑な推論・設計 | 翻訳・フォーマット変換 |
| バグ原因分析 | 箇条書きへの整形 |
| RLSポリシー設計 | 単純な分類タスク |
ポイント: 単純タスクにCoTを使うと、回答が冗長になるだけです。「複雑な推論が必要か？」を判断基準にしてください。
Tree-of-Thought（ToT）
複数の思考経路を同時に探索し、最良のものを選ぶ手法です。選択肢の比較・設計の意思決定に強みがあります。
CoTが「1本道の深掘り」なのに対し、ToTは「複数の選択肢を並べて比較する」イメージです。
【CoT：1本道】
問い → ステップ1 → ステップ2 → ステップ3 → 答え
【ToT：木構造】
┌→ 経路A → A1 → A2 → ✅ 採用
問い → 起点 ├→ 経路B → B1 → ❌ 行き詰まり → 枝刈り
└→ 経路C → C1 → C2 → C3 → 比較対象
ToT の例
Next.js + Supabaseの認証方式を設計してください。
Step1：候補を3つ出す
Step2：各候補を実装コスト・セキュリティ・UXで評価する
Step3：最良案を選んで実装方針を示す
前提：Google OAuth必須・管理者/一般ユーザーの権限分離が必要
CoT と ToT の使い分け
| CoTを使う場面 | ToTを使う場面 |
|---|---|
| 答えが1つに収束する問題 | 複数の選択肢を比較したい |
| バグの原因分析 | アーキテクチャ・DB設計 |
| 順序立てた推論が必要 | トレードオフの意思決定 |
ポイント: 「ToTで選択肢を絞ってから CoT で深掘り」が最強の組み合わせです。まず ToT で候補を並べ、選んだ案を CoT で詳細化する流れを試してみてください。
Meta-prompting
「プロンプトを作るプロンプト」をLLMに生成させる手法です。何を指定すればいいか分からないときの起点になります。
プロンプトエンジニアリングに慣れていない段階では、「何を書けばいいか」自体が難しいことがあります。Meta-prompting はその問いをAIに投げることで解決します。
【通常のフロー】
あなた → プロンプトを書く → LLM → 出力
【Meta-promptingのフロー】
あなた → 「プロンプトを作って」→ LLM → プロンプト生成
↓
生成されたプロンプトを微調整 → LLM → 出力
Meta-prompting の例
以下のタスクに対して、PTCFE/Rフレームワークに従った最適なプロンプトを作成してください。
タスク：Supabaseのテーブル設計をレビューして、
正規化の問題点とRLSの抜け漏れを指摘してほしい
状況：Next.js 14・チーム3人・テーブル数8個
生成されたプロンプトをそのまま使うのではなく、自分でレビューして微調整してから使うことが重要です。
Meta-prompting の向き・不向き
| 向いている場面 ✅ | 向いていない場面 ❌ |
|---|---|
| プロンプト設計に慣れていない | 1回限りの単純な質問 |
| 繰り返し使うテンプレートを整備したい | 急いでいるとき（2段階になる） |
| チームで標準プロンプトを共有したい | — |
ポイント: PTCFE/R に慣れるまでの補助輪として最適です。生成されたプロンプトを読むことで「何を指定すべきか」の感覚が身につきます。
コーディングでの活用
「何を・どの粒度で・どの形式で」を明示することが、使えるコードを生成する鍵です。
コーディングタスクのプロンプトは「仕様書」として書く意識が重要です。曖昧な依頼は曖昧なコードを生みます。最も効果が大きいのは 環境情報の明記（Next.jsのバージョン・ルーターの種類・使用ライブラリ）です。
① 新規実装（仕様から生成）
# P
あなたはNext.js 14とTypeScriptに精通したシニアエンジニアです。
# T
以下の仕様でSupabaseのRLSポリシーとServer Actionを実装してください。
# C
- Next.js 14 App Router / TypeScript / Supabase
- postsテーブル：id, user_id, title, content, is_published
- 要件：
- 一般ユーザー：自分のpostのみCRUD可、published=trueのpostはSELECT可
- 管理者：全post操作可
# F
- RLS SQLと Server Action（TypeScript）を別々のコードブロックで出力
- 各コードにインラインコメントを付ける
- 最後に「ハマりやすいポイント」を箇条書きで追記
# R
- Pagesルーターの書き方は使わない
- any型の使用禁止
② バグ修正（CoT + Few-shot）
# T
以下のエラーの原因を分析し、修正済みコードを出力してください。
# C
- 環境：Next.js 14 App Router / Supabase Auth
- エラー：[エラーメッセージをそのまま貼る]
- 発生箇所：[該当コードを貼る]
# F
Step1: エラーの原因を1文で説明
Step2: 根本原因を3行以内で説明
Step3: 修正済みコードを出力（変更箇所に // FIXED コメント付き）
Step4: 再発防止のために注意すべき点を1つ挙げる
③ コードレビュー（観点を指定する）
# T
以下のコードをレビューしてください。
# C
[コードをここに貼る]
技術スタック：Next.js 14 / TypeScript / Supabase
# F
以下の観点ごとに問題点を列挙してください：
1. セキュリティ（RLS・認証・XSSなど）
2. 型安全性（any使用・型推論の漏れ）
3. パフォーマンス（不要なre-render・N+1など）
4. 可読性・保守性
深刻度（🔴高 / 🟡中 / 🟢低）を各指摘に付けてください。
# R
- 問題がない観点は「問題なし」とだけ記載
- 修正方法の提案は指摘の後に1つだけ示す
④ テストコード生成
# T
以下の関数に対するユニットテストを生成してください。
# C
[テスト対象の関数コードを貼る]
テストフレームワーク：Vitest / Testing Library
# F
- 正常系・異常系・エッジケースをそれぞれ最低1つずつ
- describe / it のネスト構造で出力
- モックが必要な場合はvi.mock()を使用
# E
正常系の例：
it('should return user data when valid id is provided', async () => {
...
})
⑤ リファクタリング（制約を明示する）
# T
以下のコードを1関数1責務の原則でリファクタリングしてください。
# C
[リファクタリング対象コードを貼る]
# F
- Before / After の形式で出力
- 変更した理由を各関数の上にコメントで追記
- 型定義（interface / type）も整理する
# R
- 外部ライブラリを新たに導入しない
- 既存のAPIレスポンス形式を変えない
- any型を使わない
用語
| 用語 | 説明 |
|---|---|
| FIXED コメント | 修正箇所を明示するインラインコメント慣習 |
| N+1問題 | ループ内でDBクエリが発行され続けるパフォーマンス問題 |
| 1関数1責務 | Single Responsibility Principle。1つの関数は1つのことだけをする |
コンサルティング・調査での活用
情報収集→構造化→示唆出しの各フェーズでプロンプトを使い分けます。出力形式の指定が品質を左右します。
コンサル的な調査タスクは「情報が散らかっている状態から、構造化された示唆を出す」プロセスです。LLMはこのプロセスの各ステップを加速できます。
① 情報の構造化（インプット整理）
# P
あなたはマッキンゼー出身のストラテジストです。
# T
以下の情報を構造化して、MECE（漏れなくダブりなく）に整理してください。
# C
[調査メモや議事録などのテキストをここに貼る]
# F
- 大項目3〜5個、各項目に小項目2〜3個
- Markdownの見出しと箇条書きで出力
- 1000字以内
# R
- 解釈・示唆は含めない（事実の整理のみ）
② 競合・市場調査の要約
# T
以下の競合他社の情報を比較分析してください。
# C
[各社の情報をここに貼る]
# F
| 企業名 | 強み | 弱み | 差別化ポイント | 脅威度（高/中/低） |
の表形式で出力。最後に「総評（3行以内）」を追記。
# R
- 推測に基づく情報には「※推定」と明記
- 公開情報の範囲を超えた断定をしない
③ 示唆・提言の生成（ToT + CoT の組み合わせ）
# T
以下の調査結果をもとに、戦略提言を3案作成し、最良案を推薦してください。
# C
[調査結果サマリー]
制約：予算500万・期間6ヶ月・チーム3人
# F
Step1: 提言候補を3案出す（各案：タイトル＋根拠＋リスク）
Step2: 実現可能性・インパクト・リスクで評価
Step3: 推奨案を選び、実行ステップを3つ示す
④ レポート・スライド構成の生成
# T
以下の調査内容をもとに、経営陣向けの報告スライドの構成案を作成してください。
# F
- スライド枚数：10枚以内
- 各スライドに「タイトル」「伝えたいメッセージ1文」「コンテンツ概要」を記載
- エグゼクティブサマリー（1枚目）から始める
# R
- 詳細データの羅列はしない
- 各スライドのメッセージは結論から始める（BLUF形式）
ポイント: コンサル調査での最大の失敗は「出力形式を指定しないこと」です。表・MECE構造・スライド構成など、形式を先に決めると情報密度が劇的に上がります。
用語
| 用語 | 説明 |
|---|---|
| MECE | Mutually Exclusive, Collectively Exhaustive（漏れなくダブりなく） |
| BLUF | Bottom Line Up Front（結論から先に述べる文書スタイル） |
| エグゼクティブサマリー | 報告書の冒頭に置く全体要約（意思決定者向け） |
やりがちなミス
「曖昧な入力・形式未指定・詰め込みすぎ」が3大失敗パターンです。
{{image:dev_cycle}}
| ミス | 原因 | 改善策 |
|---|---|---|
| 指示が曖昧（「良い感じに」） | 成果物のイメージが自分の中にない | 具体的な形式・成果物を先に決める |
| 否定形だけで指示する | 「何をすべきか」ではなく「何をしないか」を伝えている | 肯定形で伝え、否定形は R にまとめる |
| 文脈を省きすぎ | 自分には自明だからと書かない | バージョン・チーム規模・現状の課題を明記する |
| 1プロンプトに詰め込みすぎ | 「一発で終わらせたい」心理 | タスクを分割して複数回に分ける |
| 出力形式を指定しない | 形式より内容を重視している | 形式・長さ・構造を先に決めて F に書く |
| 一発で完璧を求める | 完璧主義 | 投げる → 評価 → 修正 → 再投げ のサイクルを回す |
| CoT を何でも使う | テクニックを使いたい心理 | 複雑な推論タスクにだけ使う |
| Few-shot の例が雑 | 例を「おまけ」だと思っている | 形式を完全に統一する・エッジケースを入れる |
| 環境情報を省く（コーディング） | 自明だと思い込んでいる | Next.js バージョン・Router 種別・ライブラリを必ず明記 |
| 調査結果をそのまま貼る（コンサル） | LLMが勝手に整理してくれると期待 | 出力形式（表・MECE構造など）を先に指定する |
次のステップ
この記事で紹介した手法を、小さなタスクから順番に試してみてください。
実践の優先順位としては、以下の順序がおすすめです。
- PTCFE/R を日常の質問に当てはめてみる（T → C → F の順に要素を足す）
- Few-shot を繰り返し使うタスクに組み込み、テンプレート化する
- CoT をバグ分析・設計タスクに限定して使い始める
- ToT を「どれを選ぶか」という意思決定場面で試す
- Meta-prompting でチーム共通プロンプトを整備する
いずれの手法も「一発で完璧を求めない」ことが大前提です。投げる → 評価 → 修正 → 再投げ のサイクルを素早く回すことが、プロンプトエンジニアリングの本質です。
参考リンク
- Prompt Engineering Guide — 網羅的なガイド（日本語あり）
- Anthropic: Prompt Engineering Docs
- OpenAI Prompt Engineering
この記事は、こちらのブログでも書いてます
Snipphy — プロンプトエンジニアリング実践ガイド — PTCFE/R・CoT・ToT からコーディング活用まで