プロンプト
エンジニアリング
日本語による完全ガイド — 入門から応用まで。フレームワーク、実践パターン、よくある失敗。
2026年版 — ChatGPT 5、Claude 4、Gemini 2.0に対応。不要な専門用語なし。
プロンプトエンジニアリングとは?
プロンプトエンジニアリングとは、大規模言語モデル(LLM)への指示を、出力が予測可能・具体的・有用になるよう設計する技術です。魔法ではなく、適切に適用すれば使える回答に到達するまでの反復時間を60〜80%削減できる一連の規約です。
2026年において、このスキルはキャリア上の差別化要因から、テキスト・コード・意思決定にAIを使うすべての人にとっての前提になりました。良いニュース: コアとなる規律は小さい。悪いニュース: 平均的なプロンプトと優れたプロンプトの差は、出力品質に直撃します。
このガイドは、必ず知るべきフレームワーク、日本語で実際に動くパターン、大多数が犯す失敗、実践例を網羅します。理論的なコースではなく、現場のマニュアルです。
Part 1
押さえるべき6つのフレームワーク。
RGC — Role, Goal, Context
最も汎用的なフレームワーク。Roleでペルソナを与え、Goalで出力を定義し、Contextで素材(読者、トーン、制約、サンプル)を与える。どのLLMでもどのタスクでも動作します。
いつ使うか: 全タスクの80%に使える標準 — 執筆、分析、ブレスト、要約。
RTF — Role, Task, Format
RGCのミニマル版。余計な文脈が不要な単純なケース向け — 誰が、何をし、どう提示するか、だけを指定。
いつ使うか: 短い依頼や明確に定義されたタスク。トークン数とオーバーヘッドを削減。
CRISPE — Capacity, Role, Insight, Statement, Personality, Experiment
RGCより冗長。まずモデルが使うケイパビリティ・視点を宣言させ、次に回答、次に実験的なバリエーションを出させる。
いつ使うか: 複数バリエーションと推論の透明性が欲しいクリエイティブタスク。
Chain-of-Thought(CoT)
モデルに「段階的に考える」ことを強制。暗黙(「段階的に考えてください」)でも明示的(<推論>と<回答>セクション)でも実装可能。
いつ使うか: 数学、複数要因の意思決定、根本原因分析 — 中間推論が重要な場面すべて。
Few-shot prompting
実際の依頼の前に2〜5個の入力-出力例を含める。モデルは説明ではなく例からパターンを「学ぶ」。
いつ使うか: スタイルが説明より例示で伝わる場合。データの構造化抽出、分類、トーン標準化。
Self-consistency
同じプロンプトを高温度で複数回実行し、最も頻出する回答を選ぶ。検証可能な単一解を持つタスクで精度向上。
いつ使うか: 数学、論理、事実抽出など「正解」があるタスク。
Part 2
よくある6つの失敗(と修正方法)。
役割が抽象的すぎる
悪い例
あなたはアシスタントです。
良い例
あなたは解約削減に8年の経験を持つB2B SaaSのシニアグロースアナリストです。
なぜ: 具体的な役割はモデルを具体的な知識体系に錨付けします。「アシスタント」はデフォルトモード — 汎用的で無難なものに引き戻します。
目的が曖昧
悪い例
マーケティングについて何か書いて。
良い例
Notionのメールオンボーディングフローについて600字で分析し、3つの摩擦点を特定し代替案を提案してください。
なぜ: 目的が曖昧 = 出力が曖昧。字数、対象、制約、期待する結論を具体的に指定してください。
文脈が不足
悪い例
提案をください。
良い例
文脈: B2B SaaS、平均単価年間120万円、年間解約率18%。初年度解約を減らす提案を5つ、同規模企業のプレイブックを参考に提示してください。
なぜ: モデルはテレパシーを持ちません。データ、目標、制約、「良い」とみなすものの例を貼り付けてください。
基準なしにレビューを依頼
悪い例
このテキストをレビューしてください。
良い例
このテキストを次の観点でレビュー: (a) 段落ごとの明快さ、(b) 強い動詞、(c)「基本的に」「本質的に」「現代では」のような冗長語の除去。
なぜ: 基準のないレビューは汎用的なフィードバックを返します。具体的なチェックリストを与えてください。
1つのメッセージで詰め込みすぎ
悪い例
事業計画を書いて、サイトをデザインして、ピッチデックも作って。
良い例
まず事業計画を500字で書いてください。次にサイトに進みます。
なぜ: モデルは一度に1タスクの方が処理精度が高い。分解することで幻覚を減らし、各ステップの品質を上げます。
出力形式を無視
悪い例
ネーミングの候補をください。
良い例
ネーミング候補を10個、次のカラムを持つMarkdownテーブルで: 名前、語源、.comドメイン空き(あり/なし)、理由。
なぜ: 形式の明示は往復を1回減らします。自分が消費するデータ構造を正確に指定してください。
よくある質問
プロンプトエンジニアリングについて。
プロンプトエンジニアリングとは何ですか?+
大規模言語モデル(LLM)に対して、予測可能で有用な出力を生み出すように十分に構造化された指示を書く技術です。ファインチューニングや再学習は不要で、入力の設計だけでモデルの挙動を目的に沿わせることができます。
2026年でも独立した職種として存在しますか?+
「プロンプトエンジニア」という専任ポジションはほとんどの企業で消えつつあります。代わりに、このスキルは開発者、プロダクトマネージャー、アナリスト、ライターに吸収されました。2026年時点では、AIを業務で扱うすべての人にとって前提スキルです。
よく使われるフレームワークは何ですか?+
RGC(Role-Goal-Context)、RTF(Role-Task-Format)、CRISPE、CoT(Chain-of-Thought)が主要です。RGCはほとんどのケースで汎用的に使えます。CoTは分析的タスクや数学的タスクで重要です。
プロンプトエンジニアリングに英語は必要ですか?+
いいえ。モダンなモデル(GPT-4o、Claude 4、Gemini 2.0)は日本語でも完璧に動作します。英語の唯一の利点は、ベンチマークや論文へのアクセスが早いことですが、技術自体は同じです。
プロンプトエンジニアリングとファインチューニングの違いは?+
プロンプトエンジニアリングは入力を操作します。ファインチューニングはモデルの重みを操作します。95%の企業ユースケースではプロンプトエンジニアリングで十分 — 速く、安く、MLエンジニアを必要としません。
Chain-of-Thoughtは常に効果的ですか?+
分析、数学、複数ステップの意思決定ではほぼ常に効果的です。ただし、クリエイティブタスクやブレインストーミングでは出力を慎重にしすぎて逆効果になる場合があります。原則: 分析タスクにはCoT、クリエイティブタスクには不要。
プロンプトの品質をどう評価しますか?+
3つの基準: (1) 再現性 — 同じプロンプトで5回実行して似た出力が得られるか。(2) 具体性 — 脱線せずに求められたことに答えているか。(3) 密度 — 単語あたりの有用情報量は十分か。良いプロンプトは3つすべてで高得点を取ります。
なぜ私のプロンプトが時間とともに「効かなく」なるのですか?+
3つの典型的原因: (1) モデル更新で挙動が変わる — 特定のクセに依存していたプロンプトが壊れる。(2) 過去の最良出力と無意識に比較している(平均ではなく)。(3) コンテキストドリフト: 長い会話でモデルが初期の指示を「忘れる」。対策: 重要な指示はプロンプトの冒頭と末尾の両方に配置する。