2026-03-26

プロンプトエンジニアリングとは？主要手法・実例・チーム導入まで徹底解説【2026年最新版】

「PR差分を渡してレビューしてほしいと頼んだら、コードの意図とまったく関係ない改善案が返ってきた」「テストコードを生成させたら、ハッピーパスしかカバーしていないテストが量産された」——こういった経験は、LLMをエンジニアリング業務に使い始めた人なら一度はぶつかる壁です。同じモデルを使っているのに、チームメンバーによって生成結果の質が全然違う、というのも現場でよく聞く話です。

この差の正体は「プロンプトの設計品質」にあります。LLMは突き詰めるとトークン列の確率予測モデルです。入力として与えるトークン列の構造・順序・情報量が、次のトークンの確率分布を直接決定します。つまり、インプットをどう設計するかがアウトプットの質を左右する——これがプロンプトエンジニアリングの本質です。

1. プロンプトエンジニアリングとは？基本概念と定義

定義：LLMへのインターフェース設計

プロンプトエンジニアリングとは、LLM（大規模言語モデル）に対して意図した出力を引き出すために、入力テキスト（プロンプト）を体系的に設計・最適化する実践的手法です。OpenAIは「モデルをより効果的に利用するためのプロンプト開発・最適化」（※1）と定義し、Anthropicも「Claudeから望む出力を得るための明確な指示の設計」（※2）と説明しています。

要するに、「LLMへの入力を構造化することで、期待するレスポンスの品質を高められる」という手法です。

ハルシネーションとプロンプトの限界

ここで一点、誤解されやすい前提を整理しておきます。プロンプトをどれだけ精緻に設計しても、ハルシネーション（事実と異なる内容の生成）をゼロにすることはできません。

これは技術的な成熟度の問題ではなく、LLMの仕組みに起因する構造的な制約です。LLMは「指示とコンテキストからもっともらしいトークン列を確率的に生成する」モデルであり、「正しい答えを参照して返す」モデルではありません。出力が「それらしく見える」ことと「正確である」こととは別の話です。プロンプトエンジニアリングは「期待する出力が出やすくなる確率を上げる技術」であって、「正解を保証する技術」ではない——この前提のもとで使うことが重要です。

コードレビューや障害分析でLLMを使う場合も、出力を必ずバリデーションする設計を前提にしてください。

プロンプトエンジニアリングが効く場所・効かない場所

効果が出やすいもの：

構造化されたドキュメント生成（仕様書レビュー・バグ報告書・RFC）
分析・推論の補助（トレードオフ比較・インシデント仮説列挙）
フォーマット変換・要約（会議ログ整理・PR説明文生成）

プロンプトエンジニアリングだけでは解決しないこと：

レビュー・QAが人手に依存している開発フロー：プロンプトで実装アウトプットが増えても、レビュー工程がボトルネックのままでは開発フロー全体の速度は上がりません。プロンプトエンジニアリングはあくまで個別工程の補助であり、開発ワークフロー全体の設計とセットで考える必要があります。
知識カットオフ以降の情報や組織固有の内部ドキュメントへの参照：プロンプトエンジニアリングだけでなく、RAG・コンテキストエンジニアリングの領域になります。

なぜ今、エンジニアが学ぶべきか

2026年時点で、LLMはコード補完・レビュー・テスト生成・ドキュメント作成・アーキテクチャ相談といった開発ワークフローの各所に入り込んでいます。ツールとしての性能はすでに十分高い。問題は「どう使うか」の設計力がチーム内でばらついていることです。プロンプトエンジニアリングは、LLMというインターフェースを扱うためのリテラシーであり、再現性のあるチームのAI活用基盤を作るための技術です。

2. 主要手法の解説と使い分け：Zero-shot・Few-shot・CoTほか

2-1. Zero-shot Prompting（ゼロショット）

なぜ効くか

LLMは事前学習で膨大なコードや自然言語を学習済みです。Zero-shotはその学習済み知識を「タスクの説明だけ」で引き出す手法です。追加事例ゼロでも機能するため、一般的・汎用的なタスクには十分な品質が出ます（※1, ※2）。ただし、アウトプット形式の細かい制御は弱く、チーム固有のルールや出力フォーマット指定が必要な場合は後述のFew-shotと組み合わせます。

実務プロンプト例：PR差分のコードレビュー

あなたはシニアバックエンドエンジニアです。
以下のGit差分をレビューしてください。

レビュー観点：
- バグ・例外処理の抜け漏れ
- パフォーマンスへの影響
- 可読性・命名の適切さ
- テストの必要性

出力形式：
## 重大度: [CRITICAL / MAJOR / MINOR / NIT]
## 指摘箇所: <ファイル名>:<行番号>
## 問題: <何が問題か>
## 提案: <どう直すべきか>

---
<Git差分をここに貼る>

あなたはシニアバックエンドエンジニアです。
以下のGit差分をレビューしてください。

レビュー観点：
- バグ・例外処理の抜け漏れ
- パフォーマンスへの影響
- 可読性・命名の適切さ
- テストの必要性

出力形式：
## 重大度: [CRITICAL / MAJOR / MINOR / NIT]
## 指摘箇所: <ファイル名>:<行番号>
## 問題: <何が問題か>
## 提案: <どう直すべきか>

---
<Git差分をここに貼る>

このプロンプトで「ハッピーパスしか見ないレビュー」は大幅に改善されます。レビュー観点を列挙し、出力形式を構造化したことで、LLMが生成するトークン列が期待する分布に引き寄せられるためです。

2-2. Few-shot Prompting（フューショット）

なぜ効くか

LLMは入力に含まれる例示パターンを強力にインコンテキスト学習（In-Context Learning）します（※3）。例示がゼロ（Zero-shot）の場合、モデルはタスク解釈の幅が広くなりますが、Few-shotで具体例を与えると「このパターンで出力すべき」という文脈が明確になり、出力フォーマットの一貫性が大幅に向上します。Anthropicはこの手法を “multishot prompting” とも呼びます（※3）。

実務プロンプト例：バグ報告書の形式統一

以下のフォーマットでバグ報告書を作成してください。

--- 例1 ---
入力: 「ログインボタンを押しても何も起きない（iOS Safari）」
出力:
**タイトル**: ログインボタン無反応（iOS Safari）
**再現手順**:
1. iPhoneのSafariでログイン画面を開く
2. メールアドレス・パスワードを入力
3. 「ログイン」ボタンをタップ
**期待値**: ダッシュボードへ遷移する
**実際の挙動**: 何も起きない（コンソールエラーなし）
**環境**: iOS 17.4 / Safari 17 / iPhone 15

--- 例2 ---
入力: 「CSVエクスポートが空ファイルになる」
出力:
**タイトル**: CSVエクスポート結果が空ファイル
**再現手順**:
1. レポート画面を開く
2. 対象期間を選択
3. 「CSVエクスポート」をクリック
**期待値**: データが含まれたCSVファイルがダウンロードされる
**実際の挙動**: 0バイトのCSVファイルがダウンロードされる
**環境**: Chrome 124 / Windows 11

---
入力: 「検索フィルターを適用すると500エラーが出る」
出力:

以下のフォーマットでバグ報告書を作成してください。

--- 例1 ---
入力: 「ログインボタンを押しても何も起きない（iOS Safari）」
出力:
**タイトル**: ログインボタン無反応（iOS Safari）
**再現手順**:
1. iPhoneのSafariでログイン画面を開く
2. メールアドレス・パスワードを入力
3. 「ログイン」ボタンをタップ
**期待値**: ダッシュボードへ遷移する
**実際の挙動**: 何も起きない（コンソールエラーなし）
**環境**: iOS 17.4 / Safari 17 / iPhone 15

--- 例2 ---
入力: 「CSVエクスポートが空ファイルになる」
出力:
**タイトル**: CSVエクスポート結果が空ファイル
**再現手順**:
1. レポート画面を開く
2. 対象期間を選択
3. 「CSVエクスポート」をクリック
**期待値**: データが含まれたCSVファイルがダウンロードされる
**実際の挙動**: 0バイトのCSVファイルがダウンロードされる
**環境**: Chrome 124 / Windows 11

---
入力: 「検索フィルターを適用すると500エラーが出る」
出力:

例示の数は2〜5件が実用的なバランスです。例示が多いほど精度は上がりますが、トークンコストも増えるためタスクの複雑さに応じて調整します。

2-3. Chain-of-Thought（CoT）プロンプティング

なぜ効くか

Wei et al.（NeurIPS 2022）は、Few-shotの例示に「思考ステップ」を含めると、LLMが段階的な推論を模倣してより正確な解を導くことを実証しました（※4）。さらにKojima et al.（NeurIPS 2022）は、例示なしでも 「ステップバイステップで考えてください（Let’s think step by step）」 の一文を追加するだけで同様の効果が得られることを示しました（※5）。数値推論ベンチマーク（MultiArith）では正答率が17.7%から78.7%に向上しています。

直感的には「答えを直接予測させるより、途中の論拠トークンを生成させることで、後続の正解トークンの確率が上がる」という理解が正確です。難しい設計判断や複雑な障害分析ほど効果が出やすいです。

実務プロンプト例：アーキテクチャ選定のトレードオフ分析

以下のシステム要件に対して、アーキテクチャの選択肢をトレードオフ分析してください。
結論を出す前に、各選択肢の長所・短所・リスクを段階的に検討してください。

## システム要件
- DAU: 50万人
- ピーク時リクエスト: 10,000 req/sec
- データ書き込み頻度: 高（ユーザーイベントを常時記録）
- 読み取りレイテンシ要件: p99 < 100ms
- チームのRailsおよびPostgreSQL経験: 3年以上
- Kubernetes運用経験: なし

## 検討する選択肢
A. モノリシックRails + PostgreSQL（既存構成の垂直スケール）
B. Rails + PostgreSQL + Redisキャッシュ層
C. マイクロサービス + Kafka + 複数データストア

## 分析ステップ
1. 各選択肢がリクエスト要件を満たせるか検討する
2. チームのスキルセットとの適合性を評価する
3. 運用コスト・障害リスクを比較する
4. 最終推奨を根拠とともに述べる

以下のシステム要件に対して、アーキテクチャの選択肢をトレードオフ分析してください。
結論を出す前に、各選択肢の長所・短所・リスクを段階的に検討してください。

## システム要件
- DAU: 50万人
- ピーク時リクエスト: 10,000 req/sec
- データ書き込み頻度: 高（ユーザーイベントを常時記録）
- 読み取りレイテンシ要件: p99 < 100ms
- チームのRailsおよびPostgreSQL経験: 3年以上
- Kubernetes運用経験: なし

## 検討する選択肢
A. モノリシックRails + PostgreSQL（既存構成の垂直スケール）
B. Rails + PostgreSQL + Redisキャッシュ層
C. マイクロサービス + Kafka + 複数データストア

## 分析ステップ
1. 各選択肢がリクエスト要件を満たせるか検討する
2. チームのスキルセットとの適合性を評価する
3. 運用コスト・障害リスクを比較する
4. 最終推奨を根拠とともに述べる

ステップを番号で明示することで、LLMは途中論拠を省略せずに出力します。「答えだけ」を求めると推論過程がブラックボックスになり、検証できない判断が返ってきます。

2-4. Role Prompting（ロールプロンプティング）

なぜ効くか

LLMはロール（役職・専門性）を指定されると、その役割に関連する語彙・思考パターン・優先順位を強くアクティベートします。「SREとして」という指定は、信頼性・可用性・インシデント対応の視点を出力分布に強く引き込みます。逆に言えば、ロール指定なしでは一般的すぎる回答が返りやすいです。

実務プロンプト例：SREとしてインフラ設計をレビュー

あなたはSite Reliability Engineer（SRE）です。
SLO・障害対応・運用コストの観点から、以下のインフラ設計をレビューしてください。

## 設計概要
- ALB → ECS Fargate（オートスケーリング）→ RDS Aurora MySQL
- デプロイ: GitHub Actions → ECR → ECS Blue/Green
- ログ: CloudWatch Logs
- 監視: CloudWatch Metrics + PagerDuty

## レビュー観点
1. SLO99.9%達成のボトルネックになりそうな箇所はどこか
2. 障害時の切り戻し手順に設計上の問題はないか
3. 運用コスト削減のために変更すべき点はあるか
4. 追加すべき監視項目・アラートは何か

各観点について、具体的なリスクと改善提案を挙げてください。

あなたはSite Reliability Engineer（SRE）です。
SLO・障害対応・運用コストの観点から、以下のインフラ設計をレビューしてください。

## 設計概要
- ALB → ECS Fargate（オートスケーリング）→ RDS Aurora MySQL
- デプロイ: GitHub Actions → ECR → ECS Blue/Green
- ログ: CloudWatch Logs
- 監視: CloudWatch Metrics + PagerDuty

## レビュー観点
1. SLO99.9%達成のボトルネックになりそうな箇所はどこか
2. 障害時の切り戻し手順に設計上の問題はないか
3. 運用コスト削減のために変更すべき点はあるか
4. 追加すべき監視項目・アラートは何か

各観点について、具体的なリスクと改善提案を挙げてください。

ロールは具体的であるほど効果が高まります。「エンジニア」より「SRE」、「SRE」より「SLO設計の経験があるSRE」のように絞ると、専門性の高い出力が得られます。

2-5. 深津式プロンプト

なぜ効くか

深津貴之氏（THE GUILD代表 / note株式会社CXO / 弁護士ドットコム株式会社CXO兼任）（※6）が提唱・普及させた深津式は、「役割定義 → 制約条件 → 出力形式 → 入力」という構造化テンプレートです。LLMへの指示を機能ごとに明確に分離することで、解釈の揺れを最小化します。コードでいえば「引数の型定義と関数シグネチャを明示する」ようなイメージです。曖昧なナチュラルランゲージより構造的な制約が、出力の安定性を高めます。

実務プロンプト例：仕様書レビューの構造化プロンプト

## 役割
あなたはプロダクト開発経験10年以上のシニアソフトウェアエンジニアです。

## タスク
以下の機能仕様書をエンジニアリング視点でレビューしてください。

## 制約条件
- 実装上の曖昧さ・矛盾・抜け漏れに絞って指摘する
- UXや文章表現の指摘は対象外
- 各指摘は「問題」「影響範囲」「確認すべき質問」の3点セットで書く
- 指摘は重要度順（MUST / SHOULD / NICE TO HAVE）に分類する

## 出力形式
### [重要度] 指摘タイトル
**問題**: （何が不明・矛盾しているか）
**影響範囲**: （どのコンポーネント・ユーザーフローに影響するか）
**確認すべき質問**: （PMまたは設計者に確認すべき具体的な質問）

## 入力（仕様書）
<仕様書をここに貼る>

## 役割
あなたはプロダクト開発経験10年以上のシニアソフトウェアエンジニアです。

## タスク
以下の機能仕様書をエンジニアリング視点でレビューしてください。

## 制約条件
- 実装上の曖昧さ・矛盾・抜け漏れに絞って指摘する
- UXや文章表現の指摘は対象外
- 各指摘は「問題」「影響範囲」「確認すべき質問」の3点セットで書く
- 指摘は重要度順（MUST / SHOULD / NICE TO HAVE）に分類する

## 出力形式
### [重要度] 指摘タイトル
**問題**: （何が不明・矛盾しているか）
**影響範囲**: （どのコンポーネント・ユーザーフローに影響するか）
**確認すべき質問**: （PMまたは設計者に確認すべき具体的な質問）

## 入力（仕様書）
<仕様書をここに貼る>

この構造は「何をしてほしいか（タスク）」「何をしてはいけないか（制約）」「どう出力するか（形式）」を分離しているため、複数のメンバーが使い回しても出力が安定します。チームのプロンプトテンプレートとして管理するのに最適な形式です。

手法選択の目安

手法	向いているケース	トークンコスト
Zero-shot	汎用的なタスク・素早く試したい	低
Few-shot	出力フォーマットを統一したい	中〜高
CoT	推論・設計判断・複雑な分析	中
Role Prompting	専門的な観点が必要	低（組み合わせ可）
深津式	チームで再利用するテンプレート	中

3. プロンプトエンジニアリングの実例：ユースケースと推奨手法

主なユースケース	推奨手法
コードレビュー・API設計・SQL最適化・障害分析	Zero-shot + Role
アクセシビリティ検査・コンポーネント設計・パフォーマンス改善	Few-shot + CoT
アーキテクチャ選定・技術的負債評価・RFC作成	CoT + 深津式
1on1準備・採用基準整理・チームの課題構造化	深津式 + Role

SQL実行計画の分析

パフォーマンス劣化の原因を探るとき、EXPLAIN結果をそのままLLMに渡して分析させる使い方は即効性が高いです。

あなたはPostgreSQLの最適化に精通したデータベースエンジニアです。
以下のEXPLAIN ANALYZE結果を分析し、パフォーマンス改善のボトルネックを特定してください。

## テーブル概要
- usersテーブル: 500万行
- ordersテーブル: 3000万行
- インデックス: users(id), orders(user_id, created_at)

## EXPLAIN ANALYZE結果
<EXPLAIN ANALYZEの出力をここに貼る>

## 出力
1. ボトルネックになっている処理（Seq Scan・Hash Join等）を特定する
2. 推定コストと実際のコストの乖離を指摘する
3. 具体的なインデックス追加またはクエリ書き換え案を示す

あなたはPostgreSQLの最適化に精通したデータベースエンジニアです。
以下のEXPLAIN ANALYZE結果を分析し、パフォーマンス改善のボトルネックを特定してください。

## テーブル概要
- usersテーブル: 500万行
- ordersテーブル: 3000万行
- インデックス: users(id), orders(user_id, created_at)

## EXPLAIN ANALYZE結果
<EXPLAIN ANALYZEの出力をここに貼る>

## 出力
1. ボトルネックになっている処理（Seq Scan・Hash Join等）を特定する
2. 推定コストと実際のコストの乖離を指摘する
3. 具体的なインデックス追加またはクエリ書き換え案を示す

アクセシビリティ（WCAG 2.2）レビュー

WCAG 2.2（※7）への準拠チェックは、観点が多く手動では抜け漏れが出やすいです。コンポーネントのコードをLLMに渡してチェックリスト形式で確認させると、機械的な抜け漏れを防げます。

あなたはWCAG 2.2の専門家です。
以下のReactコンポーネントをアクセシビリティ観点でレビューしてください。

## チェック観点（WCAG 2.2準拠）
- 1.1.1 非テキストコンテンツ（alt属性の適切さ）
- 1.3.1 情報と関係性（ARIA役割・セマンティクス）
- 2.1.1 キーボード操作の完全サポート
- 2.4.7 フォーカスの視認性
- 4.1.2 名前・役割・値（フォーム要素のラベル）
- 2.5.3 ラベルを含む名称（ボタンテキストとaria-labelの一致）

## 出力形式
### [達成基準番号] 指摘タイトル
**問題**: 何が不適切か
**該当箇所**: コード行またはコンポーネント名
**修正案**: 具体的なコード例

## コンポーネント
<Reactコンポーネントのコードをここに貼る>

あなたはWCAG 2.2の専門家です。
以下のReactコンポーネントをアクセシビリティ観点でレビューしてください。

## チェック観点（WCAG 2.2準拠）
- 1.1.1 非テキストコンテンツ（alt属性の適切さ）
- 1.3.1 情報と関係性（ARIA役割・セマンティクス）
- 2.1.1 キーボード操作の完全サポート
- 2.4.7 フォーカスの視認性
- 4.1.2 名前・役割・値（フォーム要素のラベル）
- 2.5.3 ラベルを含む名称（ボタンテキストとaria-labelの一致）

## 出力形式
### [達成基準番号] 指摘タイトル
**問題**: 何が不適切か
**該当箇所**: コード行またはコンポーネント名
**修正案**: 具体的なコード例

## コンポーネント
<Reactコンポーネントのコードをここに貼る>

RFC（技術提案書）のドラフト作成

アーキテクチャ変更の提案書（RFC）は構成が決まっているため、CoT＋深津式で素早くドラフトを作れます。

## 役割
あなたは大規模Webサービスの設計経験を持つシニアアーキテクトです。

## タスク
以下の変更方針に基づいて、エンジニアチーム向けのRFCドラフトを作成してください。

## 変更方針
- 現状: モノリシックRails APIにすべてのロジックが集約
- 変更: 通知機能を非同期ワーカー（Sidekiq → Amazon SQS + Lambda）へ分離
- 理由: 通知処理のタイムアウトがAPIレスポンスに影響している

## RFCの構成
1. 背景と課題（現状の何が問題か、数値で示す）
2. 提案するアーキテクチャ（Before / After図を言語で表現）
3. 技術的選定理由（SQS vs SNS vs Sidekiq継続の比較）
4. 移行計画（段階的リリースの手順）
5. リスクと緩和策
6. 未解決の問題（チームで議論すべき点）

各セクションを段階的に展開してください。

## 役割
あなたは大規模Webサービスの設計経験を持つシニアアーキテクトです。

## タスク
以下の変更方針に基づいて、エンジニアチーム向けのRFCドラフトを作成してください。

## 変更方針
- 現状: モノリシックRails APIにすべてのロジックが集約
- 変更: 通知機能を非同期ワーカー（Sidekiq → Amazon SQS + Lambda）へ分離
- 理由: 通知処理のタイムアウトがAPIレスポンスに影響している

## RFCの構成
1. 背景と課題（現状の何が問題か、数値で示す）
2. 提案するアーキテクチャ（Before / After図を言語で表現）
3. 技術的選定理由（SQS vs SNS vs Sidekiq継続の比較）
4. 移行計画（段階的リリースの手順）
5. リスクと緩和策
6. 未解決の問題（チームで議論すべき点）

各セクションを段階的に展開してください。

1on1の議題設計と課題の構造化

## 役割
あなたはエンジニアリングマネージャーの思考をサポートするコーチです。

## タスク
以下のメンバー情報をもとに、次の1on1で扱うべき議題を優先度順に整理してください。

## 制約
- 各議題に「EMが事前に準備すべき情報」を添える
- 「問題」ではなく「成長機会」として表現する

## メンバー情報（直近2週間の観察）
- スプリントの消化率が60%程度（例月は85%）
- PRレビューのレスポンスが遅くなっている
- 朝会で発言が減った
- 先週「将来のキャリアについて考えている」と雑談で発言

## 出力
優先度1〜3の議題を整理し、各議題の「聞き方の例文」も添えてください。

## 役割
あなたはエンジニアリングマネージャーの思考をサポートするコーチです。

## タスク
以下のメンバー情報をもとに、次の1on1で扱うべき議題を優先度順に整理してください。

## 制約
- 各議題に「EMが事前に準備すべき情報」を添える
- 「問題」ではなく「成長機会」として表現する

## メンバー情報（直近2週間の観察）
- スプリントの消化率が60%程度（例月は85%）
- PRレビューのレスポンスが遅くなっている
- 朝会で発言が減った
- 先週「将来のキャリアについて考えている」と雑談で発言

## 出力
優先度1〜3の議題を整理し、各議題の「聞き方の例文」も添えてください。

4. コンテキストエンジニアリングとの違い：概念の進化をどう捉えるか

2025年に広まった新概念

2025年6月、元Tesla AI部門責任者のAndrej Karpathy氏と、ShopifyのCEOであるTobi Lütke氏がほぼ同時期にSNSで言及したことで、コンテキストエンジニアリングという概念が急速に広まりました。LangChainもこれを受けてブログ（※8）でまとめを公開しています。

プロンプト設計との関係

コンテキストエンジニアリングの本質は「LLMのコンテキストウィンドウの中に何を入れるかという設計問題」です。これはプロンプトエンジニアリングより上位の概念として捉えるとわかりやすいです。

観点	プロンプトエンジニアリング	コンテキストエンジニアリング
スコープ	テキスト指示の設計・最適化	コンテキストウィンドウ全体の設計
対象	ユーザーが書く指示文	指示・ドキュメント・会話履歴・ツール出力すべて
主な利用場面	チャット・単発のタスク	RAG・エージェント・マルチステップワークフロー
技術的要素	語彙・構造・例示	検索・圧縮・優先順位付け・メモリ管理

プロンプトエンジニアリングはコンテキストエンジニアリングの一部として包含される関係です。単発のチャット利用では「良いプロンプトを書く」で十分ですが、RAGシステムやエージェントを構築する段階では、検索結果をどう整形してコンテキストに注入するか、会話履歴をどう圧縮するか、ツール呼び出し結果をどう扱うかという設計が問われます。

エンジニア視点での捉え方

RAGを例に取ると、「ユーザーの質問をどう検索クエリに変換するか」「取得したドキュメントをどの順序・形式でプロンプトに組み込むか」「コンテキスト長の制限に対してどう優先度付けするか」がすべてコンテキストエンジニアリングの問題です。プロンプト設計はその中の「指示の書き方」の部分を担います。

エージェントアーキテクチャでは、ツール呼び出し結果・外部APIのレスポンス・過去のステップの出力がすべてコンテキストウィンドウに積み上がります。ウィンドウの管理が雑だと、古い情報が新しい判断を汚染したり、重要なシステムプロンプトが「流れてしまう」現象が起きます。これはプロンプトの書き方だけでは解決できない、システム設計の問題です。

5. プロンプトエンジニアリングの学習方法：習得ステップとリソース

コードと同じように扱う

エンジニアがプロンプトを学ぶ際に最も重要な視点は「プロンプトはコードと同じように管理する」という考え方です。場当たり的に試して「なんとなくうまくいった」で終わらせると、再現性がなく、チームに展開できません。

ステップ1：基礎手法を自分の業務で試す（1〜2週間）

まずOpenAI（※1）とAnthropic（※2）の公式ドキュメントを通読します。読むだけでなく、自分が普段行うタスク（コードレビュー・仕様確認・障害分析など）に対して実際に各手法を試します。「Zero-shotで出した結果」「Few-shotを追加した結果」を比較記録することで、手法の効果を体感できます。

ステップ2：プロンプトの改善サイクルを回す

試したプロンプトをバージョンのように管理し、検証→改善のサイクルを回します。コードのように「なぜこう変えたか」をコメントで残すと、改善ループが回しやすくなります。

ステップ3：テストケースを作る（1〜2週間）

良いプロンプトは良いテストで担保します。「このインプットに対してこういう出力が出るべき」というゴールデンデータセットを数件作り、プロンプトを変えるたびに全件確認する習慣をつけます。PromptFooやLangSmithといったプロンプトテストツールを使えば、評価を半自動化できます。回帰テストと同じ考え方です。

ステップ4：改善ループを仕組み化する

「期待通りでなかった出力」を記録しておき、原因仮説（指示が曖昧・例示が少ない・ロールが広すぎる等）を立てて修正します。このデバッグサイクルはソフトウェアのバグ修正と構造的に同じです。失敗パターンを蓄積することが、チームのプロンプト設計力を底上げします。

推奨リソース

Prompt Engineering Guide（promptingguide.ai）：手法・事例・研究動向を網羅した英語の定番リファレンス
Anthropic公式ドキュメント “Prompt engineering overview” ※2：Claudeモデルに合わせたベストプラクティスが随時更新
OpenAI公式ドキュメント “Prompt Engineering” ※1：GPT系モデルへの実装に直結する具体例が豊富

6. チームへの組織的導入：企業活用の進め方

「プロンプトもコードと同じく管理する」という原則

チーム導入で最もよく見るアンチパターンは「各メンバーが各自でプロンプトを工夫し、組織に蓄積されない」状態です。個人の知識資産がチームの資産にならないのは、ソースコードをローカルにしか置かない状態と同じです。

もう一つ頻繁に見る失敗が「プロンプトライブラリを作ったが誰も使わなかった」です。丁寧にテンプレートを整備しても、日常の開発フローに組み込まれていなければ形骸化します。「プロンプトを使う」という行動が、既存のワークフロー（PRテンプレート・CIチェック・オンボーディングドキュメント）に自然に埋め込まれていることが定着の条件です。

フェーズ1：個人実験フェーズ（1〜2ヶ月）

テックリードやエンジニア有志が、実業務の中で各手法を試します。ルールを強制せず、「何に使ったか・どう変えたか・結果はどうだったか」をSlackチャンネルや社内Wikiに気軽に共有する文化を作ります。「仕様確認の往復が3回から1回になった」「インシデント仮説の列挙が10分でできた」といった具体的な体験が、チームへの普及を最も効果的に促します。

フェーズ2：プロンプトライブラリの整備（2〜3ヶ月目）

個人実験で「これは使える」となったプロンプトをGitリポジトリに集約します。

prompts/
├── code-review/
│   ├── pr-review.md            # PRレビュー汎用テンプレート
│   ├── security-review.md      # セキュリティ観点レビュー
│   └── accessibility-review.md # WCAG 2.2準拠チェック
├── architecture/
│   ├── tradeoff-analysis.md    # トレードオフ分析
│   └── rfc-draft.md            # RFC作成補助
├── debugging/
│   └── incident-analysis.md    # 障害分析
└── docs/
    ├── spec-review.md           # 仕様書レビュー
    └── bug-report.md            # バグ報告書統一

prompts/
├── code-review/
│   ├── pr-review.md            # PRレビュー汎用テンプレート
│   ├── security-review.md      # セキュリティ観点レビュー
│   └── accessibility-review.md # WCAG 2.2準拠チェック
├── architecture/
│   ├── tradeoff-analysis.md    # トレードオフ分析
│   └── rfc-draft.md            # RFC作成補助
├── debugging/
│   └── incident-analysis.md    # 障害分析
└── docs/
    ├── spec-review.md           # 仕様書レビュー
    └── bug-report.md            # バグ報告書統一

各ファイルの先頭に「使い方・適用場面・使用手法」をコメントとして残します。新メンバーのオンボーディングドキュメントとしても機能します。

フェーズ3：CI/CD統合とガードレールの整備（3〜4ヶ月目）

プロンプトライブラリが充実してきたら、開発基盤との統合に目を向けます。特に重要なのが以下の2点です。

ガードレール設計：LLMに渡す情報の管理

コードをLLMに渡す際、APIキー・シークレット・個人情報が含まれていないかをprecommitフックやCIで自動チェックする仕組みが必要です。Gitリポジトリにプロンプトを管理する場合も同様で、「何を入力として許容するか」のルールをチームで明文化します。

CI/CDへのプロンプトテスト統合

プロンプトをコードと同様にバージョン管理するなら、変更時の回帰テストもCIに組み込むべきです。PromptFooのようなツールを使えば、プロンプトの変更がゴールデンデータセットに対して期待通りの出力を返すかをPRのCIチェックとして自動実行できます。「プロンプトを変更したらCIが落ちた」という状態を作ることで、品質の劣化を早期検知できます。

フェーズ4：定量評価と改善サイクルの確立（4ヶ月目以降）

プロンプトの効果を「タスクの所要時間」「出力の再利用率」「修正ラウンド数」といった指標で測ります。ここで重要なのは、プロンプトエンジニアリングの効果をポイント改善として捉えず、開発フロー全体のスループットで評価することです。実装工程の速度が上がっても、レビューやQAが詰まっているなら全体のアウトプット量は変わりません。改善施策がどの工程に効いて、次のボトルネックはどこか——この視点でスプリントレトロなどで定期的に確認します。

7. まとめ

本記事で押さえたポイントを5点でまとめます。

プロンプトエンジニアリングはLLMへのインターフェース設計：LLMはトークン予測モデルであり、入力の構造が出力の確率分布を決める。「なんとなく聞く」と「設計して聞く」では品質に明確な差が出る。
手法は目的別に使い分ける：汎用タスクはZero-shot、フォーマット統一はFew-shot、推論・分析はCoT、専門的な観点はRole Prompting、チーム再利用には深津式。組み合わせ可能。
効く場所・効かない場所を理解する：プロンプトを工夫してもハルシネーションはゼロにならない。また、実装工程だけ改善してもレビュー・QAがボトルネックなら開発フロー全体のアウトプットは変わらない。
プロンプトはコードと同様に管理する：バージョン管理・テスト・CI統合・ガードレール設計まで含めて「開発基盤」として整備することで、個人知識がチームの資産に変わる。
チーム導入は既存ワークフローへの埋め込みがカギ：ライブラリを作るだけでは形骸化する。PRテンプレート・CIチェック・オンボーディングドキュメントに自然に組み込まれて初めて定着する。

チームのAI活用を標準化・再現可能な形で進めるには、個人のプロンプト技術だけでなく、開発ワークフロー全体の設計が必要です。Findy Team+ では、エンジニア組織の開発生産性を計測・可視化し、AIを含む改善施策の効果検証をデータドリブンで行う機能を提供しています。「プロンプト改善が実際にスループットに効いているか」を定量で追いたいチームに、2週間の無料トライアルから始められます。

【4/21（火）開催！コンテキストエンジニアリングについてのイベントお申込みはこちら！】

【Findy Team+について詳しく知りたい方はこちら！】

参考・出典

OpenAI「Prompt engineering」公式ドキュメント、2024年。URL: https://developers.openai.com/api/docs/guides/prompt-engineering/
Anthropic「Prompt engineering overview」公式ドキュメント、2024年。URL: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
Anthropic「Use examples effectively」公式ドキュメント、2024年。URL: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/multishot-prompting
Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed Chi, Quoc Le, Denny Zhou「Chain-of-Thought Prompting Elicits Reasoning in Large Language Models」NeurIPS、2022年。URL: https://arxiv.org/abs/2201.11903
Takeshi Kojima, Shixiang Shane Gu, Machel Reid, Yutaka Matsuo, Yusuke Iwasawa「Large Language Models are Zero-Shot Reasoners」NeurIPS、2022年。URL: https://arxiv.org/abs/2205.11916
弁護士ドットコム株式会社「CXO（Chief Experience Officer）就任に関するお知らせ」PR TIMES、2025年2月12日。URL: https://prtimes.jp/main/html/rd/p/000000475.000044347.html
W3C Web Accessibility Initiative (WAI)「WCAG 2 Overview」2023年。URL: https://www.w3.org/WAI/standards-guidelines/wcag/
LangChain公式ブログ「Context Engineering」2025年7月2日。URL: https://blog.langchain.com/context-engineering-for-agents/

*本記事は2026年3月時点の情報に基づいています。モデルのアップデートや新手法の登場に伴い、内容を随時見直します。*

1. プロンプトエンジニアリングとは？基本概念と定義

定義：LLMへのインターフェース設計

要するに、「LLMへの入力を構造化することで、期待するレスポンスの品質を高められる」という手法です。

ハルシネーションとプロンプトの限界

コードレビューや障害分析でLLMを使う場合も、出力を必ずバリデーションする設計を前提にしてください。

プロンプトエンジニアリングが効く場所・効かない場所

効果が出やすいもの：

構造化されたドキュメント生成（仕様書レビュー・バグ報告書・RFC）
分析・推論の補助（トレードオフ比較・インシデント仮説列挙）
フォーマット変換・要約（会議ログ整理・PR説明文生成）

プロンプトエンジニアリングだけでは解決しないこと：

レビュー・QAが人手に依存している開発フロー：プロンプトで実装アウトプットが増えても、レビュー工程がボトルネックのままでは開発フロー全体の速度は上がりません。プロンプトエンジニアリングはあくまで個別工程の補助であり、開発ワークフロー全体の設計とセットで考える必要があります。
知識カットオフ以降の情報や組織固有の内部ドキュメントへの参照：プロンプトエンジニアリングだけでなく、RAG・コンテキストエンジニアリングの領域になります。

なぜ今、エンジニアが学ぶべきか

2. 主要手法の解説と使い分け：Zero-shot・Few-shot・CoTほか

2-1. Zero-shot Prompting（ゼロショット）

なぜ効くか

実務プロンプト例：PR差分のコードレビュー

あなたはシニアバックエンドエンジニアです。
以下のGit差分をレビューしてください。

レビュー観点：
- バグ・例外処理の抜け漏れ
- パフォーマンスへの影響
- 可読性・命名の適切さ
- テストの必要性

出力形式：
## 重大度: [CRITICAL / MAJOR / MINOR / NIT]
## 指摘箇所: <ファイル名>:<行番号>
## 問題: <何が問題か>
## 提案: <どう直すべきか>

---
<Git差分をここに貼る>

あなたはシニアバックエンドエンジニアです。
以下のGit差分をレビューしてください。

レビュー観点：
- バグ・例外処理の抜け漏れ
- パフォーマンスへの影響
- 可読性・命名の適切さ
- テストの必要性

出力形式：
## 重大度: [CRITICAL / MAJOR / MINOR / NIT]
## 指摘箇所: <ファイル名>:<行番号>
## 問題: <何が問題か>
## 提案: <どう直すべきか>

---
<Git差分をここに貼る>

2-2. Few-shot Prompting（フューショット）

なぜ効くか

実務プロンプト例：バグ報告書の形式統一

以下のフォーマットでバグ報告書を作成してください。

--- 例1 ---
入力: 「ログインボタンを押しても何も起きない（iOS Safari）」
出力:
**タイトル**: ログインボタン無反応（iOS Safari）
**再現手順**:
1. iPhoneのSafariでログイン画面を開く
2. メールアドレス・パスワードを入力
3. 「ログイン」ボタンをタップ
**期待値**: ダッシュボードへ遷移する
**実際の挙動**: 何も起きない（コンソールエラーなし）
**環境**: iOS 17.4 / Safari 17 / iPhone 15

--- 例2 ---
入力: 「CSVエクスポートが空ファイルになる」
出力:
**タイトル**: CSVエクスポート結果が空ファイル
**再現手順**:
1. レポート画面を開く
2. 対象期間を選択
3. 「CSVエクスポート」をクリック
**期待値**: データが含まれたCSVファイルがダウンロードされる
**実際の挙動**: 0バイトのCSVファイルがダウンロードされる
**環境**: Chrome 124 / Windows 11

---
入力: 「検索フィルターを適用すると500エラーが出る」
出力:

以下のフォーマットでバグ報告書を作成してください。

--- 例1 ---
入力: 「ログインボタンを押しても何も起きない（iOS Safari）」
出力:
**タイトル**: ログインボタン無反応（iOS Safari）
**再現手順**:
1. iPhoneのSafariでログイン画面を開く
2. メールアドレス・パスワードを入力
3. 「ログイン」ボタンをタップ
**期待値**: ダッシュボードへ遷移する
**実際の挙動**: 何も起きない（コンソールエラーなし）
**環境**: iOS 17.4 / Safari 17 / iPhone 15

--- 例2 ---
入力: 「CSVエクスポートが空ファイルになる」
出力:
**タイトル**: CSVエクスポート結果が空ファイル
**再現手順**:
1. レポート画面を開く
2. 対象期間を選択
3. 「CSVエクスポート」をクリック
**期待値**: データが含まれたCSVファイルがダウンロードされる
**実際の挙動**: 0バイトのCSVファイルがダウンロードされる
**環境**: Chrome 124 / Windows 11

---
入力: 「検索フィルターを適用すると500エラーが出る」
出力:

例示の数は2〜5件が実用的なバランスです。例示が多いほど精度は上がりますが、トークンコストも増えるためタスクの複雑さに応じて調整します。

2-3. Chain-of-Thought（CoT）プロンプティング

なぜ効くか

実務プロンプト例：アーキテクチャ選定のトレードオフ分析

以下のシステム要件に対して、アーキテクチャの選択肢をトレードオフ分析してください。
結論を出す前に、各選択肢の長所・短所・リスクを段階的に検討してください。

## システム要件
- DAU: 50万人
- ピーク時リクエスト: 10,000 req/sec
- データ書き込み頻度: 高（ユーザーイベントを常時記録）
- 読み取りレイテンシ要件: p99 < 100ms
- チームのRailsおよびPostgreSQL経験: 3年以上
- Kubernetes運用経験: なし

## 検討する選択肢
A. モノリシックRails + PostgreSQL（既存構成の垂直スケール）
B. Rails + PostgreSQL + Redisキャッシュ層
C. マイクロサービス + Kafka + 複数データストア

## 分析ステップ
1. 各選択肢がリクエスト要件を満たせるか検討する
2. チームのスキルセットとの適合性を評価する
3. 運用コスト・障害リスクを比較する
4. 最終推奨を根拠とともに述べる

以下のシステム要件に対して、アーキテクチャの選択肢をトレードオフ分析してください。
結論を出す前に、各選択肢の長所・短所・リスクを段階的に検討してください。

## システム要件
- DAU: 50万人
- ピーク時リクエスト: 10,000 req/sec
- データ書き込み頻度: 高（ユーザーイベントを常時記録）
- 読み取りレイテンシ要件: p99 < 100ms
- チームのRailsおよびPostgreSQL経験: 3年以上
- Kubernetes運用経験: なし

## 検討する選択肢
A. モノリシックRails + PostgreSQL（既存構成の垂直スケール）
B. Rails + PostgreSQL + Redisキャッシュ層
C. マイクロサービス + Kafka + 複数データストア

## 分析ステップ
1. 各選択肢がリクエスト要件を満たせるか検討する
2. チームのスキルセットとの適合性を評価する
3. 運用コスト・障害リスクを比較する
4. 最終推奨を根拠とともに述べる

2-4. Role Prompting（ロールプロンプティング）

なぜ効くか

実務プロンプト例：SREとしてインフラ設計をレビュー

あなたはSite Reliability Engineer（SRE）です。
SLO・障害対応・運用コストの観点から、以下のインフラ設計をレビューしてください。

## 設計概要
- ALB → ECS Fargate（オートスケーリング）→ RDS Aurora MySQL
- デプロイ: GitHub Actions → ECR → ECS Blue/Green
- ログ: CloudWatch Logs
- 監視: CloudWatch Metrics + PagerDuty

## レビュー観点
1. SLO99.9%達成のボトルネックになりそうな箇所はどこか
2. 障害時の切り戻し手順に設計上の問題はないか
3. 運用コスト削減のために変更すべき点はあるか
4. 追加すべき監視項目・アラートは何か

各観点について、具体的なリスクと改善提案を挙げてください。

あなたはSite Reliability Engineer（SRE）です。
SLO・障害対応・運用コストの観点から、以下のインフラ設計をレビューしてください。

## 設計概要
- ALB → ECS Fargate（オートスケーリング）→ RDS Aurora MySQL
- デプロイ: GitHub Actions → ECR → ECS Blue/Green
- ログ: CloudWatch Logs
- 監視: CloudWatch Metrics + PagerDuty

## レビュー観点
1. SLO99.9%達成のボトルネックになりそうな箇所はどこか
2. 障害時の切り戻し手順に設計上の問題はないか
3. 運用コスト削減のために変更すべき点はあるか
4. 追加すべき監視項目・アラートは何か

各観点について、具体的なリスクと改善提案を挙げてください。

2-5. 深津式プロンプト

なぜ効くか

実務プロンプト例：仕様書レビューの構造化プロンプト

## 役割
あなたはプロダクト開発経験10年以上のシニアソフトウェアエンジニアです。

## タスク
以下の機能仕様書をエンジニアリング視点でレビューしてください。

## 制約条件
- 実装上の曖昧さ・矛盾・抜け漏れに絞って指摘する
- UXや文章表現の指摘は対象外
- 各指摘は「問題」「影響範囲」「確認すべき質問」の3点セットで書く
- 指摘は重要度順（MUST / SHOULD / NICE TO HAVE）に分類する

## 出力形式
### [重要度] 指摘タイトル
**問題**: （何が不明・矛盾しているか）
**影響範囲**: （どのコンポーネント・ユーザーフローに影響するか）
**確認すべき質問**: （PMまたは設計者に確認すべき具体的な質問）

## 入力（仕様書）
<仕様書をここに貼る>

## 役割
あなたはプロダクト開発経験10年以上のシニアソフトウェアエンジニアです。

## タスク
以下の機能仕様書をエンジニアリング視点でレビューしてください。

## 制約条件
- 実装上の曖昧さ・矛盾・抜け漏れに絞って指摘する
- UXや文章表現の指摘は対象外
- 各指摘は「問題」「影響範囲」「確認すべき質問」の3点セットで書く
- 指摘は重要度順（MUST / SHOULD / NICE TO HAVE）に分類する

## 出力形式
### [重要度] 指摘タイトル
**問題**: （何が不明・矛盾しているか）
**影響範囲**: （どのコンポーネント・ユーザーフローに影響するか）
**確認すべき質問**: （PMまたは設計者に確認すべき具体的な質問）

## 入力（仕様書）
<仕様書をここに貼る>

手法選択の目安

手法	向いているケース	トークンコスト
Zero-shot	汎用的なタスク・素早く試したい	低
Few-shot	出力フォーマットを統一したい	中〜高
CoT	推論・設計判断・複雑な分析	中
Role Prompting	専門的な観点が必要	低（組み合わせ可）
深津式	チームで再利用するテンプレート	中

3. プロンプトエンジニアリングの実例：ユースケースと推奨手法

主なユースケース	推奨手法
コードレビュー・API設計・SQL最適化・障害分析	Zero-shot + Role
アクセシビリティ検査・コンポーネント設計・パフォーマンス改善	Few-shot + CoT
アーキテクチャ選定・技術的負債評価・RFC作成	CoT + 深津式
1on1準備・採用基準整理・チームの課題構造化	深津式 + Role

SQL実行計画の分析

パフォーマンス劣化の原因を探るとき、EXPLAIN結果をそのままLLMに渡して分析させる使い方は即効性が高いです。

あなたはPostgreSQLの最適化に精通したデータベースエンジニアです。
以下のEXPLAIN ANALYZE結果を分析し、パフォーマンス改善のボトルネックを特定してください。

## テーブル概要
- usersテーブル: 500万行
- ordersテーブル: 3000万行
- インデックス: users(id), orders(user_id, created_at)

## EXPLAIN ANALYZE結果
<EXPLAIN ANALYZEの出力をここに貼る>

## 出力
1. ボトルネックになっている処理（Seq Scan・Hash Join等）を特定する
2. 推定コストと実際のコストの乖離を指摘する
3. 具体的なインデックス追加またはクエリ書き換え案を示す

あなたはPostgreSQLの最適化に精通したデータベースエンジニアです。
以下のEXPLAIN ANALYZE結果を分析し、パフォーマンス改善のボトルネックを特定してください。

## テーブル概要
- usersテーブル: 500万行
- ordersテーブル: 3000万行
- インデックス: users(id), orders(user_id, created_at)

## EXPLAIN ANALYZE結果
<EXPLAIN ANALYZEの出力をここに貼る>

## 出力
1. ボトルネックになっている処理（Seq Scan・Hash Join等）を特定する
2. 推定コストと実際のコストの乖離を指摘する
3. 具体的なインデックス追加またはクエリ書き換え案を示す

アクセシビリティ（WCAG 2.2）レビュー

あなたはWCAG 2.2の専門家です。
以下のReactコンポーネントをアクセシビリティ観点でレビューしてください。

## チェック観点（WCAG 2.2準拠）
- 1.1.1 非テキストコンテンツ（alt属性の適切さ）
- 1.3.1 情報と関係性（ARIA役割・セマンティクス）
- 2.1.1 キーボード操作の完全サポート
- 2.4.7 フォーカスの視認性
- 4.1.2 名前・役割・値（フォーム要素のラベル）
- 2.5.3 ラベルを含む名称（ボタンテキストとaria-labelの一致）

## 出力形式
### [達成基準番号] 指摘タイトル
**問題**: 何が不適切か
**該当箇所**: コード行またはコンポーネント名
**修正案**: 具体的なコード例

## コンポーネント
<Reactコンポーネントのコードをここに貼る>

あなたはWCAG 2.2の専門家です。
以下のReactコンポーネントをアクセシビリティ観点でレビューしてください。

## チェック観点（WCAG 2.2準拠）
- 1.1.1 非テキストコンテンツ（alt属性の適切さ）
- 1.3.1 情報と関係性（ARIA役割・セマンティクス）
- 2.1.1 キーボード操作の完全サポート
- 2.4.7 フォーカスの視認性
- 4.1.2 名前・役割・値（フォーム要素のラベル）
- 2.5.3 ラベルを含む名称（ボタンテキストとaria-labelの一致）

## 出力形式
### [達成基準番号] 指摘タイトル
**問題**: 何が不適切か
**該当箇所**: コード行またはコンポーネント名
**修正案**: 具体的なコード例

## コンポーネント
<Reactコンポーネントのコードをここに貼る>

RFC（技術提案書）のドラフト作成

アーキテクチャ変更の提案書（RFC）は構成が決まっているため、CoT＋深津式で素早くドラフトを作れます。

## 役割
あなたは大規模Webサービスの設計経験を持つシニアアーキテクトです。

## タスク
以下の変更方針に基づいて、エンジニアチーム向けのRFCドラフトを作成してください。

## 変更方針
- 現状: モノリシックRails APIにすべてのロジックが集約
- 変更: 通知機能を非同期ワーカー（Sidekiq → Amazon SQS + Lambda）へ分離
- 理由: 通知処理のタイムアウトがAPIレスポンスに影響している

## RFCの構成
1. 背景と課題（現状の何が問題か、数値で示す）
2. 提案するアーキテクチャ（Before / After図を言語で表現）
3. 技術的選定理由（SQS vs SNS vs Sidekiq継続の比較）
4. 移行計画（段階的リリースの手順）
5. リスクと緩和策
6. 未解決の問題（チームで議論すべき点）

各セクションを段階的に展開してください。

## 役割
あなたは大規模Webサービスの設計経験を持つシニアアーキテクトです。

## タスク
以下の変更方針に基づいて、エンジニアチーム向けのRFCドラフトを作成してください。

## 変更方針
- 現状: モノリシックRails APIにすべてのロジックが集約
- 変更: 通知機能を非同期ワーカー（Sidekiq → Amazon SQS + Lambda）へ分離
- 理由: 通知処理のタイムアウトがAPIレスポンスに影響している

## RFCの構成
1. 背景と課題（現状の何が問題か、数値で示す）
2. 提案するアーキテクチャ（Before / After図を言語で表現）
3. 技術的選定理由（SQS vs SNS vs Sidekiq継続の比較）
4. 移行計画（段階的リリースの手順）
5. リスクと緩和策
6. 未解決の問題（チームで議論すべき点）

各セクションを段階的に展開してください。

1on1の議題設計と課題の構造化

## 役割
あなたはエンジニアリングマネージャーの思考をサポートするコーチです。

## タスク
以下のメンバー情報をもとに、次の1on1で扱うべき議題を優先度順に整理してください。

## 制約
- 各議題に「EMが事前に準備すべき情報」を添える
- 「問題」ではなく「成長機会」として表現する

## メンバー情報（直近2週間の観察）
- スプリントの消化率が60%程度（例月は85%）
- PRレビューのレスポンスが遅くなっている
- 朝会で発言が減った
- 先週「将来のキャリアについて考えている」と雑談で発言

## 出力
優先度1〜3の議題を整理し、各議題の「聞き方の例文」も添えてください。

## 役割
あなたはエンジニアリングマネージャーの思考をサポートするコーチです。

## タスク
以下のメンバー情報をもとに、次の1on1で扱うべき議題を優先度順に整理してください。

## 制約
- 各議題に「EMが事前に準備すべき情報」を添える
- 「問題」ではなく「成長機会」として表現する

## メンバー情報（直近2週間の観察）
- スプリントの消化率が60%程度（例月は85%）
- PRレビューのレスポンスが遅くなっている
- 朝会で発言が減った
- 先週「将来のキャリアについて考えている」と雑談で発言

## 出力
優先度1〜3の議題を整理し、各議題の「聞き方の例文」も添えてください。

4. コンテキストエンジニアリングとの違い：概念の進化をどう捉えるか

2025年に広まった新概念

プロンプト設計との関係

観点	プロンプトエンジニアリング	コンテキストエンジニアリング
スコープ	テキスト指示の設計・最適化	コンテキストウィンドウ全体の設計
対象	ユーザーが書く指示文	指示・ドキュメント・会話履歴・ツール出力すべて
主な利用場面	チャット・単発のタスク	RAG・エージェント・マルチステップワークフロー
技術的要素	語彙・構造・例示	検索・圧縮・優先順位付け・メモリ管理

エンジニア視点での捉え方

5. プロンプトエンジニアリングの学習方法：習得ステップとリソース

コードと同じように扱う

ステップ1：基礎手法を自分の業務で試す（1〜2週間）

ステップ2：プロンプトの改善サイクルを回す

ステップ3：テストケースを作る（1〜2週間）

ステップ4：改善ループを仕組み化する

推奨リソース

Prompt Engineering Guide（promptingguide.ai）：手法・事例・研究動向を網羅した英語の定番リファレンス
Anthropic公式ドキュメント “Prompt engineering overview” ※2：Claudeモデルに合わせたベストプラクティスが随時更新
OpenAI公式ドキュメント “Prompt Engineering” ※1：GPT系モデルへの実装に直結する具体例が豊富

6. チームへの組織的導入：企業活用の進め方

「プロンプトもコードと同じく管理する」という原則

フェーズ1：個人実験フェーズ（1〜2ヶ月）

フェーズ2：プロンプトライブラリの整備（2〜3ヶ月目）

個人実験で「これは使える」となったプロンプトをGitリポジトリに集約します。

prompts/
├── code-review/
│   ├── pr-review.md            # PRレビュー汎用テンプレート
│   ├── security-review.md      # セキュリティ観点レビュー
│   └── accessibility-review.md # WCAG 2.2準拠チェック
├── architecture/
│   ├── tradeoff-analysis.md    # トレードオフ分析
│   └── rfc-draft.md            # RFC作成補助
├── debugging/
│   └── incident-analysis.md    # 障害分析
└── docs/
    ├── spec-review.md           # 仕様書レビュー
    └── bug-report.md            # バグ報告書統一

prompts/
├── code-review/
│   ├── pr-review.md            # PRレビュー汎用テンプレート
│   ├── security-review.md      # セキュリティ観点レビュー
│   └── accessibility-review.md # WCAG 2.2準拠チェック
├── architecture/
│   ├── tradeoff-analysis.md    # トレードオフ分析
│   └── rfc-draft.md            # RFC作成補助
├── debugging/
│   └── incident-analysis.md    # 障害分析
└── docs/
    ├── spec-review.md           # 仕様書レビュー
    └── bug-report.md            # バグ報告書統一

フェーズ3：CI/CD統合とガードレールの整備（3〜4ヶ月目）

プロンプトライブラリが充実してきたら、開発基盤との統合に目を向けます。特に重要なのが以下の2点です。

ガードレール設計：LLMに渡す情報の管理

CI/CDへのプロンプトテスト統合

フェーズ4：定量評価と改善サイクルの確立（4ヶ月目以降）

7. まとめ

本記事で押さえたポイントを5点でまとめます。

プロンプトエンジニアリングはLLMへのインターフェース設計：LLMはトークン予測モデルであり、入力の構造が出力の確率分布を決める。「なんとなく聞く」と「設計して聞く」では品質に明確な差が出る。
手法は目的別に使い分ける：汎用タスクはZero-shot、フォーマット統一はFew-shot、推論・分析はCoT、専門的な観点はRole Prompting、チーム再利用には深津式。組み合わせ可能。
効く場所・効かない場所を理解する：プロンプトを工夫してもハルシネーションはゼロにならない。また、実装工程だけ改善してもレビュー・QAがボトルネックなら開発フロー全体のアウトプットは変わらない。
プロンプトはコードと同様に管理する：バージョン管理・テスト・CI統合・ガードレール設計まで含めて「開発基盤」として整備することで、個人知識がチームの資産に変わる。
チーム導入は既存ワークフローへの埋め込みがカギ：ライブラリを作るだけでは形骸化する。PRテンプレート・CIチェック・オンボーディングドキュメントに自然に組み込まれて初めて定着する。

【4/21（火）開催！コンテキストエンジニアリングについてのイベントお申込みはこちら！】

【Findy Team+について詳しく知りたい方はこちら！】

参考・出典

OpenAI「Prompt engineering」公式ドキュメント、2024年。URL: https://developers.openai.com/api/docs/guides/prompt-engineering/
Anthropic「Prompt engineering overview」公式ドキュメント、2024年。URL: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
Anthropic「Use examples effectively」公式ドキュメント、2024年。URL: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/multishot-prompting
Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed Chi, Quoc Le, Denny Zhou「Chain-of-Thought Prompting Elicits Reasoning in Large Language Models」NeurIPS、2022年。URL: https://arxiv.org/abs/2201.11903
Takeshi Kojima, Shixiang Shane Gu, Machel Reid, Yutaka Matsuo, Yusuke Iwasawa「Large Language Models are Zero-Shot Reasoners」NeurIPS、2022年。URL: https://arxiv.org/abs/2205.11916
弁護士ドットコム株式会社「CXO（Chief Experience Officer）就任に関するお知らせ」PR TIMES、2025年2月12日。URL: https://prtimes.jp/main/html/rd/p/000000475.000044347.html
W3C Web Accessibility Initiative (WAI)「WCAG 2 Overview」2023年。URL: https://www.w3.org/WAI/standards-guidelines/wcag/
LangChain公式ブログ「Context Engineering」2025年7月2日。URL: https://blog.langchain.com/context-engineering-for-agents/

*本記事は2026年3月時点の情報に基づいています。モデルのアップデートや新手法の登場に伴い、内容を随時見直します。*

\ 3分でわかる /

資料ダウンロード

Findy Team+のサービス資料は、
こちらからダウンロードできます。

資料をダウンロードする

2026-03-26AI活用

プロンプトエンジニアリングとは？主要手法・実例・チーム導入まで徹底解説【2026年最新版】

1. プロンプトエンジニアリングとは？基本概念と定義

定義：LLMへのインターフェース設計

要するに、「LLMへの入力を構造化することで、期待するレスポンスの品質を高められる」という手法です。

ハルシネーションとプロンプトの限界

コードレビューや障害分析でLLMを使う場合も、出力を必ずバリデーションする設計を前提にしてください。

プロンプトエンジニアリングが効く場所・効かない場所

効果が出やすいもの：

構造化されたドキュメント生成（仕様書レビュー・バグ報告書・RFC）
分析・推論の補助（トレードオフ比較・インシデント仮説列挙）
フォーマット変換・要約（会議ログ整理・PR説明文生成）

プロンプトエンジニアリングだけでは解決しないこと：

レビュー・QAが人手に依存している開発フロー：プロンプトで実装アウトプットが増えても、レビュー工程がボトルネックのままでは開発フロー全体の速度は上がりません。プロンプトエンジニアリングはあくまで個別工程の補助であり、開発ワークフロー全体の設計とセットで考える必要があります。
知識カットオフ以降の情報や組織固有の内部ドキュメントへの参照：プロンプトエンジニアリングだけでなく、RAG・コンテキストエンジニアリングの領域になります。

なぜ今、エンジニアが学ぶべきか

2. 主要手法の解説と使い分け：Zero-shot・Few-shot・CoTほか

2-1. Zero-shot Prompting（ゼロショット）

なぜ効くか

実務プロンプト例：PR差分のコードレビュー

あなたはシニアバックエンドエンジニアです。
以下のGit差分をレビューしてください。

レビュー観点：
- バグ・例外処理の抜け漏れ
- パフォーマンスへの影響
- 可読性・命名の適切さ
- テストの必要性

出力形式：
## 重大度: [CRITICAL / MAJOR / MINOR / NIT]
## 指摘箇所: <ファイル名>:<行番号>
## 問題: <何が問題か>
## 提案: <どう直すべきか>

---
<Git差分をここに貼る>

あなたはシニアバックエンドエンジニアです。
以下のGit差分をレビューしてください。

レビュー観点：
- バグ・例外処理の抜け漏れ
- パフォーマンスへの影響
- 可読性・命名の適切さ
- テストの必要性

出力形式：
## 重大度: [CRITICAL / MAJOR / MINOR / NIT]
## 指摘箇所: <ファイル名>:<行番号>
## 問題: <何が問題か>
## 提案: <どう直すべきか>

---
<Git差分をここに貼る>

2-2. Few-shot Prompting（フューショット）

なぜ効くか

実務プロンプト例：バグ報告書の形式統一

以下のフォーマットでバグ報告書を作成してください。

--- 例1 ---
入力: 「ログインボタンを押しても何も起きない（iOS Safari）」
出力:
**タイトル**: ログインボタン無反応（iOS Safari）
**再現手順**:
1. iPhoneのSafariでログイン画面を開く
2. メールアドレス・パスワードを入力
3. 「ログイン」ボタンをタップ
**期待値**: ダッシュボードへ遷移する
**実際の挙動**: 何も起きない（コンソールエラーなし）
**環境**: iOS 17.4 / Safari 17 / iPhone 15

--- 例2 ---
入力: 「CSVエクスポートが空ファイルになる」
出力:
**タイトル**: CSVエクスポート結果が空ファイル
**再現手順**:
1. レポート画面を開く
2. 対象期間を選択
3. 「CSVエクスポート」をクリック
**期待値**: データが含まれたCSVファイルがダウンロードされる
**実際の挙動**: 0バイトのCSVファイルがダウンロードされる
**環境**: Chrome 124 / Windows 11

---
入力: 「検索フィルターを適用すると500エラーが出る」
出力:

以下のフォーマットでバグ報告書を作成してください。

--- 例1 ---
入力: 「ログインボタンを押しても何も起きない（iOS Safari）」
出力:
**タイトル**: ログインボタン無反応（iOS Safari）
**再現手順**:
1. iPhoneのSafariでログイン画面を開く
2. メールアドレス・パスワードを入力
3. 「ログイン」ボタンをタップ
**期待値**: ダッシュボードへ遷移する
**実際の挙動**: 何も起きない（コンソールエラーなし）
**環境**: iOS 17.4 / Safari 17 / iPhone 15

--- 例2 ---
入力: 「CSVエクスポートが空ファイルになる」
出力:
**タイトル**: CSVエクスポート結果が空ファイル
**再現手順**:
1. レポート画面を開く
2. 対象期間を選択
3. 「CSVエクスポート」をクリック
**期待値**: データが含まれたCSVファイルがダウンロードされる
**実際の挙動**: 0バイトのCSVファイルがダウンロードされる
**環境**: Chrome 124 / Windows 11

---
入力: 「検索フィルターを適用すると500エラーが出る」
出力:

例示の数は2〜5件が実用的なバランスです。例示が多いほど精度は上がりますが、トークンコストも増えるためタスクの複雑さに応じて調整します。

2-3. Chain-of-Thought（CoT）プロンプティング

なぜ効くか

実務プロンプト例：アーキテクチャ選定のトレードオフ分析

以下のシステム要件に対して、アーキテクチャの選択肢をトレードオフ分析してください。
結論を出す前に、各選択肢の長所・短所・リスクを段階的に検討してください。

## システム要件
- DAU: 50万人
- ピーク時リクエスト: 10,000 req/sec
- データ書き込み頻度: 高（ユーザーイベントを常時記録）
- 読み取りレイテンシ要件: p99 < 100ms
- チームのRailsおよびPostgreSQL経験: 3年以上
- Kubernetes運用経験: なし

## 検討する選択肢
A. モノリシックRails + PostgreSQL（既存構成の垂直スケール）
B. Rails + PostgreSQL + Redisキャッシュ層
C. マイクロサービス + Kafka + 複数データストア

## 分析ステップ
1. 各選択肢がリクエスト要件を満たせるか検討する
2. チームのスキルセットとの適合性を評価する
3. 運用コスト・障害リスクを比較する
4. 最終推奨を根拠とともに述べる

以下のシステム要件に対して、アーキテクチャの選択肢をトレードオフ分析してください。
結論を出す前に、各選択肢の長所・短所・リスクを段階的に検討してください。

## システム要件
- DAU: 50万人
- ピーク時リクエスト: 10,000 req/sec
- データ書き込み頻度: 高（ユーザーイベントを常時記録）
- 読み取りレイテンシ要件: p99 < 100ms
- チームのRailsおよびPostgreSQL経験: 3年以上
- Kubernetes運用経験: なし

## 検討する選択肢
A. モノリシックRails + PostgreSQL（既存構成の垂直スケール）
B. Rails + PostgreSQL + Redisキャッシュ層
C. マイクロサービス + Kafka + 複数データストア

## 分析ステップ
1. 各選択肢がリクエスト要件を満たせるか検討する
2. チームのスキルセットとの適合性を評価する
3. 運用コスト・障害リスクを比較する
4. 最終推奨を根拠とともに述べる

2-4. Role Prompting（ロールプロンプティング）

なぜ効くか

実務プロンプト例：SREとしてインフラ設計をレビュー

あなたはSite Reliability Engineer（SRE）です。
SLO・障害対応・運用コストの観点から、以下のインフラ設計をレビューしてください。

## 設計概要
- ALB → ECS Fargate（オートスケーリング）→ RDS Aurora MySQL
- デプロイ: GitHub Actions → ECR → ECS Blue/Green
- ログ: CloudWatch Logs
- 監視: CloudWatch Metrics + PagerDuty

## レビュー観点
1. SLO99.9%達成のボトルネックになりそうな箇所はどこか
2. 障害時の切り戻し手順に設計上の問題はないか
3. 運用コスト削減のために変更すべき点はあるか
4. 追加すべき監視項目・アラートは何か

各観点について、具体的なリスクと改善提案を挙げてください。

あなたはSite Reliability Engineer（SRE）です。
SLO・障害対応・運用コストの観点から、以下のインフラ設計をレビューしてください。

## 設計概要
- ALB → ECS Fargate（オートスケーリング）→ RDS Aurora MySQL
- デプロイ: GitHub Actions → ECR → ECS Blue/Green
- ログ: CloudWatch Logs
- 監視: CloudWatch Metrics + PagerDuty

## レビュー観点
1. SLO99.9%達成のボトルネックになりそうな箇所はどこか
2. 障害時の切り戻し手順に設計上の問題はないか
3. 運用コスト削減のために変更すべき点はあるか
4. 追加すべき監視項目・アラートは何か

各観点について、具体的なリスクと改善提案を挙げてください。

2-5. 深津式プロンプト

なぜ効くか

実務プロンプト例：仕様書レビューの構造化プロンプト

## 役割
あなたはプロダクト開発経験10年以上のシニアソフトウェアエンジニアです。

## タスク
以下の機能仕様書をエンジニアリング視点でレビューしてください。

## 制約条件
- 実装上の曖昧さ・矛盾・抜け漏れに絞って指摘する
- UXや文章表現の指摘は対象外
- 各指摘は「問題」「影響範囲」「確認すべき質問」の3点セットで書く
- 指摘は重要度順（MUST / SHOULD / NICE TO HAVE）に分類する

## 出力形式
### [重要度] 指摘タイトル
**問題**: （何が不明・矛盾しているか）
**影響範囲**: （どのコンポーネント・ユーザーフローに影響するか）
**確認すべき質問**: （PMまたは設計者に確認すべき具体的な質問）

## 入力（仕様書）
<仕様書をここに貼る>

## 役割
あなたはプロダクト開発経験10年以上のシニアソフトウェアエンジニアです。

## タスク
以下の機能仕様書をエンジニアリング視点でレビューしてください。

## 制約条件
- 実装上の曖昧さ・矛盾・抜け漏れに絞って指摘する
- UXや文章表現の指摘は対象外
- 各指摘は「問題」「影響範囲」「確認すべき質問」の3点セットで書く
- 指摘は重要度順（MUST / SHOULD / NICE TO HAVE）に分類する

## 出力形式
### [重要度] 指摘タイトル
**問題**: （何が不明・矛盾しているか）
**影響範囲**: （どのコンポーネント・ユーザーフローに影響するか）
**確認すべき質問**: （PMまたは設計者に確認すべき具体的な質問）

## 入力（仕様書）
<仕様書をここに貼る>

手法選択の目安

手法	向いているケース	トークンコスト
Zero-shot	汎用的なタスク・素早く試したい	低
Few-shot	出力フォーマットを統一したい	中〜高
CoT	推論・設計判断・複雑な分析	中
Role Prompting	専門的な観点が必要	低（組み合わせ可）
深津式	チームで再利用するテンプレート	中

3. プロンプトエンジニアリングの実例：ユースケースと推奨手法

主なユースケース	推奨手法
コードレビュー・API設計・SQL最適化・障害分析	Zero-shot + Role
アクセシビリティ検査・コンポーネント設計・パフォーマンス改善	Few-shot + CoT
アーキテクチャ選定・技術的負債評価・RFC作成	CoT + 深津式
1on1準備・採用基準整理・チームの課題構造化	深津式 + Role

SQL実行計画の分析

パフォーマンス劣化の原因を探るとき、EXPLAIN結果をそのままLLMに渡して分析させる使い方は即効性が高いです。

あなたはPostgreSQLの最適化に精通したデータベースエンジニアです。
以下のEXPLAIN ANALYZE結果を分析し、パフォーマンス改善のボトルネックを特定してください。

## テーブル概要
- usersテーブル: 500万行
- ordersテーブル: 3000万行
- インデックス: users(id), orders(user_id, created_at)

## EXPLAIN ANALYZE結果
<EXPLAIN ANALYZEの出力をここに貼る>

## 出力
1. ボトルネックになっている処理（Seq Scan・Hash Join等）を特定する
2. 推定コストと実際のコストの乖離を指摘する
3. 具体的なインデックス追加またはクエリ書き換え案を示す

あなたはPostgreSQLの最適化に精通したデータベースエンジニアです。
以下のEXPLAIN ANALYZE結果を分析し、パフォーマンス改善のボトルネックを特定してください。

## テーブル概要
- usersテーブル: 500万行
- ordersテーブル: 3000万行
- インデックス: users(id), orders(user_id, created_at)

## EXPLAIN ANALYZE結果
<EXPLAIN ANALYZEの出力をここに貼る>

## 出力
1. ボトルネックになっている処理（Seq Scan・Hash Join等）を特定する
2. 推定コストと実際のコストの乖離を指摘する
3. 具体的なインデックス追加またはクエリ書き換え案を示す

アクセシビリティ（WCAG 2.2）レビュー

あなたはWCAG 2.2の専門家です。
以下のReactコンポーネントをアクセシビリティ観点でレビューしてください。

## チェック観点（WCAG 2.2準拠）
- 1.1.1 非テキストコンテンツ（alt属性の適切さ）
- 1.3.1 情報と関係性（ARIA役割・セマンティクス）
- 2.1.1 キーボード操作の完全サポート
- 2.4.7 フォーカスの視認性
- 4.1.2 名前・役割・値（フォーム要素のラベル）
- 2.5.3 ラベルを含む名称（ボタンテキストとaria-labelの一致）

## 出力形式
### [達成基準番号] 指摘タイトル
**問題**: 何が不適切か
**該当箇所**: コード行またはコンポーネント名
**修正案**: 具体的なコード例

## コンポーネント
<Reactコンポーネントのコードをここに貼る>

あなたはWCAG 2.2の専門家です。
以下のReactコンポーネントをアクセシビリティ観点でレビューしてください。

## チェック観点（WCAG 2.2準拠）
- 1.1.1 非テキストコンテンツ（alt属性の適切さ）
- 1.3.1 情報と関係性（ARIA役割・セマンティクス）
- 2.1.1 キーボード操作の完全サポート
- 2.4.7 フォーカスの視認性
- 4.1.2 名前・役割・値（フォーム要素のラベル）
- 2.5.3 ラベルを含む名称（ボタンテキストとaria-labelの一致）

## 出力形式
### [達成基準番号] 指摘タイトル
**問題**: 何が不適切か
**該当箇所**: コード行またはコンポーネント名
**修正案**: 具体的なコード例

## コンポーネント
<Reactコンポーネントのコードをここに貼る>

RFC（技術提案書）のドラフト作成

アーキテクチャ変更の提案書（RFC）は構成が決まっているため、CoT＋深津式で素早くドラフトを作れます。

## 役割
あなたは大規模Webサービスの設計経験を持つシニアアーキテクトです。

## タスク
以下の変更方針に基づいて、エンジニアチーム向けのRFCドラフトを作成してください。

## 変更方針
- 現状: モノリシックRails APIにすべてのロジックが集約
- 変更: 通知機能を非同期ワーカー（Sidekiq → Amazon SQS + Lambda）へ分離
- 理由: 通知処理のタイムアウトがAPIレスポンスに影響している

## RFCの構成
1. 背景と課題（現状の何が問題か、数値で示す）
2. 提案するアーキテクチャ（Before / After図を言語で表現）
3. 技術的選定理由（SQS vs SNS vs Sidekiq継続の比較）
4. 移行計画（段階的リリースの手順）
5. リスクと緩和策
6. 未解決の問題（チームで議論すべき点）

各セクションを段階的に展開してください。

## 役割
あなたは大規模Webサービスの設計経験を持つシニアアーキテクトです。

## タスク
以下の変更方針に基づいて、エンジニアチーム向けのRFCドラフトを作成してください。

## 変更方針
- 現状: モノリシックRails APIにすべてのロジックが集約
- 変更: 通知機能を非同期ワーカー（Sidekiq → Amazon SQS + Lambda）へ分離
- 理由: 通知処理のタイムアウトがAPIレスポンスに影響している

## RFCの構成
1. 背景と課題（現状の何が問題か、数値で示す）
2. 提案するアーキテクチャ（Before / After図を言語で表現）
3. 技術的選定理由（SQS vs SNS vs Sidekiq継続の比較）
4. 移行計画（段階的リリースの手順）
5. リスクと緩和策
6. 未解決の問題（チームで議論すべき点）

各セクションを段階的に展開してください。

1on1の議題設計と課題の構造化

## 役割
あなたはエンジニアリングマネージャーの思考をサポートするコーチです。

## タスク
以下のメンバー情報をもとに、次の1on1で扱うべき議題を優先度順に整理してください。

## 制約
- 各議題に「EMが事前に準備すべき情報」を添える
- 「問題」ではなく「成長機会」として表現する

## メンバー情報（直近2週間の観察）
- スプリントの消化率が60%程度（例月は85%）
- PRレビューのレスポンスが遅くなっている
- 朝会で発言が減った
- 先週「将来のキャリアについて考えている」と雑談で発言

## 出力
優先度1〜3の議題を整理し、各議題の「聞き方の例文」も添えてください。

## 役割
あなたはエンジニアリングマネージャーの思考をサポートするコーチです。

## タスク
以下のメンバー情報をもとに、次の1on1で扱うべき議題を優先度順に整理してください。

## 制約
- 各議題に「EMが事前に準備すべき情報」を添える
- 「問題」ではなく「成長機会」として表現する

## メンバー情報（直近2週間の観察）
- スプリントの消化率が60%程度（例月は85%）
- PRレビューのレスポンスが遅くなっている
- 朝会で発言が減った
- 先週「将来のキャリアについて考えている」と雑談で発言

## 出力
優先度1〜3の議題を整理し、各議題の「聞き方の例文」も添えてください。

4. コンテキストエンジニアリングとの違い：概念の進化をどう捉えるか

2025年に広まった新概念

プロンプト設計との関係

観点	プロンプトエンジニアリング	コンテキストエンジニアリング
スコープ	テキスト指示の設計・最適化	コンテキストウィンドウ全体の設計
対象	ユーザーが書く指示文	指示・ドキュメント・会話履歴・ツール出力すべて
主な利用場面	チャット・単発のタスク	RAG・エージェント・マルチステップワークフロー
技術的要素	語彙・構造・例示	検索・圧縮・優先順位付け・メモリ管理

エンジニア視点での捉え方

5. プロンプトエンジニアリングの学習方法：習得ステップとリソース

コードと同じように扱う

ステップ1：基礎手法を自分の業務で試す（1〜2週間）

ステップ2：プロンプトの改善サイクルを回す

ステップ3：テストケースを作る（1〜2週間）

ステップ4：改善ループを仕組み化する

推奨リソース

Prompt Engineering Guide（promptingguide.ai）：手法・事例・研究動向を網羅した英語の定番リファレンス
Anthropic公式ドキュメント “Prompt engineering overview” ※2：Claudeモデルに合わせたベストプラクティスが随時更新
OpenAI公式ドキュメント “Prompt Engineering” ※1：GPT系モデルへの実装に直結する具体例が豊富

6. チームへの組織的導入：企業活用の進め方

「プロンプトもコードと同じく管理する」という原則

フェーズ1：個人実験フェーズ（1〜2ヶ月）

フェーズ2：プロンプトライブラリの整備（2〜3ヶ月目）

個人実験で「これは使える」となったプロンプトをGitリポジトリに集約します。

prompts/
├── code-review/
│   ├── pr-review.md            # PRレビュー汎用テンプレート
│   ├── security-review.md      # セキュリティ観点レビュー
│   └── accessibility-review.md # WCAG 2.2準拠チェック
├── architecture/
│   ├── tradeoff-analysis.md    # トレードオフ分析
│   └── rfc-draft.md            # RFC作成補助
├── debugging/
│   └── incident-analysis.md    # 障害分析
└── docs/
    ├── spec-review.md           # 仕様書レビュー
    └── bug-report.md            # バグ報告書統一

prompts/
├── code-review/
│   ├── pr-review.md            # PRレビュー汎用テンプレート
│   ├── security-review.md      # セキュリティ観点レビュー
│   └── accessibility-review.md # WCAG 2.2準拠チェック
├── architecture/
│   ├── tradeoff-analysis.md    # トレードオフ分析
│   └── rfc-draft.md            # RFC作成補助
├── debugging/
│   └── incident-analysis.md    # 障害分析
└── docs/
    ├── spec-review.md           # 仕様書レビュー
    └── bug-report.md            # バグ報告書統一

フェーズ3：CI/CD統合とガードレールの整備（3〜4ヶ月目）

プロンプトライブラリが充実してきたら、開発基盤との統合に目を向けます。特に重要なのが以下の2点です。

ガードレール設計：LLMに渡す情報の管理

CI/CDへのプロンプトテスト統合

フェーズ4：定量評価と改善サイクルの確立（4ヶ月目以降）

7. まとめ

本記事で押さえたポイントを5点でまとめます。

プロンプトエンジニアリングはLLMへのインターフェース設計：LLMはトークン予測モデルであり、入力の構造が出力の確率分布を決める。「なんとなく聞く」と「設計して聞く」では品質に明確な差が出る。
手法は目的別に使い分ける：汎用タスクはZero-shot、フォーマット統一はFew-shot、推論・分析はCoT、専門的な観点はRole Prompting、チーム再利用には深津式。組み合わせ可能。
効く場所・効かない場所を理解する：プロンプトを工夫してもハルシネーションはゼロにならない。また、実装工程だけ改善してもレビュー・QAがボトルネックなら開発フロー全体のアウトプットは変わらない。
プロンプトはコードと同様に管理する：バージョン管理・テスト・CI統合・ガードレール設計まで含めて「開発基盤」として整備することで、個人知識がチームの資産に変わる。
チーム導入は既存ワークフローへの埋め込みがカギ：ライブラリを作るだけでは形骸化する。PRテンプレート・CIチェック・オンボーディングドキュメントに自然に組み込まれて初めて定着する。

【4/21（火）開催！コンテキストエンジニアリングについてのイベントお申込みはこちら！】

【Findy Team+について詳しく知りたい方はこちら！】

参考・出典

OpenAI「Prompt engineering」公式ドキュメント、2024年。URL: https://developers.openai.com/api/docs/guides/prompt-engineering/
Anthropic「Prompt engineering overview」公式ドキュメント、2024年。URL: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
Anthropic「Use examples effectively」公式ドキュメント、2024年。URL: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/multishot-prompting
Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed Chi, Quoc Le, Denny Zhou「Chain-of-Thought Prompting Elicits Reasoning in Large Language Models」NeurIPS、2022年。URL: https://arxiv.org/abs/2201.11903
Takeshi Kojima, Shixiang Shane Gu, Machel Reid, Yutaka Matsuo, Yusuke Iwasawa「Large Language Models are Zero-Shot Reasoners」NeurIPS、2022年。URL: https://arxiv.org/abs/2205.11916
弁護士ドットコム株式会社「CXO（Chief Experience Officer）就任に関するお知らせ」PR TIMES、2025年2月12日。URL: https://prtimes.jp/main/html/rd/p/000000475.000044347.html
W3C Web Accessibility Initiative (WAI)「WCAG 2 Overview」2023年。URL: https://www.w3.org/WAI/standards-guidelines/wcag/
LangChain公式ブログ「Context Engineering」2025年7月2日。URL: https://blog.langchain.com/context-engineering-for-agents/

*本記事は2026年3月時点の情報に基づいています。モデルのアップデートや新手法の登場に伴い、内容を随時見直します。*

\ 3分でわかる /

資料ダウンロード

Findy Team+のサービス資料は、
こちらからダウンロードできます。

資料をダウンロードする

プロンプトエンジニアリングとは？主要手法・実例・チーム導入まで徹底解説【2026年最新版】

プロンプトエンジニアリングとは？主要手法・実例・チーム導入まで徹底解説【2026年最新版】

目次

目次

1. プロンプトエンジニアリングとは？基本概念と定義

定義：LLMへのインターフェース設計

ハルシネーションとプロンプトの限界

プロンプトエンジニアリングが効く場所・効かない場所

なぜ今、エンジニアが学ぶべきか

2. 主要手法の解説と使い分け：Zero-shot・Few-shot・CoTほか

2-1. Zero-shot Prompting（ゼロショット）

2-2. Few-shot Prompting（フューショット）

2-3. Chain-of-Thought（CoT）プロンプティング

2-4. Role Prompting（ロールプロンプティング）

2-5. 深津式プロンプト

手法選択の目安

3. プロンプトエンジニアリングの実例：ユースケースと推奨手法

SQL実行計画の分析

アクセシビリティ（WCAG 2.2）レビュー

RFC（技術提案書）のドラフト作成

1on1の議題設計と課題の構造化

4. コンテキストエンジニアリングとの違い：概念の進化をどう捉えるか

2025年に広まった新概念

プロンプト設計との関係

エンジニア視点での捉え方

5. プロンプトエンジニアリングの学習方法：習得ステップとリソース

コードと同じように扱う

ステップ1：基礎手法を自分の業務で試す（1〜2週間）

ステップ2：プロンプトの改善サイクルを回す

ステップ3：テストケースを作る（1〜2週間）

ステップ4：改善ループを仕組み化する

推奨リソース

6. チームへの組織的導入：企業活用の進め方

「プロンプトもコードと同じく管理する」という原則

フェーズ1：個人実験フェーズ（1〜2ヶ月）

フェーズ2：プロンプトライブラリの整備（2〜3ヶ月目）

フェーズ3：CI/CD統合とガードレールの整備（3〜4ヶ月目）

フェーズ4：定量評価と改善サイクルの確立（4ヶ月目以降）

7. まとめ

参考・出典

目次

1. プロンプトエンジニアリングとは？基本概念と定義

定義：LLMへのインターフェース設計

ハルシネーションとプロンプトの限界

プロンプトエンジニアリングが効く場所・効かない場所

なぜ今、エンジニアが学ぶべきか

2. 主要手法の解説と使い分け：Zero-shot・Few-shot・CoTほか

2-1. Zero-shot Prompting（ゼロショット）

2-2. Few-shot Prompting（フューショット）

2-3. Chain-of-Thought（CoT）プロンプティング

2-4. Role Prompting（ロールプロンプティング）

2-5. 深津式プロンプト

手法選択の目安

3. プロンプトエンジニアリングの実例：ユースケースと推奨手法

SQL実行計画の分析

アクセシビリティ（WCAG 2.2）レビュー

RFC（技術提案書）のドラフト作成

1on1の議題設計と課題の構造化

4. コンテキストエンジニアリングとの違い：概念の進化をどう捉えるか

2025年に広まった新概念

プロンプト設計との関係

エンジニア視点での捉え方

5. プロンプトエンジニアリングの学習方法：習得ステップとリソース

コードと同じように扱う

ステップ1：基礎手法を自分の業務で試す（1〜2週間）

ステップ2：プロンプトの改善サイクルを回す

ステップ3：テストケースを作る（1〜2週間）

ステップ4：改善ループを仕組み化する

推奨リソース

6. チームへの組織的導入：企業活用の進め方

「プロンプトもコードと同じく管理する」という原則

フェーズ1：個人実験フェーズ（1〜2ヶ月）

フェーズ2：プロンプトライブラリの整備（2〜3ヶ月目）

フェーズ3：CI/CD統合とガードレールの整備（3〜4ヶ月目）

フェーズ4：定量評価と改善サイクルの確立（4ヶ月目以降）

7. まとめ

参考・出典

プロンプトエンジニアリングとは？主要手法・実例・チーム導入まで徹底解説【2026年最新版】

目次

1. プロンプトエンジニアリングとは？基本概念と定義