複雑な要件定義を精度高く完遂する：段階的コンテキストエンジニアリングの実装ガイド

Tech

ロール：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つの鉄則：

  1. State Management（状態管理）： LLMに「今、全体のどこを処理しているか」の現在地を常に提示する。

  2. Incremental Feedback（逐次フィードバック）： 1つの巨大なプロンプトを避け、出力Aを人間が確認（またはLLMが自己検閲）してからBに進むフローを組む。

  3. Cross-Reference Instruction（相互参照指示）： 「前のステップのJSONキーを必ず使用せよ」といった、強固なキーワード制約を設けることで、長文脈下でのハルシネーションを抑制する。

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

コメント

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