レッスン1：プロンプトエンジニアリングとは何か——「指示」から「設計」へ

このレッスンで学ぶこと

プロンプトエンジニアリングの定義と、入門レベルとの違いを理解する
LLM 動作の最低限の前提知識（次トークン予測、文脈窓、温度）を押さえる
2026 年 6 月時点の主要モデル（Claude Opus 4.7、GPT-5.5、Gemini 3.1 Pro）の位置づけを把握する
reasoning モデルと従来モデルの違いを区別できる
本コースの守備範囲と扱わない範囲を理解する

「プロンプトエンジニアリング」という言葉は、ChatGPT が登場した 2022 年末から急速に広まりました。SNS には「神プロンプト」「無敵テンプレ」が日々投稿され、書籍も大量に出版されています。一方、LLM を業務に組み込む現場では、まったく違う温度感の議論が進んでいます。本コースは、その実務の温度感に近い視点から、プロンプトエンジニアリングを「指示の作文」ではなく「評価とイテレーションを伴う設計」として体系化します。

プロンプトエンジニアリングの定義

プロンプトエンジニアリング（prompt engineering）は、LLM（大規模言語モデル）に与える入力（プロンプト）を設計・評価・改善することで、目的に合った出力を安定して得るための技術と運用の総称です。

ここで強調したいのは「設計・評価・改善」の 3 セットです。「うまく書く」だけではなく、評価セットを用意して結果を測り、エラーを分析して書き直す——というサイクルを回すことが、本コースが「実践」と呼ぶ核心です。

flowchart LR
  D[設計<br/>プロンプトを書く] --> E[評価<br/>結果を測る]
  E --> A[分析<br/>エラーの原因を分類]
  A --> D

💡 ポイント SNS で出回る「魔法のプロンプト」は、一発で動いた成功例だけが共有されがちです。実務では、同じプロンプトでも入力が変われば結果が変わり、モデルが更新されれば挙動が変わります。「一度書いて終わり」ではなく「測りながら磨き続ける」発想が、運用に耐えるプロンプトエンジニアリングです。

生成 AI 入門との接続

スキルアップカレッジには「生成 AI 入門」コースがあり、そこではプロンプトの 5 つの基本要素や Chain-of-Thought の入り口を扱っています。本コースは、その先の「実践」を扱います。具体的には、

入門：「プロンプトに何を書くか」（5 要素の紹介、Chain-of-Thought の入門）
本コース（実践）：「プロンプトをどう評価し、どう改善し続けるか」（評価セット、Self-Consistency、Reflexion、エージェント、運用）

の関係です。本コースは生成 AI 入門の受講を前提にはしません。基本の 5 要素はレッスン 2 で改めて整理しますし、Chain-of-Thought もレッスン 3 で再度扱います。ただし、ChatGPT・Claude・Gemini を 1 か月以上使った経験は前提です。

LLM 動作の最低限の前提知識

プロンプトエンジニアリングを「設計」として扱うために、LLM の動作を最低限理解しておく必要があります。深い技術詳細には立ち入らず、必要な範囲だけを押さえます。

①次トークン予測

LLM は、入力文の続きとして「最も確からしいトークン（単語の単位）」を、確率に基づいて 1 つずつ生成していきます。つまり、出力は「正解を検索した結果」ではなく「学習データの分布に基づく確率的な続き」です。同じプロンプトでも、毎回まったく同じ出力になるとは限らないのは、このためです。

②文脈窓（context window）

LLM が一度に「見える」入力＋出力の最大トークン数を、文脈窓と呼びます。2026 年 6 月時点では、主要モデルの多くが 100 万トークン以上の文脈窓を持つようになっています。文脈窓に収まりさえすれば長い文書も扱えますが、「収まる＝うまく使える」とは限らない点に注意が必要です。後のレッスンで触れます。

③温度（temperature）と top-p

LLM の出力には「ランダム性」を制御するパラメータがあります。代表が「温度」（0〜1 程度、モデルによっては 2 まで）と top-p（核サンプリング）です。

温度を下げる（0 に近づける）→ 出力が決定的（同じ入力なら毎回ほぼ同じ）
温度を上げる → 出力が多様（創造的だが不安定）

要約や抽出など決定性が欲しいタスクでは低温度、ブレインストーミングや創作では高温度、というのが一般的な使い分けです。

📝 補足 「温度を 0 にすれば毎回同じ結果になる」と説明されることが多いですが、実際は完全に同じにはなりません。同点候補の処理、内部の並列計算、モデル更新などの要因で、わずかにブレが残ります。「ほぼ決定的だが、保証はされない」と理解するのが正確です。

2026 年 6 月時点の主要モデル

2026 年 6 月時点で、主要な LLM ベンダーは次のラインナップを展開しています。本コースは特定ベンダーに偏らず、共通する考え方を中心に扱いますが、現時点のラインナップは前提として押さえておきます。

Anthropic（Claude シリーズ）

Claude Opus 4.7：最上位の汎用モデル。深い推論と長文処理に強い
Claude Sonnet 4.6：中位の汎用モデル。速度とコストのバランス
Claude Haiku 4.5：軽量モデル。低レイテンシ・低コスト
Claude Fable 5：物語・対話に特化したシリーズ

OpenAI

GPT-5.5：汎用フラッグシップ。マルチモーダル・推論・コーディングに対応
o シリーズ系統：reasoning に特化したモデル群

Google

Gemini 3.1 Pro：マルチモーダルと長文文脈窓に強い
Gemini Flash：軽量・高速版

モデル選択の基本発想

速度とコスト優先：Haiku／Flash 系の軽量モデル
バランス：Sonnet／Gemini Pro 系の中位モデル
難しいタスク・長文：Opus／GPT-5.5 のフラッグシップ
深い推論：reasoning モデル（後述）

⚠️ 注意 モデルのラインナップは数か月単位で大きく変わります。本コースの内容は 2026 年 6 月時点のものです。読み返したときに「いつの時点の情報か」を意識し、必要に応じて最新版を確認する習慣を持ってください。

reasoning モデルと従来モデル

2024 年後半から、「reasoning モデル」と呼ばれる新しいタイプのモデルが主流になってきました。OpenAI の o シリーズ、Anthropic の「Extended Thinking」モード、Google の Gemini Thinking モードなどが該当します。

従来モデル

入力に対して、即座にトークン列を生成し始めます。「考える時間」を意図的に取ることは、プロンプト側で「step by step で考えてください」のように促す必要がありました。

reasoning モデル

入力を受け取ったあと、内部で「思考プロセス」を実行してから最終出力を返します。この内部思考は通常ユーザーには見えませんが（一部のモデルは表示する）、深い推論を要する問題で従来モデルを大きく上回る精度を出します。

プロンプトエンジニアリングへの含意

reasoning モデルの登場で、プロンプト戦略は次のように変わってきています。

Chain-of-Thought（CoT）の必要性が下がる：reasoning モデルは内部で勝手に考えるため、外側から「step by step」を強制する効果が薄い
構造化と評価の重要性が上がる：複雑な推論に対しても安定した出力を得るには、出力形式の設計と評価が必要
コストと速度のトレードオフ：reasoning モデルは内部思考にトークンを消費するため、コストとレイテンシが上がる。速度優先のタスクには従来モデルが適する

💡 ポイント 「reasoning モデルが出てきたから、プロンプトエンジニアリングは終わった」という議論をよく見かけますが、実務では逆です。モデルが賢くなったからこそ「何をどこまで任せ、どう検証するか」の設計と運用が重要になっています。本コースの中核メッセージはここにあります。

「魔法のプロンプト」と「無敵テンプレ」への向き合い方

SNS で出回る「すごく動いた魔法のプロンプト」は、本コースでは批判的に扱います。理由は 3 つあります。

①再現性の欠如

「自分の入力で動いた」事例は、入力が変わるだけで結果が大きく変わります。評価セットで複数の入力を試して初めて、安定性が確かめられます。

②モデル更新による陳腐化

モデルが更新されると、同じプロンプトでも挙動が変わります。SNS で評判の「神プロンプト」が、半年後にはまったく機能しないことは珍しくありません。

③タスク特化の盲点

「あらゆるタスクで使える万能プロンプト」は、ありません。要約・抽出・対話・コーディングなど、タスクごとに最適なプロンプトの形は違います。

⚠️ 注意 「魔法のプロンプト」を完全に否定する必要はありません。他人の試した工夫を参考にするのは有効です。ただし、自分のタスクで動くかは別問題で、必ず自分の評価セットで試してから採用する、という運用が大切です。

本コースの守備範囲

最後に、本コースで扱う範囲と扱わない範囲を整理しておきます。

扱う範囲

プロンプトエンジニアリングの全体像と「設計」の発想（本レッスン）
プロンプトの 5 要素フレームワーク（レッスン 2）
Few-shot と Chain-of-Thought（レッスン 3）
出力制御・JSON Schema・XML タグ（レッスン 4）
評価セットとイテレーション設計（レッスン 5）
高度な推論パターン：Self-Consistency／Tree of Thoughts／Reflexion／Self-Refine（レッスン 6）
ツール使用と AI エージェント：Function Calling・ReAct・MCP（レッスン 7）
RAG・プロンプトインジェクション対策・バージョン管理（レッスン 8）

扱わない範囲

特定 LLM API の細かい仕様・料金体系（公式ドキュメントを参照）
LLM の内部実装・トランスフォーマーの数式（別の専門書を参照）
コード例による実装（本コースは「考え方の設計」に絞る。API 呼び出しのコードは登場しない）
「神プロンプト集」「業務別テンプレ集」（自分のタスクで評価する発想を優先）

スタンス

本コースは、プロンプトエンジニアリングを「魔法の話法」ではなく「評価とイテレーションを伴う設計の運用」として扱います。「reasoning モデルで不要になる」議論も「魔法のプロンプトで万事解決」議論も、両方を批判的に整理した上で、自分のタスクで継続的に磨き続ける発想を中心に置きます。

講師の現場メモ：「神プロンプトを買った経営者」

私（西脇）が独立後にコンサルティングを担当した、ある中堅 SaaS 企業の話です。経営陣から「業界で話題の『神プロンプト集』を 30 万円で購入したから、これで社内 AI 機能を作ってほしい」と依頼を受けました。

私は購入された資料を見せてもらいました。確かに、丁寧に整理されたテンプレート集でした。役割設定、出力フォーマット、Few-shot 例、ガードレールの指示——50 種類以上の業務別プロンプトが、おしゃれな PDF にまとめられていました。

経営陣は満足げで、「これを使えば、明日から AI 機能が動くはずだ」と。

私はその場で、いくつか質問させていただきました。「自社のカスタマーサポートの実データで、これらのテンプレートを試した結果はありますか？」「自社の顧客が使う日本語の癖や、業界用語に対する精度は測っていますか？」「ハルシネーションが起きたときの検出と訂正の仕組みは、どう設計されていますか？」

経営陣の答えは、すべて「いいえ」でした。

私たちは、購入したテンプレート集を一旦脇に置き、自社のカスタマーサポートの実データから、評価セット（50 件の代表的な問い合わせ）を作るところから始めました。次に、テンプレート集の 3 つのプロンプトと、自社で素朴に書いたプロンプト 2 つを、評価セットで比較。すると、自社で素朴に書いたプロンプトの方が、テンプレート集より正答率で上回るケースがあったのです。

理由は、自社の業界用語と顧客の文体への適合性でした。「神プロンプト」は一般的なベストプラクティスとして優れていましたが、自社の文脈には合っていなかった。

このときに改めて感じたのが、プロンプトエンジニアリングは「他人の成功例の収集」ではなく「自分のタスクでの測定とイテレーション」の積み重ねだということです。本コースで評価とイテレーションに多くのページを割くのは、この実感が背景にあります。

まとめ

このレッスンでは、以下のことを学びました。

プロンプトエンジニアリングは「設計・評価・改善」の 3 セットで成り立つ運用技術
LLM の動作前提：次トークン予測、文脈窓、温度と top-p の制御
2026 年 6 月時点の主要モデル：Claude Opus 4.7／Sonnet 4.6／Haiku 4.5、GPT-5.5、Gemini 3.1 Pro
reasoning モデル（o シリーズ、Claude Extended Thinking、Gemini Thinking）は内部で思考を行うため、Chain-of-Thought の外側からの強制が不要になる
「魔法のプロンプト」「無敵テンプレ」への批判：再現性の欠如、モデル更新による陳腐化、タスク特化の盲点
本コースは「評価とイテレーションを伴う設計の運用」を中心に置く

次のレッスンでは、プロンプトの基本骨格として、システムプロンプトとユーザープロンプトの区別、5 要素のフレームワーク（役割・指示・文脈・例・出力形式）、persona 設定の効用と落とし穴を学びます。

確認クイズ

このレッスンの理解度をチェックしましょう。