本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
プロンプトからコンテキストへ：LLMの情報環境設計による高度要約の最適化
【ユースケース定義と課題】
膨大な技術文書（数百ページ）から特定要件を抽出し、ビジネス影響度を構造化データとして出力するタスク。単一指示では情報欠落や幻覚が発生しやすい。
入力型：非構造化テキスト（PDF抽出テキスト、Markdown）
出力型：JSON (Schema準拠)
【プロンプト設計のループ】
graph TD A["設計: 情報環境の構造化"] --> B["実行: 長文コンテキスト処理"] B --> C["評価: 抽出精度とJSON整合性"] C -->|改善: ネガティブ制約の追加| A
設計: 単なる命令ではなく、LLMが参照すべき「事実（Grounding）」と「思考の枠組み」を分離して配置。
実行: Gemini 1.5 Pro等の長文コンテキスト窓を活用し、ドキュメント全量を高密度に処理。
評価: 抽出された項目が元文献のどこに基づいているか（ソース参照）を検証。
【プロンプトの実装案】
# Role
あなたはエンタープライズITアーキテクトです。提供された技術文書を分析し、経営層が判断可能なビジネスリスクと技術的制約を抽出してください。
# Constraints
- 出力は必ず指定されたJSON形式に準拠すること。
- 「不明な点」は推測せず、"unknown" と記載すること。
- 各抽出項目には、根拠となる原文のセクション番号を付与すること。
# Step-by-Step Process (Chain-of-Thought)
1. 文書全体をスキャンし、システム構成に関する記述をすべて特定する。
2. 特定された構成から、可用性とセキュリティに関する制約を抽出する。
3. 抽出した制約が事業継続に与えるインパクトを3段階で評価する。
4. 最終的な結果をJSON形式で構造化する。
# Input Data
[ここに技術文書のテキストをペースト]
# Output Format
{
"analysis_report": {
"system_overview": "...",
"constraints": [
{
"item": "...",
"risk_level": "High/Medium/Low",
"source": "Section X.X"
}
]
}
}
【評価指標と誤り分析】
LLMが「もっともらしい嘘（幻覚）」をつく、またはJSONのパースに失敗するケースを以下の基準で評価します。
| 評価指標 | 測定内容 | 失敗時の対策 |
|---|---|---|
| Faithfulness（忠実性） | 抽出内容がソース文献に存在するか | ソースの引用（セクション番号）を必須化する |
| Format Integrity | JSONがプログラムでパース可能か | スキーマ定義をFew-shotで強調する |
| Information Density | 重要なリスクを見落としていないか | 「他にリスクはないか？」と再考を促すステップを追加 |
【改良後の最適プロンプト】
コンテキストエンジニアリングの視点を取り入れ、「情報の優先順位」と「検証プロセス」を埋め込んだ最強のプロンプトです。
# System Instruction
あなたは高度なコンテキスト解析エンジンです。以下の「Contextual Grounding Rule」に従い、入力を処理してください。
# Contextual Grounding Rule
1. 引用のない主張を禁止する。
2. 文脈の矛盾（A節とB節の不整合）を発見した場合は、"conflict_detected" フィールドに明記する。
3. 技術用語は定義済みの用語集（もしあれば）に準拠する。
# Context (Reference Documents)
<document>
{{INPUT_TEXT}}
</document>
# Task Execution
1. <document> 内から「インフラ制約」に該当する箇所を抽出。
2. 各制約に対し、以下のJSONスキーマで出力。
# Output Schema
```json
{
"critical_constraints": [
{
"id": "integer",
"summary": "string",
"business_impact": "string",
"evidence": "string (quote from text)"
}
],
"conflict_detected": ["string"]
}
“`
【まとめ】
実務でLLMのパフォーマンスを最大化するための3つの鉄則：
「命令」より「情報環境」: 優れた命令文を書くより、LLMが迷わないように情報を構造化（タグ付け、セクション分け）して渡すことが重要。
自己検証プロセスの組み込み: プロンプト内で「矛盾をチェックせよ」「根拠を引用せよ」と命じることで、幻覚率を劇的に下げられる。
評価の自動化（LLM-as-a-Judge）: 人間が全て確認するのではなく、評価用プロンプトを用意して一貫性を担保する。
