ChatGPTやClaudeなどのLLMを使い始めると、「なぜ同じ質問でも人によって結果が違うのか」という疑問にぶつかる。
その差の多くは、プロンプトエンジニアリング——入力文の設計——に起因する。
この記事は、初心者が最初に覚えるべき5つの基本構造を、コピペできるテンプレート付きで整理する。

結論：良いプロンプトは5要素の組み合わせ

要素	役割	省略すると起きること
役割（Role）	モデルの視点・専門性を指定する	汎用的すぎる回答になる
タスク（Task）	何をしてほしいかを明示する	意図と違う作業をされる
コンテキスト（Context）	背景情報・制約条件を渡す	前提のない推測で答える
出力形式（Format）	返答の構造を指定する	長文・箇条書きの揺れが大きい
例示（Examples）	望ましい入出力のサンプルを示す	フォーマットや品質が不安定になる

覚え方：「誰として（Role）・何を（Task）・何を前提に（Context）・どう返す（Format）・こういう例（Examples）」の5点セット。

プロンプトエンジニアリングとは何か

プロンプトエンジニアリングとは、LLMに渡す入力テキスト（プロンプト）を設計・改善して、望ましい出力を得る技術のことだ。

モデルの重み（パラメータ）を変更するファインチューニングとは異なり、推論時の入力だけを工夫する手法である。
そのため、APIキーさえあれば誰でも今日から試せる。

OpenAIの公式ドキュメントでは、プロンプト設計の基本原則として以下が挙げられている。

指示を明確かつ具体的に書く
参照テキストを与える（必要な場合）
複雑なタスクはステップに分解する
モデルに「考える時間」を与える（推論の促進）
外部ツールを活用する（必要な場合）

原文: "Write clear instructions"
日本語訳: 「明確な指示を書く」（出典: OpenAI Prompt Engineering Guide）

基本の型1：役割 + タスク（最小構成）

最もシンプルな型は、役割とタスクの2行だ。

あなたはシニアバックエンドエンジニアです。
以下のREST API設計について、セキュリティ上の懸念点を3つ挙げてください。

パーツ	内容
役割	「シニアバックエンドエンジニア」
タスク	「セキュリティ上の懸念点を3つ挙げる」

役割を指定すると、専門用語の粒度や着眼点が変わる。
「初心者向けに説明して」と付け加えるだけでも、回答の難易度が大きく変わる。

基本の型2：コンテキスト付き（背景情報を渡す）

実務では、前提情報をプロンプトに含めることが多い。

あなたはテクニカルライターです。

【背景】
- 対象読者：Web開発初心者
- 記事の目的：HTTPステータスコードの基本を解説する
- 文字数：2000字程度

【タスク】
404と500の違いを、具体例付きで説明する記事の構成案を作成してください。
見出し（H2/H3）レベルまで書いてください。

コンテキストを渡すことで、モデルが「誰向けに」「どの粒度で」書くかを推測する必要がなくなる。
社内ドキュメントや仕様書の抜粋を渡す場合も同じ構造だ。

基本の型3：出力形式の指定（Format）

出力の構造を明示すると、後続処理（パース・レビュー）が楽になる。

以下のJSON形式で回答してください。他のテキストは出力しないでください。

{
  "summary": "1文の要約",
  "risks": ["リスク1", "リスク2", "リスク3"],
  "recommendation": "推奨アクション"
}

【入力テキスト】
（ここに分析対象のテキストを貼る）

形式指定の例	用途
JSON / YAML	プログラムからの自動処理
Markdown表	比較・一覧の整理
番号付きリスト	手順・チェックリスト
「3行以内で」	長文化の抑制

注意点として、複雑なJSONスキーマを一度に要求すると、構文エラーが増える。
まずシンプルな形式で試し、必要に応じてフィールドを追加するのが安全だ。

基本の型4：Few-shot（例示による誘導）

入出力の例を2〜3組示す手法を Few-shot（少数例学習）という。
モデルに「こういう変換をしてほしい」というパターンを伝えるのに有効だ。

以下の形式で、技術用語を初心者向けに言い換えてください。

【例1】
入力: API
出力: 他のソフトウェアとデータをやり取りするための窓口

【例2】
入力: デプロイ
出力: 作ったプログラムを実際に使える環境に配置して公開すること

【例3】
入力: コンテナ
出力: アプリとその実行環境をひとまとめにした箱。どこでも同じように動かせる

【今回の入力】
入力: マイクロサービス
出力:

例示のコツは次のとおりだ。

例は2〜5組が目安（多すぎるとコンテキストを圧迫する）
例の品質がそのまま出力品質に反映される（悪い例を渡さない）
境界ケース（曖昧な入力）の例も1組入れると安定する

基本の型5：Chain-of-Thought（段階的推論の促進）

複雑な問題では、思考過程を出力させてから結論を出すと精度が上がることが多い。
これを Chain-of-Thought（CoT）と呼ぶ。

以下の問題を解いてください。
回答は「思考過程」と「最終回答」の2段階で書いてください。

【問題】
あるWebサービスは月間100万リクエストを処理している。
1リクエストあたり平均200msかかる。
同時接続数の上限を見積もってください。

【出力形式】
思考過程:
（計算や前提の確認をステップごとに書く）

最終回答:
（結論を1〜2文で）

CoTが効きやすい場面は次のとおりだ。

算術・論理パズル
多段階の判断（要件分析、影響範囲の洗い出し）
コードレビュー（問題点の列挙 → 優先度付け）

一方、単純な翻訳や要約では CoT を付けると冗長になるだけなので、タスクに応じて使い分ける。

5つの型を組み合わせた実用テンプレート

実務でよく使うフル構成テンプレートを示す。

# 役割
あなたは{専門分野}のエキスパートです。

# コンテキスト
- 対象：{読者・利用者}
- 制約：{文字数・トーン・禁止事項}

# タスク
{具体的な作業内容}

# 出力形式
{Markdown表 / JSON / 箇条書き など}

# 例（任意）
入力: ...
出力: ...

# 入力
{実際のデータ・質問}

このテンプレートに当てはめるだけで、多くの業務タスクに対応できる。
最初は全部埋めず、タスクと出力形式だけから始め、精度が足りなければ役割・コンテキスト・例を追加する。

プロンプト改善の反復サイクル

プロンプトは一度書いて終わりではなく、評価 → 修正 → 再評価のサイクルで磨く。

1. ベースラインを作る（最小構成のプロンプト）
2. 代表例5〜10件で出力を確認する
3. 失敗パターンを分類する（形式崩れ / 事実誤り / 漏れ）
4. 1つずつ対策をプロンプトに反映する
5. 全体の精度が上がったらバージョンを固定する

バージョン管理の例：

バージョン	変更内容	精度（主観）
v0.1	タスクのみ	60%
v0.2	役割 + 出力形式追加	75%
v0.3	Few-shot 2例追加	85%
v1.0	制約条件を明文化	90%

本番運用では、プロンプト本文をコードや設定ファイルにハードコードせず、外部ファイルやプロンプト管理ツールで管理するのが一般的だ。

実装チェックリスト

プロンプトに「役割」「タスク」「出力形式」の最低3要素が含まれているか確認する
曖昧な指示（「いい感じに」「適切に」）を具体的な条件に置き換える
複雑なタスクはステップ分解または CoT で段階的に処理させる
出力形式（JSON/Markdown等）を明示し、パース失敗時のフォールバックを用意する
代表例5件以上で出力品質を評価し、失敗パターンを記録する
プロンプトのバージョンを管理し、変更履歴を残す
機密情報（APIキー・個人情報）をプロンプトに含めない

失敗パターン

パターン1：指示が曖昧で毎回違う出力になる
→ 対策：タスクを動詞で明確化し、出力形式と文字数制限を追加する。

パターン2：長すぎるプロンプトで重要な指示が埋もれる
→ 対策：セクション見出し（# 役割 # タスク）で構造化する。不要なコンテキストは削る。

パターン3：JSON出力で構文エラーが頻発する
→ 対策：スキーマを簡素化する。response_format: json_object（OpenAI）など API 側の構造化出力機能を使う。

パターン4：例示の品質が低く、出力も低品質になる
→ 対策：Few-shot の例を人間がレビューし、望ましい出力の「お手本」を丁寧に作る。

パターン5：プロンプト改善で過学習（特定例にだけ強くなる）
→ 対策：評価セットを多様化する。本番データに近い例で定期的に再検証する。

まとめ

プロンプトエンジニアリングは、入力文の設計でLLMの出力品質を上げる技術であり、誰でも今日から試せる。
基本の型は Role / Task / Context / Format / Examples の5要素。最小構成は Role + Task から始める。
Few-shot でパターンを示し、CoT で複雑な推論を安定させる。
一度書いて終わりにせず、評価セットで反復改善し、バージョン管理する。

参考リンク

この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。