プロンプトエンジニアリングとは
プロンプトエンジニアリングとは、言語モデルの応答が特定のタスクに合うよう、モデルに与える指示を設計・検証する取り組みです。タスクの定義、有用な例の提示、出力の指定、結果の確認を含みます。明確なプロンプトは曖昧さを減らせますが、欠けている証拠を生み出したり、回答の正しさを証明したりすることはできません。
執筆：Ai Flowi · 公開日
出発点となるのは、実務的な問いです。この入力に対してモデルに何をさせ、その回答をどう評価するか。それが、もっともらしい表現を集めることと、プロンプトエンジニアリングとの違いです。このページでは、架空のサービス依頼のタスクを使って、必要な判断を示します。モデルの応答や改善の測定結果を示すものではありません。
プロンプトに含める要素
タスクの指示には、依頼された部屋を抽出し、不足している予約情報を特定する、といった操作を明示します。文脈には、その操作の対象となる資料を含めます。制約には、推測せず不明のままにする事項を定めます。出力の取り決めには、別の人やプログラムが結果をどう読み取るかを記述します。例は、許容できる解釈と情報の創作との境界を示します。
これらの要素は整合している必要があります。短い要約を求めながら原文のすべての詳細も要求すると、期待が競合します。与えられた事実だけを使うよう求めながら、完全な予約日も必須にすると、情報の不足を埋めるよう促してしまいます。文体を調整したり、役割の説明を追加したりする前に、こうした矛盾を解消します。
どの文書や過去のメッセージを含めるかという別の問題については、コンテキストエンジニアリングを参照してください。指示を丁寧に書いても、周囲の証拠が無関係、古い、または選んだモデルには大きすぎる場合、失敗することがあります。
プロンプトエンジニアリングの例：タスクを固定して改善します
架空の入力は「金曜日の午後にCedarの部屋を手配してください」です。アプリケーションには、部屋名、暦上の日付、時刻が必要だとします。「金曜日の午後」だけでは、日付も時刻も一意に定まりません。プロンプトは、分かっている部屋を保持しながら、不足している詳細を明らかにする必要があります。
設定例であり、記録されたテストではありません。以下の改訂は抽出タスクを指定するもので、予約を実行するものではありません。
| 改訂 | 指示 | 変更の理由 |
|---|---|---|
| 曖昧なタスク | このメッセージから予約を作成してください。 | 抽出と、外部で予約を行う行動を区別していません。 |
| 範囲を限定したタスク | 部屋を抽出し、不足している日付や時刻の詳細を列挙してください。予約は行わないでください。 | 解釈と実行を分けます。 |
| 出力の取り決め | room、date、time、clarification_neededを返してください。日付と時刻がない場合はnullを使ってください。 | 後続の確認で、不足情報を把握できるようにします。 |
| 例による境界の提示 | 暦上の日付を伴わない曜日は、未解決のままにします。 | 曖昧な表現の扱い方を示します。 |
作成者が定める目標は、Cedarを保持し、日付と時刻を未解決のままにして、確認を求めることです。これは受け入れ目標であり、記録された出力ではありません。選んだモデルが従うかは、実際のモデル設定と入力を使って確認する必要があります。
詰め込みすぎず、指示を具体的にします
抽出、分類、比較、引用など、観測できる作業を表す動詞を使います。「役に立つように」という指示では、推測した予約日が欠陥かどうか分かりません。「日付がない場合はnullを使う」なら明確です。依頼の中の文を解釈する資料として扱えるよう、データと指示をはっきり分けます。
引用されたデータ内の命令を無視する指示は、設計の意図として有用です。ただし、プロンプトの文言だけではアクセス制御の境界になりません。モデルに渡す要求に、予約を確定する権限を含めてはいけません。アプリケーションは、行動の前に必須フィールドを確認し、適切な承認を求める必要があります。
希望と確定済みの詳細の区別など、判断の境界が難しい場合は、例が役立ちます。少数例プロンプティングの項目では、例の選び方と、評価用の事例をプロンプトに含めない方法を説明しています。例を増やせば必ず役立つわけではありません。
AI Flowi Workflowでの扱い
指示の文章を組み立てる方法は、Prompt Templateのリファレンスを参照してください。
機械可読な応答のフィールドとスキーマの取り決めは、Structured Outputの説明で扱っています。
この予約依頼では、roomにCedarを保持し、ユーザーが正確な値を提示するまで、dateとtimeをnullのままにする必要があります。提案するclarification_neededフィールドは、両方の不足情報を示す必要があります。基準日が示されていないのに金曜日から暦上の日付を作り出した応答は、日付の構文が有効でも却下します。
午後という希望と、確定した時刻は異なる値です。必要なら説明に希望を残しますが、無断で特定の時刻に変えないでください。同様に、Cedarを希望していることは、Cedarが利用可能である証拠ではありません。部屋の抽出が成功するのは、希望された部屋を報告したときであり、予約を約束したときではありません。
評価器の設定と失敗の分類については、LLMのハルシネーションを参照してください。
ここで評価するのは、改訂によって既知のフィールドを保ちながら曖昧さを明らかにできるかです。正確な部屋の値、nullにする判断、確認の文言を個別に比較します。適切な追加質問をしても部屋名を失ったプロンプトは、退行しています。すべてのキーを返しても時刻を推測したプロンプトは、別の要件に違反しています。どちらの結果も、役に立ちそうだという全体的な印象で隠してはいけません。
カタログに文書化されていますが、Ai Flowiによる本番環境でのテストは行われていません。
これらのツールはコンポーネントカタログに掲載されています。予約用のプロンプトを比較するには、ご自身の生成用・評価用アカウントとAPIキーを用意し、各プロバイダーの別途料金を予算に含めてください。
タスクに照らしてプロンプトをどう検証しますか？
プロンプトの改訂を比較する間は、元の依頼と受け入れ基準を固定します。モデル、原文の事実、プロンプトを同時に変えると、回答の違いを指示の変更に帰属できません。確認した各応答とともに、プロンプトの版と設定を記録します。
完全な日付、相対的な曜日、部屋の欠落、本文を通じて命令を出そうとする依頼を含めます。根拠のあるフィールド、不足情報の扱い、出力構造、無許可の行動の回避を、それぞれ採点します。形式を満たしていても、証拠の確認には不合格になることがあります。
実際にツールが必要な設計の場合だけ、Agentのリファレンスを使います。タスク別の出発点となるパターンについては、文書化されたユースケースと、そのテスト範囲を確認してください。プロンプトの検証だけでは、接続されたツールやワークフロー全体が動作することは証明できません。
よくある誤りと限界
流暢な回答を確認合格とみなしたり、共有プロンプトで非公開の例を開示したり、評価用の正解をプロンプト自体にコピーしたりしないでください。決定的なルールですでに答えが定まる場面では、モデルの解釈を使わないでください。プロンプトエンジニアリングは言語に依存するタスクに有用ですが、証拠、検証、アプリケーションの権限は、それぞれ別の責任です。
関連情報：プロンプトの自動最適化：候補の生成と評価。