プロンプトエンジニアリングとは？4要素と手法の例、ファインチューニングとの使い分け

プロンプトエンジニアリングとは、大規模言語モデル（LLM）に渡す入力を設計し、狙った出力を安定して得るための技術です。同じモデルでも入力の書き方で結果が変わるため、モデル選定と並ぶ設計項目になります。ただし2025年以降、内部で推論する推論モデルの普及や、APIからの temperature の廃止によって、定番だった手法がそのまま通用しない場面が増えました。この記事では、プロンプトの4要素、主要手法の例と使う順序、推論モデルでの扱い、ファインチューニングとの使い分け、業務へ載せる手順までを一次情報をもとに整理します。

まとめ：プロンプトエンジニアリングの要点と手法を選ぶ順序

プロンプトは命令・文脈・入力データ・出力形式の4要素で点検できます。すべてを毎回含める必要はありません。まず例示なし（Zero-shot）で試し、精度が足りないときに限ってFew-shotや知識生成プロンプティングを足す。長い処理は1本のプロンプトに詰め込まず、プロンプトチェーンで段に分けて途中結果を検証します。役割設定（ロールプロンプティング）は口調や観点をそろえる目的で使い、正答率の改善は個別の評価で確かめます。

推論モデルに対しては、OpenAIが「段階的に考えて」と書くChain-of-Thoughtの指示を公式に「不要」としています。また、Claude APIの2026-10-21版では temperature・top_p・top_k が廃止され、送ると400エラーになります。出力の揺れをパラメータで抑える前提は、使うAPIごとに確かめ直す必要があります。

プロンプトで直せないときは、足りないものが「知識」ならRAG、「振る舞いの一貫性」ならファインチューニングへ進みます。ただしOpenAIのセルフサービス型ファインチューニングでは、2026年5月7日以降、過去に利用したことのない組織は新しく学習を始められません。以下、根拠と具体例を順に示します。

プロンプトエンジニアリングの意味とプロンプトとの違い

プロンプトは入力文、エンジニアリングは設計と検証という関係

プロンプト（prompt）は、LLMに与える入力文そのものです。「この記事を200字で要約して」という一文もプロンプトに当たります。プロンプトエンジニアリングは、その入力をどう構造化すれば意図どおりの出力が安定するかを設計し、検証して改善する技術全体を指します。「エンジニアリング」は工学の意味で、思いつきの言い回しではなく、条件を変えて結果を比べ、再現できる形に落とすところまでを含みます。入力文そのものの意味や書き方の基本はプロンプトとは何かを扱った記事で整理しているため、ここでは設計と検証の側に絞ります。

混同されやすいのがシステムプロンプトです。システムプロンプトはアプリケーション側が固定で与える役割や制約で、利用者が都度入力するプロンプトの外枠に当たります。業務システムでは外枠の設計が出力品質を左右するため、システムプロンプトの指定方法と書き方も併せて押さえておくと再現性が上がります。

出力が毎回変わる仕組みと、temperatureで揺れを抑えられないAPI

LLMは、入力されたトークン列に続く確率の高いトークンを選び続けて文章を作ります。条件が変われば出力も変わる。「要約して」だけでは長さも粒度も読者も決まっておらず、モデルが選んだ長さや粒度は期待とずれやすくなります。同じ入力でも生成の非決定性で回答が変わる場合があり、こちらは書き漏らしとは別の問題です。生成の仕組みそのものはLLMの仕組みと企業導入の判断基準で扱っています。

揺れを抑える手段として、以前は temperature を0に近づける設定が定番でした。しかしAnthropicのAPIバージョン履歴によると、2026年10月21日公開のAPIバージョン2026-10-21では temperature・top_p・top_k が削除され、どのモデルでも送った時点で400エラーになります。廃止パラメータの一覧によれば、それより前のAPIバージョンでもClaude 4.7以降のモデルには既定値以外を送れず、代わりの手段は「プロンプトで振る舞いを導く」です。OpenAIも最新モデルの移行ガイドで、reasoning effort を none 以外にする場合は temperature と top_p を外すよう案内しています。パラメータで揺れを抑えられない以上、出力をそろえる手段は入力側の条件指定と出力形式の固定に移りました。移行時の書き換えはClaude API 2026-10-21移行ガイドにまとめています。

プロンプトの4要素（命令・文脈・入力データ・出力形式）

4要素の役割と、Output Indicator（出力形式）の書き方

実務で使えるプロンプトは、4つの要素に分けて点検できます。この分け方はDAIR.AIのPrompt Engineering Guide「Elements of a Prompt」に基づくもので、同ガイドは Instruction・Context・Input Data・Output Indicator を挙げたうえで「4要素すべてが必要なわけではない」と書いています。Output Indicator は出力の種類や形式の指定で、本記事では「出力形式」と呼びます。

4要素のうち抜けやすいのが出力形式です。長さと形式を指定しないと、後工程の整形に手間がかかります。受け取り側がプログラムなら、形式の指定は精度の問題ではなく実装の問題として先に決まります。JSONで受け取るなら、キー名と型、出力例を示します。プロンプトだけで形式を保証せず、利用APIのスキーマ制約機能の対応を確認し、受け取り側でも構文・型・必須項目を検証します。

区切り記号で命令と入力データを分ける書き方

命令と入力データが続けて書かれていると、モデルが入力データ内の文を命令と取り違えることがあります。OpenAIのReasoning best practicesも、Markdown・XMLタグ・セクション見出しといった区切り記号で入力の各部分を明示するよう勧めています。4要素を見出しで区切ると次の形になります。

# 命令
以下の議事録を要約する。

# 文脈
読者は非エンジニアの経営層。専門用語は使わない。

# 入力データ
<minutes>
（ここに議事録の本文）
</minutes>

# 出力形式
箇条書き5点。各60字以内。日本語。

入力データの範囲をタグで囲っておくと、その中に紛れ込んだ指示文を「データの一部」として扱う設計が組みやすくなります。後述するプロンプトインジェクション対策の最初の一手でもあります。

主要なプロンプト手法の例と使う順序

手法は「モデルに先に何を出させるか」で見分けると、使い分けを判断しやすくなります。

以下は手法の紹介順です。適用はZero-shotから始め、例示・観点指定・推論・前提知識・処理分割のどこに課題があるかで選びます。

Zero-shotとFew-shotの使い分けと例示の追加条件

例を与えずタスクだけを指示するのがZero-shot、入出力の例を添えるのがFew-shotです。Few-shotの有効性は、1,750億パラメータのGPT-3を扱った論文「Language Models are Few-Shot Learners」（Brown et al., 2020）で示され、以後の定番になりました。分類ラベルの粒度や独自フォーマットのように、言葉で説明するより見せたほうが早い指示で効きます。

順序はZero-shotが先です。例示はトークンを消費するうえ、例の偏りがそのまま出力の偏りになります。例えば、肯定的な文面だけを例示すると、出力が肯定側に偏る可能性があります。曖昧な質問文が原因でぶれているなら、例を足す前にRephrase and Respond（RaR）で質問を言い換えさせるほうが効く場合もあります。例の選び方と並べ方はFew-shotプロンプトの例示の選び方で詳しく扱っています。

ロールプロンプティング：役割設定が効くのは口調と観点

ロールプロンプティングは、「あなたは経験10年の税理士です」のようにモデルへ役割を与える手法です。AnthropicのPrompting best practicesは、システムプロンプトで役割を設定すると用途に合わせて振る舞いと口調が絞られ、1文でも違いが出るとしています。

一方で、役割設定による正確さの一貫した改善は、次の研究では確認されていません。Zheng et al.（EMNLP 2024 Findings）は、2024年10月の改訂版で162種類の役割を4系統のLLMと2,410問の事実問題で検証し、システムプロンプトにペルソナを加えても、加えない場合と比べて性能は上がらなかったと報告しました。問題ごとに最適な役割を自動で選ぶ試みも、ランダムに選ぶのと大差なかったとしています。なお2023年11月の初稿は「対人関係の役割を加えると性能が一貫して上がる」と結論しており、改訂で結論が逆になった論文です。

したがって役割は、文体・専門用語の水準・評価の観点（例：「監査担当者の立場で指摘する」）をそろえる目的で使います。事実の正確さが要る場面で「専門家です」と書いて安心するのは誤りで、根拠資料を入力データとして渡し、回答が資料と一致しているかを評価します。

CoT・Self-Consistency・Tree of Thoughtsの仕組みと処理負荷

Chain-of-Thought（CoT）は、答えだけでなく推論の過程を書かせて、多段階の計算や論理問題の正答率を上げる手法です。Wei et al.が2022年に提案し、同年にKojima et al.が例示なしで「Let’s think step by step」と添えるだけでも効くZero-shot-CoTを示しました。「段階的に考えて」という定番の言い回しはここから来ています。

Self-Consistency（Wang et al., ICLR 2023）は、推論経路を複数サンプリングし、最も多く一致した答えを採る方法です。論文ではCoT単独と比べ、算数文章題のGSM8Kで17.9ポイント、SVAMPで11.0ポイント正答率が上がりました。Tree of Thoughts（Yao et al., NeurIPS 2023）は推論を木構造に広げ、途中で自己評価して引き返せるようにした手法で、4つの数字から24を作るGame of 24ではGPT-4の成功率がCoTの4%から74%に上がっています。

ただしどちらも生成・評価の処理が増えます。費用はモデル単価や総トークン数、待ち時間は処理の依存関係や並列化の可否によって変わり、呼び出し回数だけには比例しません。Self-Consistencyは出力のばらつきを前提にした手法なので、temperature を指定できないAPIでは、ばらつきの幅を自分で調整できない点にも注意が要ります。書き方の型と失敗例はCoTプロンプトの書き方と限界で扱っています。

知識生成プロンプティングの例と前提知識の点検

知識生成プロンプティング（Generated Knowledge Prompting）は、いきなり答えさせず、まず問題に関係する知識をモデル自身に書き出させ、それを材料に回答させる手法です。Liu et al.（ACL 2022）は4つの常識推論タスクで性能が上がり、NumerSense・CommonsenseQA 2.0・QASCでは当時の最高値を出したと報告しています。構造化された外部知識ベースや、生成した知識を回答に統合するためのタスク専用の教師あり学習を必要としない点が特徴です。

業務では、モデルが学習済みの一般知識を整理する用途で試せます。未学習の社内用語や社内固有の前提は、資料として別途渡す必要があります。2段に分けると次の形です。

# 1段目
割れやすい陶器を箱で送るときに、破損を防ぐ一般的な知識を箇条書きで挙げる。
不確かな項目には「要確認」と付ける。

# 2段目
人が点検した上の知識を材料に、次の質問へ答える。
知識のうち「要確認」の項目は回答の根拠に使わない。
質問：陶器同士が箱の中でぶつからないようにするには、どう梱包すればよいか。

1段目の出力を人やプログラムが点検できるのが利点です。前提を取り違えていれば、回答が出る前に気づけます。逆に、書き出させた知識そのものが誤っていると誤りが補強されるため、法令や価格のように正誤が決まる情報は、モデルに生成させず一次資料を入力データとして渡します。

プロンプトチェーンの例：問い合わせ対応の4段構成

プロンプトチェーンは、複雑なタスクを複数のプロンプトに分け、前段の出力を後段の入力として渡す手法です。顧客からの問い合わせメールに返信案を作る処理なら、次の4段に分けられます。

4段を1本のプロンプトに詰め、途中結果を記録しない場合は、誤った返信が出たときに失敗箇所を切り分けにくくなります。分ければ、失敗した段だけを差し替えて再実行できます。前段まで成功した条件下で各段が成功する確率をそれぞれ0.9と仮定すると、4段すべての成功率は0.9の4乗で約0.66です。再試行は検出できた失敗の回復に役立ちますが、形式検証だけでは内容の正しさを保証できません。段の切り方と検証の置き方はプロンプトチェイニングの設計と採用判断にまとめています。

OpenAIの推論モデルに対するCoT指示の扱い

入門記事の多くと結論が分かれるのがこの論点です。推論モデル（reasoning model）は、回答を出す前に内部で推論トークンを使って考えます。この世代に対してOpenAIのReasoning best practicesは、2026年10月時点でも次のように書いています。

“Avoid chain-of-thought prompts: Since these models perform reasoning internally, prompting them to “think step by step” or “explain your reasoning” is unnecessary.”（Chain-of-Thoughtのプロンプトは避ける。これらのモデルは内部で推論するため、「段階的に考えて」「推論を説明して」と指示するのは不要である）

同じページは、「段階的に考えて」のような手法は性能を上げないことがあり、妨げになる場合もあると添えています。並べて挙げられている推奨は、プロンプトを簡潔かつ直接的に保つ、区切り記号を使う、まずZero-shotで試して必要なときだけFew-shotを足す、成功条件を具体的に書く、の4点です。まず達成すべきゴール・守る制約・出力形式を明示します。内部の思考手順を細かく指定する必要はありませんが、業務上必須の処理順序や確認手順は指示に含めます。

OpenAIの対応モデルでは、推論量の調整に reasoning.effort を使えます。同社のReasoningガイドは reasoning.effort の値として none・minimal・low・medium・high・xhigh・max を挙げ（対応はモデルによる）、「品質を取り戻す主な手段ではなく、調整つまみとして扱う」としています。ゴールの書き方が曖昧なまま推論量だけ上げても、品質は戻りません。一方AnthropicのPrompting best practicesは、Claudeが考えるかどうかや考え方をプロンプトで誘導できると説明しています。文面での誘導が効くかは、モデルごとの公式ガイドと評価結果で判断します。

反対に、内部推論を行わないモデルではCoTを試す余地があります。ただし、軽量モデルでの有効性は保証されず、対象タスクで比較評価が必要です。処理ごとにモデルを分けるなら、プロンプトも書き分けます。社内のプロンプト集に「必ず段階的に考えさせる」とあるなら、どのモデル向けの指示かを書き添えて整理し直す時期です。

プロンプトエンジニアリングとファインチューニング・RAGの使い分け

知識不足と振る舞いの不一致に応じた手段の選択

OpenAIの精度最適化ガイドは、プロンプト→RAG→ファインチューニングと一直線に進む考え方を否定し、課題を2つの軸で分けるよう勧めています。モデルが知らない・知識が古い・社内固有の情報が要る場合は「コンテキストの最適化」でRAGの領域、形式が崩れる・口調が合わない・推論の手順が守られない場合は「LLMの最適化」でファインチューニングの領域です。2つは排他ではなく重ねて使えます。

どちらへ進む場合も、出発点はプロンプトです。同ガイドは、まずプロンプトエンジニアリングで評価データセットを作り、それを基準値にするよう勧めています。基準値が無いままファインチューニングに進むと、学習で良くなったのかを測れません。毎回大量の例示で出力形式を矯正しているなら、そこが学習へ切り替える目安です。RAGとファインチューニングの比較はRAGとファインチューニングの違いと使い分けで詳しく扱っています。

ファインチューニングを選ぶ前に確かめる提供状況

ファインチューニングは、使えるかどうか自体が変わりつつあります。OpenAIの非推奨・廃止の告知ページによると、セルフサービス型ファインチューニングは段階的に縮小されます。2026年5月7日から過去に利用したことのない組織は学習を始められず、7月2日からは直近60日にファインチューニング済みモデルで推論していない組織も対象になり、2027年1月6日には既存の利用者も新しい学習ジョブを作れなくなります。学習済みモデルでの推論は、元のモデルが廃止されるまで使えます。

セルフサービス型を使えない組織は、他社のクラウドやオープンモデルで学習するか、プロンプトとRAGの範囲で解くかを先に決めます。学習データの作り方はファインチューニング用データセットの作り方にまとめています。

コンテキストエンジニアリングへの拡張と、渡す情報を絞る設計

入力文だけを磨いても解けない問題があります。エージェントのように複数ターンで判断を重ねる用途では、会話履歴・検索結果・ツール定義・システムプロンプトなど、モデルが参照する情報全体が出力を左右します。この情報全体を設計の対象にする考え方がコンテキストエンジニアリングで、Anthropicは2025年9月29日公開のエンジニアリング記事で、これをプロンプトエンジニアリングの自然な発展形と位置づけました。

同記事の要点のひとつが context rot です。コンテキスト内のトークン数が増えるほど、そこから情報を正確に取り出す能力が落ちる現象で、程度の差はあってもすべてのモデルに現れるとしています。関係しそうな資料を全部詰め込むと逆効果になり得るため、必要な情報だけを必要な順で渡す設計が要ります。質問の意図に応じて参照先を切り替えるOmniRAGのような検索設計パターンはその選択肢のひとつで、固定の前提を毎回送るならプロンプトキャッシュで入力コストを下げられます。考え方の全体像はコンテキストエンジニアリングとプロンプトエンジニアリングの違いで整理しています。

プロンプトインジェクションを多層で防ぐ設計

外部からの入力をプロンプトに組み込むシステムは、指示を乗っ取られるおそれがあります。OWASPのTop 10 for LLM Applications 2025では、プロンプトインジェクションが LLM01 として最上位に置かれています。

利用者が入力欄に「これまでの指示を無視せよ」と書き込む直接型に加え、RAGやエージェントでは、読み込むWebページや社内文書に指示文を仕込む間接型が現実の脅威になります。LLMは指示とデータを本質的に区別できないため、言い回しの工夫だけでは防げません。命令とデータを区切り記号で分ける、出力をそのまま実行系へ渡さず検証を挟む、ツールの権限を最小限に絞る、と設計側で重ねて備えます。攻撃の類型と個別の対策はプロンプトインジェクションの仕組みと対策で扱っています。

プロンプトを業務へ載せる手順：テンプレート化・版管理・評価

プロンプトのテンプレート化とモデル名・版の記録

業務で起きやすいのは、誰かが見つけた良い書き方が共有されないまま消える損失です。プロンプトはコードと同じ資産としてテンプレートに切り出します。切り出す境目は、4要素のうち固定できる部分と毎回変わる部分の間です。命令・文脈・出力形式は業務ごとに固定でき、入力データだけが実行のたびに入れ替わります。例えばGitでテンプレートを管理し、コミットID・実際に指定したモデルID・パラメータ・評価セットの版を実行記録に残します。文面の変更、参照データの変更、モデルの世代交代はどれも出力を変えるため、この記録があれば「モデルを上げたら壊れた」のか「文面を直したら壊れた」のかを後から切り分けられます。

評価データセットによる変更前後の比較と本番投入の判定

プロンプトを直して「良くなった気がする」で止めると、副作用に気づけません。AnthropicのPrompt engineering overviewも、プロンプトを改善する前提として、成功基準の定義と、それを実際に試せる方法を先に用意するよう求めています。想定入力と期待出力の組を評価データセットとしてそろえ、変更の前後で同じ入力を流して比べる。この工程があるかどうかが、試行錯誤と設計の分かれ目です。指標の選び方はLLM評価の指標とデータセット設計に整理しました。

評価データは、例えば現場の失敗例10件を集めるところから始められます。ただし本番投入の判断には、通常例・境界例・攻撃的な入力も含め、対象業務を代表する評価セットへ広げます。テンプレート化から評価の仕組みづくり、業務システムへの組み込みまでを社内だけで整えにくい場合は、一創の生成AI導入支援で、どこまでを自社で持つかの線引きから相談できます。

プロンプトエンジニアリングの資格と学習の順序

国内の生成AI試験とベンダー認定でプロンプトが問われる範囲

プロンプトエンジニアリングだけを対象にした国家資格は、2026年10月時点でありません。関連資格には、生成AI全般のリテラシーを測る民間試験、クラウドベンダー認定、プロンプトの設計・評価・応用を扱うPrompt Engineering Professional（PEP）検定などがあります。出題範囲と学習目的を照合して選びます。

名前にプロンプトを掲げるのは、日本プロンプトエンジニアリング協会のPEP検定です。全国のテストセンターでCBT方式により随時受験でき、合格基準は正答率70%以上。公式ページの例題はハルシネーション対策・RAG・コンテキストエンジニアリング・AIエージェント・著作権に及び、文面の書き方だけを問う試験ではありません。

生成AIパスポートはGUGAが運営する民間試験で、2026年は2・4・6・8・10月の年5回開催です。2026年8月試験の合格率は81.2%と公表されています。出題はリスクや法務まで含む広い範囲で、プロンプト設計の実技を測る試験ではありません。2,200円で受けられたJDLAのGenerative AI Testは、公式ページに掲載された最後の回が2025年6月7日で、「試験終了に伴い、次回試験の開催はございません」と案内されています。Google CloudやAWSの生成AIサービスの基礎知識を学ぶなら、Generative AI LeaderやAWS Certified AI Practitionerが候補になり、自社が使うクラウドに合わせて選ぶのが自然です。

資格では測れない実務の領域と、社内で先に整える仕組み

評価データセットを作って出力を数値で比べる力、RAGの検索設計、インジェクションを前提にした権限とログの設計は、どれも筆記試験の形になじみません。採用や配置の判断では、資格の有無より「手元の業務で評価データを作って改善した記録があるか」を見るほうが実態に合います。社内では、うまくいったプロンプトをテンプレート置き場に集め、失敗した入力を評価データへ足していく仕組みを先に回します。Googleが提供するプロンプト講座の中身はGoogle Prompting Essentialsの料金と難易度で、社内研修の組み立て方は生成AI研修の設計と外部委託の判断軸で扱っています。

よくある質問

プロンプトエンジニアリングはオワコンですか？

言い回しを磨くだけの役割は縮んでいますが、技術としては残っています。OpenAIは推論モデルへの指示を簡潔かつ直接的にするよう推奨しています。また、Claude APIでは2026-10-21版から temperature が削除されました。一方で、何をコンテキストに載せるか、出力形式をどう固定するか、評価データで変更をどう検証するかという設計は、モデルが新しくなっても不要になりません。対象が文面からシステム全体の入力設計へ広がった、と捉えるのが実態に近いでしょう。

プロンプトエンジニアにはどうすればなれますか？

決まった資格や経路はありません。業務システムの実装を目指すなら、LLMのAPI連携、評価データによる改善、RAGやエージェントの設計を学び、担当した範囲と成果を記録しておくと経験を説明できます。まず手元の業務で1つの処理をテンプレート化し、評価データで改善前後を比べた記録を作るのが近道です。

プロンプトエンジニアリングの検定（PEP検定）の難易度は？

合格率は、2026年10月28日時点でPEP検定の公式ページに載っていません。判断材料になるのは形式で、60分で100問（1問あたり36秒）、合格基準は正答率70%以上です。生成AIを業務で使っている人を対象にしており、ChatGPTなどの利用経験があれば、シラバスと練習問題で出題の範囲をつかんでから受けるのが順当です。

知識生成プロンプティングとChain-of-Thoughtはどう違いますか？

先に出させるものが違います。CoTは推論の過程、知識生成プロンプティングは回答の材料になる知識を出させます。計算や多段の論理にはCoT、前提知識の取り違えが心配な質問には知識生成が向きます。推論モデルではCoTの指示が不要とされる一方、知識の書き出しは人が点検できる中間結果として役割が残ります。

プロンプトチェーンにすると処理は遅く、高くなりませんか？

増える傾向はありますが、必ず遅く、高くなるとは限りません。4段を各1回ずつ実行すればAPI呼び出しは4回になります。待ち時間と課金トークンの増減は、各段の入出力長、モデル、再試行の有無によって変わります。判断の基準は、失敗したときの手戻りです。出力を人が読んで終わる用途なら1本で十分ですが、後工程のプログラムが結果を使う用途では、段ごとの検証で減らせる手戻り費用が、追加の推論・実装・運用費用を上回る場合に採用します。

関連記事

• プロンプトとは？生成AIへの指示文の意味と書き方・回答精度を上げる設計手法を解説
• Chain of Thoughtとは？CoTプロンプトの書き方・推論モデルでの扱いと限界を実装目線で解説【2026年版】
• プロンプトチェイニングとは？段の切り方とゲート設計・採用判断を実装目線で解説【2026年版】
• コンテキストエンジニアリングとは？プロンプトエンジニアリングとの違いと4つの実装手法
• ファインチューニングとは？LLMの追加学習の仕組み・RAGとの違いと使い分けを解説