ユーザーは「プロンプトエンジニアリング」から「コンテキストエンジニアリング」へのパラダイムシフトをテーマにした、実務的なLLM活用ガイドを求めている。
最新のLLM（Gemini 1.5 Proの長いコンテキスト窓など）を前提とし、単なる命令文の工夫ではなく、入力情報の構造化（情報環境設計）に焦点を当てる。
構成指示に従い、メタデータ、バッジ、H1、各セクションを厳密に配置。
「コンテキストエンジニアリング」の具体例として、複雑な社内規定からの構造化データ（JSON）抽出をターゲットタスクに設定。
言語は日本語、トーンはプロフェッショナルかつ実務的。
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
コンテキストエンジニアリング：構造化データ抽出の精度を極限まで高める情報環境設計手法
【ユースケース定義と課題】
複雑な非構造化ドキュメント群を解析し、後続システムで利用可能な高精度JSON形式へ構造化する。文脈の欠落やフォーマット崩れが主な課題。
入力形式： テキスト（PDF抽出ログ、会議録、社内規定など）
出力形式： 厳密に定義されたJSONスキーマ
【プロンプト設計のループ】
graph TD A["コンテキスト設計"] --> B["実行・推論"] B --> C["評価・分析"] C -->|改善: タグ付け/メタデータ付与| A
コンテキスト設計: 単なる命令文（指令）だけでなく、データの意味をLLMが理解しやすいよう、XMLタグやメタデータを用いて入力情報を構造化する。
実行・推論: Chain-of-Thought（思考プロセス）を強制し、いきなり答えを出さず、ステップバイステップで情報の関連性を整理させる。
評価・分析: 期待したスキーマとの乖離、事実誤認（幻覚）を特定し、入力データの提示順序や属性情報の付与方法を改善する。
【プロンプトの実装案】
# Role
あなたは高度なデータ構造化エンジニアです。以下の[Context]に含まれる情報を解析し、指定された[Schema]に従ってJSONを出力してください。
# Context Engineering Guidelines
- 入力データは <document> タグで囲まれています。
- 各ドキュメントには [ID][Source][Timestamp] のメタデータが付与されています。
- 複数のドキュメント間で情報が矛盾する場合、[Timestamp] が最新のものを優先してください。
# Task Instructions
1. <thought> タグ内で、抽出対象となる要素を特定し、根拠となる一文を引用してください。
2. 欠落している項目がある場合は、null ではなく "Not Specified" と記述してください。
3. 出力は純粋なJSONブロックのみとし、解説は不要です。
# Schema
{
"document_summary": "string",
"key_entities": ["string"],
"action_items": [{"task": "string", "due_date": "string"}],
"priority_score": "number (1-5)"
}
# Input Data
<document>
[ID: DOC-001]
[Source: Internal Policy]
[Timestamp: 2024-05-10]
内容は...（以下、具体的なドキュメント本文）
</document>
# Output
<thought>
【評価指標と誤り分析】
| 評価項目 | 評価基準（LLM-as-a-Judge） | 失敗時の対策 |
|---|---|---|
| Schema整合性 | 出力されたJSONが定義された型を完全に遵守しているか | Few-shotに「誤った例と修正例」を追加 |
| Grounding | 抽出された情報が提供されたコンテキスト内に存在するか | 根拠となる引用（Citation）を思考プロセスに含める |
| 優先順位判断 | メタデータ（Timestamp等）に基づき、最新情報を選択しているか | 優先順位の判定ロジックを命令文に明文化する |
典型的な失敗パターン
ハルシネーション: コンテキストにない日付や数値を「推測」で埋めてしまう。
コンテキスト無視: 過去の学習データに基づいた一般的な知識で回答を上書きしてしまう。
【改良後の最適プロンプト】
# System Role Data Architect focused on high-fidelity extraction. # Operational Environment (Context Engineering) - 構造化入力: 情報を <metadata>, <content>, <reference> のタグで分離。 - 知識の境界: 提供された <context> タグ内の情報のみを使用すること。外部知識は厳禁。 # Response Protocol 1. Analyze: <context> 内の重要情報をマッピング。 2. Verification: 抽出したデータが原文のどこに基づいているかセルフチェック。 3. Final Output: JSON形式で出力。 # Execution (Example) User: [データ入力] Assistant: <thought> 1. 抽出対象の特定: ... 2. メタデータの確認: ... 3. 整合性チェック: ... </thought>
【まとめ】
「命令」より「環境」を整える: 指示文を長くするのではなく、入力データの構造（タグ付け、メタデータ付与）に時間をかける。
思考の足跡を強制する:
thoughtタグやステップバイステップの指示により、LLMの内部推論を外出しさせ、エラーの発生箇所を特定しやすくする。スキーマ制約と検証をセットにする: 期待する型を明示するだけでなく、LLM自身に「自分の出力がスキーマに合っているか」を最終確認させるステップを組み込む。
