ロール：LLMプロンプトエンジニアリング・スペシャリスト トーン：プロフェッショナル、技術的、構造的 出力形式：Markdown（Mermaid、テーブル、コードブロックを多用） 目的：コンテキストエンジニアリングによる複雑な要件分割の最適化
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
複雑な要件定義を精度高く完遂する：段階的コンテキストエンジニアリングの実装ガイド
【ユースケース定義と課題】
大規模システムの複雑な業務ロジックを、整合性を保ちつつ各モジュールごとに段階的に分割して定義する。
入力： 粗い要件メモ、全体構造定義
出力： 整合性の取れた詳細なモジュール別仕様書（Markdown形式）
課題： 一度に全情報を入力すると、情報の希釈（Lost in the Middle）により細部の論理矛盾や出力の質の低下が発生する。
【プロンプト設計のループ】
graph TD A["設計：コンテキスト分割"] --> B["実行：段階的プロンプト注入"] B --> C["評価：整合性チェック"] C -->|矛盾発見| A C -->|合格| D["最終統合"]
設計： 全体像（Global Context）と個別詳細（Local Context）に情報を分離する。
実行： Gemini 1.5 Pro等の長文脈窓を活かしつつ、CoT（思考の連鎖）で推論ステップを明示する。
評価： 前のステップの出力内容を「制約条件」として次のステップに引き継いでいるかを検証する。
【プロンプトの実装案】
コンテキストを「構造定義（Step 1）」と「詳細設計（Step 2）」に分離し、Few-shotで出力形式を固定する手法です。
# Step 1: Global Context Structure
あなたはシステムアーキテクトです。以下の要件メモから、全体のデータ構造とモジュール間の依存関係を定義してください。
## 要件メモ
[要件内容をここにペースト]
## 出力形式 (JSON)
{
"system_name": "",
"modules": [
{"id": "M1", "name": "認証系", "dependency": []},
{"id": "M2", "name": "決済系", "dependency": ["M1"]}
]
}
---
# Step 2: Local Context Deep Dive (Sequential)
Step 1の結果に基づき、モジュール [Module_ID] の詳細設計を行います。
## 参照コンテキスト
- 全体構造: [Step 1の出力結果]
- 関連モジュール仕様: [以前のステップで生成した仕様]
## 指示
1. まず、このモジュールが他モジュールとどう連携するか思考(CoT)してください。
2. その後、以下のフォーマットでMarkdown出力してください。
## 出力例
### モジュール名: [名称]
- 機能概要: ...
- 入出力インターフェース: ...
【評価指標と誤り分析】
コンテキストを分割した際に発生しやすいリスクを、LLM-as-a-Judgeの手法で評価します。
| 評価項目 | 失敗パターン | 判定基準（1-5点） |
|---|---|---|
| 論理性（Logic） | 前後のステップで定義した変数名やIDが食い違う | ステップ間でID・用語の不一致がないか |
| 網羅性（Coverage） | 分割した結果、境界値の処理がどちらのモジュールからも漏れる | 入出力の境界条件が明文化されているか |
| 形式遵守（Format） | Markdownの階層が崩れる、JSONがパース不能になる | 指定したスキーマに100%合致しているか |
【改良後の最適プロンプト】
最新LLMの特性（Gemini 1.5 Proの「情報の関連付け能力」）を最大化するため、「コンテキストのハブ（目次）」を常に維持させるプロンプトです。
# Role
あなたは「整合性管理エージェント」です。複雑なプロジェクトを以下の3つのレイヤーで管理・記述してください。
# Layer 1: Global State (常に参照)
プロジェクトの全体像、共通定義、用語集。
# Layer 2: Thinking Process (思考プロセス)
各ステップの実行前に、以下の2点を自己分析してください。
- 前のステップで決定した事項との矛盾はないか？
- 今回の出力が次工程に与える影響は何か？
# Layer 3: Task Execution (実行)
現在、あなたは [モジュール名] の詳細化を行っています。
以下の情報を統合し、仕様書を出力してください。
## 入力データ
- 全体定義: {{global_state}}
- 既決事項: {{previous_outputs}}
- 今回の要件: {{current_task}}
## 出力形式
Markdown形式。技術的詳細を極力具体化し、未定事項は「TODO」として明記すること。
【まとめ】
実務でコンテキストエンジニアリングを運用するための3つの鉄則：
State Management（状態管理）： LLMに「今、全体のどこを処理しているか」の現在地を常に提示する。
Incremental Feedback（逐次フィードバック）： 1つの巨大なプロンプトを避け、出力Aを人間が確認（またはLLMが自己検閲）してからBに進むフローを組む。
Cross-Reference Instruction（相互参照指示）： 「前のステップのJSONキーを必ず使用せよ」といった、強固なキーワード制約を設けることで、長文脈下でのハルシネーションを抑制する。
コメント