本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
複雑な要件を段階的に処理する「コンテキスト分割プロンプティング」の設計指針
【ユースケース定義と課題】
膨大な技術資料から特定要件を抽出し、矛盾のないシステム要件定義書を生成する。情報の埋没（Lost in the Middle）と論理的不整合の回避が課題。 入出力の型：Markdown（構造化文書）
【プロンプト設計のループ】
graph TD A["要件の分解とタグ付け"] --> B["推論ステップの明示"] B --> C["中間成果物の自己検証"] C -->|論理矛盾あり| A
設計: 巨大な入力を
ContextConstraintTaskの3要素に分解し、XMLタグで構造化。実行: LLMに「まず要約せよ」「次に矛盾を探せ」と段階的な指示を出す。
評価: 生成された定義書が、元の入力資料の全要件を網羅しているかをスコアリング。
【プロンプトの実装案】
# Role
あなたは複雑なエンタープライズシステムの要件定義に精通したITアーキテクトです。
# Task
提供された「断片的な業務フロー」から、一貫性のある「システム要求仕様書」を作成してください。
# Constraints
- プロセスを3段階に分けて思考してください。
- 各ステップの結果を [Step X] として明記すること。
- 不明点や矛盾点は「未定義事項」としてリストアップすること。
# Context
<input_documents>
{{ここに大量の資料や箇条書きを入力}}
</input_documents>
# Execution Process (Chain-of-Thought)
Step 1: 入力資料から「登場人物」「入出力データ」「例外処理」をすべて抽出してください。
Step 2: 抽出した要素間の依存関係を整理し、論理的な矛盾（例：入力がないのに出力がある等）を特定してください。
Step 3: 上記を踏まえ、Markdown形式で要求仕様書を生成してください。
# Output Format
[Step 1: 構成要素の抽出]
...
[Step 2: 論理整合性チェック]
...
[Step 3: システム要求仕様書]
# 1. 概要
...
【評価指標と誤り分析】
失敗パターン：
情報の蒸発: 入力の中盤にある重要な制約が、出力の仕様書から抜け落ちる。
指示の混濁: ステップ分けを無視して、いきなり最終成果物を出力しようとする（最新のFlashモデル等で発生しやすい）。
LLM-as-a-Judge 採点基準：
| 評価項目 | 採点基準 (1-5) | 判定理由の記述 |
|---|---|---|
| 要件網羅性 | 入力に含まれる全キーワードが反映されているか | input_documentsとの照合 |
| 論理一貫性 | Step 1, 2の内容がStep 3に反映されているか | 推論プロセスの追跡 |
| フォーマット遵守 | 指定したMarkdown構造が維持されているか | 構文解析の成否 |
【改良後の最適プロンプト】
最新のGemini 1.5 Pro等の長いコンテキスト窓を活かしつつ、注意力を維持させるために「逆説的検証（Chain-of-Verification）」を組み込んだ設計。
# Role: Senior Systems Architect
# Task: High-Fidelity Requirement Structuring
# Input Data
<context>
{{Input_Text}}
</context>
# Instructions
1. **Analyze**: <context>内の情報を精査し、全要件を最小単位（Atom）に分解せよ。
2. **Verify**: 分解した各要件について、相互に矛盾がないか、または情報が不足していないか検証せよ。
3. **Draft**: 検証済みの要件のみを用いて、システム仕様書を構成せよ。
# Self-Correction Rule
もし<context>に記載のない情報を補完（ハルシネーション）した場合は、その箇所を [Assumption] と明記すること。
# Output
各ステップの結果を、以下のXMLタグで囲って出力してください。
<analysis_phase> ... </analysis_phase>
<verification_phase> ... </verification_phase>
<final_output> ... </final_output>
【まとめ】
タグによる聖域化:
contextやtaskをXMLタグで囲み、LLMに「どこがデータでどこが指示か」を物理的に理解させる。思考の外部化: 最終回答の前に必ず「分析」と「検証」のステップを出力させ、LLMの作業メモリをクリーンにする。
ハルシネーションのラベリング: AIが推測で書くことを禁止するのではなく、「推測した箇所にラベルを貼らせる」ことで実用性を担保する。
