⚖️

プロダクトで使えるプロンプトテクニック

2025/07/28に公開

プロンプト

llm

tech

はじめに

私はベンチャー企業に勤めるソフトウェアエンジニアです。最近は専ら LLM と戯れる仕事をしています。LLM を使ったプロダクトは今後メジャーであり必須なスキルになると思います。そこで今回はちょっとしたプロンプトのテクニックを紹介します。

本記事では、私が実際に業務で使用し、効果を実感しているテクニックのみを厳選して紹介します。

プチテクニック一覧

具体例を必ず混ぜ込む

プロダクトに落とし込むとしたら必ずそのドメインが強く絡むと思います。ドメインを知らない LLM がいきなり質問されてもトンチンカンな回答が返ってきます。必ず具体例を混ぜ込みましょう。

悪い例

請求書の内容を分析してください。

良い例

請求書の内容を分析してください。

請求書には以下のような情報が含まれています：
- 請求書番号: INV-2024-001
- 発行日: 2024年1月15日
- 支払期限: 2024年2月14日
- 請求元: 株式会社サンプル（〒100-0001 東京都千代田区...）
- 請求先: 御社名
- 明細: 商品A x2個 @1,000円、商品B x1個 @3,000円
- 小計: 5,000円
- 消費税: 500円
- 合計: 5,500円

上記のような形式の請求書から、請求金額、支払期限、請求元会社名を抽出してください。

このアプローチにより、LLM は：

文脈を正しく理解できる
ドメイン特有の用語を学習できる
期待される処理内容を具体的に把握できる

実際のプロダクトでは、Few-shot 学習として複数の具体例を提示するとさらに効果的です。

以下は請求書分析の例です：

例1:
入力: [請求書画像またはテキスト]
出力: {"amount": 5500, "due_date": "2024-02-14", "vendor": "株式会社サンプル"}

例2:
入力: [別の請求書例]
出力: {"amount": 12800, "due_date": "2024-03-10", "vendor": "テスト商事"}

では、以下の請求書を同様に分析してください：
[実際の処理対象請求書]

自己修復

LLM 自身にレビューをやせて期待通りの出力になるように自己修復させる手法です。これは特に複雑なタスクや高い精度が求められる場面で効果を発揮します。

基本的な自己修復プロンプト

以下のタスクを実行してください：
[具体的なタスク内容]

出力の前に、自身で下記レビュー項目に合っているかどうかをレビューしてください。
満たされなければ再度初めからやり直してください。

レビュー項目：
1. 指定されたJSON形式で出力されているか
2. 必須フィールドがすべて含まれているか
3. 数値の範囲が適切か（0-100の範囲内など）
4. 論理的な矛盾がないか

最終出力のみを提示してください。

多段階自己修復

より高度な自己修復として、複数回の検証を組み込むことも可能です：

タスク: 売上データから月次レポートを生成

Step 1: データ分析を実行
Step 2: 分析結果の妥当性をチェック
- データの整合性は取れているか？
- 計算結果に明らかな誤りはないか？
- 前月比較で異常な変動はないか？

Step 3: 問題があれば分析をやり直し、なければレポート生成
Step 4: 生成されたレポートの最終チェック
- 経営陣にとって理解しやすいか？
- アクションアイテムは明確か？
- データの根拠は示されているか？

最終出力: 完成したレポート

ステップバイステップ

これはよく言われているものでステップバイステップにすることで精度が上がります。複雑なタスクを細分化することで、LLM の推論能力を最大限に活用できます。

悪い例

以下の顧客データを分析し、マーケティング施策を提案してください。
[大量の顧客データ]

良い例

以下の顧客データを分析し、マーケティング施策を提案してください。

Step 1: データの概要把握
- 顧客数、期間、データ項目を確認
- データの品質をチェック（欠損値、異常値）

Step 2: 顧客セグメンテーション
- 購買行動に基づくクラスタリング
- 各セグメントの特徴抽出

Step 3: セグメント別分析
- 各セグメントの収益性分析
- ライフタイムバリューの算出
- チャーン率の分析

Step 4: 施策提案
- セグメント別の最適なアプローチ提案
- 予想効果とコストの試算
- 実装優先度の設定

各ステップの結果を明確に示しながら進めてください。

Chain-of-Thought（思考の連鎖）との組み合わせ

問題: ECサイトの売上が先月比で20%減少。原因分析と対策を検討せよ。

思考プロセスを明示しながら分析してください：

Step 1: 仮説設定
思考: 売上減少の要因として何が考えられるか？
- 季節的要因？
- 競合の影響？
- サイトの技術的問題？
- マーケティング予算の変化？

Step 2: データ検証が必要な項目の特定
思考: 各仮説を検証するためにはどのデータが必要か？

Step 3: 分析手順の決定
思考: 効率的に原因を特定するための順序は？

Step 4: 対策の優先順位付け
思考: 即効性と実現可能性を考慮した場合の優先順位は？

最終アウトプット: 分析結果と具体的アクションプラン

プログラマティックに書く

特に複雑な内容の場合、LLM に段階的にタスクを教育してから実行させる手法が効果的です。一度記憶領域に情報を蓄積させてから、それを活用して次のステップを実行するアプローチです。

前項のステップバイステップに近いものになりますが、途中で LLM の記憶領域を活用して情報を管理させる点が特徴です。

基本的な記憶領域活用パターン

記憶領域を活用したプログラマティックなアプローチの基本パターンです。LLM に段階的に情報を蓄積させ、後続ステップでその情報を活用する手法を示します。

あなたは経理部門の請求書管理システムの専門家です。
月末に溜まった大量の請求書を効率的に分類・整理してください。

## ステップ1：請求書の基本情報収集
まず、すべての請求書を確認し、以下の情報を記憶領域に整理してください：

### 記憶領域に保存する項目：
- 請求書番号と発行日
- 請求元企業名と業種（IT/製造/サービス/その他）
- 請求金額（税込）
- 費用カテゴリの推定（システム関連/消耗品/サービス利用料など）
- 支払期限
- 緊急度（即払い/通常/余裕あり）

### 分類ルール：
- この段階では仮分類のみ行う
- 不明な点は「要確認」として記録
- 同一企業からの複数請求書も個別に記録

記憶領域への保存例：
「INV-001: ○○システムズ（IT）、98,000円、ライセンス料、2024-02-15期限、通常」
「INV-002: △△商事（製造）、12,500円、消耗品、2024-02-20期限、余裕あり」
「INV-003: ××サービス（サービス）、245,000円、保守料、2024-02-10期限、即払い」

## ステップ2：パターン分析と関連性の特定
記憶領域の基本情報を分析し、以下のパターンを特定してください：

### 分析項目：
- 金額帯別の分布（10万円未満/10-50万円/50万円以上）
- 業種別の請求傾向
- 費用カテゴリの出現頻度
- 支払期限の切迫度分布
- 同一企業からの複数請求の有無

### 記憶領域への追加保存：
- 「分類候補グループ」を以下の軸で作成：
  - 緊急度別グループ（即払い要/通常処理/後回し可）
  - 金額別グループ（高額/中額/少額）
  - 業種別グループ（IT関連/事務用品/その他サービス）
  - 承認フロー別グループ（部長承認要/課長承認/自動承認可）

例：「高額IT関連グループ（INV-001, INV-007, INV-015）: 全て10万円以上のシステム関連費用」

## ステップ3：最適な分類軸の決定
記憶領域の「分類候補グループ」を検証し、実務に最適な分類方法を決定してください：

### 分類の優先順位：
1. 支払緊急度（業務への影響度）
2. 承認必要レベル（決裁権限）
3. 金額規模（予算管理の観点）
4. 処理の複雑さ（事務手続きの工数）

### 検証項目：
- 各グループの件数バランスは適切か
- 処理担当者の作業分散は可能か
- 月次予算との整合性は取れているか
- 急ぎの支払いに対応できる分類か

## ステップ4：最終分類と処理指示の作成
記憶領域のすべての分析結果を統合し、実際の処理手順を決定してください：

### 各分類グループについて以下を定義：
- グループ名（処理担当者が理解しやすい名称）
- 含まれる請求書リスト
- 処理優先順位（1-5段階）
- 必要な承認フロー
- 支払予定日
- 特記事項（注意点や確認事項）

### 最終出力形式：
【緊急処理グループ】
- 請求書: INV-003, INV-008, INV-012
- 優先度: 1（最優先）
- 承認: 部長承認済み確認後即日処理
- 支払予定: 2024-02-09
- 特記事項: INV-008は契約更新に関わるため遅延厳禁

【通常処理グループ】
- 請求書: INV-001, INV-002, INV-004-007, INV-009-011
- 優先度: 2（通常）
- 承認: 課長承認後処理
- 支払予定: 2024-02-14
- 特記事項: 予算残高確認要

このパターンでは、LLM が各ステップで蓄積した情報を次のステップで確実に活用できるよう、記憶領域への保存内容を具体的に指示しています。単純に「請求書を分類して」と指示するよりも、段階的に情報を整理・分析・統合するプロセスを経ることで、実務で即座に活用できる精度の高い分類結果を得られます。

特に重要なのは、記憶領域に何を保存するかを明確に指示することです。これにより、LLM は処理途中で重要な情報を見落としたり、前のステップの結果を忘れたりすることなく、一貫した分析を行うことができます。

大量データの段階的処理

大量のデータを扱う場合、LLM の記憶領域を活用して段階的に処理することで、高い精度と一貫性を保つことができます。

500件の商品レビューを分析し、カテゴリ別の課題と改善点をまとめてください。

## ステップ1：初期分類とサンプリング
まず全500件のレビューをざっくりと以下のカテゴリに分類し、記憶領域に保存してください：
- ポジティブレビュー（星4-5）
- ネガティブレビュー（星1-2）
- 中立レビュー（星3）

各カテゴリから代表的なレビューを10件ずつ抽出し、詳細分析用のサンプルとして記憶領域に追加保存してください。

## ステップ2：詳細パターン分析
記憶領域のサンプルレビューを分析し、以下のパターンを特定してください：
- よく言及される商品の強み（配送、品質、価格など）
- 頻出する不満点（梱包、説明書、サポートなど）
- 顧客の主要な使用シーン
- 改善要望のパターン

特定したパターンを記憶領域に「パターンリスト」として整理保存してください。

## ステップ3：全体データへのパターン適用
記憶領域の「パターンリスト」を使って、残りの全レビューを効率的に分析してください。
各パターンの出現頻度をカウントし、記憶領域に「頻度データ」として蓄積してください。

処理中は50件ごとに進捗を記憶領域に記録し、異常なパターンや新しい傾向があれば「例外ケース」として別途記録してください。

## ステップ4：カテゴリ別課題の整理
記憶領域の「頻度データ」と「例外ケース」を統合し、以下の観点で課題を整理してください：
- 緊急対応が必要な課題（多数の顧客に影響）
- 長期改善対象の課題（根本的な改善が必要）
- 機会となる強み（さらに伸ばせる要素）

## ステップ5：最終レポート作成
記憶領域のすべての分析データを参照して、経営陣向けの包括的なレポートを作成してください：
- エグゼクティブサマリー（重要な発見3点）
- カテゴリ別詳細分析
- 推奨アクションプラン（優先度付き）
- 数値根拠（件数、割合、傾向）

このようなプロンプトでは、LLM が大量のデータを段階的に処理しながら、各ステップの結果を記憶領域に蓄積していくことで、最終的に一貫性のある高品質な分析結果を得ることができます。

特に重要なのは、中間結果を明示的に記憶領域に保存させることです。これにより：

各ステップの処理結果が後続ステップで確実に参照される
大量データでもコンテキストを失わずに処理継続できる
処理途中での進捗確認や品質チェックが可能
最終段階で全体を俯瞰した包括的な結論を導出できる

実際のプロダクトでは、顧客フィードバック分析、競合調査、マーケット分析など、様々な大量データ処理タスクでこの手法が活用できます。

このアプローチの最大の利点は、 LLM が処理途中の情報を忘れないことです。単純なステップバイステップでは各ステップが独立してしまいがちですが、記憶領域を明示的に活用することで、前のステップの結果を後のステップで確実に参照できます。

特にコンテキストが大きくなる場合や、複数の判断要素を総合して結論を出す必要がある場合に、この手法は非常に有効です。プロダクト開発では、ユーザーの複雑な要求や多段階の業務プロセスを自動化する際に、このような「教育 → 記憶 → 実行」の流れを意識したプロンプト設計が重要になります。

構造化出力

構造化出力とは？

構造化出力とは、LLM の出力を事前に定義した JSON スキーマに従って制限する手法です。プロンプトはシンプルに保ちながら、確実に構造化されたデータを取得できます。
ただし、必ず守るわけではないから注意が必要です。複雑な条件下ではスキーマを逸脱する場合があるため、別途リトライ機構と例外処理が重要です。

実装例

以下のような JSON スキーマを想定した実装を行います：

{
  "type": "object",
  "properties": {
    "sentiment": {
      "type": "string",
      "enum": ["positive", "negative", "neutral"]
    },
    "confidence": {
      "type": "number",
      "minimum": 0.0,
      "maximum": 1.0
    },
    "key_points": {
      "type": "array",
      "items": { "type": "string" },
      "minItems": 1,
      "maxItems": 5
    },
    "category": {
      "type": "string",
      "enum": ["品質", "価格", "配送", "サービス"]
    }
  },
  "required": ["sentiment", "confidence", "key_points", "category"]
}

これを TypeScript の Zod ライブラリで実装すると以下のようになります：

import { z } from "zod";
import { generateObject } from "ai";

// Zodスキーマ定義
const reviewSchema = z.object({
  sentiment: z.enum(["positive", "negative", "neutral"]),
  confidence: z.number().min(0.0).max(1.0),
  key_points: z.array(z.string()).min(1).max(5),
  category: z.enum(["品質", "価格", "配送", "サービス"]),
});

// TypeScript型の自動生成
type ReviewAnalysis = z.infer<typeof reviewSchema>;

// AI SDK呼び出し例
async function analyzeReview(reviewText: string): Promise<ReviewAnalysis> {
  const { object } = await generateObject({
    model: openai("gpt-4"),
    prompt: `レビューを分析してください: ${reviewText}`,
    schema: reviewSchema,
    maxRetries: 3, // スキーマ準拠まで自動リトライ
  });

  return object; // 自動的に型安全で検証済み
}

まとめ

世の中にはプロンプトテクニックが沢山ありますが、あまりプロダクトレベルで使えるものがなかったので私が普段使っている手法をまとめさせていただきました。

これらのテクニックは単独で使うよりも、組み合わせて使うことでより効果を発揮します：

構造化出力 + 具体例: ドメイン特化の安定した出力
ステップバイステップ + 自己修復: 高精度な複雑タスク処理
プログラマティック + 構造化出力: 大規模データの一貫した処理

プロンプトチューニングは試行錯誤が大変ですが今後必須のスキルになると思っているのでみなさん頑張っていきましょう。

実際のプロダクト開発では、これらのテクニックを基盤として、A/B テストによる継続的な改善や、ユーザーフィードバックを活用した最適化が重要になります。小さく始めて、徐々に改善していく姿勢が成功の鍵です。