プロンプトエンジニアリングとはAIから望む答えを得るため、指示文（プロンプト）を設計して直していく技術。特別なツールは要らず、技法はZero-shot・Few-shot・CoTなど【2026年10月版】

2026年10月8日・日本時間時点の情報です。 プロンプトエンジニアリング（prompt engineering）とは、ChatGPT・Gemini・Claudeなどの生成AIから望む答えを得るために、AIに渡す指示文（プロンプト）を設計し、試しながら直していく技術のことです。総務省の初心者向け教材、Google CloudとAWSの日本語ページ、OpenAIの開発者向けガイドは、どれもこの意味で説明しています。コードを書く必要も専用のツールも要らず、チャット画面の入力欄に打つ文章の書き方がそのまま対象です。

「ChatGPTに聞いてもうまく答えが返ってこない」と感じたとき、モデルを替える前に見直せるのが指示の出し方です。本記事では、公式の定義を原文で示したうえで、主要な書き方の技法（Zero-shot・Few-shot・Chain-of-Thought）を、各社の公式ガイドが何と書いているかとあわせて整理します。「プロンプトそのものの意味」と「初心者向けの書き方の基本5つ」は別の記事に書いたので、そちらに送ります（プロンプトとは──意味と書き方）。

3行まとめ

1. プロンプトエンジニアリングは「AI モデル（特に LLM）が望ましい回答を生成するようにプロンプトを設計、最適化するための技術」（Google Cloud日本語ページ・2026年5月4日更新）。総務省の初心者向け教材は「生成AIから最適な回答を得るための指示（プロンプト）の工夫」と説明し、OpenAIは「モデルへの効果的な指示を書くプロセス」と定義する。
2. 技法の中心は、例を見せるFew-shot、段階的に考えさせるChain-of-Thought（CoT）など。Anthropicのガイドは例を「3〜5個」と書き、Googleのガイドは「常に少数ショットの例を含める」ことを勧める。一方、Microsoftの解説はCoTが「非推論モデルにのみ適用」と明記しており、モデルの種類で使う技法が変わる。
3. 論文The Prompt Report（2024年発表）の小さな比較では、gpt-3.5-turboの正答率がZero-shot 62.7%、Few-shot 65.2%、Few-shot＋CoT 69.2%。旧版にあった「Few-shotで約23%向上」は出典で確認できず、2026年8月27日に削除した。

公式はプロンプトエンジニアリングをどう定義しているか

2026年10月8日の5時14分（総務省の教材は5時29分）に、公式のページを取得して原文を確かめました。表現は違っても、中心は指示文を設計して望ましい出力に近づけることです（筆者の要約）。

日本の公的機関では、総務省が国民向けの教材「生成AIはじめの一歩〜生成AIの入門的な使い方と注意点〜」（ver1.0のPDF）の22枚目で、「生成AIへの指示入力には工夫が必要」という見出しの下に次のように書いています。

生成AIから最適な回答を得るための指示（プロンプト）の工夫を "プロンプトエンジニアリング" と呼ぶ

同じ枚には、工夫として「目的・詳細な設定・検討の材料を書く」「欲しい回答の例を与える」「書式/回答方法を制限する」「文章のテイストを指定する」の4つが、例文つきで並んでいます。

Google Cloudの日本語ページ「プロンプト エンジニアリング: 概要とガイド」（最終更新日時は2026年5月4日と表示）は、次のように書いています。

プロンプト エンジニアリングとは、AI モデル（特に LLM）が望ましい回答を生成するようにプロンプトを設計、最適化するための技術であり、科学的な手法です。

AWSの日本語ページ「プロンプトエンジニアリングとは何ですか?」は、次のとおりです。

プロンプトエンジニアリングとは、ジェネレーティブ人工知能（Generative AI）ソリューションが望ましいアウトプットを生成するように導くプロセスです。

OpenAIの開発者向けガイド「Prompt engineering」の定義は次の一文です。

Prompt engineering is the process of writing effective instructions for a model, such that it consistently generates content that meets your requirements.

（訳：プロンプトエンジニアリングとは、モデルが要件を満たす内容を安定して生成するように、モデルへの効果的な指示を書くプロセス。）

Google AI for Developersの日本語ページ「プロンプト設計戦略」は、「プロンプト設計」を次のように定義し、プロンプトエンジニアリングについて注記を付けています。

プロンプト設計とは、言語モデルから正確で高品質なレスポンスを引き出すプロンプト（自然言語のリクエスト）を作成するプロセスです。

注: プロンプト エンジニアリングは反復的なプロセスです。

辞書も確かめました。Cambridge Dictionaryは prompt engineering を名詞（computing・specialized）として載せています。

the process of designing prompts (= instructions given to an artificial intelligence by a human using natural language rather than computer language) that will give the best possible results or answers

（訳：最良の結果や答えを出させるプロンプト（＝人間が、コンピューター言語ではなく自然言語で人工知能に与える指示）を設計するプロセス。）

6つの定義を並べると、次のとおりです（比較は筆者の整理です）。

「プロンプト」と「プロンプトエンジニアリング」は何が違うか

プロンプトは、AIに渡す指示や質問そのものです。プロンプトエンジニアリングは、そのプロンプトを設計し、結果を見て直していく作業と、その技法の総称です。AWSの日本語ページも、プロンプトを「生成 AI に特定のタスクを実行するように要求する自然言語のテキスト」と書いたうえで、「プロンプトエンジニアリングでは、AI システムから望ましい結果が得られるまで、プロンプトを継続的に調整します」と続けています。

プロンプトの意味、英語の prompt の語義、公式3社に共通する書き方の基本5つ（明確・具体的に書く／例を見せる／背景を渡す／してほしいことを書く／直しながら使う）はプロンプトとは──意味と書き方に書きました。本記事は、その先の「技法の名前と使い分け」を扱います。

「プロンプトエンジニアリングはもう要らない」という議論については、OpenAIとAnthropicの公式ガイドの更新状況を確かめたプロンプトエンジニアリングはオワコンなのかを参照してください。

「エンジニアリング」とついても、プログラミングは必要か

必須ではありません。上のCambridge Dictionaryの定義は、プロンプトを「コンピューター言語ではなく自然言語で」AIに与える指示と説明しています。入力欄に打つ文章の書き方が対象で、コードを書く場面（APIを呼ぶアプリを作る場合など）とは別に、チャットだけでも成り立ちます。

「エンジニアリング」という語が付く理由として、AWSの日本語ページは、プロンプトエンジニアが「入力テキストのコレクション」を作り、アプリケーションの生成AIが想定どおりに動くようにする、と書いています。つまり、1回の質問の書き方だけでなく、繰り返し使うプロンプトを整える仕事も含みます。

「エンジニアリング」と付いていても、各社の説明には「芸術（art）」という語が出てきます。OpenAIは「a mix of art and science」（訳：芸術と科学の混合）と書き、Google Cloudも英語版では「the art and science」（日本語版では「技術であり、科学的な手法」）と書きます。Microsoft Learnの日本語ページは「多くの場合、成功したプロンプトを作成するために経験と直感を必要とする科学よりも芸術です」と書いています。どれも、試して直す前提の書き方です（筆者の読み）。

職業としての「プロンプトエンジニア」と採用の実態は「年収3000万円」のプロンプトエンジニアは今どこにいるのかに、日本の検定はPEP検定の中身にあります。

始めるのに何が要るか

当サイトのChatGPTの使い方・Geminiアプリの使い方・Claudeの使い方（いずれも2026年10月8日時点の情報）によると、3つとも無料で使えるプランがあります。始め方もそれぞれの記事にあります。本記事は料金を取り直していません。プロンプトの書き方は、どのサービスでも同じ入力欄で試せます。

主要技法の体系──4系統の整理

ここからは、プロンプトエンジニアリングで使われる技法です。名前は英語のまま広まっているので、英語表記で書きます。

Zero-shot（ゼロショット）──例示なしで指示する

最も基本的なアプローチ。タスクの説明だけを与え、例示を提供しない。Google Cloudの日本語ページも、ゼロショットを「コンテキストや例を追加することなく、モデルに直接指示や質問をします」と説明しています。

次の文章を3行で要約してください。

[文章本文]

適した用途：タスクが明確で単純なとき、モデルが事前学習で十分な知識を持っているとき。

注意点：曖昧な指示はそのまま曖昧な出力につながる。「要約して」より「200字以内で、主要な3点を箇条書きで要約して」のように具体的な制約を加えると出力がコントロールしやすくなる。

---

Few-shot（フューショット）──例示で精度を上げる

タスクの入出力の例を複数提示してから、本番の入力を渡す技法。公式ガイドの書き方は、少しずつ違います。

• Anthropicのプロンプトガイドは「A few well-crafted examples (known as few-shot or multishot prompting) improve accuracy and consistency.」（訳：よく作られた少数の例は、Few-shot／マルチショットと呼ばれ、精度と一貫性を高める）と書き、「Include 3–5 examples for best results.」（訳：最良の結果には3〜5個の例を入れる）と続けます。例は「Relevant」「Diverse」「Structured」（訳：実際の用途に近い・多様・構造化）にするよう勧めています。
• Google AI for Developersの日本語ページは「プロンプトには、常に少数ショットの例を含めることをおすすめします。少数ショットの例のないプロンプトは、効果的でない可能性があります。」と書く一方、「過剰に多くの例を追加すると、モデルが例に対するレスポンスを過学習し始める可能性があります」とも書いています。
• OpenAIの開発者向けガイドは、Few-shotを「a handful of input/output examples」（訳：数個の入出力の例）をプロンプトに入れる方法と説明し、「try to show a diverse range of possible inputs with the desired outputs」（訳：望む出力とともに、多様な入力を見せる）と書いています。

数の目安は、Pasquale Pillitteri氏のガイド（二次情報）のFAQにもあり、たいていは2〜5例で、3〜5例を超えると効果の伸びは急に鈍る、としています。Anthropicの「3〜5個」と近い数字ですが、Googleは数を示さず「プロンプトに与える例の数についてテストすることが必要な場合があります」と書いており、数は決まった値ではありません。

タスク：顧客レビューをポジティブ/ネガティブ/中立に分類する

例1：
入力：「配送が早くて助かりました」
出力：ポジティブ

例2：
入力：「商品は普通でした、特に不満もありません」
出力：中立

例3：
入力：「梱包が雑で商品が破損していました」
出力：ネガティブ

本番：
入力：「思ったより小さかったですが、品質は良いと思います」
出力：

論文の数字：The Prompt Report（arXiv 2406.06608・2024年発表、2025年2月改訂）は、gpt-3.5-turboに4択の問題集MMLUから選んだ2,800問を解かせる比較を載せています（Figure 6.1）。正答率はZero-shot 62.7%、Few-shot 65.2%、Few-shot CoT 69.2%で、例を見せた方が高く出ました。著者らはこれを「small study」（小さな研究）と書いており、1つのモデル・1つの試験での値です（旧版の「約23%向上」は出典に無く削除済み。記事末尾の「更新・訂正履歴」）。自分のタスクでも、例の有無で出力を比べてください。

例示の設計ポイント：

• 例はできるだけ多様に（同じパターンの例を複数並べても効果は薄い）
• エッジケース（判断が難しいケース）を含める
• 出力フォーマットを統一する（Googleの日本語ページも「すべてのサンプルで形式を統一することが重要」と書く）

---

Chain-of-Thought（CoT・チェーン・オブ・ソート）──思考過程を明示させる

モデルに段階的な推論プロセスを出力させる技法。IBMのCoT解説は「Chain of thought (CoT) is a prompt engineering technique that enhances the output of large language models (LLMs), particularly for complex tasks involving multistep reasoning.」（訳：CoTは、特に複数段階の推論を伴う複雑なタスクで、大規模言語モデルの出力を高めるプロンプトエンジニアリングの技法）と書いています。同じ解説は、使える場面として算数の文章題・常識的な推論・記号や論理の推論などを挙げています。

シンプルなCoTトリガー：

以下の問題を、ステップごとに考えながら解いてください。

問題：[問題文]

Google Cloudの日本語ページは、このように推論ステップを実行するよう指示する形を「ゼロショット CoT プロンプト」と呼び、「多くの場合、より良い出力が得られます」と書いています。ただしThe Prompt Reportの比較（gpt-3.5-turbo）では、ゼロショットCoTの正答率はZero-shotより下がっていました（54.7%と62.7%）。

Few-shot CoT：CoTを例示と組み合わせる方法。例示の中で推論過程を明示することで、モデルが同じスタイルで推論するよう誘導する。

例：
問題：100円のりんごを3個と80円のみかんを2個買いました。合計はいくらですか？
解答過程：まず100円×3=300円。次に80円×2=160円。合計は300+160=460円。
答え：460円

本番：
問題：[本番の問題]
解答過程：

注意点：CoTは複雑なタスクほど効果的だが、単純なタスクでは冗長になる。「2+3は？」を「ステップごとに考えて」と問うと無駄に長い出力になる。

推論モデルでは扱いが変わる（今回確認した点）：最近のモデルは、答える前に内部で考える機能を持つものがあります。公式の書き方はそれぞれ次のとおりです。

• Microsoft Learnの日本語ページは、CoTの節の冒頭に「この手法は、非推論モデルにのみ適用されます。」と書き、続けて、推論概要パラメーター以外の方法でモデルの推論を引き出そうとすることはサポートされず、利用ポリシーに反する可能性があるとしています。
• Google AI for Developersの日本語ページは「Gemini 2.5 および 3 シリーズのモデルは、推論のパフォーマンスを向上させるために、内部の「思考」テキストを自動的に生成します。そのため、一般的に、モデルが返したレスポンス自体に、モデルの概要、計画、推論ステップの詳細を含める必要はありません。」と書き、難しい問題には「回答する前に十分に考える」などの簡単なリクエストでパフォーマンスを改善できるが、「その代償として思考トークンが追加で必要になります」としています。
• OpenAIの開発者向けガイドは「reasoning models will provide better results on tasks with only high-level guidance. This differs from GPT models, which benefit from very precise instructions.」（訳：推論モデルは、大まかな指針だけのタスクでより良い結果を出す。非常に正確な指示が役立つGPTモデルとは異なる）と書いています。

つまり「ステップごとに考えて」は、モデルの種類によって扱いが変わります。使っているモデルが推論モデルかどうかは、各サービスの公式の説明で確かめてください。

---

ロールベースプロンプト──役割付与で出力トーンを調整する

モデルに特定の役割（ペルソナ）を付与することで、出力のトーン・視点・専門性を誘導する技法（Pillitteri氏のガイドの型「RTF」＝Role・Task・Formatの最初の要素）。Anthropicのプロンプトガイドにも「Give Claude a role」（訳：Claudeに役割を与える）の項があり、システムプロンプトで役割を設定すると、Claudeの振る舞いとトーンが用途に合わせて絞り込まれ、一文だけでも違いが出る、と書かれています。

あなたは10年以上の経験を持つ中小企業向けの税理士です。
以下の質問に、専門家の視点から、初心者にも分かりやすく回答してください。

質問：フリーランスが経費として計上できるものは何ですか？

適した用途：文書作成、説明文、アドバイスなどトーンや専門性のコントロールが必要なとき。

注意点：ロールを付与しても、モデルが実際にその専門知識を持つわけではない。出力された専門情報は独立して検証すること。

---

メタプロンプティング──指示そのものを生成させる

ここでのメタプロンプティングは、モデルに「良いプロンプトを作らせる」使い方です。Anthropicの概要ページは、最初の下書きが無い場合に「Generate one with the metaprompt recipe from the Claude Cookbook.」（訳：Claude Cookbookのmetapromptのレシピで生成する）と案内しています。なお、K2Viewの解説は「Meta prompting」を、具体的な例の代わりに答えの手順や構造を抽象的に示す技法として説明しており、同じ名前でも指すものが違います。

[タスクの概要を説明]

このタスクを効果的に実行するための詳細なプロンプトを作成してください。

自分でプロンプトを設計するのが難しいとき、モデルに雛形を作らせて調整するのは実用的な出発点になる。

---

セルフコンシステンシー──複数経路で精度を上げる

1つのプロンプトに対して複数回実行し、最も多く出てきた答えを採用する技法。K2Viewの解説は「Self-consistency prompting」として、推論の道筋を複数作り、最も一貫した答えを選ぶ方法と説明しています。AWSの日本語ページも、思考の連鎖プロンプティングの説明の中で「いくつかの思考の連鎖のロールアウトを展開し、最も一般的に導き出される結論を選択できます」と書いています。The Prompt Reportの比較では、この方法で正答率が上がったのはゼロショットCoTのとき（54.7%→57.4%）で、Few-shot CoTでは69.2%と69.1%でほぼ変わりませんでした。

実用上の注意：複数回実行はAPI利用料が増加する。コストと精度のトレードオフを確認してから使う。

---

ハイブリッドプロンプティング──技法を組み合わせる

実務では単一技法より、複数を組み合わせて使う場面が多い。「ハイブリッドプロンプティング」という呼称自体はPillitteri氏のガイドの用語ではなく、本記事による整理だが、Pillitteri氏のガイドもRTF→CARE→CREATEのように要素を段階的に追加していく考え方や、CoTとFew-shotの併用を紹介している。

例：ロールベース＋Few-shot＋フォーマット指定＋CoT

あなたは経験豊富なUXライターです。

以下のルールで、ボタンのラベルを改善してください：
- 動詞で始める
- 15文字以内
- 何が起きるかを明確に示す

例1：
Before：「クリック」
After：「無料で試す」

例2：
Before：「送信」
After：「お問い合わせを送る」

本番：
Before：「次へ」
理由を一文で示してから、改善案を提案してください：
After：

ただし、組み合わせが複雑になるほど意図しない干渉が起きることもある。シンプルな指示で試してから要素を追加するのが現実的な進め方だ。

---

2026年のモデル変化と技法の使い方

Pillitteri氏の2026年のガイドは、FAQで「The 2026 models are more powerful, not more telepathic.」（訳：2026年のモデルは強力になったが、察しが良くなったわけではない）と書き、構造化したプロンプトのほうが明らかに良い出力を出すとしている。Anthropicのプロンプトエンジニアリング概要は、Prompting best practices のページを「That's the living reference; start there.」（訳：そこが生きた参照資料なので、そこから始める）と案内しており、そのページはモデルごとの違いを分けて載せています。以下の優先順位はこの前提を踏まえた、筆者の実務上の提案である。

2026年時点の現実的な優先順位（筆者の提案）：

1. まず明確で具体的な指示を書く（Zero-shot）。公式3社の最初の勧めは同じ「明確・具体的に書く」です。詳しくはプロンプトとは。
2. 出力の形が安定しなければFew-shotを追加。Googleは「常に」含めることを勧めるので、形式をそろえたいときは最初から入れてもよい。
3. 推論ミスが続くならCoTを試す。ただし単純なタスクや推論モデルでは効果が小さいことがある。
4. 複雑なタスクにはハイブリッド。それでも最小限の要素から始める。

プロンプトを直しても改善しない場合について、Anthropicの概要ページは、遅延やコストのように、別のモデルを選ぶほうが簡単に改善できる場合もあると書いています（原文はプロンプトエンジニアリングはオワコンなのかで引用）。

---

実践的なプロンプト設計チェックリスト

• タスクは明確か：何をして欲しいかを1文で言えるか
• 出力フォーマットを指定したか：箇条書き・表・文章のどれか
• 制約を加えたか：文字数・数・トーン・対象読者
• 文脈を渡したか：モデルが判断に必要な背景情報が揃っているか
• 例示は必要か：Zero-shotの出力を見てから判断する
• 推論を明示させるか：複雑なタスクならCoTトリガーを追加する（推論モデルでは不要なことがある）

Anthropicのガイドは、出来を測る目安として、前提をほとんど知らない同僚にプロンプトを見せ、同僚が迷うならClaudeも迷う、という「Golden rule」を挙げています（原文と訳はプロンプトとはに）。

公式ページを開いて分かったこと

筆者は2026年10月8日の5時15分に、Playwrightのヘッドレス（画面を出さない）ブラウザで、ログインせずに公式ページを開きました（画面サイズは1280×800と390×844）。

• Google Cloudのページはタブのタイトルが「AI のプロンプト エンジニアリング ガイド | Google Cloud」で、冒頭に「最終更新日時: 2026 年 5 月 4 日」と出ました。左の目次には「プロンプト エンジニアリングとは」「プロンプトの種類」「より効果的なプロンプトを作成するための戦略」が並び、画面下にCookie同意の帯が出ました。
• AWSの日本語ページは「プロンプトエンジニアリングとは何ですか?」で、定義の節に「プロンプトとは何ですか?」「プロンプトエンジニアリングが重要なのはなぜですか?」が続く構成でした。
• Google AI for Developersのページは、日本語表示で「プロンプト設計戦略」。本文の上に「Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。」という注記と「Switch to English」のボタンが出ました。本記事の引用はこの日本語表示の文で、引用した文は英語版（最終更新2026年9月17日 UTC）の原文と同じ意味であることを確かめています。

取得できなかったページと、確かめられていない点

• 日本の公的機関の説明は、総務省の教材から引きました。ほかの省庁や公的機関の資料までは、本記事は探し切れていません。
• OpenAIのヘルプセンター（help.openai.com）とMerriam-Websterは、2026年10月8日にcurlで取得すると403が返り、本文を取れませんでした。ヘルプセンターのプロンプトエンジニアリングの定義は、同日1時台にブラウザで取得したプロンプトとはで引用しています。
• 本記事が取得した各社の公式ガイドには、技法ごとの改善率の数字はありませんでした。載せた数字は、The Prompt Reportの1つのモデル（gpt-3.5-turbo）・1つの試験（MMLU）での値です。
• Few-shotの例の数（Anthropicは3〜5個、Googleは数を示さずテストを勧める）が、日本語でのやりとりでも同じかは、本記事では確かめていません。

技法の効果は、モデルと課題で変わる

どの技法も「使えば必ず良くなる」ものではなく、同じプロンプトでも、使うモデル・バージョン・温度設定（temperature）によって出力は変わる。モデルの入れ替わりも速いので、技法の名前を覚えるより、出力のどこがずれたかを特定し、直して試す習慣の方が長く役立つ、というのが筆者の考えだ。

文章づくりに使うAIツールの比較はAI文章作成ツール おすすめ比較にあります。最新のモデル別の書き方はClaude Opus 5.5公式プロンプトガイドとClaude Sonnet 5.5公式プロンプトガイドに、非エンジニア向けの設計の原則はプロンプト設計入門にあります。

引用した公式ページと取得時刻

• 定義（日本語）：総務省「生成AIはじめの一歩〜生成AIの入門的な使い方と注意点〜」（教材PDF ver1.0・5時29分取得）、Google Cloud「プロンプト エンジニアリング: 概要とガイド」、AWS「プロンプトエンジニアリングとは何ですか?」（いずれも2026年10月8日 5時14〜15分取得）
• 定義・Few-shot・推論モデル：OpenAI「Prompt engineering」（開発者向けガイド）、Google AI for Developers「プロンプト設計戦略」、Anthropic「Prompting best practices」「Prompt engineering overview」、Microsoft Learn（日本語）
• 辞書：Cambridge Dictionary「prompt engineering」
• CoTの定義：IBM Think。セルフコンシステンシーの説明：K2View（二次情報）。Few-shotの例数目安・RTF：Pasquale Pillitteri氏のガイド（二次情報）。手法別の正答率：The Prompt Report（arXiv 2406.06608）のFigure 6.1
• 本記事の情報は2026年10月8日時点のものであり、モデルの急速な進化により内容が変わる可能性がある