<p>[META] { “style”: “logical_and_professional”, “audience”: “prompt_engineers_and_developers”, “focus”: “context_engineering_for_llms”, “tone”: “authoritative_practical” } [/META]</p> <p>本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p> <h1 class="wp-block-heading">プロンプトからコンテキストへ：LLMの出力精度を最大化する情報環境設計ガイド</h1> <h2 class="wp-block-heading">【ユースケース定義と課題】</h2> <p><strong>定義：</strong> 膨大な社内資料や多層構造のデータをLLMに読み込ませ、特定業務に特化した高度な推論と構造化出力を実行させる。 <strong>課題：</strong> 命令文のみの改善では、長文コンテキストにおける情報の埋没、ハルシネーション、出力形式の逸脱を制御しきれない。 <strong>型（入出力形式）：</strong></p> <ul class="wp-block-list"> <li><p>入力：Markdown形式のコンテキスト（背景知識、ルール、制約）</p></li> <li><p>出力：JSON形式（推論過程と思考ログを含む構造化データ）</p></li> </ul> <h2 class="wp-block-heading">【プロンプト設計のループ】</h2> <div class="wp-block-merpress-mermaidjs diagram-source-mermaid"><pre class="mermaid"> graph TD A["設計"] --> B["実行"] B --> C["評価"] C -->|改善| A </pre></div> <ol class="wp-block-list"> <li><p><strong>設計（Design）：</strong> 役割（Role）、制約（Constraints）、参照データ（Context）を明確に分離した構造を定義。</p></li> <li><p><strong>実行（Execution）：</strong> Gemini 1.5 Pro等の長文コンテキスト耐性の高いモデルで実行。</p></li> <li><p><strong>評価（Evaluation）：</strong> 期待されるJSONスキーマとの一致率、推論の妥当性を定量的・定性的に検証。</p></li> </ol> <h2 class="wp-block-heading">【プロンプトの実装案】</h2> <div class="codehilite"> <pre data-enlighter-language="generic"># Role あなたは情報環境設計（コンテキストエンジニアリング）のエキスパートです。 与えられた[Context]に基づき、論理的推論を行い、[Output Schema]に従って回答を生成してください。 # Context <background_knowledge> {{社内規定や技術仕様などのMarkdownテキスト}} </background_knowledge> <specific_rules> - 事実に基づかない回答は厳禁。不明な点は「情報不足」と明記すること。 - 専門用語は、[background_knowledge]内の定義を最優先すること。 </specific_rules> # Task [Context]を参照し、以下の質問に対する解決策を提示してください。 質問：{{ユーザーからの具体的な問い}} # Thinking Process (Chain-of-Thought) 回答を生成する前に、以下のステップで思考してください。 1. 質問の意図を解釈する。 2. 必要な情報を[Context]から抽出する。 3. 抽出した情報に矛盾がないか確認する。 4. [Output Schema]に沿って構造化する。 # Output Schema ```json { "thinking": "ステップ1〜4の思考プロセス", "answer": "最終的な回答内容", "confidence_score": 0.0 to 1.0, "sources": ["参照したセクション名"] } </pre> </div> <pre data-enlighter-language="generic"> ## 【評価指標と誤り分析】 | 評価項目 | 失敗パターン | 評価基準 (LLM-as-a-Judge) | | :--- | :--- | :--- | | **形式遵守 (Format)** | JSONが壊れる、キーが足りない | スキーマに完全一致するか (0/1) | | **根拠性 (Faithfulness)** | Contextにない情報を捏造する | Context内の記述だけで構成されているか (1-5) | | **推論精度 (Reasoning)** | CoTが飛躍している、論理が破綻 | 思考プロセスに矛盾がないか (1-5) | | **情報の網羅性 (Recall)** | 重要な制約事項を見落とす | 必須の制約がすべて適用されているか (1-5) | **誤り分析：** - **ハルシネーション：** コンテキストが構造化されていない（ただのベタ貼り）場合に発生。 - **様式崩れ：** 命令がコンテキストの末尾に配置されていない（Recency Biasの影響）場合に発生。 ## 【改良後の最適プロンプト】 ```text ## [SYSTEM_INSTRUCTION] You are a highly logical reasoning engine. Process the provided information blocks tagged with XML-like delimiters. ## [CONTEXT_BLOCK] <rules> 1. Always output in JSON format. 2. Use the <thinking> field for step-by-step logic. 3. If the context is insufficient, set "certainty" to "low" and explain why. </rules> <knowledge_base> {{STRUCTURED_MARKDOWN_DATA}} </knowledge_base> ## [INPUT_QUERY] {{USER_INPUT}} ## [RESPONSE_GUIDELINE] Generate your response by strictly following the schema below. Ensure all string values are properly escaped for JSON compliance. { "thinking": "String (Your Chain-of-Thought reasoning)", "analysis": { "key_points": ["Point 1", "Point 2"], "limitations": "String" }, "final_response": "String", "certainty": "high/medium/low" } </pre> <h2 class="wp-block-heading">【まとめ】</h2> <p>実務でコンテキストエンジニアリングを運用するための3つの鉄則：</p> <ol class="wp-block-list"> <li><p><strong>タグによる構造化：</strong> <code><knowledge></code> や <code><rules></code> などのタグを用い、LLMに情報の役割（セマンティクス）を明示的に伝える。</p></li> <li><p><strong>思考の分離（CoT）：</strong> <code>thinking</code> フィールドを設け、推論プロセスを強制的に出力させることで、最終的な回答の精度を飛躍的に高める。</p></li> <li><p><strong>スキーマの厳格化：</strong> 出力形式をJSON Schemaなどで固定し、後続のシステム処理や自動評価を容易にする「機械に優しい」設計を行う。</p></li> </ol>

graph TD
A["設計"] --> B["実行"]
B --> C["評価"]
C -->|改善| A

# Role

あなたは情報環境設計（コンテキストエンジニアリング）のエキスパートです。
与えられた[Context]に基づき、論理的推論を行い、[Output Schema]に従って回答を生成してください。

# Context

<background_knowledge>
{{社内規定や技術仕様などのMarkdownテキスト}}
</background_knowledge>

<specific_rules>

- 事実に基づかない回答は厳禁。不明な点は「情報不足」と明記すること。

- 専門用語は、[background_knowledge]内の定義を最優先すること。
</specific_rules>

# Task

[Context]を参照し、以下の質問に対する解決策を提示してください。
質問：{{ユーザーからの具体的な問い}}

# Thinking Process (Chain-of-Thought)

回答を生成する前に、以下のステップで思考してください。

1. 質問の意図を解釈する。

2. 必要な情報を[Context]から抽出する。

3. 抽出した情報に矛盾がないか確認する。

4. [Output Schema]に沿って構造化する。

# Output Schema

```json
{
  "thinking": "ステップ1〜4の思考プロセス",
  "answer": "最終的な回答内容",
  "confidence_score": 0.0 to 1.0,
  "sources": ["参照したセクション名"]
}

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

| 評価項目 | 失敗パターン | 評価基準 (LLM-as-a-Judge) |
| :--- | :--- | :--- |
| **形式遵守 (Format)** | JSONが壊れる、キーが足りない | スキーマに完全一致するか (0/1) |
| **根拠性 (Faithfulness)** | Contextにない情報を捏造する | Context内の記述だけで構成されているか (1-5) |
| **推論精度 (Reasoning)** | CoTが飛躍している、論理が破綻 | 思考プロセスに矛盾がないか (1-5) |
| **情報の網羅性 (Recall)** | 重要な制約事項を見落とす | 必須の制約がすべて適用されているか (1-5) |

**誤り分析：**

- **ハルシネーション：** コンテキストが構造化されていない（ただのベタ貼り）場合に発生。

- **様式崩れ：** 命令がコンテキストの末尾に配置されていない（Recency Biasの影響）場合に発生。

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

```text
## [SYSTEM_INSTRUCTION]

You are a highly logical reasoning engine. Process the provided information blocks tagged with XML-like delimiters. 

## [CONTEXT_BLOCK]

<rules>

1. Always output in JSON format.

2. Use the <thinking> field for step-by-step logic.

3. If the context is insufficient, set "certainty" to "low" and explain why.
</rules>

<knowledge_base>
{{STRUCTURED_MARKDOWN_DATA}}
</knowledge_base>

## [INPUT_QUERY]

{{USER_INPUT}}

## [RESPONSE_GUIDELINE]

Generate your response by strictly following the schema below. Ensure all string values are properly escaped for JSON compliance.

{
  "thinking": "String (Your Chain-of-Thought reasoning)",
  "analysis": {
    "key_points": ["Point 1", "Point 2"],
    "limitations": "String"
  },
  "final_response": "String",
  "certainty": "high/medium/low"
}