<p><!-- style_prompt: prompt_engineering_expert, RESEARCH-FIRST: [Chain-of-Thought, Iterative Refinement, Instruction Layering], PLAN: [Context Engineering for complex content generation, Stage-based processing, Mermaid loop, Few-shot implementation, LLM-as-a-Judge evaluation] -->
<strong>本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。</strong></p>
<h1 class="wp-block-heading">複雑な要件を構造化する：コンテキストエンジニアリングによる「多段実行プロンプト」の設計</h1>
<p>【ユースケース定義と課題】
1万字超のインタビュー録から技術記事を生成する際、指示の飽和による情報の欠落や文体崩れを防ぎ、構造的なMarkdown出力を実現する。</p>
<p>【プロンプト設計のループ】</p>
<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>設計</strong>: 複雑なゴールを「抽出」「構成」「執筆」の3ステップに分離し、各段階の入出力を定義。</p></li>
<li><p><strong>実行</strong>: 前のステップの出力を次のステップの「コンテキスト」として流し込む。</p></li>
<li><p><strong>評価</strong>: 最終成果物が全要件を満たしているか、LLMを用いて客観的にスコアリング。</p></li>
</ol>
<p>【プロンプトの実装案】</p>
<div class="codehilite">
<pre data-enlighter-language="generic"># Step 1: 重要な文脈の抽出（Context Extraction）
あなたは熟練の技術ライターです。以下の生データから、記事の核となる「技術的課題」「解決策」「独自の知見」を抽出してください。
## 入力データ
[インタビュー録を貼り付け]
## 出力形式
- 課題: (200字程度)
- 解決策: (200字程度)
- 独自知見: (箇条書き3つ)
---
# Step 2: 構成案の作成（Logical Structuring）
Step 1で抽出した要素に基づき、以下の構成案を作成してください。
思考プロセス（Chain-of-Thought）として、なぜその順序にしたかの理由も併記すること。
## 制約条件
- ターゲット：シニアエンジニア
- 読了後のアクション：GitHubリポジトリの確認
- トーン：誠実かつ専門的
## 出力構成
1. 導入（現状の課題提起）
2. 解決の鍵（抽出した知見の提示）
...
</pre>
</div>
<p>【評価指標と誤り分析】
複雑なプロンプトにおいて発生しやすい「指示の無視」や「事実の歪曲」を以下の基準で評価します。</p>
<figure class="wp-block-table"><table>
<thead>
<tr>
<th style="text-align:left;">評価項目</th>
<th style="text-align:left;">評価内容</th>
<th style="text-align:left;">失敗パターン</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:left;"><strong>指示遵守率</strong></td>
<td style="text-align:left;">指定した全セクションが存在するか</td>
<td style="text-align:left;">構成案の一部が勝手に省略される</td>
</tr>
<tr>
<td style="text-align:left;"><strong>文脈維持度</strong></td>
<td style="text-align:left;">入力データの事実に基づいているか</td>
<td style="text-align:left;">存在しない技術スタックを捏造する</td>
</tr>
<tr>
<td style="text-align:left;"><strong>形式適合性</strong></td>
<td style="text-align:left;">指定したMarkdown形式で出力されているか</td>
<td style="text-align:left;">JSON形式が混ざる、h2タグが抜ける</td>
</tr>
<tr>
<td style="text-align:left;"><strong>論理的一貫性</strong></td>
<td style="text-align:left;">導入と結論の論理がつながっているか</td>
<td style="text-align:left;">前半と後半で主張が矛盾する</td>
</tr>
</tbody>
</table></figure>
<p>【改良後の最適プロンプト】
各ステップを連結し、LLMが「自分の出力を客観視」するプロセスを加えた最終プロンプトです。</p>
<div class="codehilite">
<pre data-enlighter-language="generic"># Role
あなたは「コンテキストエンジニアリング」に基づき、情報を段階的に整理・洗練させるシニアエディターです。
# Task
以下の「生データ」を、3つのフェーズ（分析→構成→執筆）を経て高品質な技術記事に変換してください。
# Constraints
1. <Thought>タグ内で各フェーズの自己批判（セルフクリティーク）を行うこと。
2. 前のフェーズの矛盾を見つけた場合、即座に修正して次のフェーズへ進むこと。
3. 専門用語は正確に維持し、比喩表現は最小限にすること。
# Input Data
[対象テキストを挿入]
# Execution Flow
## Phase 1: Context Analysis
- データの主要トピックを3点特定
- 想定読者の前提知識レベルを定義
## Phase 2: Structural Design
- Phase 1に基づきMarkdown形式の目次を作成
- 各章で伝えるべき「最小単位のメッセージ」を記述
## Phase 3: Final Drafting
- Phase 2の構成に従い、1,500字程度で執筆
- 最後に、全指示（Constraints）を守れているか自己採点表を出力
# Output format
[Phase 1-3の実行プロセスと最終成果物]
</pre>
</div>
<p>【まとめ】</p>
<ol class="wp-block-list">
<li><p><strong>指示の分離（Decoupling）</strong>: 1つのプロンプトに「分析」と「執筆」を混ぜず、ステップを分ける。</p></li>
<li><p><strong>中間成果物の定義</strong>: 次のステップへの「橋渡し」となる情報の型を明確にする。</p></li>
<li><p><strong>セルフレビューの組み込み</strong>: LLM自身に「指示を守れているか」をチェックさせる思考プロセスを強制する。</p></li>
</ol>
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
複雑な要件を構造化する：コンテキストエンジニアリングによる「多段実行プロンプト」の設計
【ユースケース定義と課題】
1万字超のインタビュー録から技術記事を生成する際、指示の飽和による情報の欠落や文体崩れを防ぎ、構造的なMarkdown出力を実現する。
【プロンプト設計のループ】
graph TD
A["要件の分解/設計"] --> B["段階的実行/推論"]
B --> C["品質評価/分析"]
C -->|指示の競合を解消| A
設計: 複雑なゴールを「抽出」「構成」「執筆」の3ステップに分離し、各段階の入出力を定義。
実行: 前のステップの出力を次のステップの「コンテキスト」として流し込む。
評価: 最終成果物が全要件を満たしているか、LLMを用いて客観的にスコアリング。
【プロンプトの実装案】
# Step 1: 重要な文脈の抽出（Context Extraction）
あなたは熟練の技術ライターです。以下の生データから、記事の核となる「技術的課題」「解決策」「独自の知見」を抽出してください。
## 入力データ
[インタビュー録を貼り付け]
## 出力形式
- 課題: (200字程度)
- 解決策: (200字程度)
- 独自知見: (箇条書き3つ)
---
# Step 2: 構成案の作成（Logical Structuring）
Step 1で抽出した要素に基づき、以下の構成案を作成してください。
思考プロセス（Chain-of-Thought）として、なぜその順序にしたかの理由も併記すること。
## 制約条件
- ターゲット：シニアエンジニア
- 読了後のアクション：GitHubリポジトリの確認
- トーン：誠実かつ専門的
## 出力構成
1. 導入（現状の課題提起）
2. 解決の鍵（抽出した知見の提示）
...
【評価指標と誤り分析】
複雑なプロンプトにおいて発生しやすい「指示の無視」や「事実の歪曲」を以下の基準で評価します。
| 評価項目 |
評価内容 |
失敗パターン |
| 指示遵守率 |
指定した全セクションが存在するか |
構成案の一部が勝手に省略される |
| 文脈維持度 |
入力データの事実に基づいているか |
存在しない技術スタックを捏造する |
| 形式適合性 |
指定したMarkdown形式で出力されているか |
JSON形式が混ざる、h2タグが抜ける |
| 論理的一貫性 |
導入と結論の論理がつながっているか |
前半と後半で主張が矛盾する |
【改良後の最適プロンプト】
各ステップを連結し、LLMが「自分の出力を客観視」するプロセスを加えた最終プロンプトです。
# Role
あなたは「コンテキストエンジニアリング」に基づき、情報を段階的に整理・洗練させるシニアエディターです。
# Task
以下の「生データ」を、3つのフェーズ（分析→構成→執筆）を経て高品質な技術記事に変換してください。
# Constraints
1. <Thought>タグ内で各フェーズの自己批判（セルフクリティーク）を行うこと。
2. 前のフェーズの矛盾を見つけた場合、即座に修正して次のフェーズへ進むこと。
3. 専門用語は正確に維持し、比喩表現は最小限にすること。
# Input Data
[対象テキストを挿入]
# Execution Flow
## Phase 1: Context Analysis
- データの主要トピックを3点特定
- 想定読者の前提知識レベルを定義
## Phase 2: Structural Design
- Phase 1に基づきMarkdown形式の目次を作成
- 各章で伝えるべき「最小単位のメッセージ」を記述
## Phase 3: Final Drafting
- Phase 2の構成に従い、1,500字程度で執筆
- 最後に、全指示（Constraints）を守れているか自己採点表を出力
# Output format
[Phase 1-3の実行プロセスと最終成果物]
【まとめ】
指示の分離（Decoupling）: 1つのプロンプトに「分析」と「執筆」を混ぜず、ステップを分ける。
中間成果物の定義: 次のステップへの「橋渡し」となる情報の型を明確にする。
セルフレビューの組み込み: LLM自身に「指示を守れているか」をチェックさせる思考プロセスを強制する。
ライセンス：本記事のテキスト/コードは特記なき限り
CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。
コメント