prompt-engeneering

プロンプトエンジニアリング

あらゆる LLM で効果的なプロンプトを作成するための汎用的なテクニックです。

基本原則

1. XML タグで構造化する

XML タグを使って、明確で解析可能なプロンプトを作成します。

<context>Background information here</context>
<instructions>
1. First step
2. Second step
</instructions>
<examples>Sample inputs/outputs</examples>
<output_format>Expected structure</output_format>

利点：

• 明確さ：コンテキスト、指示、例を分けられます
• 正確さ：モデルがセクションを混同するのを防ぎます
• 柔軟性：個々のパーツを簡単に変更できます
• 解析可能性：構造化された出力の抽出が可能になります

ベストプラクティス：

• タグ名は一貫して使用します（<steps>を使う場合と使わない場合があるのではなく、常に<instructions>を使用します）
• タグを明示的に参照します：「<context>タグ内のデータを使って……」
• タグをネストして階層を作成します：<examples><example id="1">...</example></examples>
• 他のテクニックと組み合わせます：思考の連鎖には<thinking>、最終出力には<answer>を使用します

2. 出力の形式を制御する

長さ、形式、構造に関する明示的な制約を指定します。

<output_spec>
- Default: 3-6 sentences or ≤5 bullets
- Simple yes/no questions: ≤2 sentences
- Complex multi-step tasks:
  - 1 short overview paragraph
  - ≤5 bullets: What changed, Where, Risks, Next steps, Open questions
- Use Markdown with headers, bullets, tables when helpful
- Avoid long narrative paragraphs; prefer compact structure
</output_spec>

3. 範囲の逸脱を防ぐ

モデルがしてはいけないことを明示的に制限します。

<constraints>
- Implement EXACTLY and ONLY what is requested
- No extra features, components, or embellishments
- If ambiguous, choose the simplest valid interpretation
- Do NOT invent values, make assumptions, or add unrequested elements
</constraints>

4. 曖昧さに明示的に対処する

幻覚や過度な自信を防ぎます。

<uncertainty_handling>
- If the question is ambiguous:
  - Ask 1-3 precise clarifying questions, OR
  - Present 2-3 plausible interpretations with labeled assumptions
- When facts may have changed: answer in general terms, state uncertainty
- Never fabricate exact figures or references when uncertain
- Prefer "Based on the provided context..." over absolute claims
</uncertainty_handling>

5. 長いコンテキストへの根拠付け

入力が10kトークンを超える場合は、再度根拠付けを行う指示を追加します。

<long_context_handling>
- First, produce a short internal outline of key sections relevant to the request
- Re-state user constraints explicitly before answering
- Anchor claims to sections ("In the 'Data Retention' section...")
- Quote or paraphrase fine details (dates, thresholds, clauses)
</long_context_handling>

エージェント向けプロンプト

ツールの使用ルール

<tool_usage>
- Prefer tools over internal knowledge for:
  - Fresh or user-specific data (tickets, orders, configs)
  - Specific IDs, URLs, or document references
- Parallelize independent reads when possible
- After write operations, restate: what changed, where, any validation performed
</tool_usage>

ユーザーへの進捗報告

<user_updates>
- Send brief updates (1-2 sentences) only when:
  - Starting a new major phase
  - Discovering something that changes the plan
- Avoid narrating routine operations
- Each update must include a concrete outcome ("Found X", "Updated Y")
- Do not expand scope beyond what was asked
</user_updates>

高リスクな出力のセルフチェック

<self_check>
Before finalizing answers in sensitive contexts (legal, financial, safety):
- Re-scan for unstated assumptions
- Check for ungrounded numbers or claims
- Soften overly strong language ("always", "guaranteed")
- Explicitly state assumptions
</self_check>

構造化抽出

データ抽出タスクでは、必ずスキーマを指定します。

<extraction_spec>
Extract data into this exact schema (no extra fields):
{
  "field_name": "string",
  "optional_field": "string | null",
  "numeric_field": "number | null"
}
- If a field is not present in source, set to null (don't guess)
- Re-scan source for missed fields before returning
</extraction_spec>

Web リサーチ向けプロンプト

<research_guidelines>
- Browse the web for: time-sensitive topics, recommendations, navigational queries, ambiguous terms
- Include citations after paragraphs with web-derived claims
- Use multiple sources for key claims; prioritize primary sources
- Research until additional searching won't materially change the answer
- Structure output with Markdown: headers, bullets, tables for comparisons
</research_guidelines>

例：変更前と変更後

構造化なし：

You're a financial analyst. Generate a Q2 report for investors. Include Revenue, Margins, Cash Flow. Use this data: {{DATA}}. Make it professional and concise.

構造化あり：

You're a financial analyst at AcmeCorp generating a Q2 report for investors.

<context>
AcmeCorp is a B2B SaaS company. Investors value transparency and actionable insights.
</context>

<data>
{{DATA}}
</data>

<instructions>
1. Include sections: Revenue Growth, Profit Margins, Cash Flow
2. Highlight strengths and areas for improvement
3. Use concise, professional tone
</instructions>

<output_format>
- Use bullet points with metrics and YoY changes
- Include "Action:" items for areas needing improvement
- End with 2-3 bullet Outlook section
</output_format>

プロンプト移行チェックリスト

モデルやバージョンをまたいでプロンプトを適用する場合：

1. モデルを切り替え、プロンプトは同一に保つ — 変数を切り分けます
2. 推論／思考の深さを固定する — 以前のモデルのプロファイルに合わせます
3. 評価を実行する — 結果が良好であればリリースします
4. 性能が低下した場合はプロンプトを調整する — 冗長さ／形式／範囲に関する制約を調整します
5. 小さな変更を加えるたびに再評価する — 一度に一つだけ変更します

クイックリファレンス

テクニック	タグのパターン	使用例
セクションを分ける	<context>, <instructions>, <data>	複雑なプロンプト全般
長さを制御する	単語数／箇条書き数の上限を設けた<output_spec>	冗長さの防止
範囲の逸脱を防ぐ	「DO NOT」を明示した<constraints>	機能の肥大化
不確実性に対処する	<uncertainty_handling>	事実に関する質問
思考の連鎖	<thinking>, <answer>	推論タスク
抽出	JSON 構造を含む<schema>	データ解析
リサーチ	<research_guidelines>	Web 対応エージェント
セルフチェック	<self_check>	高リスク分野
ツールの使用	<tool_usage_rules>	エージェント型システム
積極性の制御	<persistence>, <context_gathering>	エージェントの自律性
ペルソナ	<role>＋行動上の制約	トーンとスタイル

プロンプト手法カタログ

プロンプト手法の包括的なカタログです。詳細、例、学術的な参考文献については、references/prompting-techniques.mdを参照してください。

手法	用途
Zero-Shot Prompting	例を使わずにタスクを直接実行します。分類、翻訳、要約に適しています
Few-Shot Prompting	例を使ったインコンテキスト学習です。形式の制御、ラベルの調整、スタイルの一致に適しています
Chain-of-Thought (CoT)	段階的に推論します。算術、論理、常識的な推論を要するタスクに適しています
Meta Prompting	LLM をオーケストレーターとして、専門家向けのプロンプトにタスクを委任します。複雑な複数領域のタスクに適しています
Self-Consistency	複数の CoT の推論経路をサンプリングし、最も多い回答を選びます。数学や推論の精度向上に役立ちます
Generated Knowledge	まず関連知識を生成し、その後に回答します。常識や事実に関する QA に適しています
Prompt Chaining	複雑なタスクを順序立てたサブタスクに分割します。文書分析、複数段階のワークフローに適しています
Tree of Thoughts (ToT)	先読みやバックトラッキングを用いて、複数の推論分岐を探索します。計画、パズルに適しています
RAG	生成前に外部文書を検索します。知識集約型のタスクや最新データを必要とする場合に適しています
ART (Auto Reasoning + Tools)	CoT を用いてツールを自動選択し、オーケストレーションします。計算、検索、API を必要とするタスクに適しています
APE (Auto Prompt Engineer)	LLM が候補プロンプトを生成し、スコアを付けます。大規模なプロンプト最適化に適しています
Active-Prompt	不確実な例を特定し、CoT のために選択的に注釈を付けます。適応型の Few-Shot に適しています
Directional Stimulus	ヒントやキーワードを加えて、生成の方向性を導きます。要約、対話に適しています
PAL (Program-Aided LM)	推論のためにテキストではなくコードを生成します。数学、データ操作、記号的なタスクに適しています
ReAct	推論の軌跡とツールのアクションを交互に実行します。検索、QA、意思決定を行うエージェントに適しています
Reflexion	エージェントが失敗を言語化されたフィードバックで自己省察します。反復的な改善、デバッグに適しています
Multimodal CoT	2 段階で進めます。まず根拠を生成し、その後テキストと画像を用いて回答します。視覚的な推論タスクに適しています
Graph Prompting	構造化されたグラフベースのプロンプトを使用します。ノード分類、関係抽出、グラフタスクに適しています

プロンプトの基礎

LLM の設定、プロンプトの要素、形式、実用例については、references/prompting-introduction.mdを参照してください。次の内容を扱います：

• LLM の設定 — temperature、top-p、最大長、停止シーケンス、頻度ペナルティ／存在ペナルティ
• プロンプトの要素 — 指示、コンテキスト、入力データ、出力の指標
• 設計のヒント — シンプルに始める、具体的にする、曖昧さを避ける、「してはいけないこと」ではなく「すべきこと」を伝える
• タスクの例 — 要約、抽出、QA、分類、会話、コード生成、推論

リスクと誤用

敵対的攻撃、事実性の問題、バイアスの軽減については、references/prompting-risks.mdを参照してください。次の内容を扱います：

• 敵対的プロンプティング — プロンプトインジェクション、プロンプト漏えい、ジェイルブレイク（DAN、Waluigi Effect）、防御策
• 事実性 — 正解データに基づく根拠付け、確信度の調整、知識がないことを認めるパターン
• バイアス — 例の分布の偏り、例の順序による影響、バランスの取れた Few-Shot の設計

プロンプトの監査／レビュー

プロンプトの監査、レビュー、改善を依頼された場合は、このワークフローに従ってください。各チェック項目の参考資料を含む完全なチェックリストについては、prompt-audit-checklist.mdを参照してください。

ワークフロー

1. プロンプトを最後まで読む — 目的、対象モデル、導入環境（対話型チャット、エージェント型システム、バッチパイプライン、RAG 拡張型）を特定します
2. 8 つの観点を確認する — それぞれを確認し、深刻度（Critical／Warning／Suggestion）を付けて問題を記録します：

#	観点	確認事項
1	明確さと具体性	タスクの定義、成功基準、対象読者、出力形式、制約の矛盾
2	構成と書式	セクションの分離（XML タグ）、プロンプトの問題点（一枚岩、レイヤーの混在、否定的なバイアス）
3	安全性とセキュリティ	制御とデータの分離、プロンプト内のシークレット、インジェクション耐性、ツールの権限
4	ハルシネーションと事実性	役割の設定、根拠付け、出典なしの引用、不確実性への対処
5	コンテキスト管理	情報の配置（中ほどに埋もれていないか）、コンテキストサイズ、RAG ドキュメント数、再度の根拠付け
6	保守性と負債	ハードコードされた値、再生成されるロジック、モデルの固定、テスト可能性
7	モデル固有の適合性	モデル固有のパラメーターと注意点（下記の「モデル固有ガイド」を参照）
8	評価への対応	評価基準、敵対的テストケース、スキーマの適用、モニタリング

3. レポートを作成する — 問題の表（観点、確認事項、深刻度、問題、修正策）と、書き直したプロンプトまたは対象を絞った修正案を提示します。チェックリストのリファレンスにあるレポートテンプレートを使用してください。
4. 各問題について、ユーザーが詳細を確認できるよう、関連するリファレンスファイルを記載します。

優先する観点を選ぶクイックガイド

• ユーザー向けチャットボット → 安全性（#3）、ハルシネーション（#4）、明確さ（#1）を優先します
• ツールを使うエージェント型システム → 安全性（#3）、コンテキスト（#5）、保守性（#6）を優先します
• バッチ／パイプライン → 構成（#2）、評価（#8）、保守性（#6）を優先します
• RAG 拡張型 → コンテキスト（#5）、安全性（#3）、ハルシネーション（#4）を優先します

よくある間違いとアンチパターン

相互に補完する 3 つのレイヤーがあります。ニーズに合うものを使用してください：

カテゴリ別の詳細解説 — 根本原因、メカニズム、防止チェックリスト（「The Architecture of Instruction」、2026 より）：

間違いのカテゴリ	主な問題	リファレンス
ハルシネーションとロジック	曖昧さによる作話、自動化バイアス、過剰なプロンプト、検証タスクにおける論理的な失敗、役割の設定不足	mistakes-hallucinations.md
構造上の脆弱性	書式への過敏性（最大 76pp の差異）、再現性の危機、プロンプトの問題点カタログ（6 つのアンチパターン）、熟考の段階	mistakes-structure.md
コンテキストの劣化	「中間部分の見落とし」における U 字型の注意、RAG の過剰な検索、単純なデータ読み込み、コンテキストエンジニアリングへの移行	mistakes-context.md
プロンプト負債	コード再生成のトークンコスト、負債の分類（プロンプト／ハイパーパラメーター／フレームワーク／コスト）、マルチエージェントによる解決策、自動修復	mistakes-debt.md
セキュリティ	直接的／間接的なインジェクション、ジェイルブレイク、システムプロンプトの漏えい（OWASP LLM07:2025）、RAG の汚染、マルチモーダルインジェクション、敵対的サフィックス	mistakes-security.md

クイックリファレンス — MRP、リスクスコア、事例、アクション項目を含む 18 カテゴリの分類：failure-taxonomy.md。全体像を把握したい場合や、最初に対処するカテゴリを決める場合は、ここから始めてください。対象：制御プレーンとデータプレーンのモデル、ヒューリスティックなリスクスコアリング、実際のインシデント（EchoLeak CVE-2025-32711、Mata v. Avianca、Samsung のシャドー AI）。

測定とテストの方法 — 評価指標、CI ゲーティング、レッドチーミング、ツール：evaluation-redteaming.md。対象：TruthfulQA、FActScore、SelfCheckGPT、PromptBench、AILuminate、LLM を審査員として使う際の落とし穴、ガードレールライブラリ、未解決の研究課題。

モデル別ガイド

モデルファミリーごとに、固有のパラメーター、注意点、パターンがあります。対象モデルのリファレンスを参照してください。

• Claude Family — Opus/Sonnet 4.6：アダプティブシンキング（effort パラメーター）、プレフィルの非推奨化（Structured Outputs を使用）、ツールの過剰起動を防ぐ方法、プロンプトキャッシュ、引用、コンテキストエンジニアリング、エージェント型サブエージェントのパターン、ビジョン、4.5 からの移行
• GPT-5 Family — GPT-5/5.1/5.2：reasoning_effort パラメーター（デフォルト値はバージョンによって異なります）、verbosity による API 制御、名前付きツール（apply_patch）、エージェント型の積極性テンプレート、コンパクション API、指示の競合に対する感度、移行パス
• Gemini 3 Family — Gemini 2.5/3/3.1：temperature は必ず 1.0、thinking_budget と thinking_level の違い、制約の配置（プロンプトの末尾）、ペルソナの優先度、関数呼び出し、構造化出力、マルチモーダル、画像生成
• GPT-5.2 Specifics — コンパクション API のコード例、ウェブ調査エージェントのプロンプト、XML 仕様ブロックの全体