複雑な要件を段階的に処理する「コンテキスト分割プロンプティング」の設計指針

Tech

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

複雑な要件を段階的に処理する「コンテキスト分割プロンプティング」の設計指針

【ユースケース定義と課題】

膨大な技術資料から特定要件を抽出し、矛盾のないシステム要件定義書を生成する。情報の埋没（Lost in the Middle）と論理的不整合の回避が課題。 入出力の型：Markdown（構造化文書）

【プロンプト設計のループ】

graph TD
A["要件の分解とタグ付け"] --> B["推論ステップの明示"]
B --> C["中間成果物の自己検証"]
C -->|論理矛盾あり| A

  1. 設計: 巨大な入力をContext Constraint Taskの3要素に分解し、XMLタグで構造化。

  2. 実行: LLMに「まず要約せよ」「次に矛盾を探せ」と段階的な指示を出す。

  3. 評価: 生成された定義書が、元の入力資料の全要件を網羅しているかをスコアリング。

【プロンプトの実装案】

# 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>

【まとめ】

  1. タグによる聖域化: contextやtaskをXMLタグで囲み、LLMに「どこがデータでどこが指示か」を物理的に理解させる。

  2. 思考の外部化: 最終回答の前に必ず「分析」と「検証」のステップを出力させ、LLMの作業メモリをクリーンにする。

  3. ハルシネーションのラベリング: AIが推測で書くことを禁止するのではなく、「推測した箇所にラベルを貼らせる」ことで実用性を担保する。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました