プロンプトエンジニアリングの基本

LLMは与えられたプロンプト(入力テキスト)に基づいて出力を生成します。 同じモデルでも、プロンプトの書き方ひとつで出力の品質は劇的に変わります。 この「プロンプトの設計技術」がプロンプトエンジニアリングです。

効果的なプロンプト設計には、3つの基本原則があります。

明確な指示

曖昧な表現を避け、LLMに期待する出力の形式・長さ・トーンを具体的に指定します。 「要約して」ではなく「3文以内で、技術者向けに要約して」と書くだけで、出力の品質は大幅に向上します。

構造化

プロンプトをセクション分けし、入力データ・指示・出力形式を明確に区切ります。 XMLタグやマークダウンの見出しを使った構造化は、LLMが文脈を正確に把握する助けになります。

<role>あなたはシニアソフトウェアエンジニアです。</role>
<task>以下のコードをレビューし、改善点を指摘してください。</task>
<format>各改善点について「問題」「理由」「修正案」の3項目で回答してください。</format>
<code>
  // レビュー対象のコード
</code>

ロールプロンプティング

LLMに特定の役割を与えることで、その専門領域に適した応答を引き出す手法です。 「あなたはセキュリティの専門家です」と前置きすれば、セキュリティ観点を重視した回答が得られます。 研究では、適切なロール設定が回答精度を有意に改善することが示されています。

主要テクニック

プロンプトエンジニアリングには、複数の確立されたテクニックがあります。 タスクの性質に応じて使い分けることが重要です。

テクニック 概要 適用場面 精度への影響
Zero-shot 例示なしで直接タスクを指示 単純な分類・翻訳 ベースライン
Few-shot 数個の入出力例を提示してからタスクを指示 フォーマット指定・分類 中程度の改善
Chain-of-Thought (CoT) 「ステップバイステップで考えて」と推論過程を促す 数学・論理推論 最大28.2%向上
Tree of Thoughts (ToT) 複数の推論パスを木構造で探索 創造的問題解決・計画立案 大幅な改善
ReAct 推論(Reasoning)と行動(Action)を交互に実行 ツール利用・情報検索 タスク依存

Zero-shotとFew-shot

Zero-shotは例示なしでタスクを指示する最もシンプルな手法です。 GPT-4クラスのモデルでは、Zero-shotでも多くのタスクで実用的な性能を発揮します。

Few-shotは、期待する入出力の例を数個(通常2〜5個)提示してからタスクを実行させます。 出力フォーマットの統一や、ニュアンスの伝達に特に有効です。

# Few-shotプロンプトの例
以下の文のセンチメントを判定してください。

文: 「この映画は期待以上に面白かった」→ ポジティブ
文: 「サービスが遅くて残念だった」→ ネガティブ
文: 「普通の味だった」→ ニュートラル

文: 「新機能のおかげで作業効率が2倍になった」→

Chain-of-Thought(CoT)

2022年にGoogleの研究チームが発表したCoTは、LLMに推論過程を明示的に生成させるテクニックです。 「ステップバイステップで考えてください」という一文を加えるだけで、算術・常識推論・記号推論において最大28.2%の精度向上が報告されています(Wei et al., 2022)。

CoTが機能する理由は、中間ステップを生成することでモデルが「作業メモリ」を持つのと同等の効果が得られるためです。 複雑な問題を小さなサブ問題に分解し、各ステップの正確性を積み上げていくことで、最終的な回答精度が向上します。

Tree of Thoughts(ToT)

CoTが一本道の推論であるのに対し、Tree of Thoughts(Yao et al., 2023)は複数の推論パスを木構造で並行探索します。 各ノードで複数の「思考」候補を生成し、有望なパスを深さ優先探索(DFS)や幅優先探索(BFS)で選択的に展開します。 行き詰まったパスはバックトラックして別の可能性を探ることができるため、創造的な問題解決や計画立案に強みを発揮します。

ReAct — 推論と行動の統合

ReAct(Yao et al., 2022)は、LLMに推論(Reasoning)行動(Action)を交互に実行させるフレームワークです。 LLMが「次に何を調べるべきか」を推論し、外部ツール(検索API、計算機、データベースなど)を呼び出して情報を取得し、その結果をもとに再度推論する — というループを繰り返します。 現在のAIエージェントの多くはReActパターンを基盤としています。

Embedding(埋め込み表現)

Embeddingとは、テキスト(単語・文・文書)を高次元の数値ベクトルに変換する技術です。 意味的に近いテキストはベクトル空間上でも近い位置にマッピングされるため、テキスト間の意味的な類似度を数学的に計算できます。

ベクトル間の類似度はコサイン類似度で測定するのが一般的です。 2つのベクトルが同じ方向を向いているほど値が1に近づき、意味的に類似していることを示します。

Embeddingは後述するRAGの根幹技術であり、以下のようなユースケースで広く活用されています。

  • セマンティック検索 — キーワード一致ではなく、意味的な類似性で文書を検索
  • 文書クラスタリング — 類似文書を自動的にグループ化
  • レコメンデーション — ユーザーの興味に意味的に近いコンテンツを推薦
  • 重複検出 — 表現は異なるが意味が同じ文を検出

RAGアーキテクチャ

RAG(Retrieval-Augmented Generation)は、LLMの知識をリアルタイムに外部データで補完する手法です。 LLM単体では訓練データに含まれない最新情報や社内ドキュメントを参照できませんが、RAGを導入することでこの制約を克服できます。

RAGの処理フローは大きくインデックス構築フェーズクエリ実行フェーズに分かれます。

graph LR
  subgraph インデックス構築フェーズ
    A[文書群] -->|チャンク分割| B[テキストチャンク]
    B -->|Embeddingモデル| C[ベクトル化]
    C -->|格納| D[(ベクトルDB)]
  end

  subgraph クエリ実行フェーズ
    E[ユーザー質問] -->|Embeddingモデル| F[クエリベクトル]
    F -->|類似検索| D
    D -->|Top-K取得| G[関連チャンク]
    G -->|コンテキスト注入| H[拡張プロンプト]
    H -->|生成| I[LLM]
    I --> J[回答]
  end

  style A fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style D fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style I fill:#f97316,stroke:#ea580c,color:#fff
  style J fill:#14b8a6,stroke:#0d9488,color:#fff
RAGの全体フロー: 文書をチャンク分割→ベクトル化→DB格納し、クエリ時に類似検索→コンテキスト注入→LLM生成

チャンク分割

長い文書はそのままEmbeddingしても精度が低下するため、適切なサイズにチャンク分割します。 一般的なチャンクサイズは200〜1000トークンで、前後のチャンクと50〜100トークン程度のオーバーラップを持たせることで、文脈の断絶を防ぎます。 分割方法には、固定長分割、文境界分割、セマンティック分割(意味的な区切りで分割)などがあります。

検索とコンテキスト注入

ユーザーの質問をEmbeddingモデルでベクトル化し、ベクトルDB内の類似チャンクをTop-K件取得します。 取得したチャンクをプロンプトに組み込み(Augmentation)、「以下のコンテキストに基づいて回答してください」とLLMに指示します。 これにより、LLMは自身の訓練データにない情報も参照した上で回答を生成できます。

# RAGプロンプトの典型例
あなたは社内ドキュメントに基づいて回答するアシスタントです。
以下のコンテキストのみを使って質問に回答してください。
コンテキストに情報がない場合は「情報が見つかりませんでした」と回答してください。

## コンテキスト
{retrieved_chunks}

## 質問
{user_question}

ベクトルDB

RAGの性能はベクトルDBの選択に大きく左右されます。 Embeddingされたベクトルを高速に格納・検索するために最適化された専用データベースが複数存在します。

ベクトルDB 特徴 ホスティング 適用規模
Pinecone フルマネージド、高速な近似最近傍探索、運用負荷が低い クラウド専用 中〜大規模
Weaviate ハイブリッド検索(ベクトル+キーワード)、GraphQL API セルフホスト/クラウド 中〜大規模
Chroma 軽量・組み込み可能、Python/JSネイティブ、プロトタイプに最適 ローカル/クラウド 小〜中規模
pgvector PostgreSQL拡張、既存RDBに統合可能、SQL対応 セルフホスト/クラウド 小〜中規模

テスト時計算(Test-Time Compute)

従来のLLM性能向上は「訓練時により多くのデータ・計算を投入する」アプローチが主流でした。 これに対し、テスト時計算推論時(テスト時)に追加の計算リソースを投入して性能を高める手法群です。 OpenAI o1やDeepSeek-R1に代表される「推論モデル」の基盤技術でもあります。

Self-Consistency

同じ質問に対して複数の推論パスを生成し、最も多く得られた回答を最終回答として採用する手法です(Wang et al., 2022)。 CoTとの組み合わせで使用されることが多く、温度パラメータを上げて多様な推論を生成し、多数決で最終回答を決定します。 算術推論タスクでは、単一のCoTに比べて大幅な精度向上が報告されています。

Self-Refinement

LLM自身に生成した回答を批判・修正させるプロセスを反復する手法です。 「この回答の問題点を指摘してください」→「指摘を踏まえて回答を改善してください」というループを数回繰り返すことで、出力品質が段階的に向上します。

RLVR(Reinforcement Learning with Verifiable Rewards)

数学やコーディングなど正解を自動検証できるタスクにおいて、推論時にモデル自身が探索と検証を繰り返す手法です。 DeepSeek-R1の訓練で注目を集めたRLVRは、人間のフィードバックなしに推論能力を大幅に向上させました。 正解が検証可能な報酬として機能するため、大規模な人間のアノテーションを必要としない点が画期的です。

理解度チェック

問題 0 / 50%
Q1

Chain-of-Thought(CoT)プロンプティングの主な効果として正しいものはどれですか?

キーボード: 1〜4 で選択、Enter で回答