プロンプトエンジニアリング完全ガイド｜書き方と評価法

プロンプトエンジニアリングというと、「AIがうまく答える魔法の言葉を探すこと」と思われがちです。しかし、表現の工夫だけに頼ると、担当者や入力データが変わるたびに品質が揺れます。業務で必要なのは、誰が使っても目的、前提、禁止事項、合格条件が伝わり、変更の効果を確かめられる状態です。

本記事では、プロンプトエンジニアリングを要件を構造化し、固定テストセットで評価・改善する技術と定義します。OpenAI、Anthropic、Google Cloudの公式ガイドに共通する考え方を基に、書き方の6要素、日本語の悪い例から改善する手順、企業向けの評価と安全管理まで解説します。

プロンプトエンジニアリングとは

プロンプトとは、生成AIへ渡す指示、質問、前提情報、例、入力データなどの総体です。プロンプトエンジニアリングは、それらを目的に沿って設計し、出力を測り、改善する一連の活動を指します。単に長文を書くことでも、決まった敬語や命令文を覚えることでもありません。

OpenAIは公式ガイドで、明確な指示、参照情報の提供、複雑なタスクの分割、外部ツールの利用、変更の体系的なテストなどを扱っています。Anthropicも、プロンプトを調整する前に成功基準と評価方法を用意することを勧めています。つまり、重要なのは「良さそうな回答が1回出たか」ではなく、用途に必要な品質を複数の入力で再現できるかです。

プロンプト作成との違い

プロンプト作成は、個別の依頼文を書く作業です。プロンプトエンジニアリングは、その前後を含みます。

1. 業務目的と利用者を定義する
2. 必要な入力と期待する出力を決める
3. プロンプトを構造化する
4. 固定したデータと基準で評価する
5. 失敗原因を分類し、プロンプトまたは仕組みを直す
6. 変更履歴を残し、運用中も監視する

たとえば、問い合わせを分類する指示文を作れても、カテゴリの定義が曖昧なら担当部署は決まりません。評価用の問い合わせが1件だけなら、短文や複数要件を含む問い合わせで失敗することにも気づけません。プロンプトだけでなく、カテゴリ設計、入力品質、後段の検証までが成果を左右します。

LLM・RAG・外部処理との役割分担

プロンプトは、AIが知っていない最新情報や社内情報を自動で補うものではありません。基礎となる仕組みはLLMの仕組みと活用方法で確認できます。独自資料を検索して回答に使う場合は、RAGの仕組みと導入ポイントのように、検索、アクセス権、引用元の管理を別に設計します。

計算、厳密な検索、データベース更新などは、外部ツールや通常のプログラムに任せるほうが適切な場合があります。出力形式を固定しても内容の正しさが自動的に保証されるわけではありません。プロンプト、検索、ツール、検証、人の判断を用途ごとに組み合わせることが基本です。

良いプロンプトを作る6要素

実務では、次の6要素を順に整理すると抜け漏れを発見しやすくなります。すべてを毎回長く書く必要はありません。簡単なタスクなら短くし、高リスクまたは複雑なタスクほど制約や完了条件を具体化します。

1．目的

何のために、何を達成するのかを示します。「要約して」ではなく、「営業担当が次の対応を判断できるよう、問い合わせの要望と期限を要約する」と書けば、残すべき情報が明確になります。用途を伝えられない場合は、そもそも成果物の合格基準も定まりません。

2．役割

どの観点と責任範囲で処理するかを指定します。たとえば「校閲担当として、表記ゆれと誤字を指摘する。内容の主張は変更しない」とします。役割指定はAIに未提供の資格や知識を与える魔法ではなく、見るべき観点を絞る補助です。

3．文脈

対象読者、前提、用語定義、参照してよい資料を渡します。背景を省くと、AIは一般的な前提を補い、利用者の事情とずれることがあります。一方、不要な資料まで大量に渡すと、重要情報が埋もれます。タスクに必要な範囲だけを選び、指示と参照データを見出しやタグで分けます。

4．指示

実行してほしい処理を、順序と優先順位が分かる形で書きます。「本文から事実を抽出する」「カテゴリ定義と照合する」「理由を付けて1カテゴリを選ぶ」のように分けます。複数の作業が互いに依存する場合は、中間結果を構造化して次の処理へ渡す方法も有効です。

5．制約

してはいけないこと、参照範囲、不明な場合の動作を決めます。「提供資料にない数値を補わない」「個人情報を出力しない」「判断できない場合は『要確認』とする」などです。文字数だけでなく、根拠、禁止事項、例外時の扱いまで書くと、もっともらしい推測を抑えやすくなります。

6．出力形式・完了条件

見出し、表の列、JSONの項目、並び順、件数を指定します。さらに、「必須項目がすべてある」「根拠箇所を示す」「定義外の分類を作らない」など、完了とみなす条件を添えます。システム連携ではJSON Schemaなどで形式を制約し、受け取った後も型、必須値、許可値をプログラムで検証します。

以下はコピーして使える基本形です。

# 目的[この成果物を何に使うか／達成したい状態]# 役割[担当する観点／責任範囲]# 文脈- 対象読者：[読者]- 前提：[用語、背景]- 参照情報：[使用してよいデータ]# 指示1. [最初の処理]2. [次の処理]3. [確認処理]# 制約- [禁止事項]- [根拠の範囲]- 不明な場合：[「要確認」と記載する、質問する等]# 出力形式・完了条件- 形式：[表／箇条書き／JSON等]- 必須項目：[項目]- 完了条件：[合格とする状態]

区切りにはMarkdown見出し、引用符、XMLタグなどを使えます。Anthropicは、指示、文脈、例、入力をXMLタグで分離する方法を案内しています。記号自体よりも、「どこからどこまでが命令で、何が処理対象のデータか」が一貫して分かることが重要です。

日本語の悪い例を改善する実践手順

ここでは、商品紹介文を作る場面で比較します。

悪い例

新商品の紹介文を書いて。分かりやすく魅力的にして。

この指示では、読者、掲載場所、目的、使用可能な事実、長さ、避ける表現が不明です。「魅力的」の基準も人によって異なります。AIが対象読者や特徴を推測すると、実際に提供していない機能や根拠のない最上級表現が混ざる可能性があります。

改善例

# 目的法人向け製品ページの冒頭文を作り、読者が資料を読むべきか判断できるようにする。# 役割BtoBコンテンツの編集担当として、提供情報を正確に整理する。# 文脈対象読者：手作業の集計を減らしたい業務改善担当者提供情報：<product>特徴：CSVを取り込み、指定した集計ルールで週次レポートを作成する導入条件：管理者による初期設定が必要</product># 指示1. 読者の課題を1文で示す。2. 提供情報にある特徴と導入条件を説明する。3. 読後に分かることを1文で示す。# 制約- 提供情報にない機能、実績、効果、比較優位を追加しない。- 「必ず」「完全」「業界最高」など、根拠のない断定を使わない。- 不足情報は推測せず、末尾に「確認事項」として列挙する。# 出力形式・完了条件- 本文：180〜220字、です・ます調- 確認事項：箇条書き- 特徴と導入条件の両方を含める。

改善のポイントは、文章を長くしたことではなく、判断に必要な要件を分離したことです。結果が合わなければ、「魅力が弱い」と感覚的に直すのではなく、読者の課題、使用できる根拠、構成、禁止表現のどこに問題があるかを特定できます。

良い入出力例を添える

説明だけで形式や分類基準が伝わりにくい場合は、入力と望ましい出力の組み合わせを複数示すfew-shot promptingが有効です。例は、簡単なケースだけでなく、判断が分かれやすいケースも含めます。ただし、例にだけ過度に適合する可能性があるため、評価データとは分けます。実在する個人の情報や機密データを例に使わないことも重要です。

構造化出力を使う

後続システムへ渡す場合は、自由文よりも構造化出力が扱いやすくなります。OpenAIのStructured Outputsは、指定したJSON Schemaへの準拠を高める仕組みです。ただし、形式が正しいことと、値が事実に合うことは別です。存在しない注文番号が正しい型で出る可能性は残るため、マスターデータとの照合や人の確認が必要です。API連携の全体像はOpenAI APIの導入ガイドも参照してください。

固定テストセットで評価・改善する方法

プロンプトの改善で最も避けたいのは、都合のよい1件だけを見て採用することです。文章を少し変えると、その入力では良くても別の入力で悪化することがあります。そこで、実際の利用場面を代表する入力を固定し、変更のたびに同じ条件で比較します。

成功基準を先に決める

最初に「良い出力」を観測可能な項目へ分解します。たとえば問い合わせ分類なら、次のように採点できます。

評価項目	確認内容	例
正確性	正解カテゴリと一致するか	一致／不一致
根拠性	入力に基づく理由か	0〜2点
形式準拠	必須項目と許可値を守るか	合格／不合格
安全性	個人情報や禁止情報を不要に出さないか	合格／不合格
保留判断	情報不足を無理に分類しないか	適切／不適切

文章生成では、正解が一つとは限りません。その場合も、「提供情報にない主張がない」「必須メッセージを含む」「指定文字数に収まる」といった客観項目と、人が確認する読みやすさを分けて採点します。自動採点は効率的ですが、採点用AIにも誤りがあるため、重要な用途では人の評価と定期的に照合します。

テストデータを4種類に分ける

固定テストセットには、少なくとも次を入れます。

• 典型例：日常的に多い入力
• 境界例：複数カテゴリにまたがる、長い、曖昧など判断が難しい入力
• 欠損例：必須情報がない入力
• 敵対的な例：指示の無視、秘密情報の開示、不正なツール操作を誘う文を含む入力

実運用ログを評価用に使う場合は、利用目的、保存期間、アクセス権を決め、必要に応じて匿名化します。評価セットをプロンプト作成者だけで作ると想定が偏りやすいため、業務担当者、品質管理担当者、安全管理担当者がレビューすると有効です。

一度に一つ変え、回帰テストする

目的、例、制約、出力形式を同時に変えると、何が効いたか分かりません。一度に一要素を変更し、全テストを再実行します。結果はプロンプトの版、実行条件、入力ID、出力、点数、評価者、変更理由とともに保存します。

採用基準は平均点だけで決めないことが重要です。平均が上がっても、個人情報の出力や誤った外部操作が1件発生すれば採用できない用途があります。「形式準拠率が基準以上」かつ「重大な安全違反は0件」のように、最低条件を別に置きます。OpenAI、Anthropic、Google Cloudはいずれも、用途に即した評価データと継続的なテストの重要性を公式資料で説明しています。

企業利用の評価とガバナンス

企業では、プロンプトの品質を個人の工夫だけにしない仕組みが必要です。NIST AI Risk Management Frameworkは、AIリスク管理をGovern、Map、Measure、Manageの4機能で整理しています。これをプロンプト運用へ当てはめると、次のようになります。

• Govern：責任者、承認者、禁止用途、文書化ルールを決める
• Map：利用者、影響を受ける人、使用データ、誤りが起きた場合の影響を把握する
• Measure：固定テストセット、品質指標、安全指標、監視方法を定める
• Manage：リスクに応じて対策を選び、問題時の停止、修正、報告を行う

リスクに応じて承認を変える

社内文書の下書きと、顧客への自動送信、採用や与信に関わる判断では、必要な管理が異なります。影響が大きい用途ほど、人の確認、法務・セキュリティレビュー、監査ログ、停止手段を強くします。AIの出力を意思決定の参考にするのか、自動実行の条件にするのかも明記します。

最低限、プロンプトの所有者、承認済み版、利用可能なデータ、利用可能なツール、評価結果、最終更新日、問題時の連絡先を台帳で管理します。現場が勝手にコピーして派生版を増やすと、どの版が承認済みか追えなくなります。共通部分と用途別部分を分け、変更をレビューできる場所で管理します。

データとログの扱いを先に決める

入力してよい情報を、公開情報、社内情報、機密情報、個人情報などに分類します。利用するサービスのデータ処理条件、保持、学習利用の設定、保存地域、アクセス制御を公式文書と契約で確認します。プロンプトに「機密情報を送らない」と書くだけでは、利用者の入力やシステム連携を技術的に止められません。送信前の検知、マスキング、権限制御も組み合わせます。

ログは改善と事故調査に役立ちますが、入力と出力を無期限に保存すると別のリスクになります。保存目的、対象項目、期間、閲覧権限、削除手順を決めます。評価データへ追加する際も、必要最小限の情報にします。

プロンプトインジェクションの多層防御

プロンプトインジェクションは、攻撃者が入力や外部コンテンツに命令を混ぜ、AIに本来の指示を無視させようとする問題です。利用者がチャット欄へ直接書く「直接型」だけでなく、AIが読むWebページ、文書、メール、検索結果などに命令を埋め込む「間接型」もあります。

OWASPはPrompt Injectionを主要なLLMアプリケーションリスクとして挙げています。RAGで取得した文書や外部ツールからの応答も、信頼できる命令ではなく、処理対象のデータとして扱う必要があります。自然言語では指示とデータの境界が曖昧になり得るため、「この指示を無視しないこと」とプロンプトに追記するだけでは完全に防げません。

防御を6層に分ける

1. 入力・データ層：信頼度を分類し、不要な外部コンテンツを渡さない。既知の攻撃表現を検知しても、それだけを唯一の対策にしない
2. 指示層：システムの目的、禁止事項、外部データ内の命令を実行しない方針を明示し、指示とデータを区切る
3. 権限層：AIと接続先に最小権限を与える。読み取りと更新を分け、操作対象を許可リストで限定する
4. 実行層：送信、削除、購入、権限変更など影響の大きい操作は、人の承認や追加認証を必須にする
5. 出力層：スキーマ、許可値、機密情報、URL、コマンドを検証し、安全性を確認してから後段へ渡す
6. 監視・評価層：敵対的テスト、異常な操作の監視、ログ、停止手順、インシデント対応を継続する

ツール連携では、AIの文章出力とツール実行を同一視しないことが重要です。モデルが生成した引数をそのまま実行せず、対象、件数、権限、値の範囲をコードで検証します。外部接続を標準化する仕組みを使う場合も、接続先ごとの権限と承認は必要です。関連する設計はMCPの仕組みとセキュリティで解説しています。

OpenAIの安全性ベストプラクティスも、モデレーション、敵対的テスト、人による確認、入力・出力の制限などを組み合わせる考え方を示しています。防御は一度設定して終わりではありません。新しいデータ源やツールを追加したとき、権限を変えたとき、失敗例が見つかったときに評価セットと対策を更新します。

プロンプトエンジニアリングのFAQ

Q. プロンプトは長いほど良いですか？

いいえ。必要な情報が不足していれば短すぎますが、無関係な背景、重複する指示、矛盾した条件が増えると判断しにくくなります。目的、必要な文脈、制約、出力形式を過不足なく書き、固定テストセットの結果で追加や削除を判断してください。

Q. 同じプロンプトなら毎回同じ結果になりますか？

必ずしも同じにはなりません。生成AIの出力には変動があり、利用環境の更新や参照データの変化でも結果が変わります。重要項目は構造化し、後段で検証します。また、複数回の試行や定期的な回帰テストにより、許容範囲に収まるかを確認します。

Q. プロンプトエンジニアリングに専門知識は必要ですか？

高度なプログラミングがなくても、目的、前提、制約、出力形式を整理するところから始められます。一方、業務で正しさを評価するには対象分野の知識が必要です。API連携、権限管理、自動実行を伴う場合は、開発とセキュリティの知識も求められます。担当者一人ではなく、業務・開発・管理の複数視点で確認するのが安全です。

Q. プロンプトインジェクションは指示文だけで防げますか？

完全には防げません。指示と外部データを分けることは有効ですが、それに加えて最小権限、許可リスト、引数と出力の検証、重要操作の承認、監視、敵対的テストを組み合わせます。特に外部文書を読む、ツールを実行する、データを更新するシステムでは多層防御が必要です。

プロンプトエンジニアリングは、言葉のコツではなく運用設計です。まず頻出タスクを6要素で構造化し、典型例・境界例・欠損例・敵対的な例を含む固定テストセットを作ります。その後、一度に一要素ずつ変更し、品質と安全性の回帰テストを続けてください。

社内の生成AI活用について、ユースケース整理、評価設計、セキュリティを含めて検討したい場合は、NexaのAIコンサルティングをご覧ください。

公式出典

• OpenAI「Prompt engineering」：https://platform.openai.com/docs/guides/prompt-engineering
• OpenAI「Evals」：https://platform.openai.com/docs/guides/evals
• OpenAI「Structured Outputs」：https://platform.openai.com/docs/guides/structured-outputs
• OpenAI「Safety best practices」：https://platform.openai.com/docs/guides/safety-best-practices
• Anthropic「Prompt engineering overview」：https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
• Anthropic「Be clear and direct」：https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/be-clear-and-direct
• Anthropic「Use XML tags」：https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/use-xml-tags
• Anthropic「Multishot prompting」：https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/multishot-prompting
• Anthropic「Develop tests」：https://docs.anthropic.com/en/docs/test-and-evaluate/develop-tests
• Anthropic「Mitigate jailbreaks and prompt injections」：https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/mitigate-jailbreaks
• Google Cloud「Prompt design strategies」：https://cloud.google.com/vertex-ai/generative-ai/docs/learn/prompts/prompt-design-strategies
• Google Cloud「Structure prompts」：https://cloud.google.com/vertex-ai/generative-ai/docs/learn/prompts/structure-prompts
• Google Cloud「Model evaluation overview」：https://cloud.google.com/vertex-ai/generative-ai/docs/models/evaluation-overview
• OWASP「LLM01: Prompt Injection」：https://genai.owasp.org/llmrisk/llm01-prompt-injection/
• NIST「AI Risk Management Framework」：https://www.nist.gov/itl/ai-risk-management-framework