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

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

プロンプトエンジニアリングは、大規模言語モデル (LLM) に対して適切な指示 (プロンプト) を設計し、望ましい出力を安定的に得るための技法である。同じモデルでもプロンプトの書き方で出力の形式や精度が変わるため、2026 年 8 月時点では LLM を組み込むシステムの設計作業の一部として扱われている。ただしモデルの世代交代が速く、ある世代で必要だった書き方が次の世代では不要になることもある。手法の名前を覚えるより、なぜ効くのかを押さえておく方が長持ちする。

主要なテクニック

下の表の手法は、どれもモデルの重みを変えずプロンプトの中身だけで出力を動かす。入出力の例を数個プロンプトに置く few-shot は Brown ら 2020 (GPT-3 の論文) が、勾配更新も fine-tuning もせずテキストのやり取りだけでタスクを指定する形として示した。推論の途中経過を書かせる Chain of Thought は Wei ら 2022 が導入し、例示を付けず「ステップごとに考えて」と足すだけの形は Kojima ら 2022 が zero-shot 側の変種として報告した。

テクニック	説明	効果
Zero-shot	例示なしで指示	シンプルなタスク向き
Few-shot	入出力の例を数個提示	出力形式の安定化
Chain of Thought (CoT)	「ステップごとに考えて」と指示	推論精度の向上
System Prompt	モデルの役割・制約を定義	一貫した振る舞い
出力形式の指定	JSON、Markdown 等を明示	パース可能な出力

Few-shot の例

few-shot はモデルの重みを一切変えず、プロンプト内の入出力の対からタスクの規則を推定させる。下は分類タスクで、ラベルの体系そのものを例で教えている。

以下の文を「ポジティブ」「ネガティブ」「ニュートラル」に分類してください。

例1: 「この製品は素晴らしい」 → ポジティブ
例2: 「配送が遅すぎる」 → ネガティブ
例3: 「昨日届きました」 → ニュートラル

分類対象: 「価格は高いが品質は良い」 →

例示があると出力形式は揃いやすくなる。ただしモデルは例から規則を推定するので、例の偏りもそのまま引き継ぐ。上で 3 つのラベルを 1 つずつ並べているのは、特定のラベルへ答えが寄るのを避けるためである。境界が曖昧な例を混ぜれば、判断の曖昧さも写る。

Chain of Thought (CoT)

複雑な推論タスクでは、答えだけを求めずに途中の手順を書かせると精度が上がることがある。Wei ら 2022 は、この効果が十分に大きいモデルで現れる性質だと報告している。小さいモデルでは手順を書かせても伸びないので、付ければ必ず良くなる指示ではない。

❌ 「100 人のうち 30% が合格し、合格者の 20% が優秀賞。優秀賞は何人？」
→ モデルが直感的に誤答するリスク

✅ 「ステップごとに計算してください。
     1. 合格者数を求める
     2. 優秀賞の人数を求める」
→ 30人 × 20% = 6人 (正答率が向上)

Bedrock での実装パターン

Bedrock の InvokeModel では、役割や制約を書く system と、対話の中身である messages がフィールドとして分かれている。プロンプトを 1 本の文字列に連結せずこの構造に沿って渡すと、役割の指示と入力データの境目が混ざりにくい。

const response = await bedrockClient.send(new InvokeModelCommand({
  modelId: 'amazon.nova-lite-v1:0',
  body: JSON.stringify({
    messages: [
      {
        role: 'user',
        content: [{ text: prompt }]
      }
    ],
    system: [{ text: 'あなたは技術文書の要約を行うアシスタントです。JSON 形式で回答してください。' }],
    inferenceConfig: {
      maxTokens: 1024,
      temperature: 0.1  // 低い温度で安定した出力
    }
  })
}));

temperature は次の語を選ぶときのばらつきを決める値である。下げると同じ入力に対する出力が揃いやすくなり、上げると語の選び方が広がる。揃うのはばらつきが減るからで、内容が正しくなるわけではない。誤った内容を安定して繰り返すこともある。Nova で指定できるのは 0 より大きく 1.0 未満の範囲で、省略時は 0.7 が使われる。出力を機械で受け取る分類・抽出は 0.1 前後まで下げ、表現の幅が欲しい文章生成は 0.5〜0.8 あたりに置くのが目安になる。

よくある落とし穴

プロンプトが曖昧: 「良い文章を書いて」ではなく「200 文字以内で、技術者向けに、箇条書きで」と具体的に指定する
コンテキストウィンドウの超過: 長すぎるプロンプトはモデルの入力上限を超える。要約や RAG で必要な情報だけを渡す
ハルシネーション対策の欠如: モデルの出力を無検証で使うと、事実と異なる情報が混入する。temperature を下げても事実の誤りは消えない (出力のばらつきが減るだけ) ので、根拠の提示を求める、値を手元のデータと突き合わせるといった検証を組み込む

手法を足す前に、出力のどこが不満なのかを分ける方が早い。形式が揃わないなら few-shot と出力形式の明示、途中の計算を誤るなら手順を書かせる指示、役割がぶれるなら system の見直しが効く。どれも効かない場合は書き方ではなく、渡している情報が足りていないか、選んだモデルが仕事に合っていない。

サイト情報

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