複雑な業務要件を担保するコンテキスト設計：プロンプト工学を超えた「構造化入力」による確実性の追求

Tech

[METADATA style_prompt.txt, output_restriction=none, audience=prompt_engineers, focus=context_engineering] 本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

複雑な業務要件を担保するコンテキスト設計：プロンプト工学を超えた「構造化入力」による確実性の追求

【ユースケース定義と課題】

タスク概要

大量の非構造化データ（プレスリリースや技術ブログ）から、投資判断や市場分析に利用可能なクリティカルなビジネスインサイトを抽出・構造化する。 課題: 抽出漏れや解釈の誤り（幻覚）、およびJSON形式の出力スキーマを厳密に遵守できない出力崩れが発生しやすい。特に、長い入力テキストに対するタスク定義の「コンテキストの持続性」をいかに担保するかが鍵となる。

入出力の型定義

項目 型 説明
入力 Markdown形式テキスト 企業の発表したプレスリリース全文。
出力 厳格なJSON形式 抽出されたインサイト、影響度、確信度を格納。

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

LLMのパフォーマンスは単一のプロンプトで決まるのではなく、反復的な評価と改善サイクル（Prompt Engineering Loop）を通じて最適化されます。

graph TD
A["設計: 制約, CoT, スキーマ定義"] --> B["実行: LLMによる推論と出力"]
B --> C["評価: LLM-as-a-Judgeまたは手動評価"]
C -->|失敗パターンの特定と改善| A

各ステップの詳細

  • 設計: 入力テキストのどこに着目すべきか、推論のプロセス（Chain-of-Thought; CoT）を具体的に指示する。特に、出力形式を厳密に定義する。

  • 実行: 最新のLLM（Gemini 1.5 Pro/GPT-4o）は、複雑な指示でも一度に実行できる能力が高いため、多段階の指示を盛り込む。

  • 評価: 期待されるビジネス要件（精度、形式遵守）に基づき、定量的に採点する。

【プロンプトの実装案】

初期段階のプロンプトでは、タスク定義、役割定義、そして具体的なCoTの指示を盛り込みます。この段階では、JSON形式の厳密な遵守と抽出の網羅性を高めることを目標とします。

ベースライン・プロンプト（CoTとFew-shotの適用）

# 役割定義

あなたは、市場分析専門のアナリストAIです。与えられた[プレスリリーステキスト]を分析し、潜在的なビジネスチャンス、リスク、または重要な市場動向を示す「ビジネスインサイト」を抽出してください。

# 制約事項


1.  抽出結果は必ずJSON形式で出力すること。プレーンテキストや補足説明は一切含めないこと。

2.  インサイトは最大5つ抽出すること。

3.  [プレスリリーステキスト]に明記されていない推測は「幻覚」とみなし、厳しく排除すること。

# 手順 (Chain-of-Thought)


1.  **全文読解**: [プレスリリーステキスト]を精読し、特に数値、提携、新技術発表の部分に印をつける。

2.  **インサイト抽出**: 印をつけた部分から、ビジネスに影響を与える可能性のある核心的な事象を抽出する。

3.  **確信度評価**: 抽出した各インサイトについて、[プレスリリーステキスト]内の証拠に基づき、確信度を以下の基準で評価する。

    *   High (明記されている/具体的な数値がある)

    *   Medium (示唆されている/計画段階)

    *   Low (間接的な言及のみ)

4.  **JSON構造化**: 最終的に抽出されたインサイトを、指定された[出力JSONスキーマ]に従って構造化する。

# 出力JSONスキーマ

```json
[
  {
    "insight_id": "I-001",
    "summary": "抽出されたインサイトの要約 (50文字以内)",
    "category": "Technology | Market | Partnership | Financial",
    "impact": "High | Medium | Low",
    "confidence": "High | Medium | Low"
  }
]

Few-shot例 (例示は省略。実際には1～2つの具体的な入出力ペアをここに配置する)

[プレスリリーステキスト]

(ここに分析対象のテキストを入力)

出力





## 【評価指標と誤り分析】

ベースラインプロンプトを実行した際によく発生する「失敗パターン」を分析し、改良の方向性を定めます。

### 失敗パターン（誤り分析）

| 失敗コード | 発生頻度 | 具体的な誤り内容 |
| :--- | :--- | :--- |
| F-01 | 高 | JSON形式の崩壊（キーの欠落、末尾カンマのミスなど）。 |
| F-02 | 中 | 幻覚（Hugging/Hallucination）：インサイトが入力テキストに裏付けられていない。 |
| F-03 | 中 | 要件の無視：`impact` や `confidence` の値が定義済みの列挙型以外になっている。 |
| F-04 | 低 | 重要な情報の抽出漏れ（網羅性の欠如）。 |

### LLMによる自動評価（LLM-as-a-Judge）

評価プロセス自体をLLMに任せることで、迅速な反復改善を可能にします。以下の採点基準を評価LLMに提示します。

| 採点基準 | 採点 (1-5) | 判定ロジックと改良示唆 |
| :--- | :--- | :--- |
| **形式遵守 (F-01, F-03)** | 5点満点 | 出力が厳密に指定されたJSONスキーマに準拠しているか。不準拠は即座に0点。 |
| **正確性 (F-02)** | 5点満点 | 抽出されたインサイトの全てが、入力テキスト内の具体的な証拠によって裏付けられているか。幻覚の有無。 |
| **網羅性 (F-04)** | 5点満点 | 入力テキスト中の最も重要なビジネス要素を適切にカバーしているか。主要情報の抽出漏れはないか。 |

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

失敗パターンF-01（形式崩壊）とF-02（幻覚）を抑制するため、プロンプト内に「自己検証（Reflection）」のステップを強制的に組み込みます。これは、思考（推論）と出力（結果）の間に「チェックプロセス」を設けるDSPy的なアプローチです。

**最適化ポイント**:

1.  出力形式の厳格化（`THOUGHT`と`JSON`の分離）。

2.  自己検証ステップの追加（Reflection）。

### 反射的推論を組み込んだ「最強プロンプト」

```text

# 役割と目標 (Persona & Goal)

あなたは、ビジネスインテリジェンスの最高責任者です。提供された[入力データ]に基づき、市場への影響度が最も高い5つのインサイトを抽出・構造化してください。

# 出力要求構造 (Strict Output Protocol)

あなたの回答は、以下の2つのセクションで構成されなければなりません。プレーンテキストは絶対に許可しません。

1.  <INTERMEDIATE_THOUGHT>...</INTERMEDIATE_THOUGHT>

2.  <FINAL_JSON_OUTPUT>...</FINAL_JSON_OUTPUT>

# 手順 (Advanced Chain-of-Thought)

## ステップ 1: データ選別と抽出

[入力データ]から、具体的な数値、日付、固有名詞を含むキーフレーズを抽出する。これらが抽出の根拠となる。

## ステップ 2: インサイトの仮説生成

抽出されたキーフレーズに基づき、投資家視点から見て最も重要なビジネスインサイトを最大5つ、簡潔な日本語でリスト化する。

## ステップ 3: 自己検証 (Reflection)

ステップ2で生成したインサイトリストに対し、以下のチェックリストを適用する。
A.  **正確性の検証**: 各インサイトは[入力データ]内のどの文によって裏付けられているか？裏付けがない場合は廃棄する。
B.  **形式の検証**: 最終的な出力が[出力JSONスキーマ]（後述）を厳密に満たすか？特に `impact` と `confidence` の値が定義された列挙型内にあることを確認する。

## ステップ 4: 最終出力

検証が完了したインサイトのみを、指定されたJSON構造に変換し、<FINAL_JSON_OUTPUT>タグ内に出力する。

# [出力JSONスキーマ]

(ベースラインプロンプトで定義したスキーマを再掲)
```json
[
  {
    "insight_id": "I-XXX",
    "summary": "抽出されたインサイトの要約 (50文字以内)",
    "category": "Technology | Market | Partnership | Financial",
    "impact": "High | Medium | Low",
    "confidence": "High | Medium | Low"
  }
]





[入力データ]




(分析対象のテキストをここに配置)




実行開始





// ステップ1～3の推論プロセスをここに記述させる


// 最終的なJSON出力をここに記述させる

“`




【まとめ】




プロンプト工学が指示の最適化であるのに対し、コンテキスト・エンジニアリングは、LLMがより確実にタスクを遂行するための「環境構築」と「推論プロトコルの構造化」を指します。最新の強力なLLM（Gemini 1.5 Pro/Flash, GPT-4o）を活用するためには、以下の鉄則が重要です。




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




    

  1. コンテキストの構造化の徹底: プロンプトを単なる指示文ではなく、厳格な入出力プロトコル（XMLタグ、JSON Schema、Markdownセクションなど）で構成し、タスクのスコープを明確に限定する。曖昧な指示は常に推論のブレを生みます。
    2. 

  2. 評価駆動型改善（LLM-as-a-Judge）: プロンプトの成功を主観的な「良さ」ではなく、「形式遵守」や「正確性」といった定量的な指標で評価する仕組みを導入する。評価基準が明確であればあるほど、改善サイクルは加速する。
    3. 

  3. メタ認知（自己検証）の組み込み: LLMに即座に出力させるのではなく、CoTやReflection（自己検証）のステップをプロンプト内に強制的に組み込むことで、出力品質に対する内部的な責任感を高め、幻覚や形式崩壊のリスクを劇的に軽減する。
    4. 







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

利用ポリシー もご参照ください。

      


      
      
      

    






  
  
  

  
  
      

        

  
  
  


  

    

      コメント          


      

  



  
  





          


        

      


    


    
    
    
    

    
    

    





    

      
  


    

	
				


















	
	
	
    


  

  

  

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