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

生成 AI モジュールでは、生成 AI モデルの入力空間は事実上無制限であることを学びました。ユーザーの期待に沿った出力を生成するには、プロンプトを作成する必要があります。プロンプトは、アプリケーションとモデル間の構造化されたコントラクトです。

適切に記述されたプロンプト:

• LLM が回答をどのように作成すべきかを指定します。
• バージョン管理、テスト、改善を時間の経過とともに実施できる複数のコンポーネントで構成されます。
• チーム間のコラボレーションのための共有アーティファクトとして機能します。

このモジュールでは、効果的なプロンプトを作成する方法について学習します。プロンプトの構造と、そのコンポーネントがシステムとエンドユーザーの間でどのように分散されるかについて説明します。また、基本的なプロンプト技術と、それぞれの技術を適用するシナリオについても学習します。

このモジュールでは、CyberAgent の Prompt API の使用に触発された AI を活用したライティング アシスタントである BlogBuddy という共通の例を使用します。

BlogBuddy システムのブループリントの生成 AI モジュールに戻ります。

プロンプトの要素

各プロンプト コンポーネントには、モデルの動作を制御する特定の役割があります。

• コンテキスト: モデルの役割とドメインを確立し、モデルがどのように動作すべきかを理解します。
• 指示: モデルに特定のタスクを割り当てます。
• 入力変数: アプリケーションによってリアルタイムで提供される状況固有のコンテキスト。
• 出力形式: 期待される出力構造を定義します。たとえば、JSON 出力が必要になることがあります。
• 例: 1 つ以上の他の入力に対してタスクを実行する方法を示します。
• 制約: 出力を一貫性があり、安全で、ブランドに沿ったものにするために、明確な制限を設定します。

プロンプトには、これらのコンポーネントの一部またはすべてを含めることができます。次の例は、BlogBuddy のライティング アシスタント機能のこれらのコンポーネントを示しています。

### Context

You are a writing assistant for blog authors.
Your job is to generate helpful, concise, and engaging content.

### Instruction

Generate 3 alternative titles for the user's blog post with a given style.

### Input variables

Here is the content of the blog post:
${blogPostContent}

Here is the desired style:
${titleStyle}

### Output format

Return valid JSON ONLY, in the following exact structure:
{
  "titles": ["Title option 1", "Title option 2", "Title option 3"]
}

### Examples

Example input:
{
  "blogPostContent": "I finally visited the small neighborhood café I've been eyeing for months...",
  "titleStyle": "friendly"
}

Example output:
{
  "titles": [
    "A First Visit to the Neighborhood Café",
    "Trying the Café I've Wanted to Visit for Months",
    "My Experience at a Long-Awaited Local Spot"
  ]
}
### Constraints

- Each title must be under 128 characters.
- Titles must be original, not copied verbatim from the draft.
- Keep the tone natural and human. Avoid emojis unless explicitly requested.
- Avoid sensationalism or clickbait.
- If the draft includes multiple topics, choose the most prominent topic.

最初のプロンプトでは、指示と出力形式という基本的なことから始めます。次に、結果を分析し、成功に必要なより細かい制御を特定しながら、コンポーネントを繰り返し追加します。

システム プロンプトとユーザー プロンプト

プロンプト コンポーネントには、ハードコードされているものと、エンドユーザーが指定できるものがあります。

• システム プロンプトはアプリケーション デベロッパーによって提供され、モデルの全体的な動作を定義します。モデルのロール、想定されるトーン、出力形式（厳密な JSON スキーマなど）、グローバル制約を設定できます。システム プロンプトでは、安全性と責任に関する要件もエンコードします。リクエスト間で一貫性が保たれ、モデルの動作の安定した基盤が提供されます。

• ユーザー プロンプトには、出力につながる直接的なリクエストが含まれます。ユーザーが特定のタスクをリクエストします。これには特定の変数を含めることができます。たとえば、「この投稿のタイトルを 3 つ表示して」、「この段落を続けて」、「このコピーをもっとフォーマルなものにして」などです。

ほとんどの生成 AI API では、プロンプトをメッセージの配列として構造化できます。各メッセージには、ロール（システムまたはユーザー）とコンテンツがあります。これにより、安定したグローバルな指示と、リクエストごとの動的な入力を簡単に分離できます。

システム プロンプトに含めるコンポーネントと、ユーザーが指定できるようにするコンポーネントをどのように決定しますか？答えは、ユーザー エクスペリエンスの柔軟性とモデルの能力によって異なります。

制約のあるユースケース

非常に具体的なユースケースでは、プロンプトのほとんどをシステム プロンプトで事前定義できます。たとえば、BlogBuddy では、[Show Titles] をクリックすると、下書き用に生成されたタイトルの候補が一覧表示されます。

タスクは固定されており、出力形式はわかっています。ユーザーは、期待される結果を得るために追加のコンテキストを提供する必要はありません。この場合、安定したルール、トーンのガイドライン、出力スキーマ、例をすべてシステム プロンプトに配置します。

プロンプト API を使用してこれを構築するには、initialPrompts を使用してセッション全体のシステムレベルの動作を定義します。

// Defines stable behavior for the entire session
const session = await LanguageModel.create({
  initialPrompts: [
    {
      role: "system",
      content: `You are a blog-writing assistant.
      Your task is to generate high-quality titles for blog posts.
      Always respond in concise, friendly language.
      Return exactly 3 alternative titles.
      Produce valid JSON with a "titles" array of strings.`
    }
  ]
});

ユーザーが [タイトルを表示] をクリックすると、現在のコンテンツのプロンプトが呼び出されます。

// The only variable input is the blog content
const result = await session.prompt(blogContent);

ユーザーは、時間の経過とともに、より柔軟な設定と制御を求めるようになる可能性があります。この場合、特定のコンポーネントをインターフェース コントロールとともにユーザー プロンプトに移動できます。たとえば、スタイルやトーンの仕様のプルダウン メニューなどです。

ただし、構造化アクションが多すぎると、ユーザー エクスペリエンスが損なわれる可能性があります。このような場合は、ユーザーがほとんどのプロンプトを自分で指定できる、よりオープンエンドな設計に移行することをおすすめします。この設計の最適化について詳しくは、UX パターン モジュールをご覧ください。

柔軟なタスクは詳細なユーザー プロンプトに依存する

ユーザーがブログ投稿をゼロから作成できる、オープンエンドのインタラクティブなエクスペリエンス。ユーザーに柔軟性を提供します。アイデア、アウトライン、書き換え、トーンの変更、ブレインストーミングを求めたり、タスクをどのように実行すべきかを具体的に指定したりする場合があります。このタイプのアプリケーションでは、より強力なサーバーサイド モデルが必要になる可能性があります。

柔軟なタスクでは、オプションの範囲が広いため、ユーザーはより多くの情報を指定する必要があります。システム プロンプトは引き続き全体的な動作を制御します。

ベスト プラクティスは次のとおりです。

• 安定したルール、構造、例をシステム プロンプトに配置します。動的コンテンツとタスク固有のリクエストをユーザー プロンプトに含めます。
• UX がオープンエンドであればあるほど、予測不可能な入力に対応するためにユーザー プロンプトの柔軟性が求められます。
• ユーザー プロンプトで実行する必要がある作業が多いほど、モデルはより高性能である必要があります。これは、組み込み構造が少ない状態でより大きなバリエーションを処理する必要があるためです。

これらのルールを使用すると、プロダクト コンテキストで制御とユーザーの柔軟性のトレードオフを徐々に最適化できます。ユーザーの設定や行動を注意深く観察します。柔軟性が高くなっても、必ずしも実際の価値に変換されるとは限りません。ユーザーは、より広範なプロンプトを作成するための時間、スキル、認知帯域幅も必要です。

一般的なプロンプトの手法

通常、デベロッパーは複数のプロンプト手法を試して、ユースケースとモデルに最適なものを見つけます。

ゼロショット プロンプト

モデルにタスクを説明し、最善の結果を期待します。次に例を示します。

"What is the capital of France?"

ゼロショット プロンプトは、多くの AI タスクの効率的なベースラインです。百科事典の知識のクエリなど、複雑でないリクエストの場合は、この手法を使い続けるのが最適でしょう。ただし、実際のアプリケーションでは、追加の条件とロジックを使用してプロンプトを拡張する必要があります。

少数ショット プロンプト

少数ショット プロンプトでは、適切な動作、スタイル、構造、その他の重要な変数を実証する例を提供します。感情分類のプロンプトの例を次に示します。

You classify user messages into one of the following categories:
- "positive"
- "negative"
- "neutral"
Here are examples to guide your classifications:
Input: "I love this product! It works perfectly."
Output: { "label": "positive" }

Input: "This is terrible. I want a refund."
Output: { "label": "negative" }

フューショット プロンプトは、このような疑似予測タスクに役立ちます。また、図 1 のタイトルの生成など、認識可能な構造に従うタスクにも適用できます。

出力スペースが非常に広い場合（オープンエンドのコンテンツや長文のコンテンツなど）、フューショット プロンプトは最適な手法ではない可能性があります。この空間を意味のある形でカバーする例を挙げるのは難しいか、不可能でさえあります。

Chain-of-Thought プロンプト

モデルが回答を生成する前にステップバイステップで推論するように促します。ステップは明示的に記述することも、モデルに定義させることもできます。次に例を示します。

"Think step-by-step to identify the main idea of this paragraph. Then produce a
short heading under 60 characters."

連鎖思考は、ブログ投稿の概要作成や複雑な意思決定のサポートなど、複数のステップで推論と実行が必要なタスクに最適です。これは、いわゆる推論モデルの背後にある主な手法です。

この方法は費用がかかる可能性があります。ステップバイステップの推論トレースを生成すると、コンピューティング、費用、レイテンシが増加します。ユースケースで複雑な推論と計画が必要な場合にのみ使用します。

自己分析のプロンプト

最初の生成の後、モデルに独自の出力を批評して修正するようリクエストします。次に例を示します。

"Review your previous output.
Identify unclear phrasing and rewrite it more concisely."

自己反省は、編集ツールや書き換えツールなど、反復的な改善が有効なタスクに特に役立ちます。実装が簡単で、品質を大幅に向上させることができます。プロンプトのパフォーマンスが良好になったら、内省ループが有効になります。まず、出力を調整して、より明確にしたり、ユーザーの満足度を高めたりします。

要点

このモジュールでは、構造化されたコンポーネントからプロンプトを構築する方法について学習しました。実際には、プロンプト エンジニアリングは非常に実験的なものです。明確さと信頼性は、複数回の改善を経て初めて生まれます。

次のモジュールでは、評価主導のプロンプト開発について説明します。この方法により、プロンプトを体系的に改善し、プロダクトとユーザーに最適なものに収束させることができます。

リソース

これらの手法には、それぞれ独自のバリエーションとベスト プラクティスがあります。詳細な外部リソースは多数あります。たとえば、次のものがあります。

• Google Cloud のプロンプト エンジニア ガイド
• DAIR のプロンプト エンジニアリング ガイド
• Prompting made simple（Janna Lipenkova 著）
• AI プロダクト開発の技術の第 6 章を読む。

選択したモデルのドキュメントを確認してください。最適な結果を得るための具体的なアドバイスが記載されている場合があります。

理解度を確認する