FDEのプロンプトエンジニアリング：クライアント現場で使う実践技術

FDEにとってプロンプトエンジニアリングとは、クライアントの業務知識をLLMに素早く伝える技術です。汎用的なプロンプトでは、LLMはその業界・会社・プロジェクトの文脈を知らないため、出力は「使える素材」にとどまります。現場固有の制約・用語・業務フローを丁寧に埋め込むことで、初めて「そのまま使えるか、一手間で済む出力」に変わります。

FDEとは何かについては別記事で詳しく解説しています。本記事では、FDE特有の5つのシーンに絞り、プロンプト設計の具体的なアプローチを示します。

---

結論：現場固有の文脈を持つプロンプトが勝つ

FDEのプロンプト設計で最も効果が出るのは、LLMに「あなたは今どの現場にいるか」を明確に伝えることです。業種・部門・使用システム・制約条件をシステムプロンプトに書いてから作業プロンプトを渡すと、同じ質問でも出力の精度が大きく変わります。

汎用プロンプトで得た出力に毎回手を加えるより、はじめに文脈を設定する30分を惜しまない方が、プロジェクト全体では時間を節約できます。

---

FDEがプロンプトを使う主要5シーン

FDE業務でLLMが最も効果を発揮するのは、以下の5つの場面です。

シーン	目的	プロンプト設計の核
要件の曖昧さ整理	発散した議論を構造化する	論点の分類・前提条件の明示
コード生成	環境に合った動くコードを得る	言語・FW・制約の明示
デモ準備	短時間でたたき台を作る	ゴール・想定聴衆・時間の明示
議事録・ドキュメント構造化	情報を拾いやすい形に変換する	抽出項目の列挙
クライアントへの説明文作成	技術をビジネス言葉に翻訳する	読み手のリテラシーレベルの明示

それぞれを順に解説します。

---

要件の曖昧さをLLMに整理させるプロンプト設計

クライアントとの打ち合わせでは、「なんとなくこういうことがしたい」という発話が頻繁に出ます。この段階でFDEが自分の頭で整理しようとすると時間がかかります。LLMに整理させる方が速く、かつ見落としが少ない。

効果的なアプローチは、発言の断片をそのままプロンプトに渡し、「論点・前提・不足情報・次のステップ」の4項目で整理させることです。

あなたはシステム導入プロジェクトの要件整理を支援するアシスタントです。
以下はクライアントとの打ち合わせメモです。

## 打ち合わせメモ
{ここに会議メモをそのまま貼る}

## 依頼
このメモを次の4項目で整理してください。
1. 確定している要件（クライアントが明示した事項）
2. 前提として置かれているが確認が必要な事項
3. 未決事項・情報不足の箇所
4. 次のアクション候補（担当・期限のたたき台）

箇条書きで出力してください。推測が含まれる場合は「要確認」と明記してください。

このプロンプトで得た出力をそのまま次の打ち合わせの確認事項にできます。「要確認」タグが付いた項目をクライアントと一つずつ潰していく使い方が現場では定着しやすいです。

---

コード生成を現場で使えるレベルに引き上げるプロンプトの工夫

コード生成プロンプトで最も多いミスは、環境情報を省略することです。LLMは最新のライブラリや一般的な書き方を優先しますが、クライアント環境はバージョンが古く、独自のコーディング規約があることが多い。

## 環境
- 言語: Python 3.9
- フレームワーク: FastAPI 0.95
- データベース: PostgreSQL 13（psycopg2を使用）
- コーディング規約: 型アノテーション必須、docstringはGoogle Style
- 制約: 外部ライブラリの追加は禁止。標準ライブラリのみ使用可

## 依頼
以下の仕様でAPIエンドポイントを実装してください。

{仕様をここに記述}

## 出力形式
- コード本体
- 動作確認用のcurlコマンド
- テスト観点（実装はしなくてよい）

環境セクションを毎回書くのが手間であれば、プロジェクト開始時に「環境プロファイル」をテキストファイルとして作成し、プロンプトに貼り付けるだけにする運用が効率的です。

もう一つ効果的なのは、「使えないコードの例」を明示することです。「○○パターンは禁止」と書くと、それを避けた実装が返ってきます。セキュリティ要件が厳しい金融系・医療系のクライアントでは特に有効です。

FDEが使うAIツールでは、コード生成以外のFDE向けAIツールも整理しています。

---

クライアント向けデモ準備を高速化するプロンプト活用

デモ準備でFDEが時間をとられるのは、スライドの構成決め・想定QAの作成・デモシナリオのフロー設計の3つです。これらはLLMが得意な作業です。

スライド構成のたたき台は次のように作れます。

## デモの目的
{クライアント名}の{部門名}に対して、{システム名}の概念実証結果を報告し、
本格導入の承認を得ることが目的です。

## 聴衆
- 意思決定者: 部長クラス3名（IT知識は限定的。コスト・リスク・業務インパクトを重視）
- 技術担当: エンジニア2名（実装可能性を確認したい）

## デモ時間: 40分（デモ15分・質疑25分）

## 依頼
上記を踏まえ、以下を作成してください。
1. スライド構成案（各スライドのタイトルと要点を1〜2行で）
2. 意思決定者から来そうな質問トップ5と回答の方向性
3. デモシナリオの流れ（操作の順序と説明のポイント）

このプロンプトから得たたたき台は、そのまま使えることはありません。クライアント固有の数値・実績・懸念事項への対応は必ず人間が加えます。しかし構成を一から考える時間を省けるため、3〜5時間分の作業がプロンプト実行と見直しの1〜2時間に圧縮できます。

---

ドキュメント・議事録の構造化プロンプトパターン

FDEは1日に複数の打ち合わせをこなすことがあります。議事録を後で書こうとすると記憶が薄れ、「決めたこと」と「検討したこと」が混ざります。会議直後に音声文字起こしや箇条書きメモをLLMに渡し、構造化させる習慣が有効です。

以下は打ち合わせの発言録です。次の形式で構造化してください。

## 発言録
{文字起こしまたはメモをそのまま貼る}

## 出力形式
### 決定事項
- 内容・決定した根拠・担当者

### アクションアイテム
| 内容 | 担当 | 期限 |
|---|---|---|

### 未解決事項
- 論点と現在の状況

### 次回打ち合わせで確認すること
- 箇条書き

推測で補った箇所は「※要確認」を付けてください。

会議の種類によってテンプレートを変えると出力の品質が安定します。概念実証のレビュー会議・要件定義会議・進捗報告会議では、確認すべき項目が異なります。プロジェクト開始時に3〜4種類のテンプレートを作っておくと、以降の議事録作成が大幅に速くなります。

FDEのドキュメンテーション術では、議事録以外のドキュメント管理全体について詳しく解説しています。

---

FDEが避けるべきプロンプトの落とし穴

現場でよく見る失敗パターンをまとめます。

曖昧な依頼で汎用的な出力を受け取り続ける

「APIを実装して」「要件を整理して」のような短いプロンプトは、LLMに文脈がないため必ず一般的な回答が返ります。これを加工し続けるのは、はじめから文脈を書くより時間がかかります。文脈を書く手間を惜しまないことが基本です。

出力をそのまま使う

LLMの出力は、ファクトチェックなしに使える状態にはありません。数値・固有名詞・日付・セキュリティ要件に関わる記述は必ず人間が確認します。とくに金融・医療・法律関係の情報は、LLMが自信を持って出力しても誤りが含まれることがあります。

一度のやり取りで完成させようとする

プロンプトを一回投げて完璧な出力を期待するより、段階的に絞り込む方が精度が上がります。まず構成を確認し、次に各セクションを詳細化するという2段階の進め方は、特に長いドキュメントを作るときに効果があります。

会社固有の情報をプロンプトに入れすぎる

機密情報・個人情報・未公表の財務情報はプロンプトに含めないことが原則です。クライアントが外部サービスへの情報送信ポリシーを持っている場合は、事前に確認が必要です。実際の顧客名や社内情報は仮の名称に置き換えてからプロンプトを作ることを習慣にします。

プロンプトを使い捨てにする

現場で精度の高いプロンプトが作れたとき、それをそのまま捨てるのは損失です。プロジェクトごとのプロンプトライブラリを作り、チームで共有する体制を作ると、次のプロジェクトでの立ち上がりが早くなります。

---

プロンプトの質を上げる具体的な手順

現場で動きながらプロンプトの精度を上げるには、次のサイクルが効果的です。

1. 目的と聴衆（または利用シーン）を書く
2. 制約・使用不可の表現・出力形式を明示する
3. 試しに動かし、ズレている点を確認する
4. システムプロンプトの文脈情報を追加・修正する
5. 同じ入力で再度動かし、改善を確認する

このサイクルを2〜3回回すと、多くの場合で「そのまま使えるかわずかな修正で済む」水準に達します。現場でよく使うシーンのプロンプトは、このサイクルを経たものをテンプレートとして保存しておくと、次のプロジェクトでの工数を削減できます。

AI時代のFDEでは、FDE全体の働き方とLLM活用の広い視点を扱っています。

---

プロンプト設計の基準まとめ

現場で「このプロンプトは使えるか」を判断するときは、次の3点を確認します。

• 文脈：業種・部門・システム・制約が明示されているか
• 出力形式：欲しい構造（表・箇条書き・コードなど）が指定されているか
• 制約：使えない表現・禁止事項・確認が必要な箇所が明示されているか

この3点が揃ったプロンプトは、最初のやり取りから使える出力が返ってくる確率が高くなります。プロジェクトの最初にシステムプロンプトとしてまとめておき、以降の作業プロンプトと組み合わせる運用が、現場では最も効率が高いです。

プロンプトの書き方は慣れで上達します。最初から完璧を目指すより、今日の打ち合わせで議事録整理に一度使ってみることが、習得への最短経路です。