1. プロンプトエンジニアリングとは: 3つの基本要素
プロンプトエンジニアリングとは、LLMから意図した品質の出力を安定して引き出すための指示設計です。ChatGPTに気の利いた質問を打つ話ではなく、業務システムに組み込むLLMの「仕様書」を書く仕事だと捉えるのが実態に近いといえます。基本要素は大きく3つです。
①システムプロンプト設計
LLMに与える「役割・前提・制約」の定義です。たとえば問い合わせ対応なら「あなたは○○社のサポート担当。回答は提供資料の範囲に限る。資料にない場合は『わかりかねます』と答え、推測しない。回答は敬体で3文以内」。このように、役割・情報源・禁止事項・出力形式を明文化します。曖昧な指示は曖昧な出力を生むため、就業規則のように具体的に書くのが原則です。
②few-shot（例示）
望ましい入出力の例をプロンプト内に数件示す手法です。「こういう問い合わせにはこう答える」という実例を2〜3件見せるだけで、言葉で説明するより確実にトーンや粒度が揃うことが多く、公式ガイドでも基本手法として紹介されています。どの例を選ぶかに業務理解が表れます。
③構造化出力
出力をJSONなどの決まった形式で返させる技術です。LLMの回答を後続のシステム（データベース登録、画面表示、次の処理への受け渡し）で使うには、自由文ではなく{"category": ..., "priority": ...}のような構造が必要になります。各社APIの構造化出力機能やスキーマ指定を使いこなすことは、LLMを「チャット」から「業務部品」に変えるうえで重要です。
2. FDEの現場では: 「魔法の呪文」ではなく「翻訳と評価の反復」
FDEの現場におけるプロンプトエンジニアリングは、完璧な一文を発明する仕事ではありません。中心にあるのは次の2つの反復です。
業務要件をプロンプト仕様に落とす「翻訳作業」
顧客の「いい感じに要約してほしい」という要望は、そのままではプロンプトになりません。ヒアリングを重ねて「誰が読むのか（役員か現場か）」「何文字で」「数字は必ず残すのか」「触れてはいけない情報は何か」を引き出し、暗黙の業務ルールを明文化していきます。この翻訳作業こそが、プロンプト設計の中心です。たとえば議事録要約なら、「決定事項・宿題・期限を必ず抽出する」「発言者の役職は社内表記に従う」といった、顧客の中では当たり前すぎて言語化されていなかったルールを掘り起こすことになります。プロンプトを書く時間より、書くべき内容を聞き出す時間の方が長いことも珍しくありません。
評価セットで測る「改善の反復」
書いたプロンプトは、印象ではなく評価セット（実際の入力と期待出力のペア、目安として数十件）で測ります。プロンプトを変えるたびに全件流して正答率や見逃し率を確認し、「良くなった気がする」ではなく「35/50が42/50になった」と数字で説明します。1つの修正が別のケースに悪影響を及ぼすことがあるため、評価を伴わない改善は現場では成立しません。この進め方はRAG実装の精度チューニングとまったく同型で、FDEの実務では両者はほぼ常にセットで登場します。
以上から、「プロンプトエンジニアリングはFDEの必須スキルか」という問いに対しては、テクニック集としては不十分であり、翻訳作業と評価の反復としては必須であると整理できます。
3. 今どうやって身につけるか: 公式ガイド＋評価セットづくり
Step 1: AnthropicとOpenAIの公式プロンプトガイドを読み込む
両社とも公式ドキュメントに体系的なプロンプトエンジニアリングガイドを公開しており、明確な指示・例示・役割付与・出力形式指定といった原則が整理されています。SNSで流れる断片的な「裏技」ではなく、モデル提供元の一次情報から学ぶことが、遠回りに見えて最も確実な方法です。読むだけでなく、ガイドの原則を1つずつ自分のプロンプトで試して差分を確認してください。
Step 2: 実務の題材で「評価セット」を作る
この工程が最も重要です。自分の業務（または内容を熟知した題材）から、実際の入力と期待する出力のペアを数十件集め、プロンプトの版ごとに正答率を記録します。このサイクルを一度経験しておくことは、プロンプトの知識を説明するよりも選考で高く評価されます。FDEになるにはで述べた「LLMを組み込んだものを作り、実際に使ってもらう」実績づくりの中心となる工程です。
Step 3: 構造化出力＋後続処理まで組んで「部品化」する
プロンプト単体で完結させず、構造化出力で受け取って後続処理（集計・通知・画面表示）につなぐ小さなアプリまで作ると、FDEの実務にぐっと近づきます。成果物はポートフォリオに、学習全体の順序は未経験からのロードマップにまとめています。
4. FDE Outlook: テクニックは陳腐化し、言語化と評価設計が残る
今見えていること: モデルの性能向上により、かつて必須だった細かな言い回しの工夫（「深呼吸して」等の呪文的テクニック）の効果は薄れ、素直に書いた指示が素直に通ることが増えました。「プロンプトエンジニア」という単独職種の求人も、FDEやAIエンジニアの業務の一部として吸収される流れが続いています（この転身ルートはプロンプトエンジニアからFDEへで詳説）。国内でもSansanのFDE組織が公式テックブログ（2026年7月）で、コーディングスキルよりも業務経験・ドメイン知識といった人間側のノウハウが価値を持つと指摘しており、「うまい呪文を知っていること」ではなく「業務を言語化できること」に価値の重心が移っている傍証といえます。
今後の見立て: この傾向は続くと見ています。テクニック的な側面はモデル進化とツール（プロンプト自動最適化等）でさらに陳腐化していく一方、①顧客の暗黙知を仕様として言語化する翻訳力、②「正しい出力とは何か」を定義する評価設計力は、モデルがどれだけ賢くなっても人間側にしか出せない入力として残るはずです。学習投資の配分も、言い回しの収集より業務の言語化と評価の経験に寄せることをおすすめします（もちろん将来の断定はできないため、求人要件の変化は求人ウォッチで定点観測を続けます）。