「指示」から「環境」へ：コンテキストエンジニアリングによるLLM回答精度の極大化手法

Tech

{ “expert_role”: “Prompt Design Expert”, “focus”: “Context Engineering & LLM Optimization”, “target_models”: [“Gemini 1.5 Pro”, “GPT-4o”, “Claude 3.5 Sonnet”], “content_type”: “Technical Framework & Practical Prompt” }

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

「指示」から「環境」へ：コンテキストエンジニアリングによるLLM回答精度の極大化手法

【ユースケース定義と課題】

社内文書を基に、技術的な意思決定を支援するための根拠に基づいた技術選定レポートをMarkdown形式で生成する。

  • 入力の型: 複数の技術ドキュメント（PDF/テキスト）、比較要件

  • 出力の型: Markdown（背景、比較表、推奨案、リスク、根拠URLの構成）

  • 課題: 文脈の欠落による「一般的な一般論」への着地、および参照情報の混同（幻覚）。

【プロンプト設計のループ】

graph TD
    A["コンテキスト構造化設計"] --> B["構造化インプット実行"]
    B --> C["事実整合性 & 形式評価"]
    C -->|情報の重み付け不足| A
    C -->|形式不備| B
    C -->|合格| D["本番運用"]

  • 設計: LLMが「何を優先すべきか」を判断できる情報階層（重要度）を定義。

  • 実行: 役割、制約、参照データ、思考プロセス（CoT）を分離して流し込む。

  • 評価: 提示された根拠が一次ソースに存在するか、出力形式がパース可能かを検証。

【プロンプトの実装案】

# Role

あなたは上級ITアーキテクトです。提供された[Reference Data]のみを根拠に、客観的な技術比較レポートを作成してください。

# Constraints


- 外部知識を使用せず、提供されたデータに記載がない場合は「不明」と明記すること。

- 回答は必ず指定の[Format]に従うこと。

- 意思決定のバイアスを避けるため、各オプションのメリット・デメリットを同量書くこと。

# Reference Data

<doc_1>
(ここに技術仕様Aの内容)
</doc_1>
<doc_2>
(ここに技術仕様Bの内容)
</doc_2>

# Thought Process (Chain-of-Thought)

以下の手順で思考してください：

1. 各ドキュメントから「コスト」「スケーラビリティ」「セキュリティ」の3点を抽出する。

2. 抽出したデータを基に比較表を作成する。

3. プロジェクト要件（[Requirement]）に照らし合わせ、最適な案を論理的に導き出す。

# Format

## 1. 概要

## 2. 技術比較表

| 項目 | A | B |
|---|---|---|...
## 3. 推奨案とその理由

## 4. 残存リスクと対策

## 5. 参照ソース（ドキュメント名）

# Output

【評価指標と誤り分析】

評価項目 評価指標 (LLM-as-a-Judge) 失敗パターン（分析） 対策
事実整合性 根拠がReference内に存在するか (1-5) 外部知識による補完（ハルシネーション） 「外部知識禁止」の強調とXMLタグ分離
構造遵守 指定のMarkdownの見出しがあるか (0/1) 表組みの崩れ、セクションの欠落 フォーマット例のFew-shot追加
論理的妥当性 推奨案が比較結果と矛盾していないか (1-5) 結論が先にありきで、比較が形骸化 思考プロセス(CoT)の強制出力を指示

【改良後の最適プロンプト】

# 役割

プロフェッショナル・テクニカル・ライター

# ミッション

以下の<context>セクションの情報のみを用いて、要件に合致する技術評価レポートを作成せよ。

# コンテキストエンジニアリング（情報構造）

<context>
  <constraints>

    - 根拠：<source_data>タグ内の情報のみを使用。

    - 禁止事項：一般的知識の混入、推測によるデータ補完。

    - 言語：日本語。
  </constraints>
  <source_data>
    {{SOURCE_TEXT_HERE}}
  </source_data>
  <user_requirements>
    {{USER_REQUIREMENTS_HERE}}
  </user_requirements>
</context>

# 実行指示


1. ステップバイステップで分析：

   - まず、<source_data>から要件に関連する事実を箇条書きで抜き出してください。

   - 次に、抜き出した事実に基づき、要件に対する適合スコアを算定してください。

2. 最終回答の生成：

   - 以下の[OUTPUT_STRUCTURE]に従って出力してください。

# [OUTPUT_STRUCTURE]

（ここに厳密なMarkdownテンプレートを記述）

# 思考の開始：

まずは提供されたデータから事実を抽出することから始めます。

【まとめ】

  1. タグによる情報の隔離: <tags> を使用して、指示、制約、参照データを明確に分離する。LLM（特にGemini 1.5 Pro）は構造化されたコンテキストをより正確に処理できる。

  2. プロセスの外部化: 「まず事実を抽出せよ」といった中間ステップを明示することで、直接回答させるよりも推論精度が飛躍的に向上する。

  3. 「知らない」を許容する: 「データにない場合は不明と書く」という逃げ道（Safety Exit）を設けることが、ハルシネーション防止の最大の防御策となる。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました