{ “focus”: “Context Engineering for LLMs”, “techniques”: [“CoT”, “Structured Output”, “Few-shot”, “Context Grounding”], “target_models”: [“Gemini 1.5 Pro”, “GPT-4o”], “version”: “1.0.0” } 本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
プロンプトから「コンテキスト設計」へ：外部知識を統合する高精度情報抽出エンジンの構築
【ユースケース定義と課題】
膨大な社内資料をコンテキストとして入力し、事実誤認を排除した上で「結論・根拠・課題」を構造化したJSON形式で抽出する。
入力型: 非構造化テキスト（会議録、技術文書等）
出力型: 厳密なスキーマに基づくJSON
【プロンプト設計のループ】
graph TD A["設計: コンテキストの構造化"] --> B["実行: 推論と抽出"] B --> C["評価: 事実整合性と書式"] C -->|改善: 制約の追加| A
設計: 単なる命令ではなく、LLMが情報を処理しやすいようタグ（
<context>等）で情報を分節化。実行: Chain-of-Thoughtを用い、回答前にコンテキストから証拠（Evidence）を引用させる。
評価: 出力されたJSONのパース可否と、ソース文書に存在しない情報の混入（ハルシネーション）をチェック。
【プロンプトの実装案】
# Role
あなたは高度な情報分析官です。提供されたコンテキストのみに基づき、以下のタスクを遂行してください。
# Task
入力された資料から重要な事実を抽出し、指定のJSONフォーマットで要約してください。
# Constraints
- コンテキストに記載のない情報は絶対に含めない（Know-nothing制約）。
- 回答は必ず有効なJSONオブジェクトのみを出力する。
- 抽出する際は、まず「思考プロセス」として、どの文言を根拠にしたかをリストアップすること。
# Context
<document>
{{INPUT_TEXT}}
</document>
# Output Format
{
"thought_process": "抽出の根拠となった箇所の抜粋",
"summary": {
"conclusion": "結論",
"evidence": ["根拠1", "根拠2"],
"next_steps": ["アクション1", "アクション2"]
}
}
# Example
Input: "プロジェクトAは予算不足により来月から3ヶ月中断する。再開には追加承認が必要。"
Output: {
"thought_process": "予算不足、来月から3ヶ月中断、再開には追加承認が必要、という記述を確認。",
"summary": {
"conclusion": "プロジェクトAの一時中断",
"evidence": ["予算不足", "来月から3ヶ月間"],
"next_steps": ["再開のための追加承認取得"]
}
}
【評価指標と誤り分析】
| 評価項目 | 評価基準 (LLM-as-a-Judge) | 失敗パターン |
|---|---|---|
| 事実整合性 | 抽出された全項目がソース内に存在するか(1-5) | 文書外の一般知識による補完 |
| 書式適合性 | JSONとして正しくパース可能か(0 or 1) | Markdownのコードブロック記号の混入 |
| 網羅性 | 重要なネクストアクションが漏れていないか(1-5) | 些末な事実のみにフォーカスする |
誤り分析: 特に「事実誤認（ハルシネーション）」は、LLMが親切心から「推測」を混ぜることで発生します。これを防ぐには「思考プロセスの分離（CoT）」と「抽出元テキストの明示」が不可欠です。
【改良後の最適プロンプト】
Gemini 1.5 Pro等の長文コンテキストモデルを想定し、システム命令を強化したバージョンです。
# System Instructions
- あなたは情報の真実性を最優先する抽出エンジンです。
- Userが提供する <source_material> タグ内のテキストのみを情報源としてください。
- もし情報源から回答を生成できない場合は、{"error": "Insufficient information"} と出力してください。
# Processing Protocol
1. **Analyze**: <source_material> を精読し、キーポイントを特定する。
2. **Verify**: 特定したポイントが明示的に記載されているか再確認する。
3. **Format**: 指定されたJSONスキーマに流し込む。
# Input Data
<source_material>
{{CONTEXT_DATA}}
</source_material>
# Response Schema (Strict JSON)
{
"metadata": {
"source_verified": boolean,
"confidence_score": 0.0-1.0
},
"extracted_data": {
"key_decision": "string",
"supporting_facts": ["string"],
"risk_factors": ["string"]
}
}
# Output
（思考プロセスを隠し、JSONのみを出力）
【まとめ】
実務でコンテキストエンジニアリングを運用するための3つの鉄則：
境界の明示: コンテキストを
<tag>で囲み、LLMが「どこまでが事実か」を物理的に理解できるようにする。思考の外部化:
thought_processフィールドを設け、LLMに「証拠のセルフチェック」を行わせる。スキーマの固定: 自由記述を避け、JSONスキーマを明示することで、後続のシステム（BIツールやDB）との連携を担保する。
