<p><style_prompt></style_prompt></p>
<ul class="wp-block-list">
<li><p>執筆スタイル:プロフェッショナル、論理的、かつ実践的。抽象的な議論を排し、具体的な実装例と数値化可能な指標を重視する。</p></li>
<li><p>構成:結論から先に述べ、視覚的な構造(Mermaid、Markdownテーブル)を活用して理解コストを下げる。</p></li>
<li><p>技術的背景:Gemini 1.5 Proの長いコンテキストウィンドウと、GPT-4oの推論能力を前提とした、最新のプロンプトエンジニアリング(CoT, Few-shot, Contextualization)を適用。
</p></li>
</ul>
<p>本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト(未検証)</strong>です。</p>
<h1 class="wp-block-heading">コンテキストエンジニアリングによる「多階層要件定義書」生成の最適化</h1>
<h3 class="wp-block-heading">【ユースケース定義と課題】</h3>
<p>乱雑なインタビューログから、整合性の取れたシステム要件定義書をMarkdown形式で生成する。一度に指示を出すと詳細が欠落し、論理矛盾が生じる課題を解決する。</p>
<ul class="wp-block-list">
<li><p><strong>入力の型</strong>:非構造化テキスト(インタビュー、メモ、仕様断片)</p></li>
<li><p><strong>出力の型</strong>:構造化Markdown(背景、機能要件、非機能要件、UI/UX要件)</p></li>
</ul>
<h3 class="wp-block-heading">【プロンプト設計のループ】</h3>
<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>: 入力情報を「背景」「機能」「制約」のバケツに分類するプロンプトを設計。</p></li>
<li><p><strong>実行</strong>: 各バケツの内容を詳細化し、ドラフトを生成。</p></li>
<li><p><strong>評価</strong>: LLM-as-a-Judgeを用い、前後のセクションで用語や論理に矛盾がないか検証。</p></li>
</ol>
<h3 class="wp-block-heading">【プロンプトの実装案】</h3>
<div class="codehilite">
<pre data-enlighter-language="generic"># Role
あなたは上級ITアナリストです。提供された「未整理のメモ」を分析し、機能要件定義書の「ドラフト」を作成してください。
# Task: Step-by-Step
1. 分析:メモに含まれる「ユーザーの痛み」「解決策」「技術的制約」を抽出してください。
2. 構造化:以下のMarkdown形式に従って、情報を整理してください。
- ## 1. 導入(解決したい課題)
- ## 2. 機能一覧(Must/Should/Could)
- ## 3. 非機能要件(性能・セキュリティ)
3. 推論(CoT):各機能がなぜ必要なのか、ユーザーの痛みに紐づけて説明を加えてください。
# Constraints
- 専門用語は適切に使用する。
- 「不明点」がある場合は、適当に埋めず「要確認事項」としてリストアップすること。
# Example (Few-shot)
入力:「ログインに時間がかかる。指紋認証を入れたい。」
出力:
- 課題:認証プロセスにおけるユーザー体験の低下
- 機能要件:生体認証(指紋認証)の実装
- 理由:パスワード入力の手間を省き、セキュリティと利便性を両立させるため。
# Input Data
[ここにインタビューメモをペースト]
</pre>
</div>
<h3 class="wp-block-heading">【評価指標と誤り分析】</h3>
<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;">LLMの勝手な要約による情報の欠落</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;">表形式が崩れる、見出しレベルが混在する</td>
</tr>
</tbody>
</table></figure>
<h3 class="wp-block-heading">【改良後の最適プロンプト】</h3>
<p>情報を一度に処理させず、<strong>「抽出ステップ」と「生成ステップ」を分ける</strong>ことで精度を最大化します。</p>
<div class="codehilite">
<pre data-enlighter-language="generic"># System Instruction
あなたは、複雑な情報を構造化するエキスパートです。
以下の「分析」→「評価」→「生成」の順序で思考し、アウトプットしてください。
# Step 1: Data Extraction (Thinking Process)
まず、入力テキストから以下の要素を箇条書きで抽出してください。
- ターゲットユーザー
- コア機能
- 排除すべき仕様
# Step 2: Quality Check
抽出した要素に矛盾がないか、あるいは元のテキストに存在しない情報を捏造していないか自己チェックしてください。
# Step 3: Final Output Formulation
Step 1, 2を踏まえ、以下のフォーマットで要件定義書を出力してください。
[フォーマット指定:Markdown見出し構造...]
# Input
[ここにデータを入力]
</pre>
</div>
<h3 class="wp-block-heading">【まとめ】</h3>
<ol class="wp-block-list">
<li><p><strong>段階的提供(Step-by-Step)</strong>: 大規模な指示は思考プロセス(CoT)を明示し、推論ステップを分離する。</p></li>
<li><p><strong>型(Format)の厳守</strong>: 出力形式(JSON/Markdown)を明確に定義し、Few-shotで具体例を示す。</p></li>
<li><p><strong>自己検閲(Self-Reflect)</strong>: 生成前に「自分で矛盾をチェックさせる」工程をプロンプト内に組み込む。</p></li>
</ol>
執筆スタイル:プロフェッショナル、論理的、かつ実践的。抽象的な議論を排し、具体的な実装例と数値化可能な指標を重視する。
構成:結論から先に述べ、視覚的な構造(Mermaid、Markdownテーブル)を活用して理解コストを下げる。
技術的背景:Gemini 1.5 Proの長いコンテキストウィンドウと、GPT-4oの推論能力を前提とした、最新のプロンプトエンジニアリング(CoT, Few-shot, Contextualization)を適用。
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト(未検証)です。
コンテキストエンジニアリングによる「多階層要件定義書」生成の最適化
【ユースケース定義と課題】
乱雑なインタビューログから、整合性の取れたシステム要件定義書をMarkdown形式で生成する。一度に指示を出すと詳細が欠落し、論理矛盾が生じる課題を解決する。
【プロンプト設計のループ】
graph TD
A["情報の抽出と分類"] --> B["セクション別詳細生成"]
B --> C["全体整合性レビュー"]
C -->|矛盾・漏れあり| A
設計: 入力情報を「背景」「機能」「制約」のバケツに分類するプロンプトを設計。
実行: 各バケツの内容を詳細化し、ドラフトを生成。
評価: LLM-as-a-Judgeを用い、前後のセクションで用語や論理に矛盾がないか検証。
【プロンプトの実装案】
# Role
あなたは上級ITアナリストです。提供された「未整理のメモ」を分析し、機能要件定義書の「ドラフト」を作成してください。
# Task: Step-by-Step
1. 分析:メモに含まれる「ユーザーの痛み」「解決策」「技術的制約」を抽出してください。
2. 構造化:以下のMarkdown形式に従って、情報を整理してください。
- ## 1. 導入(解決したい課題)
- ## 2. 機能一覧(Must/Should/Could)
- ## 3. 非機能要件(性能・セキュリティ)
3. 推論(CoT):各機能がなぜ必要なのか、ユーザーの痛みに紐づけて説明を加えてください。
# Constraints
- 専門用語は適切に使用する。
- 「不明点」がある場合は、適当に埋めず「要確認事項」としてリストアップすること。
# Example (Few-shot)
入力:「ログインに時間がかかる。指紋認証を入れたい。」
出力:
- 課題:認証プロセスにおけるユーザー体験の低下
- 機能要件:生体認証(指紋認証)の実装
- 理由:パスワード入力の手間を省き、セキュリティと利便性を両立させるため。
# Input Data
[ここにインタビューメモをペースト]
【評価指標と誤り分析】
| 評価項目 |
評価内容 |
失敗パターン(低スコアの原因) |
| 網羅性 |
全ての重要発言が反映されているか |
LLMの勝手な要約による情報の欠落 |
| 整合性 |
セクション間で用語や論理が一致しているか |
冒頭で「クラウド」と言いつつ末尾で「オンプレ」と書く |
| 構造性 |
指定したMarkdown形式を維持しているか |
表形式が崩れる、見出しレベルが混在する |
【改良後の最適プロンプト】
情報を一度に処理させず、「抽出ステップ」と「生成ステップ」を分けることで精度を最大化します。
# System Instruction
あなたは、複雑な情報を構造化するエキスパートです。
以下の「分析」→「評価」→「生成」の順序で思考し、アウトプットしてください。
# Step 1: Data Extraction (Thinking Process)
まず、入力テキストから以下の要素を箇条書きで抽出してください。
- ターゲットユーザー
- コア機能
- 排除すべき仕様
# Step 2: Quality Check
抽出した要素に矛盾がないか、あるいは元のテキストに存在しない情報を捏造していないか自己チェックしてください。
# Step 3: Final Output Formulation
Step 1, 2を踏まえ、以下のフォーマットで要件定義書を出力してください。
[フォーマット指定:Markdown見出し構造...]
# Input
[ここにデータを入力]
【まとめ】
段階的提供(Step-by-Step): 大規模な指示は思考プロセス(CoT)を明示し、推論ステップを分離する。
型(Format)の厳守: 出力形式(JSON/Markdown)を明確に定義し、Few-shotで具体例を示す。
自己検閲(Self-Reflect): 生成前に「自分で矛盾をチェックさせる」工程をプロンプト内に組み込む。
ライセンス:本記事のテキスト/コードは特記なき限り
CC BY 4.0 です。引用の際は出典URL(本ページ)を明記してください。
利用ポリシー もご参照ください。
コメント