プロンプトエンジニアリング
LLM から狙った出力を引き出すための“指示の設計”。明確な指示・役割・例示・段階的に考えさせる工夫で、同じモデルでも結果が大きく変わる。
- 1.プロンプトエンジニアリングは、LLM への入力（指示・文脈・例）を設計して、狙った出力を安定して引き出す技術。モデルを再学習せずに精度を上げられる。
- 2.効く順の定番：①明確な指示と出力形式の指定 ②役割と文脈の付与 ③Few-shot（お手本の例示）④Chain-of-Thought（段階的に考えさせる）。
- 3.LLM は“もっともらしい続き”を生成する仕組みなので、曖昧な指示ほどブレる。プロンプトを工夫してもハルシネーション（もっともらしい嘘）はゼロにならない。
なぜ“聞き方”でこんなに変わる？
LLM は質問に「答えを検索」しているのではなく、与えられた文章のもっともらしい続きを単語ごとに生成しています（仕組みは /ai/llm-transformer/ を参照）。つまり、入力した文章が出力の方向を決めるということです。
だから曖昧な入力は曖昧な出力を、具体的な入力は具体的な出力を引き出します。「いい感じにまとめて」ではモデルが“いい感じ”を推測するしかありませんが、「3行の箇条書きで、専門用語を使わず、結論から」と言えば、続きとして自然なのはその形だけになります。ファインチューニングのように再学習せず、入力だけで精度を底上げできるのが大きな利点です。
基本の4つの型
プロンプトの工夫は、ざっくり次の4段階で考えると整理しやすいです。下にいくほど手間がかかりますが、効果も大きくなります。
| 手法 | やること | 向いている場面 |
|---|---|---|
| 明確な指示 | タスク・制約・出力形式を具体的に書く | ほぼ全ての場面（まず最初にやる） |
| 役割の付与 | 「あなたは〇〇の専門家」と立場を与える | 口調・観点・専門性をそろえたいとき |
| Few-shot（例示） | 入力と理想の出力の“お手本”を数個見せる | 形式や分類の基準を言葉で説明しにくいとき |
| Chain-of-Thought | 「順を追って考えて」と途中の思考を出させる | 計算・推論・多段の判断が要るとき |
1. 明確な指示と出力形式
最も効果が高く、まず手をつけるべきところです。何を・どんな制約で・どんな形式で出すかを具体的に書きます。
悪い例:
このログを分析して。
良い例:
以下のアクセスログから、ステータスコードが500の行だけを抽出し、
「時刻 / URL / エラー内容」の3列のMarkdownテーブルでまとめてください。
該当が無ければ「該当なし」とだけ答えてください。
出力形式（JSON・表・箇条書き・文字数）まで指定すると、後続のプログラムで扱いやすく、ブレも減ります。
2. 役割（ロール）と文脈の付与
「あなたはセキュリティの専門家です」のように立場を与えると、語彙や観点がその役割に寄ります。あわせて前提・背景・読者を渡すと精度が上がります。
あなたは新人エンジニア向けの技術ライターです。
読者はGitを使い始めたばかりの初心者です。
専門用語には必ず一言の補足を付けてください。
多くのチャットAPIでは、こうした“立場や全体方針”を システムプロンプト（システムメッセージ）という、ユーザーの発言とは別枠の指示に置けます。会話全体を通して効く土台になります。
3. Few-shot プロンプティング（例示）
入力と理想の出力のペアを数個見せてから、本番の入力を渡す方法です。「こういう入力には、こう答えてほしい」を言葉で説明する代わりに実例で示すため、形式や分類基準を伝えるのに強力です。
次の文の感情を Positive / Negative で分類してください。
文: この映画は最高だった！ → Positive
文: 二度と行きたくない店だ。 → Negative
文: 配送は速いが梱包が雑だった。 →
例を1つも見せないのが zero-shot、数個見せるのが few-shot です。例の質と並べ方が結果を左右するので、理想に近い例を選ぶのがコツです。
最近のモデルは指示が明確なら例なしでも十分こなせることが多いです。いきなり例を盛らず、まず明確な指示（zero-shot）で試し、形式がブレる・分類基準が伝わらないときに例を足すと、プロンプトが短く保てます。
4. Chain-of-Thought（段階的に考えさせる）
「順を追って考えてから答えて（Let's think step by step）」のように、結論の前に途中の考えを書かせる手法です。計算や複数ステップの推論で、いきなり答えを出させるより正確になりやすいことが知られています。
問題: りんごが12個。3人に同じ数ずつ配り、2個余った。1人何個？
悪い指示: 答えだけ教えて。
良い指示: 計算の手順を1ステップずつ示してから、最後に答えを書いてください。
途中の思考が見えるので検算や原因追跡がしやすいのも利点です。一方で出力は長くなり、その分だけトークン（処理量）も増えます。最終的な答えだけが欲しい用途では、思考を出させてから結論だけ抽出する運用にすると扱いやすくなります。
つまずきポイント
LLM は「知らない」ときでも、もっともらしい続きとして事実でない内容を自信ありげに生成することがあります（ハルシネーション）。プロンプトの工夫で減らせても、ゼロにはできません。正確さが要る場面では、根拠となる資料をプロンプトに添えて「この資料の範囲だけで答え、無ければ『分からない』と言う」と縛るのが有効です（社内文書などを検索して渡す /ai/fine-tuning-rag/ の RAG が代表例）。最終的には人間の確認が前提です。
よくある失敗と、その改善の方向をまとめます。
| よくある失敗 | なぜ起きる | 改善の方向 |
|---|---|---|
| 出力がブレて毎回違う形式 | 形式を指定していない／指示が曖昧 | 出力形式・文字数・例を明示する |
| 指示の一部が無視される | 1プロンプトに要求を詰め込みすぎ | タスクを分割し、手順や箇条書きで整理 |
| 事実が間違っている | 知識が古い／無い部分を生成で埋めた | 根拠資料を渡し範囲を限定（RAG等） |
| 長文で指示が薄まる | 重要な制約が中盤に埋もれる | 重要な指示は冒頭か末尾に置く |
| 否定指示が効きにくい | 「〜するな」だけだと方向が定まらない | 代わりにしてほしい事を肯定形で書く |
ポイントは、否定形（〜するな）より肯定形（代わりに〜して）、詰め込みより分割、抽象より具体です。うまくいかないときは「自分の指示だけ読んで、人間が一意に書けるか？」を自問すると、足りない条件が見えてきます。
たとえ：新人さんへの仕事の頼み方
プロンプトエンジニアリングは、優秀だけど“あなたの事情を何も知らない”新人さんへの仕事の頼み方によく似ています。
- 「よしなにやっといて」では、相手は推測で動くしかなく、仕上がりは毎回バラバラ（＝曖昧なプロンプト）。
- 「目的・読者・締切・フォーマット」を伝えれば、狙い通りに仕上がる（＝明確な指示と文脈）。
- 「過去の完成品のサンプル」を見せれば、説明しづらいニュアンスも伝わる（＝Few-shot）。
- 「考えた過程も書いてね」と頼めば、ミスに気づきやすく直しやすい（＝Chain-of-Thought）。
新人さんが優秀でも、指示が雑なら結果は雑になります。モデルの賢さを引き出すのは、結局こちらの伝え方——これがプロンプトエンジニアリングの核心です。
AI/機械学習 Article
プロンプトエンジニアリングを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
LLM
比較で見る軸
難易度: basic / カテゴリ: AI/機械学習 / タグ数: 3
導入後に効く点
効く順の定番：①明確な指示と出力形式の指定 ②役割と文脈の付与 ③Few-shot（お手本の例示）④Chain-of-Thought（段階的に考えさせる）。
先に潰すリスク
用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。
- 難易度
- basic
- カテゴリ
- AI/機械学習
- タグ数
- 3
判断チェックリスト
- 自社の用途が「LLM / プロンプト」に近いか確認する。
- 強みである「プロンプトエンジニアリングは、LLM への入力（指示・文脈・例）を設計して、狙った出力を安定して引き出す技術。モデルを再学習せずに精度を上げられる。」が本当に評価軸になるか確認する。
- 注意点の「用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。