複雑な要件を制するコンテキストエンジニアリング：段階的分割によるLLM出力の最適化

Tech

{ “status”: “optimized”, “technique”: [“Context Engineering”, “Chain-of-Thought”, “Few-shot Prompting”], “model_compatibility”: [“Gemini 1.5 Pro”, “GPT-4o”], “output_format”: “Professional Technical Report” }

本記事は**Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）**です。 # 複雑な要件を制するコンテキストエンジニアリング：段階的分割によるLLM出力の最適化 ## 【ユースケース定義と課題】 膨大な非構造化ドキュメント（社内規定等）から、構造化された要件定義書を生成する。長文ゆえの制約無視や情報の欠落が最大の課題。 – **入力型**: プレーンテキスト（非構造化データ） – **出力型**: Markdown / JSON（構造化データ） ## 【プロンプト設計のループ】 

graph TD
A["設計: 要件のモジュール化"] --> B["実行: ステップ別の逐次生成"]
B --> C["評価: 整合性チェック"]
C -->|改善: コンテキストの再注入| A

1. **設計**: 全体のタスクを「抽出」「分類」「構造化」の3フェーズに分割。 2. **実行**: 前のステップの出力を次の入力に連結（Chaining）して精度を維持。 3. **評価**: 出力された各項目がソースコード（元データ）に存在するかを検証。 ## 【プロンプトの実装案】 コンテキストを分割し、思考プロセス（CoT）を強制するプロンプト例です。 

# Role

あなたは複雑なドキュメントを解析し、エンジニアが即座に実装可能な要件定義書を作成する専門家です。

# Task

提供された資料から「業務フロー」と「例外処理」を抽出してください。
いきなり結果を出力せず、以下のステップに従ってください。

# Steps


1. 資料の中から「条件分岐（もし〜なら）」に関連する記述をすべて箇条書きでリストアップせよ。

2. リストアップした内容を、正常系と異常系に分類せよ。

3. 最終的な要件を、以下のMarkdown形式で出力せよ。

# Constraint


- 専門用語はそのまま保持すること。

- 元データにない推測は「要検討」として明記すること。

# Few-shot Example

Input: 「申請者が承認者の場合、自動承認とする。ただし役員の場合は例外。」
Step 1:

- 申請者が承認者の場合は自動承認

- 役員の場合は例外
Step 2:

- 正常系: 申請者＝承認者での自動承認

- 異常系: 役員による申請
Output:
| 分類 | 条件 | 処理 |
| :--- | :--- | :--- |
| 正常系 | 申請者＝承認者 | 自動承認 |
| 異常系 | 申請者が役員 | 別途個別承認 |

# Input Data

[ここに解析対象のテキストを貼り付け]

## 【評価指標と誤り分析】 コンテキストが複雑化すると、LLMは「中だるみ」を起こし、中盤の制約を無視する傾向があります。 | 評価項目 | 採点基準 (1-5) | 失敗パターン | | :— | :— | :— | | **情報の網羅性** | 元データの重要キーワードが全て含まれているか | 特定の章が丸ごとスキップされる | | **構造化精度** | 指定したMarkdown/JSON形式が崩れていないか | 表の列がズレる、閉じタグの欠落 | | **事実忠実性** | 存在しない要件を「ハルシネーション」していないか | 欠落を補うために一般的な仕様を捏造する | ## 【改良後の最適プロンプト】 Gemini 1.5 Proの広いコンテキスト窓を活かしつつ、各ステップの出力をXMLタグで囲ませて構造を固定する手法です。 

# System

あなたは、高密度な情報を1bitも漏らさずに整理する情報設計者です。

# Instructions

以下のプロセスで思考し、タグごとに回答を出力してください。

<analysis_phase>
入力データから「必須要件」「任意要件」「制約事項」をそれぞれ200文字程度で要約しなさい。
</analysis_phase>

<conflict_check>
要約した内容に矛盾がないか検証し、矛盾がある場合はその箇所を指摘しなさい。
</conflict_check>

<final_output>
検証済みの情報を基に、以下のJSONフォーマットで出力しなさい。
{
  "requirements": [{"id": "", "content": ""}],
  "constraints": []
}
</final_output>

# Input

[ターゲットテキスト]

【まとめ】

実務でプロンプトを運用するための3つの鉄則：

  1. 「一気に出力させない」: 思考フェーズ（CoT）と出力フェーズを明示的に分ける。

  2. 「XMLタグで境界を作る」: LLMに対して、どのセクションが「検討」で、どこが「最終回答」かを物理的に理解させる。

  3. 「コンテキストの鮮度を保つ」: 複雑なタスクでは、数回に分けてプロンプトを投げる「プロンプト・チェイニング」を採用し、1回あたりの負荷を減らす。

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

コメント

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