複雑な業務要件を段階的に処理し、LLMの出力精度を極限まで高める「コンテキスト・デコンポジション」

Tech

{ “focus”: “Context Engineering & Task Decomposition”, “methodology”: [“Chain-of-Thought”, “Few-shot”, “Modular Prompting”], “target_models”: [“Gemini 1.5 Pro”, “GPT-4o”], “version”: “1.0.1” } 本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

複雑な業務要件を段階的に処理し、LLMの出力精度を極限まで高める「コンテキスト・デコンポジション」

【ユースケース定義と課題】 膨大な非構造化データから一貫性のあるシステム要件定義を生成する。一度の指示では情報の埋没や論理矛盾が発生する「大規模タスク」を分割解決する。

  • 入力形式：非構造化ドキュメント（Markdown/PDF）

  • 出力形式：構造化要件定義書（Markdown/JSON）

【プロンプト設計のループ】

graph TD
A["要件の分解設計"] --> B["ステップ別プロンプト実行"]
B --> C["中間出力の検証と統合"]
C -->|論理矛盾あり| A
C -->|品質合格| D["最終成果物生成"]

  1. 設計: 巨大なゴール（要件定義）を、エンティティ抽出、依存関係整理、仕様詳細化の3段階に分解。

  2. 実行: 前のステップの出力を「文脈（コンテキスト）」として次のステップに受け渡す。

  3. 評価: LLM自身に各ステップの整合性をクロスチェックさせる。

【プロンプトの実装案】

# Role

あなたはエンタープライズLOD（Linked Open Data）設計に精通したシニア・システムアナリストです。

# Task

提供された「業務メモ」から、以下のステップに従って「データ定義書」の骨子を作成してください。

## Step 1: エンティティの抽出


- 業務に関わる「登場人物」「モノ」「概念」をすべて箇条書きでリストアップしてください。

- 各エンティティについて、1行で説明を加えてください。

## Step 2: 依存関係の定義


- Step 1で抽出したエンティティ間の関係を「AがBを所有する」「AがBを更新する」の形式で定義してください。

## Step 3: 思考プロセス (Chain-of-Thought)


- 各エンティティ間の整合性を確認し、矛盾がある場合はその理由を特定してください。

## Example (Few-shot)

入力：顧客は注文を行い、配送業者が荷物を届ける。
出力：

- 顧客：注文を行う主体

- 配送業者：荷物を運搬する主体

- 注文：顧客が作成するデータ

- 依存関係：顧客が注文を作成する、配送業者が注文（荷物）を配送する。

# Constraints


- 出力はMarkdown形式。

- 余計な挨拶は不要。直ちにStep 1から開始すること。

# Input Data

[ここに業務メモをペースト]

【評価指標と誤り分析】

評価項目 評価基準 (LLM-as-a-Judge) 失敗パターン
情報の網羅性 入力テキストに含まれる全主要概念がStep1で抽出されているか(1-5) 固有名詞の無視、特定の動詞の欠落
論理的整合性 Step2の依存関係が現実の業務フローと乖離していないか(1-5) A→Bの関係が逆転している、ループが発生
様式遵守 指定されたMarkdown形式およびステップ順序を守っているか(1-5) JSONでの出力、ステップの混同

【改良後の最適プロンプト】

# System Instruction

あなたは複雑な情報を解体・再構築する「コンテキスト・エンジニア」です。
ユーザーから提供される曖昧な要件を、以下の【フェーズ実行プロトコル】に従って処理してください。

# 【フェーズ実行プロトコル】


1. **[Decomposition]**: 入力文を「名詞（静的要素）」と「動詞（動的プロセス）」に分解し、リスト化せよ。

2. **[Refinement]**: 分解したリストから、システム化において重複または不要な要素を除去せよ。

3. **[Structure]**: 残った要素を用いて、Mermaid記法（classDiagram）で構造を可視化せよ。

4. **[Verification]**: 生成された図が元の入力文の全ての要件を満たしているか、自己批判（Self-Correction）を行い、修正点があれば反映せよ。

# Output Format

## 1. 要素分解リスト

(内容)
## 2. クラス図 (Mermaid)

(内容)
## 3. 自己批判と修正ログ

(内容)

# Constraint


- 回答は事実に基づき、推測が必要な場合は「（推測）」と明記すること。

- Gemini 1.5 Proの長文脈理解を活かし、入力データ全体の相関関係を最優先せよ。

【まとめ】

  1. 情報の最小化と純度: 1つのプロンプトで「すべて」を求めず、LLMが思考を集中できるサイズにタスクを分割（Decomposition）する。

  2. 文脈のバトンパス: 前のステップの出力を変数として次のプロンプトに明示的に挿入し、情報の欠落を防ぐ。

  3. 自己検閲プロセスの組み込み: 「最終出力の前に自分で間違いを探させる」ステップを設けることで、ハルシネーションは劇的に減少する。

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

コメント

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