本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
複雑な要件を構造化する「階層的コンテキストエンジニアリング」の実装ガイド
【ユースケース定義と課題】
乱雑な会議録から「ビジネス要件定義書」を生成する。高密度な情報を一度に与えると重要項目の欠落や論理矛盾が発生する。
入力型：非構造化テキスト（議事録、メモ）
出力型：Markdown（要件定義書）および JSON（システム連携用メタデータ）
【プロンプト設計のループ】
graph TD A["設計: 階層構造の定義"] --> B["実行: 段階的推論のトリガー"] B --> C["評価: 精度・網羅性の検証"] C -->|改善: 制約条件の追加| A
設計: 全体のゴールを分解し、LLMが処理しやすい「小さなコンテキスト」の塊（モジュール）を定義します。
実行: CoT（思考の連鎖）を用いて、情報の抽出・整理・構造化を段階的に行わせます。
評価: 生成された出力がビジネス要件として成立しているか、ハルシネーションがないかを定量・定性で評価します。
【プロンプトの実装案】
# Role あなたはエンタープライズITコンサルタントです。提供された乱雑な情報を整理し、エンジニアが実装可能なレベルの要件定義書を作成します。 # Step-by-Step Instructions (Chain-of-Thought) 1. **事実抽出**: 入力テキストから「やりたいこと（機能）」「制約（期限・予算・技術）」「登場人物」を箇条書きで抽出してください。 2. **依存関係分析**: 各機能が互いにどう影響し合うか、ロジックの矛盾がないかを確認してください。 3. **構造化出力**: 抽出した情報を基に、指定のMarkdown形式で要件定義書を生成してください。 # Constraints - 不明な点は勝手に補完せず「要確認事項」としてリストアップすること。 - 専門用語は一貫性を持たせること。 # Example (Few-shot) Input: "決済機能が欲しい。あとスマホで見たい。来月までにはやりたい。" Output: - 機能: 決済処理、レスポンシブ対応 - 期限: 翌月末 - 懸念: 決済手段の詳細が不明 --- # Input Data [ここに議事録やメモを貼り付け]
【評価指標と誤り分析】
| 評価項目 | 採点基準 (1-5) | 失敗パターン |
|---|---|---|
| 網羅性 | 入力に含まれる主要な要求がすべて反映されているか | 特定の要望（例：セキュリティ要件）が無視される |
| 論理一貫性 | 前後の記述で矛盾（例：期限の食い違い）がないか | 冒頭と末尾で納期が異なるハルシネーション |
| 形式遵守 | Markdown/JSONのフォーマットが正しいか | JSONの閉じカッコ不足、Markdownの階層崩れ |
誤り分析のヒント: 出力が不安定な場合は、一度に「MarkdownとJSON」を出力させず、まず「中間思考（CoT）」を出力させてから、最後に形式を整えるように指示を分割してください。
【改良後の最適プロンプト】
# Role
IT要件定義のスペシャリスト
# Task
以下の「断片的なメモ」を、エンジニアがそのまま設計に移れる「要件定義ドキュメント」に変換してください。
# Process (Thinking Process required)
1. まず、提供された情報を [Entities], [Functional Requirements], [Non-Functional Requirements], [Constraints] に分類して思考してください。
2. 分類に基づき、以下のフォーマットでMarkdown出力してください。
3. 最後に、開発の優先度を「高・中・低」でプロパティ化したJSONを出力してください。
# Output Format
## 1. プロジェクト概要
## 2. 機能要件
## 3. 非機能要件・制約
## 4. 要確認事項
```json
{
"project_priority": "High",
"key_features": []
}
Input
[ここに具体的な業務要件を注入] “`
【まとめ】
情報の「小分け」提供: 長大な入力はLLMの注意を散漫にします。情報を意味のあるブロック（コンテキスト）に分けて処理させなさい。
思考の強制（CoT）: 直接的な出力を求めず「まず分類せよ」「次に矛盾を探せ」と、推論のステップを明示的に踏ませなさい。
型への落とし込み: JSON等の構造化データを出力させる際は、必ずMarkdownのドキュメントとセットで出力させ、整合性をLLM自身に確認させなさい。
