本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
複雑な要件を階層化する：コンテキストエンジニアリングによる高精度構造化プロンプトの設計
【ユースケース定義と課題】 膨大な非構造化データ（議事録や論文）から、複数の制約（専門用語の保持、特定様式、依存関係の整理）を維持したまま、高精度な技術要件定義書を生成する。
入力：非構造化テキスト（Markdown形式）
出力：構造化された技術要件定義書（Markdown、一部JSON埋め込み）
【プロンプト設計のループ】
graph TD A["設計"] --> B["実行"] B --> C["評価"] C -->|改善| A
設計: 要件を「背景」「制約」「思考プロセス」「出力形式」のレイヤーに分割。
実行: 最新のLLM（Gemini 1.5 Pro等）で推論を行い、長いコンテキストを処理。
評価: 出力項目の漏れ、フォーマットの不整合、論理的飛躍をチェック。
【プロンプトの実装案】
# Role あなたはITアーキテクトおよびシニアテクニカルライターです。 複雑なドキュメントから情報を抽出し、論理的な要件定義書を作成するエキスパートです。 # Task 提供された「プロジェクトメモ」を読み、以下の手順（Chain-of-Thought）に従って「技術要件定義書」を生成してください。 # Constraints - 専門用語は変えずにそのまま使用すること。 - 不明な点は推測せず「検討事項」としてリストアップすること。 - 出力はMarkdown形式とし、データ型定義のみJSONブロックを用いること。 # Process (CoT) 1. 提供されたテキストから「機能要件」「非機能要件」「制約事項」を箇条書きで抽出する。 2. 抽出した要素間の依存関係を整理する。 3. 規定のフォーマットに当てはめ、文章を技術的に洗練させる。 # Example (Few-shot) Input: "ログインはOAuth2.0を使いたい。レスポンスは200ms以内。" Output: - 機能要件: 外部IDPによる認証（OAuth2.0準拠） - 非機能要件: パフォーマンス（応答速度 200ms以内） # Input Data [ここにプロジェクトメモをペースト] # Output Format ## 1. 概要 ## 2. 要件詳細 ...
【評価指標と誤り分析】
| 評価項目 | 採点基準 (1-5) | 失敗パターン（例） |
|---|---|---|
| 指示遵守 | 5: 全制約を遵守 / 1: 制約を無視 | JSON形式がMarkdownに混ざる |
| 情報の網羅性 | 5: 全要件を網羅 / 1: 重要な欠落あり | 非機能要件が丸ごと脱落する |
| 論理的一貫性 | 5: 矛盾なし / 1: 前後で矛盾 | 手順1と手順3の結果が食い違う |
| 幻覚(Hallucination) | 5: 事実のみ / 1: 捏造あり | メモにない納期を勝手に設定する |
誤り分析のポイント：
様式崩れ: 長文出力時に後半のフォーマットが崩れる場合は、出力トークン制限やコンテキストの霧散が原因。
指示の競合: 「簡潔に」と「詳細に」を同時に指示すると、LLMが中途半端な出力を出す傾向がある。
【改良後の最適プロンプト】
# System Role You are a context engineering expert. Analyze the input carefully and execute the following multi-step instructions. # Instruction Layer 1. [Analyze]: Read the input and identify "Functional", "Non-functional", and "Technical Debt". 2. [Structure]: Organize findings into a hierarchical Markdown structure. 3. [Verify]: Cross-reference the output with the input to ensure zero hallucination. # Specific Constraints - Language: Japanese - Tone: Professional / Technical - Format: - Headers: Use #, ##, ### - Data Schema: Use ```json - Prohibitions: Do NOT create information not present in the input. # Execution (Chain-of-Thought) Think step-by-step: Step 1. What are the core requirements? Step 2. Are there any conflicting constraints? Step 3. How should the JSON schema look based on these requirements? # Input [PASTE DATA HERE] # Final Output Delivery Generate the document starting from the title "## 技術要件定義書".
【まとめ】 実務でプロンプトを運用するための3つの鉄則：
段階的命令（Layered Instruction）: 「分析→抽出→整形」のように、LLMの思考ステップを明示的に分ける。
型定義の厳格化: Markdownの見出しレベルやJSONのキー名を事前に指定し、パースエラーを防ぐ。
ネガティブ制約の活用: 「～しないでください」「推測しないでください」という禁止事項を明文化し、精度を安定させる。
コメント