「プロンプト」から「コンテキスト」へ：LLMの性能を最大化する情報環境設計の実装ガイド

Tech

research_focus: [“Context Engineering”, “In-context Learning optimization”, “Information Architecture for LLMs”] technique: [“Chain-of-Thought (CoT)”, “Few-shot Prompting”, “LLM-as-a-Judge”] tone: “Professional, Analytical, Engineering-centric” output_format: “Markdown with Mermaid diagrams”

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

「プロンプト」から「コンテキスト」へ：LLMの性能を最大化する情報環境設計の実装ガイド

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

複雑な技術文書から、ビジネス価値と実装上の制約を特定し、構造化データとサマリーを同時に出力する高度な分析タスク。

  • 入力型：非構造化テキスト（技術仕様書、論文、議事録など）

  • 出力型：Markdown（分析レポート）および JSON（パラメータ抽出）

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

graph TD
A["コンテキスト設計"] --> B["推論実行"]
B --> C["評価・誤差分析"]
C -->|コンテキスト情報の圧縮・整理| A

  1. 設計: 入力情報の優先順位付けと、LLMが迷わないための「型（Schema）」を定義。

  2. 実行: Gemini 1.5 Pro等の長文コンテキスト窓を活用し、指示と参照情報を分離して入力。

  3. 評価: 期待したJSON構造の欠落や、文脈の読み飛ばし（Lost in the Middle）を特定。

  4. 改善: プロンプトの命令（Instruction）よりも、参照データの配置（Information Architecture）を最適化。

【プロンプトの実装案】

# Role

あなたは複雑な技術仕様を解析し、開発者が即座に実装へ移れるレベルの構造化データを生成する、シニア・ソリューション・アーキテクトです。

# Context

以下の【対象ドキュメント】の内容を読み解き、出力形式に従って情報を整理してください。
特に「実装上の破壊的変更」と「コストに直結する制約」を重点的に抽出すること。

# Task Process (Chain-of-Thought)


1. 文書内の技術スタックを特定する。

2. 既存システムとの互換性に関する記述を抽出する。

3. リスク要因を「高・中・低」でランク付けする。

4. 指定されたJSONスキーマに従い、データをマッピングする。

# Constraints


- 根拠のない推測は禁止。不明な点は「不明」と明記。

- JSONは構文エラーがないよう、エスケープ処理を徹底。

# Example (Few-shot)

[Input]: "API v2では、認証方式がOAuth 2.0に統一され、従来のAPIキーは廃止されます。"
[Output Analysis]: "認証方式の変更（OAuth 2.0への移行）。既存のAPIキー利用クライアントに影響あり。"
[Output JSON]: {"category": "Breaking Change", "severity": "High"}

# 対象ドキュメント

{{input_text}}

# 出力形式

## 分析レポート

(ここにMarkdown形式で記述)

## 抽出データ

```json
{
  "tech_stack": [],
  "risks": [{"level": "", "description": ""}],
  "meta_info": {"document_id": "", "status": ""}
}

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

| 評価項目 | 失敗パターン（例） | 採点基準 (1-5) | LLM-as-a-Judgeのチェックポイント |
| :--- | :--- | :--- | :--- |
| **忠実性 (Faithfulness)** | 本文にない技術スタックを捏造する | 1: 幻覚あり / 5: 根拠100% | 抽出された全項目がソース内に存在するか？ |
| **構造化精度 (Formatting)** | JSONが閉じられていない、型が違う | 1: パース不可 / 5: 正確 | `json.loads()` がエラーなく実行可能か？ |
| **コンテキスト把握** | 文末の重要な制約を見落とす | 1: 表面的な要約 / 5: 深い洞察 | 文書全体の主要なリスクが網羅されているか？ |

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

最新のLLM（Gemini 1.5 Pro等）では、指示よりも**「情報の構造化（Context Engineering）」**が重要です。命令を冒頭に、データを中央に、出力指示を末尾に置く「サンドイッチ構造」を採用します。

```text
<system_instruction>
あなたは技術文書解析の専門家です。
出力は必ず [REPORT] セクションと [DATA] セクションに分けてください。
</system_instruction>

<context_environment>

# 優先順位


1. セキュリティ制約

2. パフォーマンス要件

3. 予算的制約

# 参照スキーマ


- type: object, properties: { "risk_score": { "type": "integer", "minimum": 1, "maximum": 10 } }
</context_environment>

<input_document>
{{input_text}}
</input_document>

<response_guidelines>
Step-by-stepで思考し、最後にJSONを出力してください。
JSONは ```json ... ``` ブロックで囲んでください。
</response_guidelines>

【まとめ】

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

  1. 「何をさせるか」より「何を与えるか」: LLMの知能に頼るのではなく、解析しやすいようにドキュメントをMarkdown等で構造化して渡す。

  2. 出力フォーマットの強制: Few-shotの中に「失敗例」を含めるか、あるいはJSONスキーマを明示的に与えて「型」を固定する。

  3. 評価の自動化: 人間の目視確認を減らすため、別のLLM（GPT-4o等）に「抽出されたデータが元の文書と矛盾していないか」を逆検証させる。

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

コメント

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