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

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

コア原則

1. XMLタグを使った構造化

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

<context>背景情報をここに記述</context>
<instructions>
1. 最初のステップ
2. 次のステップ
</instructions>
<examples>サンプル入出力</examples>
<output_format>期待される構造</output_format>

メリット:

• 明確性: コンテキスト、指示、例を分離する
• 正確性: モデルがセクションを混同することを防ぐ
• 柔軟性: 個々の部分を簡単に修正できる
• 解析可能性: 構造化された出力の抽出を可能にする

ベストプラクティス:

• タグ名を一貫して使用する(<steps>ではなく<instructions>を常に使用)
• タグを明示的に参照する: 「<context>タグ内のデータを使用して...」
• 階層化のためにタグをネストする: <examples><example id="1">...</example></examples>
• 他のテクニックと組み合わせる: チェーン・オブ・ソートには<thinking>、最終出力には<answer>

2. 出力形状の制御

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

<output_spec>
- デフォルト: 3〜6文または≤5個の箇条書き
- シンプルな はい/いいえ質問: ≤2文
- 複雑なマルチステップタスク:
  - 1つの短い概要段落
  - ≤5個の箇条書き: 何が変わったか、どこで、リスク、次のステップ、未解決の質問
- 必要に応じてMarkdownのヘッダー、箇条書き、テーブルを使用
- 長いナラティブ段落は避け、コンパクトな構造を優先
</output_spec>

3. スコープドリフトの防止

モデルがすべきことを明示的に制約します:

<constraints>
- リクエストされたことを正確にのみ実装する
- 追加機能、コンポーネント、装飾は不要
- あいまいな場合は、最もシンプルで有効な解釈を選択
- 値を作成したり、仮定を立てたり、リクエストされていない要素を追加したりしない
</constraints>

4. あいまいさを明示的に処理

ハルシネーション(幻覚)と過度な自信を防ぎます:

<uncertainty_handling>
- 質問があいまいな場合:
  - 1〜3個の正確な明確化質問をする、または
  - ラベル付きの仮定を持つ2〜3個のもっともらしい解釈を提示
- 事実が変更された可能性がある場合: 一般的な用語で答え、不確実性を述べる
- 不確実な場合は、正確な数字や参考文献を作成しない
- 絶対的な主張ではなく「提供されたコンテキストに基づいて...」を優先
</uncertainty_handling>

5. ロングコンテキストのグラウンディング

入力が10kトークン以上の場合、再グラウンディング指示を追加します:

<long_context_handling>
- まず、リクエストに関連するキーセクションの短い内部アウトラインを作成
- ユーザーの制約を回答前に明示的に再度述べる
- 主張をセクションに固定する(「データ保持」セクションで...)
- 細かい詳細(日付、閾値、条項)を引用またはパラフレーズする
</long_context_handling>

エージェンティック・プロンプト

ツール使用ルール

<tool_usage>
以下の場合はツールを内部知識より優先:
  - 新鮮またはユーザー固有のデータ(チケット、注文、設定)
  - 特定のID、URL、またはドキュメント参照
- 可能な限り独立した読み取りを並列化
- 書き込み操作の後、以下を再度述べる: 何が変わったか、どこで、実行された検証
</tool_usage>

ユーザーアップデート

<user_updates>
次の場合のみ、簡潔なアップデート(1〜2文)を送信:
  - 新しい主要フェーズを開始
  - 計画を変える何かを発見
- ルーチン操作の説明は避ける
- 各アップデートは具体的な結果を含む(「Xを発見」、「Yを更新」)
- リクエストされたもの以上にスコープを拡張しない
</user_updates>

ハイリスク出力の自己チェック

<self_check>
機密な文脈(法律、財務、安全)での回答を最終化する前に:
- 明示されていない仮定を再スキャン
- 根拠のない数字または主張をチェック
- 非常に強い言語を柔らかくする(「常に」、「保証」)
- 仮定を明示的に述べる
</self_check>

構造化抽出

データ抽出タスクの場合、常にスキーマを提供します:

<extraction_spec>
このスキーマに正確にデータを抽出(余分なフィールドなし):
{
  "field_name": "string",
  "optional_field": "string | null",
  "numeric_field": "number | null"
}
- ソースにフィールドが存在しない場合、nullに設定(推測しない)
- 返す前にソースの欠落フィールドを再スキャン
</extraction_spec>

ウェブリサーチプロンプト

<research_guidelines>
- ウェブを参照: 時間に依存するトピック、推奨事項、ナビゲーションクエリ、曖昧な用語
- ウェブ由来の主張を持つ段落の後に引用を含める
- 主要な主張に複数のソースを使用、一次ソースを優先
- 追加の検索が答えを実質的に変えるまでリサーチを続ける
- Markdownで出力を構造化: ヘッダー、箇条書き、比較用テーブル
</research_guidelines>

例: Before/After

構造なし:

あなたは金融アナリストです。投資家向けのQ2レポートを生成してください。収益、利益率、キャッシュフローを含めてください。このデータを使用: {{DATA}}。プロフェッショナルで簡潔にしてください。

構造あり:

あなたはAcmeCorp の金融アナリストで、投資家向けのQ2レポートを生成しています。

<context>
AcmeCorpはB2B SaaS企業です。投資家は透明性と実行可能なインサイトを重視します。
</context>

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

<instructions>
1. 以下のセクションを含める: 収益成長、利益率、キャッシュフロー
2. 強みと改善が必要な領域をハイライト
3. 簡潔でプロフェッショナルなトーンを使用
</instructions>

<output_format>
- メトリクスとYoY(年ごと)変動を含む箇条書きを使用
- 改善が必要な領域の「アクション:」項目を含める
- 2〜3個の箇条書きの見通しセクションで終わる
</output_format>

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

プロンプトをモデルまたはバージョン間で適用する際:

1. モデルを切り替え、プロンプトは同じままにする — 変数を分離
2. 推論/思考の深さを固定 して、前のモデルのプロファイルに合わせる
3. 評価を実行 — 結果が良い場合、展開
4. 後退がある場合、プロンプトを調整 — 冗長性/形式/スコープ制約を調整
5. 小さな変更後に再評価 — 一度に1つの変更

クイックリファレンス

テクニック	タグパターン	ユースケース
セクションを分離	<context>, <instructions>, <data>	複雑なプロンプト全般
長さを制御	<output_spec> の単語/箇条書き制限	冗長性を防ぐ
ドリフトを防止	<constraints> と明示的な「しない」	機能のクリープ
不確実性を処理	<uncertainty_handling>	事実質問
チェーン・オブ・ソート	<thinking>, <answer>	推論タスク
抽出	JSON構造を持つ<schema>	データ解析
リサーチ	<research_guidelines>	ウェブ対応エージェント
自己チェック	<self_check>	ハイリスク領域
ツール使用	<tool_usage_rules>	エージェンティックシステム
熱心さの制御	<persistence>, <context_gathering>	エージェントの自律性
ペルソナ	<role> と行動制約	トーンとスタイル

プロンプティングテクニックカタログ

プロンプティングテクニックの包括的なカタログ。詳細、例、学術的参考文献はreferences/prompting-techniques.mdを参照してください。

テクニック	ユースケース
ゼロショット・プロンプティング	例のない直接的なタスク実行。分類、翻訳、要約
フューショット・プロンプティング	模範を通じたコンテキスト内学習。形式制御、ラベルキャリブレーション、スタイルマッチング
チェーン・オブ・ソート(CoT)	ステップバイステップの推論。算術、論理、常識推論タスク
メタプロンプティング	LLMをオーケストレーターとして機能させ、専門家プロンプトに委譲。複雑なマルチドメインタスク
自己一貫性	複数のCoTパスをサンプリング、多数決回答を選択。数学と推論の精度を向上
生成知識	最初に関連知識を生成してから回答。常識と事実QA
プロンプトチェーニング	複雑なタスクを順序的なサブタスクに分割。ドキュメント分析、マルチステップワークフロー
思考の木(ToT)	先読みとバックトラックで複数の推論分岐を探索。計画、パズル
RAG	生成する前に外部ドキュメントを取得。知識集約タスク、新鮮なデータ
ART(自動推論+ツール)	CoTでツールを自動選択してオーケストレーション。計算、検索、APIが必要なタスク
APE(自動プロンプトエンジニア)	LLMが候補プロンプトを生成してスコア。大規模なプロンプト最適化
アクティブプロンプト	不確実な例を特定し、選択的にCoTにアノテーション。適応的なフューショット
方向性刺激	ヒント/キーワードを追加して生成方向をガイド。要約、対話
PAL(プログラム支援LM)	テキストではなくコード生成で推論。数学、データ操作、シンボリックタスク
ReAct	推論トレースとツールアクションをインターリーブ。検索、QA、意思決定エージェント
Reflexion	エージェントが言語フィードバック付きで失敗に対して自己反映。反復的な改善、デバッグ
マルチモーダルCoT	2段階: 根拠生成後にテキスト+画像で回答。ビジュアル推論タスク
グラフプロンプティング	構造化グラフベースのプロンプト。ノード分類、関係抽出、グラフタスク

プロンプティング基礎

LLM設定、プロンプト要素、フォーマット、実践的な例はreferences/prompting-introduction.mdを参照してください。以下をカバーしています:

• LLM設定 — 温度、top-p、最大長、停止シーケンス、頻度/出現ペナルティ
• プロンプト要素 — 指示、コンテキスト、入力データ、出力インジケータ
• 設計のヒント — シンプルに始める、具体的に、不正確さを避ける、やることを言う(やらないことではなく)
• タスク例 — 要約、抽出、QA、分類、会話、コード生成、推論

リスクと悪用

敵対的攻撃、事実性の問題、バイアス軽減はreferences/prompting-risks.mdを参照してください。以下をカバーしています:

• 敵対的プロンプティング — プロンプトインジェクション、プロンプトリーク、ジェイルブレーク(DAN、Waluigi効果)、防御戦術
• 事実性 — 真実のグラウンディング、キャリブレーション信頼性、無知を認める パターン
• バイアス — 模範分布スキュー、模範順序効果、バランスの取れたフューショット設計

プロンプト監査/レビュー

プロンプトの監査、レビュー、改善を求められたとき、このワークフローに従ってください。完全なチェックリスト(チェックごとのリファレンス付き): prompt-audit-checklist.md

ワークフロー

1. プロンプトを完全に読む — その目的、対象モデル、展開コンテキスト(対話型チャット、エージェンティックシステム、バッチパイプライン、RAG増強)を特定
2. 8つのディメンションをウォークスルー — それぞれをチェック、重要度を記録(Critical/Warning/Suggestion):

#	ディメンション	チェック内容
1	明確性と特異性	タスク定義、成功基準、対象者、出力形式、矛盾する制約
2	構造とフォーマット	セクション分離(XMLタグ)、プロンプト臭(単一塊、混合層、ネガティブバイアス)
3	安全性とセキュリティ	制御/データ分離、プロンプト内のシークレット、インジェクション耐性、ツール権限
4	ハルシネーションと事実性	ロールフレーミング、グラウンディング、引用なしの引用、不確実性処理
5	コンテキスト管理	情報配置(中央に埋め込まれていない)、コンテキストサイズ、RAGドキュメント数、再グラウンディング
6	保守性と技術債	ハードコード値、再生成ロジック、モデルピンニング、テスト可能性
7	モデル固有のフィット	モデル固有のパラメータとトラップ(以下のモデル固有ガイドを参照)
8	評価準備	評価基準、敵対的テストケース、スキーマ強制、監視

3. レポートを生成 — 問題テーブル(ディメンション、チェック、重要度、問題、修正) + 書き直されたプロンプトまたは対象となった修正提案。チェックリストリファレンスからレポートテンプレートを使用してください。
4. 各問題について, 関連するリファレンスファイルを引用して、ユーザーが深く掘り下げることができるようにしてください。

クイック判断: どのディメンションを優先させるか

• ユーザー向けチャットボット → Safety(#3)、Hallucination(#4)、Clarity(#1)を優先
• ツール付きエージェンティックシステム → Safety(#3)、Context(#5)、Maintainability(#6)を優先
• バッチ/パイプライン → Structure(#2)、Evaluation(#8)、Maintainability(#6)を優先
• RAG増強 → Context(#5)、Safety(#3)、Hallucination(#4)を優先

一般的なミスと反パターン

3つの補完的なレイヤー — あなたのニーズに合ったものを使用してください:

カテゴリ別の深掘り — 根本原因、メカニズム、防止チェックリスト(「指示のアーキテクチャ」(2026)より):

ミスカテゴリ	主な問題	リファレンス
ハルシネーション・ロジック	あいまいさ誘発の作話、自動化バイアス、過負荷プロンプト、検証タスクの論理的失敗、ロールフレーミングなし	mistakes-hallucinations.md
構造的脆弱性	フォーマット感度(最大76pp差)、再現性危機、プロンプト臭カタログ(6つの反パターン)、思慮深さのはしご	mistakes-structure.md
コンテキスト腐食	「中央で迷う」U字型アテンション、RAG過度取得、素朴なデータ読み込み、コンテキストエンジニアリングシフト	mistakes-context.md
プロンプト技術債	再生成コードのトークン税、技術債分類(プロンプト/ハイパーパラメータ/フレームワーク/コスト)、マルチエージェント解、自動修復	mistakes-debt.md
セキュリティ	直接/間接インジェクション、ジェイルブレーク、システムプロンプトリーク(OWASP LLM07:2025)、RAGポイズニング、マルチモーダルインジェクション、敵対的サフィックス	mistakes-security.md

クイックリファレンス — 18カテゴリ分類法(MRP、リスクスコア、ケーススタディ、アクションアイテム): failure-taxonomy.md。概要を得るか、最初に対処するカテゴリを優先するために、ここから始めてください。含むもの: コントロールプレーン対データプレーンモデル、ヒューリスティックリスク採点、実世界の事件(EchoLeak CVE-2025-32711、Mata v. Avianca、Samsung影のAI)。

測定方法とテスト方法 — 評価メトリクス、CI ゲーティング、レッドティーミング、ツール: evaluation-redteaming.md。含むもの: TruthfulQA、FActScore、SelfCheckGPT、PromptBench、AILuminate、LLMアズジャッジの落とし穴、ガードレールライブラリ、オープン研究の質問。

モデル固有ガイド

各モデルファミリーは固有のパラメータ、トラップ、パターンを持っています。対象モデルのリファレンスを参照してください:

• Claude ファミリー — Opus 4.7 / 4.6 / Sonnet 4.6 / 4.5 / Haiku 4.5: 適応的思考(effort with 4.7での新しいxhigh)、task_budgetエージェンティックループの上限、4.7での従来のthinking.budget_tokens 400エラー、新しいトークナイザー(テキスト1.35×、画像3×)、4.7でのツール過少トリガリング(4.6での過度トリガリング対)、より文字通りの指示追従、サーバー側コンパクションベータ、管理エージェントメモリベータ、サイバー検証ゲート、プリフィル廃止予定、構造化出力、プロンプトキャッシング、引用、コンテキストエンジニアリング、ビジョンクロップツール、移行パス 4.5 → 4.6 → 4.7
• GPT-5 ファミリー — GPT-5 / 5.1 / 5.2 / 5.4 / 5.5: reasoning_effort(5.4/5.5の最後一マイルのノブ)、text.verbosity、名前付きツール(apply_patch)、エージェンティック熱心さテンプレート、完全性/検証契約、コンパクションAPI、phaseフィールド、結果ファーストプロンプト、パーソナリティと協調スタイル、取得予算、ミニ/ナノガイダンス、移行パス
• Gemini 3 ファミリー — Gemini 2.5/3/3.1: 温度は必ず1.0、thinking_budget対thinking_level、制約配置(プロンプト終了)、ペルソナ優先度、関数呼び出し、構造化出力、マルチモーダル、画像生成
• GPT-5.2 Specifics — コンパクションAPI コード例、ウェブリサーチエージェントプロンプト、完全なXML仕様ブロック