プロンプトエンジニアリングとは?
プロンプトエンジニアリングはより良いLLM応答を得るためテキストプロンプトを最適化することです。モデルを変更したり外部データを追加したりしません。プロンプト自体を変更: 指示の明確性、例、出力フォーマット、トーン、ステップバイステップ推論。例: 「JSON形式で答える」（フォーマット）、「3つの例があります」（few-shot）、「ステップバイステップ考える」（推論構造）。プロンプトエンジニアリングは機能します。LLMは言い方に敏感です - 同じ質問を異なる方法で言い換えると、異なる品質の応答が生じます。
RAGとは?
RAG（Retrieval-Augmented Generation）は外部ナレッジベースから関連文書を検索し、LLMプロンプトに組み込みます。LLMはプロンプトと検索されたコンテキストに基づいて応答を生成します。例: ユーザーが「当社の返品ポリシーは何ですか?」と質問 → RAGがポリシードキュメントを検索 → LLMがそれらのドキュメントに基づいて応答を生成。RAGは「事実の幻覚」問題を解決: LLMが推測する代わりに、ドキュメントを参照します。
並列比較
直接比較:
| 側面 | プロンプトエンジニアリング | RAG |
|---|---|---|
| すること | プロンプトテキストを最適化 | 検索 + 生成 |
| 外部データ必要 | いいえ | はい（ナレッジベース） |
| 要求あたりコスト | $0.001～0.01 | $0.005～0.05 |
| レイテンシー | ~200ms | ~1～3s |
| 幻覚リスク | 高（知識不足） | 低（ドキュメント保証） |
| 必要インフラ | なし | Vector DB、embedding、検索 |
| 最適用途 | 推論、クリエイティビティ、汎用Q&A | 知識集約、ファクト、専有データ |
プロンプトエンジニアリング: 強み & 弱点
強み: (1) 外部インフラなし – プロンプトとLLMだけ。(2) 低コスト – 単一APIコール、最小トークン。(3) 高速 – ~200msエンドツーエンド。(4) 推論に良い – LLMはロジックと創造性に強い。(5) 柔軟 – 例、ステップバイステップ指示、出力フォーマットをその場で追加可能。 弱点: (1) 事実の幻覚 – LLMが事実を知らないと、発明する。(2) 知識カットオフ – トレーニングデータは特定日付まで。(3) 限定コンテキストウィンドウ – 何百万ドキュメントを参照できない。(4) パーソナライゼーションなし – 再トレーニングなしでユーザー固有データに適応できない。
RAG: 強み & 弱点
強み: (1) 幻覚排除 – 応答は検索ドキュメントに保証。(2) リアルタイム知識 – 検索で現在のデータ、財務報告、メール取得。(3) パーソナライゼーション – ユーザー固有ドキュメント検索可。(4) コンプライアンス – モデルがアクセスするデータを管理。(5) 説明性 – どのドキュメントが引用されたか表示可。 弱点: (1) 検索品質重要 – 悪い検索 → 悪い応答。(2) 高コスト – 検索 + embedding + 長いプロンプト = 2～5倍コスト増。(3) 高レイテンシー – 検索で500ms～2s追加。(4) インフラ複雑さ – Vector DB、embeddingモデル、検索ロジック必要。(5) 幻覚あり得る – 検索ドキュメントが不完全または矛盾。
コスト & レイテンシーのトレードオフ
コスト: プロンプトエンジニアリングはLLMトークンコストのみ（$0.001～0.01/要求）。RAG追加: (1) Embedding API（$0.0001～0.001/1Kトークン）、(2) Vector DBストレージ（$0.01～0.10/クエリ）、(3) 長いプロンプト（コンテキストウィンドウでトークン増）。総RAGコスト: $0.005～0.05/要求（2～5倍）。100万要求/月: PE $1,000～10,000。RAG $5,000～50,000。 レイテンシー: PE ~200ms（単一LLM呼び出し）。RAG ~1～3s: (1) クエリ embedding 100～300ms、(2) Vector DB検索 10～100ms、(3) ドキュメント検索 100～500ms、(4) LLM生成 500～2000ms。トレードオフ: RAGはより遅いが知識タスクで正確。
意思決定フレームワーク
3つの質問: 1. LLMは知識を持つ? タスクが汎用推論（数学、ロジック、創造的執筆、コーディング）ならLLMは十分知る。プロンプトエンジニアリング使用。 タスクが必要: 企業文書、リアルタイムデータ、ドメイン専門知識、専有 – LLMは持たない。RAG使用。 2. コスト/レイテンシー許容度? <500msで最小コスト必要（高容量public API）ならプロンプトエンジニアリング。1～3sと2～5倍コスト増許容ならRAG。 3. ファクト精度どれ重要? 幻覚不可（法的、金融、医療）ならRAG。幻覚許容可（ブレーンストーム、創造）ならプロンプトエンジニアリング。 決定木: - 知識タスク + 精度重要? → RAG - 汎用推論? → プロンプトエンジニアリング - 両方? → RAG + プロンプトエンジニアリング（コンテキスト検索、提示方法最適化）
よくある間違い
- プロンプトエンジニアリングで十分タスクにRAG使用 – 不要なコスト/レイテンシー追加。例: GPT-4oに「フランスの首都は?」聞く場合RAG不要。
- プロンプトエンジニアリングで知識タスク – 幻覚につながる。例: LLMに会社ポリシー引用させるが、RAGで提供しない。
- RAG検索品質に投資しないで構築 – システムはインデックスと順位付けと同程度。悪い検索 → 悪い応答。
- RAG完全に幻覚排除と思う – RAG減らすが排除しない。検索が不完全または矛盾ドキュメント見つけたらLLMエラーあり得る。
- エンドツーエンドレイテンシー測定しない – RAGレイテンシーは検索 + embedding + LLM含む。総レイテンシーがUX重要、LLM応答時間だけでなく。
- フォールバックなしRAG使用 – 検索失敗または何も見つからなかったら、LLMは最小コンテキスト受け取り幻覚可。フォールバック計画有（デフォルト応答、より広い検索再試行）。
これらを組み合わせられる?
はい – すべき。 知識集約的アプリ最適アプローチ: (1) RAG（関連ドキュメント検索）、(2) プロンプトエンジニアリング（LLMへのコンテキスト提示方法最適化）。例: サポートドキュメント検索 → コンテキストフォーマットのプロンプトエンジニアリング → LLMが有用応答生成。RAGの正確さとプロンプトエンジニアリングの明確性を結合。ほとんど本番システムは両方使用。
関連記事
FAQ
プロンプトエンジニアリング?
LLMに送るテキスト最適化して良い応答取得。指示、例、フォーマット含む。外部データ不要。
RAG?
ナレッジベースから関連文書検索し、LLMに組み込む。応答はそれらドキュメントに基づく。
プロンプトエンジニアリングいつ?
推論、クリエイティビティ、LLM持つ知識。速い、安い、インフラなし。
RAGいつ?
知識集約タスク: 文書、リアルタイムデータ、ドメイン。幻覚不可ときに必須。
コスト差?
PE: $0.001～0.01/要求。RAG: $0.005～0.05/要求（2～5倍）。
速度差?
PE: ~200ms。RAG: ~1～3s（検索、embedding、LLM）。
組み合わせられる?
はい。RAGでコンテキスト取得、プロンプトエンジニアリングで最適化。最強。
どちら正確?
RAG事実タスクで正確（ドキュメント根拠）。PE推論と創造性で十分。
検索失敗?
ナレッジベースに無関連文書なら、LLM最小コンテキスト受け取り幻覚可。
ファインチューニング代わり?
ファインチューニングは動作教える。知識はRAGが安く速い。