【ガイド 第1回】プロンプトエンジニアリングとは？AIエージェント時代に欠かせない理由

Prompt Engineering ガイド 第1回（全10回）。シリーズの出発点です。第1〜6回は前の回を前提に進むため、順番にお読みください。第7〜10回は実務への応用編です。次は 第2回：LLM の仕組み：生成 AI の基礎。

プロンプトエンジニアリング（prompt engineering）とは、生成 AI モデルが必要な出力を安定して返すように、入力を設計する技術です。AI の専門家向けのニッチな技術に聞こえるかもしれません。しかし実際には、ChatGPT・Claude・Gemini やコーディングエージェントが 1 時間を節約してくれるか、逆に 1 時間を奪うかを左右するのがこのスキルです。

こうしたツールを使ったことがあれば、両方の結果を経験しているはずです。ある依頼ではそのまま使える回答が返ってくる。似た依頼では、ありきたりな文章や事実と異なる内容、的外れなコードが返ってくる。モデルは同じでした。違ったのはプロンプトです。

本記事では、プロンプトとは何か、プロンプトを「書く」ことと「設計する」ことの違い、そして AI エージェントが指示ファイルを読み、ツールを呼び出し、数十分から数時間自律的に作業する今、なぜこのスキルの重要性が増しているのかを解説します。各セクションに、そのままコピーして試せるサンプルを用意しました。

プロンプトとは何か

プロンプトとは、モデルが回答する前に読むすべての情報です。チャット画面では自分のメッセージに見えますが、その裏ではアプリが書いたシステムプロンプト、会話の履歴、添付ファイル、そしてエージェントの場合は呼び出せるツールの説明も含まれています。

役に立つプロンプトには 4 種類の要素があります。指示（何をするか）、コンテキスト（作業の材料となる事実や資料）、例（良い出力の見本）、出力形式（回答の形）です。短いプロンプトでも 4 つすべてを含められます。チケット本文は自社のチケットに差し替えて試してください。

次のサポートチケットを、オンコール担当エンジニア向けに要約してください。
箇条書きはちょうど 3 項目：「影響」「推定原因」「次のアクション」。
チケットに書かれていない項目は「不明」と書いてください。

チケット：
"""
09:40 以降、シンガポールのお客様が決済時に「502 Bad Gateway」になります。
他リージョンは正常です。09:35 に payment-service v3.8.1 をデプロイしました。
現時点で失敗した注文は約 120 件です。
"""

- 影響：09:40 以降、シンガポールのお客様の決済が 502 エラーで失敗。失敗注文は約 120 件。他リージョンへの影響はなし。
- 推定原因：エラー発生の 5 分前（09:35）にデプロイされた payment-service v3.8.1。
- 次のアクション：シンガポールリージョンの payment-service を前バージョンにロールバックし、決済が回復するか確認する。

指示で読み手とタスクを明示し、区切り記号（"""）で資料と依頼を分け、形式のルールで一目で読める回答にしています。「不明と書く」というルールは、情報が足りないときに推測させず、どう振る舞うべきかをモデルに伝えるものです。

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

プロンプトエンジニアリングとは、モデルが必要な出力を安定して返すまで、プロンプトを設計・テスト・改善することです。プロンプトを「書く」ことと「設計する」ことの違いは、この「安定して」にあります。一度うまくいったプロンプトは幸運なメッセージにすぎません。次の 50 件の入力でも機能するプロンプトこそ、頼れる部品になります。

この分野は広大です。メリーランド大学、OpenAI、スタンフォード大学などの研究者による 2024 年のサーベイ論文 The Prompt Report は、テキスト向けのプロンプト技法を 58 種類、その他のモダリティ向けに 40 種類を整理しています。そのほとんどは不要です。必要なのは下図のループと、本シリーズで扱う少数の基本技法です。

設計を始める手っ取り早い方法は、新しく入った同僚の目線でプロンプトをモデル自身にレビューさせることです。Anthropic のプロンプトガイドはこれを「ゴールデンルール」と呼んでいます。前提知識の少ない同僚が混乱するなら、モデルも混乱する、という考え方です。繰り返し使っているプロンプトを貼り付けてください。

次のプロンプトを厳しくレビューしてください。背景知識のない新任の同僚が
このプロンプトを使う想定です。以下を挙げてください。
1. 曖昧な点：2 通りに解釈できる言葉や要件
2. 不足している事実：読み手が知っている前提になっている情報
3. 不足している成功基準：出力が正しいとどう判断するか
そのうえで、これらを解消したプロンプトに書き直してください。
私の意図は保ち、新しい目的は追加しないでください。

プロンプト：
"""
{ここにプロンプトを貼り付け}
"""

1. 曖昧な点
- 「短い要約」：長さの指定がありません。2 文なのか 2 段落なのか不明です。
- 「チーム向け」：どのチームか不明で、文体が決まりません。

2. 不足している事実
- リリース日と、各機能が対象とするプラン。

3. 不足している成功基準
- 必ず含めるべき項目の指定がなく、結果を確認できません。

書き直したプロンプト：
「カスタマーサクセスチーム向けに、80 字以内で要約を書いてください……」
（一部省略）

同じモデルでも結果はまったく違う

プロンプトエンジニアリングの重要性を最も早く実感する方法は、同じモデルに同じ仕事を 2 回頼むことです。題材は、どのソフトウェアチームも書く「お客様向けリリースノート」です。

新しいバージョンのリリースノートを書いてください。

# リリースノート – バージョン 2.0

最新バージョンのリリースをお知らせします！今回のアップデートでは、
強力な新機能、パフォーマンスの向上、重要なバグ修正をお届けします。

## 新機能
- **ダークモード**：目に優しい洗練された新デザイン。
- **ダッシュボードの強化**：これまで以上に素早くインサイトを把握。
……
（一部省略）

この出力に使える部分はありません。モデルは製品も変更内容も読み手も知らないため、テンプレートを作り、存在しない機能で埋めました。これはモデルの失敗ではなく、中身のない依頼に対する唯一の妥当な回答です。では、事実と読み手を明記して同じタスクを頼んでみます。

B2B 向けプロジェクト管理アプリ「Taskflow」の、お客様向けリリースノートを書いてください。

読み手：中小企業のチーム管理者。開発者ではありません。
チームにとって何が変わるのか、自分が対応すべきことがあるのかを知りたい人です。

事実（これだけを使い、機能を追加しないこと）：
- バージョン 4.2 は 11 月 12 日に提供開始。
- 新機能：Okta と Microsoft Entra ID によるシングルサインオン（SAML）。Business プランのみ。
- 新機能：監査ログの CSV エクスポート。すべての有料プラン。
- 修正：UTC+7〜UTC+9 の一部ユーザーに期日リマインダーが 2 回届いていた問題。
- 必要な対応：なし。シングルサインオンは管理者が有効化するまでオフのまま。

形式：
- 20 字以内のタイトルと、1 文の概要
- 見出しは「新機能」「修正」「対応は必要ですか？」
- 平易な言葉で、誇張した宣伝表現は使わず、300 字以内

Taskflow 4.2：シングルサインオンと監査ログのエクスポートに対応

11 月 12 日提供の Taskflow 4.2 では、Business プランでシングルサインオンが、
すべての有料プランで監査ログのエクスポートが使えるようになります。

新機能
- Okta と Microsoft Entra ID によるシングルサインオン（SAML）。Business プランで利用できます。
- すべての有料プランで、監査ログを CSV でエクスポートできます。

修正
- UTC+7〜UTC+9 のタイムゾーンの一部ユーザーに、期日リマインダーが 2 回
  届いていた問題を修正しました。リマインダーは 1 回だけ送信されます。

対応は必要ですか？
必要ありません。シングルサインオンは管理者が有効にするまでオフのままです。

2 つ目のプロンプトは書くのに 2 分ほど余計にかかりました。その代わり、書き直し、存在しない機能のファクトチェック、そしてそれを公開してしまうリスクがなくなりました。数分の仕様記述と 1 時間の手戻りを交換する。これがプロンプトエンジニアリングの経済的な根拠のすべてです。

エンジニアにも AI ユーザーにもプロンプトエンジニアリングが必要な理由

大規模言語モデル（LLM）は、設計上汎用的なものです。言語、コード、膨大な公開知識を持っています。しかし、あなたの目的、読み手、事実、制約、そしてこのタスクで何をもって「完了」とするかは知りません。この 5 つはあなたの頭の中にしかなく、それをモデルの入力へ移す唯一の手段がプロンプトです。

つまりプロンプトは仕様書であり、仕様書と同じように失敗します。

• 曖昧な入力は推測で埋められる。 指定しなかった部分を、モデルは最も典型的な答えで埋めます。典型的な答えが、あなたの状況に合うことはまれです。
• 足りない事実は作られた事実になる。 与えられていない情報について問われると、モデルは知らないと認めるより、もっともらしい答えを作りがちです。その理由は第 2 回で解説します。
• 手戻りが隠れたコストになる。 曖昧なやり取りが 1 往復増えるたびに、読む時間・直す時間、コードならデバッグの時間がかかり、チーム全体で積み重なります。

これは移行スクリプトを頼む開発者にも、照合用の数式を頼む経理担当者にも、進捗報告を頼むマネージャーにも当てはまります。モデルに何を伝えればよいか分からないときは、モデルに聞かせればよいのです。次のプロンプトはほぼどんな成果物にも使えます。

{成果物を記入。例：「新任バックエンドエンジニア向けの 1 ページのオンボーディングガイド」}
を作りたいです。

書き始める前に、回答によって結果が最も大きく変わる質問を最大 5 つしてください。
観点は、読み手、目的、必ず含める事実、制約、形式です。
質問には番号を付け、私が回答するまで下書きはしないでください。

承知しました。下書きの前にいくつか質問させてください。

1. 読み手はどなたですか？新卒の方ですか、それとも経験豊富で入社したばかりの方ですか？
2. 入社 1 週目の終わりまでに、何ができるようになっていればよいですか？
3. 扱うべきシステムは何ですか？（リポジトリ、CI/CD、環境、オンコールなど）
4. セキュリティやコードレビューの方針など、初日から知っておくべきルールはありますか？
5. 形式はチェックリスト、文章形式のページ、日ごとの表のどれがよいですか？

ポイント：質問にはまとめて 1 通で答え、最後に「では書いてください」と送ります。何を含めるべきか事前に分かっていなくても、曖昧な依頼が仕様書に変わります。

AI エージェント時代のプロンプトエンジニアリング

AI エージェントとは、ツールをループで使うモデルです。ファイルを読み、コマンドを実行し、検索し、編集し、次の一手を自分で決めます。Claude Code、Cursor、GitHub Copilot といったコーディングエージェントも、多くのサポート用・データ分析用エージェントもこの仕組みで動いています。エージェントにとって、あなたが入力するメッセージは、モデルが読む情報のごく一部にすぎません。

Anthropic はコンテキストエンジニアリング（context engineering）を、プロンプトエンジニアリングの自然な発展形と位置づけています。入力するプロンプトだけでなく、システム指示、ツール、外部データ、会話履歴を含め、モデルが見るトークン全体を整える技術です。そしてこれらの層はすべて誰かが書いたものです。システムプロンプトも、ツールの説明も、プロジェクトの指示ファイルも、各ステップで読まれるプロンプトなのです。

最も分かりやすい例が指示ファイルです。多くのコーディングエージェントは AGENTS.md というファイルを読みます。メンテナーはこれを「エージェントのための README」と説明しています。Claude Code はセッション開始時に毎回 CLAUDE.md を読み込みます。短く正確なファイルが、その後のすべてのタスクの振る舞いを変えます。

# AGENTS.md

## プロジェクト
請求書 API。Node.js 22、TypeScript（strict）、PostgreSQL 16。

## コマンド
- インストール：pnpm install
- テスト：pnpm test（タスク完了を報告する前に必ず成功させること）
- Lint：pnpm lint

## ルール
- 金額は整数（セント単位）で保存する。金額に浮動小数点数は使わない。
- 新しいエンドポイントには Zod スキーマとテストを最低 1 つ付ける。
- src/migrations/ 内のファイルは手で編集しない。pnpm db:migrate:create を使う。

## 事前に確認すること
データの削除、公開 API の変更、依存パッケージの追加は、実行前に確認すること。

どのルールにも理由があります。ルールがなければ、エージェントはもっともらしいが誤った判断をするからです。金額に浮動小数点数を使う、テストのないエンドポイントを作る、マイグレーションを手で編集する、といった判断です。ツールの説明も同じです。次のテキストは、モデルがツールを呼ぶかどうか、どう呼ぶかを決めるときに読む文章であり、これもプロンプトです。

{
  "name": "search_invoices",
  "description": "顧客 ID と期間で請求書を検索する。請求額に関する質問に答える前に必ず使うこと。新しい順に最大 20 件を返す。金額は整数（セント単位）。",
  "input_schema": {
    "type": "object",
    "properties": {
      "customer_id": { "type": "string" },
      "from": { "type": "string", "description": "ISO 形式の日付（この日を含む）" },
      "to": { "type": "string", "description": "ISO 形式の日付（この日を含む）" }
    },
    "required": ["customer_id"]
  }
}

チャットよりも影響は大きくなります。チャットでの曖昧な回答は 1 回の書き直しで済みます。しかしエージェントへの曖昧な指示は何十ものステップで繰り返され、しかもエージェントは実際に行動します。ファイルを編集し、リクエストを送り、データを変更します。仕様の誤りは、気づく前に何倍にも膨らみます。

モデルが進化してもこのスキルが廃れない理由

「モデルが賢くなればプロンプトエンジニアリングは不要になる」という主張をよく聞きます。その一部は正しく、正しくない部分と分けて考える価値があります。

廃れるものは回避策の層です。魔法のフレーズ、脅し文句、凝った書式のテクニック、弱いモデルを補うための長いルールの羅列などです。Anthropic も先のコンテキストエンジニアリングの記事で、賢いモデルほど細かく指示する必要が減ると述べています。これは良いことです。

残るものは情報の問題です。しかも 3 つの流れが、その重要性を高めています。

1. 言わなかったことを、モデルは推測できない。 どれほど賢くても、あなたのリリース日、予算、顧客との契約条件、チームの規約を言い当てることはできません。これらの事実は入力に含める必要があります。
2. 指示に従う能力が上がるほど、正確な指示の効果が大きくなる。 最新のモデルは、言われたことをより文字どおりに実行します。Anthropic のガイドも、期待以上の働きを望むならモデルに推測させず明示的に頼むよう勧めています。正確なプロンプトには正確な結果が、曖昧なプロンプトには曖昧さを文字どおりに読んだ結果が返ってきます。
3. 任せる仕事が長くなっている。 エージェントが数時間作業するようになると、人の役割は各ステップを書くことから、目的・制約・成功基準・確認方法を最初に伝えることへ移ります。これはプロジェクトの指示書の規模で行うプロンプトエンジニアリングです。

ここから導かれる実践的な習慣は、モデルやエージェントに仕事を任せるたびに「完了の定義」を書くことです。次のブロックは、どんなタスクのプロンプトの末尾にも使えます。

タスク：{やること。例：「/reports エンドポイントに CSV エクスポートを追加する」}

完了の条件：
- {確認できる条件 1。例：「pnpm test が成功する」}
- {確認できる条件 2。例：「CSV を Excel で開いたとき日本語の見出しが文字化けしない」}

対象外：{変えてはいけないもの。例：「JSON レスポンスの形式」}

条件を満たせない場合は、回避策を取らずに作業を止め、理由を報告してください。

完了しました。
- GET /reports/export?format=csv を追加しました。Excel で見出しが文字化けしないよう UTF-8 BOM を付けています。
- pnpm test は成功しています（新規テスト 3 件）。

変更していないもの：GET /reports の JSON レスポンス。

補足：10 万行を超える大きなレポートは出力に約 8 秒かかります。
ストリーミング対応は対象外のため実装していません。対応しますか？

今日から使える汎用プロンプトテンプレート

良いプロンプトの多くは、同じ問いに答えています。次のテンプレートはそれを順番に並べたものです。波かっこの部分を埋め、不要なセクションは削除してください。正確さが重要な場合は「事実」ブロックを必ず残します。各要素と順序の詳細は第 3 回で解説します。

# 役割
あなたは{役割。例：「人事オペレーションの担当者」}です。

# 目的
{成果物}を作りたいです。読み手はそれを使って{読み手が行うこと}をします。

# 読み手
{誰が読むか、すでに何を知っているか}

# 事実
以下の事実だけを使ってください。必要な情報が足りない場合は、推測せずにその旨を書いてください。
"""
{事実・メモ・データ・コードを貼り付け}
"""

# 制約
- 長さ：{例：「200 字以内」}
- 文体：{例：「親しみやすく平易に、専門用語は使わない」}
- 必ず含めること／避けること：{……}

# 出力形式
{例：「1 行目を太字にし、箇条書き 3 点で構成した Slack メッセージ」}

# 確認
回答する前に、結果が制約を満たしているか確認し、置いた前提があれば列挙してください。

新しいリモートワーク制度を Slack で告知する内容でテンプレートを埋めたところ、次の結果が返ってきました。

*12 月 1 日から新しいリモートワーク制度が始まります* 🏠

- リモートワークは週 3 日まで可能です。
- コアタイムは 10:00〜15:00（ICT）です。この時間は連絡が取れるようにしてください。
- 翌週のリモート勤務日は、木曜日までに人事ポータルで申請してください。

ご質問はこのスレッドへの返信か、人事チームまでどうぞ。

前提：なし。すべての内容は提供された事実に基づいています。

よくある失敗と対策

最もコストが高いのは最初の失敗です。作られた詳細は本物とまったく見分けがつかないからです。抜けている情報を埋めさせず、見えるようにする 1 行を加えましょう。

以下の事実だけを使ってください。必要な情報が事実に含まれていない場合は、
推測せずに［不足：必要な情報］と書いてください。

事実：
"""
{事実を貼り付け}
"""

ウェビナーは［不足：日付］の 15:00（ICT）から 45 分間開催します。
お申し込みは［不足：申込ページの URL］からどうぞ。

このプロンプトエンジニアリングガイドで学べること

シリーズは全 10 回です。初めての方は順番に、目的がはっきりしている方は必要な応用編から読んでください。どの回も本記事と同じく、短い解説とコピーして使えるサンプルで構成しています。

• 基礎知識：本記事に続き、LLM の仕組み（トークン、コンテキストウィンドウ、チャットボットと素のモデルの違い、設計上考慮すべき限界）。
• 基本テクニック：プロンプトの構造、指示とロール、ゼロショットからフューショットまでの例の使い方、技法の組み合わせ・プライミング・反復改善。
• 応用編：要約・表・文書分析、メール・ブログ・マーケティング、コーディングアシスタント、RAG を使ったナレッジベース・チャットボット。

よくある質問

新しい AI モデルでもプロンプトエンジニアリングは必要ですか？

必要です。新しいモデルほど小手先のテクニックは不要になりますが、目的・事実・制約・完了の定義は、伝えない限り知りようがありません。エージェントに長いタスクを任せるほど、それらを明確に伝える重要性は増します。

プロンプトエンジニアリングを学ぶのにプログラミングの知識は必要ですか？

必要ありません。ほとんどの技法は、明確な指示を書き、適切な材料を渡すことです。プロンプトをアプリケーションに組み込む段階ではコーディングが役立ちます。それは第 9 回と第 10 回で扱います。

プロンプトエンジニアリングとコンテキストエンジニアリングの違いは何ですか？

プロンプトエンジニアリングは指示の書き方に焦点を当てます。コンテキストエンジニアリングは、ツール、検索された文書、履歴を含め、各ステップでモデルが見るすべてを扱います。コンテキストエンジニアリングはプロンプトエンジニアリングを含むものであり、置き換えるものではありません。

同じプロンプトは ChatGPT・Claude・Gemini で使い回せますか？

明確なプロンプトは、モデルのクセではなく情報に頼っているため、モデル間でよく機能します。ただし言い回しや長さ、書式の好みは少しずつ異なるため、重要なプロンプトは実際に使うモデルで試してください。

参考資料

• Learn Prompting: Prompt Engineering Guide（イントロダクション）
• Learn Prompting: Introduction to Prompt Engineering
• Schulhoff ほか「The Prompt Report: A Systematic Survey of Prompt Engineering Techniques」（arXiv:2406.06608）
• Anthropic: Effective context engineering for AI agents
• Anthropic: Claude のプロンプトのベストプラクティス
• OpenAI: Prompt engineering ガイド
• Google: Gemini のプロンプト設計戦略
• AGENTS.md：コーディングエージェント向けのオープンな形式
• Claude Code: Claude のメモリ管理（CLAUDE.md）

Prompt Engineering ガイド 全記事

次の回：第2回：LLM の仕組み：生成 AI の基礎 →

第1〜6回は前の回を前提にしているため、順番にお読みください。第7〜10回は基礎を押さえた後なら、どの順番でも読めます。

• 第1回：プロンプトエンジニアリングとは何か、なぜ重要か（この記事）
• 第2回：LLM の仕組み：生成 AI の基礎
• 第3回：プロンプトの構造：5 つの構成要素
• 第4回：指示プロンプトとロールプロンプト
• 第5回：ゼロショット・ワンショット・フューショット
• 第6回：技法の組み合わせ・プライミング・反復改善
• 第7回：要約・表・文書分析のプロンプト
• 第8回：メール・ブログ・マーケティングのプロンプト
• 第9回：コーディングアシスタントのプロンプト
• 第10回：ナレッジベース・チャットボット（RAG）の構築