ㅤ 本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
プロンプトから「コンテキスト設計」へ：LLMの性能を極限まで引き出す情報環境構築ガイド
【ユースケース定義と課題】
膨大な社内技術ドキュメントや多様なソースを基に、LLMが誤読や情報の欠落なく、特定形式で高度な意思決定支援を行うための環境設計。
入力の型：非構造化テキスト（ドキュメント、ログ）、メタデータ（日付、重要度）
出力の型：JSON形式（要約、アクションアイテム、リスク分析を含む構造化データ）
【プロンプト設計のループ】
graph TD A["設計: 役割と外部知識の構造化"] --> B["実行: Gemini 1.5 Pro等での推論"] B --> C["評価: 精度・形式・事実性の検証"] C -->|改善: コンテキストの純度向上| A
設計: LLMに与える「文脈（コンテキスト）」を整理し、ノイズを排除。役割（Role）と出力形式を定義する。
実行: 大規模コンテキスト（Long Context）に強いモデルを使用し、情報を処理。
評価: 出力が定義したJSONスキーマに沿っているか、事実に即しているかを自動・手動で検証。
【プロンプトの実装案】
初期段階では、単に「要約して」と頼むのではなく、思考プロセス（Chain-of-Thought）と例示（Few-shot）を明示的に組み込みます。
# Role
あなたは高度なテクニカルアナリストです。提供された複数のドキュメントを読み解き、エンジニアリングチームが即座に動ける形式で情報を抽出してください。
# Constraints
- 提供されたコンテキストのみに基づいて回答すること。
- 不明な点は「不明」と明記し、推測で補完しないこと。
- 出力は必ず指定されたJSON形式に準拠すること。
# Information Context
<documents>
[ドキュメントA: 仕様書...]
[ドキュメントB: 障害ログ...]
</documents>
# Thought Process Instructions
1. まず、各ドキュメントから「システム変更点」と「発生している問題」を箇条書きで抽出せよ。
2. 次に、それらの相関関係を分析し、根本原因の仮説を立てよ。
3. 最後に、エンジニアが取るべき次の3ステップを優先度順に決定せよ。
# Output Format
{
"summary": "一言で概要",
"analysis": {
"changes": [],
"issues": [],
"root_cause_hypothesis": ""
},
"next_steps": [
{"priority": 1, "action": ""},
{"priority": 2, "action": ""},
{"priority": 3, "action": ""}
]
}
【評価指標と誤り分析】
| 評価項目 | 失敗パターン（例） | 改善策 |
|---|---|---|
| 事実忠実性 | コンテキストにない架空の仕様を捏造する（ハルシネーション）。 | XMLタグによる情報の境界明確化、引用元の明示を指示。 |
| スキーマ準拠 | JSONが閉じられていない、またはキー名が勝手に変更される。 | 出力例の提示（Few-shot）と、JSON以外の出力を禁止する強固な制約。 |
| 推論密度 | 要約が抽象的すぎて、具体的なアクションに繋がらない。 | Step-by-stepでの思考（CoT）を強制し、思考過程を出力させる。 |
【改良後の最適プロンプト】
最新のGemini 1.5 ProやGPT-4oの特性を活かし、XMLタグを用いた「構造化コンテキスト」と「自己検閲プロセス」を組み込んだ最終案です。
# System Instruction
あなたは「情報環境設計（Context Engineering）」に基づき、多角的なデータから意思決定を支援するエージェントです。
# Context Definition
<context_rules>
- 情報源は <source_material> タグ内の情報に限定する。
- 専門用語の定義は <glossary> を参照すること。
</context_rules>
<glossary>
- サービスダウン: APIレスポンスが500系を返す状態
- レイテンシ: リクエストからレスポンスまでのミリ秒
</glossary>
<source_material>
{{INPUT_DATA}}
</source_material>
# Task Execution Pipeline
1. <extraction_phase>: ソースから重要数値と日付をすべて抽出。
2. <logical_check>: 抽出したデータ間に矛盾がないか確認。
3. <final_output>: 以下のJSONスキーマで出力。
# JSON Schema
```json
{
"status": "critical | warning | stable",
"evidence_based_summary": "...",
"logical_reasoning": "なぜその結論に至ったかの論理プロセス",
"action_items": []
}
Feedback Loop
回答の最後に、自身の回答がソース資料に対してどれだけ忠実か、10点満点で自己採点し、その理由を1行で添えてください。 “`
【まとめ】
実務でプロンプトを運用するための3つの鉄則：
情報を「混ぜない」: 役割、ルール、知識、思考手順をXMLタグ等で明確に分離して与える。
「思考の余白」を与える: 即座に回答させず、内部的な推論ステップ（思考プロセス）を記述させる。
環境を固定する: 特定のモデル、特定のコンテキスト量で安定して動作するよう、Few-shotで挙動を型に嵌める。
