【位置づけ】

あなた → [プロンプト] → LLM → [レスポンス]
              ↑
    ここを設計・改善する技術

ファインチューニング         → モデルの重みを書き換える・コスト高
プロンプトエンジニアリング   → 入力の工夫のみ・今日から始められる

❌ fetch('/api/data')
✅ fetch('/api/users?role=admin&status=active&limit=10')

P - Persona      → 誰として答えるか（例：「Next.js専門のシニアエンジニア」）
T - Task         → 何をしてほしいか ← 唯一の必須要素
C - Context      → 背景・前提条件（バージョン・チーム規模・現状の課題）
F - Format       → 出力の構造・長さ（Markdown・表・コード・文字数）
E - Examples     → 期待する入出力の見本（Few-shotと組み合わせる）
R - Restrictions → やってはいけないこと（否定形指示はここに集約）

# 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の内容は含めない
- 外部ライブラリ導入前提の解決策は除外

【通常のプロンプト】
問い → 即答  ← 複雑な問題だと精度が落ちやすい

【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：1本道】
問い → ステップ1 → ステップ2 → ステップ3 → 答え

【ToT：木構造】
              ┌→ 経路A → A1 → A2 → ✅ 採用
問い → 起点  ├→ 経路B → B1 → ❌ 行き詰まり → 枝刈り
              └→ 経路C → C1 → C2 → C3 → 比較対象

Next.js + Supabaseの認証方式を設計してください。

# Step1：候補を3つ出す
# Step2：各候補を実装コスト・セキュリティ・UXで評価する
# Step3：最良案を選んで実装方針を示す

前提：Google OAuth必須・管理者/一般ユーザーの権限分離が必要

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"
出力:

【通常のフロー】
あなた → プロンプトを書く → LLM → 出力

【Meta-promptingのフロー】
あなた → 「プロンプトを作って」→ LLM → プロンプト生成
                                          ↓
あなた → 生成されたプロンプトを微調整 → LLM → 出力

# Step1：プロンプトを作らせる
以下のタスクに対して、PTCFE/Rフレームワークに従った最適なプロンプトを作成してください。

タスク：Supabaseのテーブル設計をレビューして正規化の問題点とRLSの抜け漏れを指摘してほしい
状況：Next.js 14・チーム3人・テーブル数8個

# Step2：生成されたプロンプトを自分でレビュー・微調整する
# Step3：実際のテーブル設計を貼って使う

# P
あなたはマッキンゼー出身のストラテジストです。

# T
以下の情報を構造化して、MECE（漏れなくダブりなく）に整理してください。

# C
[調査メモや議事録などのテキストをここに貼る]

# F
- 大項目3〜5個、各項目に小項目2〜3個
- Markdownの見出しと箇条書きで出力
- 1000字以内

# R
- 解釈・示唆は含めない（事実の整理のみ）

# T
以下の競合他社の情報を比較分析してください。

# C
[各社の情報をここに貼る]

# F
| 企業名 | 強み | 弱み | 差別化ポイント | 脅威度（高/中/低） |
の表形式で出力。最後に「総評（3行以内）」を追記。

# R
- 推測に基づく情報には「※推定」と明記
- 公開情報の範囲を超えた断定をしない

# T
以下の調査結果をもとに、戦略提言を3案作成し、最良案を推薦してください。

# C
[調査結果サマリー]
制約：予算500万・期間6ヶ月・チーム3人

# F
Step1: 提言候補を3案出す（各案：タイトル＋根拠＋リスク）
Step2: 実現可能性・インパクト・リスクで評価
Step3: 推奨案を選び、実行ステップを3つ示す

# T
以下の調査内容をもとに、経営陣向けの報告スライドの構成案を作成してください。

# F
- スライド枚数：10枚以内
- 各スライドに「タイトル」「伝えたいメッセージ1文」「コンテンツ概要」を記載
- エグゼクティブサマリー（1枚目）から始める

# R
- 詳細データの羅列はしない
- 各スライドのメッセージは結論から始める（BLUF形式）

# 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型の使用禁止

# 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型を使わない