<p><thought>
この回答では、複雑な計算と論理推論を必要とする「在庫補充計画」を題材に、Chain-of-Thought (CoT) を活用したプロンプト設計を行います。推論ステップの構造化、Few-shotによる思考パターンの固定、および誤り分析に基づくLLM-as-a-Judgeの基準策定という、実務的な最適化プロセスを提示します。
</thought></p>
<p>[METADATA]
{
“expert_type”: “Prompt Engineer”,
“methodology”: “Chain-of-Thought (CoT) Optimization”,
“target_models”: [“Gemini 1.5 Pro”, “GPT-4o”],
“version”: “1.0.1”
}
[/METADATA]</p>
<p>本記事は<strong>Geminiの出力をプロンプト工学で整理した業務ドラフト（未検証）</strong>です。</p>
<h1 class="wp-block-heading">論理的推論を深化させるCoTプロンプト：複雑な在庫管理ロジックの解決</h1>
<h3 class="wp-block-heading">【ユースケース定義と課題】</h3>
<p>複数拠点の在庫変動、リードタイム、予測需要を統合した補充計算。計算ステップが多いため、中間計算での脱落や論理矛盾が発生しやすい。</p>
<ul class="wp-block-list">
<li><p><strong>入力</strong>: 拠点別在庫データ、需要予測値（Markdown/CSV形式）</p></li>
<li><p><strong>出力</strong>: 補充推奨数と計算根拠（JSON形式）</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["実行: Few-shot CoTの投入"]
B --> C["評価: 推論過程の論理チェック"]
C -->|計算ミスの修正| A
</pre></div>
<ol class="wp-block-list">
<li><p><strong>設計</strong>: LLMが辿るべき思考の道筋（現状確認→需要分析→過不足算出→最終決定）を定義します。</p></li>
<li><p><strong>実行</strong>: 思考過程を含めた正解例（Few-shot）を与え、モデルの推論をガイドします。</p></li>
<li><p><strong>評価</strong>: 最終結果だけでなく、途中の数式や論理に飛躍がないかをスコアリングします。</p></li>
</ol>
<h3 class="wp-block-heading">【プロンプトの実装案】</h3>
<div class="codehilite">
<pre data-enlighter-language="generic"># 指示
あなたは高度なサプライチェーン・アナリストです。
以下のデータに基づき、各商品の補充推奨数を算出してください。
回答は、必ず【思考プロセス】を記述した後に、指定のJSON形式で出力してください。
# 思考プロセスの手順
1. 各拠点の現在庫と安全在庫の差分を算出する。
2. リードタイム期間中の予測需要を合算する。
3. 必要補充量 = (安全在庫 + 予測需要) - 現在庫 を計算する。
4. 負の値（過剰在庫）の場合は補充0とする。
# 例示 (Few-shot CoT)
入力: 商品A, 現在庫10, 安全在庫20, 予測需要15
思考プロセス:
- 現在、安全在庫に対して10個不足している。
- 予測需要15個を加味すると、合計で25個の在庫が必要。
- 補充推奨数は25個となる。
出力: {"item": "商品A", "replenishment": 25}
# 対象データ
[ここにデータを入力]
# 出力形式
{
"reasoning": "思考プロセスの要約",
"results": [
{"item": "商品名", "replenishment": 数値}
]
}
</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>
<th style="text-align:left;">対策</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:left;"><strong>推論整合性</strong></td>
<td style="text-align:left;">思考プロセスとJSONの値が一致</td>
<td style="text-align:left;">思考では「25」と言いつつJSONで「10」と出力</td>
<td style="text-align:left;">Step-by-stepの強制と出力形式の再定義</td>
</tr>
<tr>
<td style="text-align:left;"><strong>計算精度</strong></td>
<td style="text-align:left;">四則演算が正確である</td>
<td style="text-align:left;">桁の読み間違い、単純な足し算ミス</td>
<td style="text-align:left;">Pythonコード実行（Code Interpreter）の併用検討</td>
</tr>
<tr>
<td style="text-align:left;"><strong>フォーマット</strong></td>
<td style="text-align:left;">有効なJSON形式</td>
<td style="text-align:left;">思考プロセスがJSON内に混入する</td>
<td style="text-align:left;">デリミタ（###）による明確な構造分離</td>
</tr>
</tbody>
</table></figure>
<h3 class="wp-block-heading">【改良後の最適プロンプト】</h3>
<div class="codehilite">
<pre data-enlighter-language="generic"># 役割
論理的推論に長けたSCM専門家
# タスク
提供された在庫データに基づき、補充計画を策定せよ。
# 思考制約 (Chain-of-Thought)
回答を作成する前に、以下のステップで「思考の連鎖」を書き出してください。
1. **現状分析**: 各項目の数値を正確に把握する。
2. **需要計算**: 期間中の総需要を特定する。
3. **論理チェック**: 在庫が足りているか、補充が必要か、計算式を2回確認する。
# 出力ルール
- 思考プロセスは ` <thought> ` タグ内に記述すること。
- 最終結果は ` <json> ` タグ内に厳密なJSON形式で出力すること。
- 根拠のない推測（ハルシネーション）は一切排除すること。
# データ
[データ挿入]
</pre>
</div>
<h3 class="wp-block-heading">【まとめ】</h3>
<ol class="wp-block-list">
<li><p><strong>思考の可視化</strong>: <code>Let's think step by step</code> だけでなく、具体的なステップ（手順1, 2…）を指示に組み込む。</p></li>
<li><p><strong>タグによる構造化</strong>: <code><thought></code> と <code><json></code> のように、推論用と出力用の領域を明確に分けることで、パースエラーを防ぐ。</p></li>
<li><p><strong>Few-shotの有効活用</strong>: 複雑なタスクほど、1つの完璧な回答例がLLMの振る舞いを劇的に安定させる。</p></li>
</ol>
この回答では、複雑な計算と論理推論を必要とする「在庫補充計画」を題材に、Chain-of-Thought (CoT) を活用したプロンプト設計を行います。推論ステップの構造化、Few-shotによる思考パターンの固定、および誤り分析に基づくLLM-as-a-Judgeの基準策定という、実務的な最適化プロセスを提示します。
[METADATA]
{
“expert_type”: “Prompt Engineer”,
“methodology”: “Chain-of-Thought (CoT) Optimization”,
“target_models”: [“Gemini 1.5 Pro”, “GPT-4o”],
“version”: “1.0.1”
}
[/METADATA]
本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。
論理的推論を深化させるCoTプロンプト：複雑な在庫管理ロジックの解決
【ユースケース定義と課題】
複数拠点の在庫変動、リードタイム、予測需要を統合した補充計算。計算ステップが多いため、中間計算での脱落や論理矛盾が発生しやすい。
【プロンプト設計のループ】
graph TD
A["設計: 思考ステップの定義"] --> B["実行: Few-shot CoTの投入"]
B --> C["評価: 推論過程の論理チェック"]
C -->|計算ミスの修正| A
設計: LLMが辿るべき思考の道筋（現状確認→需要分析→過不足算出→最終決定）を定義します。
実行: 思考過程を含めた正解例（Few-shot）を与え、モデルの推論をガイドします。
評価: 最終結果だけでなく、途中の数式や論理に飛躍がないかをスコアリングします。
【プロンプトの実装案】
# 指示
あなたは高度なサプライチェーン・アナリストです。
以下のデータに基づき、各商品の補充推奨数を算出してください。
回答は、必ず【思考プロセス】を記述した後に、指定のJSON形式で出力してください。
# 思考プロセスの手順
1. 各拠点の現在庫と安全在庫の差分を算出する。
2. リードタイム期間中の予測需要を合算する。
3. 必要補充量 = (安全在庫 + 予測需要) - 現在庫 を計算する。
4. 負の値（過剰在庫）の場合は補充0とする。
# 例示 (Few-shot CoT)
入力: 商品A, 現在庫10, 安全在庫20, 予測需要15
思考プロセス:
- 現在、安全在庫に対して10個不足している。
- 予測需要15個を加味すると、合計で25個の在庫が必要。
- 補充推奨数は25個となる。
出力: {"item": "商品A", "replenishment": 25}
# 対象データ
[ここにデータを入力]
# 出力形式
{
"reasoning": "思考プロセスの要約",
"results": [
{"item": "商品名", "replenishment": 数値}
]
}
【評価指標と誤り分析】
| 評価項目 |
期待値 |
失敗パターン |
対策 |
| 推論整合性 |
思考プロセスとJSONの値が一致 |
思考では「25」と言いつつJSONで「10」と出力 |
Step-by-stepの強制と出力形式の再定義 |
| 計算精度 |
四則演算が正確である |
桁の読み間違い、単純な足し算ミス |
Pythonコード実行（Code Interpreter）の併用検討 |
| フォーマット |
有効なJSON形式 |
思考プロセスがJSON内に混入する |
デリミタ（###）による明確な構造分離 |
【改良後の最適プロンプト】
# 役割
論理的推論に長けたSCM専門家
# タスク
提供された在庫データに基づき、補充計画を策定せよ。
# 思考制約 (Chain-of-Thought)
回答を作成する前に、以下のステップで「思考の連鎖」を書き出してください。
1. **現状分析**: 各項目の数値を正確に把握する。
2. **需要計算**: 期間中の総需要を特定する。
3. **論理チェック**: 在庫が足りているか、補充が必要か、計算式を2回確認する。
# 出力ルール
- 思考プロセスは ` <thought> ` タグ内に記述すること。
- 最終結果は ` <json> ` タグ内に厳密なJSON形式で出力すること。
- 根拠のない推測（ハルシネーション）は一切排除すること。
# データ
[データ挿入]
【まとめ】
思考の可視化: Let's think step by step だけでなく、具体的なステップ（手順1, 2…）を指示に組み込む。
タグによる構造化: <thought> と <json> のように、推論用と出力用の領域を明確に分けることで、パースエラーを防ぐ。
Few-shotの有効活用: 複雑なタスクほど、1つの完璧な回答例がLLMの振る舞いを劇的に安定させる。
ライセンス：本記事のテキスト/コードは特記なき限り
CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。
コメント