Skip to Content
Docs03. 実装プロンプトエンジニアリングの基礎技法
初級prompt-designfew-shot更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

プロンプトエンジニアリングの基礎技法

この記事の目的

汎用のプロンプト技法を「名前・何に効くか・使いどころ」で整理し、根拠を持って使い分けられるようになります。出回っている「魔法のフレーズ」をコピペするのではなく、技法がなぜ効くか(10 章の基礎)と、効果がモデル世代で変わるという前提を持って、検証しながら使える状態がゴールです。本ライブラリの Agent 向けプロンプト記事(Agent 向けプロンプト設計、コーディングエージェントへの依頼設計)を読む前提を揃える入口でもあります。

対象読者

  • LLM API を使い始めて、プロンプトを体系立てて書けるようになりたいエンジニア
  • 「なんとなく動いているプロンプト」を、説明・改善できる形に整えたい人

前提知識

本文

概要: 技法カタログとしての位置づけ

プロンプトエンジニアリング(prompt engineering)とは、モデルへの入力(指示・例・データ・形式)を設計して、出力の品質・形式・安定性を高める技法の総称です。本記事はどの LLM 呼び出しにも共通する汎用技法を扱います。分担は次のとおりです。

対象正本
汎用技法(本記事)明確な指示・区切り・例示・思考の誘導・分解・形式指定
Agent のシステムプロンプト(長期間・多状況で読まれる)Agent 向けプロンプト設計
コーディングエージェントコードベースを読み、ファイルを編集し、コマンドを実行して検証するループで開発タスクを遂行する Agent。コード補完と異なり「タスク単位の委任」を受けられる。への依頼文コーディングエージェントへの依頼設計
プロンプトの資産管理・バージョニングプロンプト資産の管理とバージョニング

基本原則: 明確・具体・分離

もっとも効果が大きく、もっとも陳腐化しにくいのは、特殊なテクニックではなく次の基本です。

例示(few-shot): 例が仕様書になる

few-shot(少数例示)は、期待する入出力の例をプロンプトに数個含める技法です。言葉で説明しにくい「形式・粒度・トーン・判断基準」を、例が仕様書として伝えます。例なし(zero-shot)で足りるならそれが最安ですが、出力形式のばらつきや判断基準のずれが出るときは、例示が最初の対策です。

思考の誘導と推論モデル

段階的推論(chain of thought)は、中間の推論ステップを例示・生成させる技法です。Wei らの原論文 では、評価したモデルの算術・常識・記号推論タスクで改善を報告しています。生成したステップが後続の生成条件になるという仕組みはありますが、途中の誤りも引き継ぐため、文章を長く考察させれば精度が上がるという保証はありません(LLM はどうやってテキストを生成するか)。

明示的な「ステップバイステップで考えて」の効果はモデルとタスクに依存します。例えば OpenAI の推論モデル向けガイド は、内部で推論するモデルにはこの指示が不要としています(2026-09-10 確認)。目標・制約・検証可能な成果物を指定し、利用中モデルの公式ガイドと自社評価で書き方を決めます。表示用の説明の長さと内部の推論量も区別します。

分解と連鎖: 1 プロンプトに詰め込まない

1 つのプロンプトに「分類して、抽出して、変換して、要約する」を詰め込むと、どこで失敗したか分からない不安定な塊ができます。ステップに分けて連結する(プロンプトチェーン)ことで、各段を個別にテスト・改善でき、失敗箇所も特定できます。

これはワークフロー型の設計そのものです — 手順が固定できるなら、分解した各ステップを LLM の部品として使うのが、Agent 化より先に検討すべき構成です。分解の粒度は「1 ステップ 1 責務」を目安にします。

形式指定: プロンプトで頼むか、構造で強制するか

出力形式は明示的に指定します(見出し構成・箇条書き・表・JSON)。ただし、後続の処理がコードである出力(JSON など)は、プロンプトでの指定ではなく構造化出力LLM の出力を JSON Schema などの機械可読なスキーマに従わせる技術。後続の処理がコードである出力(分類・抽出・スコア)に使う。の仕組みで強制するのが原則です。プロンプトの「JSON で出力して」は高確率で従われますが保証ではなく、前置きや欠けたカンマが混ざる事故を防げません(構造化出力)。プロンプトでの形式指定は、人間が読む出力のスタイル制御に使います。

技法の陳腐化との付き合い方

プロンプト技法には賞味期限があります。モデルの世代が変わると、以前は必要だった補助(強い強調・特定の言い回し・細かな手順指定)が不要になったり、逆効果になったりします。「チップを払う」「深呼吸して」のような一時期話題になったフレーズの多くは、特定モデル・特定時点の観察であり、普遍的な技法ではありません。付き合い方は 3 つです。

  1. 技法は評価で検証してから採用する: 「効くらしい」を自分のタスクの評価セットで確かめます(Agent 評価の基礎)。数ケースの手動確認でも、ゼロよりはるかにましです
  2. プロンプトを資産として管理する: 何をなぜ入れたかを記録し、変更は回帰テストプロンプト・ツール・モデルの変更で既存の品質が壊れていないかを、評価データセットの再実行と前回比較で検知するテスト。とセットにします(プロンプト資産の管理とバージョニング)。理由の分からない「呪文の地層」を作らないことです
  3. 一次情報発信源そのものの情報(論文の原典・公式ドキュメント・公式ブログ・規格本文・法令)。解説・まとめ(二次情報)と区別し、根拠は一次情報に置くのが情報リテラシーの基本。二次情報は「存在を知る」までに使い、一次まで遡って確かめる。を参照する: 使っているモデルの公式プロンプトガイドが、そのモデルでの推奨の正です。まとめ記事の孫引きより公式を見ます

実務での注意点

アンチパターン

  • 出回っている「魔法のフレーズ」を検証なしに足す → 効果がないか逆効果でもプロンプトに残り続け、呪文の地層になる → 評価セットで確認してから採用し、理由を記録する
  • 指示・例・データを区切りなく混ぜる → 出力が不安定になり、データ内の文字列が指示として解釈される事故の入口にもなる → 区切り(タグ・記号)で構造化する
  • 機械処理する JSON をプロンプト指定だけで得ようとする → 前置き・形式崩れがまれに混ざり、パースが落ちる → 構造化出力の仕組みで強制する
  • 禁止事項のリストを増やし続ける → 重要な制約が埋もれ、指示追従の強いモデルでは過剰反応も起きる → 「せよ」形式に書き換え、禁止は少数に絞る
  • モデル更新後も古いプロンプトを無検証で使い続ける → 前世代の癖を補っていた表現が過剰・不要になっている → 更新時に評価セットで再検証する(バージョニング・デプロイ・モデル更新追従)

チェックリスト

  • 指示に長さ・観点・読み手・除外事項が明示されている
  • 指示とデータが区切りで分離されている
  • 例示を使う場合、境界ケースを含み、偏りを確認した
  • 機械処理する出力は構造化出力で強制している
  • 複数責務のプロンプトを分解できないか検討した
  • 採用している技法に「なぜ入れたか」の記録と検証結果がある

関連トピック

参考資料

TODO・未確認事項

ファインチューニングと蒸留プロンプトエンジニアリングの上級パターン